CN101243674A - 在应用BICC“延迟反向承载建立”和失败避免的情况下经由3GPP Nb接口快速建立IP用户连接的方法和装置 - Google Patents

Abstract

在媒体网关O和媒体网关T之间建立IP用户数据传输连接，其中用户数据传输连接根据BICC“延迟反向承载建立”被建立。当从MGWT接收到IPBCP请求消息之后，MGWO向MGWT发送IPBCP接受消息并开始向MGWT发送用户数据传输连接内的数据。用户数据很可能在IPBCP接受消息之前到达MGWT。MGWT由从MGWO所接收到的用户传输连接IP包中重新得到源IP地址和端口号和当从MGWO接收到用户数据传输连接IP包时，MGWT使用所重新得到的IP地址和端口号作为目的地向MGWO发送(多个)第一用户数据传输连接IP包。

Description

在应用BICC“延迟反向承载建立”和失败避免的情况下经由3GPP Nb接口快速建立IP用户连接的方法和装置

在3GPP移动网络的“Cs域”中，以3GPP TS 29.415标准化的“Nb成帧协议”被用来传输用户数据。该Nb成帧协议也以频带内信令消息为特点，例如在任何用户数据之前需要被交换的初始化消息和初始化确认消息。对于所谓的呼叫控制信令，ITU-T标准化“承载无关呼叫控制(Bearer Independent Call Control)”(BICC)协议、ITU-T Q.1902.5被使用，如在3GPPTS 23.205中所描述的那样。

在使用IP协议用于在“Cs域”的核心网中经由“Nb”接口传输用户数据的情况中，被用于在“媒体网关”(MGW)或集成式“移动业务交换中心”(MSC)处发送和接收传输连接的IP地址和UDP端口号借助于“IP承载控制协议”(IPBCP)、ITU-T Q.1970被协商，如在3GPP TS 29.414中所说明的那样，其中所述集成式“移动业务交换中心”(MSC)在一个设备中连接MGW和“MSC服务器”的功能。

BICC协议为设置IP传输连接而提供不同的方法，其中所谓的“延迟反向承载建立(Delayed Backward Bearer Establishment)”是传输连接的延迟反向建立。在这种情况下，对于Nb成帧协议的初始化，以下问题仍然是未解决的。

MGW O在被叫、即被叫方的方向上朝向下一MGW T发送具有IP地址和UDP端口号的IBCP接受消息，其中MGW O已选择了所述IP地址和UDP端口号用于发送和接收用户连接。MGW O同时或者不久以后向MGW T发送Nb成帧协议(Nb Framing Protocol)的初始化消息。有必要的是，为了实现快速建立用户连接以防止MGW O把在某一阶段期间应答消息的缺乏认为是差错情况，MGW T立即利用初始化应答消息向MGW O对Nb成帧协议初始化消息作出应答。按照现有标准，MGW T必须发送初始化应答消息到MGW O的在IPBCP接受消息中所指示的IP地址和UDP端口号。

MGW O通过IP直接向MGW T发送Nb成帧协议的初始化消息。在另一方面，MSC-O发送IPBCP接受消息到MSC服务器O，从而对其进行控制。接下来，MSC服务器O通过BICC呼叫控制信令转发IPBCP消息到控制MGW T的MSC服务器T，所述MSC服务器T将消息传递到MGWT。因此，在这一情形中可能的是，Nb成帧协议的初始化消息MGW T显然在IPBCP接受信息之前到达其目的地。

有问题的是，在这种情形下MGW T的行为在标准中迄今不被认可。因此，MGW T可能忽略Nb成帧协议的仍未预料的初始化消息和/或假设差错情况和中断连接建立。MGW T也可能继续等待IPBCP接受信息，也即在发送初始化应答消息之前，这可能导致在MGW O中传输连接建立延迟和差错。

本发明的主题是以下进程：即在如上述描述的“延迟反向承载建立”情形的情况下允许MGW T立即向MGW O发送Nb成帧协议的初始化应答消息以避免在传输连接建立期间的差错和/或延迟。

到目前为止，前述问题还没有被认可并且没有对前述问题的被接受的解决方案。

发明内容

本发明的解决方案的典型情形如下所述：

·CN中的IP，BICC延迟反向呼叫建立；

·一旦本地和远程地址信息可用，则通过发起MGW开始UP初始化；但是同时瞬间本地地址信息被发送到对等体(peer)MGW＝＞在一方面UP Init和另一方面Notify.Ind(隧道信息上行)-＞APM-＞Mod.Rep(隧道信息下行)内的IPBCP接受消息之间消息竞赛。

