Secondary PDP Context激活流程及实例

爱卫生

GPRS网络中的二次PDP上下文可以为更高优先级的业务申请更高的Qos。当GPRS演进到UMTS网络后，将会慢慢开放。   

本贴中，我们通过一个实例来了解一下GPRS网络中一个Secondary PDP Context(即同一个APN中，与Primary PDP Context共用同一个用户IP地址的其他PDP Context)的信令流程。这里仅根据抓包文件进行讲解。详细的流程请参考规范TS23.060的9.2.2.1.1章节。同时，本论坛也会在TS23.060规范版块进行相应的翻译。

首先，#1-#4为Primary PDP Context的激活过程。这部分的流程请参考本版块另外一个帖子“Primary PDP Context激活流程及实例 http://www.gprshome.com/forum.php?mod=viewthread&tid=239&extra=page%3D1 ”。因此，在#1-#4步骤中，已经为这个MS激活了一个PDP上下文。并且获得了一个用户IP地址为192.168.252.131（在#4包中的Create PDP Context Response消息的End User Address IE中可以看到）。   

#5是MS发给SGSN的Activate Secondary PDP Context Request，这里定义了一个新的NSAPI=6，用于区分Primary PDP Context(NSAPI=5),请求的QOS是因为Primary PDP Context一般对应于一些基础背景类业务（参加3GPP中关于QOS分类的定义），如HTTP业务，对QOS要求不高。但如果这个APN中还有一些其他如交互式业务和流媒体类的业务如Youtubu流媒体视频等，则需要较高的QOS，用原来Primary PDP Context中和网络侧协商的QOS来传递这种视频业务肯定有丢包或延迟降低用户体验，因为需要向网络侧申请一个更高的QOS，这个就是用专门的Secondary PDP Context Activation流程来进行申请。所以在这个包里携带的就是为某种业务类型（需要更高的QOS）所请求的QOS（包括MBR最大比特率等信息）。那具体是哪种业务呢，由下面的TFT（Traffic Flow Template)来说明，我们打开后发现，端口号是554，原来这是一个基于RTSP协议的流媒体视频业务。怪不得要更高的QOS。但这个激活请求中没有携带APN信息，这是因为Secondary PDP Context和Primary PDP Context是共用同一个APN，因此不需要再额外提供）。那Secondary PDP Context和Primary PDP Context既然是共用相同的用户IP地址，则需要建立相应的关联，怎么关联的呢？是通过Link TI字段进行关联。这里的值为00。这样网络侧也知道这个Secondary PDP Context是和哪个用户的Primary PDP Context关联了。就会使用相同的IP地址。   

#6 SGSN验证MS发过来的二次激活请求后，如果没有问题，将给GGSN发送Create PDP Context Request,包含了两个NSAPI（5和6），以及请求的QOS等信息，同样也没有APN的信息。同时SGSN会为这个Secondary PDP Context分配一个新的用户面TEID，但不会分配新的控制面TEID，因为控制面的TEID两者是共用的。而传递用户payload不一样，所以需要不同的用户面TEID来进行区分。另外，你还会发现，在这个请求消息中，并没有Selcetion Mode IE，因为不需要了，两个PDP上下文是公用同一个APN，所以不存在APN的选择问题。   

#7 GGSN验证SGSN发过来的激活请求，无误后，返回Create PDP Context Response。并携带支持的QOS、新分配的用户面TEID、GSN地址等信息、同时还分配了一个不同的Charging ID(0x09f437c8)用于对这个Secondary PDP Context对应的业务进行计费。但并没有为Secondary PDP Context分配新的用户IP地址。并且，再此步骤中，GGSN也不检查用户请求的APN等信息。   

#8 SGSN给MS返回Activate Secondary PDP Context Response消息。这里就有为Secondary PDP Context提供的协商后的QOS Profile。   

后续，MS就可以使用刚分配到的新的QOS Profile里面的QOS值（如更高的下载速率）来访问RSTP的流媒体视频了。

爱卫生

