51学通信技术论坛

标题: 一个较完整的Inter-SGSN RAU实例(除Gr接口) [打印本页]

作者: 爱卫生 时间: 2011-11-15 16:16:16 标题: 一个较完整的Inter-SGSN RAU实例(除Gr接口)

本帖最后由爱卫生于 2011-11-16 13:28 编辑

RAU流程的规范在TS23.060的6.9.1.2章节中定义。相应的翻译已完成，请参考链接http://www.gprshome.com/forum.php?mod=viewthread&tid=119&extra=page%3D1。
本例中，通过一个实例来介绍Inter-SGSN RAU流程。但因为抓包环境所限，没有抓到Gr接口的报文，而且Iu和Gn接口的抓包是分开抓的，然后通过Wireshark软件进行合并。因此在包的编号上容易引起混淆，请按时间进行排序后即可得到正确的信令流程的顺序。
本实例的步骤说明如下：
1 UE发起RAU Request消息给SGSN，包含有Old RAI(标识UE是从哪个RA过来的)，P-TMSI（标识UE的身份），更新类型（取值为0代表是一个非周期性的RA更新），PDP上下文的状态（通知网络侧是否当前仍有激活的PDP上下文）。并在RANAP层的消息中，RNC会向SGSN报告用户当前的RAI和RNC的ID。可以看到Old RAI为262-99-6-1，而当前的RAI为262-99-41-41。如图1所示。

[attach]979[/attach]

图1 UE发送RAU Request(Inter-SGSN RAU)

2 SGSN收到UE发送来的RAU Request消息后，通过对比Old RAI和自己提供服务的RA的RAI发现，这个Old RAI对应的RA不是由自己所管理的。根据Old RAI查询DNS服务器，可以得到对应的管理此RA的SGSN的IP地址。因此，New SGSN向这个Old SGSN发送SGSN Context Request消息，请求对方将用户的IMSI、MM(移动性管理)上下文和PDP上下文等相关信息返回来。在这个消息里，将提供UE的P-TMSI以及Old RAI给Old SGSN做为查询依据。如图2所示。

[attach]980[/attach]

图2 New SGSN给Old SGSN发送SGSN Context Request请求获取UE的相关信息

3 Old SGSN根据New SGSN提供的UE的P-TMSI以及Old RAI查询到了UE的相关信息，包括IMSI、MM上下文、PDP上下文等。通过发送SGSN Context Response消息给New SGSN将这些信息告诉New SGSN。其中控制面TEID是由第二步中的Old SGSN在SGSN Context Request消息中提供的。如图3所示。

[attach]981[/attach]

图3 Old SGSN给New SGSN发送SGSN Context Response消息返回UE的相关信息

4 New SGSN通过Old SGSN提供的SGSN Context Request消息得到了UE的IMSI、MM上下文、PDP上下文等信息。通过IMSI，New SGSN发起了对UE的鉴权流程，对应TS23.060的6.9.1.2.2章节的第三步---Security Function。在包中体现在按时间排序的第4至第7号报文。
5 New SGSN给Old SGSN发送SGSN Context Acknowledgement消息，确认用户的相关信息已经收到。
6 由于服务的SGSN已经发生了改变，为了保证用户下行数据的正确传递，New SGSN给为UE提供服务的GGSN发送Update PDP Context Request消息，请求GGSN对下行方向服务的SGSN的IP地址、控制和用户面的TEID等信息进行更新。服务的GGSN的IP地址可以从第3步中得到的UE的PDP上下文中获取。同时，还需要和GGSN侧进行用户Qos的协商。如图4所示。

[attach]982[/attach]

图4 New SGSN给GGSN发送Update PDP Context Request消息

7 GGSN收到后，将下行方向SGSN的控制面和用户面IP地址以及TEID进行更新，并给New SGSN发送Update PDP Context Response进行确认，并在消息中给New SGSN分配上行方向GGSN侧的控制面和用户面IP地址以及用户面的TEID（控制面TEID在New SGSN侧已经从UE的PDP上下文中获取，无需重新分配），最后完成用户的Qos协商，将GGSN支持的Qos也返回给New SGSN。如图5所示。

