109--CDMA网络无线侧接入失败原因分析及解决方案

CDMA网络无线侧接入失败原因分析及解决方案陈志强吕尧新(中国联通北京分公司技术网络维护部)摘要：接入失败是指呼叫建立过程中由于某种原因，TCH(业务信道)尚未建立成功，呼叫就异常结束。摩托罗拉在其CDMA系统中引入了CFC的概念，呼叫建立过程中在不同的阶段结束就对应不同的CFC。针对北京联通CDMA系统的几种主要的无线侧接入失败现象(CFC5、CFC16、CFC20)分析，并且给出了解决方案。本文以摩托罗拉CDMA20001X17版本电路域BS为例，对上述三种接入失败现象进行分析，并且结合实际案例，重点对由于设备隐性故障引起的CFC16进行了分析。关键词：CFC，接入失败，呼叫流程，隐性故障1CDMA系统的呼叫建立流程移动台起呼的接入流程可以大体分为5个不同的阶段：1.移动台在接入信道上发送起呼消息。基站收到起呼消息后，在寻呼信道上发送确认消息。2.基站为移动台分配业务信道在寻呼信道上发送信道指配消息，并在前向业务信道上发送空帧。3.移动台在收到信道指配消息后开始识别前向业务信道，即移动台在收到信道指配消息后0.2秒内必须识别前向业务信道。4.在前向业务信道成功解调后，移动台开始在反向业务信道上发空业务帧，然后基站在识别反向业务信道后必须在前向业务信道上发送确认消息。5.基站在前向业务信道上发送业务连接消息给移动台。手机在呼叫建立之前，要与系统进行一系列的信令交互。为了能清楚的说明可能出现的接入失败，我们首先结合信令流程图介绍一下CDMA网络主被叫的信令流程。在本文所涉及到的范围内，语音业务和数据业务并无不同，故以语音呼叫流程为例。1.1主叫信令流程语音呼叫的主叫信令流程如图1所示：a)手机通过反向接入信道发起请求，并要求基站的确认，等待基站发送BSAckOrder消息。b)基站发送BSAckOrder。c)基站将BTSCMServiceRequest消息打包在完全层3信息消息中并发送给交换机，启动定时器T303。d)交换机发送AssignmentRequest消息给基站，请求基站分配无线资源，并启动定时器T10。基站收到指配请求后停止定时器T303。e)基站查看当前的无线资源占用情况，如果有可用的无线资源，则发送CAM消息给手机。f)手机收到CAM后开始在指定的反向业务信道上发送Preamble。g)如果基站成功获取手机通过反向业务信道发送的Preamble，则在前向业务信道上发送BSAckOrder。h)手机在收到BSAckOrder后回送基站一个MSAckOrder，并开始在业务信道上发送空帧。i)基站发送ServiceConnectMsg用以和手机确认业务配置。j)手机发送ServiceConnectCompletionMsg给基站。k)基站发送AssignmentComplete给交换机，交换收到后停止定时器T10。l)主叫方手机接收回铃音。图1CDMA主叫流程1.2被叫信令流程语音呼叫的被叫信令流程如图2所示。a)交换机发送PagingRequest，寻呼被叫手机，并启动定时器T3113。b)基站通过寻呼信道将该寻呼消息发送下去。c)手机通过反向接入信道回应基站的PagingResponse消息。d)基站将来自手机的PagingResponse发送给交换机，并启动T303。e)基站给手机回应BSAckOrder消息。f)交换机向基站发送AssignmentRequest，后续一直到AssignmentComplete的过程与主叫业务相同。g)基站向手机发送Alertwithinfo，手机振铃。h)手机回应一个MSAckOrder，如果被叫选择接听电话，则发送Connectorder。i)基站作为回应给手机一个BSAckOrder，并给交换机一个Connect消息，进入通话状态。图2CDMA被叫流程2主要接入失败原因分析及解决方案2.1CFC202.1.1CFC20产生原因摩托罗拉CDMA系统中CFC20的含义是NoResourceAvailable[1]。对应主叫建立流程步骤e)，MM发现没有无线资源可用，终止了该呼叫。在这里无线侧资源指BTS的资源及XC的资源，在实际中，导致CFC20绝大部分都是BTS的Walshcoded)[2]资源不足及MCC的CE资源不足导致[2]。这与目前摩托罗拉CDMA系统资源分配机制有关。北京CDMA网络中，载波数量呈4-3-2-1梯形配置。MS在所有载波中通过HASH算法确定待机载那个载波上，某些特定情况下就会导致某个BTS下各载扇的用户数据不均衡，即某些载波出现很高，而其它载扇负荷较低，负荷高的载扇由于无线资源不足会出现拥塞。现网中，超过2个的载波分成两个carrierset(载波集)。283/201载波称作carrierset1，242/160载波称为carrierset2。摩托罗拉CDMA系统BTS的每个MCC(信道板)必须指定配置是为哪个carrierset服务。因此，有可能出现某个carrierset的MCC繁忙而另一个carrierset的MCC空闲，较为繁忙的carrierset有可能会出现拥塞。2.1.2CFC20解决措施为了解决上述由于MS分布不均而导致某些载扇出现拥塞，北京CDMA网络设置了溢出机制，即当某载扇由于Walshcode不足出现拥塞时，允许当前呼叫溢出到该扇区其它还可以接入的载波，同理当某个carrierset由于MCC资源不足时，允许当前呼叫溢出到其它可以尚有MCC资源可用的载波集。上述溢出机制为解决负荷不均导致的拥塞，如果整个BTS各载扇或各载波集负荷均很高时，可以考虑调整覆盖范围与周边基站的负荷均衡来解决。若无法实现，就意味着需要基站扩容了。一般来说，CEBlock可以通过扩容MCC解决，而出现WalshCodeBlock时，需要扩载波来解决。2.2CFC16及CFC52.2.1CFC16及CFC5的产生机制。CFC16与CFC5具有一定相似性，为了方便理解，将二者放在一起对比分析。从呼叫建立时间顺序来看，CFC16产生于呼叫流程的步骤e)g)之间。如图1所示，基站已完成无线资源的分配过程，却没能获取手机通过反向业务信道发送的Preamble，此时会导致接入失败。这个情况与CFC5比较接近，而且二者有可能会因为相同的现象导致产生：0x111B–基站没有检测到手机发送的TCHPreamble(NoTCHPreambleDetected)[3]。所以在优化过程中需要注意区分。我们再进一步深入研究这个问题时，就会发现二者的不同之处。为了方便阐述，首先看看呼叫建立过程中系统内部的信令流程，如图3所示。在北京联通实际的优化案例中，发现CFC16多数是由于设备的隐性故障造成，从而使得这类故障有很强的隐蔽性，我们会对CFC16的问题做重点分析。CBSC完成无线资源分配后，首先要建立XCDR到BTSMCC(TCH)的链路，如果这个过程失败，就不再进行后续流程。若MCC与XCDR之间的连接能够建立成功，则进行呼叫建立流程的后续步骤，BTS开始捕获MS通过反向业务信道发送的TCHPreamble。如果MCC与XCDR之间的链路建立失败，则BTS不会去捕获MS通过反向业务信道发送的TCHPreamble。关于前面讲到的同属于接入失败的CFC5和CFC16之间的区别之处，就在于图3中的椭圆所标处，BTS是否收到了CBSC发送的STRAU空帧。如果BTS没有收到空帧，那此时的接入失败现象就是CFC16；如果BTS收到了来自XC的空帧，但是没有收到MS通过反向业务信道发送的TCHPreamble，此时出现的接入失败表现为CFC5。CFC5的产生有可能MS由于某种原因没有向BTS发送TCHpreamble，也有可能MS发送TCHpreamble，但BTS没有收到。XCDR到BTSMCC(TCH)的链路建立过程中涉及到的网元较多，包括XC的CPP、XCDR(对于数据呼叫还有PSI-CE)，BTS的MCC，SPANDS0等等。在这个信令链条中的任何一个环节出现问题均会导致XCDR到MCC链路不能建立，产生CFC16。在我们处理过的实际案例中，上述所有网元都曾经因为故障导致CFC16现象的发生。2.2.2CFC5原因及解决措施实际网络产生产生CFC5产生的常见原因有两种：1.干扰，有可能是上行干扰也可能是下行干扰，上行干扰可以通过基站的反响噪声值判断出来；下行干扰大都需要现场测试才能判断。若是干扰导致CFC5高，则需要排除干扰源。2.基站的射频板卡(BBX)故障。射频板卡故障若通过重激活等相关操作不能恢复，则需要更换板卡。图3呼叫建立设备间的信令流程2.2.3产生CFC16的实际案例以及解决方案为方便案例分析，首先来看一下摩托罗拉CDMA20001X电路域BS17版本的与CFC16相关的功能模块，如图4所示。CDL(Calldetailedlog)中记录了呼叫过程中所对应的很多信息，包括呼叫时长、接入小区、占用的MCC板卡及PSI、CPP、XCDR等信息，这对于我们进行故障定位是非常有用的。在CFC16的问题解决过程中，我们充分利用了CDL所提供的信息，从而准确定位故障产生原因。以下我们会结合北京联通的CDMA网络中发现的CFC16的各种案例，逐一进行分析并给出解决方案。2.2.3.1XCDR产生CFC16案例：CBSC22的XCDR=0x2b02产生大量CFC16，重启操作后未恢复，更换板卡后恢复正常。分析：XCDR在CBSC中负责话音编解码以及帧选择与复制，整个CBSC内XCDR资源共享。当某CBSC内话音业务产生较多数量的CFC16时，极有可能是该CBSC内某XCDR板卡故障导致。我们首先过滤出现CFC16的用户话单，通过统计相关CDL中的XCDR、XCDR_CAGE_NUMBER、XCDR_SLOT_NUMBER等相关项，能够定位是哪块XCDR板卡有故障。解决方案：可以先将导致CFC16的XCDR做重启操作，观察是否恢复正常。若仍然未恢复正常，则需要更换该XCDR板卡。图4摩托罗拉CDMA20001X电路域BS结构2.2.3.2CPP产生CFC16案例：CBSC23的CPP5产生CFC16，重启操作后未恢复，更换GPROC板卡后恢复分析：CPP负责呼叫处理及XCCage的控制。当CPP工作异常时，可能导致CFC16，该CBSC内语音及数据业务均会受到影响。解决方案：首先可以过滤产生CFC16的用户话单，通过CDL中的CPP项的值确定是哪块CPP有问题，从而可以定位故障CPP。通过OMC查出产生CFC16的CPP对应的GPROC板卡，对GPROC板卡进行重启后观察话单是否恢复正常，若未恢复，则需更换GPROC板卡。2.2.3.3PSI-CE产生CFC16案例1：CBSC62逻辑地址为10.43.11.134的PSI-CE产生大量CFC16，经查询该PSI-CE的MSIport关闭，激活后恢复正常。案例2：CBSC24逻辑地址为10.1.25.154及10.1.25.134的PSI-CE产生大量CFC16，经查询两组PSI-CE板卡状态及其端口均正常，将两组PSI-CE板卡重启后，观察话单正常。分析：PSI-CE是专门为数据呼叫服务的板卡，主要完成电路域和分组域相关数据的转换。当某PSI-CE工作异常，产生CFC16时，该CBSC内的数据呼叫均受影响，用户通过手机上网时无法连接。解决方案：过滤CFC16的用户话单，查找出问题PSI-CE所对应的IP地址，然后根据IP地址查找出对应的PSI-CE板卡，检查板卡及相应端口状态是否正常。检查产生CFC16的PSI-CE板卡状态是否正常及其端口是否打开。若板卡状态为OOS则激活板卡；如相关端口没有正常打开，则需打开端口；若板卡及端口未发现异常，则尝试将PSI-CE板卡重启操作后观察话单是否正常。如果还有故障出现，则需更换相关的PSI-CE板卡。2.2.3.4BTSMCC原因产生CFC16案例1：芦城的MCCCE-453-1-13（MCC1的CE13）产生CFC16，将CE做重启操作无效，重新指派DS0与CE的对应关