接入问题分析_第1页
接入问题分析_第2页
接入问题分析_第3页
接入问题分析_第4页
接入问题分析_第5页
已阅读5页,还剩31页未读 继续免费阅读

下载本文档

版权说明:本文档由用户提供并上传,收益归属内容提供方,若内容存在侵权,请进行举报或认领

文档简介

1、产品名称Product name密级Confidentiality levelWCDMA RNP内部公开产品版本Product versionTotal 35pages 共35页2.0WCDMA RNO 专题指导书 接入问题分析 (仅供内部使用)For internal use only拟制:Prepared byURNP-SANA日期:Date2004-12-22审核:Reviewed by日期:Date审核:Reviewed by日期:Date批准:Granted by日期:Date华为技术有限公司Huawei Technologies Co., Ltd.版权所有 侵权必究All righ

2、ts reserved修订记录Revision record日期Date修订版本Revision version修改描述 change Description作者Author2004-08-23100确定大纲官仕国2004-11-03100初稿完成官仕国2004-12-20100根据评审意见修改官仕国目 录1概述72接入失败分类定义73接入失败分析流程及方法83.1分类数据分析流程8路测数据分析流程8话统数据分析流程13跟踪数据分析流程15告警数据分析流程15用户投诉分析流程153.2调整措施15工程参数15小区参数164典型接入失败问题分析174.1寻呼问题17寻呼相关信道功率配置不合适17

3、寻呼时UE进行位置更新17UE隐式分离引起寻呼失败184.2小区重选问题18现象和分析18解决方法204.3RRC建立问题21上行接入信道参数设置不合适21AICH信道功率设置不合适24FACH信道功率设置不合适24下行专用信道初始功率配置不合适274.4RAB和RB建立问题27RNC直接拒绝RAB的建立请求27IUB口准入拒绝28UE回应RB建立失败造成的RAB建立失败28空中接口RB建立失败造成的RAB建立失败284.5信令流程没有完成出现切换失败29现象和分析29解决方法314.6鉴权问题31失败原因是MAC Failure31同步失败(sync failure)314.7加密问题31问

4、题描述和分析31解决方法324.8设备异常问题32NodeB异常32手机异常345网优各阶段关注点365.1单站测试阶段365.2优化前评估阶段365.3RF优化阶段365.4参数优化阶段365.5网优项目验收阶段366附录:接入过程介绍36图目录图1 路测数据或跟踪数据的分析流程9图2 主叫UE信令流程10图3 寻呼问题分析流程图11图4 RRC连接建立问题分析流程图13图5 话统数据分析流程15图6 UE的信令19图7 UE第一次发送接入请求时的信号质量19图8 UE第二次发送接入请求时的信号质量20图9 UE的信令21图10 RNC的单用户跟踪信令21图11 下行信号质量22图12 24

5、8号小区有规律的干扰23图13 干扰局部放大图23图14 UE的信令25图15 第一次发起接入请求时的信号强度25图16 RNC的单用户跟踪信令26图17 第一次发起接入请求时的信号强度27图18 UE的信令30图19 RNC的单用户跟踪31图20 断链前的信号强度31图21 UE的信令34图22 RNC的单用户跟踪信令34图23 出问题时的信号强度34图24 UE的信令35图25 下行信号质量36WCDMA RNO 专题指导书 接入问题分析关键词:接入、接通率、FACH、功率配比、RAB、鉴权、加密、话统摘 要:接通率是网络KPI中的一个重要的指标,随着网络优化阶段的不同优化的方法和重点会有

6、所不同,本文从话统、路测和跟踪数据几个方面来阐述接通率的优化方法,并通过大量的案例来描述各类问题的定位和分析方法。缩略语清单:缩略语英文全名中文解释FACHForward access channel前向接入信道RACHRandom access channel随机接入信道AICHAcquisition indication channel确认指示信道RBRadio bearer无线承载RRCRadio resource control无线资源控制1 概述本文的主要目的是详细描述接入问题的定位流程和思路,包括从路测数据、话统数据等来分析接入失败问题的原因。接入相关的知识介绍不是本文的重点,具体

7、可以参考资料【1】。在第四章中对典型的接入相关的问题进行了分类汇总,并详细分析了原因和定位过程。第五章结合了网络优化各个阶段的特点列出了不同的关注点。2 接入失败分类定义数据分析工具Analyser按照如下的原则来定义接入失败,主叫UE在发出RRC Connection Request后,满足下面任何一个条件都认为是接入失败:a、 收到RRC Connection Reject消息;b、 UE在收到RRC Connection setup消息后收到或是发出了RRC Connection Release消息;c、 在Call setup过程中收到任何的BCCH上的消息;d、 定时器超时,即在UE