[attach]983[/attach]

图5 GGSN给New SGSN回应Update PDP Context Response消息

8 接下来应该是New SGSN和HLR进行位置更新、获取用户签约数据的操作，通知HLR会给Old SGSN发送Cancel Location消息通知Old SGSN可以将UE的相关MM上下文和PDP上下文等信息进行释放和资源回收。但这部分限于抓包环境没有抓到，仅放在此处进行信令流程的完整性补全参考。

9 和Intra-SGSN RAU更新一样，New SGSN给UE发送RAU Accept消息。消息中包含新分配的P-TMSI、T3312计时器长度以及当前的RAI是262-99-41-41。这里的当前RAI的值与第一步中RNC在RANAP消息里报告给SGSN的用户当前RAI值相同（需主要十六进制到十进制的换算:0x29=十进制41)。如图6所示。

[attach]984[/attach]

图6 New SGSN给UE发送RAU Accept消息

10 UE给SGSN回送RAU Complete消息对新分配的P-TMSI进行确认。并将收到的T3312、当前RAI的值、新分配的P-TMSI存储起来，完成整个RAU更新流程。

[attach]985[/attach]

作者: gengyangsdtm 时间: 2011-11-15 19:50:50

楼主真的辛苦了，谢谢给大家的分享

作者: Albert 时间: 2011-11-16 12:38:03

不知2G的RAU流程和相应消息是否一样?

作者: 爱卫生 时间: 2011-11-16 12:57:42

回复 Albert 的帖子

核心网侧Gn接口、Gr接口的流程是一样的。区别只是Gb接口代替了Iu-C接口，BSSGP代替了RANAP。流程基本也是一致的。BSS也需要通过BSSGP协议像SGSN报告用户的当前位置信息。

作者: Albert 时间: 2011-11-16 13:14:30

可以看到当前的RAI为262-99-6-1，而当前的RAI为262-99-41-41.这里貌似爱总过于辛苦笔误了.

作者: 爱卫生 时间: 2011-11-16 13:29:10

回复 Albert 的帖子

谢谢提醒。已更正。前者是Old RAI。不辛苦，呵呵！

作者: CC会成功 时间: 2012-2-12 12:12:24

请问一下，这个CI号是多少，从路由区更新请求中能看到小区号吗，如果能是哪一个？谢谢

作者: dong621 时间: 2012-2-12 16:21:56

写的真的是非常好，结合这个例子看协议RAU部分会理解的非常透彻

作者: Mr_Muscle 时间: 2012-2-13 11:29:36

视频加上版主的详细讲解，图文并茂，绘声绘色啊~
非常感谢版主的分享啊！

作者: vitner 时间: 2012-3-12 16:14:23

楼主还是比较强悍的

作者: xiaodong.hn 时间: 2012-3-20 15:11:41

很详细啊，楼主在GPRS这块的技术真的没啥说的了。

作者: imwoohan 时间: 2012-5-2 20:32:04

爱总，根据我观察，第6步GTP头里面的那个TEID 0x54000360 ,其实是第3步里面Old SGSN返回给New SGSN的PDP上下文里面的Up Link TEID Control Plane。也就是说，区间路由更新过程当中，New SGSN更新PDP上下文的时候必须用NSAPI和原PDP上下文的控制面TEID来标示GGSN里面的一个上下文是不？

作者: imwoohan 时间: 2012-5-2 20:33:52

还有，在GGSN里面PDP上下文的TEID必须都是唯一，即使SGSN不同，但是TEID（控制和用户）都必须唯一是不？？

作者: 爱卫生 时间: 2012-5-2 20:59:53

本帖最后由爱卫生于 2012-5-2 21:00 编辑

imwoohan 发表于 2012-5-2 20:32
爱总，根据我观察，第6步GTP头里面的那个TEID 0x54000360 ,其实是第3步里面Old SGSN返回给New SGSN的PDP上 ...

