GTP协议中的Teardown Indicator IE及实例

samsin

楼主， 好啊， 我下到一篇文档， 关于 primary and secondary PDP 的 生命期和销毁的说明 ， 分享一下，今天早晨刚下的。。{:soso_e100:}

爱卫生

回复 samsin 的帖子

  非常感谢啊。昨天你回复后，我就一直在找相关的说明，但可惜没找到。呵呵，多谢了！较真好啊，这样我也可以得到提高啊。
很多地方我的理解也不够准确，你不指出来我就一直按照错误的观点理解。那就麻烦了，呵呵！
  在你的附件中，找到了这句话应该可以证明Primary和Secondary应该是可以独立去激活的。（其实是23060中的原话，可我没找到，汗！）"Each PDP context for PDP address can be deactivated independently when one or more PDP contexts exist for PDP address。"
   另外，关于这篇帖子涉及到的一些内容，我总结一些，欢迎补充和“较真”哈。
   假设用户同时激活Primary和Secondary，则：
1 这两个PDP上下文在创建时会分配两个不同的NSAPI以及两个不同的Transacation ID，但Secondary PDP Context将通过Linked TI和Primary进行关联，达到共享PDP地址还有控制面TEID的目的。
2 在去激活的时候，分两种情况：
(1) MS发起的：
   MS必须要携带Teardown Indicator，取值可以为0可以为1。SGSN收到后，在给Delete PDP Context Request消息里也要复制过来，携带相同的Teardown Indicator以及相应的Transacation ID。如果Teardown Indicator取值为0的话，则只讲Transacation ID指明的PDP Context去激活，可以是Primary也可以是Secondary，取决于Transacation ID的值。
(2) GSN发起的：
    在发送Delete PDP Context Request消息时，如果关于这个PDP地址只剩下最后一个PDP上下文与之关联，则需要将Teardown Indicator置为1，方便对方GSN节点回收相应的资源。

samsin

楼主，太客气了，我向你，向各位专家也学了好多{:soso_e100:}

samsin

1 这两个PDP上下文在创建时会分配两个不同的NSAPI以及两个不同的Transacation ID，但Secondary PDP Context将通过Linked TI和Primary进行关联，达到共享PDP地址还有控制面TEID的目的。

楼主，你好，红色部分“共享 sgsn control teid、ggsn control teid”，这个方面有规范说明吗？ 谢谢额

stucoco

回复 samsin 的帖子

暂时没找到，以后再碰到可以传上来看一下。不过看样子这个问题有定论了，向各位高手学习了。

爱卫生

samsin 发表于 2011-11-13 15:50
楼主，你好，红色部分“共享 sgsn control teid、ggsn control teid”，这个方面有规范说明吗？ 谢谢额

  谢谢，这个有的。依据主要来自几个方面。可参考附件的CR---"Clarification on the use of TEID in the GTP header"。
  里面讲TS29.060里Create PDP Context Request/Update PDP Context Request消息里的IE "Tunnel Endpoint Identifier Control Plane"从"Mandatory"全部改成了"Conditional"。并且加上了注解：" The Tunnel Endpoint Identifier Signalling field specifies a downlink Tunnel Endpoint Identifier for signalling messages which is chosen by the SGSN. The GGSN shall include this Tunnel Endpoint Identifier in the GTP header of all subsequent downlink signalling messages which are related to the requested PDP context. This field shall not be present if there already exists a signalling tunnel for the given MS between the peer GSNs."
  信令流程实例版块有二次激活的抓包，也验证了这一点。供参考。

samsin

楼主，你好，谢谢额， 我觉得： This field shall not be present if there already exists a signalling tunnel for the given MS between ”the peer GSNs.“， 这个“the peer GSNs”，
如果说 secondary PDP的创建一定要走primary PDP创建时的 “老路”， 两个控制teid值同，我同意，因为SGSN的 控制IP,GGSN控制IP都同，这样teid才算是真正相同或者说比较teid相同才有意义，而决不是两个简单的值同，就像RAI和RAC关系一样。
那么这样一来，为啥 创建PDPrequest里的 SGSN address For signaling、For user traffic还是必须IE呢？是条件IE不是可以吗 ，Update PDP也一样。
还有就是，假设secondary 和primary 控制面上的 SGSN SIGNALING IP+SGSN control TEID同， 那么我更新PDP时，如果我只想更新NSAPI为6的PDP context的 sgsn control teid，是否primary 也 跟着改了，如果跟着改了显然不合适，不跟着改又违背了 “共享teid一说”， 所以还请楼主，给看看，这个问题，该如何？
请各位专家，也分析分析。
谢谢哦

