小白求问爱大人。。请问RAB的释放或是IU释放如何引起PDP上下文的修改啊

summer

因为自身做的一个设计，与标准的SGSN,GGSN有偏差
不 太理解RAB释放引起的上下文修改。

还有，请问下，上下文修改，是不是只有网络侧发起的啊？

summer

以上，我已经搞清楚了。修改流程不仅仅是网络侧可以发起
MS侧也可以发起。

但是对于RAB释放，和Iu释放引起的修改还是不清楚。

爱大人，请问有没有修改方面的教程啊

爱卫生

summer 发表于 2012-12-4 23:04
以上，我已经搞清楚了。修改流程不仅仅是网络侧可以发起
MS侧也可以发起。

你所提到的RAB的释放或Iu释放引起的PDP上下文修改在TS23.060的9.2.3.5节中有介绍。

“The RNC can request a RAB to be released through the RAB Release procedure without releasing the Iu connection.
After the RAB(s) release the SGSN shall modify the PDP context as follows:

- In the SGSN, for a PDP context using background or interactive traffic class, the PDP context is preserved with no modifications.

- In the SGSN, for a PDP context using streaming or conversational traffic class, the PDP context is preserved, but the maximum bit rate is downgraded to 0 kbit/s (for both uplink and downlink) when the associated RAB is released. The SGSN sends an Update PDP Context Request (TEID, QoS Negotiated) message to the GGSN to set the maximum bit rate to 0 kbit/s in the GGSN. The value of 0 kbit/s for the maximum bit rate indicates to the GGSN to stop sending packets to the SGSN on this PDP context. The value of 0 kbit/s for the maximum bit rate for both uplink and downlink indicates to the SGSN that a RAB shall not be re-established for this PDP Context in subsequent Service Request Procedure. CAMEL procedure calls shall be performed, see referenced procedure in TS 23.078 [8b]: CAMEL_GPRS_Change_Of_QoS. The procedure returns as result "Continue".

The following procedures shall be performed in the MS when the RRC layer indicate to higher layer that a RAB has been released and the RAB release was not initiated due to a PDP Context Deactivation Procedure:

- For a PDP context using background or interactive traffic class, the PDP context is be preserved with no modifications.

- For a PDP context using streaming or conversational traffic class, the PDP context is preserved, but the maximum bit rate is downgraded to 0 kbit/s (for both uplink and downlink).

At this point or at a later stage, the MS may start a PDP Context Deactivation procedure or PDP Context Modification procedure. The MS shall use the PDP context modification procedure to re-activate the PDP context and to re-establish the RAB“。

summer

额。。看了下英文版本后，粗略的翻译了一下
是不是说

当我们这个PDP上下文是激活的，RAB释放,我们的上下行速率都变成了0KB。
这时，我们需要通知GGSN，变更上下文通道，重新申请RAB，之后才继续传输数据，保持原有的PDP上下文

如果我上面的描述没有错的话
那请问爱大
我是不是只要把原有的PDP上下文信息+新的RAB的信息发送给GGSN就可以了？

summer

还有，一楼提到的一种全新的设计模式，虽然是参照标准的PS域来的
但是也做了很多改动，比如直接取消了SGSN,GGSN，改成了GMM移动管理模块，SM回话模块，GM模块等，分担原有的网元。

之后如果完成了，可以提供出来给大家做个参考。
当然过程中还需要大家多多帮忙。多多指教一下

在此先感谢

yonka

爱卫生 发表于 2012-12-4 23:10
你所提到的RAB的释放或Iu释放引起的PDP上下文修改在TS23.060的9.2.3.5节中有介绍。“The RNC can request ...

爱总

你提到释放的RAb需要在之后由MS发起PDP上下文修改来恢复PDP的QoS（重建RAB）
我的疑问是~RAB释放是MS发起的么？不然的话怎么让MS感知到RAB被释放而...呢？

还有就是，我看到你摘录的规范里提到“indicates to the SGSN that a RAB shall not be re-established for this PDP Context in subsequent Service Request Procedure.”，既然不能重建RAB，那么MS发来的这个service request的作用是？或者说为什么要发呢？

yonka

爱卫生 发表于 2012-12-4 23:10
你所提到的RAB的释放或Iu释放引起的PDP上下文修改在TS23.060的9.2.3.5节中有介绍。“The RNC can request ...

还有就是
RAB和Iu connection的关系我大致明白
但Iu connection在什么情况下会被释放呢？与RAB释放有关联么？

summer