是的。因为这是上行方向控制面的TEID，是GGSN分配的。

另外，你13楼的问题和这个其实是一个问题。虽然发生了SGSN的切换，但这属于移动性管理，对GGSN来说，还是对应到同一个PDP上下文，因此GGSN不需要重新分配TEID给新的SGSN，因为是同一个PDP上下文，并且还没有释放。但下行方向的TEID要更新，因为SGSN变了，如果不更新，GGSN会将下行数据发给Old SGSN。

作者: imwoohan 时间: 2012-5-3 19:49:08

楼主，在new sgsn回复给old sgsn的sgsn context acknowledgement里面，有一个 Tunnel Endpoint Indentifier Data II ，里面有NSAPI: 5和一个TEID Data II: 0x06d00365，我看协议说这个TEID是old sgsn向new sgsn发送g-pdu数据时所用的用户面TEID。
我是不是可以理解成在用户上网过程当中，发生了inter-sgsn rau的话，切换的过程当中，old sgsn依旧有一段时间之内要通过这个TEID来向new sgsn来转发上网的数据的？
如果是的话，那请问什么时候才能停止数据的发送呢？

作者: 爱卫生 时间: 2012-5-3 20:42:07

回复 imwoohan 的帖子

是的。有数据要传。详见TS23.060 6.9.1.2.2章节：Inter-SGSN RAU流程的第5步。如下：

"The old SGSN duplicates the buffered N PDUs and starts tunnelling them to the new SGSN. Additional N PDUs received from the GGSN before the timer described in step 2 expires are also duplicated and tunnelled to the new SGSN. N PDUs that were already sent to the MS in acknowledged mode and that are not yet acknowledged by the MS are tunnelled together with the SNDCP N PDU number. No N PDUs shall be forwarded to the new SGSN after expiry of the timer described in step 2."

什么时候不传，如这段话所示，是在第2步中的timer来控制。这里说的第2步是指的old SGSN给new SGSN回应SGSN Context Response消息之后启动开计时器。原话是这么说的“The old SGSN starts a timer and stops the transmission of N-PDUs to the MS. ”，也就是old SGSN认为MS已经到了New SGSN那边，所以停止发送下行数据给MS，而是tunnel给new SGSN，由new SGSN发送。因此old SGSN也需要知道new SGSN侧Gn接口用户面TEID、地址信息。

作者: imwoohan 时间: 2012-5-3 21:21:04

回复爱卫生的帖子

The old SGSN duplicates the buffered N PDUs and starts tunnelling them to the new SGSN. Additional N PDUs received from the GGSN before the timer described in step 2 expires are also duplicated and tunnelled to the new SGSN. N PDUs that were already sent to the MS in acknowledged mode and that are not yet acknowledged by the MS are tunnelled together with the SNDCP N PDU number. No N PDUs shall be forwarded to the new SGSN after expiry of the timer described in step 2

原SGSN复制已经缓冲了的N PDU，并且开始想新SGSN传输它们。随后被GGSN接受到的N PDUS 在第二步所描述的定时器超时之前也会同样被复制并且传输给新的SGSN。那些已经通过确认模式发送给MS的和那些没有通过MS确认的 N PDU将会和SNDCP N PDU
number一起被传输。任何N PDUS都不会在第二步描述的定时器超时之后被传送。

"N PDUs that were already sent to the MS in acknowledged mode and that are not yet acknowledged by the MS are tunnelled together with the SNDCP N PDU number."
那些已经通过确认模式发送给MS的和那些没有通过MS确认的 N PDU将会和SNDCP N PDU
number一起被传输。这一句还不是很里了解。

作者: imwoohan 时间: 2012-5-4 11:02:04

爱总，我又仔细的看了一下你这篇帖子，第二步里面的 "根据Old RAI查询DNS服务器，可以得到对应的管理此RA的SGSN的IP地址。"，难道DNS服务器还有根据RAI定位SGSN的功能吗？
我的理解是RAI的查找应该是在SGSN上面配置了RAI分布，然后SGSN去查询这个配置，找到的。