爱卫生

回复 samsin 的帖子

  不好意思，你的这段话我没有完全理解，“因为SGSN的 控制IP,GGSN控制IP都同，这样teid才算是真正相同，而决不是两个简单的值同，就像RAI和RAC关系一样。”能再详细说下吗？
  另外你的两个问题，我是这么理解的。
1 SGSN address For signaling、For user traffic在规范里定成必选的IE，而没有像控制面TEID定义成Conditional的。我觉得理论上可以这么定。但规范只所以这么定，我猜是为了实现IP承载网的负荷分担，也就是强制SGSN在创建PDP上下文的时候，可以为不同的PDP上下文分配不同的控制和用户面IP地址，这样多个PDP上下文就可以走不同的IP路径，达到在IP承载网里负荷分担的目的。但TEID不影响流量走向，只是GSN本地识别用，所以是有条件的。
2 只是猜测哈。会不会是有厂家向3GPP建议，也就是同一个用户，不管有多少个PDP上下文，都在同一个GTP业务板上处理？但出GSN的流量，这多个PDP上下文可以走不同的路由板出达到负荷分担？这样有利于厂家的业务实现？3GPP考虑了厂家的研发方便，所以采纳了？因为如果上述成立的话，那这个GTP业务板假设重启了，可能就会给GGSN发送多个Update PDP Context Request消息，将所有PDP上下文的TEID全部更新一遍，就不存在你所说的问题了。否则的话，其实Update PDP Context Request消息实际上无法区分Primary还是Secondary PDP Context的，因为只有NSAPI，但又不能肯定说NSAPI=5一定是primary，大于5就一定是Secondary，规范里好像并没有说NSAPI一定要按顺序分配吧。那如果这样，即使我想更新Primary PDP Context的TEID，我也是无法办到的。除非是将所有的PDP上下文的TEID全部更新一遍。
  当然，规范确实有不优化的地方，各厂家每年都会提交很多优化方案申请专利，你也可以写一个啊，呵呵！

samsin

谢谢楼主， 你的回复让我好好看了几篇规范，好好理解后，才敢来回复。
你的回复中的也说了，teid是本地识别用，我的理解是：teid是GSN分配的（在规范中使用了，selected、chosen一词），换言之teid只在该分配GSN节点服务范围可用。那我们为啥还要比较teid值在primary和secondary 是相同的呢？岂不是我们已经局限在  “This field shall not be present if there already exists a signalling tunnel for the given MS between the peer GSNs.“中描述的 那条已经存在的信令通道吗？ 这就是 我说的 比较“完整的teid值”的意思，在比较teid的时候，先要比较GSN IP，后比较teid， 这个我在工作中用到。

另外对与创建PDP中的 SGSN address For signaling、For user traffic你说是为 load sharing，我同意，但在primary pdp 和 secondary pdp情形中，为 secondary而发起create pdp时，因为 它要走existing signaling tunnel for the MS，所以在这个情况下
我认为可以不带SGSN address，可以让承载层使用控制面IP, gtp 层可以不带 sgsn address啊， 即该字段可以定以为 conditional 才更合适啊。

还有就是，我在切换SGSN的时候，突然发起activate secondary pdp，因为这个时候也会有 update primary pdp 发生，所以 该如何保证 我的 secondary pdp 仍然走那条 existing signaling tunnel for the MS？

多谢楼主！

爱卫生

samsin 发表于 2011-11-23 07:11
谢谢楼主， 你的回复让我好好看了几篇规范，好好理解后，才敢来回复。
你的回复中的也说了，teid是本地识别 ...

  说实话。你说的这几个问题都比较深，我没有把握一定说的对，只能说下我的理解。先说前面两个问题吧：
1 “这就是 我说的 比较“完整的teid值”的意思，在比较teid的时候，先要比较GSN IP，后比较teid。”我不确定是否理解了你的问题。我假设你的问题是，只有GSN IP相同并且TEID相同，这才是相同的一条GTP Tunnel，不知道这样理解你的问题对吗？或者说你认为如果两个GTP Tunnel的TEID-C相同，但GSN IP不同，也是两个不同的GTP隧道？
  如果是这样，我个人感觉应该和GSN IP无关。GTPV0的时代，TID=NSAPI+IMSI，所以通过TID就能够唯一的对应Gn接口上的每个GTP Tunnel是和哪个用户的哪个PDP上下文对应的。但GTPV1的时代，TEID和NSAPI、IMSI无关了。那我认为用于区分Gn口上的GTP Tunnel应该是TEID+NSAPI可以唯一的区分，但和GSN Address无关。所以，我感觉不一定要GSN IP相同，再去比较TEID才有意义。因为GSN IP虽然是GTP协议里的IE，但实际最终是在IP承载层来使用的，和上层的GTP应该是无关的。
