Secondary PDP Context激活流程及实例

本贴中，我们通过一个实例来了解一下一个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激活流程及实例  ”。因此，在#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的流媒体视频了。