看包详解带3GDT的PDP上下文激活流程

爱卫生

    关于3GDT的原理，在论坛中有几篇帖子介绍了。可以参考3GDT技术帖子以及现网经验分享中也有3GDT的部署和经验分享。这里的话，我们主要通过一个抓包实例来加强对3GDT技术下的PDP激活流程的理解。
  3GDT的信令流程图如下所示：

   在看对应的抓包之前，有必要了解下物理和逻辑拓扑图，这样我们看抓包才能看得更清晰明白。拓扑图如下：

   对应的包如下：

   下面我们来看一下对应的建立步骤，和理论上介绍的流程对比一下，看是否一致：

（注：我们在这里只重点关注3GDT的建立过程，至于PDP上下文激活请参考版块中有专门的PDP激活实例介绍”。

1）UE发起PDP激活请求给SGSN，RNC收到后加上RANAP层的信息，并将UE的这个NAS PDU作为直传消息(Direct Transfer)传递给SGSN。并加入了RAI和SAI等位置信息告知SGSN。其中OPC8194为RNC的，DPC为1030是SGSN的。

2）SGSN收到UE的PDP激活请求后，进行相应的检查。如果没有问题，将发送Create PDP Context Request消息给GGSN，发给GGSN的目的IP为172.17.5.41，这是GGSN上的GTP-C地址，SGSN需通过DNS解析得到。这个请求消息里还为GGSN分配了用于下行方向信令和数据传递的SGSN地址和TEID信息。

   其中分配的控制面信息为：

   SGSN IP:192.168.60.1 TEID为：0x2d300705

         分配的用户面信息为：

  SGSN IP:192.168.60.11 TEID为：0x2d300785。

3）GGSN收到后，确认没有问题。给SGSN回应Create PDP Context Response。在里面，同样GGSN也给SGSN分配了用于上行流量和信令的GGSN地址和TEID信息。

   其中分配的控制面信息为：

   GGSN IP:172.17.5.42 TEID为：0x5c001310

         分配的用户面信息为：

  GGSN IP:172.17.5.50 TEID为：0x5c001315。  

  并且为UE分配了一个IP地址为：10.23.192.2。

4）SGSN开始请求RNC建立对应的RAB用于用户面的承载。发送RAB-Assignment消息给RNC，在这个消息里，SGSN将把GGSN分配的用户面地址和TEID信息告诉RNC，即172.17.5.50和ox5c001315。包含在transportlayerinformation IE中（点开#4或号包能看到）。因此RNC就可以在RAB建立后开始发送上行数据了。直接将上行数据发送到这个地址和TEID对应的GTP-U隧道中就可以了。

5）RNC建立RAB并且给SGSN回应RAB-Assignment Response。点开RANAP层后，你就可以看到RNC将自己用户面的地址和TEID告诉了SGSN。这里分别是：10.36.90.6和0x00000067。

6）因为要建立直接隧道，所以SGSN要把RNC对应的用户下行数据的TEID和IP告诉GGSN，用于下行用户数据的发送。因此SGSN给GGSN发送Update PDP Context Request消息，里面包含了从第5步获知的RNC用于下行方向用户面地址和TEID。

