华为设备TBF建立成功率优化提升方案2011

《华为设备TBF建立成功率优化提升方案2011》由会员分享，可在线阅读，更多相关《华为设备TBF建立成功率优化提升方案2011（17页珍藏版）》请在装配图网上搜索。

1、精选优质文档-倾情为你奉上华为设备TBF建立成功率的提升方案目录1 网络接入性能分析优化31.1 接入性能指标31.2 无信道资源导致的下行TBF建立失败优化31.2.1 无线拥塞类型31.2.2 对于无线拥塞的处理41.3 手机无响应导致下行TBF建立失败41.3.2 空口质量51.3.3 Abis口传输61.3.4 BSC6000 PCU处理部分61.3.5 GB口传输81.3.6 手机问题81.3.7 手机行为81.4 CCCH过载导致下行TBF建立成功率低91.4.1 问题描述分析101.4.2 解决方法121.4.3 优化前后效果比较13专心-专注-专业1 网络接入性能分析优化1.1

2、 接入性能指标下行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建立失败次数/ M

3、S无响应导致下行TBF建立失败次数TBF性能优化中主要就无信道资源导致下行TBF建立失败次数和MS无响应导致下行TBF建立失败次数这2个指标进行优化。1.2 无信道资源导致的下行TBF建立失败优化在EGPRS网络建设初期，EGPRS信道配置较少，随着EGPRS数据用户的增长，需要对基站的容量进行扩容和EGPRS信道个数或信道控制参数进行调整。1.2.1 无线拥塞类型对于无信道资源导致TBF建立失败，按照问题的严重程度分为以下几个类型：1) 硬拥塞，上行下行TBF建立无可用的信道资源 该问题非常严重，由于EGPRS&GPRS无法使用，给用户造成的主观感受很差。2) 话音抢占造成TBF 释放，忙时

4、回收有负载动态PDCH次数 比较严重，相当于GSM 中的掉话。3) TBF 信道复用比较明显，每用户平均占用信道个数比较少 严重程度一般，EGPRS&GPRS 可正常使用，但是给用户的感受是速度慢。 以上是判断拥塞的一般性描述，具体的判断标准可根据具体情况进行合理定义。1.2.2 对于无线拥塞的处理 根据不同的拥塞现象，处理建议分别如下：1) 有较多的硬拥塞或者话音造成的TBF 释放， 此种情况下无可用PDCH信道，由于语音的抢占导致配置的动态PDCH为TCH状态。 此种情况必须通过增加静态PDCH信道或者TRX 扩容才能够解决。2) 有TBF复用明显现象以及少量语音造成TBF 释放问题不特别

5、明显建议增加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的建立流程中，网络

6、侧会发送POLLING消息给MS来获取TA值，并且预留块资源让MS回应指配确认消息。如果网络侧在指配的信道的预留块资源上未收到该MS的PACKET CONTROL ACKNOWLEDGEMENT消息，网络侧会多次重发下行立即指配，直到超出最大尝试次数。 图1是由于MS无响应导致建立下行TBF建立失败的过程。每当网络侧尝试次数超出最大值的时候，如图中的测量点A所示，统计值“手机无响应导致下行TBF建立失败次数”加一。图1 MS无响应导致在CCCH上发起的下行TBF建立失败(2) MS无响应导致在PACCH上发起的下行TBF建立失败 网络侧可以通过下面两种方法来建立下行TBF：在当前的上行TBF传

7、输过程中或下行TBF释放过程中发起新的下行TBF建立请求；在当前的下行TBF传输过程中为该TBF重新指配下行资源。 网络侧发送PACKET DOWNLINK ASSIGNMENT消息，并且预留块资源让MS回应指配确认消息。如果网络侧在指配的信道的预留块资源上未收到该MS的PACKET CONTROL ACKNOWLEDGEMENT消息，网络侧会多次重发下行分组指配，直到超出最大尝试次数。 图2是由于MS无响应导致下行TBF建立失败的过程，每当重发的次数超出最大的尝试次数时，如图中的测量点A所示，统计值手机无响应导致下行TBF建立失败次数加一。图2 MS无响应导致在PACCH上发起的下行TBF建

8、立失败 其次，我们来分析手机无响应有哪些影响因素：1.3.2 空口质量主要是无线环境的因素，手机无响应就是手机和网络之间传输和通信出现了问题,因此首先要检查的就是空口的传输是否存在故障（如图3）,空口质量是否良好； 图3 GSM/GPRS结构图1.3.3 Abis口传输 在网络侧,首先就是BTS和BSC之间Abis口的传输,如果传输有问题,比如端口故障,就会有大量的误码(包括失步帧和校验错帧),这会在一定程度上影响手机接入；1.3.4 BSC6000 PCU处理部分 数据业务的中央中心就是BSC6000中的内置PCU，因此排除几个传输接口的问题后，主要的分析对象就是内置PCU的下行TBF建立流

