本实例主要介绍在附着流程中,SGSN怎样通过RAI向DNS服务器查询对应的Old SGSN的IP地址的过程。
下图描述了本实例所针对的信令流程场景。
[attach]1229[/attach]
以下是具体的各个步骤的说明。
1)MS发起附着流程,发送Attach Request消息给SGSN,并携带有最近一次由Old SGSN为其分配的MS临时标识Old P-TMSI以及Old RAI。如下图所示。
[attach]1230[/attach]
2)New SGSN收到后,根据信令流程的要求。需要向Old SGSN查询关于该用户的IMSI用于后续的鉴权流程。但此时,New SGSN并不知道Old SGSN的IP地址。因此,New SGSN首先将在本地查询Old RAI和Old SGSN的映射关系,如果没有查询到,则New SGSN将向配置的DNS服务器发送DNS查询请求,请求DNS服务器根据Old RAI来解析对应的Old SGSN的IP地址。发送给DNS服务器的查询请求中包含的RAI全名是”rac0000.lac7988.mnc000.mcc460.gprs.”。
3)DNS服务器中将根据etc/named.conf文件中的内容对该收到的请求进行解析。DNS服务器在该文件中查找到对应的区域为”mnc000.mcc460.gprs”,如下图所示:
[attach]1233[/attach]
对应的区域配置内容如下图所示:
[attach]1234[/attach]
从上图可知,”rac0000.lac7988.mnc000.mcc460.gprs.”对应的解析结果为一条A记录,解析出的值为IP地址201.1.1.1。
4)New SGSN根据查询到的Old SGSN的IP地址,向目标IP地址为201.1.1.1的Old SGSN发送Identification Request,以Old-PTMSI做为查询条件,去请求用户对应的IMSI。
5)Old SGSN在收到New SGSN的Identification Request消息后,根据New SGSN提供的用户的P-TMSI,查询到对应的用户的IMSI,并通过Identification Response消息返回给New SGSN。
暂时还没有时间哦。EPC中的DNS增加了NAPTR还有Service和SRV记录,这主要原因是控制和用户面分离了,用户面更多了。需要为用户选择最近、负载最低的SGW/PGW为其服务。这块的内容是今后的论坛重点。但要花点时间,会先把基本的信令流程补上,例如缺省承载的建立实例等。
和DNS相关的故障是这样的:
1 PDP上下文激活时解析不到GGSN的IP,回CC38 Network failure。
2 RAU解析不到old SGSN IP,回CC9 MS_identity_cannot_be_derived_by_the_network,参考这个实例:http://www.gprshome.com/forum.php?mod=viewthread&tid=510。
附着不是100%确定,应该也是CC9,但个人感觉规范中定义从old SGSN获取用户的IMSI属可选流程,如果获取不到还可以找MS去要,因此理论上应该可以不用回CC9,但如果回了CC9也是符合规范的。
但RAU不行,RAU有可能涉及到带业务的切换,所以获取的不只是IMSI,是完整的MM和PDP上下文,这些上下文信息拿不到,用户的业务肯定会断,与其如此,还不如给MS回一个CC9,根据规范,MS收到CC9后,将删除P-TMSI,重新发起附着流程,这也是网络侧所期望的。
欢迎光临 51学通信技术论坛 (http://51xuetongxin.com/bbs/) | Powered by Discuz! X2 |