语音呼叫失败原因分析

失败原因值

ERR_SPS_RLSA_RCM_DBAccFail_FCHResourceAllocate

失败原因详解

在MS起呼或者被呼时，在建立基本信道时调用数据库接口分配资源失败。会导致这个失败的原因如下：

1． 调用数据库的入参错误

2． CE资源不足或者异常

3． Walsh不足

4． FO不足

5． UID不足

解决措施

1．看信令跟踪里上报的BTSSeupAck消息中的失败小区的失败原因

0x5101 表示前向基本信道CE不足

0x5102 表示反向CE不足

0x5103 表示前向基本信道、反向CE均不足

0x5104 表示前向补充信道CE不足

0x5105 表示WalshCode不足

0x5106 表示UID不足

2．查明失败原因后，查看信道板是否异常（芯片状态是否正常，CE是否被闭塞）

3．如果CHM正常，CCM也正常，可能是资源吊死，严重故障

失败原因值

ERR_SPS_RLSA_RCM_PCALL_OtherReason_CEC_REMOVEREQ

失败原因详解

这个失败的原因是在呼叫过程中，信道板在检测到前向6s无帧后请求释放当前的呼叫。也就是说CHM在6s内没有收到SDU的前向帧（不论是什么速率的帧，都没有收到），都会引发释放流程。导致前向无帧的原因有：

1． IP或者MAC值无效

2． Key值无效导致查找表地址错误

3． 通道表无效位置1

4． SDM没有建腿

5． VTC单板上与本次呼叫相关的DSP故障

解决措施

1． 查看信令中有无SDM建腿消息

2． 查看IP和MAC值设置是否正确

3． 频繁出现此类失败，可能是DSP故障

失败原因值

ERR_SPS_RLSA_RCM_FCH_TimerExpired_TconnExpired

失败原因详解

在呼叫建立过程中，建立资源时Abis口定时器超时，引发了呼叫释放流程，导致呼叫失败。这个定时器Tconnb时长为4S，是BTS侧分配完无线资源以及业务地址，并通知BSC侧后触发的，如果在定时器到时前，没有收到BSC的Ack消息，则BTS侧发起释放流程。BTS侧没有收到Ack消息的原因除了链路和消息拥塞外，还可能是BTS侧的消息内容有误。

解决措施

1． 检查Abis链路是否通信正常

2． 检查BTS侧带给BSC的AbisdrConnect消息中参数是否正确（主要和AbisdfBTSSetup相比较），主要要注意的参数有：tAbisConnectInfo里有关小区的信息

失败原因值

DBS_STASTIC_NO_RESOURCE_LACK

失败原因详解

在资源分配的情况下，不是资源不足引起的资源分配失败。会导致这个失败的原因如下：

1． 操作数据库失败

2． 入参错误

解决措施

1． 看异常探针里上报的失败原因

2． 查明异常探针上报的失败原因，如果是入参失败，则检查入参；如果

是数据库异常，则检查数据库

失败原因值

DBS_STASTIC_FWDFCHCE_LACK

失败原因详解

在MS起呼或者被呼时，建立基本信道时由于前向CE不足引起的失败。会导致这个失败的原因是前向CE资源不足。

解决措施

1． 看异常探针里上报的失败原因

2． 查看RB_FWDCE表是否还有剩余的前向CE

3． 查看信道板是否闭塞了CE

失败原因值

DBS_STASTIC_REVFCHCE_LACK

失败原因详解

在MS起呼或者被呼时，建立基本信道时由于反向CE不足引起的失败。会导致这个失败的原因是反向CE资源不足。

解决措施

1． 看异常探针里上报的失败原因

2． 查看RB_REVCE表是否还有剩余的反向CE

3． 查看信道板是否闭塞了CE

失败原因值

DBS_STASTIC_FWDFCHCE_REVCE_LACK

失败原因详解

在MS起呼或者被呼时，建立基本信道时由于前向、反向CE不足引起的失败。会导致这个失败的原因是前反向CE资源不足。

解决措施

1． 看异常探针里上报的失败原因

2． 查看RB_FWDCE表是否还有剩余的前向CE，查看RB_REVCE表是否还有剩余的反向CE

3． 查看信道板是否闭塞了CE

失败原因值

DBS_STASTIC_FWDSCHCE_LACK

