51学通信技术论坛

标题: 关于PDP上下文和TI、NSAPI的讨论，期待各位乱入~~ [打印本页]

作者: w18886hphz 时间: 2011-10-16 03:55:28 标题: 关于PDP上下文和TI、NSAPI的讨论，期待各位乱入~~

1.LTE中attach的时候就会激活一个默认的eps承载，相应的PDP上下文也会激活，是否这个PDP上下文对应

于3G和2G的primary pdp上下文呢？那如果LTE在触发专有承载的话，其对应的PDP上下文是否对应的于3G

和2G的secondary pdp上文呢？关于2G 3G 4G之间的区别和联系经常带来很多困惑。

2.transaction identifier（非扩展的）这个值的选取是0-15，nsapi也是0-15（其中0-4系统保留，使用

5-15）。这两个值是否一定相等或者是一一对应？它们的区别和联系是什么？感觉在PDP相关的讨论中很

少人提及transaction identifier

3.LTE中如果激活默认承载的话对应的NSAPI是否一定为5，即存在一个或者多个激活态的PDP上下文的话，

其对应的NSAPI是否第一个激活的一定要为5？其他顺序激活的NSAPI是否依次递增？

4.24.007中对transaction id的最高为TI flag的解释是，
0--The message is sent from the side that originates the TI
1--The message is sent to the side that originates the TI
我的理解是TI flag是用来标识收发方向的，“originates the TI”是否就是说：如果包含该信元的消

息是网络下发给UE的，TI Flag为1则说明网络让UE生成TI值，为0则说明该消息带的TI值UE不能改变？

如果以上理解中有任何问题，烦请各位批评指正。期待版主和大家的讨论，谢谢大家！

作者: 爱卫生 时间: 2011-10-16 13:56:15

回复 w18886hphz 的帖子

我说下我的理解吧。仅供参考啊。我说的对，并不见得一定对。只是我根据我的理解做的判断。
1 对。默认承载和专有承载分别映射到primary 和secondary pdp context.
2 TI规范里并没有完全说和PDP上下文对应。但实际上其实也是有对应关系的。但TI的值没有预留的。因此Primary PDP Context 的TI=0，而NSAPI则=5，对应的Secondary PDP Context的TI=1，则NSAPI=6。另外，TI只在MS-SGSN侧有。但NSAPI在Gn口也有。
TI的原意是会话标识。在24007中关于会话的定义是"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."，因此，会话是代表一个PD(protocol discriminator)和一个SAP的的。这个PD的取值有GMM消息/会话管理消息，SAP有用户数据、信令等取值。
3 LTE中已经没有了NSAPI这个概念，取而代之的是叫做EPS Bearer ID。确实是从5开始并依次递增的。但有些山寨机也不一定。论坛里有个包就是primary pdp 激活就分配了个NSAPI=6.
4 TI Flag的方向是站在上下行来说的，TI=0，代表是MS分配，发送方向是MS--->SGSN。=1则反过来。关于TI Flag的作用也在24007中有说明"Hence the TI flag identifies who allocated the TI value for this transaction and the only purpose of the TI flag is to resolve simultaneous attempts to allocate the same TI value."

作者: gaohui2008 时间: 2011-10-17 10:06:36

补充一下自己的理解：
1、TI是区分信令面的会话，NSAPI是区分数据面的业务流，NSAPI在Gb口的信令中是作为参数携带的，并不是一个标志，只有发送业务数据出现在SDCP中才起作用。TI和NSAPI没有直接的关系，也不需要有。在分组域一个TI标识会话中协商出NSAPI的值，在这个会话中可以说TI与该NSAPI对应了，但不会规定TI=0则NSAPI=5，只是一般情况下这么用（都是初始值）。
2、TI flag根据规范是the TI flag identifies who allocated the TI value for this transaction，TI=0可以是MS也可以是SGSN，这个在分组域不太好找，在电路域找一个被叫过程可以看到MSC发送的SETUP消息中携带的TI FLAG就是0，MS回应的call confirmed就是1。同理分组域应该也是如此。这也说明ＴＩ不会和ＮＳＡＰＩ直接对应的，否则电路域没有ＮＳＡＰＩ怎么办。
３、另外“transaction identifier（非扩展的）这个值的选取是0-15”说法不准确，ＴＩ只是“TI allows to distinguish up to 16 different bi-directional messages flows”，其值是０－７。