·很大可能“UP Init”将较早到达并且由于远程地址在接收MGW中是未知的将被丢弃(drop)。

·在超时(500msec)后，“UP Init”将被发起MGW重新尝试，很可能成功。

这里提供的解决方案是当在接收之后立即在MGW处通过使用“UP Init”的源地址字段内的对等体IP地址/UDP端口确认“UP Init”。在此这简要地描述如下：

·识别在接收MGW内的特殊情况：在Add.Rep处理期间准备接收“UP Init”；

·接收UP Init；从IP的源字段和“UP Init”的UDP头中重新得到远程地址；

·从UP Init的RTP头中重新得到RTP有效载荷类型号；

·使用所重新得到的远程地址、端口和RTP有效载荷类型号立即发送“UP InitAck”

·当通过IPBCP已接受(IPBCP Accepted)从MSC-S接收到远程地址时发送Notify.Ind(承载已建立)。

在所建议的解决方案的优点之中，UP Init消息丢失、超时和重复的UP Init被防止。另外，由超时所引起的呼叫建立延迟被防止。

附图说明

图1描述了本发明的消息流。

具体实施方式

根据本发明，MGW T使用在传输Nb成帧协议的初始化消息的所接收的IP包中所指示的“源”(发送机)地址和端口号作为NB成帧协议的初始化应答消息的目的地地址和端口号。

与已成文的标准相比，命令采用在从MGW O向MGW T所发送的IPBCP接受消息中所指示的IP地址和端口号。但是，按照IPBCP，保证这些地址和端口号是相同的，因为IPBCP指导：在发送以及接收传输连接的IP包时必须使用所指示的IP地址和端口号。因而，IPBCP偏离于IETF的理解：在“会话描述协议”(SDP，IETF RFC 2327)内所输送的IP地址和端口号仅仅涉及目的地，而不涉及媒体流的源，即使IPBCP采用SDP。

现在就图1而论，示出了信息流100，用于根据所提议的解决方案在媒体网关MGW O 102和控制MSC服务器MSC-S O 104以及媒体网关MGW T 106和控制MSC服务器MSC-S T 108之间通过BICC“延迟反向承载建立”来建立IP传输用户连接。

这里，如从主叫侧看，MGW O 102被示出在传输连接中位于MGW T 106之前。IPBCP协议在MGW和服务器之间通过“隧道信息上行(Tunnel Info up)”(109，110)和“隧道信息下行(Tunnel Info down)”(112，113)消息以及在MSC服务器之间通过BICC信令的“APM”消息(111，115)来传输。

根据“延迟反向承载建立”，MGW T 106首先发送IPBCP请求消息(109，111，112)到MGW O 102，并且在内部指示IP地址和UDP端口号，MGW T将使用所述IP地址和UDP端口号用于发送和接收新IP传输连接的IP包。

当接收到该IPBCP请求消息时，MGW O 102发送IPBCP接受消息(110，115，113)并且同时或者不久之后向MGW T 106发送Nb成帧协议的初始化消息“UP Init”114。因为“UP Init”通过IP被直接发送到MGW T 106，而IPBCP消息通过MSC-S T 108和MSC S O 104传递，所以很可能“UP Init”消息114首先到达MGW-T 106。

根据所建议的方法，在接收到来自MGW O的用户数据连接内的第一包、即“UP Init”消息114之后，MGW立即向MGW O发送用户数据连接内的第一包、即Nb成帧协议的初始化应答消息“UP Init Ack”116，并且使用在作为源地址和端口号的“UP Init”114的IP头中所指示的地址和端口号作为IP目的地地址和端口号。

作为在“UP Init Ack”消息116中的RTP有效载荷类型号，MGW T 106采用在所接收的“UP Init”消息114中的RTP头中所使用的RTP有效载荷类型。根据这里所建议的方法，MGW T 106在接收到初始化消息后立即或者不久之后发送初始化应答消息，而不像以前在标准中那样在收到IPBCP接受消息之后。

接下来，Nb成帧协议在“实时传输协议”(RTP)、IETF RFC 2833的有效载荷中被传输。每一个包的RTP头都包含所谓的RTP有效载荷类型用以指示有效载荷类型。对于作为RTP内的有效载荷的Nb成帧协议，所谓的动态RTP有效载荷类型号被使用，也即通过在RTP传输连接建立之前协商而分配给有效载荷类型的号。使用IPBCP用于这种协商。

