宁德案例-VOLTE劣化小区分析优化手册

1、VOLTE劣化小区分析优化手册1.摘要31.1VOLTE 简介31.2VOLTE 特点31.3VOLTE 重要性32.高RRC连接重建占比小区比例42.1概述42.2考核机制42.3关键知识介绍42.3.1RRC 重建流程42.3.2RRC 重建请求内部消息详解52.3.3RRC 重建触发原因与相关定时器72.4RRC重建处理思路82.4.1RRC重建处理流程图82.4.2重配置导致的高RRC重建92.4.3切换导致的高RRC重建92.4.4Other导致的高RRC重建102.4.5宁德高RRC重建简析102.5VOLTE高RRC重建优化案例122.5.1中兴MF91S2手机终端DRX功能不完

2、善导致高RRC重建，122.5.2ANR算法开启辅助解决VOLTE高RRC重建173.高S1切换小区203.1概述203.2考核机制203.3关键知识介绍213.3.1切换事件213.3.2S1与X2切换的区别223.4高S1切换分析参考思路233.5VOLTE高S1切换优化案例233.5.1PTN链路配置错误导致高S1切换234.语音高掉话小区274.1概述274.2考核机制274.3关键知识介绍284.3.1VOLTE呼叫流程284.3.2VOLTE呼叫信令解析304.4优化思路324.4.1VOLTE掉线原因与测量点324.4.2VOLTE网络问题异常分类334.4.3VOLTE掉线分析

3、思路354.5语音高掉线案例364.5.1异频重定向导致的VoLTE语音掉话365.高PDCP层用户面时延小区比例375.1概述375.2考核机制375.3关键知识介绍385.3.1PDCP层功能385.3.2用户面时延385.3.3PDCP时延影响因素395.4优化思路405.4.1整体优化思路405.4.2高话务导致高时延优化方案415.4.3空口质差导致高时延优化方案415.4.4非空口和话务原因导致高时延优化实施415.5高PDCP层用户面时延案例415.5.1用户开户速率低问题分析411. 摘要1.1 VOLTE简介VoLTE是基于IMS语音业务。IMS由于支持多种接入和丰富的多媒体

4、业务，成为全IP时代的核心网标准架构。经过3GPP R8/R9/R10几个版本的发展，以及GSMA对VoLTE的规范完善，VoLTE的标准和技术已经成熟。对运营商而言，部署VoLTE意味着开启了向移动宽带语音演进之路。1.2 VOLTE特点VoLTE技术带给4G用户最直接的感受就是接通等待时间更短，以及更高质量、更自然的语音视频通话效果。VoLTE与2G、3G语音通话有着本质的不同。VoLTE是架构在4G网络上全IP条件下的端到端语音方案。VoLTE相较2G、3G语音通话，语音质量能提高40%左右，因为它采用高分辨率编解 码技术。VoLTE为用户带来更低的接入时延（拨号后的等待时间），比3G降

5、50%，大概在2秒左右，而2G时代在6-7秒。此外，2G、3G下的掉线率 时有发生，但VoLTE的掉线率接近于零。1.3 VOLTE 重要性VOLTE给运营商带来两方面的价值:Ø 提升无线频谱利用率、降低网络成本。对于语音业务，LTE的频谱利用效率远远优于传统制式，达到GSM的4倍以上。Ø VoLTE体验优于传统CS语音。1) 高清语音和视频编解码的引入显著提高了通信质量；2) VoLTE的呼叫接续时长大幅缩短，测试表明VoLTE比CS呼叫缩短一半以上；3) 与RCS的无缝集成可以带来丰富的业务。随着VOLTE网络商用的不断成熟，在加强深度覆盖的同时，提升VOLTE网络质量

6、显的尤为重要。2. 高RRC连接重建占比小区比例2.1 概述RRC重建作为关键KPI指标的一部分，RRC重建成功率低会引起掉话，影响用户感知，如果优化合理，可以挽救部分掉话，降低网络掉线率；如果RRC连接重建失败，UE将进入RRC_IDLE状态，发生掉线，影响用户感知的同时，对网络其他指标也会造成一些不必要的影响。2.2 考核机制通过大数据平台，建立数据库与考核机制。对高RRC重建小区进行分析处理。l 考核公式高RRC重建小区 =RRC连接重建请求次数/（RRC连接重建请求次数+RRC连接建立请求次数）*100%l 高RRC重建条件1) RRC重建率>10%2) 一周7天，每天8:时至2

7、3时汇总的RRC连接建立请求次数>300l 高RRC重建小区华为映射计算公式指标华为计算公式RRC连接重建比率RRC重建请求次数/(RRC连接请求次数（包括重发）+RRC重建请求次数）*100%表2-2-1 RRC重建华为计算公式2.3 关键知识介绍2.3.1 RRC 重建流程² 触发原因当处于RRC连接状态但出现切换失败、无线链路失败、完整性保护失败、RRC重配置失败等情况时，触发此过程² RRC连接重建成功流程图2-3-1-1：RRC连接重建立流程1) RRC连接重建请求：UE通过UL_zCCuiCH在ShoRB0上发送，携带UE的AS层初始标识信息及重-建立原因

