根据本人有限的能力，计划依次展开
TBF建立成功率、
EGPRS Link Quality Control、
AMR、
PCU容量规划、
TRH容量规划
等话题的讨论，希望C友们在顶贴过程中有疑问的可以和本人讨论，指出本人理解有偏差的地方，大家共同提高。
另外版主和管理员也不需要担心重复内容，本人不会完全cpoy一切论文、报告、出版物里的原始文字。所讨论内容都是本人对某一话题的有限理解，即使是本人自己写的众多报告，也不会完全copy在这发出。另外对于一些图表本人也尽量自己再加工。
做这些的好处一降低侵犯知识产权的风险，二是本人自己码字的同时也更能达到温故而知新的效果，三是通过自己首先的思考过程能够理清主次给新手一些借鉴。

[ 本帖最后由 molanrotbio 于 2011-5-27 11:04 编辑 ]

寻呼请求的来源：
语音业务不需要做过多介绍；
数据业务也会有寻呼请求，数据业务中MS有3种状态（IDLE、STANDBY、READY），当MS处于STANDBY状态，而网络侧有需要发送数据或信令给MS的时候，SGSN将会于MS所在的路由区里发起寻呼请求，而MS完成寻呼响应后，状态会转为READY，SGSN接收到寻呼响应也会将MS的转为READY，自此数据得以发送到MS。
寻呼统计：
在BSC侧：BSC.TOTPAG是CS域的寻呼请求总数，BSCGPRS.PAGPSBSC是PS域的寻呼请求总数。在MSC侧：做了MSCPOOL后，LOCAREAST.NLAPAG1LOTOT里OBJECT_ID为某LAC的CS域该BSC一次寻呼请求总次数，LOCAREAST.NLAPAG2LOTOT里OBJECT_ID为某LAC的CS域该BSC二次寻呼请求总次数。PS域PAGING.NPAG1GPRSTOT,NPAG2GPRSTOT分别为一二次寻呼请求总次数。

呵呵，无线的给力，加油哦！

]寻呼过程：
[attach]168396[/attach]

上附件。。。。。。。。。。。。

从楼主一楼的前半部分的字里行间，我肿么觉得你是想和大家讲讲你那风花雪月的日子、让我们在寂寞的出差的日子里YY，发泄壮年的精力、释放多余的体力！可后半部分，楼主让我失望了。

寻呼信道配置：
在打了MultipleCCCH功能后，单小区最高可配置4个CCCH，我们知道原有的CCCH配置在BCCH0时隙上，功能打开后，还可在指定的BCCH2,4,6等时隙上依据CCCH负荷的评估配置数量不等的CCCH信道。通过RLCCC来定义CCCH数量。
在下行方向上CCCH是由AGCH和PCH复用的，在最初的规范设计里，AGCH是要优于PCH的，因为当时不存在数据业务的问题，因此从下行方向来看，PCH的量总是大于AGCH，因此AGCH要优先于PCH，并且为了更彻底保障AGCH的配置，通过AGBLK参数来确保CCCH块有最少的预留给AGCH的块数。当然我们现在用辩证的发展的眼光来看，在GPRS/EDGE配置在GSM网络上，数据业务的市场也发展的如火如荼，你和你都已经习惯于手机qq手机上网手机证券之后，每一个TBF的建立、每一次数据发送的请求、每一个你使用手机上网的一个点击都产生一次Immediate Assignment消息。海量的立即指派消息使得AGCH有可能充斥了CCCH的9个块。把寻呼消息扼杀在BTS的队列摇篮里。一次又一次的AGCH风暴刮过后，你发现在你所处的位置，你的老板、你的老婆、你的朋友会投诉你手机不开机，你的电话打不通，而你是何等的冤枉。因此你愤怒的...好吧本人不是为了赚稿费的，此处省去一些字吧。总之现在时代变了，你打了语音优先的补丁也无济于事，稍后我们
通过CCCH的评估会发现AGCH的风暴是何其大的规模。至此策略无济于事，实实在在的多给配置才是王道。
贴士：因为CCCH将会固执的占用2、4、6时隙，因此找个时间统一把SD的TN该到1、3、5吧。
[attach]168413[/attach]

风花雪月属于纯技术活，个体差异较大，硬件配置改造成本高，也包含不菲的软件成本，不能公开讨论。
但是每个领域都有先行者，哥们你如需瞻仰，可****去XX看直播。

因此No Combined BCCH/SDCCH每秒的blocks数=(9-AGBLK)/0.2354。

寻呼方式：
按次数分，一次寻呼、二次寻呼；
按方式分，TMSI寻呼、IMSI寻呼；
按范围分，LOC寻呼、GLOBAL寻呼；
通常的网络设置是，2次寻呼，第一次用TMSI作loc寻呼，第二次用IMSI作global寻呼。
只从纸面上就能理解，GLOBAL比LOC范围大，扩大范围能增加寻呼成功率，但是会增大系统负荷。