8、发送了RRC Connection Request后 3秒钟(T300)内没有收到RRC Connection setup消息。数据分析工具TEMS按照下面的原则来定义接入失败(对于主叫语音业务):a、 随机接入失败:拨号后RRC Connection Request消息没有发送;b、 RRC Connection Setup消息没有收到:UE发送了RRC Connection Request消息后没有收到RRC Connection Setup消息c、 RRC Connection Complete消息没有发出:UE在接收到RRC Connection Setup消息后,没有发出RRC Co

9、nnection Setup Complete消息。d、 UE收到消息RRC Connection Reject:UE收到RRC Connection Reject消息并且没有重发RRC Connection Request进行尝试。e、 UE没有收到测量控制消息:UE在发出RRC Connection Complete消息后没有收到测量控制消息。 f、 没有发出CM Service Request:UE在收到测量控制消息后没有发出CM Service Request。g、 UE收到Service Request Reject消息:UE收到了Service Request Reject消息。h

10、、 UE没有收到Call Proceeding消息:UE在发送了CC SETUP消息后没有收到Call Proceeding消息。i、 UE没有收到RB Setup消息:UE收到Call Proceeding消息后,没有收到RB Setup消息。j、 UE没有发出RB Setup Complete消息:UE在接收到RB Setup消息后,没有发出RB Setup Complete消息。k、 Alert or Connect消息没有收到:UE在发出RB Setup Complete消息后,没有收到Alert or Connect消息。l、 UE没有发出Connect Acknowlege消息:U

11、E收到Alert or Connect消息后,没有发出Connect Acknowlege消息。RNC后台的跟踪数据没有定义接入失败,不过可以根据Call Setup的流程来区分是否是接入失败,可以参考TEMS的接入失败定义。话统数据中将接入的过程分成多个过程进行成功率统计,包括:CN_PAGE_IDLE_UE_SUCC_RATE,CN寻呼IDLE模式下的UE的成功率;UTRAN_PAGE1_SUCC_RATE ,UTRAN发起Page1寻呼,收到响应的成功率;RRC_SETUP_SUCC_RATE/RRC_REJ_RATE ,RRC建立成功率和RRC建立拒绝率;RRC_A

12、BNORM_REL_RATE,RRC被异常释放的比率;RB_SETUP_SUCC_RATE,RB建立成功率;RAB_SETUP_SUCC_RATE,RAB指派成功率;通过这些指标可以获得各个阶段的成功率。3 接入失败分析流程及方法3.1 分类数据分析流程3.1.1 路测数据分析流程1. 数据分析主流程如果某个用户有路测数据或同时有单用户跟踪的数据,可以按照以下的流程进行分析:分析数据NYNYYNYYYNNNYN是否RRC连接建立失败鉴权加密是否失败RAB建立是否失败是否是主叫失败是否有Call Fail是否收到寻呼切换导致接入失败寻呼问题RRC建立问题鉴权加密问题RAB或RB建立问题参考切换导

13、致掉话异常问题图1 路测数据或跟踪数据的分析流程1) 测试数据的获取路测数据一般采用Agilent的E6474或者是我司开发的工具Probe连接上测试终端来获得,RNC的单用户跟踪数据在RNC的操作维护台记录,建议使用TMSI来进行单用户跟踪,这样可以记录RRC建立的消息;RNC记录CDL的数据。2) 确定是否有Call Fail和相应的时间通过路测数据分析软件,比如Analyzer软件或DA,确定发生Call Fail的时间,以及Call Fail前后Scanner采集的导频信息、手机采集的激活集和监视集的信息以及信令流程。通过消息对齐手机采集的信令和RNC的单用户跟踪的时间,同时找到RNC

14、单用户跟踪的相应的出问题的时间点。由于不同的数据分析软件对Call Fail的定义不一样,比如TEMS定义UE重发一次RRC Connection Request消息为一次接入失败,而Analyzer则认为这是一种正常的情况。如果使用Analyzer分析数据,需要通过人工统计RNC的单用户跟踪信令和UE的信令(或者使用文字查找工具)获得UE重发RRC Connection Request的时间点。3) 问题分析结合RNC的单用户跟踪和UE的信令流程,按照图1的流程确定在哪一处出现失败。然后按照后续的各个子流程分析和解决问题,主要包括寻呼问题、RRC建立问题、RAB和RB建立问题、鉴权加密问题、

15、设备异常问题等。2. 寻呼问题分析流程寻呼问题一般都表现为:主叫完成RAB指派以及CC Setup,在等待Alerting消息的时候收到CN发来的Disconnect直传消息,参见图2。被叫从UE的信令流程一般看不出异常,但也出现过UE收到Page消息而没有发起RRC连接建立请求。从被叫的RNC单用户跟踪可以看出收到CN下发的Page消息,但没有后续的消息。图2 主叫UE信令流程 CC CALL PROCEDING本应该在CC SETUP之后寻呼问题RNC是否下发pageUE是否收到page是否功率配比偏低是否是重选问题NYYNYNYN设备异常问题根据覆盖情况调整功率配比优化小区重选参数异常问

