CN1585314A - 一种请求服务区标识的处理方法 - Google Patents

Abstract

本发明提供一种请求服务区标识的处理方法，用于在PMM IDLE态下MS INFORMANTION过程向SGSN请求用户位置信息，其包括下列步骤：a、MSC/VLR向SGSN发送一条MS Information Request(IMSI，Information Type)；b、用户处于IDLE态，则SGSN发起寻呼流程；c、MS接收到寻呼消息之后，发起Service Request流程，重建Iu接口；d、Service Request流程结束之后，SGSN向MSC/VLR发送一条MS Information Response(IMSI，Information)。利用本发明，保证了SGSN向MSC/VLR提供的用户位置信息的准确性，在此基础上，提高了效率，减轻了网络负担。

Description

一种请求服务区标识的处理方法

技术领域

本发明涉及WCDMA移动通信***，尤其涉及PMM IDLE态下MSC/VLR通过MS INFORMATION过程向SGSN请求用户位置信息的实现方法。

发明背景

WCDMA***中，一个合法签约用户可以通过联合附着的方法同时在分组域和电路域同时附着，此时在Gs接口上，电路域实体MSC/VLR和分组域实体SGSN之间就建立了一种关联关系。针对这种联合附着的用户，MSC/VLR可以通过Gs接口过程MS INFORMATION来获取用户的相关信息，例如用户的位置信息。

对于联合附着的用户，MSC/VLR可以随时发起MS INFORMATION过程以获取用户的位置信息。对于附着在2G接入网中的用户，MS INFORMATION应答消息中的位置信息用小区标志表示，对于附着在3G接入网中的用户，应答消息中的位置信息用服务区标志(SAI)表示。对于3G的情况，现有实现方案如图1所示，如下描述：

1：MSC/VLR向SGSN发送一条MS Information Request(IMSI，InformationType)，其中的信元“Information Type”指示MSC/VLR请求的信息类型，这里是用户位置信息；

2：在Iu模式下，如果该用户存在Iu连接，SGSN将利用位置报告流程获取用户的SAI信息(关于位置报告流程的进一步信息请参见3GPP 25.413协议)。如果UTRAN节点不能获取用户的SAI，它将在位置报告消息中指示请求不能满足，并可选的上报该用户的上次的SAI及相应时间戳；

3：SGSN向MSC/VLR发送一条MS Information Response(IMSI，Information)，信元“Information”包括MSC/VLR请求的信息，这里是用户位置信息，即SAI；在Iu模式下，如果该用户存在Iu接口，如果位置报告流程中UTRAN节点无法确定用户SAI，并且没有向SGSN上报用户的当前SAI和上次SAI，SGSN应该在MS Information Response包含SGSN保存的用户上次上报的SAI和相应的时间戳。

然而现有技术的缺点是：没有明确规定在PMM IDLE态下，也就是没有Iu接口的情况下如何获取用户SAI信息。针对这种情况SGSN有多种选择，例如直接向MSC/VLR回MS Information Response消息，包含SGSN保存的用户上次上报的SAI和相应的时间戳，虽然SGSN能通过其他方法获取用户更精确的位置信息。但由于协议描述不明确，会导致SGSN实现的多样性，同时产生提供给用户的服务质量下降的问题。

发明内容

本发明针对上面描述的问题，提出一种利用明确的实现方案，保证SGSN向MSC/VLR提供精确的用户位置信息。

一种请求服务区标识的处理方法，包括下列步骤：

a、MSC/VLR向SGSN发送MS Information Request，其包括信元Information Type；

b、SGSN判断用户是否处于IDLE态？若是，则发起寻呼流程，向MS发送寻呼消息，进入步骤c；若否，则按照现有流程处理；

c、MS发起Service Request流程，建立Iu接口；

d、SGSN向MSC/VLR发送MS Information Response消息，其中包括Information信元，该Information信元包括SGSN在Service Request流程中获取的用户位置信息。

所述的步骤a中的信元“Information Type”指示MSC/VLR请求的信息类型。

所述的信息类型是用户位置信息。

所述的步骤b中的寻呼流程包括下列步骤：

b1、SGSN向UTRAN发送Paging Request消息；

b2、UTRAN向MS发送Paging消息。

所述的步骤c进一步包括：

c1、MS接收RNC发送的寻呼消息；

c2、MS发起RRC重建过程；

c3、MS向SGSN发送service request消息，包含Service Type信元；

c4、SGSN通过安全流程验证移动台的合法性。

利用本发明的技术方案，可带来如下的有益效果：

1：保证SGSN实现方案的一致性；

2：提高向MSC/VLR提供的用户位置信息的准确性；

3：避免寻呼之后再次发起位置报告过程，减轻了网络负担。

附图说明

图1所示为3G情况时连接态下MS Information流程；

图2所示为3G情况时IDLE态下MS Information流程；

图3是本发明Service Request流程的示意图。

具体实施方式

本发明针对现有技术中的问题，提出一种利用明确的实现方案，保证SGSN向MSC/VLR提供精确的用户位置信息。

图2所示为3G情况时IDLE态下MS Information流程，本文针对现有技术存在的问题，提出了如下的解决方案：

1：MSC/VLR向SGSN发送一条MS Information Request(IMSI，InformationType)，其中的信元“Information Type”指示MSC/VLR请求的信息类型，这里是用户位置信息，该消息的结构可以如下表所示，各信元具体结构参见3GPP29018协议相应章节：