失败原因详解

在数据业务或者并发或者PTT业务建立时，建立补充信道时由于前向补充信道CE不足引起的失败。会导致这个失败的原因是前向补充信道CE资源不足。

解决措施

1． 看异常探针里上报的失败原因

2． 查看RB_FWDCE表没一块芯片上编号36-63的前向CE是否还有空闲资源

3． 查看信道板是否闭塞了CE

失败原因值

DBS_STASTIC_WALSHCODE_LACK

失败原因详解

在MS起呼或者被呼时，建立基本信道的时候WALSHCODE分配失败导致分配资源失败。导致这个失败的原因是：该载扇下没有可用的WALSHCODE

解决措施

1． 看异常探针里上报的失败原因

2． 用探针查看WALSHCODE是否还有空闲资源

失败原因值

DBS_STASTIC_UID_LACK

失败原因详解

在MS起呼或者被呼时，IP平台在建立基本信道的时候UID分配失败导致分配资源失败。导致这个失败的原因是：该载扇下没有可用的带宽

解决措施

1． 看异常探针里上报的失败原因

2． 用探针查看R_UID表是否还有剩余UID

失败原因值

HO_STAT_PILOT_NO_SAME_FREQ

失败原因详解

在切换判决中，导频下的所有载频都不满足条件，不能加入目标导频集合。

解决措施

失败原因值

HO_STAT_CARRIER_PWR_OVERLOAD

失败原因详解

在切换判决中，选定的载频功率过载。会导致这个失败的原因如下：

1．该载频用户过多

解决措施

1．降低每个载频的用户量

失败原因值

ERR_SPS_RLSA_DSPM_CLH_TimerExpired_Twaitorder

失败原因详解

在MS起呼或者被呼，进入业务信道，捕获前缀成功后，进行空口业务信道信令握手超时：

1． 无线环境恶劣导致丢失空口握手消息，少量出现属正常现象

2． 打开帧序号校验情况下，BTS和BSC时钟不一致

3． 其他原因：如传输误码等

解决措施

1． 查看小区发射功率是否正常

2． 查看CHM和SDU单版运行版本是否匹配，是否运行正常

3． 如果大量出现该呼叫失败，首先需要确定问题的范围：单站问题、一个ABPM下挂所有站点的问题、还是整个BSC的问题

4． 确定问题范围后，把出问题的BTS帧序号校验关闭，观察是否有所改善，如果问题有很大改善，说明：是由于BTS时钟和BSC时钟不一致导致的问题；查看GPS和时钟是否正常、BTS侧和BSC侧GCM单版是否正常运行。

5． 其他：需要检查ABPM、DTB，DSM等接口板版本是否正确，运行是否正常

失败原因值

ERR_SPS_RLSA_DSPM_CLH_OtherReason_SNFailure

失败原因详解

在MS起呼或者被呼，进入业务信道后，与MS的业务协商失败：

1． 由于无线环境恶劣导致在空口丢失业务协商消息，少量出现属正常现象

2． MS不支持BSS配置的声码器工作模式（业务选项）

解决措施

1． 查看小区前向功率是否正常

2． 如果出现某一类型手机总是协商失败，查看BSS配置的VTC工作模式是否正确（默认为8K+EVRC）；更换几种组合进行测试。

3． 如果仍不能解决问题，抓取呼叫失败信令反馈给研发人员

失败原因值

ERR_SPS_RLSA_DSPM_CLH_OtherReason_Tshakehandrecv

失败原因详解

通话状态下，DSPM与SDU和BSSAP握手的定时器Trecv超时，发起呼叫释放：

1． DSPM在5分钟内给SDM发送2次握手消息都收不到SDM的应答消息

2． DSPM在5分钟内给SDM发送2次握手消息都收不到BSSAP的应答消息

解决措施

1． DSMP单版上Trecv定时器设置是否正确（默认5分钟）

2． 查看出问题时对应的CMP，SDU运行是否正常，是否有异常复位或倒换。

失败原因值

ERR_SPS_RLSA_DSPM_HOH_OtherReason_AbisdShakeHandFailure

失败原因详解

通话状态下，DSPM与RCM握手失败，发起呼叫释放：

DSPM每2分钟给RCM发送一条握手消息，连续两次没有收到RCM握手应答

