呼叫建立成功率低的分析及解决(正式)

1、“无线网络优化经验研究”之呼叫建立成功率的分析及解决PAGE 第 PAGE 42 页 共 NUMPAGES 43 页“无线网络优化经验研究”之呼叫建立成功率的分析及解决呼叫建立成功率的分析及解决目录 TOC o 1-4 h z HYPERLINK l _Toc27153433 第一章 前言 PAGEREF _Toc27153433 h 2 HYPERLINK l _Toc27153434 第二章 呼叫建立过程及相关信令流程 PAGEREF _Toc27153434 h 3 HYPERLINK l _Toc27153435 一.正常呼叫建立的信令流程 PAGEREF _Toc27153435 h

2、 4 HYPERLINK l _Toc27153436 1.移动台做主叫的信令接续过程 PAGEREF _Toc27153436 h 4 HYPERLINK l _Toc27153437 2.移动台做被叫的信令接续过程 PAGEREF _Toc27153437 h 5 HYPERLINK l _Toc27153438 二.呼叫建立的流程简述 PAGEREF _Toc27153438 h 6 HYPERLINK l _Toc27153439 1.被叫号码分析过程 PAGEREF _Toc27153439 h 6 HYPERLINK l _Toc27153440 2.话音信道指配过程 PAGERE

3、F _Toc27153440 h 6 HYPERLINK l _Toc27153441 1)呼叫建立过程所对应的初始化信道分配过程 PAGEREF _Toc27153441 h 8 HYPERLINK l _Toc27153442 2)三种初始化信道指配方式的信令接续过程 PAGEREF _Toc27153442 h 9 HYPERLINK l _Toc27153443 3.呼叫连接过程 PAGEREF _Toc27153443 h 10 HYPERLINK l _Toc27153444 4.被叫的呼叫建立过程 PAGEREF _Toc27153444 h 11 HYPERLINK l _To

4、c27153445 5.小区内部切换过程 PAGEREF _Toc27153445 h 12 HYPERLINK l _Toc27153446 6.呼叫重建过程 PAGEREF _Toc27153446 h 13 HYPERLINK l _Toc27153447 1)MS侧首先察觉无线链路失败时呼叫重建程序 PAGEREF _Toc27153447 h 13 HYPERLINK l _Toc27153448 2)BSS侧首先察觉无线链路超时呼叫重建程序 PAGEREF _Toc27153448 h 13 HYPERLINK l _Toc27153449 3)呼叫重建的规则 PAGEREF _T

5、oc27153449 h 13 HYPERLINK l _Toc27153450 第三章 呼叫建立成功率的计算公式 PAGEREF _Toc27153450 h 15 HYPERLINK l _Toc27153451 第四章 可能导致呼叫建立成功率低的原因及其解决方法 PAGEREF _Toc27153451 h 16 HYPERLINK l _Toc27153452 一.没有可用的资源导致呼叫建立成功率低 PAGEREF _Toc27153452 h 16 HYPERLINK l _Toc27153453 1.无线信道容量不足导致呼叫建立成功率降低 PAGEREF _Toc27153453

6、h 16 HYPERLINK l _Toc27153454 1)SDCCH信道拥塞 PAGEREF _Toc27153454 h 16 HYPERLINK l _Toc27153455 2)TCH信道拥塞 PAGEREF _Toc27153455 h 16 HYPERLINK l _Toc27153456 2.有线信道容量不足导致呼叫建立成功率降低 PAGEREF _Toc27153456 h 17 HYPERLINK l _Toc27153457 1)BSS的CIC电路拥塞 PAGEREF _Toc27153457 h 17 HYPERLINK l _Toc27153458 2)MSC间的电

7、路拥塞 PAGEREF _Toc27153458 h 17 HYPERLINK l _Toc27153459 二.无线环境恶劣导致呼叫建立成功率低 PAGEREF _Toc27153459 h 17 HYPERLINK l _Toc27153460 1.覆盖问题 PAGEREF _Toc27153460 h 17 HYPERLINK l _Toc27153461 1)覆盖空洞 PAGEREF _Toc27153461 h 17 HYPERLINK l _Toc27153462 2)高大建筑物的阴影效应 PAGEREF _Toc27153462 h 17 HYPERLINK l _Toc2715

8、3463 3)漂移信号 PAGEREF _Toc27153463 h 17 HYPERLINK l _Toc27153464 2.干扰问题 PAGEREF _Toc27153464 h 18 HYPERLINK l _Toc27153465 1)上行干扰 PAGEREF _Toc27153465 h 18 HYPERLINK l _Toc27153466 2)下行干扰 PAGEREF _Toc27153466 h 18 HYPERLINK l _Toc27153467 三.系统性能与参数配置问题导致呼叫建立成功率低 PAGEREF _Toc27153467 h 19 HYPERLINK l _

9、Toc27153468 1.MSC、BSC参数配置不当 PAGEREF _Toc27153468 h 19 HYPERLINK l _Toc27153469 2.信令流量超出BSS系统所能承载的最大负荷 PAGEREF _Toc27153469 h 19 HYPERLINK l _Toc27153470 3.BSS系统软件故障 PAGEREF _Toc27153470 h 20 HYPERLINK l _Toc27153471 4.BSS系统中的处理器负荷过重 PAGEREF _Toc27153471 h 20 HYPERLINK l _Toc27153472 四.设备故障导致呼叫建立成功率低

