CN105407108B - 用于传输分组的方法和节点 - Google Patents

Abstract

本发明的名称为用于传输分组的方法和节点。本发明提供一种在IP网络的节点（11、12、13、21、22、23）之间传输IP分组的方法，包括在第一网络节点（11）处接收分组和将接收到的分组分成多个流，其中每个流的分组共享公共的IP首部。合并多个分组以形成合并的分组，以及将合并的分组发送到第二网络节点。

Description

用于传输分组的方法和节点

本申请是申请号为200780004503.4、申请日为2007年2月6日、发明名称为“传输分组”的发明专利申请的分案申请。

技术领域

本发明涉及传输分组的方法，尤其涉及在一个网络节点和另一个网络节点之间传输分组。

背景技术

图1是第一网络（网络1）中的设备11、12、13与第二网络（网络2）中的设备21、22、23进行通信的示意性图解。例如，网络1中的设备11可以正在向网络2中的设备21和23发送分组，而网络1中的设备12可以正在向网络2中的设备22发送分组。由网络1中的设备11、12、13所发送的分组最初被路由到网络1中的主机（host）1，然后通过通信链路（例如IP主干线（backbone））被发送到网络2中的主机2。网络2中的主机2根据分组中所指定的目的地将接收到的分组路由到设备21、设备22或设备23。从网络1传到网络2的（或者反之亦然）所有分组均通过链路3进行传递。

分组通常包括首部和有效载荷。首部包含分组路由的细节，例如分组的目的地以及分组的源。因此，例如由设备11所产生的且目的地为设备21的分组将具有首部，该首部特别地标识要被送到设备21的分组的目的地。当在主机1处接收到分组时，主机1将从分组的首部读取目的地，将把目的地识别为在网络2中，并将把分组通过链路3转发到网络2的主机2。当在网络2的主机2处接收到分组时，主机2将从分组的首部读取目的地，并将把目的地识别为设备21。

设备（或更一般地，“网络节点”）的地址通常是IP（网际协议）地址。

特定设备可以服务多个不同应用，例如电子邮件系统、web（网络）浏览器等。因而分组的首部通常不仅标识目的地设备，而且还标识与分组内容相关的特定应用。特定应用通常通过“UDP端口号”来标识。沿链路3传送的分组的首部因而通常将包含IP地址字段和UDP端口字段。

依赖于与分组内容相关的应用，分组的首部可以包含另外的字段，例如“实时协议”（RTP）字段。RTP字段涉及诸如VoIP数据之类的实时数据的成帧（framing）和处理。因此，沿链路3传送的VoIP分组的首部因而除IP地址字段和UDP地址字段以外通常还将包含RTP字段。

当前在通过因特网传送电话呼叫或者“VoIP”（网际协议上的语音）上作出了很多努力。VoIP的一个主要问题是由于分组首部的IP/UDP/RTP成帧而造成的开销量过大。利用IPv6（网际协议版本6地址机制），具有IP、UDP和RTP字段的首部的总体长度为60字节，但是分组的实际有效载荷可能低至15-20字节，这意味着带宽的75％以上可能被分组的首部消耗。

已经提出多个首部压缩方案来克服这个问题，但是它们被设计用于点到点连接，而不是用于如图1中的通过公共链路传送多个不同分组流的情况。这些首部压缩方案实际上除在无线电接口中之外都是无用的。而且，如果首部压缩被引入固定网络的话，它将具有严格的压缩要求，在公共商用IP网络中将不可能遵循该要求。因而需要用于降低在依照3GPP规范的核心网中的VoIP的带宽要求的其他手段。

发明内容

本发明的第一方面提供一种在IP网络节点之间传输IP分组的方法，所述方法包括：

在第一网络节点处接收分组；

将接收到的分组分成多个流，其中每个流的分组共享公共的IP首部；

合并（merge）多个分组以形成合并的分组；以及

将合并的分组发送到第二网络节点。

在本发明的方法中，两个或更多个分组被合并（或被“复用（multiplex）”）。用于形成合并分组的各组成分组（component packet）的有效载荷，在公共首部下在合并分组中被发送。与单个分组的首部相比，合并分组的首部占用了合并分组的长度的较低比例。也就是，如果两个分组（作为举例）被合并，则合并分组的首部的长度将小于两个组成分组的首部的长度之和。

