51学通信技术论坛

标题: GTP协议中的Teardown Indicator IE及实例 [打印本页]
作者: 爱卫生    时间: 2011-4-30 16:04:52     标题: GTP协议中的Teardown Indicator IE及实例

本帖最后由 爱卫生 于 2012-10-26 00:51 编辑

   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。
  下面我们来看一个实例。

[attach]275[/attach]

  在这个例子中，我们会看到两个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。

[attach]276[/attach]

作者: Albert    时间: 2011-5-1 01:17:49

请教版主：
当PDP二次激活的时候，通常是用第一次激活获取的地址，还是重新获取新的地址。
如果是两个地址，在两个地址同时存在的时候会不会存在地址冲突？能否简单讲解一下实现过程。
作者: 爱卫生    时间: 2011-5-1 10:04:04

本帖最后由 爱卫生 于 2011-5-1 12:48 编辑

回复 Albert 的帖子

    呵呵。是这样。首先，如果MS做PDP二次激活，GGSN不会分配新的地址。而是使用原来的地址（即Primary PDP Context激活时分配得到的地址）。所以也不存在冲突问题。关于这部分的流程我正在翻译TS23.060，但目前的进度只刚刚完成6.13章节。而你所想了解的二次激活是在9.2.2.1.1章节。我迟早会翻译过来的。如果你有兴趣也可以先看看规范。
   这里先给出关于二次激活上下文在规范中的定义，如下：
    The Secondary PDP Context Activation procedure may be used to activate a PDP context while reusing the PDP address and other PDP context information from an already active PDP context, but with a different QoS profile.
   另外，我刚写了一个二次激活的实例配合流程的说明放到“信令流程”版块。以下为链接。http://www.gprshome.com/forum.php?mod=viewthread&tid=240&extra=page%3D1 。仅供参考。{:soso_e100:}

作者: hendouse    时间: 2011-6-18 14:41:40

（1）我看附件中的抓包文件，Teardown Indicator 设置值为 false 或 true ，这便是所谓的0或1吧。
（2）按照上面说明，二次激活后，一般的去激活过程应该先去除第二次激活（Secondary PDP Context），然后在去除第一次激活（Primary PDP Context）吧
（3）"Teardown Indicator设置为1，这样就会通知GGSN将属于这个MS的所有PDP上下文全部删除。当然这个时候，在MS上只有一个Active的PDP上下文了，也就是这个Primary PDP Context，所以也无所谓。
"  既然已经全部删除所有PDP上下文了，怎么还有一个Active的PDP上下文呢？如果还有，要发起什么信令携带什么信息才能完全删除干净呢？          谢谢~
作者: 爱卫生    时间: 2011-6-18 16:11:45

回复 hendouse 的帖子

   针对你的(1)(2)(3)来个点到点应答。
(1):是的。
(2):是的。
(3)："Teardown Indicator设置为1，这样就会通知GGSN将属于这个MS的所有PDP上下文全部删除。当然这个时候，在MS上只有一个Active的PDP上下文了，也就是这个Primary PDP Context，所以也无所谓。"
    这句话可能我表达的不是很清楚，我是想说在SGSN发第3个包delete pdp context request消息的时候，它只有属于这个MS的一个Active的PDP上下文了，即NSAPI=5这个。直到收到GGSN的回复（即第4个包delete pdp context response消息)之前，这个PDP上下文在SGSN上都是active的。所以在第4个包，SGSN收到delete pdp context response消息时，SGSN上关于这个MS实际只有一个active PDP上下文可以删，所以TI=1还是TI=0都是一样的。这时一个特例，但如果在#1号包SGSN发的delete pdp context request消息里如果TI=1的话，则GGSN会将属于这个MS的两个PDP上下文（Primary 和Secondary PDP上下文) 都删除（NSAPI=5和6），
作者: samsin    时间: 2011-10-19 22:15:46