9、程的处理了，主要从以下几点去分析：1、数据配置是否存在异常，与其它没有出现此问题的PCU小区有何区别；2、手机无响应导致下行TBF建立失败较多，从下行TBF建立流程进行分析，下行TBF建立流程主要包括CCCH上的下行TBF建立流程和PACCH上的下行TBF建立流程； 当PCU收到LLC PDU而没有下行TBF时，需要建立一个下行TBF用以传送数据。CCCH上的下行TBF建立流程，如图4所示：图4 CCCH上建立下行TBF流程 如Error! Reference source not found.，在下行TBF开始时，网络侧在下行TBF的PACCH下发以TFI标识的Packet Polling

10、Request消息。手机对此响应ACCESS BURST类型的分组控制确认消息。网络侧从AB(ACCESS BURST)中提取时间提前量，在Packet Power Control/Timing Advance消息中通知手机，并发分组下行指配消息给手机分配多个信道。(此流程的作用：一是确认手机是否收到下行立即指配，下行TBF是否建立成功；二是提取时间提前量通知手机)。 由于手机和网络的配合问题,可能会出现网络侧发了立即指配消息和Packet Polling Request消息,手机没有收到的情况,因此适当增加立即指配消息或Packet Polling Request消息的重发次数, 然而提高立

11、即指配次数会导致指配成功率的降低,因此一般选择提高Packet Polling Request消息的重发次数,可以很大程度上减少手机无响应的概率,类似于语音中的寻呼次数。 继续看Error! Reference source not found.，如果手机发的上行FAI已经发送，但此时上行TBF还处于传输状态，就不能进行下行建立，需等待一段时间后再建立下行，如果这个时间超时就会导致手机无响应。 PACCH上的下行TBF建立流程,如Error! Reference source not found.所示：图5 PACCH上建立下行TBF流程 PCU在PACCH上发分组下行指配消息以后，如果没有收

12、到手机响应的分组控制确认消息，则PACCH上的下行TBF建立失败。 另外，加大上下行延迟释放时间，可以增大手机从PACCH建立下行的几率，因此可以提高手机接入时间， 提高下行TBF建立成功率，一定程度上减少手机无响应。1.3.5 GB口传输 对于GB口，主要关注是否有GB口的链路故障,是否有拥塞情况。1.3.6 手机问题 对于个别手机可能存在手机兼容性问题，也有可能是手机本身的问题,对于这些问题需要手机侧进行处理定位。1.3.7 手机行为 下行由于手机可能已经进入其他小区，此时在原小区建立下行TBF时的POLLING消息和指配消息，手机无法响应；另外，即便手机还在原小区，由于可能该手机处于St

13、andBy状态，对于PCU建立下行TBF时的指配消息和POLLING消息，该手机也不一定能接收到或及时响应。此外，手机即使收到了Polling消息，由于兼容性问题，会导致不回AB消息。这些都可能导致下行TBF因手机无响应而建立次数占下行TBF尝试建立次数的比例较高。1.4 CCCH过载导致下行TBF建立成功率低CCCH信道在空口上主要传送寻呼信令（PCH）和立即指配信令（AGCH）。每条寻呼信令和立即指配信令均占一条51复帧，51复帧占用时长为0.2354秒。立即指配消息和寻呼消息共同在CCCH信道下发，当小区的配置为“一个非组合CCCH信道时”，CCCH共分9个消息块，接入允许保留块数设置了

14、保留多少个消息块供立即指配消息专用，一般该参数设置为1或2。当同时下发立即指配消息较多时，会占用其它消息块，此时，立即指配消息和寻呼消息同时排在寻呼队列中，会导致寻呼队列更拥塞，寻呼超时次数进一步增加。一条寻呼信令中能发多条寻呼消息。采用TMSI寻呼方式，一条寻呼信令最多可发送4条寻呼寻呼消息，采用IMSI寻呼方式，一条寻呼最多可发送4条寻呼消息。张家口移动寻呼策略则是采用两次寻呼，第一次采用TMSI寻呼，第二次采用IMSI寻呼，现网各位置区一次寻呼成功率在9194之间，采用比较统计的值为93，这样通过典型寻呼合并效率计算，估算出平均每条寻呼信令中下发2.98条寻呼消息。CCCH负荷、CCCH