10、 PAGEREF _Toc27153472 h 20 HYPERLINK l _Toc27153473 1.基站硬件故障 PAGEREF _Toc27153473 h 20 HYPERLINK l _Toc27153474 2.基站软件进程异常 PAGEREF _Toc27153474 h 21 HYPERLINK l _Toc27153475 3.基站天馈线系统故障 PAGEREF _Toc27153475 h 21 HYPERLINK l _Toc27153476 4.基站传输闪断 PAGEREF _Toc27153476 h 21 HYPERLINK l _Toc27153477 第五章

11、 呼叫建立成功率案例分析 PAGEREF _Toc27153477 h 23 HYPERLINK l _Toc27153478 一.实例：硬件故障 PAGEREF _Toc27153478 h 23 HYPERLINK l _Toc27153479 二.实例：天线反接 PAGEREF _Toc27153479 h 25 HYPERLINK l _Toc27153480 三.实例：TCH拥塞 PAGEREF _Toc27153480 h 28 HYPERLINK l _Toc27153481 四.实例：系统中的处理器负荷过重 PAGEREF _Toc27153481 h 30 HYPERLINK

12、 l _Toc27153482 五.实例：MSC侧的问题 PAGEREF _Toc27153482 h 33 HYPERLINK l _Toc27153483 六.实例：日常优化事例 PAGEREF _Toc27153483 h 37 HYPERLINK l _Toc27153484 第六章 处理呼叫建立不成功的思路 PAGEREF _Toc27153484 h 39 HYPERLINK l _Toc27153485 一.处理呼叫建立成功率低的流程图 PAGEREF _Toc27153485 h 39 HYPERLINK l _Toc27153486 二.处理呼叫建立成功率低的一般步骤 PAG

13、EREF _Toc27153486 h 40 HYPERLINK l _Toc27153487 第七章 结束语 PAGEREF _Toc27153487 h 42第一章 前言呼叫建立成功率作为反映网络性能的一项重要指标，一直是网络优化工作关注的重点之一。在移动通信中，呼叫建立过程通常是指由SDCCH信道指配到TCH信道时的信令接续过程。我们通过处理信令接续期间相关进程上的原始统计项在一定周期内的统计数据，按照预设的算法加以计算，由此得到呼叫建立成功率。通过对连续周期的计算结果加以评估比较，来帮助优化人员分析拥塞趋势和可能的出现的相关网络问题。同时，从用户感知的角度分析，有一些呼叫的信令在还没有

14、接续到SDCCH信道之前就被截止了。对于这类情况，从呼叫建立成功率上无法体现出来。但对于用户而言，则表现为不能正常接入网络。为了更好的改善网络性能，提高用户满意度。本文通过研究呼叫建立过程，以及期间可能出现的问题，提出一些解决呼叫建立成功率低的思路和方法，以供大家参考。第二章 呼叫建立过程及相关信令流程呼叫建立过程是在移动台（MS）与移动交换机（MSC）之间建立一条信令链路，并要对移动用户进行鉴权、加密及TMSI重分配的过程。下面我们从移动台主、被叫的建立信令接续过程入手，进一步分析了解与呼叫建立相关的各个消息历程。正常呼叫建立的信令流程移动台做主叫的信令接续过程移动台做被叫的信令接续过程呼叫

15、建立的流程简述被叫号码分析过程移动台进入呼叫建立过程。首先由移动台向网络发出一个启动（SETUP）的消息，该消息包含着被叫号码和所需业务等许多内容，此时MSC就能够根据它来进行呼叫接续。当MSC收到SETUP消息，就要将该消息通过向其VLR发送出局呼叫消息,VLR在收到该消息后，根据其从HLR获得的该用户数据消息，来分析被叫的号码和主叫用户本身的能力，以及网络本身的资源能力等等，核对是否能接纳这种需求，若某些项目不能通过，则向MS发出释放完成（RELEASE COMPLETE）的消息，呼叫建立就此失败，以后MS再将底层的连接释放掉，然后转入空闲状态；若可以通过VLR则向MSC发回完成呼叫能力查

16、询（COMPLETE_CALL）的消息。当MSC收到此确认后则向MS发出呼叫继续（CALL PROCEEDING）的消息，表示主叫用户的呼叫请求已经通过了核对，呼叫继续进行。话音信道指配过程在MSC向MS发出CALL PROCEEDING消息后，它就要根据业务请求，来激活后续分配，即分配给用户TCH话音信道的流程。此时，MSC要向BSC发出指配请求（ASSIGNMENT REQUEST） 消息，在此消息中将含有所请求信道的类型等内容来要求BSC来给此次呼叫分配TCH话音信道。BSC在收到MSC的信道请求后，如果发现有TCH信道资源的话就会向BTS发出请求激活TCH信道（CHANNEL ACTI

17、VATION for TCH）的消息，来激活相应的地面资源，该消息发出的也会启动本身的一个计时器，若该BTS将电路等资源准备好后，就会向BSC发出信道激活响应（CHANNEL ACTIVATION ACK）的消息。若此时BSC已无资源则向MSC返回无资源（RESOURCE FAILURE）的消息，而系统允许排队的话，则BSC向MSC发出排队指示（QUEUING INDICATION）的消息，并将指配请求消息放入队列同时打开T11定时器，如定时器超时则向MSC发出清除请求（CLEAR REQUEST）。其中立即指配请求，BSC内切换，BSC间切换是不许排队的，仅TCH资源请求（即指配请求和小区内