回复 zglaojiang 的帖子

   是的。可以这么说。更准确一点，是这样的。
   3GPP将PS中的业务分为4类。其中对QOS要求最低的就是Backgound类业务，例如普通的HTTP网页服务。而另外3类如流媒体等都是对QOS要求较高的。一般一个MS激活的第一个PDP Context叫做Primary PDP Context,一般就对应这种Backgound类业务，如果这个MS有个流媒体视频或IMS电话等其他业务需要一个更高的QOS，就需要发起建立另外一个PDP Context，就叫做Secoundary PDP Context。这两者的APN，用户IP地址都是一样的。但得到的网络侧的QOS支持是不一样的。

爱卫生

回复 zglaojiang 的帖子

   其实我觉得我也不是很聪明。顶多就算中等。但学习关键还是态度最重要。所以我还是很看好你的。
   但你说的关于协议栈的学习，其实这也算是一个基础学习，就像学外语要背单词一样，需要多花点时间和精力的。确实没有特别多的好的办法。但你可以结合信令流程来学可能会更有助理解。另外，关于配置的问题，建议你可以将配置命令进行分类，和相对应的协议栈进行映射，再用箭头将它们关联起来，可能会更好的记住它们。例如MTP3对应的命令是哪几条？SCCP对应的命令是哪几条？

爱卫生

回复 Dboyqiao 的帖子

应答：
1 在二次激活中，GGSN返回给SGSN的create PDP context response中是不是不包含控制面TEID？
   答：是的。不包含。请参考帖子中的8个报文。其中1-4对应这个MS的primary PDP context激活，5-8是紧接着的secondary PDP context的激活，在#7中，GGSN回的激活响应消息就没有包含控制面TEID。

2 是不是primary PDP context和secondary PDP context公用一个GGSN 控制面TEID？
   答：是的。这其实和第一题是同一个问题。

3 还有就是如果在二次激活中有Update PDP context procedure，那么GGSN 控制面TEID值会变化？
   答：没有任何变化，因为二次激活和Primary PDP Context是共用的相同的控制面TEID，那Update PDP context procedure也是属于控制面的流程，因此也会使用相同的TEID。知道PDP上下文被去激活。

4 关于这部分内容该从哪些协议查找？
   答：这部分的内容应参考两个。一个是TS23.060中介绍了PDP上下文的激活流程，以及二次激活的详细流程。另外一个是TS29.060，专门介绍GTP协议。

   其实你上面的四个问题正好是我在“测验和勋章中心”出的一道思考题相匹配。请参考：
http://www.gprshome.com/forum.php?mod=redirect&tid=241&goto=lastpost#lastpost  这个思考题是：
为什么Create PDP Context Request消息中,控制面TEID不是必选IE？  相信看了上面的解释之后，这道思考题的答案你应该知道了吧。

爱卫生

回复 chenhaonan 的帖子

   IPv4 address：254. 8. 64. 10是TFT的一部分。TFT通过IP包头五元组（IP地址，端口号，协议号）来区分不同的应用。这里的IPv4 address：254. 8. 64. 10代表应用层的服务器IP地址是10.64.8.254（要反过来）。再加上端口号554（RSTP流媒体服务端口号）。代表这是在10.64.8.254上的一个流媒体服务。这样在Gi口收到下行流量后，GGSN就可以通过这个TFT（IP地址+端口号）和二次激活PDP 上下文进行映射，从而可以转发给Gn接口，再加上TEID和NSAPI来再Gn接口标识PDP Context，这样就不会把本应发给Secondary PDP Context的下行数据发给Primary PDP Context，就不会乱了。
   还可以参考这篇帖子。PDP上下文详解

爱卫生

