51学通信技术论坛
标题: Secondary PDP Context激活流程及实例 [打印本页]
作者: 爱卫生 时间: 2011-5-1 12:47:04 标题: 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规范版块进行相应的翻译。
[attach]3046[/attach]
首先，#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 时间: 2011-5-1 14:29:30
Secondary PDP 激活就是一个APN激活多个PDP上下文，每次QOS不一样，是这个意思吗？
作者: 爱卫生 时间: 2011-5-1 18:10:21
回复 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 时间: 2011-5-1 18:18:48
回复 爱卫生 的帖子
谢谢版主，总是感觉每次听你讲了以后理解就更容易。真的。另外我还想请教版主一个问题，就是协议栈我不知道怎么去看，因为配置数据是根据协议栈配的嘛，每一层怎么处理，什么目的，我总是头晕晕的。别人说我智商低，版主有没有好的方法推荐。
作者: 爱卫生 时间: 2011-5-2 08:33:10
回复 zglaojiang 的帖子
其实我觉得我也不是很聪明。顶多就算中等。但学习关键还是态度最重要。所以我还是很看好你的。
但你说的关于协议栈的学习，其实这也算是一个基础学习，就像学外语要背单词一样，需要多花点时间和精力的。确实没有特别多的好的办法。但你可以结合信令流程来学可能会更有助理解。另外，关于配置的问题，建议你可以将配置命令进行分类，和相对应的协议栈进行映射，再用箭头将它们关联起来，可能会更好的记住它们。例如MTP3对应的命令是哪几条？SCCP对应的命令是哪几条？
作者: zglaojiang 时间: 2011-5-2 23:07:08
回复 爱卫生 的帖子
谢谢版主，有你这几句话足够。
作者: Dboyqiao 时间: 2011-5-20 22:26:53
你好，请教一下，在二次激活中，GGSN返回给SGSN的create PDP context response中是不是不包含控制面TEID？是不是primary PDP context和secondary PDP context公用一个GGSN 控制面TEID？还有就是如果在二次激活中有Update PDP context procedure，那么GGSN 控制面TEID值会变化？（关于这部分内容该从哪些协议查找？）
作者: 爱卫生 时间: 2011-5-20 23:34:30
回复 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 时间: 2011-5-26 09:45:01
请问爱卫生，二次激活抓包中MS发给SGSN的active pdp context request消息中的TFT中的IPv4 address：254. 8. 64. 10怎么解释，它在后续中起到什么作用？
作者: 爱卫生 时间: 2011-5-26 10:11:44
回复 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 时间: 2011-6-8 09:56:08
看了以上的，以及链接到其他地方上的知识，感叹一声收益丰厚啊。我现在有个问题，是关于Update PDP Context request以及Update PDP Context response与Create PDP 之间的关联性是怎样的？想请教一下 版主亦或是大家，请不吝赐教。理论说也可以，如果带有示例就更锦上添花了。先谢谢了。
作者: 爱卫生 时间: 2011-6-8 10:16:00
回复 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 时间: 2011-6-8 10:45:12
回复 爱卫生 的帖子
刚才看了一下，我是新兵，不知道这里还有一个Update PDP 信息，也略微懂得了一些。但，若是我一个MS在一定时间段内（比如5分钟）我由一个BS切换到另一个BS去，会不会也产生一个Update信息啊？那这个是如何与Create PDP关联上的？这个不太懂。
作者: 爱卫生 时间: 2011-6-8 11:12:04
回复 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 时间: 2011-6-8 13:33:59
回复 爱卫生 的帖子
应该就是你所说的那种PS Handover吧。
能不能提供具体的关联关系。比如
Create PDP Context request 的控制面TEID是和Create PDP Context response的TEID相同的，（也就是说，将以后的用户TEID都放在这个控制面TEID隧道中进行传输，不知道这样理解对不对？）。
那么Update PDP Context request的TEID和谁的控制面TEID相同？那Update PDP Context response呢？Delete PDP Context request的以及Delete PDP Context response呢？也不知道这样问 的是不是有问题？还望指点一下？
作者: 爱卫生 时间: 2011-6-8 16:08:08
本帖最后由 爱卫生 于 2012-10-18 20:50 编辑
回复 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:06
回复 爱卫生 的帖子
PDP去激活后 控制面的TEID号才取消，那在PDP激活后的一系列过程，用户面的TEID号是经常变化的吧？而如果变化，是不是因为用户请求的业务不同了才会变化的呢？
作者: 爱卫生 时间: 2011-6-18 15:46:33
本帖最后由 爱卫生 于 2011-6-18 15:47 编辑
hendouse 发表于 2011-6-18 15:39 
在PDP激活后的一系列过程，用户面的TEID号是经常变化的吧？而如果变化，是不是因为用户请求的业务不同了才会变化的呢？
作者: chnmyying 时间: 2011-9-9 09:54:37
看了大家的留言很有收获
作者: qiandl 时间: 2011-11-16 22:25:41
看完后很受启发，谢谢版主，真心感谢！
作者: 小丙张嘎 时间: 2012-6-8 11:45:23
对我这种小白，一定要认真看帖子，多谢分享。
作者: imwoohan 时间: 2012-9-3 15:36:14
爱卫生 发表于 2011-5-26 10:11 
回复 chenhaonan 的帖子
IPv4 address：254. 8. 64. 10是TFT的一部分。TFT通过IP包头五元组（IP地址，端 ...
ip地址写反了，应该算是wireshark的一个bug不？？
对你的回答还是有个疑问:
1.为什么主PDP上下文激活的时候，GGSN给SGSN的回复里面没有TFT呢？难道是在GGSN里面，没有TFT关联的PDP上下文都被它标示为主PDP，然后收到数据的话，就直接回复给主PDP上下文？
作者: 爱卫生 时间: 2012-9-3 21:45:35
imwoohan 发表于 2012-9-3 15:36
ip地址写反了，应该算是wireshark的一个bug不？？
基本上可以这么理解吧。不光是primary还是secondary的PDP激活，下行方向，GGSN都不需要给SGSN下发TFT。TFT是由UE报告给SGSN，再由SGSN报告给GGSN，用于下行方向用户数据到达时区分不同的PDP上下文的，没有必要GGSN由发回给SGSN。
作者: hrbqby 时间: 2012-10-9 16:12:07
爱卫生 发表于 2012-9-3 21:45
基本上可以这么理解吧。不光是primary还是secondary的PDP激活，下行方向，GGSN都不需要给SGSN下发TFT。TF ...
请问版主是怎样触发的secondary PDP?
作者: hrbqby 时间: 2012-10-10 09:35:57
hrbqby 发表于 2012-10-9 16:12
请问版主是怎样触发的secondary PDP?
我的问题是在现网中是不是很好触发SP? what is the type of your test phone ?
不知道版主提供的抓包文件时实验室的还是现网中捕获的?
作者: 爱卫生 时间: 2012-10-10 21:17:19
这个和手机终端有关。但现网可能很多地方并没有打开PDP上下文二次激活功能。我用的是索爱的。
是在实验室捕获的。但触发二次激活还是跟手机有关。也和并编写的应用APP有关系应该。
作者: sonic1822 时间: 2012-10-18 19:27:37
爱版，我看了一下 request好像都是sgsn发起的啊 下面这段话是不是说反了？
其中Create PDP Context request 里的控制面 TEID是由GGSN分配的，分配给SGSN使用。而Create PDP Context response里的TEID是由SGSN分配的，给GGSN使用。
作者: imwoohan 时间: 2012-11-28 22:56:31
爱总，我想问下，primary pdp里面，如果gtp-c和gtp-u的TEID相同的话，数据的传输可以通过udp端口号来区分的。那请问，secondary pdp的gtp-u teid和primary的gtp-u gtp-c的teid，这三者能不能完全相同呢？
作者: hijake 时间: 2012-12-14 14:11:30
爱总，请教个问题，如果使用3gnet上网的同时，发一个彩信，也就是同时用3gwap激活，这种情况下GTP-C TEID不同不属于二次激活？
作者: ithinc 时间: 2013-1-31 14:20:05
大家来谈谈Create Secondary PDP Context Request消息里的Linked NSAPI参数是否是冗余信息？一条GTP隧道里第二次以上Create PDP总是Secondary，而隧道TEID就可以确定所有相关信息，似乎可以不需要Linked NSAPI？
作者: hycl5410 时间: 2013-2-1 00:30:36
ithinc 发表于 2013-1-31 14:20
大家来谈谈Create Secondary PDP Context Request消息里的Linked NSAPI参数是否是冗余信息？一条GTP隧道里第 ...
从逻辑上来讲，似乎确实如楼上所说。我想了好久也没有想出这样一种场景--当linked nsapi不存在，理论上GGSN就没法正确判断。因为secondary pdp建立的GTP-C消息是发向已有的GGSN侧C-TEID的，该C-TEID是跟该APN&pdp地址下的第一个PDP的NSAPI有一一对应关系。
但是从内部实现来讲，也许显式的指定linked nsapi会更加有效率和避免出错？
不管如何，29.060（R6）明确写了这句话
For contexts created by the Secondary PDP Context Activation Procedure the SGSN shall include the linked NSAPI. Linked NSAPI indicates the NSAPI assigned to any one of the already activated PDP contexts for this PDP address and APN.
所以真要是较真的话，就只能去找3GPP讨论了
作者: zs622 时间: 2013-4-16 15:04:44
这个要顶一下，先学习。
作者: vicai 时间: 2013-4-17 17:47:22
很详细，谢谢楼主了，但关于Linkedin TI的作用还不是特别明白，因为好像Linkedin TI只在Activate Secondary PDP context Request里出现了。
作者: vicai 时间: 2013-4-18 09:56:11
vicai 发表于 2013-4-17 17:47
很详细，谢谢楼主了，但关于Linkedin TI的作用还不是特别明白，因为好像Linkedin TI只在Activate Secondary ...
Hi，admin，谢谢你的答复，我也知道Linked TI是用来关联primary和secondary，这样secondary在激活的过程中不用带apn等等信息，节约资源，但它具体是怎么关联的我还是不太清楚。因为在“Secondary PDP Context激活流程.pcap”这个抓包里，Linkedin TI只在第二次Activate Secondary PDP Context Request这条信息里出现,在Linkedin TI这个IE里有个TI Value=0，请问下是不是这个TI value就用来对应primary的，但问题又来了，在激活primary context的过程中就没出现过TI这个IE呀（从抓包里找的话）。
第2个问题，Activate PDP Context Request就是从MS到SGSN，也就是说在那个抓包里192.168.210.10就应该是MS的地址，但在第一个Activate PDP Context Accept的PCO里带了一个IP(192.168.252.131)，而这个IP又是GGSN(通过radius或DHCP)分配给手机的PDP address，以后手机上网就用192.168.252.131了，但192.168.210.10这个IP是怎么一回事咧。
第3个问题，关于Transaction ID（TI），我在哪里看见对它的描述有一句是(is used as NSAPI in some circumstances),也就是它有时是被当成NSAPI用的，但NSAPI从最开始的Activate PDP Context Request就有了，并且在以后的每条GTP-C信息里都有，也就是说NSAPI是一直存在的，那为什么还要搞个TI出来。
呵呵，我是个刚学习GPRS的菜鸟，问题比较多，提前谢谢你了哈。
作者: admin 时间: 2013-4-18 21:10:35
vicai 发表于 2013-4-18 09:56
Hi，admin，谢谢你的答复，我也知道Linked TI是用来关联primary和secondary，这样secondary在激活的过程中 ...
不客气。多交流。呵呵~以下是我的理解。
Hi，admin，谢谢你的答复，我也知道Linked TI是用来关联primary和secondary，这样secondary在激活的过程中不用带apn等等信息，节约资源，但它具体是怎么关联的我还是不太清楚。因为在“Secondary PDP Context激活流程.pcap”这个抓包里，Linkedin TI只在第二次Activate Secondary PDP Context Request这条信息里出现,在Linkedin TI这个IE里有个TI Value=0，请问下是不是这个TI value就用来对应primary的，但问题又来了，在激活primary context的过程中就没出现过TI这个IE呀（从抓包里找的话）。
答：有的。在primary context激活的最后一个消息activate pdp context accept消息的protocol discriminator里有一个TIO，就是它。规范里是这么说的：“The SGSN selects Radio Priority and Packet Flow Id based on QoS Negotiated, and returns an Activate PDP Context Accept (PDP Type, PDP Address, TI, QoS Negotiated, Radio Priority, Packet Flow Id, Protocol Configuration Options) message to the MS. ”还有“ Linked TI indicates the TI value assigned to any one of the already activated PDP contexts for this PDP address and APN. ”
第2个问题，Activate PDP Context Request就是从MS到SGSN，也就是说在那个抓包里192.168.210.10就应该是MS的地址，但在第一个Activate PDP Context Accept的PCO里带了一个IP(192.168.252.131)，而这个IP又是GGSN(通过radius或DHCP)分配给手机的PDP address，以后手机上网就用192.168.252.131了，但192.168.210.10这个IP是怎么一回事咧。
答：192.168.210.10是Gb接口BSC侧的service IP，不是MS的地址。Activate PDP Context Request激活还没完成，MS还没分到地址。192.168.252.131才是分配给MS的IP地址。
第3个问题，关于Transaction ID（TI），我在哪里看见对它的描述有一句是(is used as NSAPI in some circumstances),也就是它有时是被当成NSAPI用的，但NSAPI从最开始的Activate PDP Context Request就有了，并且在以后的每条GTP-C信息里都有，也就是说NSAPI是一直存在的，那为什么还要搞个TI出来。
答：不一样，NSAPI通常是区分PDP上下文的。取值4个bit。看报文里secondary PDP激活的时候Gn接口也就有两个NSAPI。规范中TI的作用定义如下：“The TI allows to distinguish up to 16 different bi-directional messages flows for a given PD and a given SAP. Such a message flow is called a transaction.”用于区分MS的不同上层消息的，比如会话管理消息有很多，比如激活、去激活、修改等消息，都有TI的出现。
作者: vicai 时间: 2013-4-19 13:13:24
呵呵，很详细很受用，太谢谢了。
作者: decembersn 时间: 2013-6-4 19:48:47
最近正好在学习GTP流程，学习了。
作者: hou3331 时间: 2013-6-9 14:18:57
是否可以告知下，触发secondary pdp时用到的终端型号，怎么使用业务的？我现在做不出来。
作者: 皮特栋 时间: 2013-6-24 11:49:32
为什么下载不了附件啊
作者: 皮特栋 时间: 2013-6-24 17:52:42
皮特栋 发表于 2013-6-24 11:49
为什么下载不了附件啊
好的，多谢啊
作者: 皮特栋 时间: 2013-6-27 08:58:57
非常有用，感谢爱总分享！
作者: lonxhg 时间: 2013-7-5 11:36:30
大补啊。。。版主值得敬仰
作者: ttyy2528 时间: 2013-7-11 16:10:15
Linkedin TI 是儿子标识. NSAPI 是排行, 6是大儿子,7是二儿子,依次类推.呵呵.
作者: bai.x 时间: 2013-7-20 20:44:55
为什么我用wireshark打开包后，#2、#3、#6、#7这四条信令都只解到NS层呢，只显示PDU type：Unknown（0x32），有没有人遇到这种情况？
作者: zzz 时间: 2013-7-25 21:19:09
hijake 发表于 2012-12-14 14:11
爱总，请教个问题，如果使用3gnet上网的同时，发一个彩信，也就是同时用3gwap激活，这种情况下GTP-C TEID不 ...
请问一下版主，手机有两个APN，一个CMNET，一个CMWAP。假设手机使用微博时是用CMNET，但用某个APP时是会切换成CMWAP的（APPl控制采用哪个接入点）按这种情况看在Gn口应该是先发起删除PDP，然后创建PDP，就算网络支持二次PDP激活也不会发起二次激活。要是这样子这两个APP交替使用那就会频繁发起PDP创建，PDP删除了对吗？另外PDP二次激活中是否会给手机分配另一个IP地址呢？这方面很困惑望能解答一下！
作者: hou3331 时间: 2013-8-7 14:45:24
zzz 发表于 2013-7-25 21:19
请问一下版主，手机有两个APN，一个CMNET，一个CMWAP。假设手机使用微博时是用CMNET，但用某个APP时是会切 ...
你说的意思是first pdp和second pdp，在激活cmwap时，会得到一个新的ip，并且不会去激活原来的pdp。和secondary pdp概念是不一样的。
作者: hou3331 时间: 2013-8-7 14:53:15
本帖最后由 hou3331 于 2013-8-7 15:11 编辑
爱总，假如先在LTE上激活default eps bearer和dedicated eps bearer，然后redirect到UMTS网络上，SGSN context response消息中携带的TIO=0,1并没有Linked NSAPI，该如何判断哪个属于primary pdp，哪个属于secondary pdp呢？
碰到的问题是： 当sgsn向UE发送modify pdp context request后，TIO=0成功了，TIO=1 回复sm status：“SM Cause: Message type not compatible with the protocol state (98)”，然后UE开始去激活TIO=1（tear down=0）， 为何PGW会把2个pdp都同时去激活了？
作者: 爱卫生 时间: 2013-8-7 20:25:29
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上下文了。
作者: hou3331 时间: 2013-8-8 09:58:00
本帖最后由 hou3331 于 2013-8-8 10:00 编辑
hou3331 发表于 2013-8-7 14:53
爱总，假如先在LTE上激活default eps bearer和dedicated eps bearer，然后redirect到UMTS网络上，SGSN cont ...
昨天一直上传不了，现在好了。是不是很多终端都无法支持secondary pdp的？使用高通8960芯片。
作者: hycl5410 时间: 2013-8-8 16:53:20
hou3331 发表于 2013-8-7 14:53
爱总，假如先在LTE上激活default eps bearer和dedicated eps bearer，然后redirect到UMTS网络上，SGSN cont ...
爱总，假如先在LTE上激活default eps bearer和dedicated eps bearer，然后redirect到UMTS网络上，SGSN context response消息中携带的TIO=0,1并没有Linked NSAPI，该如何判断哪个属于primary pdp，哪个属于secondary pdp呢？
个人理解不需要Linked NSAPI，NSAPI即可。也就是说，这两个PDP其实是对等的，不像4G里一定要有default bearer。事实上，SGSN context response 也不可能带Linked NSAPI，因为压根就没有定义这个IE。
碰到的问题是： 当sgsn向UE发送modify pdp context request后，TIO=0成功了，TIO=1 回复sm status：“SM Cause: Message type not compatible with the protocol state (98)”，然后UE开始去激活TIO=1（tear down=0）， 为何PGW会把2个pdp都同时去激活了？
从对NSAPI=6 （TIO=1）的modify dpd req里，感觉qos不太对，既不是从4G map过来的negotiated，也不是向GGSN update的qos。可能手机无法接受这样的qos，即使规范里确实定义了。
比如这种 Reliability class: Unacknowledged GTP/LLC/RLC, Unprotected data (5) ，从来都没在现网中见到。
至于PGW/GGSN去激活所有PDP，从抓包里看不出什么原因，因为也没有gx，gy或者radius等外部网元的信令交互。
可以确定的是，旧MME发给SGW的delete session req是没问题的。OI=0，SI=1，delete只会终结在SGW上。
作者: tonyztao 时间: 2013-8-16 15:56:53
新手上路，收获颇多！
作者: fenye123 时间: 2013-9-23 10:01:02
谢谢版主，有你这几句话足够
作者: chrisniu1984 时间: 2013-11-20 13:20:46
GGSN区分用户数据走哪个PDP Context是靠用户面的TEID区分呢还是GGSN返回应道时分配不同的GGSN IP呢？
因为没有权限下载数据包，没法去研究，只能在这里问问题了。
作者: 爱卫生 时间: 2013-11-20 20:57:26
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地址是独立分配的。
作者: levidoudou 时间: 2013-12-15 23:15:37
非常感谢楼主的细心和专业解答，看了受益良多！
作者: hou3331 时间: 2014-1-16 23:21:20
本帖最后由 hou3331 于 2014-1-20 15:22 编辑
hycl5410 发表于 2013-8-8 16:53
爱总，假如先在LTE上激活default eps bearer和dedicated eps bearer，然后redirect到UMTS网络上，SGSN co ...
H00000000000000000000000
作者: hou3331 时间: 2014-1-16 23:36:14
24008 8.4章节中的NOTE: The use by GMM and SM of unacknowledged LLC may lead to messages "not compatible with the protocol state".，该怎么解释哦
作者: ccc123 时间: 2014-2-9 16:53:48
OK.........
作者: hust104 时间: 2014-4-13 00:14:51
仔细看了2条 response里的QOS，没有发现有差异哦。secondary PDP里 response回的QOS哪里跟Primary PDP里的QOS不一样了？
作者: 奥格威 时间: 2014-5-8 15:06:40
对初学者很有用
作者: xiongyang 时间: 2014-5-15 14:35:28
LZ 问下大牛，发AT指令如何激活二次PDP呢？我可以通过发AT激活主PDP，但是二次的激活不了。
万分感激
作者: ouwangqiu 时间: 2014-6-22 13:56:49
多谢爱总制作和分享
作者: ouwangqiu 时间: 2014-6-22 13:57:59
学习了，不错，谢谢版主分享
作者: maqizhao 时间: 2014-8-3 23:07:42
我已深深爱上这个地方了,在成为专家之前坚决不撤退!
作者: ccc123 时间: 2014-8-12 19:41:39
非常非常感谢
| 欢迎光临 51学通信技术论坛 (http://www.51xuetongxin.com/bbs/) |
Powered by Discuz! X2 |