18、部切换）允许根据内部优先级的的指示来按优先顺序给相应的请求分配在规定时间内被释放掉的信道，若排队长度或等候时间超出要求则请求将被拒绝。在BSC收到BTS发出信道激活响应（channel activation ack）的消息后，就按照BTS所提供的该信道的物理信息将它放在指配命令（ASSIGNMENT COMMAND）的消息中（该消息中包含着信道类别如话音/数据的指示，信道的速率和类别及话音解码算法和透明传输指示时器，分配优先级以及CIC电路识别码）通过SDCCH信道发给MS。在MS收到基站发来的ASSIGNMENT COMMAND消息后，将会就将收发信配置调整到该TCH信道上，通过FACCH信

19、道（此后传递信令，将都采用该信道形式，它就是利用的TCH信道，唯一不同是将TCH突发脉冲的标识位由0改为1，这种形式被称为偷帧）向系统发出SABM消息，系统在收到该消息后，会向BSC发出ESTABLISH INDICATION建立指示消息，同初始分配信令信道一样，需系统再发回一条UA的证实帧。当MS收到UA帧后将通过FACCH信道向系统发出分配完成（ASSIGNMENT COMMPLETE）消息，若因无线接口失败、无线接口消息失败或因干扰和硬件问题无法识别指配信息等原因MS无法占用该指定的信道，MS就会向系统发出ASSIGNMENT FAILURE（指配失败），若因干扰等原因MS未收到系统发给

20、它的指配命令或系统未收到MS的响应导致在BSC未收到MS返回的消息，则系统将该信道释放掉。在BSC收到分配完成的信令后，一方面向MSC发出指配完成（ASSIGNMENT COMPLETE）消息，一方面向BTS发出无线信道释放（RF CHANNEL RELEASE）消息，要求将以前占用的SDCCH信令信道资源释放掉，当BTS完成了信令信道的释放后，将发给BSC一条信道释放完成（RF CHANNEL RELEASE ACK）消息，BSC收到此消息后就认为该信道已返回到空闲状态下，该资源可以用于分配给新的信道请求。图示 业务信道指配过程呼叫建立过程所对应的初始化信道分配过程初始化信道分配是移动台与网

21、络之间建立信令传输所必须的，在建立信令传输过程中，系统可首先选择给它分配TCH信道，这被称为特别早指配；若首先选择给它分配SDCCH信道，在需要时才分配TCH信道，这被称为早指配；若首先选择给它分配SDCCH信道，当在被叫端发回连接消息（CONNECT）时，才分配TCH信道，这被称为晚指配-停止广播建立呼叫（OACSU），目前我们所采用的是早指配方式。晚指配方式使系统具有较高的业务信道（TCH）资源利用率，但同时使独立专用信道（SDCCH）的负荷加重；反之，特别早指配方式可以降低SDCCH的负荷，但使TCH的利用率降低。一般而言，对于试呼次数较高，通话平均时间较短的小区，可以采用特别早指配方式

22、。相反，对于试呼次数较少，平均通话时间较长的小区，可以采用早指配方式。在实际操作过程中，系统的TCH资源较宝贵，因此建议采用早指配方式。只有当系统中出现立即指配拒绝（原因为无可用无线资源）次数较高，而小区中TCH的平均占用率很低时，才使用特别早指配方式。此外，对于移动主叫、移动被叫、呼叫重建及紧急呼叫过程的指配方式可以分别处理，因此在出现SDCCH的负荷很高而TCH的平均占用率很低的情况时，应对上述三种呼叫过程的指配方式进行逐步调整。即可以先对被叫过程采用特别早指配，在情况依然不佳时，再逐步开启主叫、呼叫重建和紧急呼叫的特别早分方式。三种初始化信道指配方式的信令接续过程下面是移动台主叫时不同初

23、始化信道指配方式的信令接续过程：早分配Early Assignment without OACSU晚分配Late Assignment with OACSU特别早分配Very Early Assignment呼叫连接过程当收到BSC发回的指配完成消息后，MSC在向被叫端送出初始化地址IAM消息，不用很久就会收到被叫端网络发回的有关呼叫建立的报告，若成功MSC则会收到ADDRESS COMPLETE地址完成消息。如果因某种原因（如对端占线或线路拥塞等等）呼叫建立失败，主叫MSC则会收到被叫端发出的RELESASE释放消息。如果MSC收到被叫端发回的ADDRESS COMPLETE 地址完成消息后

24、，MSC会将ALERTING提醒消息发给该MS（该消息可由MS翻译成回铃音），该消息属DTAP消息类别，若被叫不应答而主叫也没有终止的动作，经过一定的时间，网络端会终止呼叫或可执行无应答转移。如此时被叫摘机，MSC会收到被叫端发回的ANSWER应答消息，此时主叫与被叫之间的链路接通，MSC将发给MS一条CC协议中的CONNECT接通消息，MS收到该消息后将停止待命指示，接着向系统返回CC协议中的CONNECT ACKNOWLEDGE接通确认，当系统收到此消息时，就开始记费。如被叫端是数据设备，在收到SETUP指示后可直接进入CONNECT 状态。这时呼叫建立过程完毕，双方进入通话或传送数据业务