7）GGSN收到后，更新下行方向地址和TEID信息，本来应该是在第3步里收到的用户面信息为：

  SGSN IP:192.168.60.11 TEID为：0x2d300785。将替换成第6步中更新的值10.36.90.6和0x00000067。当然，GGSN并不知道实际上和自己建立GTP-U隧道的已经不是SGSN，而变成RNC了。SGSN再此使用了金蝉脱壳的计谋，自己逃了。GGSN回应Update PDP Context Response消息进行确认。(GGSN其实还是知道的，在Update PDP Context Request消息中有DTI标志位为1代表使用了3GDT）。

8）SGSN给RNC回送Activate PDP Context Accept消息。来确认关于这个UE的PDP上下文的成功建立。并且携带了GGSN分配给UE的IP地址。

DreamHeart

版主总结的很好！赞

二雷

赞一个

再睡一夏

爱总，怎么样才能获得权限

奥格威

非常详细，很适合新手理解。

hyl_4955

版主解释的很专业  功力深厚 虽然刚接触GPRS核心网不久，但是看版主的文章，图文并茂，还有抓包可供参考，感觉很容易就理解了

gaozhongbao

请问爱总，3GDT现网用的多吗？谢谢~

paul

版主，我想学习一下，没权下载附件啊，帮帮忙啊

beck17

学习下！

zyzai605

非常感谢，搞明白了

admin

admin 发表于 2012-9-25 20:39
这段话是这么理解的： 预置条件： 1）基于3GDT的PDP上下文已经激活。 2）UE开始发送和接收数据，RNC和GGS ...

不好意思，上面的说法有点不正确。文字已经更正。

查了下规范23007，这种场景下RNC发送error indication，并不是RNC的用户面出现了什么问题。而是RNC收到了下行方向GGSN侧的用户数据，但某种原因RNC侧的RAB已经释放了，RNC采取的操作时丢弃该下行数据并发送error indication给GGSN。通过该指示，还可以通知GGSN fallback到非3GDT的环境下。原文如下：“

When the RNC/BSC receives a GTP U PDU for which no RAB context exists, the RNC/BSC shall discard the GTP U PDU and return a GTP error indication to the originating node that may be SGSN or GGSN if Direct Tunnel is established.”

如果是SGSN的话，SGSN也应丢弃该下行PDU并发送error indication通知GGSN。“When the SGSN receives a GTP U PDU from the GGSN for which no PDP context exists, it shall discard the GTP U PDU and send a GTP error indication to the originating GGSN.”

GGSN也是一样的。“When the GGSN receives a GTP U PDU for which no PDP context exists, it shall discard the GTP U PDU and return a a GTP error indication to the originating node (the SGSN or, if Direct Tunnel is established, the RNC).”

如果是UE正在发送上行数据的情况下出现了这种事，那GGSN将通知SGSN错误指示，SGSN将因此去激活PDP上下文，MS也要去激活PDP上下文。原文：“When the GGSN receives a tunnel PDU for which no PDP context exists it discards the tunnel PDU and sends an Error indication message to the originating SGSN. The SGSN deactivates the PDP context and sends an Error indication to the MS. The MS may then re-activate the PDP context.”

admin

yonka 发表于 2012-9-24 22:34
In case of a pre-release 7 GGSN, error indications from the RNC are treated as if they came from the ...

这段话是这么理解的：

预置条件：

1）基于3GDT的PDP上下文已经激活。

2）UE开始发送和接收数据，RNC和GGSN之间传送用户数据。

3）GGSN发送下行数据给RNC，但RNC发现没有对应的RAB对应。RNC丢弃该GTP-U PDU并通过GTP-U的Error Indication通知GGSN。

- 这时，如果该GGSN是3GPP R7版本之前的，那么它是不支持3GDT的（3GDT是在3GPP R7才有的）。因此，RNC送过来的用户面error indication，GGSN仍将认为是SGSN送过来的（因为R7之前的GGSN认为控制和用户面都是和SGSN通信，而没有RNC），因此既然认为是SGSN送过来的，那自然不会再通知SGSN了。这样就可能导致该PDP上下文已经在GGSN侧被释放，而SGSN侧由于没有得到任何通知，所以还认为这是一个有效的PDP上下文。这就叫hanging的PDP上下文。SGSN和GGSN上的状态不同步了。

- 如果该GGSN是3GPP R7之后的，那是支持3GDT的，所以能够分别出该错误指示是RNC发过来的。因此，GGSN将通知SGSN做相应的处理，PDP上下文不会释放。但SGSN收到通知后会将RAB释放掉。

yonka

In case of a pre-release 7 GGSN, error indications from the RNC are treated as if they came from the SGSN, and the GGSN deletes the PDP context without informing the SGSN. This results in a hanging PDP context in the SGSN and User Equipment (UE), which is resolved at the next connection establishment.

With a release 7 GGSN, the PDP context is not deleted but the SGSN is informed and the Radio Access Bearer (RAB) can be reestablished.

Therefore during an ISRAU, the SGSN checks if the GGSN supports 3GDT based on 3GPP release 7, using the optional Private Extension Information Element (IE) in the Forward Relocation Request and SGSN Context Response messages. If there is no optional Private Extension IE, it means the GGSN does not support 3GDT based on 3GPP release 7 or the old SGSN does not support the optional Private Extension IE, therefore 3GDT is not used.


在R7之前的GGSN中，来自RNC的错误指示error indication会被认为来自SGSN，于是GGSN会删除PDP上下文并且不会通知SGSN。这样会导致SGSN和MS中会吊死（该）PDP上下文。这个问题会在下一次连接建立时解决。

    对于R7 GGSN，该PDP上下文不会被删除，不过会通知SGSN，RAB可以重新建立。

    因此在ISRAU中，SGSN可以检查GGSN是否支持R7的3GDT，方式是在Forward Relocation Request和SGSN Context Response消息中使用可选的私有扩展IE。    如果没有可选的私有扩展IE的话，就意味着GGSN不支持R7的3GDT或者老的SGSN不支持该可选私有扩展IE，于是就不会使用3GDT。


爱总你看这段怎么理解？
虽然翻译出来了，但还是有些不理解。

R7之前GGSN收到错误指示会删除PDP上下文？
“对于R7 GGSN，该PDP上下文不会被删除，不过会通知SGSN，RAB可以重新建立。”怎么理解？

yuws

这个比较新鲜啊

爱卫生

imwoohan 发表于 2012-4-23 16:06
回复 爱卫生 的帖子

爱总，你这篇文章里面说到的SGSN分配的数据(I)TEID和控制面TEID好像说反了。

是的。呵呵，你谦虚了。已经改正更新。谢谢！

imwoohan

回复 爱卫生 的帖子

爱总，你这篇文章里面说到的SGSN分配的数据(I)TEID和控制面TEID好像说反了。
数据(I)TEID好像是G-PDU的下行TEID，应该是GTP-U的TEID才是，而控制面的TEID，也就是TEID Control Plane才是GTP-C的TEID吧？
在您的附件里面SGSN发给我们的wireshark抓包里面

TEID Data (I)是 0x2d300785
TEID Control Plane是0x2d300705
本人新手学习中，冒昧的怀疑下您。

Mr_Muscle

讲解得非常地直观明了，感谢版主的总结和分享！

xiaomaobei

太经典了！非常感谢！很详细啊。