15、溢出率为参考移动通信业界的思路自定制的分析公式，用如下公式估算：CCCH负荷（A330:寻呼下发次数（电路业务）A331:寻呼下发次数（分组业务）/2.980.2354+(A301H:立即指配命令次数（分组业务）CA301J:立即指配命令次数（电路业务）)0.2354 /3600/ （9配置的CCCH时隙数）100；其中配置的CCCH时隙数指的是BCCH信道数和扩展BCH信道（BCH信道）数之和，默认不开通扩展BCH场景下为1。（每51复帧中能够发送多条PCH寻呼块，每个寻呼块最大能够发送2-4条寻呼消息；而每51复帧只发送一条立即指配命令消息）考虑以CCCH溢出率来估算CCCH信道过载程度：

16、CCCH溢出率（A337:PCH电路业务寻呼删除次数A338:PCH电路业务寻呼超时次数A339:PCH分组业务寻呼删除次数A340:PCH分组业务寻呼超时次数L3188A:Abis接口删除指示消息上报次数）/( A330:寻呼下发次数（电路业务）A331:寻呼下发次数（分组业务）+ A301H:立即指配命令次数（分组业务）CA301J:立即指配命令次数（电路业务）)100。指标指标描述1.4.1 问题描述分析 对于PCU下面个别小区因业务量高导致话统指标“手机无响应导致下行TBF建立失败次数”较高，导致下行TBF建立成功率较低，晚忙时特别明显。 从CCCH上的下行TBF建立流程分析，对存在手

17、机无响应导致下行TBF建立失败次数较高的小区（沽源ZJGDO1D、沽源ZJGDO1C、沽源ZJGDO1B等），分析流控测量相关的话统指标“呼叫相关测量（CALL）-流控测量- Abis接口分组CCCH负载指示消息上报次数（此话统指标需要在M2000上先进行登记）”，发现重要信息：Abis接口分组CCCH负载指示消息上报次数非常多（见表1）起始时间GCELLL3188D:Abis接口CCCH负载指示（PCH）消息上报次数（分组业务）02/16/2011 19:00:00ZJDH899A16602/16/2011 19:00:00ZJDHB38F15202/16/2011 19:00:00ZJDH

18、B38G10102/16/2011 19:00:00ZJG801A10902/16/2011 19:00:00ZJG801B17802/16/2011 19:00:00ZJGB01A18402/16/2011 19:00:00ZJGB01B21102/16/2011 19:00:00ZJGB01C21602/16/2011 19:00:00ZJGB38A24002/16/2011 19:00:00ZJGB38D13102/16/2011 19:00:00ZJGD01B22602/16/2011 19:00:00ZJGD01C114表1 Abis接口分组CCCH负载指示消息上报次数当CCCH过载

19、，BSC收到测量小区所属的BTS报告的PACKET CCCH LOAD IND消息的次数，然后，BSC侧启动一个TN_CCCH_OVERLOAD_PROTECTION定时器，BSC为了降低CCCH拥塞程度，基于话音业务优先于分组业务的原则，分组域不重发下行分组立即指配，并且只发1个polling request，即只发1个IMM ASS和1个Polling Request消息。在TN_CCCH_OVERLOAD_PROTECTION定时器超时后，恢复正常。即正常情况下，如果手机对下行分组立即指配无响应的话，BSC会重发IMM ASS和Polling Request，直到手机有响应为止。而且每个

20、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信道

21、溢出严重，此时应及时采取路由区分裂、位置区分裂、增加BCH信道等优化措施；当CCCH负荷在60到75之间，此时CCCH信道溢出率指标不超过6，此次应予关注，必要时采取减少寻呼次数、增加CCCH信道数目等相关措施；当CCCH负荷低过60时，CCCH溢出次数比较少，只需针对个别问题小区进行优化处理。对于LAC区内的寻呼业务考虑。若A330A331寻呼容量典型值(每小时19万次)，需考虑对该LAC区内所有小区扩展BCH。对目前张家口华为区域现网的CCCH负荷分析来看，不存在整个LAC区下所有小区CCCH过载问题。对于个别小区CCCH过载评估，若(A337+A338+A339+A340+L3188A)

22、/ (A330A331)10%，表示出现寻呼消息丢弃，建议配置扩展BCH，扩容CCCH信道：对应的一个BCCH复帧中CCCH消息块数为：3、9、18、27、36。CCCH配置决定了PCH、AGCH和RACH容量。接入允许保留块数、CCCH配置参数会根据小区主B载频0信道配置类型动态调整：若小区CCCH配置为非“1个组合CCCH”，则接入允许保留块数缺省值修改为2，同时该参数的取值范围为17。若小区的CCCH配置为“1个组合CCCH”时，则将该小区对应的系统消息表中的接入允许保留块数缺省值修改为1，同时该参数的取值范围为12；默认情况下，一个小区只配置一个主BCCH，这样有“1个非组合的CCCH

