一个较完整的Inter-SGSN RAU实例(除Gr接口)

爱卫生

   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所示。

图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所示。

图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所示。

图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所示。

图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所示。

图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所示。

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

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

tge

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

hannerson

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

爱卫生

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

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

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

lihongya66

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

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

lihongya66

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

hendouse

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

yanxin267

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

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

爱卫生

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

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

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

yanxin267

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

yanxin267

爱卫生 发表于 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上下文中获得”。

爱卫生

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

yanxin267

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

admin

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产生的吗？这个貌似比较难吧。还没想好有没有什么好办法！

gaoyang_fei

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

yonka

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

hrbqby

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

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

gege

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