解决措施

1． DSMP单版上Tphysical定时器设置是否正确（默认2分钟）

2． 查看出问题时对应BTS的RCM，ABPM运行是否正常，是否有异常复位或倒换。

失败原因值

ERR_SPS_RLSA_DSPM_HOH_DBAccessFail_GetHandoffProc

失败原因详解

数据库软切换判决失败（该失败原因需要细化）：

数据库异常：数据库入参错误，配置错误等

解决措施

1． 检查数据配置，如邻区配置等

失败原因值

ERR_SPS_RLSA_DSPM_HOH_DBAccessFail_GetInterFreqSSHO

失败原因详解

数据库换频切换判决失败（该失败原因需要细化）：

数据库异常：数据库入参错误，配置错误等

解决措施

1． 检查数据配置，如邻区配置等

失败原因值

ERR_SPS_RLSA_DSPM_HOH_TimerExpired_Thoreq

失败原因详解

切换请求超时或切换请求被目标侧拒绝：（可结合切换时长区分，失败原因需要细化）

1. 切换请求超时（切换时长>=Thoreq） BSC发送切换请求到目标BTS\BSC，Thoreq（默认5s）超时中后没有收到目标侧切换应答

2. 切换请求被目标侧拒绝（切换时长 < Thoreq） BSC发送切换请求到目标BTS\BSC，目标BTS\BSC侧由于资源异常或流程异常而拒绝切换请求

解决措施

1.查看DSMP单版上Thoreq定时器设置是否正确（默认5s）

2． 查看Abis\A3A7接口链路是否正常

3． 查看切换的目标BTS单版运行是否正常，载频状态是否正常，信道板是否异常（芯片状态是否正常，CE是否被闭塞）

4． BSC间切换：查看两个BSC的A3A7接口板HGM运行是否正常，物理链路是否正常

失败原因值

ERR_SPS_RLSA_DSPM_HOH_TimerExpired_Thocompletion

失败原因详解

切换完成超时，基站发送切换指示（HDM），Thocompletion（默认5s）超时后没有收到MS切换完成消息（HCM）：

无线环境恶劣导致丢失空口消息

解决措施

1． DSMP单版上Thocompletion定时器设置是否正确（默认5s）

2． 查看切换目标小区发射功率是否正常

3． 查看切换目标BTS单版运行是否正常，该BTS下呼叫是否正常

失败原因值

ERR_SPS_RLSA_DSPM_CLH_TimerExpired_Tactivatesdm

失败原因详解

激活SDM超时：建立FCH后，DSPM激活SDM，在Tactivatesdm（6s）内没有收到任何应答消息。

解决措施

1．查看DSMP单版上Tactivatesdm定时器设置是否正确（默认6s）

2．查看对应SDU单版运行是否正常

3．出现问题时SDU是否有异常复位

失败原因值

ERR_SPS_RLSA_DSPM_CLH_OtherReason_ShakehandFail

失败原因详解

通话状态下，DSPM与SDU或BSSAP握手失败：

1． DSPM在5分钟内给SDM发送2次握手消息都收不到SDM的应答消息

2． DSPM在5分钟内给SDM发送2次握手消息都收不到BSSAP的应答消息

解决措施

1． DSMP单版上Trecv定时器设置是否正确（默认5分钟）

2． 查看出问题时对应的CMP，SDU运行是否正常，是否有异常复位或倒换。

失败原因值

ERR_SPS_RLSA_DSPM_CLH_TimerExpired_Ta8setup

失败原因详解

数据业务呼叫建立阶段，A8建链超时：DSPM发送A9SetupA8消息给PCF，在Ta8setup（3s）内收不到任何应答消息

解决措施

1． DSMP单版上Ta8setup定时器设置是否正确（默认3s）

2． 查看后台PCF IP地址配置是否正确，物理链路是否正常

3． 查看出问题时对应的PCF运行是否正常，是否有异常复位或倒换。

失败原因值

SDM_Activate_Fail_AcquirePreambleFail_Normal

失败原因详解

捕获手机失败，在定时器超时前没有收到手机发给BSC的Preamble。

该异常原因有很多种，系统中的每个问题都有可能引起捕获手机失败。例如给手机的参数与基站侧的不一致，长码错误、RC不一致、PN偏置错误等等。