23、”，那么CCCH在一个BCCH复帧中的消息块数就为9。如果多配置一个BCH，那么就有“2个非组合的CCCH”，那么CCCH在一个BCCH复帧中的消息块数就为18，很大程度上提高了CCCH的容量。1.4.3 优化前后效果比较以下是实施优化方案前后的对比效果：优化方案实施后Abis接口分组CCCH负载指示消息上报次数明显减少(见表2)，只有业务突发高峰造成的几次过载。起始时间GCELLL3188D:Abis接口CCCH负载指示（PCH）消息上报次数（分组业务）(无)02/16/2011 19:00:00ZJDH899A16602/17/2011 19:00:00ZJDH899A1802/16/20

24、11 19:00:00ZJDHB38F15202/17/2011 19:00:00ZJDHB38F002/16/2011 19:00:00ZJDHB38G10102/17/2011 19:00:00ZJDHB38G002/16/2011 19:00:00ZJG801A10902/17/2011 19:00:00ZJG801A002/16/2011 19:00:00ZJG801B17802/17/2011 19:00:00ZJG801B2902/16/2011 19:00:00ZJGB01A18402/17/2011 19:00:00ZJGB01A002/16/2011 19:00:00ZJGB

25、01B21102/17/2011 19:00:00ZJGB01B002/16/2011 19:00:00ZJGB01C21602/17/2011 19:00:00ZJGB01C002/16/2011 19:00:00ZJGB38A24002/17/2011 19:00:00ZJGB38A002/16/2011 19:00:00ZJGB38D13102/17/2011 19:00:00ZJGB38D202/16/2011 19:00:00ZJGD01B22602/17/2011 19:00:00ZJGD01B902/16/2011 19:00:00ZJGD01C11402/17/2011 19:

26、00:00ZJGD01C0表2 增加扩展BCCH信道前后的Abis接口分组CCCH负载指示消息上报次数从KPI上看，扩容CCCH后，下行TBF建立成功率已经有了很大的提高。忙时的下行TBF建立成功率由原来的80%多上升到90%以上（见表3），效果非常明显。起始时间网元名称GCELL下行EGPRS TBF建立尝试次数下行EGPRS TBF建立成功次数MS无响应导致下行EGPRS TBF建立失败次数下行EGPRS TBF建立成功率(%)02/16/2011 19:00:00ZKBS17ZJDH899A109709605136587.56%02/16/2011 19:00:00ZKBS9ZJDHB3

27、8F7274629597986.54%02/16/2011 19:00:00ZKBS9ZJDHB38G56694377129277.21%02/16/2011 19:00:00ZKBS17ZJG801A1138010097128388.73%02/16/2011 19:00:00ZKBS17ZJG801B119411094699591.67%02/16/2011 19:00:00ZKBS9ZJGB01A9352864670692.45%02/16/2011 19:00:00ZKBS9ZJGB01B102799273100690.21%02/16/2011 19:00:00ZKBS9ZJGB01

28、C9269828798289.41%02/16/2011 19:00:00ZKBS9ZJGB38A1362911909172087.38%02/16/2011 19:00:00ZKBS9ZJGB38D7968714981989.72%02/16/2011 19:00:00ZKBS9ZJGD01B123281135897092.13%02/16/2011 19:00:00ZKBS9ZJGD01C6738587286687.15%02/17/2011 19:00:00ZKBS17ZJDH899A127851227115095.90%02/17/2011 19:00:00ZKBS9ZJDHB38F5

29、06150016098.80%02/17/2011 19:00:00ZKBS9ZJDHB38G134791332715298.87%02/17/2011 19:00:00ZKBS17ZJG801A992698556999.20%02/17/2011 19:00:00ZKBS17ZJG801B124641173034394.10%02/17/2011 19:00:00ZKBS9ZJGB01A395039262499.30%02/17/2011 19:00:00ZKBS9ZJGB01B539953574299.20%02/17/2011 19:00:00ZKBS9ZJGB01C6214617341

30、99.30%02/17/2011 19:00:00ZKBS9ZJGB38A533252745798.90%02/17/2011 19:00:00ZKBS9ZJGB38D551354199398.20%02/17/2011 19:00:00ZKBS9ZJGD01B139971376121498.30%02/17/2011 19:00:00ZKBS9ZJGD01C548254453599.30%附录：相关话统含义说明1、PCH电路业务寻呼删除次数A337: CELL_CIRCUIT_PCH_DEL含义:本指标统计了PCH块上调度消息时存在竞争问题，记录电路域寻呼消息被删除的次数。BTS统计PCH电

31、路业务寻呼删除次数并每分钟上报一次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块上调度消息时存在竞争问题，记录分组域寻

32、呼消息被删除的次数。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作为电路业务的被叫时

33、，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接

34、口删除指示消息上报次数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上的分组业务过载将

35、会被认为是电路业务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消息，如果是分组

36、业务过多则向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消息的次数。