回复 pursuer 的帖子

   根据规范TS23.060，Update PDP Context Request在很多流程中都需要用到。例如Inter-SGSN RAU流程等。最主要的用途是SGSN需要向GGSN更新一些信息，这些信息最常见的主要有用户/控制面的TEID和IP地址、用户的QOS Profile等。
  可以参考这个链接看包详解带3GDT的PDP上下文激活流程。这个包当中就是在创建PDP上下文过程中用到了Update PDP Context Request消息，用于SGSN将RNC的用户面TEID和IP地址通过Update PDP Context Request消息给GGSN做一个更新。这样GGSN就可以直接和RNC建立用户面的GTP-U隧道了。
  帖子如果不详细你可以留言继续提问或者看相关的视频（在视频版块专区发布）。

爱卫生

回复 pursuer 的帖子

   没关系的。大家都是从新兵过来的。你说的BS是指什么？BSC吗？如果是在不同的BSC之间切换的话，这个流程叫做PS Handover。在TS43.129中有详细的定义。
   PS Handover有很多中场景，只有在Inter-SGSN/Inter-BSC的场景下，也就是这个切换，跨了不同的BSC，并且这两个BSC属于不同的SGSN管理。假设跨之前的SGSN叫Old SGSN,之后的SGSN叫New SGSN。才会有Update PDP Context Request消息产生。因为这种情况下，New SGSN需要通过GGSN更新下用户面的TEID和地址信息，否则下行数据GGSN仍然会发给Old SGSN。
   如何关联这个问题，首先在Old SGSN上肯定知道如何关联，因为Old SGSN在创建MS的PDP上下文的时候，就已经得到了GGSN这一侧用于建立GTP-C/GTP-U隧道的TEID和IP地址，然后和Update PDP Context消息进行关联就好了。因为Update PDP Context  Request消息也属于GTP-C的消息，所以和Create PDP Context Request使用相同的GTP-C的TEID和IP地址。
   但问题是New SGSN不知道，那这实际上是Old SGSN要把GGSN相关的信息通知New SGSN。
   在PS Handover流程中，规范定义分成两个阶段。第一个阶段是准备阶段，目的是为MS的到来在New 节点中预留资源。第二个阶段是执行阶段，开始实际的切换。其中在准备阶段Old SGSN会给New SGSN发送"Forward Relcocation Request"消息给New SGSN，在这个请求消息中就会携带MS的MM/PDP上下文信息给New SGSN，这里面就包含了GGSN这一侧的GTP-C/GTP-U隧道的TEID和IP地址信息，从而实现了关联。

爱卫生

回复 pursuer 的帖子

两个问题哈。
1 Create PDP Context request 的控制面TEID是和Create PDP Context response的TEID相同的，（也就是说，将以后的用户TEID都放在这个控制面TEID隧道中进行传输，不知道这样理解对不对？）。
   答：这个是不对的。这两个消息里的TEID是完全独立，完全不同，没有任何关联的。其中Create PDP Context request 里的控制面 TEID是由SGSN分配的，分配给GGSN使用。而Create PDP Context response里的TEID是由GGSN分配的，给SGSN使用。你使用了我分配的TEID，我才能识别出来。否则我就不认识这个GTP隧道。就像甲乙两人是同学，互相串门。甲把自己的小区门禁卡给乙，乙就可以进甲的小区。甲如果来拜访乙的话，同样，乙也可以把自己小区的门禁卡给甲。这样甲就可以进来了。这两张卡是完全不相干的。就是说如果甲拿着自己小区的门禁卡去开乙的小区门，肯定也是打不开的。具体你可以参考另外一篇帖子：GTP协议循序渐进（三）----通过实例了解TEID。