针对你的(1)(2)(3)来个点到点应答。
(1):是的。
(2):是的。个人认为：这个不一定吧。要看需要而定
(3)："Teardown Indicator设置为1，这样就会通知GGSN将属于这个MS的所有PDP上下文全部删除。当然这个时候，在MS上只有一个Active的PDP上下文了，也就是这个Primary PDP Context，所以也无所谓。"
     这句话可能我表达的不是很清楚，我是想说在SGSN发第3个包delete pdp context request消息的时候，它只有属于这个MS的一个Active的PDP上下文了，即NSAPI=5这个。直到收到GGSN的回复（即第4个包delete pdp context response消息)之前，这个PDP上下文在SGSN上都是active的。所以在第4个包，SGSN收到delete pdp context response消息时，SGSN上关于这个MS实际只有一个active PDP上下文可以删，所以TI=1还是TI=0都是一样的（个人认为这句话有问题，这时的Teardown一定是1不可能为0，另外TI是transaction identity的缩写，难道Teardown也缩写为TI，请楼主谈谈。）。这时一个特例，但如果在#1号包SGSN发的delete pdp context request消息里如果TI=1的话，则GGSN会将属于这个MS的两个PDP上下文（Primary 和Secondary PDP上下文) 都删除（NSAPI=5和6）（同意，所以删除或者去活时是不区分primay还是secondary的，为啥楼主在“PDP上下文详解里提到当去活primary的时候所有的secondary也都去活了，反之当去活secondary的时候，只能去活一个，请楼主谈谈这个问题。），

本文摘自: GPRS家园(www.gprshome.com) 详细出处请参考：http://www.gprshome.com/forum.php?mod=viewthread&tid=237&extra=page%3D1
谢谢楼主
作者: 爱卫生    时间: 2011-10-20 09:57:50     标题: RE: GTP协议中的Teardown Indicator IE及实例

samsin 发表于 2011-10-19 22:15
谢谢楼主

  说说我的理解哈。
  (2):这个不一定吧。要看需要而定
      这个我同意。但通常来说会先去激活Secondary，再去激活Primary，因为Secondary是要依附于Primary的，如果Primary都不存在了，那Secondary也就会被去激活。这个和Tear down Indicator无关，不管Tear down Indicator取值为0或1，只要Primary去活了，那Secondary也将一定要被去激活。
