根据网络结构及对GPRS业务的处理单元，小区上行TBF建立失败的原因可以分为以下几类：
1 Radio Problem
在GPRS话务报告中有特定的Counter P28指明，从现场的分析观察来看原因可能是冲突和差的覆盖，不符合规范的终端发起的请求，TRE或BTS故障，TRE/RSL关系错乱等多种，并一定是完全由于无线信号不好导致。
2 Radio Congestion
在GPRS话务报告中有特定的Counter P27指明，表现为问题小区的PDCH处于繁忙的状态，需要增加小区的PDCH个数来解决。
3 BSS Resource Congestion
根据GPRS网络结构图和GPRS处理单元来看，BSS资源的拥塞是由于GPU处理能力、Abis/Ater传输资源等方面的瓶颈引起。在GPRS话务报告中由以下Counter指明：
P66：Number of UL TBF establishment failures due to the unavailability of the BVC (Gb interface problem) associated with the cell.
P105d：Number of UL TBF establishment failures due to GPU congestion.
P105f：Number of UL TBF establishment failures due to CPU processing power limitations
of the GPU.
P105h：Number of UL TBF establishment failures due to a lack of Ater resources.
P105j：Number of UL TBF establishment failures due to a lack of Abis resources.
P105l：Number of UL TBF establishment failures due to a too low number of GCH to
guarantee a minimum throughput for the UL TBF.This may happen when the number of TBFs is too high compared to the number of available GCHs.
4 BSS Problem
由于BSS系统原因而导致的小区上行TBF建立失败，在GPRS话务报告中没有明确的Counter定义，话务报告中所有的请求次数减去成功次数和以上三种类型的失败次数即为BSS原因导致的失败次数。
5 GB Problem
由于GB的原因导致的小区上行TBF建立失败，一般会影响同一个NSE下的多个小区，可以查看对应GPU下的多个小区同一时间的话务报告来确认。也可以通过以下两个Counter来间接验证
P43：Number of DL LLC bytes received from the SGSN at BSSGP level per cell.
P44：Number of UL LLC bytes received from the MS at BSSGP (08.18) sublayer per cell.
根据话务报告和GPU实时信息分析处理小区上行TBF建立成功率低的问题
根据话务报告和GPU的实时信息可以对上行TBF建立成功率低的小区进行分析，定位问题故障点并正确处理小区问题。以下主要是根据长期的观察和分析得出的方法，并不一定适用于所有情况，现场处理时还是要根据不同的情况观察分析。
1 从每个小时的话务报告中过滤上行TBF建立成功率低的小区（如G103>500，G106<10）并根据话务报告中小区建立失败原因G110/G111/G112对小区做初步分类；
2 在OMC-R终端上察看小区的GPRS状态、TRE/RSL状态、数据配置及BSC/MFS告警等，若有以上方面的问题先处理，若确认以上都无异常后可以继续。
3 若失败原因主要是G111（UL TBF Est Fail Rate Radio Cong），则可以初步判定为PDCH资源不足，也可以进一步来查看这个小区的PDCH复用度来确认；
4 若失败原因主要是G112（UL TBF Est Fail Rate BSS），则有可能是GPU资源block或传输有问题，可以按照以下方法逐步派查，
1）
真正的由于GPU原因导致的小区上行TBF建立成功率低一般表现为有上行TBF请求次数，但成功次数为零，通过Re-Initialize GPRS可以恢复，这个问题在B10 MR2 Ed07中已解决；若Re-Initialize GPRS不能使小区的性能恢复，需要继续排查第二路传输问题和GAter传输问题；
2） GAter传输引起的小区上行TBF建立成功率低一般会使同一个GPU下的多个小区都出现问题，可以在GPU网页中main menu->pmuMainMenu->aterMux的占用情况来找到有问题的小区占用哪一路AterMux，在BSS Ater Viewer中lock这一路AterMux，观察此时的小区情况；
3）
由于第二路传输引起的小区上行TBF建立成功率低，一般不会使成功率降为零，具体的成功率和第二路传输上的Extra Abis TS数目与第一路传输上的Basic Abis TS/Extra Abis TS的数目以及GPRS业务情况有关系，BTS上GPRS TS的分配顺序是Basic Abis TS> Extra Abis TS>Bonus Abis TS，可以通过Lock Secondary Abis Chain来观察；
4）由于GPU，GATER等资源不足导致的小区上行TBF建立成功率低也会归结到BSS problem，这种情况下需要查看话务报告中的p105系列，p383，p384等值来确定在那个环节出现了资源的拥塞；
5）若对小区做Re-intilalize GPRS后小区业务不能恢复，且没有查到明显的传输问题，则可以通过删创小区的GPRS业务使功能恢复；
5
若失败原因主要是G110（UL TBF Est Fail Rate Radio），这种情况比较复杂，真正的无线原因，无线负荷过高，TRE隐性故障，终端原因等都会统计到G110
1）
扩容后AGCH负荷过高引起上行TBF建立成功率低，表现为请求次数比正常时间段多很多，在Cell的MS Allocation页面中如下图所示，上行占用很多而下行很少，此种情况可以通过开关HR或删创RSL来恢复，该问题在B10 MR2 Ed07中已解决；
2）
从话务报告上看，上行请求次数是正常时的几倍，但成功率很低，通过观察cell的PDCH Group的页面，如下图所示，可以发现有一个载频Traffic很忙，另一个载频只有Radio占用，但是一直没有Traffic（可以观察如两三分钟等相对长的一段时间），此种情况有可能是这个TRE有问题，可以尝试通过Lock/Unlock TRE或Change Perf_Mark来解决；
3）
请求次数不多，出现很随机，多是是微蜂窝和MBO，做Lock/Unlock TRE，change Perf_mark等也不会恢复，但过一段时间（一两个小时或几个小时）会自动恢复；
4）
请求次数不多，出现频率较多，做Lock/Unlock TRE，change Perf_mark等也不会恢复，但过一段时间（一两个小时或几个小时）会自动恢复，目前没有好的处理方法；
5）一些小区（多为高校或临时集会场所）会在固定时间出现，且请求小区的上行TBF建立请求很多，一般可达20万次，连续观察次小区的情况，一般请求次数降低后，成功率一般会有明显改善，这种小区可以查看GSM报告的MC8C的值来确定是否是由于AGCH复合过高导致；
卡特设备GPRS上行TBF建立成功率低原因分析与提升.doc (392 KB)
关注楼主