在实时业务的情况下，合并的分组优选地包括来自任何流的不超过一个分组。然而，在非实时业务的情况下，原则上一个流可以为合并的分组贡献两个或更多个分组。

通过通信网络发送合并的分组不需要更改网络。

当合并的分组在第二网路节点处被接收到时，它将被分成其组成分组。

本发明的方法可以被应用于，例如在3GPP UMTS网络中通过媒体网关（MGW）之间的Nb接口或者RNC与MGW之间的Iu接口、通过IP传输的语音业务。然而，基本上能够针对指向相同IP地址的所有分组执行合并（或复用）分组，并且本发明能够被用于所有类型的UDP业务。本发明的复用方法特别地可以被用于RTP分组（虽然它可能不适用于RTCP（实时控制协议），所述RTCP可以通过IP/UDP分组被继续正常地传输）。复用方法独立于IP之下的协议，并且它能够被用于例如MPLS（多协议标签交换）使能（enabled）网络以及任何其他基于IP的网络。

附图说明

现在将参考附图通过说明性示例的方式来描述本发明的优选实施例，其中：

图1是通信系统的示意性图解；

图2是本发明方法的方块流程图；

图3（a）和3（b）是在本发明方法中使用的分组的示意性图解；

图3（c）是复用首部的示意性视图；

图3（d）是在本发明方法中使用的另一分组的示意性图解；

图4是合并的分组的构成的示意性图解；

图5是复用首部的示意性视图；并且

图6是被压缩的RTP首部的示意性视图。

具体实施方式

本发明将参考图1中所示的网络通过举例的方式进行描述。将要假设的是，作为例子，网络1中的设备所控制的各种应用正在向网络2设备发送分组，但是本发明可以被同样好地应用于网络2中的设备向网络1发送分组的情况。

在一个实施例中，网络1中的一个设备，例如设备11，是去往网络2中的设备的两个或更多个分组流的源。假设这些流具有相同的DiffServ（区分服务）等级。这实际上要求一个流的业务非常类似于其他流的业务，并且在许多情况下两个流很可能与相同应用相关。

进一步假设，已经在设备之间对地址进行了协商以使得例如从设备11到设备21的分组以设备11的IP地址作为源地址并且以设备21的IP地址作为目的地地址。在这个示例中，从设备11到设备21的流中的分组仅能够与从设备11到设备21的一个或多个其他流进行合并，并且对这些流的复用是在设备11中执行的。（类似地，对从设备12到设备21的流的合并将在设备12中被执行，对从设备21到设备11的流的合并将在设备21中被执行，诸如此类。）主机1和2在这个示例中仅被用作路由器。

在这个示例中，最初在设备11处接收分组（图2中的步骤1）。在这个示例中，假设尤其包括去往设备21的、并具有相同DiffServ等级的两个或更多个分组流（并且还可以包括具有网络2中的不同目的地设备和/或与另一个DiffServ等级相关的另外的分组流）。去往设备21的分组将具有尤其包含有设备21的IP地址的首部，而去往设备22[23]的分组将具有尤其包含设备22[23]的IP地址的首部。

接下来，在设备11处接收到的分组被分类成两个或更多个流，每个流对应于单个IP地址（图2的步骤2）。在这个示例中，该分类步骤将引起从设备11去往设备21的、与相同DiffServ等级相关的两个（或更多个）分组流，并且也可能引起具有网络2中的不同目的地设备的和/或与另一个DiffServ等级相关的另外的分组流。

优选地，在步骤2创建的每个流仅包含一种类型的分组（更正式地，每个流优选地仅包含一种DiffServ等级的分组）。因而在其中网络1中的设备11所控制的两个（或更多个）不同应用（例如VoIP和电子邮件）正在向网络2中的设备21发送分组的示例中，例如，到达设备11的分组优选地将被分类成流以使得VoIP和电子邮件分组彼此不被包含在相同的流中。

