W接入问题分析指导书1101A10.docx
《W接入问题分析指导书1101A10.docx》由会员分享，可在线阅读，更多相关《W接入问题分析指导书1101A10.docx（39页珍藏版）》请在冰豆网上搜索。
W接入问题分析指导书1101A10
华为技术有限公司
HuaweiTechnologiesCo.Ltd.
产品版本
密级
V100R001
内部公开
产品名称:
WCDMARNP
共35页
WCDMARNO接入问题分析指导书
（仅供内部使用）
Forinternaluseonly
拟制:
URNP-SANA
日期：
2003-10-08
审核:
日期：
审核:
日期：
批准:
日期：
华为技术有限公司
HuaweiTechnologiesCo.,Ltd.
版权所有XX
Allrightsreserved
修订记录
日期
修订版本
描述
作者
2003-10-08
1.00
初稿完成。
焦安强
2003-10-14
2.00
根据意见修改。
焦安强
2003-11-11
3.00
根据评审意见修改
焦安强
目录
1前言6
2接入问题分析过程6
2.1分析前的准备工作6
2.2接入问题分析方法7
2.2.1话统数据分析7
2.2.2信令流程分析9
2.2.2.1确定标准信令接口信令流程的异常点9
2.2.2.2无线网络层标准信令分析10
2.2.2.3传输网络层标准信令分析10
2.2.2.4内部信令流程分析11
2.2.2.5RRC连接建立信令分析过程12
2.2.2.6信令分析案例15
2.2.3设备情况分析17
2.2.4覆盖分析20
2.2.5功控信息分析20
2.2.6接入算法参数分析23
2.2.7UE自身特性分析23
3接入问题常见原因分析23
3.1网络原因24
3.1.1信号覆盖存在盲点24
3.1.2存在过大的上下行干扰信号24
3.1.3小区负荷引起的接入问题25
3.2无线参数设置原因25
3.2.1Qqualmin，Qrxlevmin设置过高25
3.2.2接入门限设置不合理26
3.2.3前导功率攀升步长和重传次数设置不合理26
3.2.4相邻小区设置不合理27
3.2.5同步参数设置不合理27
3.2.6公共信道功率配比过低28
3.2.7上下行专用信道初始功率过低28
3.2.8专用信道上行初始SIR目标值设置过低29
3.3设备原因29
3.3.1RAN设备单板资源不够29
3.3.2设备时钟异常29
3.4数据配置原因30
3.4.1IUB带宽资源不够30
3.4.2AAL2PATH的PATHID和NSAP地址配置错误31
3.4.3IU/IUB口两端AAL2PATH的个数不一致31
3.5其它原因32
3.5.1UE的接入等级AC不够32
3.5.2UE、RNC、CN的安全性数据不一致32
3.5.3UE在HLR没有开户33
4遗留问题33
表目录
表1公共信道功率配比28
表2IUB接口各层开销比例表30
图目录
图1话统分析过程8
图2无线层信令示意图10
图3传输网络层信令分析示意图11
图4单用户故障定位工具12
图5RRC建立在专用信道各层信令13
图6RRC建立在专用信道问题分析流程14
图7UE空口消息跟踪16
图8因覆盖受限导致的接入问题现象22
图9正常接入过程22
图10UE鉴权和安全模式过程32
WCDMARNO接入问题分析指导书
关键词：
接入过程，问题分析，小区搜索，小区选择和重选，随机接入，
摘要：
本文从接入层（AS）的角度分析了阐述了定位接入问题的一般步骤，然后分析了导致接入问题的常见原因并给出解决方法。
缩略语清单：
略
1
前言
在WCDMA网络运行中，呼通率低、接入困难是用户投诉的热点，也是无线网络质量直接反映。
本文主要分析了解决接入问题的一般流程，引起接入失败的常见原因，以及通过哪些手段来解决问题，从而提高呼通率，提高网络质量。
本文讨论的主题是接入过程，首先明确一下“接入过程”的概念。
从无线的角度来看，接入过程包括用户开机搜网、随机接入、RRC建立、RAB建立等一系列的过程。
站在最终用户的角度上，接入过程就是从拨打电话到电话接通的过程，这个意义上来讲的接入过程除了包含无线接入过程，还包括很多在固网中发生的过程。
无线网络优化主要关注无线侧的接入过程，重点考察包括小区搜索、小区选择重选、随机接入、RRC建立等过程，也是本文讨论的重点所在。
之所以这样考虑，是因为在网优阶段，更多的是考虑网络覆盖等无线口性能，通过UE或路测设备测量小区的导频信号，观察UE是否正常进行小区搜索和选择、重选，发起随机接入，附着、位置登记/更新，接受网络的正常服务，以便进行站点调整（站间距、天线的方向角和下倾角等）。
和RAB建立成功率相比，RRC连接建立的成功率更能反映无线接入性能的好坏，因为RRC连接建立的过程基本涵盖了小区搜索和选择、重选，发起随机接入等发生在空口的过程，而RAB建立成功率更多地与设备、传输、业务参数等网络因素相关，网络因素导致接入问题的几率相对要小得多。
2接入问题分析过程
2.1分析前的准备工作
接入问题分析前的准备工作主要是在对网络接入问题进行分析前，要尽量充分地收集网络的相关信息，这样才能有效确定网络优化的目标，对于不同的覆盖区域、不同的应用环境应制定不同的优化策略和优化目标。
前期准备工作如下：
●熟悉网络前期规划情况，获取网络规划的前期文档，如规划报告，建立对网络的整体印象并可能从中发现一些明显问题。
●对于开通后网络，可能在本次优化之前已经经历了优化过程。
在本次优化开始之前应获得各次优化历史记录，了解各次网络调整过程及遗留问题。
●如果因为某些原因无法获得完整的规划报告、扩容报告、优化历史记录，则需要通过其它途径获得可靠的最新工程参数汇总表，小区参数配置表可以直接从设备配置数据中联机读取。
●获取出现接入问题时的网络话统数据和用户对接入的投诉材料，话统信息可以在M2000上获取。
●获取无线参数的配置情况，相对版本发布的基线参数有什么调整，特殊算法（如DRD等）是否运用。
●要检查设备使用的软硬件版本是否正确，确定各基站、RNC等版本是否配套，确定全网版本是否统一，是否所有基站都采用相同的版本，包括补丁版本。
●如果是网络开通前的优化，要确定每个基站开通后是否进行过拨测，基站的底噪是否进行过校准（校准接收通道增益），是否测试过天线的驻波比。
●如果是网络开通前的优化，还要检查系统各个设备的时钟情况，重点检查各个设备的时钟源是否合理，是否按照规划进行具体执行的，当前的时钟状态等等。
2.2接入问题分析方法
接入过程是UE和网络进行交互的第一步，接入成功与否涉及到很多方方面面的因素，所以网络出现接入问题有时感觉到无从下手，找不到问题的切入点。
下面给出了常用的接入问题分析方法，遵循操作上由易到难、人力物力投入尽量低的原则。
通过话统分析和信令流程分析可以迅速缩小问题定位范围，锁定问题出现在接入过程的哪个环节。
然后辅助以设备情况分析和覆盖情况分析，在问题定位早期排除设备、覆盖等外部因素，避免在定位过程走弯路。
如果需要的话，接下来在前面几个环节分析的基础上对功控信息、接入算法、UE自身特性进行更深入的分析，直至最终解决问题。
以下接入问题的分析方法在实际定位过程中可以根据实际情况综合使用，不必拘泥于严格的先后顺序。
2.2.1话统数据分析
查看RNC的话统数据“呼叫建立成功率”,呼叫建立成功率的公式如下：
其中，
同理，当然也可以分别统计每种QoS的呼叫建立成功率。
RRC连接建立成功的标志是RRCConnectionSetupComplete消息。
因此，RRC连接建立成功率通过统计RRCConnectionSetupComplete消息个数和RRCConnectionRequest消息个数得到。
RAB指配成功的标志是RABAssignmentResponse消息（消息内容为RAB指配）。
因此，RAB指配成功率通过统计RABAssignmentResponse消息中建立成功的RAB数目个数和RABAssignmentRequest消息个数得到。
这个指标是面向小区统计的，反映网络的呼叫建立情况，可以对conversation，Streaming，Interactive，Background四种QoS业务一起统计，也可以分别统计。
分析话统数据可以从统计的角度上找到解决问题的大致方向，话统数据除了要关注比例数据外，还要重点关注原始计数器统计数据（如RNC收到RRC连接请求消息个数），并且要熟悉原始计数器数据和比例数据的对应关系，以及这些数据的自身意义、在信令业务建立过程的所处环节等等。
呼叫建立成功率由RRC建立成功率和RAB建立成功率的乘积得到，在实际话统分析过程中可以进行简化处理，单独分析RRC建立成功率和RAB建立成功率，甚至针对conversation，Streaming，Interactive，Background单独分析。
通过对RRC、RAB建立中的相关话统数据进行分析，可以锁定可能出现问题的环节，确定下一步深入分析的方向，毕竟话统分析是一种统计意义上的近似分析方法。
接入过程话统分析流程如图1。
图1话统分析过程
RRC建立成功率在很大程度上反映了网络的用户呼叫成功率，因为在接入的角度上衡量，RRC建立更加接近无线口，出现异常的几率要比RAB建立高。
RRC建立成功率表现在话统上可能有两种截然相反的表现，一个是话统显示成功率高，但是用户还是投诉接入困难，这种情况原因是接入过程在RRCCONNECTREQUEST消息发出前已经失败了，如果在创建性能统计任务时加入“RRCCONNECTREQUEST消息个数”，会发现这个数值比正常统计值（或经验值）小得多。
出现这种情况的原因是如果UTRAN没有收到RRC建立请求消息，话务统计无法用RRC建立成功率指标统计这种情况（见RRC建立成功率的定义），只能查看RRC连接请求消息的个数这个统计指标。
这种情况可以重点分析RRC连接建立前小区搜索、小区选择与重选、随机接入等过程。
另外一种情况是RRC建立成功率低真实反映了接入困难的问题，这种情况也不能完全肯定接入失败发生在RRC连接建立之后，要查看“RRCCONNECTREQUEST消息个数”指标，如果远远低于正常统计值，还是要考虑RRC连接建立之前的因素；如果接近正常统计值就可以侧重于分析UTRAN收到RRCCONNECTREQUEST消息之后的流程了。
RAB建立中的关键过程是RB建立（和UE有空口消息交互），在分析RAB建立成功率可以重点考察RB建立成功率，因为除了RB建立外其它过程主要是地面接口和设备内部的消息交互，RB建立成功率公式如下。
如果RB建立成功率高而RAB建立成功率低，要重点检查设备情况和地面接口传输层配置。
和接入相关的话统数据除了RRC、RAB建立成功率及其相关原始计数器数据外，还可以分析其它与RRC、RAB相关的统计数据，如RRC、RAB因为拥塞导致建立失败的比例，如果拥塞比例高就表示小区已经超设计负荷运行了。
本文限于篇幅不作详细讨论了，可以查看话统指标的相关说明文档《华为3GWCDMA部分性能管理指标（RNC）》。
2.2.2信令流程分析
信令流程可以很直观的看到整个接入过程在哪个环节失败，通过信令流程分析往往可以解决大部分的接入问题，包括下行容量受限的问题。
信令流程分析的步骤基本上遵循从高层到底层、从外到内、从控制面到用户面的原则。
从高层到底层是指依次分析L3、L2、物理层、传输层的信令，NAS的信令在RAN透传，需要在在核心网进行跟踪分析。
从外到内的原则是指先分析标准接口信令，如果从标准接口信令分析中无法获得足够的信息，需要分析设备内部单板间、单板模块间的信令。
2.2.2.1确定标准信令接口信令流程的异常点
分析接入问题的标准信令有三个观察点：
UE的监控后台、NODEB的维护台、RNC的维护台，由于RNC基本上包括另外所有接入侧的标准接口，所以在实际操作中基本上以RNC的信令观察分析为主。
信令流程的异常无非有两种：
请求消息发出后收到失败消息、没有收到请求消息或者响应消息。
这样可以确定定位方向，缩小问题定位的范围。
如果是L3请求消息发出后收到失败消息，基本上可以肯定是底层传输没有问题（也有可能传输误码导致消息ASN.1解码错误，这种情况基本上不会出现，截至现在为止没有发现过），原因要么是发过来的请求消息填写错误，要么就是接收方处理异常。
没有收到请求消息或者响应消息，就有两种可能，一个是发送方根本没有发送，发送方可能由于内部过程出现种种异常导致该发出的消息未能发出；一个是消息包在传送过程中丢失了。
如RRCCONNECTREQUEST消息没有收到，可能是由于种种原因UE根本没有发出，这个可以从UE后台打印和消息跟踪可以看出，也有可能是NODEB解码错误丢包、或者是IUB口丢包（可以用网鹰观察）。
2.2.2.2无线网络层标准信令分析
无线网络信令包括UU、IU、IUB、IUR四个标准接口的信令，在信令流程出现异常的情况下，可以打开维护台上跟踪的消息包，查看消息中相关IE，看是否出现异常赋值.尤其消息交互的一方收到失败或者是拒绝消息时，可以从消息解析中直接获得失败的原因值，为下一步的定位提供基础。
如图5在RLSETUPREQUEST消息中，上行初始sirtarget值原来设置的值一直是0dB，导致UE在接入过程中发生失步现象，因为相对于内环功控来说，外环功控有一个滞后，这段时间如果SIR过低会导致UE上行专用信道发射功率较低，从而上行失步。
图2无线层信令示意图
2.2.2.3传输网络层标准信令分析
传输网络层信令包括IUB的SAAL、ALCAP信令跟踪，IU、IUR口的SAAL、ALCAP、MTP3B、SCCP信令跟踪。
如果传输网络层发生故障，如AAL2CHANNAL建立失败，可以跟踪传输层信令进行分析。
如图，跟踪了IUB接口ALCAP的ESTABLISHREQUEST消息，NODEB端的NASP地址是Ox3902030405060708090009080706050403020100，如果RNC和NODEB进行数据协商时NASP地址两边不一致就会导致AAL2CHANNAL建立失败，RNC会向UE发送RRCCONNNECTREJECT消息，原因值是UNSPECIFIED，类似这种情况，从无线网络层信令分析中无法得到充足的信令，可以分析一下传输网络层的信令。
图3传输网络层信令分析示意图
2.2.2.4内部信令流程分析
如果无线层和传输层的信令分析都不能解决问题，可以考虑进行内部消息流程分析，主要是内部消息流程跟踪及打印分析，关于RNC的呼叫内部流程可以参考文档《RR流程20020916.PRZ》。
在现网中尽量不要使用这种方式，因为内部跟踪和打印开关一旦打开可能会导致内部消息通道拥塞，造成设备发生意外事故。
RNC和NODEB都可以使用调试台或者是串口进行内部消息流程分析，具体方法可以参考RNC和NODEB的调试台帮助文档，NodeB可以参考《WCDMANodeBV100R002算法子系统调试台用户手册》，RNC可以参考《WCDMARNC测试台透明消息联机帮助》。
另外，RNC新近开发了CDR工具（单用户故障跟踪），可以跟踪与指定UE相关的所有信息。
包括标准接口消息、内部消息、L2L3间的原语、与UE相关的所有的打印信息等等，包含用户面和信令面的定位信息，如图6。
图4单用户故障定位工具
2.2.2.5RRC连接建立信令分析过程
RRC建立是接入过程优化需要关注的重点，RRC建立在专用信道各层信令流程如图5所示。
RRC建立涵盖了RRC、NBAP、Q.AAL2、FP等协议交互，其中有一个环节失败就会导致整个过程的失败。
图5RRC建立在专用信道各层信令
对于RRC建立在专用信道，根据图5的信令流程，可以对其中出现的问题参考以下分析步骤，如图6所示。
现场工程师可以对照流程图定位出问题的大概范围并收集相关现场定位信息，如果需要在现场对问题进行深入定位，请参考文档《WCDMA专家组，WCDMA系统问题定位手册20030102版》。
图6RRC建立在专用信道问题分析流程
1、RNC没有收到RRCCONNECTREQUEST消息：
RNC的UU口跟踪没有发现RRC连接请求消息，首先可以用网鹰在IUB口观察RRC连接请求消息是否已经发到IUB接口，如果没有发现，再进一步分析是小区搜索、随机接入的问题还是NODEB内部异常，可以借助UE后台打印和NODEB调试台进行定位；如果在IUB接口有RRC连接请求消息出现，可能是IUB接口丢包、RNC内部处理异常等原因，借助网鹰可以检查IUB接口丢包情况，RNC内部处理异常可以查看RNC的告警台、单板串口打印、单板运行日志和内部消息跟踪。
2、无线链路建立失败：
这个问题出现的可能性小，如果出现了该问题，很大可能是RNC或者是NODEB内部出现异常，可以查看告警台和无线链路建立消息解析，如果需要深入定位可以使用RNC和NODEB的调试台定位内部流程。
3、承载空口信令的AAL2链路建立失败：
检查RNC和NODEB的AAL2PATH数据配置，重点检查AAL2PATH的VPI/VCI、NODEB的ATM地址、AAL2PATHID、PVC流量大小和类型、AAL2PATH带宽和CID消耗情况等因素。
4、DCHFP同步失败：
DCHFP通过交互上下行同步帧进行传输信道同步，可以用网鹰在IUB接口观察这两个控制帧。
如果DCHFP同步失败，可能的原因有两端AAL2PATH配置不一致、IUB接口时延过大或者设备时钟异常，可以进行逐步排查。
5、UE没有收到RRCCONNECTSETUP消息：
从RNC开始检查，依次查看RNC的UU接口跟踪、IUB接口（用网鹰）、IUB接口的AAL2链路、E1/T1状态、NODEB的处理情况等因素。
确定在哪个环节出了问题。
6、RNC没有收到RRCCONNECTSETUPCOMPLETE消息：
见本文2.2.2.6信令分析案例部分的论述。
7、RNC没有收到RLRESTORE消息：
RNC如果在一定的时间内没有收到RLRESTORE消息会认为NODEB上行同步失败，就会发起删链。
可以检查上行同步参数N_INSYNC_IND、N_OUTSYNC_IND、T_RLFAILURE设置是否合理。
2.2.2.6信令分析案例
现象：
RNC收不到UE的RRCCONNECTSETUPCOMPLETE消息【7】
对于RRC连接建立在专用信道，RRCConnectComplete消息是上行DPCH的第一条消息，这条消息成功收到与否标志着上行DPCH是否真正建立成功以及传输质量的好坏。
可以首先通过观察UE的打印信息以及消息跟踪确认UE是否收到RRCConnectSetup消息以及RRCConnectSetupComplete消息是否发出。
北研UE具备上述观察点，NECUE要借助其专门的维护工具观察（NECUE出现问题可以考虑使用北研UE协助定位）。
RNC收不到UE的RRCCONNECTSETUPCOMPLETE消息有三种可能，UE根本没有发出、消息在传输中丢掉了、UE没有收到RRCCONNECTSETUP。
UE没有发出RRCConnectSetupComplete消息
定位步骤：
确认UE收到RRCCONNECTSETUP消息。
有两种方法：
1）可在超级终端上看是否有收到RRCCONNECTSETUP消息的打印，如没有则是没有收到SETUP消息。
打开RRC上报空口消息，查看在RRCCONNECTIONREQ消息后有无RRCCONNECTIONSETUP消息，如有查看这两个消息的UEID是否一致，如不一致，则没有收到SETUP消息（因为UE在收到空口消息后，先报给后台，然后再处理的，所以后台看到的SETUP不一定是该UE的，需要比对UEID后确认）。
RRC上报空口消息图示如下：
图7UE空口消息跟踪
2）UE收到SETUP消息后，释放RB0（随机接入信道），在保护定时器超时之前释放完成后启动功控，开始建立下行专用信道（配置无线链路和传输信道和MAC）。
在保护定时器超时之前RRC收全各层的配置原语确认之后，启动定时器T312，在T312超时之前收到N312个CPHY_SYNC_IND原语后，停止T312。
开始建立上行专用信道（无线链路）同时配置RLC（RB1-RB4）。
在RRC的保护定时器超时之前收全各配置原语确认后，启动测量，配置UE最大上行发射功率，并启动SRBDELAY定时器（等待NODEB进行上行同步），在SRBDELAY定时器超时后发送RRCCONNECTIONSETUPCOMPLETE消息。
在配置的各个阶段如果在保护定时器超时（终端输出会有TIMEROUT字样）之前RRC没有收全各配置原语确认会导致UE发不出RRCCONNECTIONSETUPCOMPLETE，主要涉及到RLC、MAC和物理层发给RRC的实例建立、配置、释放等原语。
现在最多的情况是T312超时RRC还没有收够N312个CPHY_SYNC_IND原语（表示下行同步失败）而导致UE发不出RRCCONNECTIONSETUPCOMPLETE。
如果同步失败可以打开UE后台的“功率控制信息显示”观测下行RSSI和SIR测量值。
如果RSSI小于－100dBm，SIR测量值一直低于Sir目标值，可以检查NodeB的发射功率设置范围是否正确（通过Iub口的无线链路建立消息观察）。
需要注意的是要在“显示设置”中设置相应的选项，才会有信息显示。
NodeB内异常导致丢包
通过NODEB的调试台查看解调DSP和译码DSP的相关统计信息，确定NodeB在新建的上行DPDCH上是否收到数据包或者收到的全部是错包。
详细的操作方法可参考NODEB调试台帮助文档。
IUB口丢包
RRCCONNECTSETUPCOMPLETE可能在IUB接口丢掉，可以从底层到高层E1->ATM->FP来分析。
首先检查是否有E1告警，可以查看告警台是否“E1信号丢失告警”，然后可以在RNC的维护台上执行DSPE1T1检查AAL2PATH对应的E1状态。
如果E1断链，可以分别在RNC、NODEB端进行环回操作，基本上可以定位问题是出在RNC、NODEB或者是传输。
底层传输有可能是IMA组，这时要重点检查IMA组内的各条E1、IMA组号两端要一致。
如果E1正常，可以检查ATM层的AAL2PATH是否正常，用MML命令DSPAAL2PATH检查PATH的状态，PATHID、NASP地址、E1链路号、PVC是重点检查的对象。
如果AAL2PATH没有异常，继续检查IUB的用户面FP层，FP层可能会因为发生时间窗问题而丢包，关于时间窗的概念可参考相关文档。
RNC在超时后收到RRCCONNECTSETUPCOMPLETE消息
RNC等待消息超时的定时器长度是5秒，用MML命令L
升级会员 