25、阶段。被叫的呼叫建立过程当MSC完成了对移动台的TMSI重新分配后，就会向移动台发一条启动（SETUP）的消息，其中包括了呼叫所必须的细节（如请求的业务类别和主叫号码等），被叫移动台收到此消息后，则将该消息进行核实，如果移动台能处理主叫请求的业务类别，就返回一条呼叫核准（CALL CONFIRMED）消息，在该消息中，还将携带着移动台选定的参数，如移动台可选用哪一种速率的信道和选定的业务类别。当MSC收到呼叫核准的消息后，将向BSC发起指配请求，来给被叫用户分配话音信道。指配过程完成消息后，被叫移动台将向网络发出待命（ALERTING）的消息，此时被叫移动台将出现振铃提示，MSC在收到该指示后

26、，则向主叫方发出地址完成的消息（ACM），主叫端在收到该消息后也会将该提示发给主叫用户。此时，被叫用户在听到提示，作应答后，即将发送给MSC一条接通（CONNECT）的消息，MSC在收到此消息后接通全部传输链路，用户端到端的传输路径正式建立。下面是移动台被叫时不同初始化信道指配方式的信令接续过程：早分配Early Assignment without OACSU晚分配Late Assignment with OACSU小区内部切换过程小区内部切换过程和指配过程的程序是一样的，只是消息的名称不同而已。 和立即指配过程有些类似，当在MS 的指配过程中，BSC将触发一个T3107的定时器，该定时器在

27、BSC向BTS发送指配命令（ASSIGNMENT COMMAND ）的消息启动，在收到BTS发出的指配完成时（ASSIGNMENT COMPLETE ）时，将该定时器复位。该定时器逾时一般是由于无线链路覆盖很差导致的，当此定时器逾时后，将认为移动台已脱网，则将占用的该资源释放掉让给其它的移动台。如在设置时间内BSC仍未收到指配完成消息，则该指配过程失败。小区内部切换呼叫重建过程呼叫重建程序是允许移动台在无线链路失败后，来重新恢复连接的一个过程，呼叫重建可能会建立在一个新的小区或新位置区上。在无线环境下，一条无线链路很有可能突然中断，这可能是由于桥梁、建筑物、隧道等障碍物给移动台造成的严重传播损

28、耗，当采用该机制后，移动台便可利用另一小区，在很短的时间内恢复通话，在某种程度上可改善网络的服务质量。可以认为呼叫重建是一种移动台发起的切换，但只限于对当前小区丢失的呼叫，来用于挽救呼叫的一种极端情况。呼叫重建根据首先察觉无线链路失败的实体不同，将会导致两个不同的建立程序。MS侧首先察觉无线链路失败时呼叫重建程序 移动台将在被选中的小区上（可能是原小区，也可能是新小区）发送一个呼叫重建的请求。以前的信道资源将在BTS侧的定时器radio_link_timeout或 link_fail超时后被BSC释放掉。BSS侧首先察觉无线链路超时呼叫重建程序在BTS侧的定时器radio_link_timeo

29、ut或 link_fail超时后，BTS将发送一个无线链路故障的消息到BSC。此后BSC将释放掉旧的无线资源，同时MSC将激活定时器T3109来等待移动台的呼叫重建。而后移动台通过一段时间的观察，当检测到无线链路失败后，它就会通过来选择一个合适的邻小区，并在选中的小区上发出信道请求。呼叫重建的规则如果要想一个小区支持呼叫重建，那么小区参数Call Reestablishment必须要设为“allowed”，而且该小区不能是被禁止的（cell barred）。 移动台最多在5秒钟之内应该根据以下算法来决定，在哪个小区上进行呼叫重建。根据在SACCH上携带的邻小区的BA表（频率分配表），来测量服务

30、小区和相邻小区的BCCH载波的接收电平，并根据5秒的测得的平均测量样本值来选择一个接收电平最高的小区作为呼叫重建的目标小区。在BCCH频点上，移动台将试图去解码BCCH所携带的影响小区选择的系统消息，当该小区未被禁止、C1值大于0并且允许呼叫重建时，将选择该小区。否则，将选择次强的小区进行重试以上的步骤。当接收电平最强的6个小区都被尝试但都不合乎条件时，则放弃该次呼叫重建。第三章 呼叫建立成功率的计算公式CALL_SETUP_SUCCESS_RATE 统计值显示了对于正常呼叫、呼叫重建、寻呼响应、紧急呼叫以及短消息等服务请求时，呼叫成功接入TCH信道的百分率。CALL_SETUP_SUCCES

31、S_RATE在MOTOROLA的统计项中属于Key统计，它是使用一条预先制定的规则，对OMC-R不同的原始统计数据运算产生新的统计值。原始统计项： CONGEST_ASSIGN_HO_SUCOK_ACC_PROCCM_REESTABLISHOK_ACC_PROCCM_SERV_REQ_CALLOK_ACC_PROCCM_SERV_REQ_EMERGOK_ACC_PROCCM_SERV_REQ_SMSOK_ACC_PROCPAGE_RESPONSESMS_INIT_ON_SDCCHTOTAL_CALLS呼叫建立成功率的分子计算了完成的呼叫建立TCH分配任务的数字，其中包括由于使用定向重试（Dir