作者: 爱卫生 时间: 2012-6-16 13:47:50

gaohui2008 发表于 2011-10-17 10:06
补充一下自己的理解：
1、TI是区分信令面的会话，NSAPI是区分数据面的业务流，NSAPI在Gb口的信令中是作为参 ...

谢谢，你提到的我部分同意。

"TI是区分信令面的会话，NSAPI是区分数据面的业务流"和我的理解是一样的。但我的疑问是觉得TI和Gn控制面（GTP-C）的NSAPI应该是有映射关系的。但我始终没有找到规范里的原文。正如你在后面提到的“TI allows to distinguish up to 16 different bi-directional messages flows”，这里提到的消息流之前我的理解是区分MS和SGSN之间的会话管理（不含移动性管理）消息的，那么如果是这样的话，MS发起的一个激活、二次激活、去激活流程分别会使用3个TI值，分别是0、1和2。但实际上抓包的时候看到，最后一个去激活流程Deactivate PDP Context Request消息的TIO值仍然为1，并没有为2。”这说明TI也不完全是区分会话管理这样的消息流的。

反过来，如果没有这种映射关系，那么PDP激活完成后，如果要对这个PDP上下文进行修改或去激活，SGSN怎么才能将这个MS发起的去激活或修改消息和Gn口的某一个PDP上下文关联？（假设MS同时有5个active的PDP上下文）。

最后我还有一个问题，如果TI和NSAPI有映射关系，那TI的取值为0-7，而NSAPI有11个有效取值，怎么来一对一映射呢？

作者: gaohui2008 时间: 2012-6-25 11:43:45

爱卫生发表于 2012-6-16 13:47
谢谢，你提到的我部分同意。 "TI是区分信令面的会话，NSAPI是区分数据面的业务流"和我的理解是一样的。但 ...

可能是我表述的意思不准确，我的意思是TIO和NSAPI没有直接的对应关系，如TIO=0就必须用NSAPI=5。但它们在会话过程中是有动态的对应关系的，如果TIO=0协商参数NSAPI是5，在此会话过程中TIO=0和NSAPI=5是对应的。
1、一次、二次激活TIO应该是0、1，去激活如果是对二次激活，则TIO应该是1
2、在会话过程中这是有一定的对应关系，SGSN中的上下文会记录Gb口的TIO和NSAPI（猜得，从GGSN侧来的信令用NSAPI关联到PDP，从UE来的信令用TIO关联到PDP）
3、TIO=0～7加上双向（即TI flag为0、1）可以有16个会话，NSAPI有11个，是根据实际需要定制的，应该没有考虑对应关系。不过如果有的化，是不是可以说NSAPI有11个，但最多有8个是手机发起的PDP激活会话，其它3个是网络发起的？

作者: 行虚名座画 时间: 2012-7-10 13:01:57

看下面一段话： There is more TI available than NSAPIs so if this is not successful it wiil be the case that there is not enough NSAPIs

就是说，TI值比NSAPI的可用值还多，如果分配TI就不成功的话，则就是NSAPI不够用了。
怎么理解呢，就是说TI是保证NSAPI的，如果TI值都不够了，那NSAPI更不够了，其次，现网中最多支持3个PDP，nsapi值是够的，TI值肯定更够了，意义似乎不大。

作者: feile99 时间: 2012-7-11 13:02:22

爱卫生发表于 2012-6-16 13:47
谢谢，你提到的我部分同意。 "TI是区分信令面的会话，NSAPI是区分数据面的业务流"和我的理解是一样的。但 ...

关于TI可表示的PDP数量和NSAPI不一样，请参考24.008 6.1.1的描述如下：

For the session management protocol, the extended TI mechanism may be used (see 3GPP TS 24.007 [20]).

欢迎光临 51学通信技术论坛 (http://51xuetongxin.com/bbs/)