Secondary PDP Context激活流程及实例

ithinc

大家来谈谈Create Secondary PDP Context Request消息里的Linked NSAPI参数是否是冗余信息？一条GTP隧道里第二次以上Create PDP总是Secondary，而隧道TEID就可以确定所有相关信息，似乎可以不需要Linked NSAPI？

hijake

爱总，请教个问题，如果使用3gnet上网的同时，发一个彩信，也就是同时用3gwap激活，这种情况下GTP-C TEID不同不属于二次激活？

imwoohan

爱总，我想问下，primary pdp里面，如果gtp-c和gtp-u的TEID相同的话，数据的传输可以通过udp端口号来区分的。那请问，secondary pdp的gtp-u teid和primary的gtp-u gtp-c的teid，这三者能不能完全相同呢？

sonic1822

爱版，我看了一下 request好像都是sgsn发起的啊 下面这段话是不是说反了？
其中Create PDP Context request 里的控制面 TEID是由GGSN分配的，分配给SGSN使用。而Create PDP Context response里的TEID是由SGSN分配的，给GGSN使用。

爱卫生

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

hrbqby

hrbqby 发表于 2012-10-9 16:12
请问版主是怎样触发的secondary PDP?

我的问题是在现网中是不是很好触发SP? what is the  type of your test phone ?


不知道版主提供的抓包文件时实验室的还是现网中捕获的?

hrbqby

爱卫生 发表于 2012-9-3 21:45
基本上可以这么理解吧。不光是primary还是secondary的PDP激活，下行方向，GGSN都不需要给SGSN下发TFT。TF ...

请问版主是怎样触发的secondary PDP?

爱卫生

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

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

imwoohan

爱卫生 发表于 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上下文？

小丙张嘎

对我这种小白，一定要认真看帖子，多谢分享。

qiandl

看完后很受启发，谢谢版主，真心感谢！

chnmyying

看了大家的留言很有收获

爱卫生

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。

hendouse

回复 爱卫生 的帖子

PDP去激活后 控制面的TEID号才取消，那在PDP激活后的一系列过程，用户面的TEID号是经常变化的吧？而如果变化，是不是因为用户请求的业务不同了才会变化的呢？

爱卫生

回复 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呢？”这个问题请参考第一个问题的答案。

pursuer

回复 爱卫生 的帖子

应该就是你所说的那种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呢？也不知道这样问 的是不是有问题？还望指点一下？

爱卫生

回复 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

回复 爱卫生 的帖子

刚才看了一下，我是新兵，不知道这里还有一个Update PDP 信息，也略微懂得了一些。但，若是我一个MS在一定时间段内（比如5分钟）我由一个BS切换到另一个BS去，会不会也产生一个Update信息啊？那这个是如何与Create PDP关联上的？这个不太懂。