CN1780300A - 一种版本协商的方法 - Google Patents

Abstract

本发明公开了一种版本协商的方法，该方法包括：设置第一设备标识及所属第二设备支持的对话版本类型之间的对应关系；当网络侧的节点设备收到来自第一设备的含有自身标识的对话请求后，判断自身支持的对话版本与第一设备所属的第二设备支持的对话版本级别的高低，如果节点设备支持的对话版本高，则从所述对应关系中获取该终端对应的第二设备对话版本类型，然后向第二设备发起该版本类型的对话请求，否则，利用自身支持的对话版本与第二设备进行通信。该方法能够使基于MAP协议的设备相互通信时，最大可能的直接命中对方支持的版本，避免降版本过程，从而降低了流程延时和数据流量。

Description

一种版本协商的方法

技术领域

本发明涉及通信技术领域，特别是指一种版本协商的方法。

背景技术

随着第三代移动通信标准化组织(3GPP)协议的不断演化，核心网的移动应用部分(MAP)协议已经发展出多个个版本，如V1、V2和V2+V3、V4等。随着版本的升高，MAP协议所能实现的功能不断增加，提供了越来越多的业务支撑，同时也使现网中各个设备支持的版本多样、复杂。而正是由于现网设备构成的复杂性，不同协议版本的设备之间的通信也相应复杂起来。

例如，服务GPRS支撑节点(SGSN)和归属位置寄存器(HLR)之间的Gr接口，由于不同的SGSN和HLR对于不同的对话所支持的MAP协议版本可能不同，为此，SGSN在建立和HLR之间的MAP对话之前，就必须知道HLR所支持这个对话上的版本。在目前的MAP协议框架下，SGSN可以通过版本探测的方法得到HLR的版本。

在发起对话的时候，SGSN会先向HLR发送三条消息，分别是MAP_OPEN_Req，MAP_SERVICE_Req，MAP_DELIMITER_Req，其中MAP_OPEN_Req承担打开对话和版本探测协商的功能。MAP_OPEN的消息结构如表1所示，并且各个信元的具体取值请参考3GPP 29002-V4b0。

Parameters	Request	Indication	Response	Confirm
					Application context name	M	M(＝)	U	C(＝)
Destination address	M	M(＝)
					Destination reference	U	C(＝)
Originating address	U	O
					Originating reference	U	C(＝)
Specific information	U	C(＝)	U	C(＝)
					Responding address			U	C(＝)
Result			M	M(＝)

Refuse-reason			C	C(＝)
					Provider error				O

                       表1

如表1所示，MAP_OPEN_Req中的Application context name表明对话类型和版本。当HLR接收到SGSN发送的MAP_OPEN_Req后，HLR将检查这个信元，如果发现自身对话类型支持的版本低于SGSN请求的版本，HLR将在MAP_OPEN_Cnf的Application context name返回自己支持的版本。

例如，支持V2+的SGSN发起到HLR的版本协商的过程，如果HLR支持V2+，则对话可以继续，如果不支持V2+版本，会在MAP_OPEN_Cnf中返回自己支持的版本，SGSN会根据HLR返回的版本重新发起低版本的对话。

参见图l所示，如果HLR支持V2+，其具体流程如下：

步骤101～103：SGSN向HLR发送V2+版本的MAP_OPEN_Req请求、MAP_SERVICE_Req请求和MAP_DELIMITER_Req。

步骤104：HLR收到这些请求后，如果自身支持V2+版本，则向SGSN发送MAP_OPEN_Cnf，同意V2+版本。

步骤105：SGSN与HLR之间采用V2+版本进行对话。

参见图2所示，如果HLR不支持V2+，其具体流程如下：

步骤201～203：SGSN向HLR发送V2+版本的MAP_OPEN_Req请求、MAP_SERVICE_Req请求和MAP_DELIMITER_Req。

步骤204：HLR收到这些请求后，如果自身不支持V2+版本，则向SGSN发送MAP_OPEN_Cnf消息，表示自身支持的版本V1、V2。

步骤205～207：SGSN收到该MAP_OPEN_Cnf消息后，向HLR发送选择V1或V2版本的MAP_OPEN_Req请求、MAP_SERVICE_Req请求和MAP_DELIMITER_Req。