Information Element	Type/Reference	Presence	Format	Length
					Message type	Message type18.2	M	V	1
IMSI	IMSI18.4.10	M	TLV	6-10
					MM information	MM information18.4.16	O	TLV	3-n

2、SGSN判断用户状态是否为IDLE，若不是，则按照正常流程处理，若是，则进入步骤3；正常流程与前面现有技术中的描述是一致的。

3：SGSN根据移动台当前驻留的路由区、RNC等相关信息，向MS发送寻呼请求消息；

4：MS接收到寻呼消息之后，发起Service Request流程，Service Request的流程如图3所示，具体过程描述如下：

41)移动台接收到RNC发送的寻呼消息；

42)移动台发起RRC重建过程；原则上这时应该没有RRC连接，如果有则肯定是对应于CS域的RRC连接(也就是和MSC的连接)，这时MSC应该有更直接的方法获取移动台的SAI，也就不会通过SGSN获取了。

43)重建RRC连接后，移动台向SGSN发送service request消息，包含PTMSI、CKSN、Service Type等信元，其中Service Type信元指示是寻呼响应；

44)SGSN通过安全流程验证移动台的合法性；

Service Request流程以安全流程结束为成功标志。由于此时的Service Request消息是通过RNC和SGSN之间的RANAP协议层的Init UE原语消息承载的，InitUE原语中包含了移动台当前的服务区信息。因此，Service Request流程结束后，SGSN就得到移动台当时所在的位置区的准确信息。Init UE原语消息头的结构如下所示，各信元具体结构参见3GPP 25413协议相关章节(注意其中包含SAI，也就是服务区标志信元)：

IE/Group Name	Presence	Range	IE type andreference	Semanticsdescription	Criticality	AssignedCriticality
							Message Type	M		9.2.1.1		YES	ignore
CN Domain Indicator	M		9.2.1.5		YES	ignore
							LAI	M		9.2.3.6		YES	ignore
RAC	C-ifPS		9.2.3.7		YES	ignore
							SAI	M		9.2.3.9		YES	ignore
NAS-PDU	M		9.2.3.5		YES	ignore
							Iu Signalling ConnectionIdentifier	M		9.2.1.38		YES	ignore
Global RNC-ID	M		9.2.1.39		YES	ignore

5：SGSN向MSC/VLR发送一条MS Information Response(IMSI，Information)，信元“Information”包括SGSN在Service Request流程中获取的用户位置信息，不包括时间戳信息，而无需再次发起位置图1中的位置报告流程。该消息的结构如下表所示，特别的，在3G情况下，对于MSC/VLR请求用户位置信息触发的MS Information Response消息，除消息中的必选信元(消息类型、IMSI)外，只可能包含Location Information Age、Mobile Station State和ServiceArea Indication这3个信元，这些信元的具体结构参见3GPP 29018协议相关章节。

Information Element	Type/Reference	Presence	Format	Length
					Message type	Message type18.2	M	V	1
IMSI	IMSI18.4.10	M	TLV	6-10
					TMSI	TMSI18.4.23	O	TLV	6
PTMSI	PTMSI18.4.20	O	TLV	6
					IMEI	IMEI18.4.8	O	TLV	10
IMEISV	IMEISV18.4.9	O	TLV	10
					Cell global identity	Cell global identity18.4.1	O	TLV	10
Location information age	Location information age18.4.15	O	TLV	4
					Mobile station state	Mobile station state18.4.19	O	TLV	3
Service area identification	Service area identification18.4.21b	O	TLV	9

利用本发明的技术方案，其有益效果如下：

1：保证了SGSN实现方案的一致性；

2：提高了向MSC/VLR提供的用户位置信息的准确性；

3：避免了寻呼之后再次发起位置报告过程，减轻了网络负担；

利用本发明，保证了SGSN向MSC/VLR提供的用户位置信息的准确性，在此基础上，提高了效率，减轻了网络负担。

Claims (5)

1、一种请求服务区标识的处理方法，其特征在于包括下列步骤：

a、MSC/VLR向SGSN发送MS Information Request，其包括信元InformationType；

b、SGSN判断用户是否处于IDLE态？若是，则发起寻呼流程，向MS发送寻呼消息，进入步骤c；若否，则按照现有流程处理；

c、MS发起Service Request流程，建立Iu接口；

d、SGSN向MSC/VLR发送MS Information Response消息，其中包括Information信元，该Information信元包括SGSN在Service Request流程中获取的用户位置信息。

2、如权利要求1所述的一种请求服务区标识的处理方法，其特征在于：所述的步骤a中的信元“Information Type”指示MSC/VLR请求的信息类型。

3、如权利要求2所述的一种请求服务区标识的处理方法，其特征在于：所述的信息类型是用户位置信息。

4、如权利要求1所述的一种请求服务区标识的处理方法，其特征在于：所述的步骤b中的寻呼流程包括下列步骤：

b1、SGSN向UTRAN发送Paging Request消息；

b2、UTRAN向MS发送Paging消息。

5、如权利要求1所述的一种请求服务区标识的处理方法，其特征在于所述的步骤c进一步包括：

c1、MS接收RNC发送的寻呼消息；

c2、MS发起RRC重建过程；

c3、MS向SGSN发送service request消息，包含Service Type信元；

c4、SGSN通过安全流程验证移动台的合法性。

Images