解决措施

1． 看异常探针里上报的失败原因

2． 查看RB_FWDCE表是否还有剩余的前向CE

3． 查看信道板是否闭塞了CE

失败原因值

SDM_Activate_Fail_AcquirePreambleFail_NoRevFrm

失败原因详解

捕获手机失败，在定时器超时前没有收到BTS发给BSC的反向业务帧。

BSC连BTS侧发来的业务帧都收不到，原因也有很多种，可能性比较大的有：1．Abist媒体流链路不通

2．BTS或BSC侧任一方通道表加错等等。

解决措施

1． 检查Abis链路是否断链

2． 查看信令跟踪里添加通道表（BSC及BTS侧）是否成功

失败原因值

SDM_Find_Fail_WaitConfigVTCTimeout

失败原因详解

SDM激活成功后，在定时器超时前没有收到DSPM发给SDM的EV_S_AbafStartVocoderCoding消息。

该异常可能原因有以下两种：

1．层三与手机的业务协商失败，层三没有收到手机的证实消息。具体原因有很多：比如手机本身没有收到BS侧的证实消息，因此也不会回证实消息给BS。或者手机收到了BS侧的证实消息，但是由于某种原因没有给BS回证实。该异常也有可能是手机和BS侧参数不一致（例如RC不一致），导致手机解不出基站侧的证实消息等等。

2．层三处理异常，与手机协商成功后，仍未发送EV_S_AbafStartVocoderCoding消息给SDM。可从信令跟踪中进行判断。

解决措施

1． 检查是否有业务信道的握手消息EV_S_UmfBSOrder和EV_S_UmrMSOrder

2． 如果没有其中任何一条消息，可能是MS和BS侧参数不一致，检查MS以及BS侧的版本

3． 如果握手正常，查看信令中有没有EV_S_AbafStartVocoderCoding消息，如果没有，是DSPM没有发消息

失败原因值

SDM_Link_Fail_RevNoFrm

失败原因详解

链路失败。SDM在一段时间内收不到BTS发来的业务帧（默认时间为18s）。

该异常原因有很多种。比如Abist链路问题，CHM调度问题。需要视情况而定。

上报该异常时，呼叫会被释放。

解决措施

检查Abis链路是否断链

失败原因值

SDM_Find_Fail_SemiHandoffFail

失败原因详解

半软切换失败，SDM没有收到层三发来的去腿消息。

半软切换时，层三需要先发送加腿消息给SDM，切换完成后层三还需发送去腿消息给SDM，该异常原因就是层三在发送加腿消息给SDM后，SDM在定时器超时前没有收到半软切换的去腿消息。

上报该异常时，呼叫会被释放。

解决措施

如果不是断链，属于异常情况，请找研发人员进一步分析

失败原因值

SDM_Link_Fail_RevTooManyBadFrm

失败原因详解

链路失败，SDM在一段时间内从BTS侧收到的几乎都是坏帧（默认时间为18s）。

原因有很多种，有可能是正常原因，也有可能是异常原因，视具体情况而定。比如，反向空中链路真的非常差时，就会上报该异常，这种情况属正常释放。但是，该异常也不一定都是正常的，很有可能隐藏很多系统问题，比如呼叫过程中，由于某种原因手机自行释放自己，此时BS并未得到手机的释放消息，因此一段时间后就会上报该异常，这样就需要查为什么手机要自行释放自己。还有，手机和BS侧参数不一致，PN偏置错误等等都有可能引起该异常

解决措施

1． 查看MS和BS侧参数（PN偏置、版本）

2． 参数一致，是MS自行释放，属于正常范畴内失败

失败原因值

ERR_SPS_RLSA_BSSAP_FchSetup_RcvSccpDisconnect

失败原因详解

手机作起呼或者被呼时，向MSC发送CMServiceRequest或PagingResponse消息后，收到SccpDisconnect消息，SCCP连接建立失败或异常拆除。

会导致这个失败的原因如下：

1． 7号信令链路不稳定或链路状态不正确。

2． SSN状态不正确。

3． 手机在MSC侧没有正确放号。

4． 小区CI与MSC侧配置的CI不一致。

解决措施

1. 通过数据库探针查看CMP上的信令点状态是否为0。