步骤208：SGSN与HLR之间采用V1或V2版本进行对话。

从以上两个流程图的对比可以看出，SGSN在发起对话时，都是以自身支持的版本作为初始版本进行探测，如果对端只支持低版本的对话，版本协商过程就复杂，导致消息流量和流程延时的增加。也就是说，当SGSN支持高版本，HLR支持低版本的情况下，由于版本协商过程，SGSN和HLR之间的数据流量会显著增加。这一方面会导致流程持续时间延长，降低提供给用户的服务质量，同时由于HLR的特殊性，过多的数据流量会导致HLR负荷增加，使其运行状况恶化，甚至导致事故。

发明内容

有鉴于此，本发明的目的在于提供一种版本协商的方法，使其在发端支持高版本、收端支持低版本的情况下，能减小版本协商的复杂度，从而减少发端与收端之间的消息流量和延时。

为了达到上述目的，本发明提供了一种版本协商的方法，该方法包含：

a.设置第一设备标识及所属第二设备支持的对话版本类型之间的对应关系；

b.当网络侧的节点设备收到来自第一设备的含有自身标识的对话请求后，判断自身支持的对话版本与第一设备所属的第二设备支持的对话版本级别的高低，如果节点设备支持的对话版本高，则从所述对应关系中获取该终端对应的第二设备对话版本类型，然后向第二设备发起该版本类型的对话请求，否则，利用自身支持的对话版本与第二设备进行通信。

步骤a中所述用户标识为国际移动用户识别(IMSI)号码或用户MSISDN号码。

所述节点设备为SGSN，或拜访位置寄存器(VLR)，或短消息网关。

所述第一设备为用户终端，或网络设备。

当所述第一设备为用户终端，第二设备为HLR时，

步骤a中所述第一设备标识及其第二设备对话版本类型之间的对应关系为用户IMSI号码段和HLR对话版本类型的对应关系，或为MSISDN号码段和HLR对话版本类型的对应关系。

本发明通过预先设置第一设备标识和第二设备的版本类型之间的对应关系，当第一设备需要通过网络侧的节点设备与第二设备进行通信时，节点设备从该对应关系中获取第二设备的版本类型，并利用该版本类别与第二设备进行对话。该方法能够使基于MAP协议的设备相互通信时，最大可能的直接命中对方支持的版本，避免降版本过程，从而降低了流程延时和数据流量。

附图说明

图1为现有技术中HLR和SGSN都支持V2+版本时版本协商的流程示意图；

图2为现有技术中SGSN都支持V2+版本，HLR不支持V2+版本时版本协商的流程示意图；

图3为实现本发明方法的流程示意图。

具体实施方式

为使本发明的目的、技术方案和优点更加清楚，下面结合附图对本发明作进一步的详细描述。

本发明的核心思想是：设置第一设备标识及第二设备支持的各种对话版本类型之间的对应关系；当网络侧的节点设备收到来自第一设备的含有自身标识的对话请求后，从所述对应关系中获取该终端对应的第二设备对话版本类型，然后利用该版本类型向第二设备发起对话请求。这里，第一设备、第二设备以及网络侧的节点设备可以是进行通信的任何通信实体，只要基于MAP协议进行通信的设备即可。比如，第一设备可以为用户终端，也可以是其它网络设备，第二设备可以为HLR等网络侧的设备实体，网络侧的节点设备可以为VLR、SGSN、短消息网关等，此时节点设备与HLR之间采用MAP协议进行通信。

参见图3所示，实现本发明的方法包括以下步骤：

步骤301：设置第一设备标识及其第二设备对话版本类型之间的对应关系。

所述对应关系可以设置在第一设备中，也可以设置在网络侧的节点设备中，也可以设置在一个独立的服务器中。

步骤302：当网络侧的节点设备收到来自第一设备的含有自身标识的对话请求后，比较第二节点设备的版本与自身版本级别的高低，如果自身版本级别高，则执行步骤303，否则，利用自身的版本进行对话，结束本流程。

步骤303：网络侧的节点设备从所述对应关系中获取该终端对应的第二设备对话版本类型，然后向第二设备发起该版本类型的对话请求。