32、ected Retry）功能，分配到相邻小区TCH上的数字。呼叫建立成功率的分母计算了请求分配TCH的SDCCH接入的数字。第四章 可能导致呼叫建立成功率低的原因及其解决方法导致呼叫建立成功率降低的因素有很多，首先如果没有可用的有线或无线资源，系统就无法正常给用户分配信道；其次，即使有充足资源，由于无线传播环境的复杂性，不同的覆盖条件和干扰等级，都会影响呼叫建立成功率；另外，由于系统自身配置不当，以及突发的硬件故障，也会造成呼叫建立成功率下降。针对这些可能导致呼叫建立成功率降低的因素，下面我们从四个方面进行具体的分析。没有可用的资源导致呼叫建立成功率低无线信道容量不足导致呼叫建立成功率降低SD

33、CCH信道拥塞小区SDCCH信道由于话务容量、基站软件或硬件故障导致小区SDCCH信道分配异常、LAC区的划分不合理、基站信道配置等多种原因造成拥塞。从而导致该小区的手机在呼叫时，SDCCH信道指配失败。造成在该小区的用户无法正常呼叫。针对这种情况，应尽快调整相关参数；查找到硬件故障，锁死相应载频；甚至对基站做强制重启动。以缓解SDCCH拥塞。随后，根据需要合理配置SDCCH信道，划分位置区域。TCH信道拥塞小区TCH信道由于话务容量、基站小区参数配置不合理、基站软件或硬件故障手机无法正常占上TCH信道或基站的其它异常等多种原因造成拥塞。从而导致该小区的手机在呼叫时，因没有TCH信道而得不到信

34、道指配。造成在该小区的用户无法正常呼叫。针对这种情况，应尽快调整相关参数（如小区发射功率、流量控制、排队等）；重新激活故障信道；进行天线调整。以控制小区TCH接入量，缓解TCH拥塞。进而根据需要合理配置TCH信道数目。注：引起SDCCH、TCH拥塞的原因有许多，在其它的部分中，我们已进行了专题论述分析。这里就不再一一重述了。有线信道容量不足导致呼叫建立成功率降低BSS的CIC电路拥塞当一个BSC所承载的载频数量增长到一定量时，随着用户数和业务量的增长，由BSC到MSC的CIC电路的电路数也要相应增加。当BSC承载的用户数过高，或由于一些高端用户长时间使用数据业务，一直占用部分CIC电路。致使C

35、IC电路数不足，MSC将无法在CIC电路拥塞的情况下为呼叫请求建立连接，引起呼叫失败。针对这种情况，应及时根据CIC电路的忙闲统计，相应增加BSC到MSC的CIC电路数；以及对不同BSC,MSC之间的话务量进行均衡。MSC间的电路拥塞当MSC之间或本网与外面其它网络间的电路数配置不足时，MSC将无法为过多呼叫请求建立连接，引起呼叫失败。针对这种情况，及时根据需求补足网间电路，即可解决问题。无线环境恶劣导致呼叫建立成功率低覆盖问题覆盖空洞因为基站太少导致覆盖不连续或室内信号强度较弱。造成MS与BTS之间的上、下行信令链路不能正常通信。致使MS或BTS不能正确解调出相关信息。高大建筑物的阴影效应移

36、动台在移动过程中由于一些高大建筑物所产生的阴影效应而导致移动台信号发生快衰落，导致小区上、下行传输损耗增大，通信质量下降。致使MS或BTS不能正确解调出相关信息。漂移信号由于高站、覆盖不规则的基站导致的信号漂移。导致信号强度变化较大，同时形成一定成程度同邻频相互干扰。造成通信质量下降。问题分析：在覆盖较差的区域，常常发生呼叫不能建立的情况。除了通过调整基站天线覆盖范围或新加站解决覆盖以外，某些时候是由于服务小区的参数设置存在问题，例如：呼叫没有达到小区的最小接入电平；服务小区所在的基站，将poor_initial_assignment=1即距离较远的RACH信息加以滤除。当用户处于ms_max

37、_range设定范围之外时，不予接入系统。这种情况只对于用户有感受（如用户在没有达到最小接入电平时，在做被叫时会被当作不再服务区），而不计入呼叫建立成功率的统计公式中。另外，则是由于在呼叫建立的过程中，由于服务小区的信号强度不稳定，上、下行传输质量差造成在接续过程中的信令丢失。从而导致SD、TCH的接入失败，无法建立呼叫。这种情况有可能计入呼叫建立成功率的统计公式。针对以上情况，应在覆盖差的区域，通过小区覆盖调整；新建宏蜂窝和微蜂窝改善原有覆盖。同时，针对个别地区综合测试的结果，相应的调整小区相关参数（例如：C1，C2，CRO的设置；T3101；T3109设定时长等）。干扰问题无线干扰主要包括