接下来，多个分组被选择（图2的步骤3）并被合并以形成合并的分组（图2中的步骤4）。被选择进行合并的分组彼此具有相同的IP地址，例如所有的分组都去往设备21，并且因而以设备21的IP地址作为它们的目的地地址。合并的分组在其首部中包含单个IP字段，这是因为合并的分组的所有组成分组都去往相同的IP地址。合并的分组还包含多个有效载荷字段，对于组成分组中的每一个都有一个有效载荷字段。

在实时业务的情况下，合并的分组优选地包含来自任何流的不超过一个分组。在这种情况下，选择步骤将包括从每个流中选择一个分组（或者，更一般地，从非空的每个流中选择一个分组）。如果流包含两个或更多个分组，则被选择的分组优选地是在流中等待的时间最长的分组。

然而在非实时业务中，原则上合并的分组可以包含来自一个流的两个或更多个分组。

在优选实施例中，合并的分组仅包含相同类型的分组（也就是，包含仅一个DiffServ等级的分组）。在这个实施例中，合并的分组可以通过把来自于去往设备21的一个（例如）VoIP分组流的分组与来自于去往设备21的另一个VoIP分组流的分组进行合并而形成。类似地，合并的分组可以通过把来自于去往设备21的一个（例如）电子邮件分组流的分组与来自于去往设备21的另一个电子邮件分组流的分组进行合并而形成，通过把来自于去往设备22的一个（例如）VoIP分组流的分组与来自于去往设备22的另一个VoIP分组流的分组进行合并而形成，等等。

接下来，合并的分组被传送至通过合并的分组的首部中的IP地址字段指示的目的地（图2的步骤5）。在这个示例中，通过把来自于去往设备21的两个VoIP分组流的分组进行合并而形成的合并分组被传送到设备21，通过把来自于去往设备22的两个分组流的分组进行合并而形成的合并分组被传送到设备22，等等。

当在由合并的分组的首部中的IP地址字段所指示的目的地处接收到合并的分组时，将合并的分组分成其组成分组。

在本发明的优选实施例中，合并的分组的首部包含指示，即分组是合并的分组。在特定优选实施例中，这是通过在合并的分组的首部中包括用于指示分组是合并的分组的UDP端口号来实现的。该UDP端口号对应于为合并的分组而预留（reserve）的目的地设备处的UDP端口－被分配作为所有合并的分组被发送到的“复用端口”的一个UDP端口。因为该端口是为合并的分组预留的，所以它不允许被分配给任何单独连接，并且该端口因而将仅接收合并的分组。目的地设备于是知道何时到达的分组是合并的分组。在这个实施例中，当合并的分组在由合并的分组的首部中的IP地址字段所指示的目的地设备处被接收到时，合并的分组将被送往为合并的分组预留的目的地设备的UDP端口。

通过把UDP端口号包含在合并的分组的首部中，不需要附加的映射表。

为合并的分组预留的UDP端口被建议是端口2002。

图3（a）是在本发明的方法中使用的合并的分组14的示意性图解。通常，分组14具有首部4和有效载荷5。首部包含IP地址字段6，其包括合并的分组的目的地设备的IP地址。如上所解释的，首部4还可以包含UDP字段7，其标识在目的地设备处为合并的分组预留的UDP端口的端口号。可替换地，首部可以包含另一个字段，其标识分组是合并的分组。

对于非实时业务而言，所有被用于形成合并的分组的组成分组可能具有相同的UDP端口号，并且在这种情况下，首部4的UDP字段7可以包含原始UDP端口号而不是特别分配给合并的分组的UDP端口号。然而，这将要求所有UDP端口都必须能够检测和处理合并的分组。因而，实际上，优选地具有被特别分配来处理合并的分组的、不同于传统应用UDP端口的一个UDP端口。如果一个UDP端口被分配来处理合并的分组，则所有其他端口可以正常地接收分组，并且不受本发明的分组复用的影响。

合并的分组14的有效载荷5包含多个复用的分组字段5a、5b，每个组成分组对应于一个复用的分组字段。图3（a）示出了通过合并两个组成分组而形成的合并的分组，并且合并的分组因而具有两个复用的分组字段；然而，本发明不限于此，多于两个的分组可以被合并以形成合并的分组。

分组14的首部4是“公共首部”，这是因为首部4中的信息为所有复用的分组字段5a、5b所共用。