2. 检查BSC和MSC侧是否都配置了本端和对端的SSN(0、1、254)。

3. 检查手机的IMSI和ESN在MSC侧放号是否正确。

4. 检查起呼消息CMServiceRequest中的小区CI在MSC侧是否已正确配置。

失败原因值

ERR_SPS_RLSA_BSSAP_TE_Tassignment

失败原因详解

手机作起呼或者被呼时，BSSAP向DSMP发送EV_S_AvfServiceAssignment指配请求消息后，长时间没有收到DSMP的指配完成消息EV_S_AvrAssignmentComplete或指配失败消息EV_S_AvrAssignmentFailure，导致BSSAP的定时器Tassignment超时。

会导致这个失败的原因如下：

1. 定时器Tassignment时间太短。

2. DSMP的实例数配置太大，大于实际支持的DSMP实例数。

3. DSMP的CPU占用率太高。

4. 激活SDM时超时。

解决措施

1. 检查CMP上的定时器Tassignment是否设置正确，缺省值为6000 (6秒)。

2. 检查RMP与DSMP的关联中DSMP的实例数是否超过允许的范围(不同的DSMP版本支持的实例数不一样)。

3. 确认DSMP的CPU占用率是否太高，若太高则需要扩充DSMP的模块数。

4. 若是激活SDM超时，则可能SDU与CHM间的媒体流不同，或者BSC与BTS间的时钟不一致，需要检查媒体面的光纤是否连接正确、检查是否存在个别SDU子卡有故障。

失败原因值

ERR_SPS_RLSA_BSSAP_TE_T303

失败原因详解

手机作起呼或者被呼时，向MSC发送CMServiceRequest或PagingResponse消息后，长时间没有收到MSC的AssignmentRequest消息，导致CMP上的T303定时器超时。

会导致这个失败的原因如下：

1. T303定时器设置时长太短。

2. MSC侧对呼叫处理有问题。

解决措施

１．检查CMP上的定时器T303设置是否正确，缺省值为6000 (6秒)。

２．从MSC侧查找MSC呼叫失败的原因，出现T303一般都是MSC侧对该呼叫处理出现问题，问题原因需要通过MSC的工具进行分析。

失败原因值

ERR_SPS_RLSA_BSSAP_DB_GetCallBlockingStatus

失败原因详解

95手机作起呼或者被呼时或者硬切换时，BSSAP调用数据库接口GetCallBlockingStatus分配无线资源，数据接口返回失败导致呼叫失败。

会导致这个失败的原因如下：

1. 载频资源状态不正确（载频过载、载频被闭塞）。

2. CE资源不足或状态不正确，没有空闲的CE资源。

3. 帧偏置不足。

4. 输入参数不正确。

解决措施

看业务观察中的详细数据中的字段dwInnerCause的值，可以判断数据库接口失败的原因：

1. 0x4414：小区配置的CE模式(大模式、正常模式)不正确。

2. 0x4409：参考小区的导频强度太低。

3. 0x44af：95手机不支持大模式配置，保存信令并发回给开发人员分析。

4. 0x4435：通过小区CI获取BTS的系统号失败，说明BTS上保存的CI与BSC保存的CI数据不一致，需要重新同步数据。

5. 0x449a：帧偏置不足。

6. 0x449b：帧偏置不足。

7. 　0x4438：载频状态不正确，通过动态管理工具查看载频是否闭塞，查看控制信道是否配置，查看BTS是否过载或有低功率告警，以及查看CE资源是否足够、CE状态是否正常。

8. 　0x4448：载频选择失败，检查载频状态是否正确，通过动态管理工具查看载频是否闭塞，查看控制信道是否配置，查看BTS是否过载或有低功率告警，以及查看CE资源是否足够、CE状态是否正常。

0x4a02 /*选定的载频功率过载*/

0x4a03 /*选定的载频状态不对*/

0x4a04 /*选定的载频为伪导频*/

0x4a05 /*选定的载频没有CE资源*/

0x4a06 /*选定的载频没有5KCE资源*/

0x4a07 /*选定的载频FO不匹配*/

0x4a08 /*导频没有匹配的载频*/

0x4a09 /*导频所有的载频都不可用*/

0x4a0a /*导频所有的载频都没有FO*/

0x4a0b /*不是本BSC的导频*/

