Ready Timer T3314(就绪定时器)

爱卫生

就绪定时器T3314的长度在MS和SGSN中相同，由SGSN通过Attach Accept、Routing Area Update Accept等消息来控制。在MS发送LLC PDU（比如MS响应SGSN寻呼）后，MS中的该定时器将被复位；在SGSN收到一个正确的LLC PDU（比如SGSN收到MS的寻呼响应）后，相应的就绪定时器就被复位。当就绪定时器设置为0时，MS应该回到STANDBY状态；当就绪定时器全1编码时，就绪定时器功能被禁止。

T3312 T3314
在MS和网络中，对于每个分配的P_TMSI，都有一个T3314来控制小区的更新过程；当就绪定时器正在运行或是已经被禁止时，MS在每次选择了一个小区之后都要进行小区更新过程；当就绪定时超时：当穿越路由区域边界时，执行路由区域更新过程；当选择了一个新小区之后，不执行更新（所有其他的GMM过程不受T3314影响）
两种方式启动T3314：在MS中，当GMM实体收到来自底层的指示，表明其已经在无线接口上发送了一个LLC帧；在网络中，当GMM实体收到来自底层的指示，表明其已经成功接收到一个LLC帧。

我的理解：
ready timer不能设置太短，否则会增加寻呼的负荷，因为用户很快就切换到standby状态了。另外，现在大屏智能手机也越来越普遍。一页可以显示好多信息，用户可能要好几分钟才能翻页。这样就会增加手机的负荷。原来默认44秒就不合时宜的，可以适当加长。因为原来规范取默认44秒时是当时还没有这样丰富的手机应用的。可见时代真的是在发展啊。

但ready timer也不能设置的太长。因为这样会增加很多小区更新的信令流程，也会增加负担。因为在ready状态下是要做小区更新的。而在standby状态下只做RA更新，而不做小区更新。所以standby状态的负荷要小一些。

爱卫生

回复 Albert 的帖子

   不用客气。交流吧。我知道的我就很快作答。我不懂的我再去问别的朋友。不用客气的。
是这样的，在ready状态下，SGSN是知道MS在哪个小区的，在ready状态下，MS需要做的就是小区更新，通知网络侧关于小区的变化。这样，如果MS正在上网，有下行数据要发给手机（例如一个手机报），SGSN就可以直接把这个数据发给手机了，而不需要去做寻呼（寻呼是在整个路由区RA下对手机的一个广播消息），因为SGSN知道MS的确切位置而不用去找你。你可以把这种广播想像成由100台LAN Swtich组成的一个广播域，如果有一个MAC地址要泛洪处理，是不是会对局域网造成很大的负荷呢？
    而如果ready timer过短，则MS会很快切换到standby状态，那么SGSN在这种状态下只知道MS在哪一个路由区（RA），并不知道MS在哪一个小区，这样如果有下行数据要发的话，就只能对MS进行寻呼了。寻呼的作用就是找到MS在哪个小区。而且寻呼的范围是整个RA。一个RA的范围是比较大的，因为它是由很多小区组成的。所以这种寻呼对空口的负荷其实是比较大的。咨询过无线的朋友，一个小区的覆盖范围差不多是10到几十公里的范围。
    因此为了减少这种寻呼对空中接口负荷的影响，ready timer不能设置得过短。
    但也不能设置得太长，因为这样MS将很长时间都停留在ready状态，而ready状态是要做小区更新的。如果这个用户不断的小区间来回穿越，这样负荷也会很高。
   因此，根据用户的行为习惯调查，按用户的行为习惯，取了个折中值，44秒。就是假设一个用户看手机报或者新闻的话，要44秒翻页。
   对，MS发送任何一个LLC PDU（代表LLC层的上层数据）来切换到ready状态，在3G的PS核心网中，用service request流程来取代，请求建立MS到SGSN之间的空口连接。这是后话了。

爱卫生

天高云淡ah 发表于 2011-7-9 15:20
24008讲，Ready Timer T3314的启动条件：
The READY timer is started:
-in the MS when the GMM entity  ...

  这句话我感觉没有问题啊。我是这样理解的，根据上述规范的要求。只要手机收到了上层的指示要在空口发送一个非空的LLC帧，就应该启动Ready Timer，换句话说Ready Timer就应该从44秒开始往下计时一直到0。
  非空的LLC帧代表的是手机要向网络侧发送数据payload了，因此按照协议中对MM状态切换的规定，MS在发送非空LLC帧时，将把自己的MM状态切换成Ready，因此启动Ready Timer就是理所当然了。
  但你提到的，“LLC每发一个LLC非空帧，T3314都要启动一次，那发送数据时，会有大量的LLC非空帧发送，将会导致T3314频繁的重启”。这个不会发生。因为协议规定的是，发非空LLC帧的时候，是Start Ready Timer，而并不是说要Restart Ready Timer或者Reset Ready Timer。否则我觉得你提到的这个是不成立的。除非规范说明，在后续的LLC非空帧发送时，将Restart T3314。
协议只是说，有非空帧LLC发送时start T3314，如果后续还有非空帧LLC发送的话，手机判断出T3314已经启动了，就不会再start了，因为这时如果在打开一次，就叫restart，而不是start。start和stop是对应，就是一个开关，On和Off。Start相当于打开这个开关，而Restart相当于先将开关置为Off，然后再打开。
  这是我的理解，仅供参考！

爱卫生