CCCH块的使用：
结合前面寻呼信道配置的介绍。
一个CCCH每秒块数为9/0.2354=38.25。每小时块数为38.25*3600=137700。
对于这些块的使用，一个立即指派（CS 或PS）都占用一个块，而paging消息对CCCH块的占用如下：
[attach]168699[/attach]

是以一个块可发4个TMSI方式的PAGING消息，或者2个IMSI方式的PAGING消息，或者混合方式的2个TMSI和一个IMSI。

寻呼瓶颈
A接口信令负荷的评估：
采集的Object type:C7SL，涉及的COUNTER:NSIFSRE、NMSURE、NSIFTR、NMSUTR、ASLDUR。
A接口信令链路不够引起与无线性能相关的切换、寻呼、TCH分配等诸多问题，信令负荷在20%以下则是非常健康的状态。
信令负荷计算公式：
64K 链路：
接收负荷<NMSURE>*6+<NSIFSRE>)*8/(<ASLDUR>*64*1024)
发送负荷<NMSUTR>*6+<NSIFTR>)*8/(<ASLDUR>*64*1024)
2M 链路
接收负荷<NMSURE>*9+<NSIFSRE>)/(<ASLDUR>*8*31*1024)
发送负荷:(<NMSUTR>*9+<NSIFTR>)/(<ASLDUR>*8*31*1024)

寻呼消息在BSC里的处理：
最常用的APZ 212 30处理能力为每秒50000次寻呼，这对于当前各地普通网络的寻呼量来说不存在顾虑，有问题的话则可考虑LAC割接。
TRH处理PAGING消息。对TRH评估分为TRH设备占用和TRH负荷两方面。
对TRH设备占用的评估就是实际连接在该TRH上的TRX数/该TRH类型理论支持的TRX数。由于是半永久连接，在同一个BSC里各TRH上连接的TRX并不是均匀分布，对此TRH有自己的过载保护机制，另外还能激活TRH的动态负荷调节功能。
TRH负荷则是对TRH处理能力的评估，推导公式为MAXLOAD－70×LOWCAP/CAP [％]
整个TRH部分在寻呼这个话题里就点到为止，今后有时间可以做更详细的讨论。

Abis接口对PAGING的处理
Absi接口使用LAPD信令.
LAPD过载对网络的影响顺序依次是测量报告、位置更新、PAGING等。这部分的影响主要是信令压缩。要保障网络的健康运行，通常建议不使用信令压缩。（有时间再铺开讨论：））

BTS处的瓶颈其实和空口资源密切相关，网络侧有AGBLK和MFRMS以及BCCHTYPE 三个参数影响到这个部分。AGBLK前面以及介绍了。其他的东西其实没太多新意了，劳烦新手参考论坛资料，或者市面上GSM很火的绿色封面的书、蓝色封面的书（不打免费广告啊）。

最后就是CCCH信道了。

CCCH信道评估
前面讲明了一个CCCH一小时有137700个块，一个立即指派占一个块，4个TMSI方式的PAGING占一个块/2个IMSI方式的paging占一个块。
因此对CCCH的评估只需要找到COUNTER就OK了。
PCH的采集的OBJTYPE：LOCAREAST（前面已经介绍）
AGCH采集的OBJTYPE：CCCHLOAD
阿莱士说CCCHLOAD有：
CSIMMASSNumber of CS IMMEDIATE ASSIGNMENTS sent on the CCCH
REJCSIMMASSNumber of CS IMMEDIATE ASSIGNMENTS REJECT sent on the CCCH
PSIMMASSNumber of PS IMMEDIATE ASSIGNMENTS sent on the CCCH
REJPSIMMASSNumber of PS IMMEDIATE ASSIGNMENTS REJECT sent on the CCCH
DISCIMMASSNumber of discarded 44.018 IMMEDIATE ASSIGNMENT (for CS and PS) messages in the BTS.
因此 如果第一次TMSI，第二次IMSI则：
PCH占用信道数＝一次寻呼次数*0.2354/3600*(1+2*二次重发比例)/4
一次寻呼次数＝Nlapag1lotot+Npag1gltot
二次重发比例＝（Nlapag2lotot+ Npag2gltot）/（Nlapag1lotot+ Npag1gltot）
AGCH占用信道数＝（Csimmass+Psimmass+Discimmass）* 0.2354 / 3600
所以小区的CCCH负荷=（PCH占用信道数+AGCH占用信道数）/ 9
由于AGCH对PCH的优先，因此评估小区的CCCH负荷需要考虑AGCH信道数/PCH信道数
对于AGCH信道数/PCH信道数可以依据各地网络的规律来考虑AGCH信道数/PCH信道数大于某一个值时，小区的CCCH负荷的预警门限，和小于某一个值时的预警门限。


好了寻呼瓶颈和CCCH信道评估这个话题就讨论到这，如果你仔细理解的话，那么LAC最大寻呼容量、当前寻呼负荷等等很多东西就能推导出来了。
下个话题讨论TBF建立成功率吧。

唉，咋一看还比较激动，看看后面才知道白鸡冻了！

这帖子不错，发言讨论很踊跃，学习了！

波哥给力 我顶