为什么在3G中没有类似Ready Timer来管理UE在有active的PDP上下文情况下的MM状态切换？

爱卫生

  如题，为什么在3G中没有类似Ready Timer来管理UE的MM状态切换？
  我们都知道，在2G中，MS的移动性管理状态有3类。其中附着成功后，将进入到Ready状态。如果默认的44秒的Ready Timer时间内，MS和网络侧没有流量或信令交互，SGSN将把MS的MM状态切换到Standby，以节省相应的资源。
  而在3G（WCDMA和TD-SCDMA)中，我们发现，很多计时器保留下来，例如周期性RAU计时器，Mobile可达计时器等等。但却没有和Ready Timer对应的值来完成UE的移动性管理状态从连接态（PMM-Connected）切换到空闲态（PMM-IDLE)。
   那SGSN是怎样来管理移动性状态的呢？
  通过读规范我们发现，如果要从PMM-Connected切换到PMM-IDLE，需要Iu连接的释放。这个切换图如下所示：

  那什么情况下会释放Iu连接呢？由谁来释放？
  规范是这样规定的，有人认为SGSN其实并不需要知道UE在哪个小区，它其实只要知道UE在哪个RA就可以了。因为具体的小区接入和寻呼都实质上是由RAN的节点来完成的。并且为了加强网络侧的集中控制，简化管理。在3G中，强化了RNC的控制功能，将类似ready timer的功能放到了RNC上实现。当这个计时器在RNC上超时之后，RNC将发起Iu连接释放流程。并且在给SGSN的Cause里面会携带原因值为"User Inactivity"。这样，UE就会切换到PMM-IDLE状态。这个定时器叫做RRC-Connection-Release timer。这在TS23.060 V10.2.0的12.7.3.1 Iu释放流程中有详细描述。
摘录如下：
The RAN notices that the RRC connection has been released or detects a need to release the radio resources. It sends an Iu Release Request (Cause) message to the SGSN. Cause indicates the reason for the release (e.g. O&M Intervention, Unspecified Failure, User Inactivity, Repeated Integrity Checking Failure, or Release due to UE generated signalling connection release). User Inactivity means that the RAN decided to release an MS that shows no more activity, in the case where the MS has only non real-time RABs established, in order to optimise the radio usage after the RRC-Connection-Release timer expired.

hendouse

“在3G中，强化了RNC的控制功能，将类似ready timer的功能放到了RNC上实现。当这个计时器在RNC上超时之后，RNC将发起Iu连接释放流程。并且在给SGSN的Cause里面会携带原因值为"User Inactivity"。这样，UE就会切换到PMM-IDLE状态。这个定时器叫做RRC-Connection-Release timer。这在TS23.060 V10.2.0的12.7.3.1 Iu释放流程中有详细描述。”   楼主的探索精神可谓啊，谢谢分享~

zhenjiucuo

在网络侧对3G接入的MS状态的维护，是通过终端本身在移动性管理消息中上来的follow-on-pending信元是否置位来决定在没有PDP时或者RAU结束时是否还保持Iu链接。即如果是follow-on-not-pending，则SGSN立即发起Iu Release Command释放Iu链接。

爱卫生

zhenjiucuo 发表于 2011-7-27 23:48
在网络侧对3G接入的MS状态的维护，是通过终端本身在移动性管理消息中上来的follow-on-pending信元是否置位来 ...

  谢谢补充。你说的对。follow-on request pending确实有这样的作用。这个flag在2G中也有，在EPC中也有，但换了个名字，叫active flag。用户可以在附着的时候或RAU的时候，携带这个flag，请求网络侧不要释放掉Iu连接。
  但我们这里讨论的不是这个场景。这个帖子讨论的是，当用户已经激活成功，正在上网的这个过程中，如果因为空口的信号原因，MS和网络侧失去了连接，并且没有数据传递的情况下，怎么才能把Iu连接释放掉，并进行手机的状态切换到PMM-IDLE。（这时候，手机已经和网络侧没有任何消息能够传递了）在2G中这可以由ready timer来控制，但3G中，是由RNC来控制的，RNC有类似ready timer的计时器，超时后将请求SGSN释放Iu连接，并将手机状态切换到PMM-IDLE。

