朗讯CDMARF优化经验总结

朗讯CDMA_RF优化经验总结简介：5如何应用本文51路测分析及优化51.1掉话分析51.1.1掉话定义及分类51.1.2掉话分析过程61.1.2.1无线参数设置不当81.1.2.2高话务负荷区域81.1.2.3弱覆盖91.1.2.4前向或者反向干扰91.1.2.5基站资源不足91.1.2.6直放站101.1.2.7基站的硬件故障101.1.3路测掉话分析举例101.2呼叫失败分析211.2.1语音主叫过程211.2.1.1主叫流程和相关信令221.2.1.2语音主叫失败分析要点及一般过程241.2.2数据业务主叫流程281.2.2.1主叫流程281.2.2.2数据业务主叫失败分析要点和一般过程291.2.3短消息业务处理流程311.2.3.1短短消息业务主叫311.2.3.2短短消息主叫失败分析341.2.3.3长短消息主叫分析351.2.4寻呼过程及常见问题处理361.2.4.1语音寻呼过程信令分析361.2.4.2语音被叫寻呼阶段失败分析361.2.5小结381.2.6相关Log文件实例：381.3切换失败分析381.3.1切换类型及相关流程分析381.3.1.1Common Soft handoff的一般流程391.3.1.2Interfrequency handoff 的流程451.3.1.3Intervendor hard handoff的流程541.3.2切换失败分析要点661.3.2.1软切换失败的分析：661.3.2.2半软切换失败的分析：671.3.2.3InterVendor hard handoff 失败的分析：691.3.2.4其它切换失败分析案例举例：711.4综合分析731.4.1覆盖弱（盲）区的分析731.4.2直放站引起的问题分析741.4.3导频污染分析及解决751.4.4呼叫建立时长分析751.4.5外部干扰分析751.4.6上下行功率分析751.4.7FFER分析791.4.8路测中的数据速率优化821.4.8.1前向速率优化831.4.8.2反向速率分配信令流程862关键指标性能分析892.1呼叫建立成功率分析892.1.1简介892.1.2呼叫建立成功率公式892.1.3呼叫建立流程912.1.3.13G1X语音呼叫建立流程912.1.3.23G1X数据呼叫建立流程922.1.4影响呼叫建立成功率的主要因素及其解决方案922.1.4.1RF Access Failure(TCCF)的呼叫建立失败分析932.1.4.2系统硬件资源（CE/PP）或功率资源限制导致的呼叫建立失败分析952.1.4.3BAD ESN 导致的呼叫建立失败982.1.4.4Call Setup Failure 的呼叫建立失败分析992.1.4.5与Call Delivery Type 相关的被叫失败分析1002.1.4.6由于登记和寻呼策略导致的被叫失败1002.1.4.7Assignment rate 降低的分析1002.1.5相关案例1012.2寻呼成功率分析1012.3掉话率分析1012.3.1掉话率公式：1012.3.2掉话率公式分析1022.3.3掉话率改善指标思路1022.3.3.1问题定位1022.3.3.2原因分析与针对性措施1032.3.4小结1062.4阻塞分析1062.4.1CE/PP 资源阻塞分析1062.4.1.1CE/PP阻塞定义1062.4.1.2相关Peg counts1072.4.1.3CE/PP资源阻塞原因及解决建议1072.4.2前向功率资源阻塞分析1082.4.2.1前向功率资源阻塞定义1082.4.2.2参考Peg counts1082.4.2.3向功率资源阻塞原因及解决建议1082.4.3反向RF 负载资源阻塞分析1102.4.3.1反向RF 负载资源阻塞的定义1102.4.3.2参考Peg counts1112.4.3.3反向RF 负载资源阻塞原因及解决方案1112.4.43G to 2G Assignment1132.4.4.1相关 Peg counts1132.4.5Walsh code资源不足1142.4.5.1相关peg counts1142.4.6其它系统原因1153Feature、参数及其他优化专题1153.1多载频话务分配1153.2切换相关参数优化1153.3厂商间硬切换1163.4高层，室内问题解决1163.5VVSD1163.6数据优化1173.7天线选择1173.8开销信道及负荷分析1183.9快速寻呼信道1183.10超远距离覆盖1183.11SHAPCAR功能1183.12COW的RF相关优化1183.13邻区优化1183.14IS-page21193.15TMA&TMB1193.16Misc1194常用RF优化工具应用介绍1204.1FCI Alert,HOMAX,UNL及邻区优化方法介绍1204.2RFCenter1204.3Transcend1204.4Deploy scripts1204.5PCMD Tool1204.63G_1x优化工具设置1214.7Google Earth工具1214.8ROP文件的分析：1215RF经典文档1215.1RF相关参数1215.2RF opt& trouble shooting Guidelines1215.3RF 工具：1225.4Ldat各种Metrics的定义1225.5Lucent技术文档查询：（APX_Lib）1226附件和目录结构122简介：本文主要意图是对CDMA_RF优化工作的一些方法，思路,工具等进行一次较为全面的总结。全文共分为四个章节：路测分析及优化，关键性能指标分析及优化，主要feature，及专题优化，主要工具介绍。每个章节则包括基本的流程，流程分析，常见问题以及相应的解决方案等内容。希望通过本文的应用，使得各地现有的一些经验，方法得以共享。同时将RF工作的一些方法和流程进行标准化，从而使新进员工的工作更容易上手。以及朗讯员工在指导SubC工作时，或了解现场情况时更具系统性，并进一步提高工作效率。如何应用本文新进RF人员可通过通读本文对CDMA常用流程和分析方法和优化思路有一较系统全面的理解。并在实际工作中，尝试这些方法的应用。所有RF人员，在指导Subc或客户工作，或进行问题分析时，可参照本文提供的一些思路和方法，对常见的问题加以迅速定位或归类，以提高问题定位和解决的效率。1 路测分析及优化1.1 掉话分析1.1.1 掉话定义及分类在CDMA网络用户通话过程中，由于各种原因发生通话无法正常继续而被迫中断则称为掉话现象。在覆盖边缘区域前向覆盖功率与Ec/Io都较差，手机与基站无法建立正常通信，通信被迫中断，这种掉话属于正常掉话；而发生在设计覆盖区域内，前向覆盖都比较好，反向手机功率可以被基站良好接收，在这种无线环境中发生的掉话，属于异常掉话。路测掉话率定义：在90%射频覆盖区域内，沿路测路线发起一全速率马尔可夫呼叫(如果呼叫失败，会自动发起一个新的呼叫)，则- 掉话率=成功建立呼叫后的掉话总次数/成功建立呼叫的总次数*100%- 路测所记录的总呼叫持续时间除以90秒，等于成功建立呼叫次数的总数。从空中接口来定义通话正常结束（以下摘自IS2000规范），则不管是手机还是系统发起释放通话，都需要前向，反向双方的RELEASE消息。如果缺少某一个RELEASE消息，则在路测软件分析时会认为是一次掉话现象。可能引起掉话的大致分类为：1) 无线参数设置不当：切换参数设置 、邻区列表设置、导频PN复用、邻居搜索窗设置不合理；2) 高话务负荷区域 ：周围扇区服务用户数较多，话务量较大；3) 弱覆盖：接收功率或Ec/Io（导频污染）较差； 4) 前向或者反向干扰 ：干扰的存在，影响系统的正常工作；5) 基站资源不足：前向功率、CE资源、walsh资源、传输资源 不足；6) 直放站：通常为直放站或室内分布系统或者干线放大器的参数未能正确设置。这种情况通常发生在直放站覆盖区域内，此时前向FER较高。7) 基站的硬件故障8) GPS故障引起时间与其他基站时间不同步，造成切换失败；9) 基站放大器、滤波器发生故障，无功率输出；10) MSC和基站之间的传输闪断11) 其他硬件故障 1.1.2 掉话分析过程我们首先对层三信令进行一个简单的解读：从路测文件信令分析图中可以看到正常的呼叫结束是由手机（MS）先给基站发RELEASE消息（在下图中的第一个ORDER MESSAGE），之后基站再回手机一个RELEASE消息（在下图中的第二个ORDER MESSAGE）。之后有一个同步消息。12/27/2006 06:44:03:357Order MessageBSMSFWD_TRAFF12/27/2006 06:44:05.877Sync Channel MessageBSMSSYNC下面是详细信令，可以看到左侧文本框中是手机向基站发的RELEASE ORDER，该消息的序列号（MSG_SEQ）是3。之后基站向手机回的RELEASE ORDER在右侧文本框中，可见该消息回的是手机MSG_SEQ为3的消息（因为ACK_SEQ=3）。MS-BS Release OrderBS-MS ACK Release OrderRecNo : 4996 : 12/27/2006 06:44:03.357 REV_TRAFF : Order Message (ORDM) Record_Header RECORD_LENGTH 19 byte LOG_CODE 0x1005 MESSAGE_TIMESTAMP 06:44:03.357 EXPECTED_MESSAGE_LENGTH 7 byte Message IS Signalling Reverse Channel Traffic Message MSG_LENGTH 7 byte MSG_TYPE 1 SDU_AND_PDU_PADDING_LENGTH 24 bits Order Message FDSCH_LAYER2_BEG_FIELDS FDSCH_LAYER2_ARQ_FIELDS_REG_PDU ACK_SEQ 3 MSG_SEQ 3 ACK_REQ 1 ENCRYPTION 0 ORDER Release Order (Normal release for implicit field ORDQ = 0) ADD_RECORD_LEN 0 RESERVED 0 IS2000_L2_PDU_PADDING CRC 38612 RecNo : 5004 : 12/27/2006 06:44:03.552 FWD_TRAFF : Order Message (ORDRM) Record_Header RECORD_LENGTH 20 byte LOG_CODE 0x1008 MESSAGE_TIMESTAMP 06:44:03.552 EXPECTED_MESSAGE_LENGTH 8 byte Message IS Signalling Forward Channel Traffic Message MSG_LENGTH 8 byte MSG_TYPE 1 SDU_AND_PDU_PADDING_LENGTH 32 bits Order Message FDSCH_LAYER2_BEG_FIELDS FDSCH_LAYER2_ARQ_FIELDS_REG_PDU ACK_SEQ 3 MSG_SEQ 5 ACK_REQ 0 ENCRYPTION 0 USE_TIME 0 ACTION_TIME 0 second ORDER Release Order ADD_RECORD_LEN 0 RESERVED 0 IS2000_L2_PDU_PADDING CRC 7171 了解了通话正常结束信令之后，可以理解当没有出现Release Order而发生掉话时，需要从掉话时的sync消息往前分析，找出该次掉话的真正原因。根据1.1.1中的分类，我们分别对各种可能引起掉话的原因进行简单的定位分析：1.1.2.1 无线参数设置不当第一种情况是邻小区缺失：邻小区缺失时会导致强候选导频无法加入到有效导频集。相反地，候选导频对该通话而言是一个纯干扰存在。当干扰越来越强时，手机就会发生掉话，产生一个Lost call。分析方法：使用LDAT在掉话点之前检查是否有NLA告警，例：77 53g(450) -9 NLA A54g(372)-8.5 A41a(90)-12.0 23:42:45.552此时根据情况，应该把53g加入到54g或41a的邻小区集合中。如果需要用层三信令自己进行分析，则可以对PSMM（导频测量报告）消息及NLM（邻小区消息）进行分析，得到和LDAT相同的结论。解决思路：增加/删除邻区及重新设定邻区优先级：参考FCIAlert输出的单向，One-Way，Two-Way告警及HOMAX统计的邻小区切换比例，同时也需要注意是否有可能同PN复用过近，或出现PN混淆。第二种情况是搜索窗设置不当： 当搜索窗设得不够大时，在搜索窗范围外到达的导频将不能被手机检索并在PSMM消息汇报给系统，这样它们将也不能顺利进入有效集，从而或早或晚成为一个强干扰存在，然后导致掉话。 分析方法：使用LDAT在掉话点之前分析是否有搜索窗告警，例：Warning D=45.75 chips (144), use srch_win_a10 A113b(144) A53b(282) 19:28:17.435 Warning D=39.6 chips 113b(144), use srch_win_n9 A113b(144) A53b(282) 19:28:41.040以上两条搜索窗告警分别是对有效集及邻小区集的告警。解决思路：根据搜索窗告警及时延Chips，然后对照搜索窗表确定有效集或邻小区集搜索窗的实际需要大小。1.1.2.2 高话务负荷区域高话务能增加Lost Call的概率。这是因为在一个区域有多个高话务基站会急剧增加该区域的系统内干扰水平，使得个别手机建立的业务信道克服干扰比较困难。（一个扇区高话务不一定会导致高掉话率，当一圈基站话务量较高时会出现干扰水平急剧增加。）分析方法：需要用话务统计工具如SPAT，SMART进行周围基站忙时的话务分析，从而考虑高话务负荷的程度。解决思路：增加载频；增加新站来进行话务吸收；适当减少软切换比例；扇区间调整覆盖平衡话务分担等；1.1.2.3 弱覆盖在CDMA中，弱覆盖可能是接收功率差或Ec/Io差。因此弱覆盖区域可能是由于室内深度穿透不足，建筑物或地形（山，树木）阴影阻挡或基站位置，站高的不合理设计造成，也有可能是由于导频污染原因。 分析方法：根据路测数据进行手机接收功率，手机发射功率，主导频Ec/Io，前向FFER几幅相关路测图的结合分析确定是否存在弱覆盖区域。解决思路：主要通过对天线参数：方位角及倾角进行调整解决；其次也可以对扇区发射功率及衰减值进行调整；在没有其他手段情况下，只能通过加站解决覆盖问题。1.1.2.4 前向或者反向干扰前向或反向干扰都有可能导致异常掉话。通常来说， CDMA系统更容易受到反向干扰，且干扰有可能仅影响某个载频。在基站受到干扰时，在前向或反向需要更多的业务信道功率以维持通话。当没有足够的功率克服干扰时，通话有可能被迫中断。分析方法：可以在基站J5口接泰克等设备直接查看该扇区是否在上行下行频段受到干扰，对突发或稳定的干扰信号进行中心频点，干扰强度的确定；也可以通过扫频仪进行频谱扫描， 在路面上确定干扰影响的范围；在定向天线的辅助下，也可以对干扰源具体的位置进行查找并最终定位发现干扰设备。在OMP侧，也可以通过DUMP命令及话务统计中PEAK RSSI，AVERAGE RSSI计数器值来综合判断是否存在外部干扰。解决思路：根据分析从多种数据确定是否存在外部干扰，然后检查是否可以对IROC参数进行修改，但最终解决办法只能是查到干扰源并通过无委会协调将干扰设备最终关闭。1.1.2.5 基站资源不足当切换被正常触发而目标基站因为资源短缺而阻塞切换时，如果原先导频仍能维持通话时，不会引起掉话。但持续不能切换，当未能进入的新导频产生的干扰过大时，就有可能会导致掉话了。分析方法：从层三中分析，当看到PSMM消息满足切换的条件而没有Handoff Direction Message时，可能需要怀疑是资源原因被阻塞了切换指示。此时需要到SPAT话务统计去确认是CE，PP，RF POWER还是WALSH CODE导致切换的阻塞。解决思路：根据阻塞的瓶颈资源，解决资源问题。主要资源可能是CE，PP，RF POWER。另外也可以适当地减少软切换比例。1.1.2.6 直放站对于直放站如果搜索窗等时延参数未正确设置及直放站的前反向增益设置不当给主站带来底噪的抬升，也会使得出现异常掉话。分析过程：在直放站覆盖区域进行路测，分析手机接收功率及发射功率，同时分析接入探针的次数。如果MRX+MTX在-80-85dbm左右，且探针次数只有1次，则认为直放站工作的较好。另外也可以在MSC用DUMP命令或RSSI统计来确认直放站是否对主站带来了额外的底噪抬高。解决思路：检查直放站所接施主扇区的参数设置：根据直放站光纤长度进行各个相关参数的计算且直放站主站扇区的选择要有所选择；对直放站前反向增益进行调整：保证直放站的覆盖同时对主站影响尽量少；另外对于直放站连接扇区搜索窗不是越大越好；搜索窗需要考虑直放站周围扇区并对它们也进行适当设置。1.1.2.7 基站的硬件故障当基站出现各种各样故障时，也会发生异常掉话。分析方法：在路测时，如果发现信号忽弱忽强或经常脱网进网，可以怀疑CBR或功放等问题；如果在站下起呼没问题，而切入切出都不能进行，则可以判断出现孤岛现象，可以怀疑关于时钟单元的基站硬件如TFU，晶振等器件有否问题。另外也可以参考OMP上网管系统及ROP中的硬件HEH告警，来查找是否该站出现硬件故障。解决思路：尝试RMV，RST故障硬件，或进行更换然后观察指标或进行现场测试看问题是否得以解决。1.1.3 路测掉话分析举例在路测过程中可能会直接遇到掉话的现象。一个电话之所以会被路测工具或后台分析工具判成掉话，主要是因为手机完成起呼后（即发送Service Connection Completion Message）到下一次同步之前（即收到Sync Channel Message），未接收到正常释放过程完整的信令消息。如下图所示，我们先来看一个正常起呼和释放的过程（raw data 中有正常起呼，被叫，释放的数据文件可供分析）： 正常起呼：正常释放：手机发送Release Order基站回应的Release Order该正常释放过程为手机侧发起的释放，如果由基站侧发起的释放，则这两条消息的顺序相反。如果这两条都有，则路侧分析软件通常会认为这是一次正常的释放过程。相反，如果手机没有记录Release Order消息而直接收到同步消息，则算作一次异常释放，即掉话，如下图所示：通常这是因为前向或反向链路质量变差，手机或基站无法解调信号，超时后释放无线链路。我们一般会在Sync消息之前的Searcher and Finger Information手机LOG中发现手机已经无法正确解调导频信道。如下图所示： 所以，从路测角度来说，无论什么原因造成的掉话，从空中接口的层三信令来看基本上是一样的。这里的链路质量变差主要指前向基站功率或者反向手机功率已经无法增大以克服外部的干扰，从而无法满足解调信道要求的Eb/No值。 前反向链路质量变差的原因主要包括以下几个方面：1) 服务扇区和手机的功率损耗超过链路预算 这种情况常常发生在郊区，特别是山区。由于地形等因素的阻挡造成前向、反向或两者链路的路径损耗急剧增加，链路质量急剧恶化。路测时可以发现手机的接收功率和服务导频的Ec/Io都变得很差，手机的发射功率达到了最大值，如下图所示：2) 软切换失败 这种情况通常包括包括两个方面：邻小区遗漏造成的无法正常切换；硬件故障导致的无法正常切换。前者在基站邻小区关系优化未完成时有可能会测到，特别是在网络建设初期和后期增加新站时。网络发展成熟后经过多次优化这样的现象比较少见。典型的例子如下图所示，由于邻小区关系的遗漏，PN68的导频不在PN432和PN264扇区下发的邻小区关系表中，因此不能做软切换，即对这两个导频来说是强干扰，随着信道质量Eb/No不断变差，最终导致掉话。后者主要指基站硬件故障造成的相邻扇区无法作软切换，其现象和上述情况类似，由于无法软切换，非服务扇区的强信号对服务扇区的信号造成干扰，最终掉话。常见的原因有TFU问题导致时钟不同步、基站资源拥塞、ATM信令拥塞等，一般可查找ROP文件确认硬件故障的存在。3) 多个基站干扰造成的导频污染 这种情况归根结底就是该区域没有主导频，每个基站扇区到达该区域的信号强度都差不多弱，虽然合成的MRx还比较好（Io较大），但Ec都比较差，所以最终每个导频的Ec/Io也比较差。频繁的导频切换容易造成掉话，如下图所示：通常基站分布不当和基站天线参数设置不当会造成局部地区的导频污染，特别是楼宇的高层。一般可以用优化手段，即调整天线的倾角和基站功率来控制扇区覆盖范围，从而减少导频重叠区域。也可以增加合适的基站或室内分布系统，使得目标覆盖区域都能有较好的主导频。4) 外部干扰 CDMA网络带内的外部干扰会直接影响前反向链路的解调，因此也是造成掉话的原因之一。由于基站的发射功率较大，发生前向干扰的情况比较少，而手机的发射功率较小，发生反向干扰的情况较多。严重的反向干扰往往会造成大面积区域的掉话和呼叫失败，一旦怀疑可能存在外部干扰，则可以用Agilent的Viper的频谱分析功能扫频，或用Tectronix仪表直接查找干扰源。常见的干扰源包括：民用电子设备、通信设备、自激的无线直放站等。1.2 呼叫失败分析1.2.1 语音主叫过程对于语音和数据业务，主叫过程定义为从终端发起起呼消息开始，到终端发送服务连接完成消息为止。对于短消息业务来讲，又分为短短消息和长短消息，具体将会在后文详细阐述。1.2.1.1 主叫流程和相关信令一般语音业务主叫流程如下图表示：图：语音主叫流程图从图中可以看到，一般语音主叫由若干个信令处理阶段组成。某一个阶段上如果出现问题都可能会导致主叫失败。各处理阶段具体含义如下：阶段1：Origination Message On Access Channel终端在上行链路接入信道上发送一个起呼消息请求服务。阶段2：Base Station ACK On Paging Channel基站在收到终端发出的起呼消息后，在下行寻呼信道上发送响应消息进行确认。同时，基站会与系统进行一些配置协商，申请系统资源和基站资源。在所有配置和资源都具备的情况下，基站在前向业务信道开始发送空业务数据帧，方便终端进行捕获。阶段3：Channel Assignment Message On Paging Channel & Cell Null Traffic Data基站在下行寻呼信道发送信道指配消息，引导终端捕获前向业务信道。阶段4：Mobile Traffic Preamble On Acquiring Traffic Channel终端至少“看到”来自基站的两个好空帧后，认为这是一条可用的前向信道，于是就相对应的反向信道上发送两个空帧前缀。阶段5：Base Station ACK On Traffic Channel基站对收到终端发出的空帧前缀进行响应。阶段6：Mobile ACK On Traffic Channel & Mobile Null Traffic Data终端对基站响应消息的再次响应，说明一切都已经准备好。并且在反向业务信道上发送空数据帧，等待通讯开始。阶段7：Service Connect Message On Traffic Channel基站此时已经知道通讯双方都已准备就绪，发送该消息询问终端通讯是否可以立即开始。阶段8：Service Connect Complete Message On Traffic Channel终端同意准备就绪，通讯立即开始。在路测过程中所记录的路测文件，用Friendly viewer打开后可以找到相对应的信令记录。一个典型的主叫信令流程如下：7654321图中用红框表示的是路测文件信令与主叫流程可以相对应参照的部分。 下面就利用Friendly viewer工作对每条信令中主要内容进行阐述和分析（由于信令较长，此处只提供每条信令中比较重要的内容进行文字阐述）。v 第一条信令：Origination Message对应于主叫流程中的第1阶段。该信令中主要包括的内容有：v 主叫类型（Service Option）；v 终端ESN号和MIN号；v 寻呼类型（时隙或非时隙）和SCI值；v 拨号号码；v 当前导频强度；v 无线配置类型（Radio Configuration）v 第二条信令：Order Message对应于主叫流程的第2阶段。这条Order Message是对前一条终端发向基站的Origination Message的响应消息。主要用途是对前一条信令的响应，没有什么具体内容。如果没有收到该响应消息，则说明第一条Origination Message并没有被基站接收到。同时，我们可以观察到空口有很多条Order Message，究竟哪一条才是针对Origination Message的响应消息呢？这里有个方法，就是查看本条信令消息中的ACK_SEQ号是否与上一条信令消息中的MSG_SEQ相对应，如果对应起来，就说明这两条消息是一组里的。另外还可以察看消息中的MIN号，如果MIN号相同，则说明这几条消息是针对一个终端的，也可以对应起来。v 第三条信令：Extend Channel Assignment Message对应于主叫流程的第3阶段，主要用于基站向终端发送信道指配消息，主要内容包括：v 指配信道频段、PN、Walsh Code；v 前向功控目标FER；功控步进值；v 第四条信令和第五条信令：这两条信令都是Order Message，对于应主叫过程中的阶段4到阶段6。其中第四条Order消息是基站发向终端而第五条则相反。请注意这两条信令分别在前反向业务信道上进行发送，说明这两条消息都是对前反向业务信道的确认。v 第六条信令和第七条信令：Service Connect Message & Service Connect Complete Message这两条信令对应于主叫流程的第7和第8阶段。所包含的意义和主叫流程中的解释一样。在第七条信令结束之后，通讯就可正常开始。1.2.1.2 语音主叫失败分析要点及一般过程从上述分析可知，如果在主叫流程有一个阶段出问题（或信令丢失），就会发生主叫失败。下面我们分析一下几种常见的问题情况。1) 情况1：终端发送起呼消息失败。这种失败情况发生在主叫流程中第一阶段，也就是说终端发出的第一条信令Origination Message基站没有处理（或者没有受到）。典型信令消息样式如下：手机在较短时间间隔内连续发送两条或多条起呼（接入消息）请注意，这两条起呼消息从内容到格式上是一模一样的，并且分析Access probe info消息知道第二条Origination Message与第一条是同一sequence中的不同Probe，也有可能是不同sequence，说明终端在不停的尝试接入。v 分析要点及思路：由于前反向链路上某些原因导致终端发送起呼消息失败。分析思路及相关信令分析如下：相关信令消息和解决方案分析思路可能原因v Searcher and finger information Log（on traffic channel） INTEGRATION 512 chips NON_COHERENT 1 PILOT_OFFSET_INFO PILOT_OFFSET 0x8022 Pilot_Set_Value_Tmp 64 Set Active Reference Pilot Yes PN 34 Window Size WINDOW_POSITION -16112 chips WINDOW_POSITION_RAWDATA 4294838400 chips WINDOW_CENTER 320 chips WINDOW_CENTER32BITS 4294836544 chips WINDOW_CENTER 536854568 chips WINDOW_SIZE 3712 chips WINDOW_START 536854336 chips RX_AGC -75.248 dBm TX_AGC 10.2704 dBm TX_GAIN_ADJ 5 dB TX_PWR_LIMIT 226 SRCH_STATE Operation on the traffic channel 接收功率在-75dbm左右，而发射功率为10db左右，并且通过 LDAT分析后发现FFER偏大，由此可认为通讯链路存在干扰的可能性比较大。随后通过查基站实时底噪进一步确认干扰的存在。如确实存在干扰，则安排清查干扰。多次发送起呼消息才能接入，接入业务信道后发现终端发射功率偏高，路测软件分析后发现FFER偏大。存在干扰v 发现多次呼叫需要2到3次probe才能接入：Access Probe Info message:Message CDMA Access Probe Info SEQ_NUM 1 PROBE_NUM 2 RX_AGC -84.91467 dBm TX_ADJ 4 dB PSIST 0 CHANNEL 0 RANDOM_M 11 BACKOFF_RS 0 BACKOFF_RT 1 注意：该消息需要在CAIT的LOG MASK中激活。v 进入业务信道后发射功率稍许偏大：INTEGRATION 512 chips NON_COHERENT 1 PILOT_OFFSET_INFO PILOT_OFFSET 0x8022 Pilot_Set_Value_Tmp 64 Set Active Reference Pilot Yes PN 34 Window Size WINDOW_POSITION -16112 chips WINDOW_POSITION_RAWDATA 4294838400 chips WINDOW_CENTER 320 chips WINDOW_CENTER32BITS 4294836544 chips WINDOW_CENTER 536854568 chips WINDOW_SIZE 3712 chips WINDOW_START 536854336 chips RX_AGC -52.91467 dBm TX_AGC -10.3932 dBmTX_GAIN_ADJ 10.5 dB结论：前反向链路不平衡导致终端需要对接入功率进行重新估算和调整后才能接入。解决方案是找出链路不平衡的原因：如果是直放站引起的，可以通过修改接入参数提高一次接入成功率；如果是上行链路干扰引起，就查找干扰；还有一部分原因是测试终端或测试设备连接不正确引起，需要我们在测试时认真检查测试设备。一般需要2到3次probe才能接入，接入后终端接收功率很好，但发射功率稍有偏大，FFER正常。前反向链路不平衡在没有发现干扰和链路不平衡的情况下，出现多次接入情况。可能的原因是基站接入信道繁忙导致出现ACOC。可以通过观察SPAT数据来证实基站接入信道繁忙，是否可能出现接入拥塞情况。ACOC如果上述情况都没有发生，则有可能是基站发生的偶然现象。建议重复测试，如果没有在发生接入失败，则可以确定是偶然现象。偶然现象2) 情况2：在起呼流程中的其他阶段发生失败当基站接收到终端发起的起呼消息后，就开始处理该次起呼。从呼叫信令分析图可以看到，完成一次主叫共有7个阶段，基站收到起呼消息并开始处理后，还有6个信令阶段需要交互完成，其中任意一个阶段以外中断都会引发起呼失败。相对于终端发送起呼消息失败这种情况不同的是，终端发送起呼消息失败的原因比较多，类型比较复杂，需要分析的内容也较多（请见上述部分）。而在起呼消息被基站接收并处理后，终端已经通过了接入许可，后6个阶段只是为通信需要而进行的交互和协商。因此后6个阶段意外中断的大部分可能性是由于无线信号突然恶化造成交互信令丢失或解调失败所引起的。如果出现呼叫失败，分析信令的意外中断，可以分析起呼信令中最后一条信令前后的信号质量来分析无线原因，以下图为例： 路测发生一次起呼失败，通过分析信令后发现基站在发出第二条信令消息：Order Message之后，起呼就中断了。为定位问题原因，我们分析最后一条信令前后终端Log下来的Searcher and Finger Information消息。这个消息记录的是当前激活集、邻居集和剩余集中导频信号强度。如下图所示：OMMON_PREGAIN_INTEGRATION_PILOT_SEARCHER_INFO PREGAIN 2 INTEGRATION 512 chips NON_COHERENT 1 PILOT_OFFSET_INFO PILOT_OFFSET 0x800c Pilot_Set_Value_Tmp 64 Set Active Reference Pilot Yes PN 12RX_AGC -72.58133 dBm TX_AGC -13.5988 dBmTOTAL_PILOT_ENERGY -12.89126COMMON_PREGAIN_INTEGRATION_PILOT_SEARCHER_INFO PREGAIN 2 INTEGRATION 512 chips NON_COHERENT 1 PILOT_OFFSET_INFO PILOT_OFFSET 0x2562 Pilot_Set_Value_Tmp 18 Set Neighbor Reference Pilot 1024 PN 354RX_AGC -71.248 dBm TX_AGC -52.25 dBmTOTAL_PILOT_ENERGY -14.46732 由上图分析可知，在Order Message前后的信号质量已经很差了，不管是激活集还是邻居集中的信号，Ec/Io都在-12db以下。因此可以判断正是由于信号质量差导致信令丢失而引起起呼失败。另外，我们从中可以观察到另外一个重要信息，在Searcher and Finger Information消息中提示终端接收功率却比较好，基本在-70dbm左右。按理说这样的接收功率其主导频的Ec/Io应该比较好才对。而事实上从LOG消息发现主导频的Ec/Io很差。因此我们继续查看另外几个Searcher and Finger Information消息（由于篇幅限制不能一一展现），发现终端接收到多个导频，且强度都在-13左右，因此判断此点属于典型的导频污染区，需要优化解决。另外需要指出的是，由于CDMA终端有RAKE接收功能，所以在Searcher and Finger Information消息中可以发现有一个导频有4个path信号强度，总强度是4个path经过RAKE合成之后的总和，因此以消息中的TOTAL_PILOT_ENERGY（图中红色粗体标注）数值为准。 总的来说，主叫失败以上面两种情况密切相关。当然，具体问题还要具体分析，除无线部分原因以外，在起呼过程中由于交换系统发生软硬件问题引起呼叫处理问题而导致主叫失败也有可能。象这种系统问题我们可以在系统的ROP文件中找到相对应的失败消息。有关于ROP文件的使用和阅读，会在本文中专门章节中论述。1.2.2 数据业务主叫流程1.2.2.1 主叫流程数据业务主叫流程在空口建立阶段和语音呼叫非常类似。比语音呼叫复杂的是，数据业务主叫还要在分组域内进行一些必要的协议协商。数据业务主叫流程示意图如下所示：由图可见，数据主叫包括三个主要部分：空口建立阶段、SVC建立阶段和PPP协商阶段。v 空口建立这个阶段和语音主叫空口建立阶段几乎是一样的，所不同只是在第一条Origination Message里的Base_Service_Option_Number是33（表示是数据呼叫）。v SVC建立MSC会为每个数据呼叫建立一条与PCF之间的SVC链路。SVC是通过MSC内部协议处理板PH4/PH22来完成的。v PPP协商在SVC建立后，终端和PDSN之间就会对PPP进行一些协商，协商的内容包括链路协议类型、鉴权、账户消息、IP地址分配等。1.2.2.2 数据业务主叫失败分析要点和一般过程由于数据业务主叫分三个阶段，因此每个阶段出现问题都会影响主叫成功率。同时，为确保不受意外情况影响，在测试前必须确保以下几项内容：1) 测试终端/测试号码是否合法？2) 测试号码是否已开通数据服务？3) 终端和电脑间是否连接正确？拨号服务是否设置正确？4) 区域内基站是否设置参数正确？在确认上述全部设置正确后，就可以开始路测和分析。下面就对主叫中常见的问题进行分析。v 数据业务主叫空口建立失败数据业务主叫空口建立阶段几乎和语音主叫空口建立是一样的，只有在Origination Message里的Base_Service_Option_Number是不同的。因此数据业务主叫空口建立阶段的失败原因、案例分析和语音主叫的分析过程是一样的，此处不在赘述。v MSC和PCF之间SVC建立失败当每次数据呼叫建立时候的，MSC都会要求建立与PCF之间的SVC链路。如果SVC申请失败，则此次呼叫也失败。下面一张示意图说明SVC申请过程： 其中，401中继表示用户逻辑中继链路，501/502中继表示为每个数据用户分配的逻辑中继链路。在每条501/502逻辑中继链路上，各建有多条虚拟用户链路SVC链路。每个数据用户在建立数据联接时就要占用一条SVC链路。当每次数据呼叫时，都会先给用户分配一条401用户中继链路，随后在PH4中处理后在为数据用户分配一条501/502逻辑中继（SVC）。 在某些情况下，可能由于501/502中继数量不够导致无法给用户分配SVC而造成呼叫失败的情况。在这种情况，首先分析空口信令确认空中接口是否已经建立，如果空口已经建立而呼叫失败，则可以基本排除空口建立失败的可能性；此时就需要在MSC侧利用Uxcptrace来定位问题点。下面就以一个Trace后的消息来说明由于SVC分配失败而引起的呼叫失败。仔细察看以下消息：10:25:13.038 Received MG_SH_ASGN_X (b6) from DCS 16 Assigned speech handler TNN 16-403-24 to the call 10:25: MOR015 (CPor015) Signal - DCSMSG MG_SH_ASGN_X 。 10:25:14.238 Received TCCONF_C (94) from CS 4 Forward SMV Mode: premium (0) Forward Radio Configuration: RC3 Reverse SMV Mode: premium (0) Reverse Radio Configuration: RC3 Code Channel and Frame Offset: code channel 45; frame offset 14 3G1X Packet Data: max rate 153.6 kbps (fwd) 76.8 kbps (rvs) Measurement Data in Call Record: length 10 10:25: MOG070 (CPog070) Signal - CS_MSG TCCONF_C 10:25:49.738 Received MURLS (5c) from CS 4 10:25: MOG070 (CPog070) Signal - CS_MSG MURLS 10:25:49.738 Sent RLSACK (4e) to CS 4 10:25:53.038 Received MG_FAIL_X (71) from DCS 16 DCS Fail on TNN 16-502-32 6 TYPE: Failure to seize a trunk 16 REASON: Network Order Failure 2 RESULT: Clear Request DCS message type causing failure: MG_SETUP_SVC_X 10:25: MOG070