为什么在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.

爱卫生

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。

爱卫生

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

爱卫生

回复 gaohui2008 的帖子

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

爱卫生

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 发表于 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-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上了。