zhenjiucuo

回复 爱卫生 的帖子

啊。。。。
我看到的是MM状态，没有提到是否有PDP啊。。。
不过爱老板你说的是对的，在有active的PDP后，网络侧已经无权再释放Iu链接了（除非是RAU而非PS HO）。

爱卫生

  呵呵，不好意思。可能我有些用词不够准确。但又找不到更好的词汇了。应该在加个定语，标题改为“为什么在3G中没有类似Ready Timer来管理UE在有active的PDP上下文情况下的MM状态切换”，不知道这样子对吗？

zhenjiucuo

回复 爱卫生 的帖子

绝啊，相当正确啊~~~~~

zglaojiang

回复 爱卫生 的帖子

那这个RRC-CONNECTION-Release TIMER的时长是不是就是在RNC上配置的，如果是的话，有没有哪条命令去查这个时常是多少？
另外在消息跟踪时有没有哪条消息里面会带上这个定时器。因为我看消息时好像没见过这个定时器。谢谢！

z36306610

在3G中，强化了RNC的控制功能，将类似ready timer的功能放到了RNC上实现。当这个计时器在RNC上超时之后，RNC将发起Iu连接释放流程。并且在给SGSN的Cause里面会携带原因值为"User Inactivity"。（在RNC上能否查到这个定时器的大小？）
从IU接口抓包来看iu release request cause为"user inactivity"占比非常小，绝大部分为"network optimization"（80%），应该是用户从DCH落到fach再到idle时RNC定时器超时，RNC发起的IU连接释放流程。还有20%是"release-due-to-ue-generate-signaling-release"，这是由于R8手机具有快速休眠功能，终端检测到无下行或上下流量时Ue告知RNC，RNC发起iu连接释放。

gaohui2008

对这个定时器是否可以从是否需要角度考虑呢？在Gb口的信令是没有连接建立概念的，MS在附着后随时可以发起层三消息，这个消息不需要建立连接，可以认为是无状态的，因此需要有Ready 定时器同步双方的状态转换，设想如果设计了一个消息专门同步SGSN 和MS，告知双方应该进入Standy by，这是层三消息发送后先到Ready在转Standy by为此浪费资源不值过。但Iu口的信令需要建立连接后才能发送，拆除连接就可以表示状态的变化，因此不需要定义Ready定时器。至于是谁拆除、何时拆除是另一个问题，与此不是同一层次的问题。

爱卫生

回复 gaohui2008 的帖子

  呵呵，有道理。深入的分析啊！谢谢！

yonka

回复 爱卫生 的帖子

RRC-Connection-Release timer和SGSN上的Iu activity supervision timer有什么关系吗？

yonka

回复 爱卫生 的帖子

RRC-Connection-Release timer这个计时器监控的是信令还是payload？
也就是说是这个指定时间内都没有信令或负载就超时还是只要没有负载就超时？

看过一个优化的案例，中兴的RNC的设计上是只监控payload~只要用户面没有流量一段时间后即释放Iu连接~~~

爱卫生

yonka 发表于 2012-3-11 14:19
回复 爱卫生 的帖子

RRC-Connection-Release timer和SGSN上的Iu activity supervision timer有什么关系吗？ ...

请问下，能找到SGSN上Iu activity supervision timer的默认值吗？如果有的话，那顾名思义，这个是监控Iu连接的，只针对信令，不针对用户面。用户面叫RAB。释放用户面资源就是释放RAB。所以和RRC计时器肯定不一样。

而RRC-Conncetion Release Timer则不一样，不管是控制消息还是用户数据，都需要分配传送信道。所以，应该是信令和payload都监控。中兴那个方案其实是WCDMA的特性，叫动态带宽分配。如果监控到数据发送速率低于门限值，RRC状态可以从CELL-DCH切换到CELL-FACH再到CELL-PCH、URA-PCH。区别就是只有CELL-DCH才会分配到专用的传输控制信道。

imwoohan

爱卫生 发表于 2011-7-27 23:59
谢谢补充。你说的对。follow-on request pending确实有这样的作用。这个flag在2G中也有，在EPC中也有， ...

如果没有携带follow-on request pending，那就意味着在大约44s后，MS和网络侧没有数据往来的话，SGSN也可以发起Iu-Release流程？

爱卫生

imwoohan 发表于 2012-12-4 18:08
如果没有携带follow-on request pending，那就意味着在大约44s后，MS和网络侧没有数据往来的话，SGSN也可 ...

一般来说都是RNC先检测到UE和网络侧没有数据，然后RNC向SGSN发起Iu释放请求，由SGSN来决定Iu的释放的。因为RNC是无线侧网元，最靠近用户。最早感知用户是否有流量。SGSN照道理是感知不到的。另外，RNC上的这个idle timer是远小于44秒的（因为伴随的，还有无线侧资源的释放）。所以，实际上如果没有那个follow-on request pending flag，那UE的MM状态将很快切换到PMM-IDLE。

imwoohan

爱卫生 发表于 2012-12-4 20:37
一般来说都是RNC先检测到UE和网络侧没有数据，然后RNC向SGSN发起Iu释放请求，由SGSN来决定Iu的释放的。因 ...

我回去重新看了下Ts23060 V10的 12.7.3，里面有这么一段描述

1a) If PDP Contextsassociated with the released RABs are using streaming or conversational trafficclass and to be preserved, or Direct Tunnel was established the SGSN sendsUpdate PDP Context Request to the GGSN(s) concerned to establish the GTP tunnelbetween SGSN and GGSN. The No QoS negotiation indication is set in Update PDPContext Request to indicate to the GGSN that the SGSN does not upgrade thepreviously negotiated QoS attributes and that the GGSN(s) shall not negotiatethe QoS attributes. The GGSN(s) update the Address for User Plane and TEID fordownlink data and return an Update PDP Context Response. The GGSN(s) shall notinclude a PCO in the Update PDP Context Response if the No QoS negotiationindication is set. See clause 12.7.3.2 when S4 interface is used.


大致的意思是如果MS已经建立了PDP上下文，或者是Direct Tunnel已经建立了起来。SGSN会向GGSN发起一个更新PDP上下文请求，里面会携带一个No Qos Negotiation信元给GGSN，要求GGSN暂时不修改QOS。并且GGSN也会更新下行数据的IP地址和用户面TEID。

但是随后说的那个GGSN不应该携带PCO在更新上下文的回复里面是什么意思呢？
还有，Dierect Tunnel是指的GGSN直连RNC吧？只有直连RNC，GGSN更改下行数据的ip地址和TEID才有意义。

爱卫生

imwoohan 发表于 2012-12-5 11:20
我回去重新看了下Ts23060 V10的 12.7.3，里面有这么一段描述

1a) If PDP Contextsassociated with the ...

是的。这个场景就是说的再GGSN和RNC已经建好了direct tunnel的情况下，如果Iu连接要释放，那SGSN应该做些什么。这段描述相关的就是，SGSN应帮助用户保持住已经建立的PDP上下文，但Iu连接已经释放了，所以SGSN需要给GGSN发update pdp context request消息来保持住这个PDP上下文，也就是执行一个direct tunnel的回退，将该上下文回退到SGSN和GGSN之间，而不是RNC和GGSN之间。

如果在允许GGSN在update pdp期间协商Qos，那就带上你说的那个no qos negotiation flag。并且不允许GGSN重新分配PCO参数。这样做的好处个人感觉是对用户的影响是最小的，用户体验最好。用户就感觉不到PDP上下文已经切换到SGSN上了。