yonka 发表于 2012-12-5 09:56
还有就是
RAB和Iu connection的关系我大致明白
但Iu connection在什么情况下会被释放呢？与RAB释放有关 ...

我的认识是
IU释放了，RAB必然释放
RAB释放，IU不一定要释放。。。。

wenliu

我认为Iu释放和RAB 释放两者没有关系。

用户在注册到SGSN的时候，可以释放RAB， SGSN 向GGSN发起Deactive Tunnel 过程， 这个时候Iu没有释放，但是用户面已经就没有了。

用户释放了Iu，但是用户并没有去激活之间建立的Tunnle，SGSN 还可以继续保留。 用户可以用CM Seq过程，重新建立Iu链接，然后复用之前的tunnle 信息。


只有在用户注销的时候，Iu释放和RAB 可能同时发生（但不排除SGSN还可能保留Context一段时间）

hycl5410

对于一个用户而言，iu release可以理解为RNC与SGSN之间控制面连接“通路”的断开。RAB则可以理解为RNC与SGSN或者GGSN（DT场景）之间用户面的“通路”。

于是Iu release则必然会带来该用户所有RAB的release，反过来则不一定。比如一个用户激活了多个PDP，那么就有多个RAB，但是只会有一个Iu连接。

在Gn接口，无论数据面还是用户面，tunnel都是随着PDP一直存在的。

对于绝大部分现实场景，Iu的release是不会对PDP造成任何影响的，因为目前还主要是background和interactive类型的业务。其他类型的PDP，爱老大已经给出了明确的规范说明，就不赘述了。

说到底还是协议层次的事情，Iu release是RANAP层上的事，PDP是NAS层上的事。对于NAS来说，RANAP只管建通路，断掉无所谓，用时重建即可（service request流程）。
而NAS层是使用P-TMSI来标识用户的，所以底下的通路断了并不会导致上层逻辑连接的中断。
打个比方，两端规定，实线代表的是A用户的连接，虚线代表的是B用户的连接。连上线就代表两端可以通信，断掉线就不可以通信。那么A需要通信的时候我就连上一条实线，通信完成我就擦掉它，下一次再想通信，我就再画一条实线即可。至于每次我画的线用了什么颜色，什么粗细，都无所谓，只要是实线就代表了A用户。

顺便说一句，RANAP其实并不具备标识一个连接的功能，它是借用了底下SCCP层的确认连接功能。

Iu release设计的目的是为了节省或者有效利用资源，如果空口RRC都断掉了，还保留Iu有什么意义呢？

这个帖子里讨论的问题其实其他很多帖子一直都在讨论，只不过没有串起来说而已。

hycl5410

wenliu 发表于 2012-12-6 14:12
我认为Iu释放和RAB 释放两者没有关系。

用户在注册到SGSN的时候，可以释放RAB， SGSN 向GGSN发起Deactiv ...

wenliu大侠应该是CS交换出身吧？
我觉得Iu release这里CS和PS还是有所不同。CS是一个call过来，从下层到上层一起建也一起释放；而PS的一个call（PDP）则可能持续很长时间，而有效的业务时间又不需要那么久，所以在没有实际业务的时候断掉底层连接是一个合理的选择。

wenliu

hycl5410 发表于 2012-12-6 21:45
wenliu大侠应该是CS交换出身吧？
我觉得Iu release这里CS和PS还是有所不同。CS是一个call过来，从下层到 ...

是的确做过CS Core , 然后就直接做IMS去了。  为工作需要，LTE方面的，不过只是读规范和协议，不和实际的接触。

”现在因用户在注册到SGSN的时候，可以释放RAB， SGSN 向GGSN发起Deactiv ...“

这个例子，只是给个极端的例子，就是在RAB的确已经释放的情况下。Iu也用不着释放。用户attach在网络中，但是不用激活上下文PDP。

只是我自己对比下和LTE 的Attach+Default Bearer的模式有了很大区别。

爱卫生

summer 发表于 2012-12-5 09:59
我的认识是
IU释放了，RAB必然释放
RAB释放，IU不一定要释放。。。。

引用下《WCDMA关键技术详解：姜波》一书6.3.5章节的说明是：

“在核心网的某个域上，一个UE可以保持信令连接而没有RAB资源，但是如果UE具有RAB资源，则UE肯定需要使用信令连接。”上面提到的信令连接就是Iu连接。

可参考这个帖子：http://www.gprshome.com/forum.php?mod=viewthread&tid=3224&highlight=。是关于这一节内容的介绍。