2 "SGSN Address"做为conditional的IE，我其实也同意你的观点。觉得理论上primary和secondary共享控制面的SGSN IP是没有问题的，就像共享TEID-C一样。但之所以没有定义为conditional，我觉得理由和第1个问题的答案类似。也就是说CR提到"existing signaling tunnel for the MS"，这个已经存在的tunnel是通过TEID来标识的，而和SGSN GTP-C IP无关。既然不通过SGSN GTP-C IP来标识这个已经存在的信令隧道，自然也就不能复用相同的IP了。个人理解，呵呵！我觉得也能说得过去。而且我也总感觉SGSN Address相当于是一个承载层，在厂家设计板卡的时候，只需要定义一个IP Host处理IP协议栈即可，而TEID则涉及到GTP协议的处理，两者的开发成本也是不一样的。后者要贵很多，感觉设计上可以是处理GTP协议栈的板卡将SGSN Address分配好后，通过背板发布给处理SGSN Address的IP Host板卡处理。相当于用户面和控制面的内部分离。有点想当然了，呵呵！

爱卫生

samsin 发表于 2011-11-23 07:11
谢谢楼主， 你的回复让我好好看了几篇规范，好好理解后，才敢来回复。
你的回复中的也说了，teid是本地识别 ...

第三个问题“我在切换SGSN的时候，突然发起activate secondary pdp，因为这个时候也会有 update primary pdp 发生，所以 该如何保证 我的 secondary pdp 仍然走那条 existing signaling tunnel for the MS？”。
   这个问题我觉得倒不用担心。因为RAU没做完，MS的activate secondary pdp请求应该是没办法做的。首先，按照我的理解，RAU是附着的子集，它不光是做位置更新，实际上还有在新的RA对MS的身份确认和网络注册登记，包括对MS要分配一个新的P-TMSI。但我没找到规范里的明确说明，要完成RAU流程才能去做PDP激活。
  但退一步来讲，即使RAU流程还没做完，MS发起的二次PDP激活，也是会被New SGSN直接拒绝的。因为它已经来到了新的RA，是由New SGSN服务，那在二次PDP激活请求中，携带的很多个IE，在New SGSN上都是找不到对应关系的。包括Tlli、Linked TI、Requested NSAPI等等。因为P-TMSI要在RAU完成后才能分配，这样New SGSN才能识别这个用户，从而接受它的二次激活请求，另外，Linked TI、Requested NSAPI这些IE也是在Old SGSN传给New SGSN的PDP上下文IE中才有。如果没有完成RAU流程，New SGSN也是无法识别的。因此，我觉得结论是，当在做Inter-SGSN RAU切换SGSN时，MS同时发起了二次PDP激活请求，会被New SGSN立即拒绝，因为有不认识的IE。所以，这个问题我觉得不用担心。

爱卫生

回复 samsin 的帖子

  关于第三个问题再补充一点。你的担心应该是用户已经有一个active的PDP上下文到了一个新的RA（由不同的SGSN负责）发起Inter-SGSN RAU的场景把。流程摘过来如下：

    你应该是担心是做第9步给GGSN发送Update PDP Context Request时，如果这时New SGSN收到了MS的二次激活请求怎么和Primary PDP Context的TEID的绑定问题。因为这时，MS的Primary PDP Context是active的。

   仔细看下第3步Old SGSN给New SGSN回的SGSN Context Response消息里的PDP Context IE就会发现，里面只有Uplink TEID for Control，而没有Downlink TEID for Control，前者是GGSN分配给Old SGSN用于上行方向信令的发送，后者则是Old SGSN给GGSN分配的用于下行方向信令发送。但在SGSN Context Response消息里的PDP Context IE里，Old SGSN根本就没有将自己分配的用于下行方向的控制面TEID告诉New SGSN（它觉得传过去没有任何意义，反正New SGSN需要重新分配的，老的TEID将作废），因此New SGSN实际上并不存在更新MS的PDP上下文中的控制面TEID的问题。如果这时New SGSN收到了MS的二次激活请求，也假设New SGSN通过从Old SGSN过来的MM Context的信息能够识别出这个MS，那它只需要重新将自己分配给GGSN的控制面TEID（也就是在Update PDP Context Request）消息里的TEID和MS的Secondary PDP Context所需要的控制面TEID做个绑定就可以了，应该就不会乱了。因为这个控制面TEID是重新分配的，和原来Old SGSN分配的无关。