38、同频干扰、邻频干扰、交调干扰。当手机在服务小区中收到很强的同频或邻频干扰信号时，会引起误码率恶化，使手机无法准确解调小区的BSIC码或不能正确接收移动台测量报告。干扰导致的上、下行传输质量差会造成在接续过程中的信令丢失。基站分配给移动台的SDCCH信道频点可能与TCH信道频点不同，因而需要对它们分别进行分析。从确定呼叫建立过程中哪个阶段为干扰所影响。上行干扰针对上行干扰：这种干扰为目前的主要干扰现象。上行干扰主要发生在话务高峰期它主要来源于同频干扰，也可能是外部干扰，同频干扰与同频小区的话务量有关，话务量高则干扰大，外部干扰主要是来自直放站的交调干扰，以及电力通信微波、CDMA相邻频段的直接干

39、扰。对上行干扰可通过分析驱车测试中的相关报告，修改同频小区的同频频率，增加两个同频小区间的间距（实际统计表明信号强度随距离以近似4次幂指数的规律衰减）或利用频谱分析仪对交调干扰加以定位，通过分集接收和有效的功率控制也可减少干扰。对无上述情况但有干扰的小区可用频谱分析仪,采用有源定向天线配合寻找干扰源。下行干扰针对下行干扰：这种干扰不是很普遍。下行干扰主要是由于频率规划不当而造成部分基站的同频干扰和邻频干扰。发现的方法是通过在OMC中取得相关载频的BER统计；MOTOROLA优化工具CTP测量报告来加以判断，下行干扰会引起频繁下行切换。通过测量报告和现场实测如发现存在同频和邻频干扰，需对蜂窝系统

40、的频率规划重新进行优化调整。系统性能与参数配置问题导致呼叫建立成功率低MSC、BSC参数配置不当对于位置更新参数T3212的定义，当MSC定义的定期位置更新时长小于BSC小区中定义的T3212时长，会导致当用户手机在固定周期内未发生通信时，MSC会在BSC强制MS做周期性位置更新之前，将MS的状态置为关机。从而使用户在开机的情况下，无法建立被叫，被告知用户已关机。为避免这种情况，必须核准各个小区中的T3212值小于当前所在MSC中定义的周期性位置更新时长。BSC中的相关参数设置不合理，造成MSC、BSC间呼叫建立过程中，MSC或BSC由于计数器超时，在未收到确认信息的情况下，主动拆线，释放信道

41、。解决方法：核对MSC、BSC的相关信令接续时长的计数器设定值，使计数器设定能够保证正常通信。信令流量超出BSS系统所能承载的最大负荷由于信令流量超出了BSC的信令承载能力，导致小区内用户无法成功建立呼叫。此情况主要针对BSC中LCF的信令承载，当SSM进程的处理门限达到BSC流量控制设定值时: ssm_critical_overload_threshold=80% ，ssm_nrm_overload_threshold=70%。LCF会将对超过门限BTS小区，限制用户呼叫，只允许切换。目前，LCF最大可同时支持250个(GSR4版本)激活的呼叫（GSR5版本支持400个）。针对这种情况：当发

42、现多个基站小区被BAR时，应及时检查一个LCF下是否配置了过多的基站。如果存在此问题，应将部分基站割接到其它的LCF上去。BSS系统软件故障由于BSC、BTS在重新装载数据库过程中软件出错，导致相关LCF或BTP控制下的基站突发呼叫建立成功率降低。此情况曾发生在CSFP与主用BSP倒换后；BSC内部电路主备切换后，个别LCF装载数据过程中软件出错，从而导致对BTS、MTL的控制出现问题。针对这种情况，当出现多个BTS或者整个BSC出现突然的呼叫建立成功率下降时，在通过检查SWFM告警、A接口信令分析以及BTS、BSC相关状态和统计分析后，可根据情况的严重程度复位出相应的GPROC板，重新加载数

43、据就能解决问题。BSS系统中的处理器负荷过重由于超出BSC、BTS中控制单元处理器门限，导致小区内用户无法成功建立呼叫。当BSC、BTS中的CPU单元工作在非正常状态时，即处理的消息量远远超出了CUP本身性能所能负担的水平，或者没有足够的内存处理相关的进程。都会导致处理器丢掉溢出的数据，甚至直接使处理器进程吊死。这种情况下，除了针对普遍性问题更换更高性能的处理器外；还要仔细检查基站的软、硬件相关告警，滤除由于偶发因素造成的突发CPU单元故障。对于由于突发高话务量造成的处理器负荷上升，可以通过降低基站话务量；增加新的LCF分担BSC的信令处理负荷。设备故障导致呼叫建立成功率低基站硬件故障由于小区

44、中载频内部发生了故障。可能会导致通话不能正常的接续到相关的硬件上，对于承载BCCH、SDCCH、TCH等不同类型信道的载频，其表现也不相同。一般来说：当BCCH所在的载频出现问题时，呼叫将不被接入，Total_call为零。当SDCCH所在的载频出现问题时，可能会出现SD拥塞或SDCCH掉话升高。当TCH所在的载频出现问题时，可能会出现TCH拥塞或单个载频掉话升高。针对这种问题，可以通过锁住可疑的载频进行判断。在有些时候，通过INS指令对载频进行复位后，问题即可得到解决。基站软件进程异常由于基站软件、硬件存在故障导致小区分配SDCCH信道发生异常（例如：SDCCH吊死）。由于基站软件、硬件问题

