专利名称：协议转换设备和方法
技术领域：
本发明涉及协议转换设备和方法，尤其涉及在使用不同物理线路的设备被连接时所应用的协议转换设备和方法。
背景技术：
WCDMA(宽带CDMA)系统中的无线接口的协议体系结构包括物理层(第1层)、数据链路层(第2层)和网络层(第3层)。第2层具有用于传送控制信号的信令的C-平面(C-Plane)，以及用于传送用户信息的U-平面(U-Plane)。
在利用不同物理线路连接设备时，IWF(Inter Working Function，互工作功能)设备被用作协议转换设备。传统IWF设备的配置没有被划分为C-平面和U-平面(例如参见参考文献1(3GPP TR25.933 V5.2.0(2002-09))。
由于此原因，如果配置实际上被划分成C-平面和U-平面，则在如何端接(terminate)每个协议以及如何获取预定资源的参数的资源预定方法中出现了问题。这抑制了具有增加/减少U-平面的高缩放性(scalability)的配置的使用。参考文献1中没有描述资源预定。
发明内容
本发明被用来克服传统缺陷，其目标是提供一种可采用具有高缩放性的配置的协议转换设备和方法。
为了实现上述目标，根据本发明，连接在使用不同物理线路的第一设备和第二设备之间的一种协议转换设备的特征在于包括C-平面设备，其控制所述第一设备和所述第二设备之间的信令；以及U-平面设备，其控制所述第一设备和所述第二设备之间的用户数据传送。
此外，根据本发明，在使用不同物理线路的第一设备和第二设备被连接时应用的一种协议转换方法的特征在于包括通过C-平面设备来控制所述第一设备和所述第二设备之间的信令的第一步骤，以及通过独立于所述C-平面设备安排的U-平面设备来控制所述第一设备和所述第二设备之间的用户数据传送的第二步骤。
图1是示出根据第一实施例的IWF设备的配置的框图；图2是示出图1中的IWF-c和IWF-u的配置的框图；图3是示出根据第一实施例的C-平面的协议栈的视图；图4是示出根据第一实施例在发布CS呼叫时的操作的序列图；图5是示出根据第一实施例在发布PS呼叫时的操作的序列图；图6是示出图1中的IWF-c的操作的流程图；图7是示出图1中的IWF-c的操作的流程图；图8是示出图1中的IWF-u的操作的流程图；图9是示出图1中的IWF-u的操作的流程图；图10是示出根据第二实施例的IWF设备的配置的框图；图11是示出图10中的IWF-c和IWF-u的配置的框图；图12是示出根据第二实施例的C-平面的协议栈的视图；图13是示出根据第二实施例在发布CS呼叫时的操作的序列图；图14是示出根据第二实施例在发布PS呼叫时的操作的序列图；以及图15是示出图10中的IWF-u的操作的流程图。
具体实施例方式
以下将参考附图描述本发明的实施例。
第一实施例图1是示出根据本发明的第一实施例作为协议转换设备的IWF(互工作功能)设备的配置的框图。在图1中，IWF设备3包括主要执行信令控制的IWF-c 31，以及主要执行用户数据传送的IWF-u 32和33。IWF-c 31对应于用于传送控制信号的信令的C-平面，而IWF-u 32和33对应于用于传送用户信息的U-平面。注意信令是指连接线路的过程，用户信息是流经由信令连接的线路的分组。
IWF设备3连接在用作第一设备的MSC(Mobile Switching Center，移动交换中心)4或SGSN[Serving GPRS(General Packet Radio Service)Support Node，服务GPRS(通用分组无线业务)支持节点]5，以及用作第二设备的RNC(Radio Network Controllerbase station control device，无线网络控制器基站控制设备)1之间。IWF设备3和MSC 4或SGSN 5由ATM(Asynchronous Transfer Mode，异步传送模式)传输协议栈连接，该协议栈由3GPP(3rd Generation Partnership Projects，第三代合作伙伴计划)版本99定义。IWF设备3和RNC 1由IP(Internet Protocol，因特网协议)传输协议栈连接，该协议栈由3GPP版本5定义。这些协议栈作为Iu接口被详细描述在参考文献2(3GPP TS25.412 V5.1.0(2002-09))等中。
IWF设备3的IWF-c 31转换信令中的ATM传输协议栈和IP传输协议栈。IWF设备3的IWF-u 32和33转换用户信息传送中的ATM传输协议栈和IP传输协议栈。
RNC 1包括发送/接收控制信号的控制信号发送/接收部分(信令控制设备)11到13，以及发送/接收用户信息的数据发送/接收部分21到23。
图2是示出图1中的IWF-c 31和IWF-u 32的配置的框图。在图2中，IWF-c 31是由资源管理单元311、协议端接单元312和314以及与IWF-u 32的接口(I/F)单元313形成的。IWF-u 32是由交换机控制单元321、交换机322、与IWF-c 31的接口(I/F)单元323、ATM侧的协议端接单元324到326以及IP(因特网协议)侧的协议端接单元327到329形成的。
图3是示出根据第一实施例的C-平面协议栈的视图。在图3中，RNC1由数据链路层、IP层、SCTP(Stream Control Transmission Protocol，流控制传输协议)层、M3UA[SS7(Signalling System No.7)MTP3(MessageTransfer Part 3)User Adaptation，SS7(7号信令系统)MTP3(消息传送部分3)用户自适应]层、SCCP(Signalling Connection Control Part，信令连接控制部分)层和RANAP(Radio Access Network Application Part，无线访问网络应用部分)层构成。
IWF-c 31在RNC 1侧是由数据链路层、IP层、SCTP层、M3UA层、SCCP层和RANAP层形成的，在MSC 4和SGSN 5侧是由ATM层、SAAL-NNI(Signalling ATM Adaptation Layer-Network Node Interface，信令ATM自适应层-网络节点接口)层、MTP3-B(消息传送部分3-B)层、SCCP层和RANAP层形成的。
MSC 4和SGSN 5各自是由ATM层、SAAL-NNI层、MTP3-B层、SCCP层和RANAP层形成的。
在这种情况下，SCCP层的一个终端由IWF设备3端接。相反，作为最高信令协议的RANAP层被端接在RNC 1和MSC 4或SGSN 5之间，虽然部分RANAP层必须被确定。某些消息的关于资源地址的内容变化。
由于用IWF设备3端接SCCP层的一个终端，对于一个呼叫，两个SCCP连接被建立在RNC 1和IWF之间以及IWF和MSC 4或SGSN 5之间。SCCP层在IWF设备3的资源管理单元311中具有SCCP对应表，用于使得两个SCCP连接彼此对应。根据此表，IWF设备3端接SCCP的一个终端，识别呼叫信息，并将呼叫再次发送到适当的目的地。因此，可从RNC 1中的控制信号发送/接收部分11到13中选出适当的发送/接收部分。
注意CS(Circuit Switched，电路交换)呼叫已被详细描述，并且上述描述也适用于使用SGSN 5而不是MSC 4的PS(Packet Switched，分组交换)呼叫。CS呼叫是使用MSC 4的音频线路呼叫，PS呼叫是使用SGSN5的分组通信呼叫。
图4是示出根据第一实施例在发布CS呼叫时的操作的序列图。以下将参考图4说明根据第一实施例在发布CS呼叫时直到每个设备的资源预定为止的操作。
当UE(User Equipment，用户设备)向RNC 1发送“连接请求”(图4中a1)时，呼叫序列开始。当RNC 1向MSC 4发送“初始UE消息”时，SCCP连接被建立在RNC 1和IWF-c 31之间，以及IWF-c 31和MSC4之间(图4中的a2和a3)。此时，RNC 1和IWF-c 31之间的SCCP连接被定义为SCCP连接#1，IWF-c 31和MSC 4之间的SCCP连接被定义为SCCP连接#2。
IWF-c 31只传递“初始UE消息”，将SCCP从SCCP连接#1迁移到SCCP连接#2，并且向MSC 4发送SCCP(图4中的a4和a5)。IWF-c 31的资源管理单元311创建SCCP对应表，该表表示SCCP连接#1和SCCP连接#2被相同呼叫使用。当SCCP连接由MSC 4在寻呼(Paging)等中首次建立时，IWF-c 31具有任意选择控制信号发送/接收部分的功能。
在呼叫使用过程中的多呼叫中，IWF-c 31具有根据对终端唯一的信息(例如IMSI(International Mobile Subscriber Identity，国际移动用户标识))确定终端是否在使用中并允许使用相同的控制信号发送/接收部分的装置。
在认证和隐蔽(concealment)被执行后(图4中a6)，MSC 4预定用户数据资源(图4中a7)，并向RNC 1发送“RAB分配请求”(第一资源请求)，以预定无线资源(图4中a8)。在接收到此消息时，IWF-c 31确定IWF-u 32和33的资源必须被预定。以下将说明IWF-u 32的资源被预定的情况。
“RAB分配请求”包含被MSC 4用于传送用户数据的第一参数(例如地址)。IWF-c 31的资源管理单元311从“RAB分配请求”获取第一参数，将第一参数添加到资源请求(第二资源请求)，并向IWF-u 32发送资源请求(图4中a9)。
IWF-u 32的交换机控制单元321从接收到的资源请求中获取第一参数，预定用户数据资源(图4中a10)，并向IWF-c 31发送资源已被预定的通知(图4中a11)。此通知包含被IWF-u 32用于传送用户数据的第二参数(例如RNC 1的地址)。
IWF-c 31的资源管理单元311从接收到的通知中获取第二参数。资源管理单元311用IWF-u 32的地址重写MSC 4的地址，MSC 4的地址用作“RAB分配请求”中的用户数据传送目的地地址。资源管理单元311将重写后的“RAB分配请求”发送到RNC 1中的适当的控制信号发送/接收部分(图4中a12)。适当的控制信号发送/接收部分的选择利用了SCCP对应表。
此后，RNC 1预定用户数据资源(图4中a13)。为了建立U-平面，RNC 1将“建立请求”发送到IWF-u 32的地址，该地址是由“RAB分配请求”通知的(图4中a14)。此通知包含RNC 1的用户数据地址。通知的发送可利用IPALCAP(IP Access Link Control Application Protocol，IP访问链路控制应用协议)。
在接收到通知时，IWF-u 32通过ALCAP(Access Link ControlApplication Protocol，访问链路控制应用协议)向MSC 4发送“建立请求”(图4中a15)。作为MSC 4的目的地，已预先从IWF-c 31通知来的MSC 4的地址被使用。
“建立确认”作为确认消息被从MSC 4发送到IWF-u 32，并且被从IWF-u 32发送到RNC 1(图4中a16和a17)。然后，在UE和RNC 1之间，无线资源被预定(图4中a18)。当无线资源被预定时，“RAB分配响应”被从RNC 1发送到IWF-u 32，并被从IWF-u 32发送到MSC 4，完成用户数据传送路径的建立(图4中a19和a20)。
通过利用建立的路径，用户数据被传送。
当IWF-u 33的资源被预定时，也执行相同的过程。
图5是示出根据第一实施例在发布PS呼叫时直到每个设备的资源预定为止的操作的序列图。以下将参考图5说明根据第一实施例在发布PS呼叫时直到每个设备的资源预定为止的操作。
参见图5，在发布PS呼叫时直到每个设备的资源预定为止的操作与以上描述的在发布CS呼叫时直到每个设备的资源预定为止的操作几乎相同。即，图5中b1到b13中的操作与图4中a1到a13中的操作相同。但是，PS呼叫不使用ALCAP或IPALCAP，从而最后的“RAB分配响应”与图4中的不同。
当在UE和RNC 1之间无线资源被预定之后(图5中b14)，IWF-c31通过“RAB分配响应”完成用户传送路径的建立(图5中b15)。然后，IWF-c 31通过“RAB分配响应”获取RNC 1的用户数据地址，并将该地址通知给IWF-u 32(图5中b16)。作为响应，IWF-u 32将MSC 4侧IWF-u 32的地址通知给IWF-c 31(图5中b17)。IWF-c 31获取该地址，并用IWF-u 32的地址重写RNC 1的地址，其中RNC 1的地址用作“RAB分配响应”中的用户数据传送目的地地址。IWF-c 31向MSC 4发送重写后的“RAB分配响应”(图5中的b18)。
此时，SCCP连接利用SCCP对应表。SCCP被分配线路号码，以确认每个链路。对于每个链路号码，SCCP对应表存储表示链路号码到MSC 4或SGSN以及链路号码到RNC 1之间的对应的信息。
后面的过程与以上描述的在发布CS呼叫时的过程相同。
当IWF-u 33的资源被预定时，执行相同的过程。
预定资源的序列已在图4和5所示的以上操作中详细说明。资源也可通过相同序列来释放。
图6和7是示出IWF-c 31的操作的流程图。以下将参考图6和7说明IWF设备3中的IWF-c 31的操作。
在接收到信令时(图6中步骤S1)，IWF-c 31确定它是否已从RNC 1或MSC 4接收到信令(图6中步骤S2)。
对于从RNC 1接收到的RANAP信令，仅对于表示对PS呼叫的资源预定响应的“RAB分配响应”(图7中的步骤S14)，IWF-c 31将RNC地址通知给IWF-u 32和33(图7中步骤S15)。
IWF-c 31等待来自IWF-u 32和33的响应，并获取IWF-u(RNC 1侧)地址(图7中步骤S16)。IWF-c 31用IWF-u 32和33的地址重写信令中用户数据的RNC地址(图7中步骤S17)，并向MSC 4发送RANAP信令(图7中步骤S18)；否则IWF-c 31直接向MSC 4发送RANAP信令(图7中步骤S18)。
在从MSC 4接收到RANAP信令时(图6中步骤S3)，如果在来自MSC 4的第一RANAP信令(例如寻呼)时，尚未对控制信号发送/接收部分号码和SCCP连接创建SCCP对应表(图6中步骤S4)，则IWF-c 31任意选择控制信号发送/接收部分，并将RANAP信令直接发送到控制信号发送/接收部分(图6中步骤S11到S13)。
如果SCCP连接和控制信号发送/接收部分号码之间的对应尚未被创建，则SCCP对应表被创建(图6中步骤S12)。SCCP对应表在呼叫结束(SCCP连接结束)时被删除。
IWF-c 31确定RANAP信令是否是“RAB分配请求”，以预定用户数据资源(图6中步骤S6)。如果RANAP信令是预定用户数据资源的请求，则IWF-c 31与IWF-u 32和33交换信令，并预定IWF-u 32和33的资源。然后，IWF-c 31用IWF-u 32和33的地址重写用作RANAP信令的用户数据传送目的地的MSC 4的地址(图6中步骤S7到S9)，从SCCP对应表获取控制信号发送/接收部分的目的地，并将信令发送到控制信号发送/接收部分(图6中步骤S10)。
如果请求不预定用户数据资源，则IWF-c 31在不改变RANAP的情况下将RANAP信令发送到适当的控制信号发送/接收部分(图6中步骤S10)。
图8和9是示出图1中IWF-u 32和33的操作的流程图。以下将参考图8和9说明IWF-u 32和33的操作。
在从IWF-c 31接收到资源预定信令时(图8中步骤S23和图9中步骤S28)，IWF-u 32和33预定其内部资源(图9中步骤S29)。IWF-u 32和33根据其IWF-u地址存储通过信令通知的MSC 4的地址，并将IWF-u地址通知给IWF-c 31(图9中步骤S30)。
在从RNC 1接收到信令时(图8中步骤S24)，IWF-u 32和33将IPALCAP信令迁移到ALCAP，并将信令发送到对应的MSC地址(图8中步骤S27)。
在从MSC 4接收到信令时(图8中步骤S25)，IWF-u 32和33将ALCAP信令迁移到IPALCAP，并将信令发送到对应的RNC地址(图8中步骤S26)。
如上所述，IWF-u 32和33通过与从RNC 1或MSC 4接收信令相同的用户数据流程转换协议。
通过这种方式，根据第一方法，IWF设备3被划分成C-平面设备(IWF-c 31)和U-平面设备(IWF-u 32和33)，并且IWF设备3可采用具有高缩放性的配置。更具体而言，IWF-c 31不受IWF-u 32和33的数目的增大/减小影响。
在第一实施例中，由于IWF设备3在每个呼叫中端接SCCP，因此多个控制信号发送/接收部分11到13可被安装在RNC 1上。通常，只有一个控制信号发送/接收部分被用作RNC 1。
在第一实施例中，当IWF设备3被划分成C-平面设备(IWF-c 31)和U-平面设备(IWF-u 32和33)时，响应于来自C-平面设备(IWF-c 31)的请求，在U-平面设备(IWF-u 32和33)中资源被预定，利用最短的路径分布了IP流量的负载。
第二实施例图10是示出根据本发明的第二实施例作为协议转换设备的IWF设备的配置的框图。第二实施例与上述第一实施例的不同之处在于在图10中，在IWF-c 31和IWF设备7中的IWF-u 71和72之间没有信号被发送/接收，并且IWF-u 71和72是由RNC 6的控制信号发送/接收部分61到63控制的。与第一实施例相同的参考标号表示相同的部件。
在第一实施例中，IWF-c 31需要识别RANAP信令，从而必须对所有信令解码，以识别“RAB分配请求”是否存在。相反，在第二实施例中，IWF-u 71和72的资源是由RNC 6中的控制信号发送/接收部分61到63管理的。从而，IWF-c 31不需要对RANAP信令解码，简化了IWF-c 31的过程。
图11是示出图10中的IWF-c 31和IWF-u 71的配置的框图。在图11中，IWF-c 31是由协议端接单元312和314以及信号传送单元315形成的。IWF-u 71是由资源管理单元711、交换机322、ATM侧的协议端接单元324到326以及IP(因特网协议)侧的协议端接单元327到329和712形成的。
图12是示出根据第二实施例的C-平面协议栈的视图。第二实施例与上述第一实施例的不同之处在于协议栈中的SCCP层和RANAP层不由IWF-c 31端接。剩余部分与第一实施例相同。
图13是示出根据第二实施例在发布CS呼叫时的操作的序列图。以下将参考图13说明根据第二实施例在发布CS呼叫时直到每个设备的资源预定为止的操作。
在图13中，根据第二实施例，SCCP连接被端接在RNC 6和MSC 4之间，并且IWF-c 31不涉及端接。由于标识RNC 6所使用的控制信号发送/接收部分的标记被附于SCCP连接中，因此IWF-c 31可确定该标记，以选择适当的控制信号发送/接收部分。
从MSC 4发送来的“RAB分配请求”(第四资源请求)在不被IWF-c 31涉及的情况下到达RNC 6(图13中c6)。在接收到“RAB分配请求”时，RNC 6预定用户数据资源(图13中c7)。预定了资源的RNC 6向IWF-u 71发送资源请求(第三资源请求)，以预定IWF-u 71的资源(图13中c8)。通过将RNC 6的地址添加到资源请求中MSC 4的地址，资源请求取代了IPALCAP的“建立请求”。
IWF-u 71获取用作用户数据传送目的地的MSC 4的地址，并预定用户数据资源(图13中c9)。IWF-u 71通过ALCAP将“建立请求”发送到MSC 4(图13中c10)。IWF-u 71等待响应于请求而通过ALCAP发送回IWF-u 71的“建立确认”(图13中c11)。然后，IWF-u 71将IWF-u71的地址通知给RNC 6(图13中c12)。
后面的过程与第一实施例的相同。
当IWF-u 72的资源被预定时，也执行相同的过程。
图14是示出根据第二实施例的PS呼叫时的操作的序列图。以下将参考图14说明根据第二实施例在发布PS呼叫时直到每个设备的资源预定为止的操作。
由于PS呼叫不使用ALCAP的“建立请求”，因此在“RAB分配响应”中，在CS呼叫和PS呼叫之间没有操作需要更改(图14中d12)。
在第二实施例中，IWF-c 31不需要预定任何资源，并且RNC 6中的控制信号发送/接收部分61到63预定资源。IWF-c 31可省略图6和7中所示的确定步骤，只执行较低层的协议转换。
图15是示出图10中的IWF-u 71的操作的流程图。在图15中，步骤S41到S48中的过程与图8和9中所示的那些相同。由于步骤S23和S28中的确定过程被省略，确定过程的数目减少，因此IWF-u 71执行的过程可被简化。
如上所述，根据第二实施例，由于RNC 6中的控制信号发送/接收部分61到63控制预定IWF-u 71和72的资源的信令，因此IWF-c 31不需要对RANAP信令解码，并且不需要端接任何SCCP连接。由于IWF-c 31和IWF-u 71和72变得彼此不相关，因此可确保实现的灵活性，并且IWF-u71和72易于实现在RNC 6中。
正如以上已经描述的，根据以上实施例的IWF设备3或7被划分成用于控制信令的C-平面设备和用于控制用户数据的U-平面设备，从而可采用具有高缩放性的配置。RNC 1或6也可采用具有高缩放性的配置。注意IWF设备3或7不仅可被应用在其连接在不同物理线路间之时，还可被应用在不同中间协议被用于相同物理线路时。
权利要求
1.一种协议转换设备，其连接在使用不同物理线路的第一设备和第二设备之间，其特征在于包括C-平面设备，其控制所述第一设备和所述第二设备之间的信令；以及U-平面设备，其控制所述第一设备和所述第二设备之间的用户数据传送。
2.如权利要求1所述的协议转换设备，其特征在于所述C-平面设备包括资源管理单元，在来自所述第一设备的预定用户数据资源的第一资源请求被接收到时，所述资源管理单元将第二资源请求发送到所述U-平面设备，以及所述U-平面设备包括控制单元，在所述第二资源请求被接收到时，所述控制单元预定所述U-平面设备中的所述用户数据资源。
3.如权利要求2所述的协议转换设备，其特征在于所述资源管理单元获取包含在所述第一资源请求中并用于传送所述第一设备中的用户数据的第一参数，并将所述参数添加到所述第二资源请求中。
4.如权利要求3所述的协议转换设备，其特征在于在资源被预定后，所述控制单元向所述C-平面设备发送资源预定通知，用于传送所述U-平面设备中的所述用户数据的第二参数被添加到所述资源预定通知中，以及所述资源管理单元根据接收到的资源预定通知获取所述第二参数，并向所述第二设备传送通过用所述第二参数重写所述第一资源请求中包含的所述第一参数而获得的第一资源请求。
5.如权利要求1所述的协议转换设备，其特征在于所述U-平面设备包括资源管理单元，在来自所述第二设备的预定所述用户数据资源的第三资源请求被接收到时，所述资源管理单元预定所述U-平面设备中的用户数据资源。
6.如权利要求5所述的协议转换设备，其特征在于所述资源管理单元获取包含在所述第三资源请求中并用于传送所述第一设备和所述第二设备中的所述用户数据的参数。
7.如权利要求5所述的协议转换设备，其特征在于当来自所述第一设备的预定所述用户数据资源的第四资源请求被接收到时，所述第二设备将所述第三资源请求发送到所述U-平面设备。
8.如权利要求1所述的协议转换设备，其特征在于所述第一设备是利用ATM(Asynchronous Transfer Mode，异步传送模式)传输协议栈的MSC(Mobile Switching Center，移动交换中心)和SGSN[Serving GPRS(General Packet Radio Service)Support Node，服务GPRS(通用分组无线业务)支持节点]中的至少一个，以及所述第二设备是利用IP(Internet Protocol，因特网协议)传输协议栈的基站控制设备。
9.如权利要求8所述的协议转换设备，其特征在于SCCP(SignallingConnection Control Part，信令连接控制部分)连接被建立在所述C-平面设备和所述MSC和SGSN中的至少一个之间，以及所述C-平面设备和所述基站控制设备之间。
10.如权利要求9所述的协议转换设备，其特征在于所述基站控制设备包括多个信令控制设备，用于发送/接收控制信号，以及所述C-平面设备存储使得每个信令控制设备的号码与SCCP连接彼此对应的SCCP对应表，并在信令被从所述MSC和SGSN中的至少一个接收到时，根据所述SCCP对应表选择所述信令控制设备之一。
11.一种协议转换方法，其被应用在使用不同物理线路的第一设备和第二设备被连接时，其特征在于包括第一步骤，该步骤通过C-平面设备来控制所述第一设备和所述第二设备之间的信令，以及第二步骤，该步骤通过独立于所述C-平面设备安排的U-平面设备来控制所述第一设备和所述第二设备之间的用户数据传送。
12.如权利要求11所述的协议转换方法，其特征在于所述第一步骤包括第三步骤，该步骤将来自所述第一设备的预定用户数据资源的第一资源请求发送到所述C-平面设备，第四步骤，该步骤在所述C-平面设备接收到所述第一资源请求时将第二资源请求发送到所述U-平面设备，以及第五步骤，该步骤在所述U-平面设备接收到所述第二资源请求时预定所述U-平面设备中的所述用户数据资源。
13.如权利要求12所述的协议转换方法，其特征在于所述第四步骤包括以下步骤获取包含在所述第一资源请求中并用于传送所述第一设备中的所述用户数据的第一参数，并将所述参数添加到所述第二资源请求中。
14.如权利要求13所述的协议转换方法，其特征在于所述第一步骤包括所述第五步骤之后的第六步骤，该步骤向所述C-平面设备发送资源预定通知，用于传送所述U-平面设备中的所述用户数据的第二参数被添加到所述资源预定通知中，第七步骤，该步骤从接收到的资源预定通知获取所述第二参数，并向所述第二设备传送第一资源请求，该第一资源请求是通过用所述第二参数重写包含在所述第一资源请求中的所述第一参数来获得的。
15.如权利要求11所述的协议转换方法，其特征在于所述第一步骤包括第八步骤，该步骤将来自所述第二设备的预定用户数据资源的第三资源请求发送到所述U-平面设备，以及第九步骤，该步骤在所述U-平面设备接收到所述第三资源请求时，预定所述U-平面设备中的所述用户数据资源。
16.如权利要求15所述的协议转换方法，其特征在于所述第九步骤包括以下步骤获取包含在所述第三资源请求中并用于传送所述第一设备和所述第二设备中的所述用户数据的参数。
17.如权利要求15所述的协议转换方法，其特征在于所述第一步骤还包括所述第八步骤之前的第10步骤，该步骤将来自所述第一设备的预定所述用户数据资源的第四资源请求发送到所述第二设备，以及所述第八步骤包括以下步骤在所述第二设备接收到所述第四资源请求时，将所述第三资源请求发送到所述U-平面设备。
18.如权利要求11所述的协议转换方法，其特征在于所述第一设备是利用ATM(Asynchronous Transfer Mode，异步传送模式)传输协议栈的MSC(Mobile Switching Center，移动交换中心)和SGSN[Serving GPRS(General Packet Radio Service)Support Node，服务GPRS(通用分组无线业务)支持节点]中的至少一个，以及所述第二设备是利用IP(Internet Protocol，因特网协议)传输协议栈的基站控制设备。
19.如权利要求18所述的协议转换方法，其特征在于所述第一步骤包括第11步骤，该步骤在所述C-平面设备和所述MSC和SGSN中的至少一个之间以及所述C-平面设备和所述基站控制设备之间建立SCCP(Signalling Connection Control Part，信令连接控制部分)连接。
20.如权利要求19所述的协议转换方法，其特征在于所述第一步骤还包括第12步骤，该步骤在信令被从所述MSC和SGSN中的至少一个接收到时，根据SCCP对应表选择多个信令控制设备中的一个，所述SCCP对应表使每个所述基站控制设备的信令控制设备的号码与SCCP连接彼此对应。
全文摘要
IWF设备(3)被划分成作为控制信令的C平面设备的IWF－c(31)以及作为控制用户数据的U平面设备的IWF－u(32，33)。从而，可以构成具有灵活可缩放性的配置。
文档编号H04L29/06GK1754369SQ200480005109
公开日2006年3月29日 申请日期2004年2月10日 优先权日2003年2月26日
发明者坂田正行, 小岛正彦 申请人:日本电气株式会社