16、题转RRC建立问题图3 寻呼问题分析流程图出现寻呼问题的原因主要有图示的几类:RNC没有下发page消息、寻呼信道或寻呼指示信道的功率偏低、UE发生小区重选等。1) 如果是RNC收到CN下发的page消息后UU口没有下发,可能是寻呼信道的容量不够(现阶段由于网络负载很低,出现的概率很小,在以后网络负载较高时,可能会出现UU口page消息阻塞的情况),或者是设备异常。2) 如果RNC下发了page消息,而UE没有收到,首先查看UE的驻留小区和监视小区的Ec/Io。如果驻留小区和监视小区的CPICH信道的Ec/Io都很低(低于-12dB),那么要么是PCH信道或者是PICH信道的功率偏低,或者是这

17、个点的覆盖太差。3) 如果UE驻留小区的信号偏低而监视小区的信号较好,那么可能是小区重选的问题。还有就是在寻呼的时候UE从3G重选到2G或者是跨LAC的重选。3. RRC连接建立问题分析流程RRC连接建立失败的问题通过UE的信令流程和RNC的单用户跟踪可以获得。RRC连接建立的过程主要包括几个步骤:UE通过RACH信道发送RRC Connection Request消息,RNC通过FACH信道发送RRC Connection Setup消息,UE在建立下行专用信道并同步后通过上行专用信道发送RRC Connection Setup CMP消息。RRC建立失败一般有下面几类原因:上行RACH的问

18、题、下行FACH功率配比问题、小区重选参数问题、下行专用初始发射功率偏低、上行初始功控问题、拥塞问题、设备异常问题等。在这些问题中尤其上行RACH的问题、下行FACH功率配比问题、小区重选参数问题、设备异常问题出现的概率比较高。1) UE发出RRC Connection Request消息,RNC没有收到,如果此时的下行CPICH的Ec/Io不是太低(比如大于-14dB),一般都是RACH的问题,可能是上行的开环功控估计不准或、Preamble的功率攀升不够或者是UE的输出功率比要求值偏低等原因。2) RNC收到UE发的RRC建立请求消息后,下发了RRC Connection Setup消息而

19、UE没有收到。查看此时的CPICH的Ec/Io,如果低于-12dB(因为基线的配置是基于Ec/Io为-12dB配置的),而且检视集中没有质量更好的小区,那么是覆盖的问题可以适当提高FACH的功率。如果此时检视集中有更好的小区,则可能是小区重选的问题,可以适当调整小区重选参数加快小区重选。3) UE收到RRC Connection Setup消息而没有发出Setup Complete消息,如果此时下行的信号质量正常,那么可能是手机异常。否则可能是下行专用信道初始功率过低导致下行不能同步。4) UE发出RRC Setup Complete消息而RNC没有收到,由于上行初始功控会让UE的发射功率上升

20、,这种问题出现出现的概率很小。如果出现这类问题可以适当提高专用信道的Constant Value值。RRC建立问题UE是否发出请求消息RNC是否收到请求消息RNC是否发出建立消息UE是否收到建立消息UE是否发出建立完成消息RNC是否收到建立完成消息手机异常问题调整PRACH或AICH信道参数其他问题调整FACH信道功率调整下行初始发射功率调整上行专用信道开环功控参数是否发生小区重选优化小区重选参数NYNYNYNNYYNYNY图4 RRC连接建立问题分析流程图3.1.2 话统数据分析流程分析话统指标时,要先看RNC RAB建立成功率指标和RRC建立成功率指标,掌握网络运行的整体情况后,再有针对性

21、地对小区性能统计。分析时一般采取过滤法,先找出指标明显异常的小区分析,此时很可能是版本、硬件、传输、天馈或者数据配置出了问题导致的异常,可以结合NodeB和RNC的告警首先从这几个方面检查,同时按小区统计的话统指标里面也包括了一些原因值,比如RRC_REJ_CONG_CELL 表明RRC建立拒绝的原因为"congestion"。如无明显异常,根据指标将各扇区载频进行统计分类,可整理出各重点指标较差小区列表,对于这些小区进一步细分话统指标,比如RRC建立失败看是主叫的原因还是被叫的原因等。然后可以在问题比较严重的小区重点路测重现和解决问题。1.分析RNC话统中和接入

22、相关的指标2.分析基于CELL的和接入相关的话统指标3.检查系统告警是否异常3.1解决设备异常问题4.RRC建立成功率偏低6.RB建立成功率偏低5.RAB建立成功率偏低7.寻呼成功率偏低4.1解决RRC建立失败问题5.1解决RAB建立失败问题6.1解决RB建立失败问题7.1解决寻呼失败问题结束YYYYYNNNNN图5 话统数据分析流程1. 分析RNC话统中和接入相关的指标与接入相关的指标主要包括RRC的建立成功率、RAB的建立成功率、RB的建立成功率以及Page的成功率。这些指标的计算可以参考话统分析指导书。RRC建立成功率和RAB的建立成功率即反映了网络的接通率。通过分析这几个指标了解网络接

23、通率的现状,同时获得是什么业务的什么指标偏低需要提高。2. 分析基于CELL的和接入相关的指标在第1步的基础上再分析按CELL统计的相应指标,可以获得偏低的指标在网络中的小区分布。对于指标特别差的小区重点分析。另外在按CELL统计的指标里面有一些问题原因的统计,比如对应RB建立失败的原因,有按照配置不支持、失败原因为“Configuration Unsupported”、 物理信道故障、“physicalChannelFailur”等原因统计的失败次数。3. 检查系统是否有告警异常检查话统指标明显较差的小区和RNC的告警信息,看是否有有设备异常。4. 分析和解决各指标偏低的问题(需补充)如何通

24、过话统来解决接通率的问题还需要后续积累经验3.1.3 跟踪数据分析流程跟踪数据主要是RNC的单用户跟踪和各个接口的信令跟踪,分析方法可以参考路测数据的分析流程。3.1.4 告警数据分析流程(暂缺)3.1.5 用户投诉分析流程(暂缺)3.2 调整措施3.2.1 工程参数工程参数可调整的不多,主要有天线的方向角、下顷角、天线的波瓣宽度以及天线的增益等。一般来说主要在解决覆盖导致的接入问题的时候会考虑调整这些工程参数。比如覆盖的盲区通过增加站点、提高附近覆盖小区的天线增益或者减小附近小区的天线下顷角等方法。在进行这些调整的时候注意对小区原来的覆盖区域的信号质量的影响。3.2.2 小区参数下面列出了与

25、接入问题相关性比较大的几个参数,在定位接入失败的问题时,可以根据具体原因调整这些参数的设置:1. FACH信道的发射功率该参数定义了FACH的发射功率。该参数设置过小,会使得小区边缘UE不能正确接收FACH承载的业务和信令,影响下行公共信道覆盖,从而最终影响小区覆盖,设置过大,则会对其它信道产生干扰,并且占用下行发射功率,影响小区容量。基线中FACH信道的功率为-1dB是基于覆盖小区边缘CPICH的Ec/Io为-12dB,如果现场的覆盖更差,需要根据边缘的CPICH的Ec/Io的大小相应的提高FACH的功率。2. PCH信道的发射功率该参数定义了PCH的发射功率。该参数设置过小,会使得小区边缘

26、UE无法正确接收寻呼信息,增加寻呼的时延,导致寻呼成功率低,从而影响接入成功率。设置过大则浪费功率,增加了下行干扰。3. PICH信道的发射功率该参数定义了PICH的发射功率。该参数设置过小,会使得小区边缘UE无法正确接收寻呼指示信息,导致呼叫时延增加,也有可能进行读取PCH信道的误操作,浪费UE电池,并影响下行公共信道覆盖,从而最终影响小区覆盖;由于PICH信道是连续发射的,所以设置过大,则会对其它信道产生干扰,并且占用下行发射功率,影响小区容量,所以建议不增加如果为了增加PICH的覆盖可以减小NP值为18。减小NP会减小UU口的寻呼容量,在建网初期NP为18寻呼容量足够,而且18也是业界的

27、典型配置。4. 小区重选参数测量迟滞2(Qhyst2s)根据R准则,当前服务小区测量值加上迟滞后参与小区重选排序。参数值的大小与小区所在地区的慢衰落特性相关。该参数主要防止当UE处于小区边缘时由于慢衰落使得小区重选结果出现乒乓,从而可能导致频繁的位置更新(空闲模式)、URA更新(URA_PCH)或小区更新(CELL_FACH,CELL_PCH)增加网络信令负载,同时也增加了UE的电池损耗。5. 小区重选参数重选迟滞时间Treselections如果其它小区信号质量(UE测量的CPICH Ec/No)在该参数指定的时间内始终优于当前驻留小区的质量,则UE重选该小区作为驻留小区。该参数用于防止UE

28、在小区间的乒乓重选。6. 小区重选参数Sintrasearch同频小区测量的启动门限,当本小区的Ec/Io低于QRelxmin+2*Sintrasearch时启动同频小区测量。该参数影响会影响小区重选的速度,进而影响UE的一次接入成功率和IU口的一次寻呼成功率。在对UE的耗电影响比较小的情况下,建议将该值尽量设大。7. 小区重选参数Qoffset2临小区的信号质量参与R准则评估前需要先减一个偏置即为Qoffset2。对于普通的单层小区,该参数可以设置为0,而通过Qhyst来达到相同的目的。建议一般不做调整。8. AICH信道的发射功率该参数设置过小,会使得小区边缘UE无法正确接收捕获指示,影响

29、下行公共信道覆盖。基线中该参数配置为-6dB,从优化结果来看,AICH的功率在下行的覆盖中一般没有问题,而且该信道是连续发射的,如果提高功率会占用较大的下行容量。9. PRACH的相关参数对应上行PRACH的问题,需要调整PRACH的相应参数,包括preamble的重传次数、preamble的功率攀升步进、preamble和Message和功率偏差等参数。这些参数相互制约,在出现PRACH信道的问题时,建议调整preamble的重传次数,当前基线设置为8,建议设置为20避免PRACH的问题。4 典型接入失败问题分析4.1 寻呼问题4.1.1 寻呼相关信道功率配置不合适和寻呼相关的有PICH和P

30、CH两个信道,当这两个信道的功率配置偏低不能满足UE的解调的要求时,UE不能正确的接收寻呼消息。基线参数中PCH的功率设置为-2dB,PICH的功率设置为-7dB,根据参数优化的结果,这个功率配置可以确保小区信号质量为-12dB的寻呼要求。如果网络的覆盖比-12dB更差,可以考虑提高PCH的功率和减小NP值。在没有UE的路测数据和RNC的单用户跟踪数据的情况下,如果寻呼的指标偏差,可以先分析网络的覆盖情况的分布图,看是否有必要提高这两个信道的功率配比。4.1.2 寻呼时UE进行位置更新这种情况通常发生在UE正在进行3G到2G的重选。当UE重选到2G,还没有完成位置更新时,对此UE的寻呼消息在U

31、MTS网络中下发,UE将收不到。一般3G到2G的重选需要5s的时间,在这5秒中对该UE的寻呼将会失败。当UE的LAC变化也有可能会出现寻呼失败,不过UE重选到目标小区和位置更新的时间比较短,从IU口来看不会出现寻呼失败。4.1.3 UE隐式分离引起寻呼失败UE一般情况下要周期性的进行位置更新,这个时间通常设置为2小时。核心网也有一个定时器,一般该定时器要比周期性位置更新的定时器要长,在定时器设置的时间内没有收到该用户的位置更新就会发起隐式分离,同时会将该用户的呼叫允许标准清除,那么对该用户的寻呼将会失败。出现这种情况可能的原因是:UE长时间处于覆盖的盲点,现在的网络一般是GSM全覆盖,在没有U

32、MTS网络覆盖的情况下将会重选到GSM,所以这种情况的可能性不大。还有一种是误操作比如直接拔掉手机电池或者直接拔掉USIM卡。4.2 小区重选问题4.2.1 现象和分析一个典型的小区重选导致RRC Connection Request重发的现象:图6 UE的信令两次UE重发请求消息之间的时间间隔大概是1.2S。图7 UE第一次发送接入请求时的信号质量图8 UE第二次发送接入请求时的信号质量按照系统基线配置的参数,Treselection为1,Qhyst2为2dB,Qoffset2为0dB,Sintrasearch为5。当目标小区的信号优于本小区的信号时,最快也需要1秒钟才可以重选完成。因此目标

33、小区和本小区的信号变化类似上面描述的现象,那么小区重选参数优化的余地不大。因为Treselection最小只能设置为1。如果设置为0,那么因为我们的DRX最小只能设置为0.64秒,导致相当于重选的时间需要8*DRX,远大于1秒。并且如果Treselection设置为0,那么协议规定目标小区需要比原小区的Ec/Io高3dB。统计多次小区重选的时间大概在1.21.4秒。4.2.2 解决方法为了尽量减少小区重选的时间,曾经将Qhyst2修改为0,SintraSearch修改为7,测试发现在步行测试时会出现乒乓小区重选,而重选的时间没有减小。所以建议Qhyst2保持为2dB不变,而SintraSear

34、ch的设置尽可能的使UE早点启动同频测量。在对UE的功耗影响不大的前提下,建议Sintrasearch设置为7。4.3 RRC建立问题4.3.1 上行接入信道参数设置不合适1. 现象和分析下面是一次接入过程的相关信息:图9 UE的信令图10 RNC的单用户跟踪信令将时间对齐后发现RNC响应的是UE发上来的第二个RRC建立请求消息。此时的下行信号质量参见图11。图11 下行信号质量从图3的信号质量可以看出,此时下行的信号质量很好,上行的信号应该不会很差。为什么上行第一次不能接入呢?后来在Warwick办公室静止测试,问题重现。每次在半个小时内必定回出现,有时出现4次RRC建立请求重传不成功导致C

35、all Fail。对应的分析RNC根据TMSI跟踪的信令,RNC没有收到RRC Connection Request消息。这个小区的信号强度:RSCP为-60-70dBm,Ec/No为-2-4dB。根据先前的干扰分析,在该小区存在有规律的干扰参见下图:图12 248号小区有规律的干扰图13 干扰局部放大图注:每个干扰的持续时间大概在40秒左右,图4最后一个尖峰不是和前面一样的周期性干扰。只持续了很短的时间(一个样点)。干扰在早上8:00到晚上9:00中,其他的时间没有干扰。开始怀疑是干扰导致的问题。采样数据,结合RNC的消息、UE的消息以及记录的RTWP,发现在出现Call Fail时(UE发

36、了4次RRC建立请求)在前后1分钟内都没有干扰。所以这个问题可能和干扰还没有关系。做了以下的测试来定位问题的原因1、采用高通手机(6200)进行了测试,在1个多小时的呼叫中,没有出现一次类似的现象。在这个期间干扰依然存在。这说明高通的测试手机没有问题。2、为了排除AICH的问题,将AICH的功率提高到0dB,测试moto手机,还是有问题。即问题的出现与AICH功率大小没有关系。3、将AICH的功率恢复到-7dB,将Preamble的重传次数从8提高为20次。测试了1个多小时,问题没有出现。4、由于是在室内静止测试,信号很稳定,并且信号很强,Ec/Io为-3左右,RSCP为-50dBm左右。怀疑

37、是否是在信号很好的地方MOTO的功率估计有问题,通过加下行负载将下行的Ec/Io降低到-7dB左右,问题依旧。5、为了进一步确定不是干扰导致的问题,在晚上10点以后测试,这个时候从RTWP来看没有干扰,测试了1个多小时还是出现了4次重发Request的现象,另外还有两次Call Fail。通过UE的系统消息和NodeB的干扰记录对比分析,干扰确实及时更新了。有Request重传的时间段里,前后系统消息里的干扰水平都没变(-105dB)。这进一步说明moto Request重传问题与外部干扰无关。通过以上的测试可以得到这样的结论:该问题和上行干扰没有关系,和AICH的功率配置也没有关系。由于高通

38、手机6200也没有问题,说明是MOTO上行RACH信道的问题。2. 解决方法修改Preamble的重传次数在pilot网中测试,没有再出现这种问题。4.3.2 AICH信道功率设置不合适AICH信道的功率配比直接影响UE对AI的解调,如果这个功率偏低会导致UE解调AI误码,将不能完成接入的过程。AICH的功率较早前设置为-12dB,这类问题比较多。现在的基线配置-6dB,完全可以满足已知的MOTO、高通、NEC等手机的AICH在Ec/Io为-12dB情况下的解调。不过AICH的解调性能不同品牌的UE差别较大,对于没有测试过的UE在出现PRACH的问题时需要关注AICH的功率配比。4.3.3 F

39、ACH信道功率设置不合适1. 现象和分析图6是UE的信令。图14 UE的信令以下是驻留小区和监测小区的信号强度:图15 第一次发起接入请求时的信号强度说明:第二列是驻留小区的信号强度,第3列是驻留小区的扰码,第四、五列是最好的监视小区的信号强度和扰码号。两个小区的信号一直在波动。图16 RNC的单用户跟踪信令由于下行覆盖比较差,这一次UE发起了接入请求,RNC收到了RRC建立请求消息并且下发了RRC建立消息,但下行的信号比较差,UE没有收到。2秒钟后UE发起第二次接入时候的信令和信号强度:图17 第一次发起接入请求时的信号强度UE第二次发起接入请求的时候,下行信号的强度在-13dB左右,接入成

40、功。可以看出当下行信号Ec/Io低于-12dB以后不能保证下行FACH的正确接收。当前的FACH的功率配比是-1dB,这个配比值是在外场测试出FACH的Ec/No和功率配比值的关系曲线后假设小区边缘的Ec/Io为-12dB的情况下给出的。为了提高FACH在-14dB情况下的接收成功率,同时结合我们异系统测量的启动测量门限,建议将FACH的功率配比提高2dB。2. 解决方法修改FACH的功率配比为+1dB后测试,在KPI测试路线上没有发现UE下行接收不到RRC Setup消息导致接入失败的问题。4.3.4 下行专用信道初始功率配置不合适下行的初始发射功率有RNC根据当前的Ec/Io计算获得,并且

41、在上下行已经同步进行内环功控前,初始发射功率维持不变。所以如果这个功率计算的偏小的话会导致UE下行不能同步导致RRC建立失败。当出现UE收到RRC Connection Setup消息而没有发RRC Connection Setup Complete消息时,可以查看UE发射接入请求时的Ec/Io和下行的码域发射功率来确认是否是下行初始发射功率的问题。当前RNC计算的初始功率发射功率大部分情况来说是偏高的,所以出现这类问题的概率较小。4.4 RAB和RB建立问题4.4.1 RNC直接拒绝RAB的建立请求参数设置非法导致RNC直接回应RAB建立失败在商用网络的发生概率很小,一般是由特殊用户的特殊操

42、作造成的。主要场景是:用户PS业务的上行开户和激活申请信息超过了手机的能力,导致RNC直接回应拒绝。例如:某特殊用户的开户能力是上下行384K,而其使用的手机上行最大能力只是64K,在用户使用AT命令或者手机终端软件(索爱手机终端软件可以任意设置激活申请的QoS)设置激活PDP的QoS信息中上下行最大速率均为384K,这样在RNC收到RAB指派请求时,发现请求的上行最大速率超过了UE的能力,将直接返回RAB建立失败,不发起RB建立过程。由于参数设置错误超过UE能力的情况造成的RAB建立失败后,SGSN会重新协商发起新的RAB指派,直到UE能力可以支持,最终完成RAB指派,对于用户来说,这次PD

43、P激活仍然可以成功,指示获得的最大速率为UE能力所能支持的最大速率。但是,如果UE的PDP激活请求中QoS设置要求的最小保证速率都超过了UE的能力,那么虽然网络协商了较低的速率接受UE的PDP激活请求,但是当UE发现PDP激活接受消息中网络协商的速率小于其最小保证速率时,会发起去激活PDP请求,最终无法完成PDP激活。4.4.2 IUB口准入拒绝这类问题在香港的网络出现比较频繁,在pilot网中有很多小区的IUB用于业务的AAL2的带宽只能支持一个384k的业务,如果已经存在一个12.2k的语音业务,再激活PS384k业务,则IUB口会因为带宽受限拒绝。表现为RAB assignment Re

44、sponse原因为申请速率不可获得,然后SGSN会重选协商发起RAB指配。在话统里面表现为一次RAB建立失败。在基于CELL的话统中有区分不同失败原因的RAB建立失败的统计,通过这些指标可以初步获得RAB建立失败的原因。4.4.3 UE回应RB建立失败造成的RAB建立失败UE回应RB建立失败主要是由于用户的错误行为造成。第一种情况是,用户在已经有下行128K的数据业务时,收到了VP业务的RB建立请求(VP主叫或者被叫),由于大部分终端不支持下行同时进行VP和高速(大于等于64K)PS业务,UE直接回应RB建立失败,原因是unsupported configuration。另一种情况是主叫3G终

45、端进行VP业务的被叫方驻留在GSM网络,不支持VP业务,这样在RNC收到RAB指派请求后,核心网Call Proceeding后立刻下发Disconnect命令(原因为Bearer capability not authorized),而此时UE在刚收到RB_SETUP命令,还没来得及完成RB建立,收到该Disconnect后会马上发起回应RB建立失败,RNC返回RAB建立失败,原因为failure in radio interface procudure。索爱Z1010终端经过测试可以稳定支持VP和PS128K的多RAB建立,Moto终端则不支持,会直接回应RB建立失败,更多的终端和更新版本

46、的终端能力还需要不断验证确认。现在对于用户这些行为造成的RAB建立失败,在RNC B03D205版本的KPI统计中,只能通过PS(/CS)_RAB_SETUP_FAIL_PARAM_CELL来反映,不够直观,在后续的KPI版本统计中应该针对这样的情况有更明确具体的话统点,明确用户要求QoS高于签约情况的话统点、UE自身判断能力不足的话统点和被叫能力不足的话统点,通过这些话统点的指标可以更客观分析网络的质量。4.4.4 空中接口RB建立失败造成的RAB建立失败另一种RB建立失败是RB建立命令没有响应,导致RNC认为RB建立失败。商用网络中出现最多的是这种由于空中接口信号质量不好导致的RB建立失败

47、。在过程上表现为RB建立命令没有收到ACK或者没有收到RB建立完成命令。这样的情形主要出现在弱信号区,造成信号弱的原因有两种情况,一种是UE没有驻留在最优小区发起接入,另一种是覆盖不好。UE没有驻留在最优小区发起接入,会在RB建立过程中希望活动集更新加入最优小区(同时信号快速变化导致驻留小区信号快速下降),但是由于流程不能嵌套进行(网络和终端都不支持),活动集更新只能等待RB建立完成后进行,导致RB建立过程在弱信号小区进行,容易出现失败。对于这种情况需要提高同频小区重选的启动门限和速度,使得UE尽快驻留在最优小区,在最优小区发起接入,对于初期负载比较低的网络,UE同频小区重选启动门限可以设置为

48、-4dB,Treselction为1,对于不同LAC边界的小区,这些参数可以设置的低一些,减少位置更新和小区更新的信令流量。覆盖不好造成的RB建立失败分为上行和下行质量不满足两种情况。下行覆盖引起的情况表现为UE无法收到RB建立命令,下行覆盖质量不满足部分原因是UE的解调性能不佳造成,部分原因是需要RF优化来解决的。上行覆盖引起的情况表现为UE收到了RB建立命令,但是RAN收不到RB建立的ACK,这种情况往往是由于上行信令阶段的外环功控性能不够好所致,可以通过提高初始上行SIRtarget的方法来避免,在现阶段的商用网络中上行初始SIRtarget可以设置为较高的5dB,在提高上行信令处理性能

49、的同时对于网络上行容量基本没有影响。4.5 信令流程没有完成出现切换失败4.5.1 现象和分析UE在RRC建立完成到RAB指派之间或RB建立完成之后都有可能进行切换。如果在这个期间切换失败会给用户带来感观上的接入失败。参见下面的一个例子,在Anylze软件里表现为一次接入失败。图18 UE的信令相对应的RNC记录的单用户跟踪:图19 RNC的单用户跟踪此时的小区的信号强度:图20 断链前的信号强度从RNC的信令可以看出来121号小区信号很快的变差了,此时要加入56号小区,但是RNC下发的ActiveSet Update消息UE已经接收不到。4.5.2 解决方法此类问题的解决方法,主要是调整软切

50、换的参数,使得目标小区尽早的加入。具体可以参考掉话分析指导数。4.6 鉴权问题4.6.1 失败原因是MAC Failure1. 问题描述和分析此问题一般在刚开始使用新卡时经常出现,主要原因是没有将USIM卡和HLR中给该用户设置相同的Ki和OP(OPc)导致鉴权失败,原因值为Mac Failure。定位方法:检查开户信息中的该IMSI的Ki值和OP(OPc)值是否相同。2. 解决方法因为USIM卡中已经有默认的Ki和OP(OPc),但通过读卡器无法读出此值,所以开户时预先清楚此USIM卡的Ki和OP(OPc)或重新将USIM卡的Ki和OPc值烧成与HLR中相同的值。4.6.2 同步失败(syn

51、c failure)1. 问题描述和分析USIM认为从VLR/SGSN收到的SQN不满足要求,返回同步失败,由于HLR内部处理机制的问题,进行鉴权计算的进程不能区分CS域鉴权请求和PS域鉴权请求,所以无法分别分配CS和PS的SQN的Index值,导致在CS域和PS域交叉进行时USIM卡会覆盖原来的PS域或CS域的SQN值,结果偶尔会出现同步失败。2. 解决方法同步失败后会再进行一次鉴权,此时因为根据USIM卡中保存的SQN值重新取了鉴权集,所以不会同时出现两次失败情况。HLR计划在V62版本中解决此问题。4.7 加密问题4.7.1 问题描述和分析手机不支持配置的加密算法、RNC和核心网加密模式

52、配置不匹配,如:MSC只配置了加密算法UEA0,而RNC只设置为支持UEA1,此时Iu接口会出现加密模式拒绝。在RRC Connect Setup CMP消息中看手机上报的能力是否支持。目前不支持加密的终端有:NEC 单模手机,NEC C606,NEC C616支持的终端有:Nokia 7600,Nokia 6650,Moto A835,高通6200,高通6250,西门子U15查看MSC或SGSN跟RNC选择的加密模式是不是匹配,即MSC或SGSN支持的加密模式和RNC支持的加密模式必须要有相同的。4.7.2 解决方法更换手机或网络侧选择非加密模式,MSC和SGSN可以选择全部的加密模式,RNC根据

温馨提示

  • 1. 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。图纸软件为CAD,CAXA,PROE,UG,SolidWorks等.压缩文件请下载最新的WinRAR软件解压。
  • 2. 本站的文档不包含任何第三方提供的附件图纸等,如果需要附件,请联系上传者。文件的所有权益归上传用户所有。
  • 3. 本站RAR压缩包中若带图纸,网页内容里面会有图纸预览,若没有图纸预览就没有图纸。
  • 4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
  • 5. 人人文库网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对用户上传分享的文档内容本身不做任何修改或编辑,并不能对任何下载内容负责。
  • 6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
  • 7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

评论

0/150

提交评论