45、，导致信令信道出现问题，从而在信令的分配流程上出现问题，导致接续失败。这种情况，从统计上常能看到chan_req_ms_fail；ma_fail_from_ms的次数很高。针对这种问题，应及时对从统计上反映出表现较差的载频进行复位。甚至对基站做软、硬重启动。基站天馈线系统故障天馈线损伤、进水、打折和接头处接触不良，均会降低发射功率和收信灵敏度，导致小区上、下行传输损耗增大，通信质量下降。由于两副天线俯仰角不同而产生的掉话基站安装过程中每个定向小区均有主集和分集两副天线，该小区的BCCH和SDCCH就有可能分别从两副不同的天线发出。当两副天线的俯仰角不同时，就会造成两副天线的覆盖范围不同，即会出

46、现当用户能收到BCCH信号，但产生呼叫时却因无法占用另一天线发出的SDCCH。在基站安装过程中每个定向小区均有两副天线，当两副天线的方位角不同时，就会形成一个方向中的用户可以收到控制信号SDCCH，但用户一旦被指定为由另一副天线发射出的TCH时，另一个方向中的用户将无法收到信号。这种情况，常出现在新站安装过程中，相邻小区天线被反接或错接。针对以上情况，首先应到基站现场进行观测。如不能发现问题可以通过对故障小区进行拨打测试（CQT）或驱车测试并结合从OMC中得到的相关统计项（ma_fail_from_ms）配合MOTOROLA优化工具（如CTP）来发现故障原因，并及时调整天线方位角和俯仰角。由于

47、天馈线损坏或接头接触不良致使发射功率和收信灵敏度降低，可采用天馈线测试仪对天馈线进行测量来判断故障原因及故障点，并及时更换故障天馈线和接头。基站传输闪断由于基站RSL受于中继传输问题、硬件NIU、MCU故障等原因造成间隙式中断，导致在小区建立呼叫的用户信令接续中断，致使total_call/ok_acc_proc值变小，致使统计中呼叫建立成功率下降。第五章 呼叫建立成功率案例分析实例：硬件故障分析Figure 5-1& Figure 5-2，我们可以看到由十月三日开始连续七天cell-3018的呼叫建立成功率下降至30% ，同时其SDCCH的阻塞率达到65%。Figure 5-1 Call S

48、etup Success for 3018Figure 5-2 Call setup vs SDCCH Setup blocking for 3018发现呼叫建立成功率下降后，针对小区利用工具CTP 进行呼叫跟踪分析。我们发现其中一个载频RTF61没有收集到任何测量报告，从这个载频得不到呼叫的记录，意味这个DRCU一直不能被占用。从Figure 5-1 看到呼叫数量也自十月三日起急剧下降，由此我们怀疑，cell-3018的呼叫建立成功率下降时由于小区中某一载频故障，造成分配至RTF61的TCH接入失败。因此，承载RTF61的DRCU在经过完整的硬件校验后，重启恢复正常。在十月十一日Call S

49、etup Success rat恢复到原来的90+%。此案例中，没有任何告警出现在EVENT LOG，从而我们可以看到MOTOROLA工具的应用，对于提早发现并解决Call setup和SD Setup blocking等最差小区性能问题有很多帮助。实例：天线反接分析Figure 5-3& Figure 5-4，对于同一个站的两个小区，Call Setup Success rat均在70%以下。Figure 5-3 Call setup Success Rate for 121Figure 5-4 Call setup Success Rate for 121通过对基站利用工具CTP 进行呼叫

50、跟踪，分析call trace summary & path balance，我们可以发现存在一些问题。CTP信息概要Figure 5-5 Cell -121 Path Balance从CTP概要信息中，我们可以看到Cell 121的BCCH所在载频的path balance平均值为-17.88，显示出其传输路径上存在一定问题；同时作为重要的补充，可以看到其下行RXQUAL分布主要集中于5-7。加之,NON BCCH 载频的path balance也显示出类似的现象。由此，我们怀疑基站硬件及其收发单元的射频连接（包括馈线、电缆、射频接口等）存在问题。 Figure 5-6 基站内部馈线连接在十

51、月十日，我们前往基站做硬件完整检测时发现，Cell 121 BCCH所在载频连接的双工器，其ANT端口的电缆错误的连到Cell 123 天线上；而Cell 123 TCH所在载频连接的双工器，其ANT端口的电缆错误的连到Cell 121 天线上（Figure 5-6）。因此造成两小区天线的反接。在恢复正常连接后，我们可以看到Cell 121&-123的呼叫数量、呼叫建立成功率均恢复正常。实例：TCH拥塞由于突发话务量造成TCH拥塞，导致呼叫建立成功率下降。Figure 5-7 Call Success rates vs TCH Blocking for 642通过Figure 5-7我们注意到

52、，十月五日除了TCH话务量达到了18 Erl远高于日常的平均值12 Erl，造成TCH拥塞外。对于本小区的DRCU没有检测到任何硬件问题。我们怀疑是由于本小区的突发话务量，或相邻小区的问题导致的结果。对于TCH拥塞的小区，可通过关注统计项MA_CMD_TO_MS_BLKD，该统计反映了由于TCH拥塞而引起的分配拒绝数目。Figure 5-8 TCH assignment blocked一般来讲依靠新加站或基站扩容来进行缓解。同时，还可以根据周边基站得覆盖情况，打开MOTOROLA特殊类型的切换Congestion Relief /Direct Retry,临时缓解小区拥塞状况。鉴于当时全网TC

