GTP协议中的Teardown Indicator IE及实例

爱卫生

   Teardown Indicator这个IE用来指示，共用同一个PDP地址的所有的PDP上下文是否都要去激活（例如primary和secondary PDP上下文）。当这个IE置1时，将指示GSN节点将所有共用同一个PDP地址的所有的PDP上下文都去激活。如果这个IE值为0或没有携带这个IE，则指示GSN节点仅将在Delete PDP Context Request消息中指明的这个NSAPI对应的PDP上下文删除即可。在MS发起的去激活流程中，这个IE由MS产生，SGSN应将这个IE复制到Delete PDP Context Request消息中传给GGSN。
  下面我们来看一个实例。

  在这个例子中，我们会看到两个Delete PDP Context Request消息，是SGSN请求GGSN删除对应的PDP上下文，对应的流程是PDP上下文去激活流程。这是两个PDP Context，但实际上这两个PDP Context是属于同一个MS的。一个是Primary PDP Context，用NSAPI=5标识，对应的是#3和#4包。另一个是Secondary PDP Context，用NSAPI=6标识，对应的是#1和#2包。这两个PDP Context是共用的同一个MS地址。也就是说，Secondary PDP Context的激活，GGSN不会分配新的IP。
  下面，我们来看下关于这两个PDP Context去激活的时候，Teardown Indicator的设置。
  #1和#2的包是关于Secondary PDP Context的去激活，Teardown Indicator设置为0.这样就会通知GGSN只将在这个Delete PDP Context Request消息中指明的PDP上下文（由NSAPI=6指明），而不会将属于这个MS的其他PDP Context删除。#3和#4的包是关于Primary PDP Context的去激活，Teardown Indicator设置为1，这样就会通知GGSN将属于这个MS的所有PDP上下文全部删除。当然这个时候，在MS上只有一个Active的PDP上下文了，也就是这个Primary PDP Context，所以也无所谓。
  通过这个实例我们也可以了解到终端的一些行为。不同终端的行为可能不一样。所以经常需要很多测试啊。
  最后，附上关于Teardown Indicator IE的字段说明。它总共2个字节。1个字节为type。另一个字节的7个bit是保留的。只有1个bit是有效位，用于Teardown的指示。所以在#1中，Teardown Indicator的值为13FE。#3中，Teardown Indicator的值为13FF。只相差一个bit。

ithinc

samsin 发表于 2011-11-15 20:47
楼主，你好，谢谢额， 我觉得： This field shall not be present if there already exists a signalling t ...

那么这样一来，为啥 创建PDPrequest里的 SGSN address For signaling、For user traffic还是必须IE呢？是条件IE不是可以吗 ，Update PDP也一样。

这个问题我是这样理解的：SGSN address For user traffic当然是必须的，因为每个PDP Context的user plan是独立的；SGSN address For signaling其实是不会变的，只是因为SGSN address For user traffic当然是必须的，所以SGSN address For signaling就成必须的了，因为GTP协议格式的局限性，接收端依赖于GSN Address IE的顺序来确定是SGSN address For signaling还是SGSN address For user traffic。

还有就是，假设secondary 和primary 控制面上的 SGSN SIGNALING IP+SGSN control TEID同， 那么我更新PDP时，如果我只想更新NSAPI为6的PDP context的 sgsn control teid，是否primary 也 跟着改了，如果跟着改了显然不合适，不跟着改又违背了 “共享teid一说”， 所以还请楼主，给看看，这个问题，该如何？

“如果我只想更新NSAPI为6的PDP context的 sgsn control teid”这个说法是不准确的，TEID是标记GTP隧道的，同一PDN Connection的所有控制面消息是共享同一隧道的，所以不能说更改某个PDP Context的sgsn control teid的。

admin

不客气的。规范中提到delete pdp context request消息中的teardown indicator IE是conditional的IE，这个字段的值是从MS发起的deactivation pdp context request消息中复制过来的。但deactivation pdp context request消息中规范规定teardown indicator IE是可选的，所以综合来讲，这个teardown indicator字段是可选的。但如果一个APN中MS建立了多个PDP上下文，则一定要携带该IE，否则就会删除有歧义。

gaoyang_fei

爱卫生 发表于 2012-10-26 00:56
没有啊。delete pdp context response消息中本来就没有teardownInd字段啊。因为不需要啊，只要在delete r ...

谢谢爱总回答，差点犯了大错，那在 del_req中的 teardownInd 什么情况下会携带？如果不携带是不是就一个主上下文了，对方删除的时候没有歧义。

爱卫生

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

gaoyang_fei

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

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

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

gpf_gprs2012

围观学习，膜拜大家

samsin

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

爱卫生

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

谢谢楼主，第三个问题，我非常同意你的观点。
再说一下，我对第一个问题的理解，
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 的帖子

  关于第三个问题再补充一点。你的担心应该是用户已经有一个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 发表于 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 发表于 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

谢谢楼主， 你的回复让我好好看了几篇规范，好好理解后，才敢来回复。
你的回复中的也说了，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 的帖子

  不好意思，你的这段话我没有完全理解，“因为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

楼主，你好，谢谢额， 我觉得： 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 发表于 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."
  信令流程实例版块有二次激活的抓包，也验证了这一点。供参考。

stucoco

回复 samsin 的帖子

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