(3所以TI=1还是TI=0都是一样的（个人认为这句话有问题，这时的Teardown一定是1不可能为0，另外TI是transaction identity的缩写，难道Teardown也缩写为TI，请楼主谈谈。）。
      我能够理解你的疑惑。照道理来说，如果只有一个active PDP Context了，Tear down indicator设置为0也没有意义，但24008里并没有完全说死，所以也不排除有手机会这样来做。TI是transaction identity这个确实是，只不过我在回帖的时候偷懒了，不好意思，将Teardown Indicator也缩写成TI了，实际上是不合适的，请见谅。
这时一个特例，但如果在#1号包SGSN发的delete pdp context request消息里如果TI=1的话，则GGSN会将属于这个MS的两个PDP上下文（Primary 和Secondary PDP上下文) 都删除（NSAPI=5和6）（同意，所以删除或者去活时是不区分primay还是secondary的，为啥楼主在“PDP上下文详解里提到当去活primary的时候所有的secondary也都去活了，反之当去活secondary的时候，只能去活一个，请楼主谈谈这个问题。），
      我觉得从消息上看感觉是没有明确的区分，即Gn口的delete pdp context request消息并没有区分是primary还是secondary，MS和SGSN的GMM消息也不像激活时分activate pdp context request和activate secondary pdp context，在去活时都是一个消息叫做deactivate pdp context request。但实际上，是可以区分出来的。例如正如你所说，在GMM消息里，会有Transaction identity里的TIO，这个值会和激活时的TIO对应，用于区分是primary还是secondary，本例取值为0和1，分别对应primary和secondary，同理，在Gn口的delete pdp context request，也有nsapi和创建pdp上下文时候的NSAPI进行对应，所以站在SGSN的角度来看，它是能够在去激活时区分出primary还是secondary的，只不过我们的消息没有分开成两个而已。
    "上下文详解里提到当去活primary的时候所有的secondary也都去活了，反之当去活secondary的时候，只能去活一个"，我的本意是想说明去活primary会导致所有的secondary都去活，但如果去活secondary，不会导致primary被去活，但可能导致其他的secondary被去活。
作者: samsin    时间: 2011-10-20 13:20:22

我能够理解你的疑惑。照道理来说，如果只有一个active PDP Context了，Tear down indicator设置为0也没有意义，但24008里并没有完全说死，所以也不排除有手机会这样来做。
本文摘自: GPRS家园(www.gprshome.com) 详细出处请参考：http://www.gprshome.com/forum.php?mod=viewthread&tid=237&page=1#pid4678
在TS 29.060 V9.1.0 (2009-12）里面：（红色部分）


The Teardown Ind is used to indicatewhether all PDP contexts that share the PDP address or two IP addresses(one IPv4 and one IPv6 if PDP Type IPv4v6 is supported and used) withthe PDP context identified in the request should also be deactivated. This maytrigger the deletion of all the information kept for a MS at a GSN, if no otherPDP contexts associated to other PDP addresses are active on the GSN. If theTeardown Ind information element value is set to "1", then all PDPcontexts that share the same PDP address or two IP addresses(one IPv4 and one IPv6 if PDP Type IPv4v6 is supported and used) withthe PDP context identified by the NSAPI included in the Delete PDP ContextRequest Message shall be torn down. If more than one PDP Contexts are activethat share the same PDP address or two IP addresses (one IPv4 and one IPv6 ifPDP Type IPv4v6 is supported and used), only the PDP context identified by the NSAPIincluded in the Delete PDP context Request shall be torn down if the value ofthis information element is "0" or this information is not included. The SGSN shall copy this IE to the Delete PDP Context Request fromthe associated Deactivate PDP Context Request initiated by MS, if it isincluded.
This information element shall NOT be included by the SGSN if theDeactivate PDP Context Request message from the MS does NOT include the Teardown indicator at PDP Context Deactivation initiated by MS. However,exceptionally this information element shall be included and its value set to "1"by the sending GSN only when the last PDP context associated to a PDP address or two IPaddresses (one IPv4 and one IPv6 if PDP Type IPv4v6 is supported and used) is torndown and there are no outstanding Create PDP context requests for other PDPcontext different from the one being torn down for that PDP address or twoIP addresses (one IPv4 and one IPv6 if PDP Type IPv4v6 is supported and used).意思是：如果要去活一个PDP，而这个PDP恰是‘pdp address and apn’ 唯一的一个并且目前没有在此‘pdp address and apn’上的 create pdp request， 那么在sending gsn的删除pdp里它的Teardown Ind 字段必须有、并且值肯定是1。

谢谢楼主


  

    


作者: 爱卫生    时间: 2011-10-20 13:27:11

回复 samsin 的帖子

  非常感谢纠正错误。学习了！多谢！
  总结一下，就是说如果当前UE只有一个active的PDP上下文了（实际上只可能是primary pdp context)，那在delete pdp context request消息里的tear down indicator一定要置1。
作者: samsin    时间: 2011-10-20 13:40:58     标题: hi，请楼主看看

本帖最后由 samsin 于 2011-10-20 13:44 编辑
我觉得从消息上看感觉是没有明确的区分，即Gn口的delete pdp context request消息并没有区分是primary还是secondary，MS和SGSN的GMM消息也不像激活时分activate pdp context request和activate secondary pdp context，在去活时都是一个消息叫做deactivate pdp context request。但实际上，是可以区分出来的。例如正如你所说，在GMM消息里，会有Transaction identity里的TIO，这个值会和激活时的TIO对应，用于区分是primary还是secondary，本例取值为0和1，分别对应primary和secondary，同理，在Gn口的delete pdp context request，也有nsapi和创建pdp上下文时候的NSAPI进行对应，所以站在SGSN的角度来看，它是能够在去激活时区分出primary还是secondary的，只不过我们的消息没有分开成两个而已。
本文摘自: GPRS家园(www.gprshome.com) 详细出处请参考：http://www.gprshome.com/forum.php?mod=viewthread&;tid=237&extra=#pid4691

我认为： TI，这个东东，其实是在gb口上的‘NSAPI’，在协议里24008：Tear down indicator

This IE is included in the message in orderto indicate whether only the PDP context associated with this specific TI orall active PDP contexts sharing the same PDP address and APN as the PDP contextassociated with this specific TI shall be deactivated.

在sgsn上TI和NSAPI有个映射关系，所以sgsn当然知道 对哪个PDP操作了（创建哪个PDP，更新的又是哪个PDP等），因此gn口的PDP消息，绝对离不开NSAPI，这个东东。这也正如gb的GMM/GSM中的GSM也离不开TI一样.
感觉楼主的意思 好像是 从TI的值上来区分 哪个是主哪个是次，这个能确定吗？ 我还记得 NSAPI有个先为6，接着一个为5的例子。
个人认为，TI也MS自己分配的，如果MS有个自己认为有效的TI=0,而网络却把它给无效了，这时MS发起了activate PDP procedure,那么它的TI=1, 一段时间后，它又发起activate pdp procedure，那么它的TI=0不就可能了吗？ 1为primary，而0就是secondary了呀。
请楼主谈谈自己的观点。
谢谢楼主哦

作者: samsin    时间: 2011-10-20 13:54:42     标题: hi，楼主你好

本帖最后由 samsin 于 2011-10-20 13:58 编辑
      这个我同意。但通常来说会先去激活Secondary，再去激活Primary，因为Secondary是要依附于Primary的，如果Primary都不存在了，那Secondary也就会被去激活。这个和Tear down Indicator无关，不管Tear down Indicator取值为0或1，只要Primary去活了，那Secondary也将一定要被去激活。

本文摘自: GPRS家园(www.gprshome.com) 详细出处请参考：http://www.gprshome.com/forum.php?mod=viewthread&;tid=237&page=1#pid4692

楼主，你好，这个红色的依附关系，个人认为应该是创建PDP时的，一旦创建完成后，还存在这个依附关系吗？不是独立核算的吗？从gb口的去活pdp消息格式里，TI难道有潜在的 限制吗？ 请楼主谈谈这个问题。
谢谢楼主。
作者: stucoco    时间: 2011-11-11 09:52:43

回复 samsin 的帖子

小弟也是刚刚开始学习，但是我个人也觉得secondary PDP在建好以后对primary没有这么大的依赖关系。激活一个primary和secondary，然后干掉primary，应该没什么问题吧。同样期待指教。
作者: 爱卫生    时间: 2011-11-11 12:01:26

本帖最后由 爱卫生 于 2011-11-11 12:23 编辑

回复 stucoco 的帖子

  我说下这个Teardown Indicator IE在PDP去激活时，对Primary和Secondary PDP上下文去激活的影响的个人理解吧。也就是上面提到的依附问题。先说结果吧，我个人觉得是有依附关系的。
1 谈依附，首先到TS23060的9.2.4章查找去激活流程的说明：
   分成两种情况讨论，一是MS发起的，一是GSN发起的去激活。在去激活流程中并不区分Primary PDP Context还是Secondary。都是一个消息---Deactivate PDP Context Request，在Gn侧也是一个消息----Delete PDP Context Request。先看9.2.4.1---MS发起的：这里提到"The MS sends a Deactivate PDP Context Request (TI, Teardown Ind) message to the SGSN. If the MS deactivates the PDP context created by the PDP Context Activation Procedure, the Teardown Ind shall be sent"。也就是说这个PDP上下文是由正常的PDP上下文创建流程建立的，在去激活时，应该要带上Teardown Indicator。
2 然后到TS24008去查看Teardown Indicator的作用和Deactivate PDP Context Request消息的构成。
   在9.5.14.1查到Teardown Indicator的作用。"This IE is included in the message in order to indicate whether only the PDP context associated with this specific TI or all active PDP contexts sharing the same PDP address and APN as the PDP context associated with this specific TI shall be deactivated."这个Teardown Indicator可以取的值是0或1。如果为0，则代表关联到指定TI(Transcation ID)的PDP上下文都要删除，那Secondary肯定是需要通过Linked TI关联到Primary的。如果取值为1，则代表共享相同PDP地址的所有PDP上下文全部都要删除，同样，Secondary肯定是要和Primary共享相同PDP地址的。也就是说Teardown Indicator不管取值为0还是1，当对Primary PDP Context执行去激活时，Secondary PDP Context都将被删除。但反过来不会，这就需要再去看看Deactivate PDP Context Request消息的构成。同样也是在9.5.14，你会发现消息里并没有NSAPI这个字段。那这个消息由MS发给SGSN，SGSN怎么能够区分出MS的Primary和Secondary PDP Context呢？原来是靠Transaction identifier。你会发现在Deactivate PDP Context Request消息里Transaction identifier是必选的IE。所以，这里实际上有一个Transaction identifier到NSAPI的映射过程的，否则SGSN根本无法知道到底是要将哪个PDP上下文去激活。
  举个例子:             NSAPI      Transaction identifier     Linked Transaction identifier
Primary PDP Context       5                  0
Secondary PDP Context     6                  1                            0
  那这个时候，如果MS发起的Deactivate PDP Context Request希望是对Secondary进行去激活，Transaction identifier则会填1，但这时即使携带了Teardown Indicator，也不会将Primary去激活。因为Primary没有通过Linked Transaction identifier和Secondary进行关联。但反过来，如果去激活Primary，Transaction identifier对应为0，无论Teardown Indicator设置为0还是1，都会将Secondary去激活。
  以上就论证Secondary即使在建立好以后，在去激活时也不能单独存在。
PS:
  最后还查了TS29060，发现在GTP规范中的Delete PDP Context Request消息里的Teardown Indicator是一个有条件的IE，当MS在Deactivate PDP Context Request带了Teardown Indicator之后，Delete PDP Context Request消息就一定会携带。所以是可以关联在一起的。"This information element shall be included by the SGSN if the Deactivate PDP Context Request message from the MS includes the Tear down indicator at PDP Context Deactivation initiated by MS."
作者: stucoco    时间: 2011-11-11 16:57:28

回复 爱卫生 的帖子

楼主说的很有道理，受益匪浅。可能我之前看到的一个case不是很符合协议。确实是把primary干掉，只留下了secondary PDP。这个例子让我一直觉得primary和secondary在建立之后就相互独立了。感谢楼主！
作者: samsin    时间: 2011-11-12 09:40:42

stucoco
兄弟， 能否把你的 那个例子 的文件 传上来吗？ 大家都学习一下。谢谢
作者: samsin    时间: 2011-11-12 10:07:28

在9.5.14.1查到Teardown Indicator的作用。"This IE is included in the message in order to indicate whether only the PDP context associated with this specific TI or all active PDP contexts sharing the same PDP address and APN as the PDP context 【associated with this specific TI】 shall be deactivated."

楼主，好哈，你对associcate这么理解的， 为啥 不能认为 associate 就是 identified呢？， 个人认为这也可以说通啊。
作者: 爱卫生    时间: 2011-11-12 10:21:17

回复 samsin 的帖子

  因为在TS24008中还提到了Secondary和Primary是有Assoicate这种关系的。原文是"Each PDP address may be described by one or more PDP contexts in the MS or the network. The PDP Context Activation procedure is used to activate the first PDP context for a given PDP address and APN, whereas all additional contexts associated to the same PDP address and APN are activated with the secondary PDP context activation procedure. "
  而在实际的使用中，Secondary PDP Context是通过Linked TI(Trancation ID)和Primary关联的。达到共享PDP地址的目的。所以我的理解是这种依附关系。
  而且在后面也提到了，"After successful PDP context deactivation, the associated NSAPI and TI values are released and can be reassigned to another PDP context. "。所以，这个不是说的自己的ID，而应该是关联到这个TI的所有PDP上下文，可能是1个Primary + N个Secondary。
作者: samsin    时间: 2011-11-12 11:56:42     标题: PDP CONTEXT

本帖最后由 samsin 于 2011-11-12 12:01 编辑

楼主，你好，这样，你描述的只是， 在 PDP 的初期，secondary要用Link TI ；NSAPI 和 TI 有关联，我都同意。问题是在PDP新建之后， 到PDP 销毁 之间， 是否仍按照这个依附关系 来操作 primary和secondary。
在SGSN 的 关于 PDP context 中[attach]950[/attach]， 没有看到 PDP ‘s primary 方面的参数， 如何保证我当前去活的 不是 primary呢？ 难道在信令消息 里面 不展现？
楼主，能否 提供这方面的 规范呢， 谢谢哦 。 我较真了。
作者: samsin    时间: 2011-11-13 13:09:36     标题: primary 和 secondary PDPs 如何去活的说明

本帖最后由 samsin 于 2011-11-13 13:24 编辑

楼主， 好啊， 我下到一篇文档， 关于 primary and secondary PDP 的 生命期和销毁的说明 ， 分享一下，今天早晨刚下的。[attach]955[/attach]。{:soso_e100:}
作者: 爱卫生    时间: 2011-11-13 14:52:59

回复 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    时间: 2011-11-13 15:45:20

楼主，太客气了，我向你，向各位专家也学了好多{:soso_e100:}
作者: samsin    时间: 2011-11-13 15:50:19

1 这两个PDP上下文在创建时会分配两个不同的NSAPI以及两个不同的Transacation ID，但Secondary PDP Context将通过Linked TI和Primary进行关联，达到共享PDP地址还有控制面TEID的目的。
楼主，你好，红色部分“共享 sgsn control teid、ggsn control teid”，这个方面有规范说明吗？ 谢谢额
作者: stucoco    时间: 2011-11-14 10:39:47

回复 samsin 的帖子

暂时没找到，以后再碰到可以传上来看一下。不过看样子这个问题有定论了，向各位高手学习了。
作者: 爱卫生    时间: 2011-11-14 12:17:27

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."
  信令流程实例版块有二次激活的抓包，也验证了这一点。供参考。
[attach]957[/attach]
作者: samsin    时间: 2011-11-15 20:47:03     标题: teid值同？

本帖最后由 samsin 于 2011-11-15 20:53 编辑

楼主，你好，谢谢额， 我觉得： 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一说”， 所以还请楼主，给看看，这个问题，该如何？
请各位专家，也分析分析。
谢谢哦
作者: 爱卫生    时间: 2011-11-15 21:37:23

回复 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    时间: 2011-11-23 07:11:23     标题: teid

本帖最后由 samsin 于 2011-11-23 07:16 编辑

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

多谢楼主！




作者: 爱卫生    时间: 2011-11-23 11:34:23     标题: RE: GTP协议中的Teardown Indicator 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板卡处理。相当于用户面和控制面的内部分离。有点想当然了，呵呵！
作者: 爱卫生    时间: 2011-11-23 12:01:38

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。所以，这个问题我觉得不用担心。
作者: 爱卫生    时间: 2011-11-23 14:21:48

本帖最后由 爱卫生 于 2011-11-23 14:23 编辑

回复 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 20:55:18

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



作者: 爱卫生    时间: 2011-11-23 21:21:36

回复 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    时间: 2011-11-24 07:17:51     标题: 谢谢额

本帖最后由 samsin 于 2011-11-24 07:19 编辑

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

围观学习，膜拜大家
作者: gaoyang_fei    时间: 2012-10-25 11:48:07

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

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

del resp 中没有teardownInd字段，是什么情况，这个主上下文中没有过secondary pdp context 的创建？
作者: 爱卫生    时间: 2012-10-26 00:56:32

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    时间: 2012-10-26 11:53:50

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

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

作者: admin    时间: 2012-10-27 19:30:30

不客气的。规范中提到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，否则就会删除有歧义。
作者: ithinc    时间: 2013-1-31 10:34:55

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的。






欢迎光临 51学通信技术论坛 (http://www.51xuetongxin.com/bbs/) Powered by Discuz! X2