作者: 爱卫生 时间: 2012-5-4 12:42:13

本帖最后由爱卫生于 2012-5-4 12:42 编辑

imwoohan 发表于 2012-5-4 11:02
爱总，我又仔细的看了一下你这篇帖子，第二步里面的 "根据Old RAI查询DNS服务器，可以得到对应的管理此RA的 ...

两者都可以。但大部分情况是在DNS上配置的，即DNS上需要配置RAI和SGSN IP的对应关系，方便New SGSN根据Old RAI找到Old SGSN，这样扩展性会强一些。你说的情况是SGSN在本地配置相邻的SGSN地址，也是可以的。

作者: hrbqby 时间: 2012-6-7 19:59:13

问一下版主:如何在一个GB口的抓包文件里,过滤出一个Session RAU的流程 request---->accept or request----->reject 是一个用户的 ?

作者: 爱卫生 时间: 2012-6-7 20:13:09

根据BSSGP层的TLLI来过滤吧。

作者: gege 时间: 2012-9-15 15:38:20

爱总，有个问题，New SGSN已经从Old SGSN那里得到了上行的控制面和用户面TEID，而这两个TEID都是GGSN之前分配好了的，所以我觉得在Update PDP Context Response消息中GGSN不用再为New SGSN分配新的用户面TEID了吧，你帖子里是否写错了？谢谢！

作者: hrbqby 时间: 2012-9-16 09:08:44

imwoohan 发表于 2012-5-4 11:02
爱总，我又仔细的看了一下你这篇帖子，第二步里面的 "根据Old RAI查询DNS服务器，可以得到对应的管理此RA的 ...

无疑问啊, INTER-RAU中根据OLD RAI 从DNS解析到原SGSN的GN 地址, 从而在GTP-C面有 SERVICE REQUEST/RESPONSE 的信令流程来继续RAU流程.

作者: yonka 时间: 2012-9-26 10:35:07

爱总，RAU消息流程中是不是没有专门的identity request而是在pdp context request（的响应）中一起获得用户的IMSI和PDP等？

作者: gaoyang_fei 时间: 2012-10-9 15:45:32

爱总。New SGSN给为UE提供服务的GGSN发送Update PDP Context Request消息的时候，消息头中的TEID哪里来的，我觉得是0x00000000更合理啊？因为之前没有在这个新SGSN和GGSN之间为MS建立上下文？非RAU的update流程是在update request中TEID沿用之前上下文的上行TEID，是非零合理（之所以关心这个是因为我可能需要找到update流程是因为RAU更新发起的，还是其他的原因？爱总能提供方法吗？）

作者: admin 时间: 2012-10-9 21:14:40

gaoyang_fei 发表于 2012-10-9 15:45
爱总。New SGSN给为UE提供服务的GGSN发送Update PDP Context Request消息的时候，消息头中的TE ...

设置为0不大合情理，因为从信令流程规范角度看，创建PDP上下文流程才会分TEID，所以最开始的create pdp context request里的头部TEID为全0，但更新PDP流程因为此时PDP已经创建，所以GTP头部TEID一定不能为全0，一定要是有值才行。本例中，New SGSN的GTP协议头部TEID值是从Old SGSN返回的SGSN Context Response消息中PDP Context IE中的Uplink TEID Control Plane IE得到的。

从GGSN的角度看，并不认为更换了SGSN，只是傻傻的认为是Old SGSN因为各种原因需要请求更换TEID（例如某块处理GTP的板卡坏了）。从这个角度看，GGSN应该区分不出来是RAU流程产生的update pdp context request。

后面那个问题你是说不结合信令流程报文上下文，只给一个update pdp context request消息的抓包，来判断是否是RAU产生的吗？这个貌似比较难吧。还没想好有没有什么好办法！

作者: yanxin267 时间: 2012-10-15 14:10:33

Hi请问下，发现最终给newSGSN给的上行Uplink控制和数据TEID分别是0x54000360和0x54000365，和oldSGSN给newSGSN返回的PDP Context中的给的上行Uplink控制和数据TEID一样，这么说inter RAU中到GGSN上行TEID都不变，对吧?