本发明的方法可以应用在两个进行通信的设备中。例如，第一设备为用户终端，第二设备为HLR，网络侧的节点设备为SGSN，SGSN与HLR之间的接口为Gr接口，在Gr接口中应用本发明的方法即可减小Gr接口的消息流量以及延时。

以下以第一设备为用户终端，第二设备为HLR，网络侧的节点设备为SGSN时，SGSN与HLR之间的接口为Gr接口为例，来说明本发明的技术方案。

需要说明的是，对于Gr接口上的大部分对话来讲，都是针对特定用户的对话，比如取鉴权集、Ready for SM等，这些对话对应的HLR就是用户开户的HLR。在网络规划中，HLR为一个或若干个连续号段的用户开户。这样，在发起对话之前，SGSN只要判断用户的IMSI在哪个号段之内就能获取到其开户HLR的地址，然后再向这个HLR发送相关消息。

基于此，本实施例可以设置IMSI号段与HLR支持的各种对话版本的对应关系，表示某一或某些号码段内所有IMSI号码所属的HLR所支持的对话版本类型，这个版本类型可以是一种或几种。如表2所示，IMSI号段为460000000000000～460009999999999，其所属HLR支持的对话版本为V1、V2、V3。这里，由于HLR和SGSN之间有多种对话，每个对话都可能有多种版本如：HLR支持V1、V2、V3等多个对话版本。

IMSI号段

对话类型1

对话类型2

对话类型3

460000000000000～460009999999999

V3

V2

V1

                        表2

这样，在发起对话之前，SGSN就可以根据用户IMSI号码查询用户开户HLR支持的对话的版本，从而能够发起该HLR支持的版本的对话，直接与HLR进行正常对话。

用户MSISDN号段

HLR不同对话版本

               表3

网络侧的节点设备SGSN与HLR之间进行对话的方法是这样的：当网络侧的节点设备SGSN收到来自用户终端含有自身IMSI号码的对话请求时，根据用户终端的IMSI号码确定该用户终端所属HLR的版本类型，并按照获取到的该版本类型与其所属HLR进行对话。

当然，对于网络侧的节点设备为VLR、短消息网关的情况，上述实施例的方法同样适用，只是应用在不同的接口上而已，比如，VLR与HLR之间的接口为D接口，短消息网关与HLR之间的接口为C接口。

参见表4所示，将上述实施例中的IMSI号段改成用户的MSISDN号段，同样可以用于C接口，D接口。

用户MSISDN号段

HLR不同对话版本

               表4

参见表5所示，对于利用网络设备号寻址的对话，如Gd接口、E接口上的短消息，Gf接口上的IMEI校验，将IMSI号段改成相应设备的MSISDN号，将HLR支持的协议版本改成相应设备支持的对话版本，本发明同样可以利用在Gd接口、E接口和Gf接口。

相应设备的MSISDN号

对应设备的不同对话版本

                    表5

总之，以上所述仅为本发明的较佳实施例而已，并非用于限定本发明的保护范围。

Claims (5)

1、一种版本协商的方法，其特征在于，该方法包括以下步骤：

a.设置第一设备标识及所属第二设备支持的对话版本类型之间的对应关系；

b.当网络侧的节点设备收到来自第一设备的含有自身标识的对话请求后，判断自身支持的对话版本与第一设备所属的第二设备支持的对话版本级别的高低，如果节点设备支持的对话版本高，则从所述对应关系中获取该终端对应的第二设备对话版本类型，然后向第二设备发起该版本类型的对话请求，否则，利用自身支持的对话版本与第二设备进行通信。

2、根据权利要求1所述的方法，其特征在于，步骤a中所述用户标识为IMSI号码或MSISDN号码。

3、根据权利要求1所述的方法，其特征在于，所述节点设备为SGSN，或VLR，或短消息网关。

4、根据权利要求1所述的方法，其特征在于，所述第一设备为用户终端，或网络设备。

5、根据权利要求1所述的方法，其特征在于，当所述第一设备为用户终端，第二设备为HLR时，

步骤a中所述第一设备标识及其第二设备对话版本类型之间的对应关系为用户IMSI号码段和HLR对话版本类型的对应关系，或为MSISDN号码段和HLR对话版本类型的对应关系。

Images