51学通信技术论坛

标题: Ready Timer(T3314)定时器优化 [打印本页]

作者: 爱卫生 时间: 2011-6-26 11:57:06 标题: Ready Timer(T3314)定时器优化

本例主要讨论为什么要进行Ready Timer的优化及措施。和具体厂家产品无关。因为各个厂家都支持T3314的调整。

一问题：
Ready定时器过短，导致寻呼次数增多。
下面是一个包含寻呼消息的用户信令跟踪：18:53:29秒MS向SGSN发送了TCP ack消息，18:55:43秒SGSN有下行数据向MS发送，触发了寻呼消息，说明SGSN的MM状态已经从ready转为standby。寻呼消息与上一次上行的TCP ack消息的时间间隔达到74秒，超过了ready定时器(T3314)设定的44秒，MM状态从ready转为standby。如图一所示：

[attach]623[/attach]

图一 Ready Timer未优化前

二分析
Ready定时器作用是，用于控制MS与SGSN之间无LLC PDU传输后，在Ready状态下能够停留的最长时间。该定时器超时后，手机进入Standby状态。
当SGSN向一个处于STANDBY状态的MS传输数据之前，SGSN需向MS发送一个寻呼请求，MS收到寻呼请求后将回送任一有效的LLC帧作为应答，将SGSN中的MM上下文由STANDBY状态转为READY状态。因此，ready定时器的长短与寻呼消息次数密切相关。
统计paging消息与上一个LLC PDU之间的时延，MS平均空闲时间是83秒，平均空闲时间低于83秒的占据72%，而SZ SGSN1 ready定时器当前取值是44秒，显然偏小。

三优化建议与效果
Ready定时器从44秒修改为83秒，调整后2G SGSN 忙时寻呼次数从平均1150663次/小时下降到平均762412/小时，寻呼次数下降了388251次/小时（大约33.74个百分点），有效降低了系统负荷。效果图如图二所示：

[attach]622[/attach]

图二 Ready Timer优化后2G寻呼次数变化图

作者: cmcc_demon 时间: 2011-6-26 19:47:27

“统计paging消息与上一个LLC PDU之间的时延，MS平均空闲时间是83秒”这个是类似QQ、飞信的心跳时间么？如何统计的？想知道。

作者: 爱卫生 时间: 2011-6-26 21:07:33

cmcc_demon 发表于 2011-6-26 19:47
“统计paging消息与上一个LLC PDU之间的时延，MS平均空闲时间是83秒”这个是类似QQ、飞信的心跳时间么？如何 ...

这个优化我没有参与。不大清楚。
但这个83秒我觉得应该就是你说的类似QQ、飞信的心跳时间（可能还有更多的应用也是这样吧，例如MSN、还有很多手机杀毒的要定期更新什么的等等）。否则不可能说手机发了一个IP包给应用服务器，MM状态切换到Ready，然后有数据交互，却要等83秒才收到下行数据。这不大现实。IP承载网再烂也不会这么大延迟的。能够解释清楚的就是心跳包了。
  怎么统计，确实感觉比较神奇。要计算这么多手机平均空闲时间工作量是比较大。但依据上面的说明，我猜流程应该是这样：
1 针对每个手机都启动一个计时器，当这个时间对MS1来说是T1。这个计时器当MS切换到Ready状态下开始计时。（即MS发送了一个上行LLC PDU给网络侧或直接附着成功）。
2 从T1开始后，从SGSN侧收到了GGSN过来的关于这个MS的下行数据的时间。假设是T2。
3 用T2-T1就是MS1的空闲时间。
4 所有的MS统计出来后求平均值。
  例如：MS1在10:00:00发送LLC PDU给网络侧，MM状态就切换到Ready。当10:00:50的时候，MS1收到了切换到Ready状态后的第一个下行数据（这里不要管SGSN是否要对MS进行寻呼）。那关于MS1的空闲时间就是10:00:50 减去 10:00:00 = 50秒。
  以上是我的理解，谨供参考。

作者: gprssanling 时间: 2011-7-16 13:04:47

cmcc_demon 发表于 2011-6-26 19:47
“统计paging消息与上一个LLC PDU之间的时延，MS平均空闲时间是83秒”这个是类似QQ、飞信的心跳时间么？如何 ...

如何统计的？

有专门的软件把包数据和数据库结合，计算这个时延就很简单了。。

作者: z36306610 时间: 2011-9-28 10:00:39

这个还是比较容易统计的，定义一个流程记录下第一次paging之后最后一个包的时间，在定义第二次paging的起始时间，将这两次时间相减就可以得到一个用户的2次paging的时间间隔，有专门的工具可以统计，我做过这方面的统计，呵呵，纠结在sql语句上，最后没办法用excel处理的。
另外3G网络中可以通过cell-pch增加用户处于pmm-connect的时长，用户从cell-dch到cell-fach状态通常为5s（根据rnc和sgsn协商的Qos决定），cell-fach到idle状态时间通常为2s，用户处于idle状态后iu接口RAB和iub的RB资源就会释放，如果这时候有paging消息的话需要重新建立rrc和rab，所以cell-pch这个feature还是比较重要的，现在sy这边没开这个feature，所以对iu资源和RRC资源的浪费比较严重。所以我们在推销这个feature，呵呵！

作者: 三国杀小王子 时间: 2012-1-3 19:15:16

goog,顺便请问爱立信的ready timer（T3314）所对应的参数是什么？

作者: 爱卫生 时间: 2012-1-3 19:36:53

就是规范里的ready timer啊。所有厂家都是一样的。默认44秒。

作者: lizq8285 时间: 2012-1-10 17:14:01

Gb_T3314-ReadyTimer -val 60，在爱立信的alex有

作者: 杨昭 时间: 2013-12-26 12:40:09

爱卫生发表于 2011-6-26 21:07
这个优化我没有参与。不大清楚。
但这个83秒我觉得应该就是你说的类似QQ、飞信的心跳时间（可能还 ...

爱总，我总觉的应该是手机切换到ready状态后，发送完或者接受完最后一个LLC PDU时开始计时，即就是T3314启动的那个时刻开始计时（标记为T1），直到手机从SGSN侧收到了GGSN过来的关于这个MS的下行数据的时间为止(标记为T2)，T2-T1为平均空闲时间。
不知道我说的对不对？

作者: 爱卫生 时间: 2013-12-26 17:06:00

杨昭发表于 2013-12-26 12:40
爱总，我总觉的应该是手机切换到ready状态后，发送完或者接受完最后一个LLC PDU时开始计时，即就是T3314启 ...

我的感觉没那么复杂。其实作者在图例里应该已经给出了什么是平均空闲时间，在这个例子里是74s。而平均是83s。也就是图例中2105到2116中间的时间间隔，可能图比较模糊了，但依稀可以看清楚上面的一点注释。2105是PCU--SGSN也就是MS发送的上行数据。2116是SGSN---PCU的寻呼，也就是由下行数据要发给手机，但MM状态已经变为standby了，所以要寻呼。如果调整成83s，那在本例中，SGSN就不需要在2116处对用户发起寻呼。

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