 |
善于提问，勤于回答，你也是专家
|
 |
问题已开启
(普通问题)
LAC寻呼次数达多少次，就可以裂分？
提问者:
• LAC分裂对寻呼成功率的影响 2015-07-24
• LAC分裂后寻呼成功率下降，求分析，谢谢！ 2015-07-22
• 同一LAC下为何寻呼下发次数不一样 2015-07-17
• 提问：中兴WCDMA 寻呼指标很差一个LAC寻呼成功率90%，另一个78%左右，我再网管上看只有5个跟paging有关，都rnc级的。新人一名，想请教各位，如果想提升寻呼成功率，从哪些方面入手，如果不 2015-05-19
• 交换LAC配错全网寻呼能成功吗？ 2015-04-16
• MSCPOOL内跨LAC会有位置区更新吗，更新会导致收不到寻呼吗？ 2014-09-19
• 为什么寻呼量最小的小区决定了LAC寻呼量，求机制原理！ 2014-07-01
• LAC区寻呼量 2014-04-09
• LAC分裂后寻呼成功率下降，求分析，谢谢！ 2015-07-22
• 同一LAC下为何寻呼下发次数不一样 2015-07-17
• 提问：中兴WCDMA 寻呼指标很差一个LAC寻呼成功率90%，另一个78%左右，我再网管上看只有5个跟paging有关，都rnc级的。新人一名，想请教各位，如果想提升寻呼成功率，从哪些方面入手，如果不 2015-05-19
• 交换LAC配错全网寻呼能成功吗？ 2015-04-16
• MSCPOOL内跨LAC会有位置区更新吗，更新会导致收不到寻呼吗？ 2014-09-19
• 为什么寻呼量最小的小区决定了LAC寻呼量，求机制原理！ 2014-07-01
• LAC区寻呼量 2014-04-09
问题答案
( 7 )
为未开多CCCH信道的平时寻呼到20W次，就要考虑分裂了。开了多CCCH的30W吧！
回答者：
clang107
回答时间：2011-12-31 10:53
15
20
超过18w的话就预警了
回答者：
吴家大院777
回答时间：2012-01-05 14:45
12
15
华为的一般20万吧，卡特的是15万次
回答者：
xshhua
回答时间：2012-01-11 16:50
19
13
一般没开多CCCH的20W左右，具体可以根据话统寻呼删除的多少来判断。
回答者：
zhangying8219
回答时间：2012-01-11 17:54
15
13
MFRMS、AGBLS、单复帧CCCH块数是绝对寻呼能力的依据，空口采用TMSI（4 MS）还是IMSI（2 MS）寻呼是提高无线容量的方式。比如MFRMS=2、AGBLK=1、单复帧CCCH块数=9，那么寻呼块数为2*（9-1）=16，每秒寻呼块数为16*1000/（2*51*4.615）=33.99块/s。假如采用TMSI寻呼，1个小时寻呼容量大概为：33.99*4*3600=489452。当然该值为理论计算值。
回答者：
jskyt
回答时间：2012-01-11 21:56
13
14
学习了，20万次可以分裂
回答者：
qianlifeixue
回答时间：2012-01-11 23:42
14
19
要根据寻呼利用率，寻呼拥塞率综合来判断：
1.1 寻呼扩容判定
寻呼拥塞目前RAN侧不能区分寻呼拥塞导致的寻呼失败的业务类型，所以我们可以从核心网和RNC侧综合进行考虑。MSC上的CS域会话类业务寻呼成功率要作为重要的指标。从目前网络负载看，很多局点的话务量都不高，但还是有寻呼拥塞发生，原因是PS域的一些业务引起的对所有用户的群呼导致寻呼消息的大量突发导致。目前RNC的处理在拥塞时会导致会话类等对用户感知大的寻呼的大量丢失，从而导致语音等时延敏感业务呼叫时间拉长，或呼叫失败，从而导致用户感知下降。针对这类原因，单纯扩容不能完全解决问题，对寻呼消息的分类处理是关键（产品5.0之前版本没有实现该功能）。
RAN侧的寻呼拥塞采用话统数据进行判断：当网络用户数逐渐增多，话务量逐渐增大时，首先看寻呼资源利用率是否达到门限，如果达到门限，立即扩容。如果没达到门限，由于目前话统粒度的限制，还需要查看寻呼拥塞率。如果寻呼拥塞率大于5%，立即扩容。当寻呼资源利用率没有达到扩容门限，而拥塞率较大时，可能是由于并发大量寻呼导致，且大部分是PS寻呼。目前产品的处理机制，一旦发生寻呼碰撞，不区分CS和PS业务，只按寻呼先后顺序处理。如果这种并发大量寻呼经常发生，为了保护用户感受，建议进行寻呼扩容。后期如果产品实现了按寻呼原因，业务来处理碰撞的寻呼消息，可通过评估CS域会话类寻呼消息拥塞率来决定是否进行寻呼扩容。
表 2‑4寻呼扩容判断标准
1.1 寻呼扩容判定
寻呼拥塞目前RAN侧不能区分寻呼拥塞导致的寻呼失败的业务类型，所以我们可以从核心网和RNC侧综合进行考虑。MSC上的CS域会话类业务寻呼成功率要作为重要的指标。从目前网络负载看，很多局点的话务量都不高，但还是有寻呼拥塞发生，原因是PS域的一些业务引起的对所有用户的群呼导致寻呼消息的大量突发导致。目前RNC的处理在拥塞时会导致会话类等对用户感知大的寻呼的大量丢失，从而导致语音等时延敏感业务呼叫时间拉长，或呼叫失败，从而导致用户感知下降。针对这类原因，单纯扩容不能完全解决问题，对寻呼消息的分类处理是关键（产品5.0之前版本没有实现该功能）。RAN侧的寻呼拥塞采用话统数据进行判断：当网络用户数逐渐增多，话务量逐渐增大时，首先看寻呼资源利用率是否达到门限，如果达到门限，立即扩容。如果没达到门限，由于目前话统粒度的限制，还需要查看寻呼拥塞率。如果寻呼拥塞率大于5%，立即扩容。当寻呼资源利用率没有达到扩容门限，而拥塞率较大时，可能是由于并发大量寻呼导致，且大部分是PS寻呼。目前产品的处理机制，一旦发生寻呼碰撞，不区分CS和PS业务，只按寻呼先后顺序处理。如果这种并发大量寻呼经常发生，为了保护用户感受，建议进行寻呼扩容。后期如果产品实现了按寻呼原因，业务来处理碰撞的寻呼消息，可通过评估CS域会话类寻呼消息拥塞率来决定是否进行寻呼扩容。
表 2‑4寻呼扩容判断标准
|
参考项 |
扩容指标 |
网络资源利用率预警 |
扩容依据 |
扩容门限(TMSI) |
|
寻呼扩容 |
寻呼资源利用率 |
一周内累计超过3次或者两周累计超过4次，需要发出扩容预警 |
充分条件 |
>70% |
|
寻呼拥塞率 |
同上 |
充分条件 |
>5% |
回答者：
super1943
回答时间：2012-01-14 00:03
17
14
| 联系我们 - 问通信专家 | Powered by MSCBSC 移动通信网 © 2006 - |