专利名称：实时数据传输系统和方法
技术领域：
本发明涉及实时数据传输系统和方法。
采用第三代网际协议工业中心组体系(third generation internetprotocol industrial focus group architecture,3G IP)和第三代伙伴项目体系(third generation partnership project architecture,3G PP)的电话网络的结构如下任何在网际协议上的语音(VoIP)数据流要在网络中经过一个比较长的路由。于是，在如图一表示的例子中，产生于移动站(mobile station,T1)2并且去往目标站(target station,T2)14的VoIP数据流采取如下路由从移动站2启程，数据流经过无线网络控制器(RNC)4送到服务GPRS(通用分组无线系统)支持节点(SGSN)6。从那里，信号经过网关GPRS支持节点(GGSN)8到媒体网关(MGW)12，以便和公用交换电话网(PSTN)互通，或者当需要转换代码时，通过其到达目标电话(T2)14。
采用上述路径的数据流处理是非常低效率的。
至今，在GGSN和VoIP媒体网关(MGW)的选择之间没有进行协调。GGSN的确定(当建立PDP承载通路时)和MGW的选择(由应用层呼叫控制来确定)是两个独立的过程。但是，当数据流不得不通过这两点时，已确定的GGSN和MGW会导致一个不够优化的数据流路由。例如，这种情况在移动站(MS)GGSN和MGW组成一个三角形时发生。
在公共地面移动网络(PLMN)(如移动电话接线员网络，mobiletelephone operators network)中的数据流不得不经过在RNC4和SGSN6之间的第一个接口In-ps，在SGSN6和GGSN8之间的第二个接口Gn。结果，每个信号包的报头获得如下协议栈或代码序列。实时传输协议/用户数据报协议/网际协议/GPRS通道协议/用户数据报协议/网际协议/L1,2(RTP/UDP/IP/GTP/UDP/IP/L1,2)。结果是，对于实时或语音服务，资源利用率低下(约25％)。
这个问题由新的移动电话系统体系来克服，该体系由在同一日期受理的同一申请人的同样未决的专利申请文件中也做出了描述。这个系统的问题是必须引入新的协议。
本发明的目的是提供一个改进的实时数据传输系统，在该系统中减少了协议的管理开销。
根据本发明，提供了一个实时数据传输系统，用于在移动站和目的地站之间进行上行和下行传输。在上行传输中，移动站通过产生一个包括其自身标识和目的地标识的报头，添加到有效载荷数据流中，以随附数据流中的有效载荷。无线网络控制器一旦收到数据流，向报头中添加一个从服务通用分组无线系统支持节点(SGSN)处获得的通道标识，以识别数据流，然后引导数据流直接到媒体网关。在下行传输中的媒体网关接收包含报头的数据流，该报头包括从呼叫控制系统获得的移动站标识和移动站输入端口标识，媒体网关采取行动，将报头中的移动站标识和输入端口标识替换为无线网络控制器的网际协议(IP)地址、输入端口标识和用以识别数据流的通道标识，(以上)所有都是从呼叫控制系统中获得的，并且然后，引导数据流直接到无线网络控制器，无线网络控制器采取行动将报头中的无线网络控制器地址替换成为移动站标识地址和输入端口标识，二者都是从呼叫控制系统获得的，并且响应接收到的通道标识数据来识别数据流，然后引导数据流到相关的无线承载通路中，将其与移动站链接。
根据本发明，进一步提供了一种在网络中的实时数据传输方法，该网络包括移动站；无线网络控制器；媒体网关；目的地站和呼叫控制系统。在该网络中，在移动站和目的地站之间的包括报头部分和载荷部分的数据流的通行需由报头部分的内容来管理，该方法包括在从移动站到目的地站之间的上行传输中，一个步骤是，向从移动站到无线网络控制器传输的数据流的报头部分添加两个基站的标识，一个步骤是，向流经无线网络控制器的数据流的报头加入从呼叫控制系统获得的通道标识，一个步骤是，从无线网络控制器向媒体网关转发数据流；以及在从目的地站到移动站的下行传输中，一个步骤是，向从目的地站流出的数据流的报头中添加移动站标识和端口标识，二者都是从呼叫控制系统中获得的，一个步骤是，当数据流流经媒体网关时，将数据流的报头中的移动站标识和端口标识替换为无线网络控制器地址、输入端口标识和数据流的通道标识，以上都是从呼叫控制系统中获得的，一个步骤是，发送数据流到无线网络控制器，一个步骤是，当数据流经过无线网络控制器时，将数据流的报头中的无线网络控制器地址和端口标识替换为移动系统地址和输入端口，二者都是从呼叫控制系统中获得的，以及一个步骤是，引导数据流到移动站。
根据本发明，还进一步提供了一种在网络中的实时数据传输方法，该网络包括移动站，无线网络控制器，媒体网关，目的地站和呼叫控制系统。在该网络中，在移动站和目的地站之间的包括报头部分和载荷部分的数据流的通行需由报头部分的内容来管理，该方法包括一个步骤是，当其从网络的一个位置流向另一个位置时，至少将报头部分中一些与地址相关的内容替换成与内部地址相关的内容，以减少通过网络的数据流的路径和报头部分相对载荷部分的大小比例。
现在通过示例，参照所附的示意图，对实施本发明的电话网络进行描述，其中
图1是现存网络的主要组成部分的方块图；图2是在同样未决的专利申请中所描述的网络的方块图，表现了网络主要组成部分之间的物理连接；图3是描绘图2网络主要组成部分之间逻辑连接的方块图；图4是表示在本地与PSTN之间互通的呼叫建立情况的方块图；图5是表示远程与PSTN之间互通的呼叫建立过程的方块图；图6是表示上行数据流处理的方块图；图7是表示在本地媒体网关的下行数据流处理的方块图；图8是表示在无线网络控制器中的下行数据流处理的方块图；图9是表示在无线网络控制器中使用基于端口号码的方案的下行数据流处理的方块图
图10是在通用移动电话系统UMTS中话音业务两条路径的方块图。
在图2所示的共同未决专利申请中的网络，包括PLMN网际协议(IP)核心或云20。这个核心20是通过无线网络控制器(RNC)/无线接入网(RAN)24与移动站22进行通讯的。PLMN IP核心20通过时分复用-实时传输协议、媒体网关(TDM-RTP)、MGW28与公用交换电话网(PSTN)/综合业务数字网(ISDN)26相连接。
PLMN IP核心20与一个网际协议IP骨干网30通过两条路由连接。第一条路由包含实时传输协议-实时传输协议媒体网关(RTP-RTP-MGW)32，而第二条路由包含SGSN34,GGSN36。媒体网关控制器40控制路由。
可见，语音网际协议数据流现在可以通过使用较少报头内容到达IP骨干网30。
图3表示在图2显示的组成部分之间的逻辑连接，控制连接用虚线表示，媒体连接用一条连续的单线表示，媒体和控制连接用一粗一细的平行线表示。
单元之间的接口如下Gx是RNC24和MGW28之间的接口，Gy是RNC24和MGW32之间的接口。Iu-ps是RNC24和SGSN34之间的接口。Gn是SGSN34和GGSN36之间的接口，Gi是GGSN36和IP骨干网30之间的接口。
可见，因为MGW28和32通过PLMN IP核心20与RNC24相连接，任意MGW可以与任意RNC在单一管理(移动运营者)域中对话。
我们可以认识到，VoIP流经过与PLMN IP核心网络20相连接的MGW28和32之一。如果呼叫数据流立即流向PSTN/ISDN网络，RTP/PSTN网关将被用到。否则，如果数据流流向另外的可以包括一个PSTN/ISDN网关的网际协议端点，则RTP-RTP GW32将被用到。MGW28和32都可以执行译码的功能。
在每次通讯会话中，每个VoIP流的MGW将成为锚点。选出的MGW可以在MGC40的控制下，在同一个系统中，将VoIP流从一个RNC24切换到另一个。该MGC40本身可能通过GGSN36从SGSN34接收指令。
为了运行图2表示的系统，需要实施多种新过程。
为了在移动站和其目的地之间建立任意呼叫，需要实施承载通路建立和呼叫建立，现介绍如下承载通路建立网际协议(IP)的承载通路，在第一阶段需要建立一个数据会话来传送数据包，于是一个分组数据PDP上下文在GPRS的正常方式下被建立。该上下文可能和所要求的信令服务的服务质量(QoS)特性相关联。
在呼叫建立过程的第一阶段之后，特别对于VoIP媒体数据流要求一个新的或修改的承载通路(PDP上下文)(这可以从特殊PDP类型中表现出来。)这类承载通路采用不同于正常情况的处理。当实际的多媒体路径是从RNC24直接到两个MGW,28和32中的一个时，SGSN34和GGSN36都不需要实际地为其分配资源。只有控制功能性需要被SGSN34和GGSN36执行。两条通道的标识(TID)，即GRPS通道协议标识，以正常方式被分配。
一旦接到VoIP媒体数据流的PDP上下文建立请求，SGSN34，将指示MGC40，并且，MGC将指示MGW28或32在被使用的本地MGW和RNC24之间预留资源。
一旦呼叫建立过程完成之后，在该承载通路的数据流处理将在以后被SGSN34指示和控制。
呼叫建立呼叫建立过程就路由确定而言与一般的或标准的VoIP呼叫控制过程不同，因为其总是要把本地MGW带入呼叫(数据流)路径。下面将考虑两种可能的情况对呼叫路由规则进行描述第一中呼叫建立的情况涉及与PSTN/ISDN网络26的互通，如图4所表示。在建立呼叫过程中，需获取以下信息(a)移动站22的网际协议地址IP1；(b)所选媒体网关28的网际协议地址IP2；
(c)在移动站22处的下行媒体数据流的用户数据报协议(UDP)端口号码，端口1；(d)在网关28处的上行媒体数据流的UDP端口号码，端口2；和(e)连接网关28到PSTN/ISDN网络22的干线号码(干线标识)。
呼叫从移动站22产生，以下高层和通用的过程将被执行。
移动站22初始化一个向CC(呼叫控制)服务器38的呼叫请求，该请求包括被叫方号码及移动站22的IP地址(IP1)CC服务器38分析被叫方号码并且，如果决定在本地和PSTN/ISDN网络22互通，它将根据如负载均衡/容量/所支持的编解码器来识别一个网关28(IP2)。
呼叫控制服务器38与(移动)站22和控制着被标识的网关28的媒体网关控制器(MGC)40，使用被采用的呼叫信令协议专用的消息进行对话，建立媒体路径并且，作为结果，媒体路径会包括网关28，端口号码端口1和端口2，以及TDM干线号码(干线标识)。
呼叫在移动站22中止，以下高层和通用的过程将被执行。
包含被叫方号码的呼叫请求经过信令网关(没有显示)从PSTN/ISDN网络22到达呼叫控制服务器38。
呼叫控制服务器38分析被叫方号码并且将其从呼叫控制服务器38中在本地可用的数据映射到移动站22的IP地址中(IP1)。
呼叫控制服务器38还根据如负载均衡/容量/被支持的编解码器来识别网关28的地址(IP2)。
呼叫控制服务器38与移动站22和网关控制器40(控制被识别的媒体网关28)使用被采用的呼叫信令协议专用的消息对话以建立媒体路径并且，作为结果，媒体路径将包括选出的网关28并且，端口号码端口1和端口2将被确定。
第二种呼叫建立情况涉及远程地与PSTN/ISDN网络互通，如图5表示。在这种情况下，引入第二个网关28和其自身的呼叫控制服务器(CC)39。
在建立呼叫过程中(包括呼叫路由)，需获取以下信息(a)移动站22的网际协议地址IP3；(b)本地RTP-RTP媒体网关32的网际协议地址IP4；(c)远程网关28的网际协议地址IP5；(d)在移动站22处的下行媒体数据流的UDP端口号码，端口3；(e)在网关32处的上行媒体数据流的UDP端口号码，端口4；(f)在远程网关28处的上行媒体数据流的UDP端口号码，端口5；和(g)从网络26到第一或本地网关32的下行媒体数据流的UDP端口号码，端口6。
对于移动站22产生的呼叫，以下高层和通用的过程将被执行。
移动站22初始化一个向CC(呼叫控制)服务器38的呼叫请求包括被叫方号码和自己的IP地址(IP3)。
接着，呼叫控制服务器38分析被叫方号码来判断是否需要在本地和PSTN网络26互通。如果不需要，本地网关32(其地址是IP4)被本地呼叫控制服务器38识别。
本地呼叫控制服务器38与另一台(远程)呼叫控制服务器39联系，后者识别远程网关28及其IP地址，IP5。
本地呼叫控制服务器38与(工作)站22和媒体网关控制器40(控制着本地网关32)使用被采用的呼叫信令协议专用的消息对话并且，作为结果，媒体路径会包括本地网关32并且端口号码端口3和端口4会被确定。
本地呼叫控制服务器38与远程呼叫控制服务器39使用被采用的呼叫信令协议专用的消息对话并且，作为结果，端口号码端口5和端口6将被确定。
对于移动站22中止的呼叫，以下高层和通用的过程将被执行
包括被叫方号码的呼叫请求经过一个IP连接从远程呼叫控制服务器39到达本地呼叫控制服务器38。
本地呼叫控制服务器38分析被叫方号码将其映射到移动站IP地址上(IP3)。
本地呼叫控制服务器38根据如负载均衡/容量/被支持的编解码器来识别本地网关地址IP4。
本地呼叫控制服务器38与远程呼叫控制服务器39使用被采用的呼叫信令协议专用的消息对话，作为结果，远程网关28的IP地址IP5，端口号码端口5和端口6将被确定。
本地呼叫控制服务器38与移动站22和媒体网关控制器40(控制着本地网关32)使用被采用的呼叫信令协议专用的消息对话，作为结果，媒体路径将包括本地网关32，并且，端口号码，端口3和端口4将被确定。
在以上呼叫建立过程之后，呼叫的路由(媒体路径)将被确定(反映在各个网关的IP地址和端口号码上)。然后，(本地)呼叫控制服务器38通知GGSN36和SGSN34关于媒体流的这些细节(传输地址)，GGSN36和SGSN34然后指示RNC24和本地网关28，这二者参与直接经过RNC24和本地媒体网关32间的PLMN IP CN(核心网络)20的数据流传输。
如以上所述，VoIP媒体现在可以在媒体网关和RNC24之间直接经过PLMN IP核心20传输，不必通过SGSN34和GGSN36。这种安排的优势在于，媒体流不得不经过的(网络)元素的数量减少了，并且，在媒体网关和RNC24之间的媒体传输可以在更短的协议栈上进行，于是使得协议的管理开销减少。
为了优化数据流的传输，现在对两个独立的方案现叙述如下第一个方案涉及基于GPRS通道协议识别(GTP TID)的数据流识别，操作如下在收到建立的VoIP数据流路径(传输地址)以后，SGSN34识别两种与已建立的VoIP对话的上行与下行数据流路径相关的TID(GTP通道标识)。然后SGSN34可以控制RNC24和(本地)MGW(通过媒体网关控制器)来处理媒体数据流，尤其是用以下描述的优化的方法。
对于上行数据流处理，SGSN34将VoIP会话的上行数据流通道标识GTP TID通知RNC24。RNC24得到这个TID，然后可以处理从与该TID相关的特定RAB到达的数据流。对于该RAB的数据流处理如下。(如图6中示意)。
VoIP包50正常情况下从移动端22经过节点B到达RNC。对于每一个包，RNC24剥去L1和L2报头，得到用户级的IP包。该用户级的IP包将使用正常的IP路由方案被路由到本地MGW28。(作为结果，在Gx接口的L1和L2报头将被使用。)下行数据流处理需要在本地媒体网关和RNC24进行。在媒体网关的数据流处理中，SGSN34经过GGSN36指示本地网关采取以下动作如果本地媒体网关是一个TDM-RTP MGW，在TDM干线和(IP1，port1)之间的连接需要被转接到(IPRNC,port-x)，如图7a所示。端口号码port-x由本地MGW来确定，或用其他任何手段确定，只要没有使用上的冲突。
如果本地媒体网关是一个RTP-RTP MGW，进入MGW的RTP流和(IP1,port1)之间的连接需要被转接到(IPRNC,port-x)，如图7b所示。端口号码port-x由本地MGW确定或用其他任何手段确定，只要没有使用上的冲突。
SGSN34然后向本地MGW通知TID，该TID是VoIP会话的下行数据流的通道标识。本地MGW然后将这个TID插入这个连接的每个下行实时传输协议(RTP)包。TID(4个字节)可以作为扩展的RTP报头字段插入或使用已经存在的RTP报头字段。经扩展或重新使用的报头后的RTP记为RTP+。
在RNC24，对下行数据流作如下处理(如图8所示)SGSN34向RNC24通知TID和目的地传输地址(IP,port1)，该TID是VoIP会话的下行数据流的通道标识。RNC24保留这一映射以便以后使用。
对于来自本地媒体网关的每一个RTP+/UDP/IP包，被网关插入的TID被检查并且被映射到目的地传输地址(IP1,port1)。然后，TID字段被清除或设定一个合适的值，如果RTP被重新使用(于是原始的RTP包被恢复)。用户数据报协议(UDP)目的地端口号码被端口1替换，并且IP目的地地址被设定为IP1。新的RTP/UDP/IP包被放到和TID相关的RAB中。
第二个方案涉及基于端口号码的(数据)流识别，操作如下在得知已建立的VoIP数据流路径(传输地址)以后，SGSN34可以控制RNC24和本地媒体网关(通过网关控制器)来处理媒体数据流，特别是用优化的方法。上行数据流处理完全和第一种方案(使用TID进行(数据)流识别)相同，但下行处理是不同的。
下行数据流处理需要在本地网关(MGW)和RNC24处理，其实施方法如下在本地媒体网关处理时，SGSN34经过GGSN36指示本地网关如下如果本地媒体网关是一个TDM-RTP MGW，在TDM干线和(IP1,port1)之间的连接需要被转接到(IPRNC,port-x)，如图7(a)所示。端口号码port-x由SGSN34提供。
如果本地媒体网关是一个RTP-RTP MGW，在进入媒体网关的的RTP流和(IP1,port1)之间的连接需要被转接到(IPRNC,port-x)，如图7b所示。端口号port-x由SGSN34或GGSN36提供。
在RNC24，对下行数据流进行如下处理(如图9所示)SGSN34向RNC24提供以下信息VoIP会话的下行数据流通道标识，TID，目的地传输地址(IP1,port1)和由SGSN34分配的用于该VoIP会话的端口号码port-x。RNC24保留这一信息以便以后使用。
对于从本地媒体网关来的每一个RTP/UDP/IP包，UDP端口号码(port-x)被检查并且被映射到目的地传输地址(IP1,port1)。UDP目的地端口号码被端口1替换，并且IP目的地地址被设为IP1。然后新的RTP/UDP/IP包被放到和TID相关的RAB中。
现有的支持在通用移动电话系统(UMTS)中的VoIP的体系结构是在UMTS PS域上覆盖VoIP业务域(见图10)。VoIP业务域包括若干个组成部分，包括CSCF(呼叫状态控制功能)/信令网关。
CSCF提供呼叫控制功能性和补充特性(呼叫转移，呼叫等待和多路呼叫)。
CSCF提供的功能包括寻址翻译，许可控制，如允许完成呼叫和设定带宽限制，网关和呼叫信令的管理和控制，呼叫管理，报告和日志。
信令网关提供信令互通和到PSTN/ISDN网络的接口。
媒体网关将提供多种服务，包括协议和媒体翻译。这一实体将执行双向同步/异步转换(TDM到包)和信令互通功能，包括控制(SS7)接口/连接管理。
正如此前说明书所阐述与附图所示意的，可以在元素的组合与安排中进行一些变化，可以理解的是，可以在不背离本发明的精神与范围的情况下，在所公开的实施方案中进行改变，并且在随后的权利要求中作了定义。
权利要求
1．一个用于在一个移动站和一个目的地站之间进行上行和下行传输的实时数据传输系统，在上行传输中的该移动站，产生一个包括其自身标识和目的地标识的报头，并将该报头添加到有效载荷数据流中，以随附数据流中的有效载荷；一个无线网络控制器，一旦收到数据流，将一个从呼叫控制系统获得的通道标识添加到报头中以识别数据流，然后引导数据流直接到达媒体网关；在下行传输中的媒体网关，接收到包括含有从服务通用分组无线系统支持节点(SGSN)获得的移动站标识和移动站输入端口标识的报头的数据流；媒体网关，用于将报头中的移动站标识和输入端口标识替换为都是从呼叫控制系统中获得的无线网络控制器的地址、输入端口标识和用以识别数据流的通道标识，并且然后引导数据流直接到无线网络控制器；无线网络控制器，用于将报头中的无线网络控制器地址替换成为都是从呼叫控制系统经过SGSN获得的移动站标识地址和输入端口标识，并且其响应接收到的用以识别数据流的通道标识数据，然后引导数据流到达相关的无线承载通路中，以将其与移动站连接。
2．一种在网络中的实时数据传输方法，该网络包括一个移动站，一个无线网络控制器，一个媒体网关，一个目的地站和一个呼叫控制系统并且其中在移动站和目的地站之间的包括报头部分和载荷部分的数据流的通行由报头部分的内容来管理，该方法包括在从移动站到目的地站之间的上行传输中，向从移动站向无线网络控制器传输的数据流的报头部分添加两个(工作)站的标识的步骤；向流经无线网络控制器的数据流的报头添加从呼叫控制系统获得的通道标识的步骤；从无线网络控制器向媒体网关转发数据流的步骤；以及在从目的地站到移动站的下行传输中，向流经目的地站的数据流报头添加都是从呼叫控制系统中获得的移动站标识和端口标识的步骤；当数据流经过媒体网关时，将数据流报头中的移动站标识和端口标识替换为都是从呼叫控制系统中获得的无线网络控制器地址、数据流的输入端口标识和通道标识的步骤；向无线网络控制器转发数据流的步骤；当数据流经过无线网络控制器时，将数据流报头中的无线网络控制器地址和端口标识替换为都是从呼叫控制系统中通过SGSN获得的移动系统地址和输入端口的步骤；以及，引导数据流到达移动端的步骤。
3．依据权利要求2的方法，包括一个步骤引发无线网络控制器响应从呼叫控制系统获得的通道标识数据以识别收到的数据流并且引导其沿相关的无线承载通路连接到移动站。
4．一种在网络中的实时数据传输方法，该网络包括移动站，无线网络控制器，媒体网关，目的地站和呼叫控制系统，并且其中在移动站和目的地站之间的包括报头部分和载荷部分的数据流的通行需由报头部分的内容来管理，该方法包括一个步骤，当其从网络的一个位置流向另一个位置时，至少将报头部分中一些与地址相关的内容替换成与内部地址相关的内容，以减少通过网络的数据流路径和报头部分相对载荷部分的大小比例。
全文摘要
一种在网络中使用的实时数据传输方法,该方法中,除通常的GPRS专用网关之外,还提供一种实时媒体网关,来允许访问互联网骨干网。该方法包括在实时数据流流经网络时,对其报头部分进行改动,以使其能够直接流向实时网关而不经过GRPS专用网关。这就保证了数据流经过一条更直接的路由并且缩短了在过程中数据流所使用的报头。
文档编号H04L29/06GK1325244SQ0111777
公开日2001年12月5日 申请日期2001年5月17日 优先权日2000年5月19日
发明者劳尼斯·克里亚拉斯, 苏迪普·库马尔·帕拉特, 哈特夫·亚米尼, 杨劲 申请人:朗迅科技公司