华为设备TBF建立成功率优化提升方案XXXX03
华为设备TBF建立成功率的提升方案
目录
1 网络接入性能分析优化 (5)
1.1接入性能指标 (5)
1.2无信道资源导致的下行TBF建立失败优化 (6)
1.2.1无线拥塞类型 (6)
1.2.2对于无线拥塞的处理 (7)
1.3手机无响应导致下行TBF建立失败 (8)
1.3.2空口质量 (10)
1.3.3 Abis口传输 (11)
1.3.4 BSC6000 PCU处理部分 (11)
1.3.5 GB口传输 (14)
1.3.6手机问题 (15)
1.3.7手机行为 (15)
1.4CCCH过载导致下行TBF建立成功率低 (15)
1.4.1问题描述分析 (18)
1.4.2解决方法 (21)
1.4.3优化前后效果比较 (22)
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建立失败次数”加一。
图1MS无响应导致在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建立失败次数"加一。
图2MS无响应导致在PACCH上发起的下行TBF建立失败
其次，我们来分析手机无响应有哪些影响因素：
1.3.2 空口质量
主要是无线环境的因素，手机无响应就是手机和网络之间传输和通信出现了问题,因此首先要检查的就是空口的传输是否存在故障（如图3）,空口质量是否良好；
图3GSM/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所示：
图4CCCH上建立下行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所
示：
图5PACCH上建立下行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％。
指标指标描述
A330:CELL_PAGES_CS寻呼下发次数（电路业务）
A331:CELL_PAGES_PS寻呼下发次数（分组业务）
A337: CELL_CIRCUIT_PCH_DEL PCH电路业务寻呼删除次数
A338: CELL_CIRCUIT_PCH_EXP PCH电路业务寻呼超时次数
A339: CELL_PACUIT_PCH_DEL PCH分组业务寻呼删除次数
A340: CELL_PACUIT_PCH_EXP PCH分组业务寻呼超时次数
L3188A:CELL_DEL_IND Abis接口删除指示消息上报次数
1.4.1 问题描述分析
对于PCU下面个别小区因业务量高导致话统指标“手机无响应导致下行TBF建立失败次数”较高，导致下行TBF建立成功率较低，晚忙时特别明显。
从CCCH上的下行TBF建立流程分析，对存在手机无响应导致下行TBF建立失败次数较高的小区（沽源ZJGDO1D、沽源ZJGDO1C、沽源Z JGDO1B等），分析流控测量相关的话统指标“呼叫相关测量（CALL）->流控测量<小区>-> Abi s接口分组CCCH负载指示消息上报次数（此话统指标需要在M2000上先进行登记）”，发现重要信息：Abis接口分组CCCH负载指示消息上报次数非常多（见表1）
起始时间GCELL L3188D:Abis接口CCCH负载指示（PCH）消息上报次数（分组业务）
02/16/2011 19:00:00 ZJDH899A 166
02/16/2011 19:00:00 ZJDHB38F 152
02/16/2011 19:00:00 ZJDHB38G 101
02/16/2011 19:00:00 ZJG801A 109
02/16/2011 19:00:00 ZJG801B 178
02/16/2011 19:00:00 ZJGB01A 184
02/16/2011 19:00:00 ZJGB01B 211
02/16/2011 19:00:00 ZJGB01C 216
02/16/2011 19:00:00 ZJGB38A 240
02/16/2011 19:00:00 ZJGB38D 131
02/16/2011 19:00:00 ZJGD01B 226
02/16/2011 19:00:00 ZJGD01C 114
表1 Abis接口分组CCCH负载指示消息上报次数
当CCCH过载，BSC收到测量小区所属的B TS报告的PACKET CCCH LOAD IND消息的次数，然后，BSC侧启动一个TN_CCCH_OVE RLOAD_PROTECTION定时器，BSC为了降低CCCH拥塞程度，基于话音业务优先于分组业务的原则，分组域不重发下行分组立即指配，并且只发1个polling request，即只发1个IMM ASS 和1个Polling Request消息。在TN_CCCH_OVE RLOAD_PROTECTION定时器超时后，恢复正常。即正常情况下，如果手机对下行分组立即指配无响应的话，BSC会重发IMM ASS和Polling Request，直到手机有响应为止。而且每个IMM ASS后发5个Polling Request（所发个数在LMT
中可以配置，默认值已为最大值5）。IMM AS S的下发次数在LMT中也可以配置，现在默认为2次。
正常情况下，手机无响应导致下行TBF 建立失败的话，BSC侧会共发送2个IMM ASS和10个Polling Request。由于空口质量不稳定，一般网络侧会发几个Polling Request后，手机才有响应，如图6 所示：
图6Polling消息下发次数