传输信道 PCH 逻辑信道 PCCH TF0 TF1 TF0 TF1 TF2 TF3 TF4 TFS 0×240 1×240 0×171 1×171 2×171 3x171 Coding type CC 1/2 CC 1/2 TF_ NUM 3 7 TTI 20 20 CRC 16 16 RM 210 200 FACH DCCH DTCH BCCH CCCH 4x171 5x171 6x171 TF5 TF6 此时，PCH信道编码后的数据为264bits；FACH信道编码后的数据为1146bits，还可以使用5个SCCPCH配置方案，具体信息如下
SCCPCH配置方案 5个S CCPCH 有效容量（一个无线帧） 864bits PL 0.60 PCH打掉 96bits FACH打掉 451bits 需要强调的是，PCH与FACH复用时，PCH数据调度的优先级高于FACH数据调度的优先级。如果PCH数据量较小，FACH可以使用NPCH对应时段的物理资源。 4.1.5 共享信道配置与容量说明
HSDPA系统资源配置包括HS-DSCH的下行时隙个数、上行伴随DPCH信道、上行反馈信道HS-SICH个数、下行伴随DPCH信道和下行公共控制信道HS-SCCH个数。
随着系统分配的下行HS-DSCH时隙个数增多，系统的吞吐速率就会增加并且符合成倍的增长关系。单载波情况下典型时隙比例和峰值吞吐率关系如下
时隙比例 HS-DSCH时隙数目 峰值速率 3：3 <=2 <=1.12Mbps 2：4 <=3 <=1.68Mbps 1：5 <=4 <=2.24Mbps HS-SCCH和HS-SICH的信道个数会对多用户小区吞吐量有一定的影响。如果配置HS-SCCH/HS-SICH信道个数增多，小区的吞吐量也会有所增加。由于TD-SCDMA系统的HSDPA在每个TTI（5ms）调度一次，所以当配置一对HS-SCCH/HS-SICH时，每秒钟最多调度200次，而当配置多对HS-SCCH/HS-SICH时，在HS-DSCH资源有剩余的情况下就可以在同一TTI调度多个用户，从而提高资源利用率，使系统吞吐量得到提高。然而配置多对HS-SCCH/HS-SICH信道需要占用更多的资源，因此必须考虑小区吞吐率及共享控制信道资源
第 36 页 共 220 页
占用率之间的平衡。一般情况下，当配置的HS-PDSCH时隙数少于3个时，建议只配置一对HS-SCCH/HS-SICH信道。
目前，H载波采用2：4配置，HS-DSCH时隙数目配置为3，同时，配置2对HS-SCCH/HS-SICH信道。按照目前配置，单载波最大支持用户数受限于下行伴随DPCH信道的数量，为6个。
当共享信道需要扩容时，首先考虑伴随DPCH帧分，若采用1：2帧分，则单载波最大支持用户数可以提高至12个；其次，可以考虑增加H载波数目。 4.1.6 LAC与RAC负荷优化
空口寻呼受限计算
对于短消息的寻呼，其寻呼过程与普通的话音业务寻呼相同，因此在计算时可以将短消息的话务量等同于话音业务的话务量进行合并计算，在下面的计算中按照现网配置来计算：
PICH：SF=16，每个子帧44个符号，一帧中包含：44×2(2个子帧)×3（3个码道）=264符号，每个寻呼指示因子的长度可以为2、4 或8 个符号（长度对应于4、8 或16个比特）。目前，寻呼指示长度设置为8，PICH的重复长度为2，PICH的重复周期为640ms。因此，PICH容量为2*22*1000/640=68.75/秒/小区。
PCH：1个码道的单个寻呼分组 传输信道配置1×240。一个寻呼分组最多能放下寻呼记录数为（其中７位是用户面对寻呼记录的编码）IMSI，（240*1-7）/72=3.3，TMSI，（240*1-7）/40=5.9。每个寻呼分组最大容纳的IMSI个数为3，TMSI个数为5个。按照目前宁波配置的PBP=64帧，重复因子=1计算，寻呼分组=8计算，IMSI寻呼能力＝3×8/0.64/1=37次/秒，TMSI寻呼能力=5×8/0.64/1=62次/秒。
可以看出PCH能力小于PICH，所以寻呼能力由PCH能力决定，理论上每小时寻呼能力大于37×3600=133200次/H，小于62×3600=223200次/H。
大唐寻呼容量预警机制如下：
? 当一周忙时最大寻呼量超过空口寻呼容量的55%时，进入黄色预警，考虑进行空口
第 37 页 共 220 页
寻呼容量扩容或者LAC分裂；
? 当一周忙时最大寻呼量超过空口寻呼容量的70%时，进入红色预警，必须尽快进行
空口寻呼容量扩容或者LAC分裂。
考虑到寻呼容量使用率为70%，现网寻呼容量在93240～156240次/H之间。 4.1.6.1 基于核心网统计数据的寻呼容量评估
统计5月4日和5月5日核心网寻呼数据（只能统计CS寻呼情况），按LAC分析，平均每天寻呼情况如下：
LAC 55072 55073 55074 55075 55076 55077 55078 55079 55080 55081 55082 55083 55084 55085 55086 55087 55088 55089 55091 55092 55093 55094 55096 全网 寻呼尝试次数 242200 388157 495540 266007 308621 267232 993928 691093 566188 610311 1095346 892199 430238 887717 479086 180869 699969 525495 562882 528795 344774 100997 206131 11763775 寻呼成功次数 225603 377126 482595 258577 299566 257803 962917 672041 546085 581243 1062605 861896 414367 855807 463178 173617 670598 507133 534293 502290 333549 97126 194699 11334714 寻呼成功率 93.15% 97.16% 97.39% 97.21% 97.07% 96.47% 96.88% 97.24% 96.45% 95.24% 97.01% 96.60% 96.31% 96.41% 96.68% 95.99% 95.80% 96.51% 94.92% 94.99% 96.74% 96.17% 94.45% 96.35% 第 38 页 共 220 页
根据上图，宁波全网各LAC语音寻呼成功率均在核心网警界线90%以上，其中以LAC55072最低，只有93%，其他LAC均在94%以上。另外，从上表可以看出，语音寻呼量与寻呼成功率不成正比，寻呼次数低的LAC寻呼成功率不一定高，反之亦然，因此寻呼评估需通过空口与PS域相结合分析。
现时宁波核心采用两次寻呼方式，每一次寻呼包含一次TMSI和一次ISMI寻呼消息下发（TMSI/IMSI->TMSI/IMSI），连续下发的寻呼消息之间相隔2秒，根据5月4日和5月5日核心网寻呼数据分析，存在下面情况：
PAGINGATTEMPTPERLA 5906490 5857285 PAGINGSUCCPERLA 5691346 5643368 寻呼成功率 96.36% 96.35% PAGINGATTEMPTWITHIMSISUCC 74480 71862 PAGINGATTEMPTWITHTMSISUCC 5682827 5627821 PAGINGATTEMPTWITHIMSIFAIL 413793 412980 PAGINGATTEMPTWITHTMSIFAIL 404387 404875 日期 5月4日 5月5日 总体语音寻呼量统计
130504核心网寻呼130505核心网寻呼情况.xls情况.xls
从上表可以看出，现时全网寻呼成功率平均为96.35%，失败总体失败次数为214530次，约为“PAGINGATTEMPTWITHTMSIFAIL”和与“PAGINGATTEMPTWITHTMSIFAIL”统计项的一
半，另外，“PAGINGATTEMPTWITHIMSIFAIL”与“PAGINGATTEMPTWITHTMSIFAIL”两统计项从数量级上对比，基本一致，因此，核心网发起一次业务寻呼，若寻呼失败基本会下发4次寻呼，并且都失败。
第 39 页 共 220 页
宁波目标配置PBP=64帧，重复因子=1计算，寻呼分组=8，IMSI寻呼能力＝3×8/0.64/1=37次/秒，TMSI寻呼能力=5×8/0.64/1=62次/秒。鉴于宁波核心网寻呼方式为4次，结合核心网寻呼成功率的警界值90%计算宁波最大寻呼量：
? 修正后TMSI寻呼占比=（90%+10%*2）/（90%+10%*4） ? 修正后IMSI寻呼占比=（10%*2）/（90%+10%*4） 按TMSI/IMSI每秒62次/37计算：
? 修正后每秒混合下发长度=62*（（90%+10%*2）/（90%+10%*4））+37*（（10%*2）
/（90%+10%*4））=57次/秒。
? 则一个小时内LAC能够支持的寻呼量=57次/秒/小区*3600秒=205200次/小时/小区 结论，于目前宁波寻呼模型下大唐设备支持的寻呼容量为205200/h，考虑到30%的寻呼冗余，则最终呈现的寻呼容量为205200*0.7=143640次/小时/小区
另外，在寻呼量没有到达门限时，仍然产生寻呼拥塞有以下两个原因：
? 寻呼信道1s内只能调度62.5个寻呼（现网参数配置且TMSI寻呼模式下），如果
CN在1s内向该LAC下发的寻呼量超过62.5个，产生“雪崩效应”则会导致无法调度，引起拥塞，对应的解决方案是寻呼信道扩容、合理LAC规划。
? TD网络中寻呼信道有8个寻呼子信道。如果同一时刻IMSI过于集中，比如寻呼
调度算法将同一时刻2个IMSI调度到一个寻呼子信道中，而每次只能发1个，这也会导致调度失败，引起拥塞。对应的解决方案是寻呼信道扩容，合理LAC规划、均匀放号。
4.1.6.2 基于空口统计数据的寻呼容量评估
分析数据取自凯通平台，寻呼量包括CS域和PS域。 4.1.6.2.1 寻呼概况分析： 1. 一周最忙时段分析
统计4月19日致4月26日宁波UTRAN下挂的所有LAC最忙时段发起寻呼类型1次数（包含CS/PS），其中4月20日和4月21日为周未休息日，其余时间为正常工作日，统计结果如下表：
时间 2013-4-23 16:00 2013-4-20 10:00 2013-4-19 16:00 LAC 55072 55073 55074 县市名称 海曙 海曙 江东 UTRAN发起寻呼类型1次数 55598 65245 85870 寻呼类型1拥塞次数(次) 0 0 0 寻呼拥塞率(%) 0.00 0.00 0.00 第 40 页 共 220 页