华为设备TBF建立成功率的提升方案
目录
1 网络接入性能分析优化 (3)
1.1接入性能指标 (3)
1.2无信道资源导致的下行TBF建立失败优化 (3)
1.2.1无线拥塞类型 (3)
1.2.2对于无线拥塞的处理 (4)
1.3手机无响应导致下行TBF建立失败 (4)
1.3.2空口质量 (5)
1.3.3 Abis口传输 (6)
1.3.4 BSC6000 PCU处理部分 (6)
1.3.5 GB口传输 (8)
1.3.6手机问题 (8)
1.3.7手机行为 (8)
1.4CCCH过载导致下行TBF建立成功率低 (9)
1.4.1问题描述分析 (10)
1.4.2解决方法 (12)
1.4.3优化前后效果比较 (12)
1 网络接入性能分析优化
1.1 接入性能指标
下行TBF建立成功率计算公式如下：
内置PCU TBF建立成功率定义：
1)上行TBF建立成功率=（上行GPRS TBF建立成功次数+上行EGPRS TBF建立成功
次数）/(上行GPRS TBF建立尝试次数+上行EGPRS TBF建立尝试次数)
2)下行TBF建立成功率=（下行GPRS TBF建立成功次数+下行EGPRS TBF建立成功
次数）/(下行GPRS TBF建立尝试次数+下行EGPRS TBF建立尝试次数) 统计TBF建立失败的主要有以下2个指标：
1)无信道资源导致下行TBF建立失败次数/无信道资源导致下行TBF建立失败次数
2)MS无响应导致下行TBF建立失败次数/ MS无响应导致下行TBF建立失败次数
TBF性能优化中主要就无信道资源导致下行TBF建立失败次数和MS无响应导致下行TBF建立失败次数这2个指标进行优化。
1.2 无信道资源导致的下行TBF建立失败优化
在EGPRS网络建设初期，EGPRS信道配置较少，随着EGPRS数据用户的增长，需要对基站的容量进行扩容和EGPRS信道个数或信道控制参数进行调整。
1.2.1 无线拥塞类型
对于无信道资源导致TBF建立失败，按照问题的严重程度分为以下几个类型：
1)硬拥塞，上行下行TBF建立无可用的信道资源
该问题非常严重，由于EGPRS&GPRS无法使用，给用户造成的主观感受很差。
2)话音抢占造成TBF 释放，忙时回收有负载动态PDCH次数
比较严重，相当于GSM 中的掉话。
3)TBF 信道复用比较明显，每用户平均占用信道个数比较少
严重程度一般，EGPRS&GPRS 可正常使用，但是给用户的感受是速度慢。
以上是判断拥塞的一般性描述，具体的判断标准可根据具体情况进行合理定义。
1.2.2 对于无线拥塞的处理
根据不同的拥塞现象，处理建议分别如下：
1)有较多的硬拥塞或者话音造成的TBF 释放，
此种情况下无可用PDCH信道，由于语音的抢占导致配置的动态PDCH为TCH状态。
此种情况必须通过增加静态PDCH信道或者TRX 扩容才能够解决。
2)有TBF复用明显现象以及少量语音造成TBF 释放
问题不特别明显建议增加PDCH动态信道个数，并且如果该点为CQT 点则一定要增加EGPRS静态信道。
内置PCU，增加小区级PDCH信道控制参数：“小区下最大PDCH比率门限”。
3)有少量的TBF 复用明显
问题不明显，但如果为CQT 点则最好增加PDCH动态信道。
内置PCU的BSC，增加小区级PDCH信道控制参数：“小区下最大PDCH比率门限”。
1.3 手机无响应导致下行TBF建立失败
本测量指标统计一个测量周期内小区MS无响应导致下行GPRS TBF建立失败次数，MS无响应导致下行TBF建立失败包含以下两种情况：
(1) MS无响应导致在CCCH上发起的下行TBF建立失败
在下行TBF的建立流程中，网络侧会发送POLLING消息给MS来获取TA值，并且预留块资源让MS回应指配确认消息。如果网络侧在指配的信道的预留块资源上未收到该MS的PACKET CONTROL ACKNOWLEDGEMENT消息，网络侧会多次重发下行立即指配，直到超出最大尝试次数。
图1是由于MS无响应导致建立下行TBF建立失败的过程。每当网络侧尝试次数超出最大值的时候，如图中的测量点A所示，统计值“手机无响应导致下行TBF建立失败次数”加一。
图1 MS无响应导致在CCCH上发起的下行TBF建立失败
(2) MS无响应导致在PACCH上发起的下行TBF建立失败
网络侧可以通过下面两种方法来建立下行TBF：在当前的上行TBF传输过程中或下行TBF释放过程中发起新的下行TBF建立请求；在当前的下行TBF传输过程中为该TBF重新指配下行资源。
网络侧发送PACKET DOWNLINK ASSIGNMENT消息，并且预留块资源让MS回应指配确认消息。如果网络侧在指配的信道的预留块资源上未收到该MS的PACKET CONTROL ACKNOWLEDGEMENT消息，网络侧会多次重发下行分组指配，直到超出最大尝试次数。图2是由于MS无响应导致下行TBF建立失败的过程，每当重发的次数超出最大的尝试次数时，如图中的测量点A所示，统计值"手机无响应导致下行TBF建立失败次数"加一。
图2 MS无响应导致在PACCH上发起的下行TBF建立失败
其次，我们来分析手机无响应有哪些影响因素：
1.3.2 空口质量
主要是无线环境的因素，手机无响应就是手机和网络之间传输和通信出现了问题,因此首先要检查的就是空口的传输是否存在故障（如图3）,空口质量是否良好；
图3 GSM/GPRS结构图
1.3.3 Abis口传输
在网络侧,首先就是BTS和BSC之间Abis口的传输,如果传输有问题,比如端口故障,就会有大量的误码(包括失步帧和校验错帧),这会在一定程度上影响手机接入；
1.3.4 BSC6000 PCU处理部分
数据业务的中央中心就是BSC6000中的内置PCU，因此排除几个传输接口的问题后，主要的分析对象就是内置PCU的下行TBF建立流程的处理了，主要从以下几点去分析：
1、数据配置是否存在异常，与其它没有出现此问题的PCU小区有何区别；
2、手机无响应导致下行TBF建立失败较多，从下行TBF建立流程进行分析，下行TBF 建立流程主要包括CCCH上的下行TBF建立流程和PACCH上的下行TBF建立流程；
当PCU收到LLC PDU而没有下行TBF时，需要建立一个下行TBF用以传送数据。CCCH 上的下行TBF建立流程，如图4所示：
图4 CCCH上建立下行TBF流程
如图4，在下行TBF开始时，网络侧在下行TBF的PACCH下发以TFI标识的Packet Polling Request消息。手机对此响应ACCESS BURST类型的分组控制确认消息。网络侧从
AB(ACCESS BURST)中提取时间提前量，在Packet Power Control/Timing Advance消息中通知手机，并发分组下行指配消息给手机分配多个信道。(此流程的作用：一是确认手机是否收到下行立即指配，下行TBF是否建立成功；二是提取时间提前量通知手机)。
由于手机和网络的配合问题,可能会出现网络侧发了立即指配消息和Packet Polling Request消息,手机没有收到的情况,因此适当增加立即指配消息或Packet Polling Request消息的重发次数, 然而提高立即指配次数会导致指配成功率的降低,因此一般选择提高Packet Polling Request消息的重发次数,可以很大程度上减少手机无响应的概率,类似于语音中的寻呼次数。
继续看图4，如果手机发的上行FAI已经发送，但此时上行TBF还处于传输状态，就不能进行下行建立，需等待一段时间后再建立下行，如果这个时间超时就会导致手机无响应。
PACCH上的下行TBF建立流程,如图5所示：
图5 PACCH上建立下行TBF流程
PCU在PACCH上发分组下行指配消息以后，如果没有收到手机响应的分组控制确认消息，则PACCH上的下行TBF建立失败。
另外，加大上下行延迟释放时间，可以增大手机从PACCH建立下行的几率，因此可以提高手机接入时间，提高下行TBF建立成功率，一定程度上减少手机无响应。
1.3.5 GB口传输
对于GB口，主要关注是否有GB口的链路故障,是否有拥塞情况。
1.3.6 手机问题
对于个别手机可能存在手机兼容性问题，也有可能是手机本身的问题,对于这些问题需要手机侧进行处理定位。
1.3.7 手机行为
下行由于手机可能已经进入其他小区，此时在原小区建立下行TBF时的POLLING消息和指配消息，手机无法响应；另外，即便手机还在原小区，由于可能该手机处于StandBy状态，对于PCU建立下行TBF时的指配消息和POLLING消息，该手机也不一定能接收到或及时响应。此外，手机即使收到了Polling消息，由于兼容性问题，会导致不回AB消息。这些都可能导致下行TBF因手机无响应而建立次数占下行TBF尝试建立次数的比例较高。
1.4 CCCH过载导致下行TBF建立成功率低
CCCH信道在空口上主要传送寻呼信令（PCH）和立即指配信令（AGCH）。每条寻呼信令和立即指配信令均占一条51复帧，51复帧占用时长为0.2354秒。
立即指配消息和寻呼消息共同在CCCH信道下发，当小区的配置为“一个非组合CCCH 信道时”，CCCH共分9个消息块，接入允许保留块数设置了保留多少个消息块供立即指配消息专用，一般该参数设置为1或2。当同时下发立即指配消息较多时，会占用其它消息块，此时，立即指配消息和寻呼消息同时排在寻呼队列中，会导致寻呼队列更拥塞，寻呼超时次数进一步增加。
一条寻呼信令中能发多条寻呼消息。采用TMSI寻呼方式，一条寻呼信令最多可发送4条寻呼寻呼消息，采用IMSI寻呼方式，一条寻呼最多可发送4条寻呼消息。张家口移动寻呼策略则是采用两次寻呼，第一次采用TMSI寻呼，第二次采用IMSI寻呼，现网各位置区一次寻呼成功率在91％～94％之间，采用比较统计的值为93％，这样通过典型寻呼合并效率计算，估算出平均每条寻呼信令中下发2.98条寻呼消息。
CCCH负荷、CCCH溢出率为参考移动通信业界的思路自定制的分析公式，用如下公式估算：
CCCH负荷＝[（A330:寻呼下发次数（电路业务）＋A331:寻呼下发次数（分组业务））/2.98×0.2354+(A301H:立即指配命令次数（分组业务）＋CA301J:立即指配命令次数（电路业务）)×0.2354] /3600/ （9×配置的CCCH时隙数）×100％；
其中配置的CCCH时隙数指的是BCCH信道数和扩展BCH信道（BCH信道）数之和，默认不开通扩展BCH场景下为1。（每51复帧中能够发送多条PCH寻呼块，每个寻呼块最大能够发送2-4条寻呼消息；而每51复帧只发送一条立即指配命令消息）
考虑以CCCH溢出率来估算CCCH信道过载程度：
CCCH溢出率＝（A337:PCH电路业务寻呼删除次数＋A338:PCH电路业务寻呼超时次数＋A339:PCH分组业务寻呼删除次数＋A340:PCH分组业务寻呼超时次数＋L3188A:Abis接口删除指示消息上报次数）/( A330:寻呼下发次数（电路业务）＋A331:寻呼下发次数（分组业务）+ A301H:立即指配命令次数（分组业务）＋CA301J:立即指配命令次数（电路业务）)×100％。
1.4.1 问题描述分析
对于PCU下面个别小区因业务量高导致话统指标“手机无响应导致下行TBF建立失败次数”较高，导致下行TBF建立成功率较低，晚忙时特别明显。
从CCCH上的下行TBF建立流程分析，对存在手机无响应导致下行TBF建立失败次数较高的小区（沽源ZJGDO1D、沽源ZJGDO1C、沽源ZJGDO1B等），分析流控测量相关的话统指标“呼叫相关测量（CALL）->流控测量<小区>-> Abis接口分组CCCH负载指示消息上报次数（此话统指标需要在M2000上先进行登记）”，发现重要信息：Abis接口分组CCCH 负载指示消息上报次数非常多（见表1）
表1 Abis接口分组CCCH负载指示消息上报次数
当CCCH过载，BSC收到测量小区所属的BTS报告的PACKET CCCH LOAD IND消息的次数，然后，BSC侧启动一个TN_CCCH_OVERLOAD_PROTECTION定时器，BSC为了降低CCCH拥塞程度，基于话音业务优先于分组业务的原则，分组域不重发下行分组立即指配，并且只发1个polling request，即只发1个IMM ASS和1个Polling Request消息。在TN_C CCH_OVERLOAD_PROTECTION定时器超时后，恢复正常。即正常情况下，如果手机对下行分组立即指配无响应的话，BSC会重发IMM ASS和Polling Request，直到手机有响应为止。而且每个IMM ASS后发5个Polling Request（所发个数在LMT中可以配置，默认值已为最大值5）。IMM ASS的下发次数在LMT中也可以配置，现在默认为2次。
正常情况下，手机无响应导致下行TBF 建立失败的话，BSC侧会共发送2个IMM ASS
和10个Polling Request。由于空口质量不稳定，一般网络侧会发几个Polling Request后，手机才有响应，如图6 所示：
图6 Polling消息下发次数
图6 所示的是手机不在小区业务高峰时，BSC侧发了3个Polling Request后手机才有回应，这属于正常现象。
1.4.2 解决方法
当CCCH负荷超过75％后，CCCH信道溢出严重，此时应及时采取路由区分裂、位置区分裂、增加BCH信道等优化措施；当CCCH负荷在60％到75％之间，此时CCCH信道溢出率指标不超过6％，此次应予关注，必要时采取减少寻呼次数、增加CCCH信道数目等相关措施；当CCCH负荷低过60％时，CCCH溢出次数比较少，只需针对个别问题小区进行优化处理。
对于LAC区内的寻呼业务考虑。若A330＋A331>寻呼容量典型值(每小时19万次)，需考虑对该LAC区内所有小区扩展BCH。
对目前张家口华为区域现网的CCCH负荷分析来看，不存在整个LAC区下所有小区CCCH 过载问题。
对于个别小区CCCH过载评估，若(A337+A338+A339+A340+L3188A)/ (A330＋
A331)>10%，表示出现寻呼消息丢弃，建议配置扩展BCH，扩容CCCH信道：对应的一个BCCH复帧中CCCH消息块数为：3、9、18、27、36。CCCH配置决定了PCH、AGCH和RACH容量。
接入允许保留块数、CCCH配置参数会根据小区主B载频0信道配置类型动态调整：
若小区CCCH配置为非“1个组合CCCH”，则接入允许保留块数缺省值修改为2，同时该参数的取值范围为1～7。若小区的CCCH配置为“1个组合CCCH”时，则将该小区对应的系统消息表中的接入允许保留块数缺省值修改为1，同时该参数的取值范围为1～2；
默认情况下，一个小区只配置一个主BCCH，这样有“1个非组合的CCCH”，那么CCCH 在一个BCCH复帧中的消息块数就为9。如果多配置一个BCH，那么就有“2个非组合的CCCH”，那么CCCH在一个BCCH复帧中的消息块数就为18，很大程度上提高了CCCH的容量。
1.4.3 优化前后效果比较
以下是实施优化方案前后的对比效果：
优化方案实施后Abis接口分组CCCH负载指示消息上报次数明显减少(见表2)，只有业务
突发高峰造成的几次过载。
表2 增加扩展BCCH信道前后的Abis接口分组CCCH负载指示消息上报次数
从KPI上看，扩容CCCH后，下行TBF建立成功率已经有了很大的提高。忙时的下行TB F建立成功率由原来的80%多上升到90%以上（见表3），效果非常明显。
附录：相关话统含义说明
1、PCH电路业务寻呼删除次数
A337: CELL_CIRCUIT_PCH_DEL
含义:本指标统计了PCH块上调度消息时存在竞争问题，记录电路域寻呼消息被删除的次数。BTS统计PCH电路业务寻呼删除次数并每分钟上报一次BTS_STATIS_REPORT消息给BSC。
2、PCH电路业务寻呼超时次数
A338: CELL_CIRCUIT_PCH_EXP
含义:本指标统计了PCH块上调度消息时存在竞争问题，记录电路域寻呼消息超时的次数。因为每个寻呼都有生存周期，超过生存周期后，寻呼消息就会被删除。这个生存周期默认值是5s，可以通过基站软参修改。
BTS统计PCH电路业务寻呼超时次数并每分钟上报一次BTS_STATIS_REPORT消息给BSC。
3、PCH分组业务寻呼删除次数
A339: CELL_PACUIT_PCH_DEL
含义:本指标统计了PCH块上调度消息时存在竞争问题，记录分组域寻呼消息被删除的次数。BTS统计PCH分组业务寻呼删除次数并每分钟上报一次BTS_STATIS_REPORT消息给BSC。
4、PCH分组业务寻呼超时次数
A340: CELL_PACUIT_PCH_EXP
含义:本指标统计了PCH块上调度消息时存在竞争问题，记录分组域寻呼消息超时的次数。因为每个寻呼都有生存周期，超过生存周期后，寻呼消息就会被删除。这个生存周期默认值是5s，可以通过基站软参修改。
BTS统计PCH分组业务寻呼超时次数并每分钟上报一次BTS_STATIS_REPORT消息给BSC。
5、寻呼下发次数（电路业务）
A330: CELL_PAGES_CS
含义:当BSC下的MS作为电路业务的被叫时，BSC收到来自MSC或PCU的电路PAGING消息后，根据小区识别标志向相应小区下发PAGING CMD消息，并以小区为对象统计该指标。该指标统计的是Abis口寻呼下发情况。参见GSM 0858、0408协议。
6、寻呼下发次数（分组业务）
A331: CELL_PAGES_PS
含义:当BSC下的MS作为分组业务的被叫时，SGSN向PCU下发PAGING REQ消息寻呼MS，PCU处理后发送PACKET PAGING 消息给BSC，BSC根据消息中的小区识别标志向相应小区下发PACKET PAGING CMD，并以小区为对象统计该指标。参见GSM 0408，0460，0360协议。
7、Abis接口删除指示消息上报次数
L3188A:CELL_DEL_IND
含义:当小区内的下行CCCH过载导致BSC下发给BTS的一条IMM ASS CMD 消息被BTS删除时，BTS上报给BSC DELETE IND消息。
本指标用于统计BSC收到测量小区报告的DELETE IND消息的次数。
8、Abis接口CCCH负载指示（RACH）消息上报次数
L3188B:CELL_CCCH_LOAD_RACH_OVERLOADS
含义:当小区内的上行CCCH（RACH）过载时，BTS上报CCCH LOAD IND（RACH过载）消息给BSC。
目前华为BSS不支持分组业务的RACH过载指示，如果RACH上的分组业务过载将会被认为是电路业务RACH过载。
本指标用于统计BSC收到测量小区报告的CCCH LOAD IND（RACH过载）消息的次数。9、Abis接口CCCH负载指示（PCH）消息上报次数
L3188C:CELL_CCCH_LOAD_PCH_OVERLOADS
含义:BTS把下行CCCH（PCH信道）上的来自BSC和PCU的寻呼消息分别存放在不同的接收缓冲队列中，当接收缓冲队列的长度超过一定门限时就认为下行CCCH过载。当小区内下行CCCH过载时，BTS不但可以上报过载给BSC，还能区分出过载是下行分组业务过多还是电路业务过多导致的，如果是电路业务过多则向BSC报告CCCH LOAD IND消息，如果是分组业务过多则向BSC报告PACKET CCCH LOAD IND消息，并由BSC转发给PCU。
本指标用于统计BSC收到测量小区所属的BTS报告的CCCH LOAD IND消息的次数。
10、Abis接口分组CCCH负载指示消息上报次数
L3188D:CELL_OVERLOAD_PS
含义:BTS把下行CCCH（PCH信道）上的来自BSC和PCU的寻呼消息分别存放在不同的接收缓冲队列中，当接收缓冲队列的长度超过一定门限时就认为下行CCCH过载。当小区内下行CCCH过载时，BTS不但可以上报过载给BSC，还能区分出过载是下行分组业务过多还是电
路业务过多导致的，如果是电路业务过多则向BSC报告CCCH LOAD IND消息，如果是分组业务过多则向BSC报告PACKET CCCH LOAD IND消息，并由BSC转发给PCU。
本指标用于统计BSC收到测量小区所属的BTS报告的PACKET CCCH LOAD IND消息的次数。