samsin

谢谢楼主，第三个问题，我非常同意你的观点。
再说一下，我对第一个问题的理解，
1、我上文说的也有问题，是这样：我是站在 好多个 GN口之外说的 的 tunnel的唯一性，所以要加上分配GSN节点的控制IP。
2、GTPV1中，imsi+NSAPI仍然能唯一表示一个PDP，比如在创建PDP 请求中 可以表示一个未来的PDP。规范在创建PDP中：

The IMSI informationelement together with the NSAPI information element uniquely identifies the PDPcontext to be created. 在这种表示下不需加GSN 的控制IP。

3、TEID+NSAPI 可以唯一表示一个PDP，规范在 upatePDP 请求中， 其实也使用于删除PDP，但应该不适应创建PDP。

The NSAPI informationelement together with the Tunnel Endpoint Identifier in the GTP headerunambiguously identifies a PDP Context in the GGSN.

The NSAPI informationelement together with the Tunnel Endpoint Identifier in the GTP headerunambiguously identifies a PDP Context in the SGSN.

4、再说 imsi+NSAPI,和 TEID+NSAPI的区别，个人认为imsi+nsapi是从使用PDP的角度来描述tunnel的唯一性，不管是在SGSN中还是GGSN中。而TEID+NSAPI是从 建立PDP的角度来描述tunnel的唯一性即用分配的TEID资源，二者都唯一表示了一个tunnel； 再说GTPV0到GTPV1的INTER-SGSN RAU 的情况，不正是靠imsi+nsapi 这个强大的表示才让GGSN 找到了 那个相关的 V0 PDP 的吗？

爱卫生

回复 samsin 的帖子

  谢谢！我们的观点基本上是一致的。
  最后你提到的IMSI+NSAPI还是TEID+NSAPI来标识一个PDP上下文。我个人的理解是这要看具体的场景。这两者都可以在GTPV1时代来唯一标识一个PDP上下文。区别就是，如果在Gn接口的GTP-C消息中，如果有IMSI这个IE，则用前者，如果没有，则用后者来标识一个PDP上下文。
  例如：TS29060规定，IMSI这个IE在Create PDP Context Request消息中是Conditional的，并且只能在创建Primary PDP Context的时候出现，引用如下“When using the Secondary PDP Context Activation Procedure, the Selection mode, IMSI, MSISDN, End User Address, Access Point Name and APN Restriction information elements shall not be included in the message.” 但IMSI这个IE在Update PDP Context Request消息中又是可选的。也就是说并不是所有的GTP-C消息都有IMSI传递，那这时候就只能用TEID+NSAPI来唯一标识某个用户的某个PDP上下文了。我仔细想想也是，Gn接口的会话建立确实和IMSI没多大关系，带上IMSI很多情况是给GGSN及后台的计费系统提供一个参考。

samsin

谢谢，我非常同意你的观点，再提一下imsi+nsapi，我说的第四点
，实现了某个PDP V0到V1的跳跃标识（常见用在更新pdp中），为什么呢？因为它的角度不同，
它是从 使用者来说的：是我这个imsi专用的tunnel、并且是第1个哦，所以用我表示就是myimsi+5了，实际上这个很有意义。不得不佩服3GPP，尽管协议给革命了，但标识还可以继续有效，真的不简单。呵呵，说说心得。

gpf_gprs2012

围观学习，膜拜大家

gaoyang_fei

爱卫生 发表于 2011-5-1 10:04
回复 Albert 的帖子

    呵呵。是这样。首先，如果MS做PDP二次激活，GGSN不会分配新的地址。而是使用原来 ...

del resp 中没有teardownInd字段，是什么情况，这个主上下文中没有过secondary pdp context 的创建？

爱卫生

gaoyang_fei 发表于 2012-10-25 11:48
del resp 中没有teardownInd字段，是什么情况，这个主上下文中没有过secondary pdp context 的创建？

没有啊。delete pdp context response消息中本来就没有teardownInd字段啊。因为不需要啊，只要在delete request消息中指明要去激活的PDP上下文就可以了。

以下是规范中关于delete pdp context response消息的定义：

Table 12: Information Elements in a Delete PDP Context Response

Information element	Presence requirement	Reference
Cause	Mandatory	7.7.1
Protocol Configuration Options	Optional	7.7.31
User Location Information	Optional	7.7.51
MS Time Zone	Optional	7.7.52
Private Extension	Optional	7.7.46