8、，该消息对应随机接入过程的Msg3。2) RRC连接重建：eNB通过DL_CCCH在SRB0上回复，携带SRB1的完整配置信息，该消息对应随机接入过程的Msg4。3) RRC连接重建立完成：UE通过UL-DCCH在SRB1上发送，不携带任何实际信息，只起到RRC层确认的功能。² RRC连接重建拒绝流程图2-3-1-2 RRC重建拒绝流程第二步中，如果eNB中没有UE的上下文信息，则拒绝为UE重建RRC连接，则通过DL_CCCH在SRB0上回复一条RRC连接重建立拒绝消息2.3.2 RRC 重建请求内部消息详解Ø RRCConnectionReestablishmentReq

9、uest消息字段表与图例字段名类型描述c-RNTIBIT STRING (SIZE (16）UE的C-RNTI标示physCellIdINTEGER (0.503)小区的物理层标示，即PCIshortMAC-IBIT STRING (SIZE (16)用于在RRC连接重建过程中标识和校验UEreestablishmentCausereestablishmentCause指示引发RRC连接重建过程的原因spareBIT STRING (SIZE (2)预留字段criticalExtensionsFuture预留预留表2-3-2-1：RRC连接重建立流程图2-3-2-1 RRC连接重建请求信息&#

10、178; ue-Identity设置与认识1) UE识别码，凭借该标识可以取回UE信息，以及帮助低层减缓竞争问题。2) 切换失败时，使用源小区的C-RNTI设置c-RNTI，或其他情况下，设置为触发重建过程的小区使用的C-RNTI；切换失败时，使用源小区的物理层标识设置cellIdentity，或其他情况下，设置为触发重建过程的小区使用的物理层标识² reestablishmentCause设置与认识在RRCConnectionReestablishmentRequest消息中ReestablishmentCause为枚举类型，包括四个信息元素：reconfigurationFail

11、ure, handoverFailure, other Failure, spare 1。1) 如果由于重配失败，当UE无法应用在RRCConnectionReconfiguration消息中的部分配置时，重配失败，UE应该继续使用前面的配置。并且，当安全性没有激活时，UE脱离RRC_CONNECTED状态并且设置release cause为other；当安全性已经激活时，则UE初始化连接重建过程，在上述重配过程结束后将reestablishmentCause设置为reconfigurationFailure2) 如果由于切换失败，含LTE内切

12、换失败、从EUTRA 移动到RAT失败；这两种情况都是T304超时，切换失败触发重建过程。将reestablishmentCause 设置为handoverFailure3) 否则将reestablishmentCause 设置为otherFailure设置完成后，UE将RRCConnectionReestablishmentRequest消息递交给下层进行传输。2.3.3 RRC重建触发原因与相关定时器² 协议 3GPP36.331 定义触发重建原因包括如下几类1) upondetecting radio link failure （UE检测到无线链路失败）重建常见原因为RLF,

13、如果UE检测到当前检测到“radio link failure”，则会发起原因值为“other”的重建，通常引起RLF存在如下几种机制：Ø 上行RLC重传达到最大次数：包括SRB和DRB，与eNB侧下行的SRB与DRB机制相同，当UE RLC发送了一个PDU之后，需要等到eNB侧反馈对应的状态PDU才能完成一次RLC的正常调度。对于没有收到eNB状态PDU的原因有两个，一个原因为eNB侧上行根本就没有收到任何RLC PDU，也就不会响应状态PDU，另一个原因为eNB响应的状态PDU，由于下行误码的原因，没有到达UE侧。上行RLC重传次数由参数UeMaxRetxThreshold控制。

14、Ø MAC层SRI重传达到最大次数：切换过程中，切换完成命令丢失，此时如果UE有SR发送，因为下行链路问题，UE无法收到ENB的确认，则发起重建请求。2) uponhandover failure （UE在E-UTRAN内切换失败）UE在切换流程中，在收到了切换的重配置消息之后，会启动T304，但如果在T304超时之前UE无法完成在目标小区的随机接入，则会发起原因值为“handover failure”的重建。3) uponmobility from E-UTRA failure （发生E-UTRAN移动性失败）4) uponintegrity check failure indic

15、ation from lower layers （UE收到下层的完整性检测失败指示）5) uponan RRC connection reconfiguration failure (发生RRC连接重配失败)UE在安全模式激活的状态下，如果收到了重配置消息后对于重配置消息内的信元无法匹配/兼容，则发起原因值为“reconfiguration failure”的重建。注：发起连接重建的一个前提条件是，在RRC连接建立、初始上下文建立和安全性激活后，进行RRC连接重配，目的是建立SRB2和DRB，如果重配过程失败了，则UE需要发起RRC连接重建，将SRB1重新建立以及重新进行安全性激活。²