每个复用的分组字段5a、5b包含复用首部（“MUX首部”）8a、8b和有效载荷字段9a、9b。复用首部在图3（c）中被示出。复用首部8a、8b包含复用ID字段15，其可以包含整个UDP端口信息。复用ID字段15用于标识不同的连接。如果在不使用本发明的复用的情况下，按照常规方式发送分组的话，则它的值与UDP目的地端口相同的－也就是，复用ID字段15是原始的组成分组的UDP端口号。

复用首部8a、8b优选地还包含有效载荷长度指示器字段16。提供该字段是因为复用ID字段15不指示下一个复用分组字段何时开始。因而，有效载荷长度指示器字段16指示每个复用分组字段（首部8a、8b和有效载荷9a、9b）的字节数量以使得下一个复用分组字段的开始能够被确定。

在一个实施例中，复用ID字段是16比特（2字节）字段，有效载荷长度指示器字段是8比特（1字节）（给定有效载荷长度指示器字段之后字段的最大长度为256字节）。因而，在这个实施例中，MUX首部字段总体上为3字节字段。

每个复用的分组字段5a、5b是如下形成的：

||复用ID/UDP端口（2字节）||长度指示器（1字节）||有效载荷（1－256）字节||

除了图3（a）中所示的那些字段以外，合并的分组14的首部4还可以包含其他字段。作为示例，合并的分组的首部4还可以包含RTP首部字段，其包含合并的分组的RTP信息。图3（b）是还包含RTP首部字段10的合并的分组14’的示意性图解。

在一些应用中，例如3GPP网络中的语音业务，RTP信息是必需的。图3（b）中所示的分组结构可以被用于其中合并的分组的所有组成分组共享公共IP/UDP/RTP首部的情况，并且可以被用于其中不需要每个分组的单独RTP信息的情况。然而，在一些应用中，需要每个分组的单独RTP信息，而在这种情况下，图3（b）的分组结构是不适用的。

图3（d）示出了另外的分组结构，其中每个复用的分组字段5a、5b的首部8a、8b包含RTP信息。RTP信息被提供在MUX首部8a、8b内的RTP字段17a、17b中。在这个示例中，RTP字段17a、17b具有12字节的长度。

图4图示了图3（d）的合并的分组的信息。合并的分组的公共首部4包含IP地址字段6和UDP首部字段7。UDP首部字段包含用于标识分组是合并的分组的UDP端口号（例如2002）。每个复用的分组字段5a、5b具有MUX首部，其包含与组成分组的UDP端口号相对应的UDP端口号，和有效载荷长度指示器字段（未示出）。每个复用的分组字段5a、5b还具有RTP首部字段17a、17b，和有效载荷字段9a、9b（在这个示例中，有效载荷被示为NbUP帧）。有效载荷长度指示器字段之后的字段－也就是，RTP首部字段17a、17b以及有效载荷字段9a、9b－具有最大256字节的总长度（在1个字节有效载荷长度指示器字段的示例中）。

优选的是，分组在已经被放入其相应的流之后很快在图2的步骤3中被选择用于进行合并，以避免将额外的延迟引入网络。在一个实施例中，合并步骤是通过选择在给定时间帧内到达网络节点的分组（和在时间帧的结束后很快形成合并的分组）来实施的。时间帧的持续时间应当足够大以确保分组可能在时间帧内到达若干个流（通过选择在给定时间帧内到达网络节点的分组来执行合并步骤有效地限制了合并成为合并分组的组成分组的数量），以确保实现带宽的有用节省，但是不应当大到引入明显的延迟和复用抖动。时间帧大约1 ms（毫秒）的持续时间在很多应用中是合适的－该定制（order）的时间帧应当长到足以将多个分组集合成合并的分组，但应当短到足以保持延迟和复用抖动很低。

对于时间不敏感的应用，或者如果用户准备接受更大延迟/抖动来获得更多带宽节省，则能够使用更长的时间帧。然而，1 ms的持续时间是实时业务的优选值。

