一个较完整的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更新流程。

gengyangsdtm

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

Albert

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

爱卫生

回复 Albert 的帖子

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

Albert

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

爱卫生

回复 Albert 的帖子

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

CC会成功

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

dong621

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

Mr_Muscle

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

vitner

楼主还是比较强悍的

xiaodong.hn

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

imwoohan

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

imwoohan

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

爱卫生

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

楼主，在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来转发上网的数据的？
如果是的话，那请问什么时候才能停止数据的发送呢？

爱卫生

回复 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

回复 爱卫生 的帖子

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

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