16、; RRC重建定时器定时器T301、T311超时，均会导致UE回到RRC_IDLE 状态2.4 RRC重建处理思路2.4.1 RRC重建处理流程图定位RRC重建问题，需要有明确的分析思路再根据话统指标进行原因归类。1) 切换类重建重点围绕切换失败原因排查，包括通过配置文件基本切换参数配置以及邻区配置，其次是通过覆盖排查是否存在弱覆盖或者干扰源；最后再排查是否是UE在目标小区的接入问题。2) 重配置类问题重点是在UU口信令对比触发重建的重配置信令和正常信令各个信源的差异，如果是TOP终端问题，则可反馈运营商进行TOP终端处理；如果是终端兼容性问题，则可进行版本特性排查或给出规避方法。3) Oth

17、er类问题：a) 基于基站侧分析，如果是重建到非源小区，思路同切换类重建。排查配置文件是否未配置邻区或者切换参数配置不合理导致无法发起切换。或者是存在PCI混淆问题。其次通过UU口跟踪UE information Response观察是否存在服务小区信号突变。也可以观察是否由于下行问题造成UE未收到切换命令导致重建。b) 基于基站侧分析，如果是重建到源小区，除了覆盖分析、邻区配置分析外，需要通过UU口跟踪排查是否存在弱覆盖，或者是存在针尖效应。另外也可能是eNodeB已释放UE上下文，但是UE没有收到最后发起重建。c) 基于终端侧分析，首先要判断出是RLC问题，RACH问题，T310定时器问题

18、。并再次判断是上行问题还是下行问题造成的。2.4.2 重配置导致的高RRC重建1) 重配置问题现象协议定义重配置失败发起的重建大多数原因是由于基站配置参数终端不兼容造成的。大多表现上为重建到原小区，重建次数突然升高，重建成功。2) 重配置问题解决方案a) 通过信令对比确定问题根因，确定重配置信元是否符合协议，是否满足UE当前能力（UE能力通过FGI查看和能力查询消息的UE-EUTRA-Capability查看），是否与其他信元配置冲突，调整参数保证eNB不再下发不兼容参数给UE解决该问题。b) 如果短时间内通过UU口跟踪RRC CONN SETUPREQUEST中的信源TMSI相同，那么则认为

19、存在TOP终端，或者通过FMA解析CHR找到TMSI最多终端。重配置如果存在TOP终端，建议反馈TMSI+MMEC到MME网管，由MME确定TOP终端。c) TMSI（Temporary Mobile Subscriber Identity）是长度为32 bits 的数字，用于标识UE，MME Group ID是长度为16 bits的数字，MME Code是长度为8 bits的数字2.4.3 切换导致的高RRC重建切换类导致的常见原因主要有3种：邻区漏错配、弱覆盖、切换过早晚等。相应的处理思路可参考以下建议：1) 弱覆盖切换失败触发重建Ø 【现象确认】地理位置上确认（孤站、海域等场景

20、），MR数据采集(RSRP<-110&占比>20%),低QCI占比（0-6占比>35%）均可以作为弱覆盖的依据。Ø 【解决方案】建议路测分析进行RF优化解决2) 邻区错漏配切换失败触发重建Ø 【现象确认】跟踪信令；体现为eNodeB在收到UE上报的测量报告后未处理，并未发起切换请求而是直接发起RRC重建请求。现场DT测试还可以通过UE的RSRP来进行判断，当服务小区RSRP越来越弱，邻区RSRP越来越强，也可作为判断依据Ø 【解决方案】邻区添加或检查外部邻区参数并修正。3) 切换过早晚触发重建Ø 【现象确认】协议定义切换失败后将

21、会发起RRC重建切换过早UE重建回源小区切换过晚时，UE重建到目标小区，但更容易掉话。该现象我们可以通过后台采集两两小区切换进行判断。Ø 【解决方案】可以通过RF优化，调整CIO进行解决。2.4.4 Other导致的高RRC重建1) 触发原因描述协议将重配与切换之外触发的RRC重建均归类至Other。可分为站内重建和站间重建。Ø 【站内重建】调度问题或者是孤站弱覆盖造成的重建Ø 【站间重建】信号突变或者切换参数配置问题造成UE未及时。进行切换动作而造成重建。2) 解决方案Ø 切换异常：参见章节2.4.3Ø 弱覆盖：RF优化、新建站等增强覆盖&#

22、216; 高RLC重传：排查干扰（带外干扰、同频同PCI）与解决弱覆盖Ø RACH最大：排查外部干扰，优化切换，针对高速场景的可以减少TA定时器2.4.5 宁德高RRC重建简析1) 现网高RRC重建原因统计对章节2.4.12.4.4理解的话，通过以下2点分析，不难看出宁德高RRC重建主要来自无上下文导致的RRC重建即弱覆盖与切换导致。需要注意的是，非源导致的RRC重建一般均为切换入失败形成，而华为统计的切换失败发起的RRC重建均为统计点在本小区的RRC重建。a. 从图2-4-5-1以看出，RRC重建请求主要触发为Other类问题，占94.83%；其次为切换触发占5.06%，而重配触发