0x4a0c /*导频归属不清，没有配置成邻接小区*/

0x4a0d /*BSC没有互联*/

0x4a0e /*目标BSC不支持PTT*/

0x4a0f /*数据业务以及并发布支持IP到HIRS的BSC间软切换*/

0x4a10 /*互联状态不对*/

失败原因值

ERR_SPS_RLSA_BSSAP_DB_GetDSPM_SE_VEbyCIC

失败原因详解

手机作起呼或者被呼时，根据MSC分配的CIC分配BSC侧的动态资源DSPM、选择器SDU、声码器VTC和BSC侧CIC资源时失败，导致呼叫失败。

导致这个失败的原因如下：

1. MSC与BSC两边的配置的CIC时隙没有一一对应，MSC侧配置的CIC在BSC侧没有配置，查看信令跟踪中MSC下发的指配消息 A1fAssignmentRequest中字段wCircuitIdentityCode的值，此值为MSC分配的CIC，把此值转换为2进制数，取高 11 bit得到PCM号，取低5 bit得到时隙号，确认MSC与BSC两边配置的PCM号和时隙号是否一致。

2. 查看BSC侧对应的CIC是否被闭塞。

3. 通过数据库探针查看MSC分配的CIC是否处于忙状态，若处于忙状态则可能BSC侧打开了优选CIC功能，导致BSC与MSC分配的CIC有冲突，没有IWF业务时需要关闭优选CIC开关。

4. DSMP状态不正确，导致无法分配DSPM资源，或者DSMP实例数配置不够，需要扩大DSMP的配置实例数或增加DSMP单板。

5. SDU状态不正确，确认SDU单板是否故障或被闭塞，或者SDU资源不足

6. VTC状态不正确，确认VTC单板是否故障或VTC资源被闭塞，或者VTC资源不足。

解决措施

失败原因值

ERR_SPS_RLSA_BSSAP_DB_GetHandoffProc

失败原因详解

1X手机作起呼或者被呼时或者硬切换时，BSSAP调用数据库接口GetHandoffProc分配无线资源，数据接口返回失败导致呼叫失败。

会导致这个失败的原因如下：

1. 载频资源状态不正确（载频过载、载频被闭塞）。

2. CE资源不足或状态不正确，没有空闲的CE资源。

3. 帧偏置不足。

4. 输入参数不正确。

解决措施

看业务观察中的详细数据中的字段dwInnerCause的值，可以判断数据库接口失败的原因：

1. 0x4414：小区配置的CE模式(大模式、正常模式)不正确。

2. 0x4409：参考小区的导频强度太低。

3. 0x44af：95手机不支持大模式配置，保存信令并发回给开发人员分析。

4. 0x4435：通过小区CI获取BTS的系统号失败，说明BTS上保存的CI与BSC保存的CI数据不一致，需要重新同步数据。

5. 0x449a：帧偏置不足。

6. 0x449b：帧偏置不足。

7. 0x4438：载频状态不正确，通过动态管理工具查看载频是否闭塞，查看控制信道是否配置，查看BTS是否过载或有低功率告警，以及查看CE资源是否足够、CE状态是否正常。

8. 0x4448：载频选择失败，检查载频状态是否正确，通过动态管理工具查看载频是否闭塞，查看控制信道是否配置，查看BTS是否过载或有低功率告警，以及查看CE资源是否足够、CE状态是否正常。

0x4a02 /*选定的载频功率过载*/

0x4a03 /*选定的载频状态不对*/

0x4a04 /*选定的载频为伪导频*/

0x4a05 /*选定的载频没有CE资源*/

0x4a06 /*选定的载频没有5KCE资源*/

0x4a07 /*选定的载频FO不匹配*/

0x4a08 /*导频没有匹配的载频*/

0x4a09 /*导频所有的载频都不可用*/

0x4a0a /*导频所有的载频都没有FO*/

0x4a0b /*不是本BSC的导频*/

0x4a0c /*导频归属不清，没有配置成邻接小区*/

0x4a0d /*BSC没有互联*/

0x4a0e /*目标BSC不支持PTT*/

0x4a0f /*数据业务以及并发布支持IP到HIRS的BSC间软切换*/

0x4a10 /*互联状态不对*/

失败原因值