以不把明显延迟引入网络的要求为条件，基本上不对能够被复用到合并分组的分组数量进行限制。IP数据报具有65535字节的最大长度，并且以太网帧具有1518字节的最大长度，这意味着实际上是以太网帧大小限制了能够被复用成一个合并分组的分组数量。

除了减少带宽之外，本发明进一步的益处是网络中分组的数量也被减少。当仅两个分组在同一时间被复用成一个合并分组的时候，网络中的分组数量立即被减少到其原有值的50％。此外，好几十个分组可以被复用成一个合并分组，这意味着网络中的分组数量可以被减少到没有使用复用时网络中分组数量的极小比例。（例如如果10个分组在同一时间被复用成一个合并分组，则网络中的分组数量被减少到其原有值的10％）。网络中分组数量的这种减少在针对每个分组处理业务的网络路由器中带来巨大的处理节省。这还将对语音质量具有正面影响，在VoIP的情况下，因为更少的分组在网络中，因而在传输期间可能丢失的分组就更少。如果分组因为某种原因而被丢失的话，影响将扩散到多个连接，对一个连接的实际影响实际上是不大的。

表1示出了能够通过本发明获得的带宽减少的示例。表1示出了四种不同情形的结果：针对IPv4和IPv6这二者的PoS，以及针对IPv4和IPv6这二者的以太网。在PoS示例中，假设网络使用双MPLS成帧（VPN和业务类型区别），而在以太网示例中假设使用VLAN标签。数字是针对具有60％活动因子（activity factor）的AMR12.2分组而言的。

对于四种情况种的每一种，表1示出了：没有使用复用的带宽（BW）、其中2个分组被复用成合并分组的带宽以及其中10个分组被复用成合并分组的带宽。结果假设合并的分组具有如3（d）所示的形式，具有公共的IP/UDP首部并且在每个MUX首部中具有RTP信息。

表1

	PoS，IPv4	PoS，IPv6	Eth，IPv4	Eth，IPv6
					BW 参考	22,88 kbps	28,08	29,90	35,10
BW，2 pkts	18,07 kbps	20,67	21,58	24,18
					减少	21%	26%	28%	31%
BW，10 pkts	13,60 kbps	14,12	14,30	14,82
					减少	41%	50%	52%	58%

（对于2个或10个组成分组被合并成一个分组的情况所示的带宽是每个组成分组的有效带宽－即在PoS、IPv4情况下，具有两个组成分组的合并分组将具有36.14 kbps的带宽）。

在本发明的进一步优选实施例中，为了实现更好的带宽节省，RTP首部字段被压缩。这是可能的，因为RTP首部包含很多在RTP会话期间保持不变的静态字段，这样在许多情况下RTP首部可以被压缩。RTP压缩对于把分组复用成合并后分组而言是额外的，这样在不使用RTP压缩的情况下总是可以返回到单纯的复用。

在特定优选实施例中，使用RTP首部压缩的合并分组被发送到为具有RTP首部压缩的合并分组预留的UDP端口。因而优选地，为具有RTP首部压缩的合并分组预留一个UDP端口，并且为不具有RTP首部压缩的合并分组预留另一个UDP端口。

为具有RTP首部压缩的合并分组而预留的UDP端口被建议是端口2004。以与端口2002相同方式使用的该端口被用于不具有RTP首部压缩的合并分组。

在压缩中，首先总是存在着把完整首部传送到接收端的初始化阶段。完整首部被存储并且它被用于解压缩。在初始化阶段之后，仅压缩的首部被发送，除非首部中的信息改变太多，在这种情况下有必要发送完整的首部。可替换地，为了确认完整的首部已经被接收到并且初始化已完成，首部被压缩的分组的发送可以不在第一个分组之后立即启动。例如，前十个分组可以是没有被压缩的分组，后续的分组是被压缩的分组，并且如果首部必须被更新的话，则相同的过程（即将前十个分组作为没有被压缩的分组来发送）可以被重复。

复用的分组字段的首部8a、8b的一种可能结构在图5中被示出。图4的复用首部包括类型字段18，其具有1比特长度。类型字段18具有两种可能状态，0用于指示不具有RTP首部压缩的合并分组，而1用于指示具有RTP首部压缩的合并分组。

图5的首部8a还包括复用ID字段15和有效载荷长度指示器字段16。复用ID字段15具有15比特的长度，用于标识不同的连接。复用ID字段15的值与没有被复用的分组的UDP目的地端口除以2所得结果相同的（仅偶数端口被用于RTP会话）。有效载荷长度指示器字段16具有8比特的长度，并以字节为单位来给出复用的RTP分组的长度（首部＋有效载荷）。

图6图示了被压缩的RTP首部17’的一种可能格式。图6的RTP首部压缩机制是一个示例，其他机制也可以被使用。

RTP首部包含两个字段：序列号和时间戳，这两个字段在连接期间改变并需要在每个分组内被转移。然而，这两个字段都以明确的（well defined）方式改变。每个被发送的分组都有序列号（步长为1）用以指示任何分组丢失，时间戳描述连续分组之间的时间差。

图6的被压缩的RTP首部17’包括长度为3比特的序列号（SN）字段19。序列号字段19随着原始序列号而改变，但是仅有8个状态，这是足够的，因为分组通常在非常低BER的网络中被发送。如果序列号字段不够，则应该使用完整的RTP首部。

图6的被压缩的RTP首部17’还包括长度为5比特的时间戳（TS）字段20。时间戳字段20基本上随着原始时间戳而改变，但是时间戳字段的一个步长所表示的实际时间差取决于有效载荷类型，这是因为根据初始化消息该类型是已知的。当转换到时间戳字段中的原始步长时，被压缩的RTP首部17’中的时间戳字段20的一个步长表示PCM语音的80个步长（5 ms×16 kHz = 80）和AMR编码语音的320个步长（20 ms×16 kHz = 320）。如果时间戳字段由于某种原因是不足的，则应该使用完整的RTP首部。

被压缩的RTP首部17’可以代替合并分组中的完整（即，没有被压缩的）RTP首部字段而被使用，例如代替图3（d）的合并分组的完整RTP首部字段17a、17b。

可替换地，图6的被压缩的RTP首部中的序列号SN字段可以是8比特，而时间戳TS字段可以是16比特。在这种情况下，根据请求注释3550，每个字段的长度为其在没有被压缩的首部中所具有的长度的一半。TS字段随着原始时间戳而改变（RFC3550），但是长度是原始的一半，这将得到具有16 kHz时钟参考的、4秒的模（modulo）。

表2示出了当采用RTP压缩时通过本发明能够获得的带宽减少的示例。表2示出了在如表1中所作的相同假设下，在表1中所考虑的四种情况的结果。

表2

	PoS，IPv4	PoS，IPv6	Eth，IPv4	Eth，IPv6
					BW 参考	22,88 kbps	28,08	29,90	35,10
BW，2 pkts	15,73 kbps	18,33	19,24	21,84
					减少	31%	35%	36%	38%
BW，10pkts	11,26 kbps	11,78	11,96	12,48
					减少	51%	58%	60%	64%

应当注意的是，不是所有的设备都能够支持复用以形成合并的分组，和/或还支持RTP首部压缩。因而，在发送分组之前，对于发送节点和接收节点而言必要的是同意使用复用来形成合并的分组，而且也同意是否使用RTP首部压缩。

Nb和Iu接口这二者中的承载（bearer）初始化阶段包括用于被使用的支持模式的命令（mandatory）消息，例如用于语音业务。在初始化时使用Nb/Iu UP PDU类型14，并且这些消息包括能被用于任何附加功能的备用（spare）扩展字段（在初始化和确认帧这两者中）。所建议的是，这些字段被用于检测是否本发明的复用方法是可适用的。（Iu接口中的透明模式因为其没有初始化阶段而将不会支持复用，但是该模式不被实时应用所使用）。

当支持复用的始发节点（例如，MGW（媒体网关）或RNC）发送初始化消息时，它将在初始化消息中指示其想要使用复用，例如，通过将第一比特设为1或者在初始化帧的备用扩展字段中使用特定序列。接收节点从初始化消息中的该比特或序列中获知复用能够被使用。如果接收节点支持复用，则它将该比特或序列拷贝到用于指示的肯定确认消息的备用扩展字段，并将该确认消息传送到始发节点。这样向始发节点确认了能够使用复用。然而，如果接收节点不支持复用，则它仅忽略初始化消息中的备用扩展字段，并发送常规的确认－开始初始化的始发节点然后获知不使用复用。

因为节点可以支持复用但不支持RTP首部压缩，所以能够支持复用和RTP首部压缩这二者的始发节点所发送的初始化消息必须包含分别与复用及RTP首部压缩相关的指示。例如，如果初始化消息中的第一比特指示始发节点能够支持复用，那么始发节点另外能够支持RTP首部压缩的事实可以通过开始的两个比特（或通过不同序列）来指示。目的地节点现在能够以三种方式答复。目的地节点可以指示可以使用具有RTP首部压缩的复用，例如通过重复这些比特或序列。然而，目的地节点可以通过指示可以使用复用但不使用RTP首部压缩来进行答复（例如通过以一个指示正常复用的比特/序列来答复），或者它可以通过指示不可以使用复用来答复（例如，通过在没有任何复用指示的情况下进行答复）。

对于Nb接口，已经存在着承载控制的标准化协议，IP承载控制协议（IPBCP），并且这还可以被用于检测复用适用性。然而，IPBCP不能用于Iu接口，因而，当有必要确定复用是否可能的时候，作为更通常的解决方式UP初始化是更合适的初始化。通常，确定复用是否适用的步骤能够被视为迁移（migration）阶段功能，这在已知所有相关节点都支持复用的时候将被省去。在这种情况下，复用的分组可以总是根据UDP端口（例如，针对正常复用的分组的端口2002以及针对具有RTP首部压缩的复用分组的端口2004）来检测。

原则上，RTP首部压缩可以被应用于具有公共RTP首部的合并分组（如图3（b）中的），或者甚至应用于传统的未合并（unmerged）的分组。然而，在这些情况下，利用RTP首部压缩而节省的带宽大约将会是5-10%，这不可能证明RTP首部压缩会向连接处理增加的复杂度。

上述给出的示例中，假设已经在设备之间对地址进行了协商，以使得例如从设备11到21的分组以设备11的IP地址作为其源地址，并且以设备21的IP地址作为目的地地址。在这个示例中，仅从一个始发设备11、12、13到一个终止设备21、22、23的流可以被合并，并且合并发生在始发设备中。在这个示例中主机1和2仅被用作路由器。然而本发明并不限于此。

例如，可以是网络1和2具有某一其他内部路由机制，对于设备1x和设备2x之间的所有流，主机1和2之间的连接必须被独立地建立。（“设备1x”表示网络1中的设备11、12、13，“设备2x”表示网络2中的设备21、22、23）。这是在例如基于3GPP的网络中的情况，其中IP传输网络被用在主机1和2之间，并且网络1和2实际上是使用TDM或ATM来代替IP的无线电接入网络。然后主机1和2是处理媒体转换和协商的媒体网关，这样网络1能够被连接到网络2（因为先前示例中的直接通信是不可能的，这是由于其间的不同传输网络）。因为主机1和2之间的连接被独立地协商并独立于真实的源和目的地，所以从网络1到网络2的所有分组，在链路3处，都具有相同的IP源及目的地地址对，并且对于从网络1到网络2的分组而言它们全部能够在主机1中被合并（复用）（并且在从网络2到网络1的分组的情况下，能够在主机2中被复用）。

在这个可替换的示例中，到达主机1的分组（在从网络1传到网络2的分组的情况下）被分类成流，其中每个流优选地包括单个DiffServ等级的分组。然后通过把来自于两个或更多个流的分组进行合并来形成合并的分组，并且合并的分组被传送到主机2。合并的分组在主机2中被解合并，并且组成分组被传递到它们在网络2中的相应目的地。

第二示例特别地示出了机制的潜能，这是因为复用的获益与能够被复用的流的数量成正比，并且现在能够在其中业务负载通常是最高和最昂贵的链路处（即，独立地点之间的核心链路）执行合并。当在主机1处执行合并时，把来自于在设备11处始发并去往设备21的流的分组与来自于在网络1中的设备1x处始发并去往网络2中的设备2x的任何其他流的分组进行合并是可能的（服从优选地仅一个DiffServ等级的分组被合并这一附带条件）。