因此，MGW T 106使用相同的RTP有效载荷类型号用于Nb成帧协议初始化应答消息，该号被用在传输Nb成帧协议初始化消息的包的RTP头中。根据现有的标准，MGW T 106将会使用在IPBCP消息内所接收的RTP有效载荷类型号来代替。但是，因为MGW O 102使用针对Iu FP初始化消息朝向MGW T 106的IPBCP消息中所指示的RTP有效载荷类型号，并且因为MGW T 106必须在至MGW O 102的IPBCP应答消息中指示相同的RTP有效载荷类型号，其中MGWT 106根据IPBCP从MGW O 102在IPBCP消息中接收到所述相同的RTP有效载荷类型号，所以可以保证MGW T 106的改变了的行为在MGW O 102处不产生差错。

根据现有标准，一旦用户数据传输连接已经通过Nb成帧协议初始化被建立，则MGW T 106需要利用承载已建立进程118来通知MSC-S T 108。但是，MSC-ST 108将只在发送了隧道信息下行进程113之后才期望该通知。因此，如果MGWT 106只在接收到信道信息下行进程113之后发送发送承载已建立进序118，则是有利的。

应当理解的是，在这里所建议的方法论的情况下，通过3GPP移动网络的Cs域在建立IP传输连接期间在BICC“延迟反向承载建立”的情况下避免差错和延迟。

如果其他成帧协议代替Nb成帧协议被用于传输用户数据，例如如果用户数据直接在“实时传输协议”(RTP)、IETF RFC 2833内被传输，则这里所建议的方法论也是可应用的。实质上，MGW T在从MGW O接收到用户数据传输连接内的第一包之后向MGW O发送用户传输连接数据内的第一包包并且MGW T使用在来自MGW T的所接收的包的IP头中所指示为源地址和端口号的地址和端口号作为IP目的地地址和端口号。在这里，所建议的方法论的特定优点是用户数据传输连接建立的加速。

Claims (11)

1.一种用于在IP网络内在网络实体MGW O和网络实体MGW T之间使用BICC“延迟反向承载建立”建立IP传输用户连接的方法，其中，MGW O向MGW T发送IPBCP接受消息并且也开始向MGW T发送用户数据传输连接内的(多个)包，该方法包含下述步骤：

由MGW T从自MGW O所接收的用户数据传输连接IP包重新得到源IP地址和端口号，

当从MGW O接收到用户数据传输连接IP包时，由MGW T利用所重新得到的IP地址和端口号作为目的地向MGW O发送(多个)第一用户数据传输连接IP包。

2.根据前面权利要求所述的方法，进一步的特征在于，当从MGW O接收到第一用户数据传输连接IP包时立即由MGW T向MGW O发送第一用户数据传输连接IP包。

3.根据前面任一权利要求所述的方法，进一步的特征在于，传输“实时传输协议”、IETF RFC 2833或者RFC 1889内的用户数据。

4.根据前面任一权利要求所述的方法，进一步包含步骤：由MGW T从自MGW O所接收的用户数据传输连接IP包的RTP头中重新得到RTP有效载荷类型号。

5.根据前面任一权利要求所述的方法，进一步包含步骤：由MGW T使用从来自MGW O的所接收的用户数据传输连接IP包的RTP头中所重新得到的RTP有效载荷类型号作为向MGW O所发送的用户数据传输连接包内的RTP有效载荷类型号。

6.根据前面任一权利要求所述的方法，进一步的特征在于，传输“Nb成帧协议”、3GPP TS 29.415内的用户数据。

7.根据前面任一权利要求所述的方法，进一步的特征在于，由MGW T使用“Nb Init”消息作为来自MGW O的用户数据传输连接IP包，其中从MGW O重新得到数据。

8.根据前面任一权利要求所述的方法，进一步的特征在于，由MGW T使用“Nb Init Ack”消息作为向MGW O所发送的第一用户数据传输连接IP包。

9.根据前面任一权利要求所述的方法，进一步包括如下步骤：在接收到“隧道信息下行”进程113之后由MGW T发送“承载已建立”通知指示118。

10.根据前面任一权利要求所述的方法，进一步的特征在于，由MGWT使用3GPP移动网络的Cs域的Nb接口来传输用户数据传输连接。

11.根据前面任一项权利要求建立IP用户数据传输连接的装置MGWT，例如“媒体网关”或者集成式“移动业务交换中心”。