2 那么Update PDP Context request的TEID和谁的控制面TEID相同？那Update PDP Context response呢？Delete PDP Context request的以及Delete PDP Context response呢？也不知道这样问 的是不是有问题？还望指点一下？
   答：这里有一个原则。在创建PDP上下文的流程中，SGSN和GGSN会分别通过Create PDP Context Request/Response消息来给对方分配控制和用户面的TEID和IP地址。（但是在SGSN发给GGSN的第一个控制面消息即Create PDP Context Request消息里的TEID为全0，因为这个时候GGSN还没有分配TEID给SGSN。）在接下来所有SGSN和GGSN之间的控制面消息都会使用相同的TEID和地址，直到这个PDP上下文被去激活。也就是说在后来可能发生了很多的Update PDP Context Request/Response消息，但都是用的同一个TEID，直到这个PDP上下文被通过Delete PDP Context Request/Response消息被去激活。然后下次再激活将重新分配TEID。
       所以，这里，Update PDP Context Request的TEID，将和GGSN在Create PDP Context Response消息中分配给Old SGSN的控制面TEID相同。这个TEID将由Old SGSN在PS Handover过程中，通过"Forward Relcocation Request"消息传给New SGSN。这样New SGSN就可以使用这个TEID作为控制面的TEID和GGSN进行通信，既然是控制面，当然也就包括了Update PDP Context Request消息。
     “那Update PDP Context response呢？Delete PDP Context request的以及Delete PDP Context response呢？”这个问题请参考第一个问题的答案。

爱卫生

hendouse 发表于 2011-6-18 15:39
在PDP激活后的一系列过程，用户面的TEID号是经常变化的吧？而如果变化，是不是因为用户请求的业务不同了才会变化的呢？

   PDP激活后，用户面的TEID不会变化，直到这个用户的PDP上下文被去激活。但GSN节点可以通过PDP Context Modification流程（对应的消息是Update PDP Context Request/Response)在PDP激活后、PDP去激活之前的这段期间发起给TEID、GSN IP地址或Qos的修改。但一般更新用户面的TEID和用户的业务类型无关。通常发生在Inter-RAU流程期间，New SGSN去向GGSN更新用户面的TEID和IP地址，否则如果不更新，GGSN将把下行数据仍旧发给Old SGSN。

爱卫生

imwoohan 发表于 2012-9-3 15:36
ip地址写反了，应该算是wireshark的一个bug不？？

基本上可以这么理解吧。不光是primary还是secondary的PDP激活，下行方向，GGSN都不需要给SGSN下发TFT。TFT是由UE报告给SGSN，再由SGSN报告给GGSN，用于下行方向用户数据到达时区分不同的PDP上下文的，没有必要GGSN由发回给SGSN。

爱卫生

这个和手机终端有关。但现网可能很多地方并没有打开PDP上下文二次激活功能。我用的是索爱的。
是在实验室捕获的。但触发二次激活还是跟手机有关。也和并编写的应用APP有关系应该。

爱卫生

hou3331 发表于 2013-8-7 14:53
爱总，假如先在LTE上激活default eps bearer和dedicated eps bearer，然后redirect到UMTS网络上，SGSN cont ...

不用这么复杂。其实这个LTE-UMTS的切换场景，MME和SGSN之间的交互，和inter-SGSN RAU场景中两个SGSN之间的交互是类似的。发的消息都是sgsn context request/response消息。只不过前面的场景还要做EPS bearer到pdp上下文的映射。我们就以inter-sgsn rau流程为例来说吧，我个人觉得要区分primary和secondary pdp context还是比较容易的。因为sgsn context response消息的pdp context IE中包含了NSAPI和TI还有TEID，我个人觉得就可以区分了，因为在old sgsn上也是通过这几者的关系来区分primary和secondary的（我查了下规范，规范确实好像没提TI和NSAPI必须要从小到大顺序分配，但通常都是这样来分的。例如primary pdp context的nsapi=5，TI=0）。另外，由于primary和secondary是共用APN、GTP-C TEID和UE的IP地址等资源，只要设备检查哪个pdp上下文里不包含UE的IP、APN等就可以判断出这是个secondary pdp上下文了。

爱卫生

chrisniu1984 发表于 2013-11-20 13:20
GGSN区分用户数据走哪个PDP Context是靠用户面的TEID区分呢还是GGSN返回应道时分配不同的GGSN IP呢？

因 ...

已经放开权限，可以下载了。

GGSN区分用户数据走哪个PDP Context是靠用户面的TEID区分呢还是GGSN返回应道时分配不同的GGSN IP呢？

用户面的TEID和GTP-U IP地址都要看的。用户面和控制面板的TEID和IP地址是独立分配的。