本发明的方法可以被应用于IMS分组。这将要求利用SIP的不同类型的初始化过程。

本发明的方法可以通过适当编程的处理器来执行。用于控制处理器执行本发明方法的程序可以被存储在任何适当的存储介质上，例如计算机盘、磁盘或光盘。

Claims (21)

1.一种在3GPP IP网络的节点之间传输IP分组的方法，所述方法包括：

在所述3GPP IP网络的第一网络节点处接收分组；

将接收到的分组分成多个流，其中每个流的分组共享公共的IP首部，所述公共的IP首部指示所述3GPP IP网络的第二网络节点为分组的目的地；

独立地协商第一网络节点和第二网络节点之间的连接，其中所述连接独立于真实的源和目的地；

在发送分组之前，在NB/Iu接口的承载初始化阶段中，在第一网络节点和第二网络节点之间同意能够使用分组复用；

合并来自于两个或更多个流的多个分组以形成合并的分组；以及

将合并的分组发送到第二网络节点。

2.如权利要求1所述的方法，其中流的分组包含相同类型的信息。

3.如权利要求2所述的方法，其中至少一个流的分组是VoIP分组。

4.如权利要求1、2或3所述的方法，其中合并来自于两个或更多个流的多个分组以形成合并的分组的步骤包括：从至少第一流中选择分组和从至少第二流中选择分组，并对所选择的分组进行合并以形成合并的分组。

5.如权利要求4所述的方法，当从属于权利要求2或3时，其中第一流的分组和第二流的分组包含相同类型的信息。

6.如权利要求1、2或3所述的方法，其中合并来自于两个或更多个流的多个分组以形成合并的分组的步骤包括：对在预定时间窗内在第一网络节点处接收到的分组进行合并。

7.如权利要求6所述的方法，其中时间窗具有1 ms的持续时间。

8.如权利要求1、2或3所述的方法，其中合并的分组包含公共首部以及两个或更多个复用的分组字段，每个复用的分组字段对应于合并的分组的相应组成分组。

9.如权利要求8所述的方法，包括另外的步骤：在合并的分组的公共首部中指示分组是合并的分组。

10.如权利要求9所述的方法，包括将UDP字段分配到合并的分组的公共首部，UDP字段指示合并的分组。

11.如权利要求10所述的方法，进一步包括分配所选择的UDP端口以仅处理合并的分组。

12.如权利要求8所述的方法，包括在公共首部中提供公共RTP信息。

13.如权利要求8所述的方法，包括在相应复用的分组字段中提供每个组成分组的RTP信息。

14.如权利要求13所述的方法，包括在相应复用的分组字段中提供每个组成分组的压缩的RTP信息。

15.如权利要求14所述的方法，包括在合并的分组中指示分组包含压缩的RTP信息。

16.如权利要求15所述的方法，其中每个复用的分组字段包含相应的首部，并且其中所述方法进一步包括在相应的首部中指示分组包含压缩的RTP信息。

17.如权利要求1、2或3所述的方法，包括另外的步骤：在第二网络节点处，将合并的分组分成其组成分组。

18.一种3GPP IP网络的节点，所述节点包括：

用于接收分组的装置；

用于将接收到的分组分成多个流的装置，其中每个流的分组共享公共的IP首部，所述公共的IP首部指示所述3GPP IP网络的第二网络节点为分组的目的地；

用于独立地协商第一网络节点和第二网络节点之间的连接的装置，其中所述连接独立于真实的源和目的地；

用于在发送分组之前，在NB/Iu接口的承载初始化阶段中，在第一网络节点和第二网络节点之间同意能够使用分组复用的装置；

用于合并来自于两个或更多个流的多个分组以形成合并的分组的装置；以及

用于将合并的分组发送到第二网络节点的装置。

19.如权利要求18所述的节点，适于把接收到的分组分成多个流以使得流的分组包含相同类型的信息。

20.如权利要求18或19所述的节点，适于通过从至少第一流中选择分组和从至少第二流中选择分组、并对所选择的分组进行合并以形成合并的分组。

21.如权利要求18或19所述的节点，其中第一流的分组和第二流的分组包含相同类型的信息。