23、的RRC请求仅0.11%。b. 从图2-4-5-2以看出，RRC重建请求主要来自源小区占57.6%，非源42.4%图2-4-，5-1 RRC重建请求话统1图2-4-5-2 RRC重建请求话统22) 解决方案【非源小区重建】该类原因主要来自其他小区切换入失败后，在本小区发起的RRC重建。该问题基本上都是邻区切入过早过晚或漏配导致，以下进行分场景说明。1） 【高速高铁RRC重建】现象：该场景下UE快速移动，容易切换不及时导致的高RRC重建该类优化较为困难，目前以白名单形式进行剔除。方案：暂无，省公司统一剔除该类问题点，暂不做考核。2） 【海域高RRC重建】现象：海域场景存在站高、信号反射等问题，导

24、致覆盖广，信号飘忽等情况，导致邻区漏配、弱覆盖方案：可临时开启ANR功能，进行邻区自优化。(切换成功率98%以上，日切换次数150次，否则无效)或进行RF优化（只限海域村庄同覆盖场景）成效：实验10个问题点，解决7个，解决率70%，剩余30%已无邻区可添加，海域弱覆盖区域无其他强信号小区进行衔接。（可参见章节2.5.2 ANR辅助解决高RRC重建）3） 【超高站或山顶站】现象：该类站点容易过覆盖，甚至形成孤岛效应。方案：建议对站点整改或RF优化做好覆盖，不建议添加邻区解决。成效: 对过覆盖、覆盖问题小区累计下压12个问题点，解决8个，其中未解决的为主覆盖海域场景【源小区重建】源小区重建其触发原

25、因主要有小区内无上下文导致的RRC重建、重配置导致的RRC重建、切换导致的RRC重建，而无上下文导致的RRC重建占比又最高。现针对该问题提高简要分析思路1） RRC重建请求消息辅助分析：检查请求消息里的PCI是否已做邻区关系，或者该PCI是否已做本小区的邻区关系。若都有需要重点排查源小区回复无上下文重建响应结果为failure或回复超时的原因。如小区是否外部干扰，重叠覆盖过覆盖等导致2） 两两小区对分析：分析双向切换指标，是否存在过早过晚或乒乓切换、重建回源小区。通过修改切换参数进行解决，注意的是切换成功率并不能代表其重建率低3） MR数据分析：采集MR过覆盖、重叠覆盖对问题小区分析并RF优化

26、；采集MR弱覆盖数据，对问题小区进行RF优化，功率、接入、系统间重选等参数优化，站点规划等。4） 其他：a. 告警：当本小区有告警，特别是驻波告警的时候对RRC重建则会影响较大，另邻区产生告警也需要留意，避免关键邻区告警无服务导致的无最优邻区触发RRC重建，特别是孤站，站间距大的农村、山间国道县道这类场景.b. 终端问题：该问题定位需要核心网协助处理，无线侧只能确认某个时段是否有哪个用户标识一起发起RRC重建而进行初判2.5 VOLTE高RRC重建优化案例2.5.1 中兴MF91S2手机终端DRX功能不完善导致高RRC重建，【问题描述】全省重建劣化小区，福4州重建劣化小区为严重，占比为6.15

27、%，而福州测试网格8有70个小区6为重建劣化小区，占整8个网格24.7%属较严重网格，探究高RRC重建的要因，总结出可以执行推广的解决高RRC重建的方法，指导后续网络的优化工作，提升网络质量。【问题分析】1）现场RRC重建原因分析首先需要查明RRC重建的原因，再根据不同原因进行优化提升。从网管统计可以看出97.7%的重建原因是“OtherCause”而非切换与重配置。2）与主要网管指标关联分析分析重建比例与无线掉线率、ERAB掉线率、切换成功率的相关分析，发现重建比例高与这些指标没有相关性，重建劣化小区，无线掉线率、ERAB掉线率、切换成功率未见明显恶化，证明重建的主要原因非切换原因。3）与M

28、R指标相关分析与MR相关分析，重建比例与低SINR<0(干扰)、RSRP<-110(覆盖)以及RIP>-105(底噪)进行分析，虽然个别小区SINR<0占比偏大，但与重建比例大相关性不明显。4）重建劣化时段分析对重建劣化化小区的劣化时段进行分析，发现劣化小区并不是所有时段都呈劣化现象。未劣化时段，劣化比例几乎都为0，即基本没有重建（这些时段都是忙时），因此怀疑重建跟终端行为有关系。5）与终端关联分析a) TOP小区分析选择三个TOP小区，关闭DRX进行实验，发现该三个小区的重建指标好转地市厂家CGI 高RRC重建出现次数福州诺基亚460-00-417983-17福州诺基

29、亚460-00-418437-23福州诺基亚460-00-417901-32指标变化情况如下，2月2号关闭DRX，测试小区重建比例基本消失因此基本上可以作出如下结论个别终端性能不完善是照成RRC重建比例高的主要原因；DRX功能不完善是终端问题的主要问题；b) 问题终端查找方法当核心网开启IMEI-check功能后，会下发Identity Request消息封装在下行直传消息中查询IMEI，UE会在上行直传消息中携带自己的IMEI上报核心网，这条消息是在核心网加密之前，所以网络侧可以解析这条消息。华为系统U口与S1口可以一起分析，在核心网开启IMEI-check功能后，在信令跟踪中有CallID