回复 天高云淡ah 的帖子

   实在是不好意思。上面的答案可能误导你了。其实24.008中关于发送非空LLC帧Start Ready Timer没说错，如果没有启动的话，就启动。如果已经启动了，则是Reset还是Restart在24.008中并没有说。
   我重新找了下，发现在23060里有关于这部分的详细说明：“The READY timer shall be reset and begin running in the MS when an LLC PDU is transmitted, and in the SGSN when an LLC PDU is correctly received”。它用的是过去式。也就是说MS在发送了一个LLC PDU时，就应该将T3314进行Reset并保证是running状态，同样，SGSN在收到这个LLC PDU后，也应将T3314进行reset并继续running。
   也就是说，举个例子。手机在第1秒，发了第一个LLC PDU，ready timer启动，从44秒计时。到了第2秒，T3314计时为43秒，手机发了第二个LLC PDU，这时按照23060的规定，应将43秒重置为44秒并继续往下计时。也就是说，只要这个手机不断的发LLC PDU，则T3314应该一直处于40夺秒的样子（假设无线环境好的情况下），而不是说等到Ready Timer降到0的时候，MS将MM状态切换到Standby状态，然后又被一个LLC PDU的发送切换到Ready状态，并重新启动Ready Timer。这样子反而是不合适的。
   因此，纠正一下我前面说的。请以23060的为准。而且这个说法和24008的讲法并不矛盾。24008只是说要启动，没提reset。我觉得24008说start ready timer，是不是就是要保证ready timer在running的状态呢？
  所以说，你之前的说法应该就是对的。不断的LLC PDU发送会不断导致Ready Timer被重启。但我想了下这是没有办法的是啊，除非Ready Timer处于not running的状态才不会消耗资源。但Ready状态下T3314是一定要运行的。那要么就是被不断的重置，要么就是从44往下一直数到0，后面这种方式也得耗资源啊。这两种方式应该差不多的。而且如果是后一种方式，如果ready timer超时了，手机和网络侧将MM状态切换到standby，然后重新再将ready timer启动也是多了一道程序，也很麻烦啊。所以我觉得这也是没有办法的事啊！

  第二个问题，原语有啊。在LLC规范44064中定义。一个用于确认，一个是非确认模式。摘录如下：
7.2.2.5 LL-DATA
The LL-DATA primitives shall only be used for LLEs in ABM. The following operations are defined:
- LL-DATA-REQ shall be used to request the confirmed transmission of an L3 PDU to the peer. QoS Parameters in the SGSN includes precedence class, delay class, and peak throughput. QoS Parameters in the MS includes peak throughput. QoS Parameters is defined as part of the Quality of Service information element in 3GPP TS 24.008 [8a]. Radio Priority indicates the radio priority level to be used by RLC/MAC.
- LL-DATA-IND shall be used to deliver a correctly received L3 PDU to layer 3.
- LL-DATA-CNF shall be used to confirm the delivery of an L3 PDU to layer 3 in the peer. The Reference parameter shall be set to the same value as the Reference parameter received in the corresponding LL-DATA-REQ.
7.2.2.6 LL-UNITDATA
LL-UNITDATA-REQ shall be used to request the unconfirmed transmission of an L3 PDU to the peer. QoS Parameters in the SGSN includes precedence class, delay class, reliability class, and peak throughput. QoS Parameters in the MS includes peak throughput and reliability class. Reliability class indicates whether the UI frame carrying the L3 PDU shall be transmitted in protected or unprotected mode, and whether RLC/MAC acknowledged or unacknowledged mode shall be used. Radio Priority indicates the radio priority level to be used by RLC/MAC. Cipher indicates whether the UI frame shall be ciphered or not.
LL-UNITDATA-IND shall be used to deliver an L3 PDU received in a UI frame to layer 3. Cipher indicates whether the received UI frame was ciphered or not.

爱卫生

回复 天高云淡ah 的帖子

  你说的对啊。我也觉得应该是有这样的问题。但怎么优化比较合适呢？
  比如类似DHCP中，IP地址使用到期，可以续租。那等ready timer快到期时，如还剩5秒的时候，如果还有LLC PDU传递，则原语通知ready timer续约44秒？那其实也不合适啊。因为万一这个用户在5秒后，没有数据发送，不是要白白启动44秒？
  后面你说的那个原语，我不大确定哦。但根据24008提到的"when the GMM entity receives an indication from lower layers“，这也让我比较困惑，如果这样的话，那原语应该就是44064中7.2.1章GMM-LLME原语中涉及到的9个原语中的一个，但确实，仔细看看。这9个又都不像是。你说的对，我刚才提到的LL-DATA是LLC和LLC层间的通信原语。
  还有一点，我也是不大明白，就是为什么GMM要从低层收到一个指示才开启ready timer，根据协议栈的封装顺序，不是应该GMM通过原语调用LLC的服务吗？应该LLC层收到通知才对啊，怎么感觉反过来了？
  一起讨论哈，谢谢。我也学习了不少。

爱卫生

回复 天高云淡ah 的帖子

  有道理，学习了！谢谢分享。等有机会我去请教下其他高人。

爱卫生

回复 linyuxuan 的帖子

  Ready Timer确实是允许协商的。其中MS在附着请求中携带的叫requested ready timer,而SGSN在Attach accept消息里携带的叫做Negotiated Ready Timer,这个timer在TS24.008的10.5.7.3中有明确的字段规定，值有最大限制。是5个bit。单位可以是2秒的倍数或者是分钟的倍数。
  但通常来说，MS都没有请求ready timer，都是由网络侧来分配。所以实际环境中，大多数情况下都是由SGSN来分配的。但有一个例外，就是你提到的红字部分。但选B的话又比较牵强。所以我觉得还是应该选A。