作者: 爱卫生 时间: 2012-10-15 16:25:47

是的。可以这么说。因为上行TEID是GGSN分配给SGSN的。不能由Old SGSN来决定变不变。变了的话那GGSN就不认了。New SGSN就需要根据Old SGSN提供的GGSN上行TEID来找到GGSN，GGSN根据这个TEID找到关联的用户GTP隧道。

作者: yanxin267 时间: 2012-10-25 22:34:02

爱卫生发表于 2012-10-15 16:25
是的。可以这么说。因为上行TEID是GGSN分配给SGSN的。不能由Old SGSN来决定变不变。变了的话那GGSN就不认了 ...

爱总，我看你视频中讲到第7步中这个“TEID Data I: 0x54000365”是这样说的：“这是GGSN给SGSN分配的用户面的TEID，而控制面中的TEID已经从前面PDP上下文中得到了。”
其实上行的用户面的TEID在第3步返回PDP上下文中也有啊，所以你的视频讲解让我误解了。我还以为“控制面中的TEID是从PDP上下文中得到，而用户面的TEID是GGSN新分配的，只是刚好重合而已！”

谢谢你帮我确认这个问题！也就是说“Inter-SGSN RAU中上行的TEID都不变，都可以从oldSGSN给newSGSN返回的PDP上下文中获得”。

作者: yanxin267 时间: 2012-10-25 22:39:03

还请问下，在第7步消息中写到“给New SGSN分配上行方向GGSN侧的控制面和用户面IP地址以及用户面的TEID”，这些好像在第3步返回的PDP上下文中都有的，是吧？

作者: 爱卫生 时间: 2012-10-26 00:43:14

yanxin267 发表于 2012-10-25 22:39
还请问下，在第7步消息中写到“给New SGSN分配上行方向GGSN侧的控制面和用户面IP地址以及用户面的TEID”，这 ...

是的。但因为跨了新的SGSN，GGSN可以在update pdp context response消息中给SGSN重新分配TEID和IP地址。

（本例只是没有重新分配新的TEID和IP地址，但是是可以重新分配的）。

作者: yanxin267 时间: 2012-10-26 10:22:14

本帖最后由 yanxin267 于 2012-10-26 10:29 编辑

爱卫生发表于 2012-10-26 00:43
是的。但因为跨了新的SGSN，GGSN可以在update pdp context response消息中给SGSN重新分配TEID和IP地址。 ...

用户面的TEID可以重新分配，而控制面的TEID不分配！明白了，谢谢！

作者: hendouse 时间: 2013-9-7 14:42:02

这份资料挺强大的，理论结合实际。问题是wireshark中如何把几个接口采集的信令文件合并在一起呢？

作者: lihongya66 时间: 2014-1-5 22:22:28

我想问下，如果用户跨SGSN，GGSN是否必须给用户重新分配一个新的用户IP地址？

作者: lihongya66 时间: 2014-1-7 18:47:32

我想问下。在现网多个APN的情况下，用户的IP能重复么？

如果能重复，那在GN口采集数据，怎么才能确定是一个用户的数据呢？

作者: 爱卫生 时间: 2014-1-9 00:08:25

lihongya66 发表于 2014-1-7 18:47
我想问下。在现网多个APN的情况下，用户的IP能重复么？

如果能重复，那在GN口采集数据，怎么才能确定是 ...

多APN情况，理论可以重复。但实际网络都是不重复的。如果要区分，可以通过GTP TEID，NSAPI等来区分。

作者: hannerson 时间: 2014-7-8 21:09:28

讲解的非常清楚，我是新手，谢谢爱总

作者: tge 时间: 2016-2-9 12:47:29

爱总，我想问一下，新的SGSN通过DNS查询旧SGSN地址时，如果这两个是跨省的怎么去寻找，本省的DNS不能把全国的信息全部配置了吧

欢迎光临 51学通信技术论坛 (http://51xuetongxin.com/bbs/)