53、H拥塞引起的TCH呼叫成功率分布，重点地区的解决对全网指标的提高影响很大，如下表所示：Call_setup_success_rateTch_blocking_rateMa_cmd_to_ms_blkdTotal_calOMC184.24%24.48%11709193465OMC294.04%6.3%575218159OMC393.05%18%28378435Table 5-1 全网TCH拥塞引起呼叫成功率低的分布情况从上表，我们OMC1的TCH拥塞最大。TCH拥塞最严重的站，比如新发地，昌平，狼垡，铁家坟等都在OMC1上。所以，解决OMC1的TCH拥塞是增加呼叫成功率的最好方法。假设能够将OM

54、C1的MA_CMD_TO_MS_BLKD降到OMC2的程度则对全网影响为：538792*100/（603570-（11709-575）-89.27=1.7%即，可以使全网TCH呼叫成功率提高1.7%。实例：系统中的处理器负荷过重1999年我们发现网上一些IN_CELL基站的TCH呼叫建立成功率较低，由92.44%下降到了的88.07%，通过分析我们发现由于BTS中的BTP、DHP等GPROC板的（CPU）处理能力原因，造成在话务量很高的地区，GPROC板的CPU负荷过重。信令处理能力不够，导致呼叫建立成功率下降。下面以七月二日的数据为例，对相关统计项进行对比分析： （TOTAL CALLS）

55、= 538792；MO+MT = 403050+200520 = 603570（MA_REQ_FROM_MSC） (MA_CMD_TO_MS) (MA_CMD_TO_MS_BLKD)= 575891 545970 13209 = 16712简单计算七月二日的TCH呼叫成功率为：538792*100/603570 = 89.27%若将异常原因导致的失败从总呼叫次数中去除，TCH呼叫成功率为：538792*100/(603570-16712) = 91.81%MA_REQ_FROM_MSC表示MSC请求BSS为呼叫分配无线资源。MA_CMD_TO_MS表示向MS发送分配命令。在正常情况下，两者应该

56、基本相等，在存在拥塞情况下，MA_CMD_TO_MS加上MA_CMD_TO_MS_BLKD应该基本等于MA_REQ_FROM_MSC。然而，在异常的情况下，由于BSC中的LCF负荷太重或BTS内的DHP、BTP负荷太重，可能会造成两者差值较大。针对昌平IN_CELL基站的相关统计加以进一步分析：siteCellSetup_ratecm_serv_req_callpage_responsetotal_callsma_req_from_mscma_cmd_to_msChangPing4120-75535.2431341216153241022774Table 5-2 昌平基站的cell-2相关统计

57、BSC中的LCF控制情况，可以看出BSS10的GPROC 0213控制昌平基站：Table 5-3 BSS10的GPROC 0213控制的基站昌平基站内各GPROC BTP和DHP的控制情况：Table 5-4 昌平基站的各个GPROC控制载频CPU #Gproc_namecpu_usage_meancpu_usage_mincpu_usage_maxBSC10GPROC-021315.02724ChangPing_6GPROC-101476.265996ChangPing_6GPROC-0F1375.155794ChangPing_6GPROC-101671.705493ChangPing_

58、6GPROC-101370.974997ChangPing_6GPROC-0F1470.175388ChangPing_6GPROC-101558.323098ChangPing_6GPROC-0F1647.344166ChangPing_6GPROC-0F1511.46829Table 5-5 GPROC的相关统计由上表可以看到，BSC中的作LCF的GPROC负荷没有问题，但是，昌平站的BTP负荷最大值已达到98%；控制第二小区DRI的DHP中GPROC-1016和GPROC-1013平均负荷超过70%，最大负荷超过90%，由于处理器负荷过重，会导致资源不能正常释放、信令处理进程不能正常运行

59、，从而使呼叫建立成功率降低。针对这种情况，应增加DHP或使用高性能的处理器，如GPROC-2，来提高处理能力。另外，由于某个软件进程的运行出现问题，偶尔也会引起CPU的负荷过大，造成资源不能正常释放等问题，此种情况可通过RESET基站后，观察CPU负荷有无变化来验证。若负荷减小，则是由于软件异常引起，无需更换硬件。实例：MSC侧的问题CONN_REFUSED表示MSC拒绝建立连接。造成它的原因有很多，除呼叫连接建立请求拒绝外，还包括位置更新、呼叫重建拒绝、IMSI Detach等，每种原因都对应一个原因值，在MSC侧根据拒绝原因值来进行错误定位。现在，我们以1999年网络的一些数据为例进行分析

60、，考虑到位置更新和呼叫重建等与呼叫建立无关的信令过程也会引起CONN_REFUSED，根据全网统计分析，位置更新申请到SDCCH的数目与MO和MT之和大致相等，而呼叫重建在绝大部分小区中均被禁止，暂时忽略它的影响。另外，对于MOTOROLA的统计，在一些MSC下一次成功IMSI Detach对应的消息是CONN_REFUSED，而非CONN_CONFIRM消息。故此，在滤除以上因素后，我们可以大致估计，CONN_REFUSED总数量的一半是在MO和MT过程中产生的。由CTP呼叫跟踪的例子分析，我们可以看到，正常呼叫建立的信令流程中，在Call proceeding消息后，应该是BSSMAP: