TD-LTE网络优化指导书-掉话优化

TD-LTE网络优化指导书掉话优化2013-08公布 2013-09实施大唐移动通信设备 发布名目TOC\o“1-2“\h\z\u\l“_TOC_250021“引言 3\l“_TOC_250020“根底学问 3\l“_TOC_250019““连接”与“掉话”的概念 3\l“_TOC_250018“正常的连接释放 4\l“_TOC_250017“特别的连接释放〔掉话〕 5\l“_TOC_250016“3DT/CQT常见掉话缘由分析 7\l“_TOC_250015“弱掩盖 7\l“_TOC_250014“切换失败 8\l“_TOC_250013“邻区漏配 10\l“_TOC_250012“越区掩盖 11\l“_TOC_250011“系统设备特别 13\l“_TOC_250010“3.6干扰 14\l“_TOC_250009“3.7拥塞 16\l“_TOC_250008“话务统计掉话数据分析 17\l“_TOC_250007“掉话相关的KPI 17\l“_TOC_250006“全局掉话率偏高问题分析〔TopN〕 18\l“_TOC_250005“小区〔簇〕掉话率偏高问题分析 19\l“_TOC_250004“掉话问题的分析流程 20\l“_TOC_250003“典型掉话案例分析 21\l“_TOC_250002“弱掩盖导致的掉话 21\l“_TOC_250001“切换失败导致的掉话 21\l“_TOC_250000“邻区漏配导致的掉话 22引言编写本文的目的：整理了与TD-LTE系统中与保持性〔掉话〕相关的根本概念、信令流程、所涉及的参数。指导TD-LTE网络维护、优化过程中，与掉话相关的问题分析和定位〔解决〕。根底学问学问点：12UE、eNodeB的操作“连接”与“掉话”的概念本文所提及的“保持性”，指的是“连接”的“保持性”，更狭义地，是指“RRC连接”的“保持性”。因此，本文所称的“掉话”，具体是指UE特别退出RRC_CONNECTED状态导致的连接中断。图0-1 NAS和AS的几种状态1、关机 附着

2/

连接到EPC

3、激活移动性治理〔EMM〕连接治理〔ECM〕

(Attaching) 登记已撤销(Deregistered)空闲〔IDLE)

(Active)(Registered)连接(Connected)无线资源掌握〔RRC〕 空闲(Idle)

连接 空闲(Idle)(Connected)

(Connected)上图给出了从开机到进入激活〔数据传输〕状态过程中，从不同角度来看的“状态”的变化情况。从EPSEMUE状态，直至UE发起、并成功登记。EPS连接治理〔ECM〕来说，只有在激活态时，UEEPS是连接的，其余时间，UE处于和EPS的空闲状态。对于RRC来说，只要UE和网络侧〔空口、EPS〕有连接，即为RRC的连接状态。ECM_Idle态转到ECM_Connected态，不仅涉及RRC连接建立、还涉及到S1连接建立。RRCNASS1连接建立完成。RRC_Connected态的连接仅限于UE和E-UTRAN的掌握信息的交互。RRC连接的释放由eNB发起、紧随S1连接释放之后。RRC_ConnectedOMC统计数据分析力量的限制，本文临时只考虑上图中RRC_Connected状态〔激活态〕、暂不考虑附着过程中的连接状态。通常将在附着过程中发生的RRC连接中断归为“接入失败”进展分析；本文所分析的“掉话”、仅限于RRC_Connected状态下的连接特别中断。学问点：掉话的定义本文所称的“掉话”，具体是指UE特别退出RRC_CONNECTED状态导致的连接中断。正常的连接释放在了解“掉话”之前，需要先了解正常的“通话完毕”〔即“连接释放”〕的过程。RRC连接释放流程如以下图所示〔36.3315.3.8小节RRCConnectionRelease〕。UEEUTRANRRCConnectionRelease图0-2 RRCUEEUTRANRRCConnectionReleaseUERRCConnectionRelease之后，应当：1、从收到RRCConnectionRelease〔或者下层指示收到RRCConnectionRelease消息〕起，将以下60ms；2、假设RRCConnectionRelease消息中包含idleModeMobilityControlInfo，存储其中的小区重选优先级信息；假设消息中包含t320，启动该T320定时器〔并将定时器取值为t320〕；假设没有包含idleModeMobilityControlInfo，UE使用系统信息中播送的小区重选优先级信息。3、假设RRCConnectionRelease消息中的releaseCause为loadBalancingTAURequired，UE将在离开RRC_CONNECTEDreleaseCause为loadBalancingTAURequired；假设releaseCause为otheRRC_CONNECTEDreleaseCause为other。UE在离开RRC_CONNECTED时执行的操作：1MAC；2、停顿除T320以外的全部定时器；3、释放全部无线资源，包括释放全部已建立的RB的RLC实体、MAC配置和相关的PDCP实体；4、告知上层RRC连接释放〔releaseCause〕；5MobilityFromEUTRACommand消息而触发的离开RRC_CONNECTED状态，UE将〔依据离开RRC_CONNECTED的缘由〕通过执行小区重选过程进入RRC_IDLE，具体TS36.304[4].通常状况下，以下情形会触发EUTRAN下发RRCConnectionRelease消息：1UE发起Detach之后；2TAU之后3loadBalancingTAURequired之后特别的连接释放〔掉话〕结合常见的掉话类型，从信令上来看，有以下几种表达：1图0-3 常见掉话的信令表现〔1〕——重建立失败导致的掉话首先是UE在UL-CCCH上发送“rrcConnectionReestablishmentRequest; Cause=otherFailure”；eNBDL-CCCH上回复“rrcConnectionReestablishmentReject”；随后UE发生掉话、开头接收系统播送消息〔BCCH-SCH上的SIB1〕、直至UE发起下一次呼叫。2UE在没有收到Release消息的状况下，直接从RRC-CONNECTED状态转到RRC-IDLE。此类掉话的一个典型UE发起了RRCConnectionReestablishmentRequeseNodeB发来的RRCConnectionReestablishment，而且UE也没有发出RRCConnectionReestablishmentComplete消息。图0-4 常见掉话的信令表现〔2〕——空口信号变差等缘由导致的掉话3、狭义上来讲，可以认为“只要UERRC重建立，就意味着RRC连接已断、即产生了掉话”。在实际工程中，还会遇到这种状况：由于切换失败或其他缘由导致的RRCRRC这种RRC重建立是否算作掉话，需要特别关注、在必要时需要和客户达成全都意见。留意:工程执行过程中，需要明确“掉话”的具体定义图0-5 常见掉话的信令表现〔3〕——其他缘由导致的RRC留意:工程执行过程中，需要明确“掉话”的具体定义在实际工程中，通常需要与客户就掉话的定义达成共识。考虑到实际用户的应用是以数据业务为主，因此工程组与客户协商、达成共识：只要重建立时间在100ms之内〔即从UE发起RRCConnectionReestablishmentRequest，到UE 回复RRCConnectionReestablishmentComplete的时间间隔小于100ms1〕，都不计入掉话。〔注：这仅仅是统计方法上的定义〕3DT/CQT弱掩盖现象现象由于弱掩盖导致的掉话，通常有以下表现：RSRP持续变差〔低于弱掩盖标准2-105dBm〕、同时效劳小区的SINR也一起持续变差〔小于-5dB，甚至更低〕；掉话后可能会有一段时间〔数秒至数分钟不等，取决于实际网络掩盖状况〕UE报〔类似于UE脱网〕。图0-1 弱掩盖导致的掉话示意图ServServingCellCINRDropServingCellRSRP20100-10-70-90-110-130分析方法分析方法承受路测数据分析法。步骤1、采集到相关路测数据，用路测数据分析软件OUTUM进展分析；2、定位到掉话时间点的数据，通过查看地理化显示的图层〔效劳小区RSRP、SINR〕确认以下特征：掉话时，UE测得的效劳小区RSRP低〔如：<-105dBm〕；掉话时，UE测得的效劳小区SINR低〔如：<0dB〕掉话时，UE没有测到〔上报〕其他〔如：强度>-105dBm的〕邻区信号。解决方案解决方案总的来说，要解决此类掉话，需要改善掩盖，具体的操作步骤和手段有：首先明确当前的弱掩盖区域由哪些扇区的信号掩盖；依据网络拓扑构造和相关无线环境来确定最适合掩盖该区域的扇区、并加强它的掩盖：排解主掩盖小区的硬件故障〔例如：基带及射频器件故障、天馈系统驻波比告警等〕上调主掩盖小区的RS功率上调主掩盖扇区的功率调整主掩盖扇区的天线下倾角调整住掩盖扇区的天线方位角建议加站〔并调整周边基站天线的方位角和下倾角〕开启SON-CCO〔Coverage&CapacityOptimization〕功能〔待实现〕切换失败现象现象由于切换失败导致的掉话，通常有以下表现：首先，在掉话前UE 曾发出Measurement Report、并能收到eNB 发来的RRCConnectionReconfiguration；但是UE 收取目标小区的播送消息之后、马上上报“RRC 连接重建立恳求”〔rrcConnectionReestablishmentRequest; Cause=handoverFailure〕；通常UE在切换失败后，都会发起回到源小区的“RRC连接重建立恳求”、并且此类RRC连接重建立成功率大局部都是成功的、此类重建立通常也会在100ms内完成。图0-2 信令〔由于切换失败导致的掉话〕分析方法分析方法承受信令分析法。步骤1、猎取采集到的掉话数据，使用路测数据分析软件OUTUM进展分析；2、翻开路测数据的信令，定位到掉话时间点，确认以下几个特征：掉话前UE曾发起MeasurementReport消息；UE能够收到eNB发来的带有MobilityControlInfoRRCUE切换到“RRCBCCH-SCH上接收到播送消息〔systemInformationBlockType1〕；UE收完播送消息后、发起“RRC连接重建立〔缘由为切换失败〕”；通常UE能够在较短时间〔200ms〕内重建立成功、回到切换前的源小区。3、进一步分析以下内容：MR消息和RRC连接重配置消息中所提及的目标小区的PCI，确认该PCI所指小区；分析UE在的目标小区接收到的播送消息，确认该小区是否就是MR消息上报的小区，用以排解邻区错配的状况；OMC中确认邻区配置,检查邻区参数是否正确；OMC中的切换类型〔X2、S1〕；确认目标小区的工作状态〔小区的功率输出、小区负荷〕、排解由于目标小区工作特别导致的切换失败；确认源小区和目标小区的切换参数〔TTT和迟滞等〕配置与其他正常小区的一样。解决方案步骤4、假设上述分析无法得到明确结论，需要进一步确认该小区的切换成功率，假设该目标小区的切换成功率偏低，初步定为为基站故障〔或者系统版本问题〕，需要进一步将问题反响给前方技术支持。解决方案总的来说，解决此类掉话有以下方法：检查源小区的邻区配置状况，确认邻区参数配置正确；确认目标小区的工作状态正常〔包括传输无误码、功率输出正常、小区负荷不会导致拒绝切入〕确认源小区和目标小区的软件版本是否正确；〔是否配置了X2率是否低？周边是否有开站点？是否处于不同的MME边缘？是否处于不同频率的基站交界处？〕当无法定位问题时，需要总结规律、将归纳后的信息反响给前方技术支持、以便提交系统开发人员作问题的最终定位。邻区漏配现象现象由于邻区漏配导致的掉话，通常有以下现象：掉话前、后的下行掩盖不差〔通常大于-105dBm〕；掉话前、后效劳小区的SINR变差〔由于受到邻区信号的干扰〕；〔关键点〕掉话前UE〔可能会屡次〕上报测量报告〔MR〕、并且MR中上报的PCI，并没有配置在当前效劳小区的邻区列表之中；掉话后UE通常会发起小区重选、并重选到一个的小区。图0-3 邻区漏配导致的掉话示意图ServServingCellCINRN1CINRDropServingCellRSRPN1RSRP20100-10-70-90-110-130分析方法分析方法承受信令分析法。步骤1、猎取采集到的掉话数据，使用路测数据分析软件OUTUM进展分析；2、翻开路测数据的信令，定位到掉话时间点，确认以下几个特征：掉话前效劳小区的RSRP持续下降；掉话前，UE〔连续〕上报MR消息；〔目的是：确认邻区信号足够强、是由于邻区漏配导致的效劳小区信号变差、最终导致掉话〕MR消息中UE上报有符合A3〔A5，取决于系统设置〕大事的目标邻区；在当前效劳小区下发的系统〔邻区〕消息中，并没有包含MR消息中UE上报的目标邻区；UE上报MR后，没有收到eNB发来的用于指示切换的重配置消息。步骤3、通过基站信息表〔或者OMC导出的基站配置表〕MR消息中上报的不在邻区中的PCI归属〔即目标小区〕；步骤4、在掉话前的效劳小区的邻区列表中添加相应的目标邻区。解决方案解决方案通过OMC〔可以使用界面供给的配置工具、或者批量导入功能〕，在掉话前的效劳小区列表中，添加漏配的邻区。开启ANR功能，完善邻区配置。〔待验证〕越区掩盖现象现象在支持切换的移动通信网络中，由于无法准确掌握无线信号的传播，因此或多或少都会存在越区掩盖的状况。而由于越区掩盖导致的掉话，通常表现为：频污染”——在掩盖区内，没有稳定的强信号作为主效劳小区。效劳小区信号的频繁变化，是导致掉话的一个主要缘由。越区掩盖对主效劳小区的干扰〔包括邻区漏配、越区信号的快速变化等〕：在某些区域，主效劳小区受到越区信号的干扰、最终导致掉话。一方面是由于越区信号的消灭，超出了网络规划设计的预期，初始设计的邻区列表没有加上越区掩盖的小区；另一方面，在某些区域，越区掩盖的小区信号并不稳定，即使配置了邻区，也可能会消灭由于越区信号的不稳定而无法准时参加邻区的状况。图0-4 越区掩盖造成导频污染、并导致掉话示意图ServingServingCellCINRDropServingCellCINRDropN1CINRServingCell1RSRPServingCell2RSRPCell2RSRPServingCell1RSRP20100-10-70-90-110-130分析方法分析方法路测数据分析法。步骤1、猎取采集到的掉话数据，使用路测数据分析软件OUTUM进展分析；2、翻开路测数据的信令，定位到掉话时间点，确认以下特征：发生掉话的区域，效劳小区或者搜寻到的邻区信号中有越区掩盖信号〔跨3“层”或以上的小区〕判定掉话区域是否为“导频污染区”〔掩盖该区域、RSRP>-110dBm的3个，通常信号的SINR<0dB〕判定是否存在邻区漏配：检查掩盖该区域的小区邻区列表、是否包含了越区掩盖的小区解决方案步骤3、确认了存在越区掩盖、以及越区掩盖的具体影响之后，进一步明确掩盖掉话区域的主效劳小区、并通过RF优化、邻区优化等手段，掌握越区掩盖信号。解决方案越区掩盖的一般优化原则是：在区域中已有合理的稳定信号掩盖的状况下、尽可能地掌握越区掩盖的信号：下调越区掩盖信号的功率增加越区掩盖扇区的天线下倾角在考虑了越区掩盖扇区周边的掩盖状况、以及网络拓扑构造的状况下，慎重地调整越区掩盖扇区的天线方位角假设越区掩盖导致了导频污染，依据网络拓扑构造和相关无线环境来确定最适合掩盖该区域的扇区、并加强它的掩盖：上调主掩盖扇区的功率调整主掩盖扇区的天线下倾角调整主掩盖扇区的天线方位角掌握其他污染信号对该地区的掩盖假设越区掩盖未导致导频污染、只是由于邻区漏配而导致掉话，则只需要在掉话区域相关小区的邻区列表中添加越区掩盖小区即可。系统设备特别现象现象并排解了无线环境〔信号〕的影响之后，掉话问题照旧存在，这时可以将问题考虑为系统设备〔可能是硬件或软件〕特别。切换流程特别〔在切换区、无法正常完成切换、而导致掉话〕在业务进展到相对固定的一段时间内、发生掉话〔并且可复现〕在特定某〔几〕个扇区、eNodeB下，发生可复现的掉话MME、或者跨TA等，在特别区域进展业务时，发生可复现的掉话分析方法分析方法路测数据和OMC统计数据结合分析法。步骤1、采集掉话区域的路测数据和OMC性能统计数据；2、分析发生掉话前后的数据，包括：当时的无线环境〔可借助GoogleEarth来查看〕〔确定不是由于建筑物阻挡、拐角等环境因素导致的弱掩盖、快衰落、阴影衰落等〕当时主效劳小区和邻区的RSRP、SINR〔确认当时的信号掩盖状况〕邻区配置状况〔确认邻区都已配置〕小区对的切换、掉话次数统计〔确认该扇区的切换是否都失败、掉话率是否偏高〕掉话时，业务停留在什么地方〔例如：在切换过程中掉话、需要确认切换流程进展到哪个步骤了〕步骤3、排解掉话缘由〔无线环境、无线弱掩盖和导频污染、邻区漏配等〕之后，需要进一步查找掉话的规律性，包括查看：〔几〔MME的边界站点等特征〕的扇区、eNodeB？掉话是否集中在某种类型的切换上〔例如经由X2口的切换〕？掉话是否在某次版本升级之后？解决方案解决方案问题缘由定位为系统设备特别之后，需要将问题转交系统开发工程师、并协作抓取进一步分析问题所需的数据、跟踪问题的进展并最终验证该问题得到妥当解决。干扰现象现象依据干扰的来源、种类、工作频段等特性，我们可以将干扰分为：外部干扰、内部干扰带外干扰、带内干扰窄带干扰、宽带干扰长时干扰、瞬时干扰上行干扰、下行干扰由于干扰分类依据较多，为了便于识别，本文着重从上、下行干扰的角度进展分析。系统中存在干扰，会有以下表象：上行干扰：当只有上行链路受到干扰的时候，可能下行链路并无特别表现；当上行链路受到干扰的时候，UE的放射功率通常较高〔接近UE最大放射功率〕、而且基站侧测得的RSSI偏高下行干扰：当只有下行链路受到干扰时，可能上行链路并无特别表现；当下行链路受到干扰的时候，UE测得的RSRP较好、但是SINR偏差。图0-5 上行干扰导致掉话示意图Interference(Uplink)UEUETxPowerDropServingCellCINReNodeBRSSIServingCellRSRP100-10-70-90-110-130图0-6 下行干扰导致掉话示意图ServingCellServingCellandNeighborCellCINRDropServingCell&NeighborCellRSRP20100-10-70-90-110-130分析方法分析方法路测数据+OMC动态数据分析法。步骤1、采集掉话时的路测数据、后台动态观看〔RSSI〕数据。步骤2、推断掉话时的数据特征：基站侧测得的RSSI是否偏高〔如：-85dBm以上〕，假设偏高，说明存在上行干扰；掩盖区域，则说明存在上行干扰；假设UE〔甚至包括邻区RSRP较好〔-90dBm甚至更好〕、而此时的SINR较差〔<0dB〕，则说明此时可能存在下行干扰。步骤3、定位了干扰的大致类型，实行相应的解决方法进展处理。解决方案解决方案对于上行干扰的进一步确认和排查：明确干扰所涉及的范围〔看路测数据,明确有哪些小区存在此类现象、查看这些小区是否成片分布〕、大致定位干扰区域使用频谱扫描仪〔如YBT250等〕+八木天线进展扫频、以便进一步定位干扰源对于下行干扰的进一步确认和排查：首先确认下行干扰并非系统内部干扰〔需要排解越区掩盖、邻区漏配导致的“干扰”现象〕+八木天线进展扫频、以定位具体的干扰源。当确认存在有干扰的状况时，可以实行以下方法进展去除或躲避：确认干扰源、请客户帮助协调去除干扰源假设干扰来自其他系统，需要增加我方和其他系统的天线隔离度〔水平隔离、垂直隔离度〕、或者在干扰源上加装信号屏蔽装置防止信号泄漏带来的干扰变更我方系统的工作频点或者带宽、避开干扰开启ICIC功能、并优化相关参数〔待验证〕拥塞现象现象当系统资源缺乏、而用户数较多时，简洁消灭拥塞，现象包括：小区实时激活用户数较多小区开头消灭接纳拒绝小区的放射功率接近饱和小区的呼叫建立成功率、掉话率指标恶化分析方法分析方法OMC性能统计数据分析法。步骤1、采集忙时OMC性能统计数据〔包括呼叫、切换和释放数据〕；步骤2、查看掉话时小区的用户数、话务量等状况，确认小区处于高负荷状态；步骤3、查看小区的呼叫建立成功率、切换成功率和掉话率、以及相应的失败缘由；步骤4、当消灭由于小区资源缺乏而导致接纳拒绝的状况时，可以判定为系统消灭拥塞。解决方案解决方案解决拥塞的方法，从两个大方面入手：增加系统容量增加小区功率容量压缩开销信道的功率、RB资源功率掌握〔安排〕相关参数的优化增加基站、扇区、频点〔带宽〕转变网络拓扑构造、均衡话务负荷〔放射功率〕，使得基站只效劳距离较近的用户、减小单用户下行功率开支改善话务热点的拓扑构造〔调整扇区天线方位角〕，开启SON-CCO功能、及优化相关参数〔待实现〕话务统计掉话数据分析KPIRRC连接特别掉话率=RRC/RRC连接建立成功次数X100%E-RAB掉话率=E-RAB/E-RAB建立成功次数X100%E-RAB掉话率〔按QCI统计〕E-RAB特别释放次数〔按QCI统计，QCI1-9〕/E-RAB建立成功次数〔按QCI统计，QCI1-9〕X100%激活E-RAB掉话率=E-RAB特别释放次数/E-RAB建立成功次数X100%全局掉话率偏高问题分析〔TopN〕现象现象全局〔整网〕掉话率偏高，通常会在网络建设初期、或者网络重大操作〔割接、拆分、升级〕期间消灭，表现如下：全局〔大面积基站、小区〕掉话率偏高往往会伴随全局〔大面积基站、小区〕的切换成功率和呼叫建立成功率偏低分析方法分析方法全局掉话率指标偏高的问题定位，通常可以通过OMC统计指标来找到一些规律，可能的缘由有：全网掩盖受限、或者存在大量越区掩盖的状况全网邻区漏配、错配状况严峻全网切换参数〔包括切换门限、迟滞、TTT、层三滤波系数等〕配置有误X2口配置有误〔X2口切换失败率偏高〕系统中存在干扰与其他设备商的业务区交界系统版本有故障某些时段用户数少、OMC性能数据不具备统计意义在具体分析的时候，通常实行OMC性能统计数据分析法。步骤1、采集OMC在一段时间〔含系统忙时〕内的切换、掉话、呼叫统计数据；步骤２、分析系统忙时的掉话率指标、找出掉话率排名Top N的小区；步骤3、将掉话率TopN小区进展分簇，依据本小节、0小节的内容进展分析。解决方案解决方案针对上述不同缘由，实行相应的解决方法：0、0小节。邻区及切换参数相关：具体优化手段见0、0小节。0小节。0小节。假设是存在与其他设备商的业务区有交界的状况，可以考虑掌握掩盖、躲避干扰的方法0、0小节。小区〔簇〕掉话率偏高问题分析现象现象〔簇〕扇区、基站的掉话率偏高〔TopN小区〕，表现为：个别扇区、基站〔簇〕掉话率偏高问题基站与周边基站的切换成功率偏低〔往往表现为单向切换成功率偏低〕分析方法分析方法OMC性能统计数据分析法。30〔簇TopN小区〔基站〕的以下特征〔的规律性〕：掉话率偏高的小区〔基站〕是否开站点？或该小区〔基站〕周边有开站点？〔需要检查该站及周边站点的邻区、切换参数〕掉话率偏高的基站工作是否正常？〔有无告警、功率输出是否正常、基站运行的软件版本是否正确？〕掉话率偏高的扇区，天馈系统是否正常？〔天线有无接反？有无驻波比告警？天线的增益、方位角和俯仰角是否与规划、实际地形相符？〕掉话率偏高的基站，周边的无线环境如何？〔有无阻挡、拐角、干扰？〕掉话率偏高的小区，切换、功控等参数是否正确？掉话率偏高的小区资源是否足够？解决方案解决方案0小节提到的解决方案。掉话问题的分析流程掉话问题分析流程1、通过OMC告警治理模块，判定eNB工作是否正常2、通过路测觉察问题、上站检查硬件掉话问题分析流程1、通过OMC告警治理模块，判定eNB工作是否正常2、通过路测觉察问题、上站检查硬件3、通过OMC版本治理模块检查4、确认UE工作正常备设常见的硬件问题：传输无码、驻波比告警、主分集不平衡、重要单板告警扇区功率输出是否正常、基站侧RSSI是否正常扇区天馈鸯线等UE的鉴权正常1