ERR_SPS_RLSA_BSSAP_FchSetup_SendChannelAssignment_AllBtsFail

失败原因详解

呼叫建立时，BTS上的无线资源已经分配且基本信道已经建立成功，BSSAP也已经收到MSC的指配请求消息，并且成功分配了BSC侧的资源，开始向手机所在的所有BTS发送信道指配消息ECAM或CAM，但是向所有BTS都发送失败。

导致这个失败的原因如下：

1. 获取Abis口接口板的逻辑地址以及BTS的IP地址失败，原因是Abis口的UID状态不正常，Abis链路不稳定。

解决措施

这个故障一般是Abis口链路不稳定所致，通过数据库探针查看CMP上BTS对应的UID的状态是否为0，不为0表示UID状态不正常，需要检查Abis口链路和传输。

失败原因值

ERR_SPS_RLSA_BSSAP_TE_Tfchsetup

失败原因详解

呼叫建立时，BSC向BTS发送了AbisdfBTSSetup消息请求建立基本信道，但是长时间没有收到BTS建立基本信道成功或失败的响应消息AbisdrBTSSetupAck，导致CMP上的定时器Tfchsetup超时。

会导致这个失败的原因如下：

1. 定时器Tfchsetup设置的时长太短，缺省应该是5000 (5秒)。

2. BTS上建立基本信道失败。

3. CCM的CPU占用率太高。

解决措施

1. 检查预定义定时器Tfchsetup的时长是否正确，若设置时长太短则需要修改为缺省值5000。

2. 检查BTS上是否有足够的CE、FO资源。

3. 检查CCM的CPU占用率是否过高，若过高则需要调整CCM的CPU过载控制门限，或通过降低天线发射功率来减少接入用户。

失败原因值

ERR_SPS_RLSA_BSSAP_FchSetup_AllLegFail

失败原因详解

呼叫建立时，BSC向BTS发送了AbisdfBTSSetup消息，请求BTS建立基本信道，但BTS返回的AbisdrBTSSetupAck中的所有小区都是建立失败的，失败的主要原因有：

1. CE资源不足，CE资源状态不正确。

2. WASH码不足。

3. 帧偏置FO不足。

4. UID的状态不正确或媒体面链路不正确。

5. 载频状态不正确。

解决措施

1. 从AbisdrBTSSetupAck消息中的失败原因中可以得知失败的具体原因：

0x5101 表示前向基本信道CE不足

0x5102 表示基本信道反向CE不足

0x5103 表示基本信道前向、反向CE均不足

0x5105 表示WalshCode不足

0x5106 表示UID不正确

2. 确认CE状态是否正常，是否被闭塞。

3. 确认载频状态是否正常，是否被闭塞。

4. 通过数据库探针查看UID状态或者媒体面链路是否正常。

5. 检查CHM上配置的CE组号是否正确。

失败原因值

ERR_SPS_RLSA_BSSAP_TE_T3230

失败原因详解

呼叫建立时，BSSAP向MSC发送CMServiceRequest或PagingResponse消息后，没有收到对端的SccpConnect连接证实消息，导致T3230超时。

解决措施

1. 检查7号信令链路是否正常，可能是链路不稳定。

2. 当前业务量太大，超过当前信令链路所能承载的业务量，需要增加信令链路。

失败原因值

ERR_SPS_RLSA_BSSAP_TE_Tchdbaccess

失败原因详解

呼叫建立时，CMP向RMP发送资源分配消息后，等待资源分配应答超时，其中可能原因是CMP与RMP间的通信断或者RMP、CMP的CPU占用率太高。

解决措施

1. telnet到RMP上，通过命令OSS_GetCpuUseRate查看RMP的CPU占用率，若CMP的占用率太高，需要降低CPU的过载门限以通过过载控制来降低呼叫量。

2. 若CPU占用率不高时出现此呼叫失败，通过数据库探针查看OMP上R_MODULE表，确认RMP和CMP的模块状态是否正常，状态值的bit0表示右板状态，bit1表示左板状态，相应状态bit位为0时表示状态正常。若状态不正常则为严重故障，需要联系开发人员定位问题。

3. 通过OSS_DbgShowComm查看CMP与RMP之间的通信链路是否正常（3为正常），若不正常则为严重故障，需要联系开发人员定位问题。