51学通信技术论坛

标题: 看包详解带3GDT的PDP上下文激活流程 [打印本页]

作者: 爱卫生 时间: 2011-6-3 14:28:17 标题: 看包详解带3GDT的PDP上下文激活流程

本帖最后由爱卫生于 2012-4-23 19:21 编辑

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

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

[attach]426[/attach]

对应的包如下：[attach]428[/attach]

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

（注：我们在这里只重点关注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地址。

作者: weishengzi 时间: 2011-7-27 16:01:03

精辟啊，太精辟了

作者: zhenjiucuo 时间: 2011-7-28 00:26:07

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

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

------------------个人理解，GGSN是知道的。因为Update PDP Context Request中DTI置位。

作者: 爱卫生 时间: 2011-7-28 06:34:29

本帖最后由爱卫生于 2011-7-28 06:37 编辑

有道理。GGSN确实应该知道。谢谢指正！

作者: afeizai 时间: 2011-8-28 21:23:11

本帖最后由 afeizai 于 2011-8-28 21:29 编辑

这个是3GDT的PDP激活，如果非DT的流程是怎么样？是如下的步骤吗：
1）UE发起PDP激活请求给SGSN，RNC收到后加上RANAP层的信息，并将UE的这个NAS PDU

作为直传消息(Direct Transfer)传递给SGSN。并加入了RAI和SAI等位置信息告知SGSN

2）SGSN收到UE的PDP激活请求后，进行相应的检查。如果没有问题，将发送Create

PDP Context Request消息给GGSN，发给GGSN的目的IP，这是GGSN上的GTP-C地址，

SGSN需通过DNS解析得到。这个请求消息里还为GGSN分配了用于下行方向信令和数据传递的SGSN地址和TEID信息。

3）GGSN收到后，确认没有问题。给SGSN回应Create PDP Context Response。在里面

，同样GGSN也给SGSN分配了用于上行流量和信令的GGSN地址和TEID信息。并且为UE分配了一个IP地址。

4）SGSN开始请求RNC建立对应的RAB用于用户面的承载。发送RAB-Assignment消息给

RNC，在这个消息里，sgsn将为自己分配另外一个TEID，并将TEID和用户面IP告诉RNC。

5）RNC建立RAB并且给SGSN回应RAB-Assignment Response。点开RANAP层后，你就可以

看到RNC将自己用户面的地址和TEID告诉了SGSN。

至此，RNC->SGSN->GGSN的双Tunel就建立起来了

作者: 爱卫生 时间: 2011-8-29 10:51:40

回复 afeizai 的帖子

对。我个人觉得你的说明完全正确。关于不带3GDT的PDP激活流程，可以参考6.2版块，有相应的实例。
另外，补充一点就是，在创建PDP上下文激活时，SGSN和GGSN除了给对方分配用户面TEID和IP地址外，还要分配控制面的TEID和IP地址，这样GTP-C和GTP-U就分别对应到不同的GTP Tunnel了。

作者: afeizai 时间: 2011-8-29 13:47:20

谢谢斑竹的耐心解答。可确定的是SGSN和GGSN之间的双隧道,一个C的，一个U的。但，SGSN和RNC之间为什么为什么不是给的两个TEID呢，信令和用户面不分离吗？另外，我想知道是，针对R5的，SGSN上的PDP上下文中是不是应该有3个TEID，两个for GGSN(Gn)，一个for RNC(IuPS).

作者: 爱卫生 时间: 2011-8-29 13:54:19

回复 afeizai 的帖子

1 但，SGSN和RNC之间为什么不是给的两个TEID呢，信令和用户面不分离吗？
答：只用分一个。因为SGSN和RNC控制面不是用的GTP协议，而是RANAP协议，因此只需要分配一个用户面TEID。

2 另外，我想知道是，针对R5的，SGSN上的PDP上下文中是不是应该有3个TEID，两个for GGSN(Gn)，一个for RNC(IuPS).
答：是的。

作者: afeizai 时间: 2011-8-29 14:58:47

谢谢斑竹！！

作者: afeizai 时间: 2011-8-29 21:05:51

那mscserver和Mgw的信令用户面分离也与DT类似吗,能否看到对比呢

作者: 爱卫生 时间: 2011-8-29 21:28:10

回复 afeizai 的帖子

msc-server和MGW上的控制用户面的分离，是从节点级进行分离。是硬件上的分离，即将传统的MSC拆分成MSC-S和MGW两个实体。这和3GDT还不一样。3GDT并没有将SGSN的用户和控制面进行拆分。只是相当于采用软件逻辑的方式，将用户流量bypass SGSN。但在3GPP R8以后，由于PS业务的不断增长，对SGSN也进行了物理上的拆分。其中SGSN的控制面叫做MME(Mobility Management Entity)，用户面叫做SGW(Serving-Gateway)。如果你感兴趣，可以关注下论坛的版块14 EPC演进的包交换核心网。

作者: jmt110 时间: 2012-2-10 10:26:51

3GDT的理解比较经典了，学习了，谢谢！

作者: xiaodong.hn 时间: 2012-3-28 11:19:43

很详细，希望以后多发些这样的帖子。

作者: xiaomaobei 时间: 2012-4-7 18:03:37

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

作者: Mr_Muscle 时间: 2012-4-7 23:32:01

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

作者: imwoohan 时间: 2012-4-23 16:06:27

回复爱卫生的帖子

爱总，你这篇文章里面说到的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
本人新手学习中，冒昧的怀疑下您。

作者: 爱卫生 时间: 2012-4-23 19:22:30

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

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

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

作者: yuws 时间: 2012-7-25 13:07:52

这个比较新鲜啊

作者: yonka 时间: 2012-9-24 22:34:54

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可以重新建立。”怎么理解？

作者: admin 时间: 2012-9-25 20:39:09

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释放掉。

作者: admin 时间: 2012-9-25 21:08:14

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.”

作者: zyzai605 时间: 2012-12-28 14:07:48

非常感谢，搞明白了

作者: beck17 时间: 2013-3-30 23:11:53

学习下！

作者: paul 时间: 2013-8-17 10:11:29

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

作者: gaozhongbao 时间: 2013-9-5 15:17:07

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

作者: hyl_4955 时间: 2014-5-7 16:10:05

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

作者: 奥格威 时间: 2014-5-8 13:50:31

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

作者: 再睡一夏 时间: 2014-8-20 12:55:47

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

作者: 二雷 时间: 2015-1-9 15:10:48

赞一个

作者: DreamHeart 时间: 2015-9-22 10:18:55

版主总结的很好！赞

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