30、标识唯一用户，只要找到重复重建UE UU口跟踪的CallID，对应找到相同CallID直传消息里的IMEI，就可以唯一确认重建用户的IMEI，从而可以知道频繁重建的终端。通过该方法已查明最严重的一款终端型号为中兴MF91S2，该终端重建占比达全网重建次数的95.6%。目前终端厂家也已确认该终端存在此问题，问题终端的IMEI前8位均为86449600，后续可通过软件升级逐个解决问题终端。问题终端图示如下：【解决方案】1) 关闭中兴MF91S2的用户DRX功能，使RRC重建恢复正常。通过查询所有的中兴MF91S2的用户IMSI，通过核心网和eNB的配合，使特定用户不进入DRX，不影响网络中其他用户

31、DRX的正常开启。修改开户信息的方法：a) 在HSS的业务开户界面 SAE-HSS MML窗口更改IMSI对应的RFPRID，将特定用户的SPID值设置为1；MOD RFPRID: IMSI="460150002000050", RATFREQSELPRIID=1;b) 无线侧基站配置，如果开户的SPID为1，通过以下配置使TOP终端无法进入DRX休眠期，却不影响正常用户进入DRX：ADD SPIDCFG: Spid=1, DrxStatus=false；MODDRX:LONGDRXCYCLESPECIAL=SF10ONDURATIONTIMERSPEC

32、IAL=PSF8;2) 相关参数优化a) 多长时间失步则进入重建的定时器：t310（1000ms）省控b) 失步后在特定时间内寻找合适小区的定时器：T311(1000ms)省控c) 找到合适小区发起重建，在该时间超时前需完成重建:T301(600ms)省控d) RRC信令等待时间：Rrcguardtime NOKIA VENDOR 参数 2000MS（因RRC 重配置失败的重建适用）e) RLC最大重传次数：drbAmMxRtxTh NOKIA VENDOR参数 16（因重传次数超限引起的重建适用）f) 相关随机接入参数：prachConfIndex、prachCS、prachFreqOff的

33、规范设置对RRC建立成功率有提升作用，规范参数如下：小区prachConfIndexprachCSprachFreqOff备注室外第一小区3116室外第二小区4116室外第三小区31188室分第一小区5160室分小区prachConfIndex交替使用51、52室分第二小区5260【验证结果】由于关闭中兴MF91S2的用户DRX功能为临时解决措施，需联合终端厂家，对中兴MF91S2联合定位，分析根因，因此并不对此进行验证；涉及修改参数的小区，取修改前后5天的指标进行比对（2月5号完成修改），在其它指标保持稳定的情况下，RRC建立成功率修改后稳定处于高位，修改前平均为99.625%，修改后平均为

34、99.935%，提升0.31%。2.5.2 ANR算法开启辅助解决VOLTE高RRC重建Ø 问题描述宁德蕉城-外窑省道-2存在高RRC重建，影响VOLTE用户感知。日期小区名称VOLTE高RRC重建数_分子VOLTE高RRC重建数_分母VOLTE高RRC重建比例2016-03-09宁德蕉城-外窑省道-HLH-2418382910.92%2016-03-10宁德蕉城-外窑省道-HLH-2382366310.43%2016-03-11宁德蕉城-外窑省道-HLH-2417354711.76%Ø 问题排查1) 告警与干扰排查：通过后台查询，该站点并无告警与无线干扰。2) 信令跟踪分

35、析：当前华为后台信令统计高RRC重建原因主分三大类： reconfigurationFailure(0)、handoverFailure(1)、otherFailure(2)。通过跟踪分析本小区信令，发现其RRC重建原因大量Other类，Other类重建可以又分为站内重建和站间重建。a) 站内重建大多是由于调度问题或者是孤站弱覆盖造成的重建（例如由于UE处于失步态，eNB下发RRC Rel造成UE收不到而发起重建）。b) 站间重建大多是由于信号突变或者切换参数配置问题（包括PCI冲突，PCI混淆）造成UE未及时进行切换动作而造成重建。3GPP中将切换、重配剔除后的重建原因均归类到该原因值。3)

36、 查询无线环境与切换情况a) 检查PCI冲突：并未发现MOD3干扰，3KM内务同频同PCIb) 检查地理环境：该站点覆盖海域与海岸线的村庄以及道路，易受海域特性影响形成弱覆盖。c) 邻区核查：通过邻区关系核查，其邻区配置无明显漏配d) 采集网管原因值，发现无上下文导致发起的重建原因为主导，切换触发导致重建为其次。与信令跟踪结果一致。4) 无线参数优化通过工参查询该小区RF最优调整，现通过无线参数优化参数修改前修改后目的最低接收电平-128-124减少边缘用户或弱信号用户接入，以降低因弱覆盖导致高RRC重建异频异系统盲切换A1A2事件RSRP门限-124-122CIO根据后台统计的切换指标渐进性

37、优化减少切换过早过晚导致的RRC重建Ø 解决方案1) 方案定制与说明通过以上优化并未得到明显改善，考虑到海域场景的特殊性，容易形成重叠覆盖、过覆盖、弱覆盖等现象且RF优化手段有限。手动盲目添加邻区又容易形成冗余邻区、乒乓切换、非最优小区切换等现象。打开ANR（邻区自优化）算法能够自动维护邻区关系的完整性和有效性，从而减少非正常邻区切换，提高网络性能。2) 方案成效开启ANR开关后，新增了有效邻区9个（日均切换>150，成功率>98%），该小区RRC重建比例再次降低。优化阶段日期小区名称VOLTE高RRC重建比例无2016-03-09宁德蕉城-外窑省道-HLH-210.92

38、%2016-03-10宁德蕉城-外窑省道-HLH-210.43%2016-03-11宁德蕉城-外窑省道-HLH-211.76%接入与切换参数优化2016-03-12宁德蕉城-外窑省道-HLH-29.78%开启ANR2016-03-13宁德蕉城-外窑省道-HLH-27.43%2016-03-14宁德蕉城-外窑省道-HLH-27.78%2016-03-15宁德蕉城-外窑省道-HLH-26.71%3. 高S1切换小区3.1 概述S1接口切换要比X2接口切换信令更复杂、信令流程更长，直接导致在时延上的劣势。因此在条件，允许的情况下，我们应该尽量选择X2切换，以提高用户感知度，降低切换失败发生的概率。3

39、.2 考核机制l 考核公式eNB间S1切换出请求次数/（eNB间S1切换出请求次数+eNB间X2切换出请求次数+eNB内切换出请求次数）*100%l 高S1切换条件1) S1切换占比率>5%2) 一周7天，每天8:时至23时汇总的切换出请求次数>300l 高RRC重建小区华为映射计算公式指标华为计算公式S1切换占比eNB间S1切换出请求次数/(eNB间S1切换出请求次数+eNB间X2切换出请求次数+eNB内切换出请求次数）*100%eNB间S1切换出请求次数eNodeB间同频切换出尝试次数+eNodeB间异频切换出尝试次数-eNodeB间X2接口同频切换出尝试次数-eNodeB间X

40、2接口异频切换出尝试次数eNB间X2切换出请求次数eNodeB间X2接口同频切换出尝试次数+eNodeB间X2接口异频切换出尝试次数eNB内切换出请求次数eNodeB内同频切换出执行次数+eNodeB内异频切换出执行次数表3-2-1高S1比例华为计算公式3.3 关键知识介绍3.3.1 切换事件1) 切换事件说明2) 切换公式说明事件A3的触发，即邻区质量高于服务小区一定偏置值。参照3GPP协议36.331规定事件A3的判决公式。触发条件：Mn+Ofn+Ocn-Hys>Ms+Ofs+Ocs+Off取消条件：Mn+Ofn+Ocn+Hys<Ms+Ofs+Ocs+Off公式中的变量有如下定

41、义：Ø Mn是邻区测量结果。Ø Ofn是邻区频率的特定频率偏置，采用默认值0，同频切换可以不考虑。Ø Ocn是邻区的特定小区偏置，由参数CellIndividualOffset（CIO）决定。当该值不为零，此参数在测量控制消息中下发；否则当该值为零时不下发，该参数较多地用于提前切换或推迟切换。无线参数说明：小区偏移量：CellIndividualOffset，该参数表示同频邻区的小区偏移量。用于控制同频测量事件发生的难易程度，该值越大越容易触发同频测量报告上报。参考3GPP TS 36.331。调整影响：若加大该值，将降低A3事件触发的难度，提前切换；若降低该值，

42、则增加A3事件触发的难度，延缓切换。Ø Ms是服务小区的测量结果。Ø Ofs是服务小区的特定频率偏置，采用默认值0，同频切换可以不考虑。Ø Ocs是服务小区的特定小区偏置，该值通常为零。Ø Hys是事件迟滞参数，在测量控制消息中下发。无线参数说明：同频切换幅度迟滞: IntraFreqHoA3Hyst, 该参数表示同频切换测量事件的迟滞，可减少由于无线信号波动导致的同频切换事件的触发次数，降低乒乓切换以及误判,该值越大越容易防止乒乓和误判。异频A3幅度迟滞与该参数取值相同。参见协议3GPP TS 36.331。调整影响：增大迟滞Hyst，将增加A3事件触

43、发的难度，延缓切换，影响用户感受；减小该值，将使得A3事件更容易被触发，容易导致误判和乒乓切换。Ø Off是事件偏置参数，该参数针对事件设置，用于调节切换的难易程度，该值与测量值相加用于事件触发和取消的评估。此参数在测量控制消息的测量对象中下发，可取正值或负值，当取正值时，此时增加事件触发的难度，延缓切换；当取负值时，此时降低事件触发的难度，提前进行切换。无线参数说明：同频切换偏置: IntraFreqHoA3Offset, 该参数表示同频切换中邻区质量高于服务小区的偏置值。调整影响:该值越大，表示需要目标小区有更好的服务质量才会发起切换。参见协议3GPP TS 36.331。若为正

44、，将增加A3事件触发的难度，延缓切换；若为负，则降低A3事件触发的难度，提前进行切换。Ø 同频切换时间迟滞: IntraFreqHoA3TimeToTrig, 该参数表示同频切换测量事件的时间迟滞。当同频切换事件满足触发条件时并不能立即上报，而是当该事件在时间迟滞内，一直满足上报条件，才触发上报该事件测量报告。该参数可以减少偶然性触发的事件上报，并降低平均切换次数和误切换次数，防止不必要切换的发生。异频A3时间迟滞与该参数取值相同。320ms(320毫秒)，延迟触发时间的设置可以有效减少平均切换次数和误切换次数，防止不必要切换的发生。延迟触发时间越大，平均切换次数越小，但延迟触发时间

45、的增大会增加掉话的风险。3.3.2 S1与X2切换的区别通过上图比对可以看出，LTE的S1接口信令比X2接口信令要少3条，详情如下：Ø 判决切换对比：S1接口切换需2条信令，多出eNB1向MME发送handover Require消息。而X2接口只需1条信令即可完成。Ø 资源分配阶段：S1接口切换中MME向eNB2发送切换请求消息，eNB2回复MME切换请求ACK消息，之后MME再向eNB1下发切换命令，经过3条信令。而X2接口切换中，eNB1直接向eNB2发送切换请求消息，eNB2回复eNB1切换请求ACK消息。只经过2条信令。Ø 切换完成过程：如果从RRC C

46、onnection Reconfiguration 信令算为切换开始，到RRC Connection Reconfiguration Complete信令为切换完成。由上面对比图可以发现，S1接口切换中，eNB1向eNB2发送Status transfer消息要比在X2接口切换中多1条信令。即，X2中eNB1直接向eNB2发送Status transfer消息，而S1中eNB1需要先向MME发送Status transfer消息，然后MME再向eNB2发送该消息。Ø UE删除实例过程：该过程虽然内容不尽相同，但经过3条信令。在时延上没有太大差别。根据以上分析可以发现：总体上，S1接口

47、切换要比X2接口切换信令更复杂，信令流程更长，直接导致在时延上的劣势。所以在条件允许的情况下，我们应该尽量选择X2切换，以提高用户感知度，降低切换失败发生的概率。3.4 高S1切换分析参考思路S1切换需要通过核心网来完成，S1接口切换要比X2接口切换信令更复杂，涉及的信令交互节点也比X2切换多，不仅在切换过程中更耗时，且切换失败的风险也高于X2切换； eNodeB和eNodeB之间存在X2接口，X2接口的存在适应了LTE网络扁平化的要求，使部分信息交互在eNodeB侧就可以完成，比如在切换过程中，如果存在X2链路，切换的信令流就可以走X2链路，从而降低小区切换过程中信令流对核心网的压力。剔除跨

48、MME切换需用到S1切换，其余切换现网均配置为优先X2切换，当X2链路不通时，才会进行S1切换。从该点出发，整理出一份处理思路，如下图：3.5 VOLTE高S1切换优化案例3.5.1 PTN链路配置错误导致高S1切换【问题描述】宁德周宁-西街桥头-HLH-1产生高S1切换问题，S1切换占比为55.37%，远大于S1切换占比<5%的基本要求，为VoLTE劣化小区。日期小区名称本地小区标识VOLTE高S1切换比例数_分子VOLTE高S1切换比例数_分母VOLTE高S1切换比例数（劣化）2016-01-18宁德周宁-西街桥头-HLW-1151092155.37%2016-01-19宁德周宁-西

49、街桥头-HLW-1132977142.67【问题分析】1) 检查X2相关配置是否正确Ø 执行MML命令DSP X2INTERFACE，检查是否添加X2链路：Ø 执行MML命令LST GLOBALPROCSWITCH，检查配置X2自建链开关是否为ON，X2自建链方式是否为X2_OVER_S1；Ø 执行MML命令LST EPGROUP ，检查是否添加端节点组；Ø 配置控制面数据a) 执行MML命令LST SCTPTEMPLATE，检查是否添加SCTP参数模板。b) 执行MML命令LST SCTPHOST，检查是否添加SCTP本端对象。c) 执行MML命令LS

50、T SCTPHOST2EPGRP，检查是否增加端节点组的SCTP本端对象。Ø 配置用户面数据a) 执行MML命令LST USERPLANEHOST，检查是否增加用户面本端对象。b) 执行MML命令LST UPHOST2EPGRP，检查是否增加端节点组的用户面本端对象。6、执行MML命令LST X2，检查是否添加X2对象，其中包含X2所归属的运营商、控制面端节点资源组和用户面端节点资源组信息，是否超过128条X2链路导致满配置。经过排查，该站点配置正常。2) 问题站点X2接口重配置a) 跟踪S1信令，确认对端eNodeB ID.b) 将高S1切换小区的X2自建立开关关闭。c) 删除X2

51、接口用户面对端和本端承载（PPEER2EPGRP2、USERPLANEPEER）注：与PGW的承载不能删除。d) 删除SCTP链路对端以及本段（SCTPPEER2EPGRP、SCTPPEER、SCTPLNK）注：删除时，注意与核心网的S1链路不能删除，且SCTP链路在删除对端以及本断承载后会自动删除。e) 删除X2INFACE接口。（此时X2接口自动全部删除）f) 开X2自建立开关。让X2接口自动建立。在重配置后，X2接口故障告警、用户面承载链路故障告警、SCTP链路故障告警依然存在，告警定位为底层链路故障，经过以上排查可以基本判断基站配置本身无问题，通过在源基站和目标基站进行SCTP链路跟踪

52、分析，发现问题很可能在与PTN的链路上（如下图）。左图：桥头站点给目标站点 64 4D 47 CF（街头）发送init消息右图：街头站点收到init消息之后，回复initack消息给桥头站点，但是在对应的时刻在桥头站点并没有收到initack消息，该报文是760字节，怀疑PTN侧设置存在问题。【解决方案】传输侧排查原因步骤：1) 经PTN网管查看周宁-西街桥头-HLW（IP:100.77.71.93）与宁德周宁-西街街头-HLH（IP：100.77.71.207）无任何传输告警，光功率无异常，对4条隧道进行环回测试正常；2) 从周宁LTE桥接设备PING LTE基站IP可通，且与无线侧核对，发

53、现无线侧只有X2相关告警，无S1相关告警，可确定为传输问题引起故障；3) 排查业务数据发现PTN主用桥接点的备用桥虚接口选择错误，经修正后，X2告警消除。传输侧排查结果：当LTE基站承载至PTN设备时，若基站至主用桥接点和备用桥接点的4条PW有一条不通，则将导致无线侧出现X2告警。本次故障原因为PTN主用桥接点的备用桥虚接口导致主用桥接点的备用PW不通，导致X2告警。【验证结果】通过处理后，已无S1切换处理时段日期小区名称本地小区高S1切换比例数_分子高S1切换比例数_分母VOLTE高S1切换比例数（劣化）处理前2016-01-18宁德周宁-西街桥头-HLW-1151092155.37%201

54、6-01-19宁德周宁-西街桥头-HLW-1132977142.67%2016-01-20宁德周宁-西街桥头-HLW-1112348625.31%处理后2016-01-27宁德周宁-西街桥头-HLW-1113880.26%2016-01-28宁德周宁-西街桥头-HLW-1103980.00%4. 语音高掉话小区4.1 概述VOLTE语音其作为IP数据传输，无需2G/3G网，全部业务承载于LTE网络上，可实现数据与语音业务在同一网络下的统一。相对于现有的2G/3G网络，通过引入高清编解码等技术，VoLTE可拥有比2G/3G语音，以及时下流行的OTT语音业务更好的用户体验。同时，当终端离开LTE的

55、覆盖区域时，VoLTE能够将LTE上的语音呼叫切换到2G/3G网络上，保证语音呼叫的连续性。VOLTE作为LTE语音解决的最终方案，提高该性能指标对用户感知显得尤为重要！4.2 考核机制通过大数据平台，建立数据库与考核机制。对语音高掉线小区进行分析处理。l 考核公式（1-（1-E-RAB掉线率（QCI=1）*(1-E-RAB掉线率（QCI=5）*100%ERAB掉线率公式：（eNB请求释放的E-RAB数 -正常的eNB请求释放的E-RAB数 +切出失败的E-RAB数 ）/（遗留E-RAB个数+E-RAB建立成功数+切换入E-RAB数）*100%l VOLTE语音高掉线条件1

56、) 掉线率>0.5%2) 一周7天，每天8:时至23时汇总的QCI1和QCI5的(遗留E-RAB个数+切换入E-RAB数+E-RAB建立成功数)同时>300l 语音高掉线小区华为映射计算公式指标华为计算公式VOLTE高掉线（1-（1-E-RAB掉线率（QCI=1）*(1-E-RAB掉线率（QCI=5）*100%E-RAB掉线率（QCI=1）（eNodeB触发的QCI为1的业务E-RAB异常释放次数+切换出QCI为1的E-RAB异常释放次数）/（QCI为1的业务E-RAB建立成功次数+QCI为1的遗留E-RAB个数+QCI为1的切换入E-RAB成功建立次数）E-RAB掉线率（QCI=5）（eNodeB触发的QCI为5的业务E-RAB异常释放次数+切换出QCI为5的E-RAB异常释放次数）/（QCI为5的业务E-RAB建立成功次数+QCI为5的遗留E-RAB个数+QCI为5的切换入E-RAB成功建立次数)表4-2-1语音高掉线小区华为计算公式4.3 关键知识介绍4.3.1 VOLTE呼叫流程上述A和B均是IDLE模式，互相进行拨打的方式是实际应用场景中最常见的一种方式了，具体流程如下。1) 用户A和B在注册成功后，无业务触发，MME发起上下文释放，将A和B均置为IDLE模式。2) UE A呼叫UE B，此时A发现其为IDLE模式，则需要先建立信令连接。首先缓存