信令异常分析(掉话)

未接通、掉话及切换失败分析一、未接通分析正常呼叫主叫起呼和被叫接入过程：主叫起呼信令流程图被叫接入信令流程图由主叫起呼信令流程图可以看出，主叫首先发出channel request report-→immediate assignment-→CM service request-→setup-→call proceeding-→assignment command-→assignment complete-→alerting-→connect-→完成一次起呼。

在主叫assignment complete 完成后2－3秒左右被叫开始信道请求流程Channel request report→immediate assignment-→setup→call confirmed→assignment command→assignment complete-→alerting→connect-→完成一次被叫接入。

1、未接通原因分析（1）RACH冲突或者AGCH拥塞建议：查看与RACH相关的参数――最大重发次数和发送分布时隙数以及与AGCH相关的参数――接入准许保留块数（2）SDCCH拥塞建议：检查SDCCH配置，查看相关小区SDCCH话务量（3）SDCCH掉话或者TCH拥塞建议：查看是否启用SDCCH信道上的切换，查看相关小区话务量和TCH配置，在排除无线方面原因后，应跟踪Abis接口、A接口信令从交换侧寻找问题原因（4）位置更新引起未接通建议：查看位置更新定时器和位置区设置（5）小区重选过程引起未接通建议：查看相关小区的小区重选参数2、未接通实例分析（1）SDCCH拥塞导致未接通在主叫完成起呼（assignment complete ）后2秒左右，此时被叫发起信道请求channel request report,由于SDCCH拥塞溢出，被叫手机无法获得SDCCH，重复2次发送信道请求后仍然无法获得SDCCH信道消息的回复，导致未接通的发生。

GSM系统中的话务掉话分析和处理摘要本文主要针对GSM网络系统出现的掉话问题进行详细的分析，并提出解决问题的建议和办法。

关键词GSM 掉话切换移动通信中的话务掉话是指在分配了话务信道（TCH）后，由于某种原因，呼叫丢失或中断，导致正常通话无法继续进行的现象。

掉话是衡量网络QoS的重要标志，虽然掉话对系统接通率等指标没有直接影响，但却给用户造成了许多不便，是目前用户投诉的热点，因此必须予以重视。

下面从掉话计算公式出发对掉话产生的原因及解决方法进行阐述。

一、公式话务掉话总次数：本地区无线子系统所有原因引起的业务信道掉话，包括正常信道丢失及各种切换等原因引起的话音掉话。

计算公式如下：话音信道掉话总次数=C1164/8+C1164/13+C1164/14+C1164/16+C1164/24+C1164/25与掉话相关的指标：无线话务掉话比=（C1611/0+C1611/1）*60/（C1164/8+C1164/13+C1164/14+C1164/16+C1164/24+C1164/25）即：话务掉话比=话务量*60/掉话次数二、计数器解释C1611/0：TCH正常分配时的话务量；C1611/1：TCH重新建立时的话务量；C1164/8：由于PCM等设备问题造成时隙释放而产生的掉话；C1164/13：无线接口失败造成的掉话；C1164/14：无线链路失败而造成的掉话；C1164/16：A接口上有断连接指令发出（指没有正常情况下释放信道的CLEAR COMMAND或SCCP断连接指令），多半是硬件原因的造成的；C1164/24：切换中的T3103超时造成的掉话；C1164/25：跨BSS的切换中的T8超时造成的掉话；基本上优化掉话基本上就是想尽各种办法减少掉话次数。

三、掉话产生原因及解决方案1、无线链路失败无线呼叫过程见下图：当移动台在通话过程中，由于某种原因，不能发出SACCH(包含有测量报告消息)，或者在规定时间内没有被网络(即BTS)解码，也无法执行其它切换，造成的掉话就是无线链路超时掉话。

⼤唐后台信令跟踪LDT异常事件解读3、CDL⽂件掉话失败原因分析3.1、cdl分析关注要点⽬前的CDL⽂件使⽤LDT分析后，UE掉话对应的有“掉话事件”和“掉话原因”，掉话原因为关注的重点，具体掉话原因对应的有：1)RL failure or RLC error timer expiry。

RB建⽴后，掉话；2)Receive Ue TimerOut Response Message In DTD Proc。

RB建⽴失败，影响接通；3)切换过程中发⽣RL失败引起的掉话。

切换失败导致掉话；4)未知原因引起的掉话。

切换失败导致掉话；5)failed because cell update occurs。

⼩区更新失败导致掉话；6)Receive Ue Timeout Msg during HO。

切换失败导致掉话；7)⼩区更新超时。

实为切换失败掉话；8)RL Failure引起的掉话。

⽆线链路失败触发⼩区更新，导致掉话；9)user or link forece release。

UE在cs域和ps域中建⽴RAB，kpi中会统计为掉话或接⼊失败；10)RA THO, as waiting lu timer expire message, received a cell change order from utran failuremessage。

系统间切换失败导致掉线；11)rolled Fail during HO。

⼩区更新导致切换失败掉话；12)The reason for the action is expiry of timer TRELOCoverall.。

系统间切换失败导致掉话；13)RRC release when INTEGRITY CHECK fail。

RAB建⽴失败14)Cell Update Confirm 超时。

⼩区更新，掉线；15)Receive Ue Failure Response Message In DTD Proc。

网优掉话分析及信令流程怡创李宇鹏今天我和大家一起探讨一下关于网优掉话的相关问题，但是在讲解掉话问题之前，我想首先给大家介绍一下简单的通话过程和手机作为被叫和主叫的信令接续过程，然后再和大家探讨一下怎样处理掉话方面的问题。

在给大家讲打电话的过程之前，我先向大家说一下各种号码。

一、编号系统1、移动台的国际身份号码ISDN（MSISDN）是在公用交换电话网编号计划中唯一地识别移动电话的鉴约号码。

CCITT建议结构为：MSISDN＝CC＋NDC＋SNCC＝国家码即在国际长途电话通信网中的号码(86)NDC＝国内目的地码SN＝用户号码如1392223456－139222便是NDC，前三位用于识别网号，后三位用于识别归属区，目前开通的135--138实际上是同一个网。

2、国际移动用户识别码（IMSI）是唯一地识别GSMPLMN网中某一用户的信息。

IMSI＝MCC＋MNC＋MSIN (460-00---)MCC＝移动网的国家号码（与CC不同）MNC＝移动网号MSIN＝移动台识别号，最长为15位。

3、移动台漫游号码（MSRN）用于一次呼叫的路由选择。

MSRN＝CC＋NDC＋SNCC＝国家号NDC＝国内目的地号码(用于识别MSC/VLR）SN＝用户号，对应于用户的IMSI号码4、临时移动用户识别码（TMSI）用于保护IMSI码，该号只在本MSC区域有效，其结构可由各电信部门选择，长度不超过4个字节。

5、国际移动台设备识别码（IMEI）是唯一用来识别移动台终端设备的号码，称作系列号。

IMEI＝TAC＋FAC＋SNR＋SPTAC＝型号论证码FAC＝最终装配码，用于识别制造厂家。

SNR＝序号SP＝备用6、位置区识别码（LA）LAI代表MSC业务区的不同位置区，用于移动用户的位置更新。

LAI＝MCC＋MNC＋LACMCC＝移动国家号，识别一个国家MNC＝移动网号，识别国内的GSM网LAC＝位置区号码，识别一个GSM网中的位置区7、小区全球识别码（CGI）用于识别一个位置区内的小区。

掉话类故障处理指导掉话分类定义在华为Probe侧对于掉话（ERAB Abnormal Release）的定义：UE没有收到Deactivate Eps Bearer Context Request消息，但收到RRC Release或RRC Connection Reconfiguration消息，则表示ERAB异常释放。

标口信令在eNodeB跟踪到的标准接口信令中，如果存在eNodeB发起的释放，即在S1接口上发往CN的S1AP_UE_CONTEXT_REL_REQ消息内携带的原因值不为“User-inactivity (20)”时，则判断为掉话。

掉话预检查方式异常掉话通常都是由eNB发起的释放，通知MME释放上下文，因此只要查看S1口发送的S1AP_UE_CONTEXT_REL_REQ消息即可，如下图所示。

S1AP_UE_CONTEXT_REL_REQ点击“标准接口消息类型”按消息类型进行排序，这样所有的S1AP_UE_CONTEXT_REL_REQ 都会排列在一起，如下图所示。

按消息类型排序依次点击下一条，查看中的原因值，找出最后的原因为非02 80 的原因值。

找到异常掉话消息根据对应的时间点，打开标准UU口的跟踪，找到对应时间点的RRC_CONN_REL消息，如下图所示。

找到对应的UU口消息掉话率指标话统公式在话统侧异常掉话指标的公式定义如下：Call Drop Rate = L.E-RAB.AbnormRel / (L.E-RAB.AbnormRel + L.E-RAB.NormRel)等同于：Call Drop Rate = L.E-RAB.AbnormRel.QCI.N / （L.E-RAB.AbnormRel.QCI.N +L.E-RAB.NormRel.QCI.N）其中：分子上表征异常释放的Counter为L.E-RAB.AbnormRel.QCI.N= L.E-RAB.AbnormRel.QCI.1+L.E-RAB.AbnormRel.QCI.2+L.E-RAB.AbnormRel.QCI.3+L.E-RAB.AbnormRel.QCI.4+ L.E-RAB.AbnormRel.QCI.5+ L.E-RAB.AbnormRel.QCI.6+ L.E-RAB.AbnormRel.QCI.7+ L.E-RAB.AbnormRel.QCI.8+ L.E-RAB.AbnormRel.QCI.9；而分母上是正常释放与异常释放的总和，正常释放的Counter为L.E-RAB.NormRel.QCI.N= L.E-RAB.NormRel.QCI.1+L.E-RAB.NormRel.QCI.2+L.E-RAB.NormRel.QCI.3+L.E-RAB.NormRel.QCI.4+ L.E-RAB.NormRel.QCI.5+ L.E-RAB.NormRel.QCI.6+ L.E-RAB.NormRel.QCI.7+ L.E-RAB.NormRel.QCI.8+ L.E-RAB.NormRel.QCI.9；常见掉话原因邻区错/漏配通常，网络建设初期优化过程掉话占大多数是由于邻区错/漏配导致的。

移动通信掉话问题分析摘要:针对GSM系统掉话原因及解决方法进行简要阐述,并对移动网络掉话问题进行总结,为日常优化提供一定的参考。

关键词:掉话GSM 优化一、引言在移动通信中,掉话是指在分配了话音信道(TCH)后,由于某种原因,使呼叫丢失或中断,正常通话无法进行的现象。

掉话不仅影响网络指标,而且会给用户造成许多不便,是用户投诉的热点。

二、原因分析及解决(一)干扰1、干扰原因GSM系统内部干扰主要由以下几个方面的原因产生:(1)频率规划不合理,引起同、邻频干扰;(2)基站或手机功率设置不合理,引起下、上行链路干扰;(3)频率复用不合理;(4)由于多径效应、建筑物反射等造成干扰。

2、问题定位干扰可能是网外或网内的,存在于上行信号或下行信号中,我们可采用多种方法来定位干扰。

(1)从话统上分析,找出可能受到干扰的小区。

(2)结合用户投诉,在可能受干扰的地方进行通话路测,检查下行干扰。

还可用测试手机锁频拨打测试,观察是否在某个频点上受到干扰。

(3)检查频率规划,是否存在规划不当的地方而出现同邻频干扰。

(4)对可能存在干扰的频点进行调整,看是否能避开或降低干扰。

(5)排除设备方面的原因造成的干扰。

(6)信令分析在我们的路测过程中,看到的是下行的干扰,同样,我们可以通过信令仪分析ABIS口的通话质量及电平的对应情况来确定是否有上行干扰。

若在信令分析仪上看到通话质量很差而接收电平较高,我们可以确定有上行干扰。

(7)通过以上方法仍不能很好的排除干扰,可使用频谱仪进行扫频,找出干扰频点,进一步查出干扰源。

3、解决措施(1)进行实际路测。

根据实际情况,通过调整相关小区的基站发射功率、天线倾角,或调整频点规划等避免干扰。

(2)使用不连续发射(DTX)、跳频技术、功率控制及分集技术(3)解决由设备自身问题产生的干扰(如:载频板自激、天线互调干扰等)(4)排除网外干扰(5)频率规划(二)覆盖1、原因(1)不连续覆盖(盲区)(2)室内覆盖差(3)孤岛(4)覆盖过小2、问题定位对覆盖不足的地区进行较大范围的路测,观察信号电平大小,切换是否正常,是否存在掉话等,还可借助OMC话统查看BSC整体掉话率,及其它相关的话统,来辅助判断。

1、MS呼叫未接通：问题描述: 在做DT测试过程中发生了一次未接通，地点是LAC区交接处.在DT测试的行程中，可能发生数次跨LAC区的切换，极易发生掉话或未接通情况。

主要有以下三条信令消息：UL：CHANNEL REQUESTDL：IMMEDIATE ASSIGNMENTUL：CM SERVICE REQUEST问题分析: (1)在上行的CM SERVICE REQUEST信令发出后，没有下行的响应，通话状态由起呼直接转为空闲模式（IDLE），由此可以断定发生了一次未接通。

由于上行UL：CM SERVICE REQUEST是MS发起的对SDCCH的申请，发出申请后没有应答，没有出现标志呼叫接通的信令消息，可以断定发生了一次未接通情况。

其原因可能为该服务小区的SDCCH 信道拥塞，也可能是由于无线环境的恶化造成SDCCH信令丢失。

因为此次DT测试发生在跨数个LAC的路段，而且是上一个通话刚刚结束，起初判断可能是发生了一次位置更新。

(2) 位置更新信令消息如下：DL：CHANNEL RELEASEUL：CHANNEL REQUEST（开始位置更新）DL：IMMEDIATE ASSIGNMENTUL：LOCATION UPDATING REQUESTDL：AUTHENTICATION REQUESTUL：AUTHENTICATION RESPONSEDL：LOCATION UPDATING ACCEPTUL：TMSI REALLOCATION COMPLETEDL：CHANNEL RELEASE结合此例的第三层信令消息来看，例子中MS发出了UL：CM SERVICE REQUEST，并不是UL：LOCATION UPDATING REQUEST，由此可以判断出此例并非是位置更新。

2 、位置更新导致数据吞吐量为0问题描述: 在某路段,进行数据业务测试时,发现MS数据吞吐量变为0,没有了与GPRS网络的连接.问题分析: (1) 在该路段进行语音业务测试, 确认已经完全覆盖.(2) 分析当时数据业务测试的层3信令. 当时的信令为:DL：SYSTEM INFORMATION TYPE 1UL：LOCATION UPDATING REQUESTUL：CHANNEL REQUEST初步定位数据吞吐量变为0的原因是MS执行了一次跨路由区的小区重选(3) 对比在当时显示图的信令部分可以明显的看出该MS正在做位置更新.3 、FTP下载中断问题描述: 在DT FTP下载测试中，MS已成功登陆FTP Server，并已经开始下载数据，FTP下载进度为9％，在经过一次小区重选后, FTP下载不能继续进行，在一系列的Ping fail后，FTP掉线.问题分析: (1) 查看层三信令,具体显示如下：Direction Type Layer 3 MessageUL GPRS SM Deactivate PDP Context RequestDL RR System Information Type 13UL RR Channel RequestDL RR Immediate AssignmentDL GPRS SM Deactivate PDP Context Accept发现在事件列表中有PDP Deactivated的消息，在层三消息中可以看到是手机发起的上行消息.(2)发生这种情况可能有3种原因：一是手机在测试过程中电缆的某个接口发生了松动，这样手机可能会发出PDP去激活申请。

VoLTE经验总结1 广州VOLTE网络质量现状经过近三个月的优化工作,广州ATU网格内,掉话率逐步改善,从%四月下降至%七月；接通率从%提升至6月份的%,七月份下降至%;七月份测试期间核心网的IOT测试也在进行；较多invite 500、SIP unknown、MT CSFB 等异常问题导致的连续多次未接通;广东公司计划在本周对广州IMS进行华为IMS替换爱立信IMS的操作,故七月份测试遇到的异常IMS相关问题分析进度暂缓;2 广州VoLTE测试问题优化进展异频重定向掉话问题验证问题解决背景：中兴eNodeB在P01版本下,因邻区缺失导致异频重定向掉话,该问题需升级P02版本解决;网格44、45测试过程中未发生异频重定向掉话,信令上分析测试过程中出现过多次连续上报异频A3的测报,未切换也未发生重定向,P02版本禁止QCI 1 业务异频重定向功能生效;异系统重定向掉话问题验证问题解决背景：中兴eNodeB在P01版本下,VoLTE发生重定向掉话,该问题需升级P02版本解决; 网格44、45基础覆盖较差,以往拉网测试均会发生多次系统重定向掉话,7月24日,网格44、45完成P02版本升级,升级后重定向掉话问题解决,拉网测试掉话率改善明显;P02版本禁止QCI 1业务重定向功能打开,终端上报A2盲重定向门限或B2事件2G邻区信息错误等前期会导致重定向的情况下,网络均未下发重定向,VoLTE业务保持通话结束后自动挂机,未产生掉话事件TM3/8转换掉话问题验证问题解决背景：中兴eNodeB在P01版本下,VoLTE业务过程中发生TM3到TM8模式转换,因为基站提前转换导致终端掉话,该问题需升级P02版本解决;8月3日,网格45所有升级站点打开TM3/8自适应,验证VoLTE业务在TM3与TM8进行转换时是否掉话,测试结果如下：网格45遍历拉网测试中出现26次TM3向TM8的模式转换,转换正常未发生异常;X2开启告警验证问题解决背景：广州前期因中兴网管告警问题未打开X2接口,导致跨站重建立不可用,需升级P02版本对X2告警量进行抑制;8月5日,网格44、45所有升级站点打开X2接口功能,指定开启X2自配置站点213个,8月6日统计站点X2偶联条数共计4604条;告警问题：网格44、45开启X2后,8月6日网管出现60多条X2断链告警,告警主要原因：a、传输不通,部分微站无法与宏站正常建链；b、个别小区被蔽塞不能正常建链；升级后EMS网管上只出X2断链告警,并且所有基站仅出1条多条X2断链,无SCTP断链告警,网管上可明确区分X2与S1告警,告警量大幅下降;X2开启跨站重建立功能验证P02版本支持无邻区的跨站重建立,在X2链路建立后,对于无邻区跨站重建立带来一定的增益,提高跨站重建立的效率；X2开启,网格44统计VoLTE拉网发生重建立请求共14次,跨站重建成功6次；从性能指标统计来看,RRC重建成功率从50%左右提升至80%左右;原理：目标小区通过终端上报的PCI查找该站点保存的有X2关系的邻站所有小区信息,向所有相同PCI小区索取上下文;3 广州VOLTE优化经验日常优化工作日常优化工作主要从无线覆盖优化、参数优化、系统内外邻区优化,功能优化四个方面着手,与ATU路网、工程建设紧密配合,提升整体网络质量;RLC优先级优化现象：呼叫建立与切换过程冲突,专载被MME释放;呼叫建立过程中专载建立与切换几乎同时发生,MME未收到NAS专载完成消息导致释放专载,终端回复invite580也有上发CANCLE的情况,专载丢失形成未接通事件;原因分析：QCI5设置的RLC优先级为2,高于SRB=2传送NAS层消息配置为3. 导致NAS的层3消息已经比MR要早,但是因为优先级比MR和SIP低,未及时发送;优化措施：降低QCI 5优先级,确保SIP消息及时上传,修改后此类问题改善明显;QCI 5 PDCP DiscardTimer时长优化现象：终端业务建立过程中,出现SIP信息传递丢失的问题,导致收到网络下发的INVITE500或者580等原因值释放;原因分析：UE在无线信道较差的情况下,SIP信令发送或接收不完整或者无法及时传递,导致IMS相关定时器超时而发起会话cancel;经过分析,由于QCI5的pdcp 丢弃时长过小,在无线覆盖较差的地方,上行时延会变大,容易导致QCI5信令丢包;优化措施：QCI5 PDCP DiscardTimer由300ms修改为无穷大优化效果：VoLTE无线接通率提升明显SBC传输协议TCP重传次数优化背景：被叫从2G返回4G后,主叫起呼,被叫首先bye消息,紧接着接连收到多条上一次呼叫的invite,被叫回复bye481\invite486\invite580,呼叫失败;优化措施：爱立信SBC对TCP配置进行了修改：最大重传次数从15次改为5次,最大重传隔间从十几分钟改为15s,此类问题已解决;系统间邻区优化广州LTE网络的GSM邻区关系根据工程参数、共站2G邻区同向小区继承进行规划,同时根据4G、2G道路测试数据匹配进行邻区补充：4G弱信号路段与2G拉网服务小区匹配：利用第三方拉网测试数据,将4G和2G拉网信号强度、经纬度、服务小区等信息导出;通过经纬将4G弱信号RSRP<-110dbm与2G 强信号RXLOV>-95dbm在50米范围内拟合,根据拟合度对2G邻区进行补漏工作5月份第一轮拟合数据,剔除现网已配置的邻区关系,补漏483对；6月份第二轮拟合数据,剔除现网已配置的邻区关系,补漏邻区关系487对;eSRVCC切换提升明显,且由于2G邻区不准确导致的异系统重定向大大减少;重定向掉话中兴区域掉话最严重属于重定向掉话,在中兴基站算法中,以下三种可能发生重定向,重定向释放RRC后,专载同时被拆除,VoLTE业务产生掉话;上行PUSCH功控参数优化背景：4月集团在中兴区域拉网测试发现上行PUSCH发射功率偏高,对现网参数检查发现,中兴区域上行期望功率值设置过高;优化措施：进行功控相关参数优化,现网配置：p0NominalPUSCH =-75 ；puschPCAdjType=0优化值：p0NominalPUSCH =-87 ；puschPCAdjType=2●同等路损情况下,参数修改后,ue发射功率大约下降2~3dB;●目前终端平均上行发射功率仍高于10db,仍需中兴完善现有功控方式;修改后,PUSCH TxPower10dbm以上占比由40%下降到30%左右;RTP丢包率优化背景：4月份测试中,中兴区域RTP丢包率偏高,个别网格甚至达到2%以上;原因分析：在无线质量较好的情况下基本无丢包；无线质量较差的情况下上行丢包现象较为严重,PDCP重传时间超时,数据包将被丢弃；外场测试表明QCI 1 PDCP Discardtimer 配置与RTP丢包率及Jitter有密切关系,QCI 1 PDCP Discardtimer 配置越大,RTP丢包率越低,但Jitter也随之变大;●MOS值与RTP丢包及Jitter关系都较大,目前广州正在601P02版本下进行100ms / 300ms / 500ms / 750ms / 1500ms / infinity完整的对比验证;●进一步联合中兴公司定位RTP丢包率偏高的问题,并推动产品功能算法改进;MME专载保存功能可选功能描述：在基站发起UE-lost原因值的上下文释放请求时,MME保持专载2s不释放,等待空口重建;验证情况：已在GZMME1602下成功验证了该功能;当时无线环境较差,UE发起RRC重建失败,通过MME专载QCI1保持功能使得在新发起的业务过程中,RRC重配中建立包括专载QCI1的3条DRB,不会发生掉话;本次测试中专载保持时长约功能总结：1当无线环境较差时,UE发生RRC重建,若RRC重建成功,将不会掉话;2MME侧也可以在RRC重建失败后,通过MME专载QCI1保持功能使得在新发起的业务过程中,专载QCI1继续保持,也可使得不掉话;3此功能为爱立信MME非必选功能,建议打开;但是该功能不在集采目录,暂时无法采购; 专载释放与切换冲突,通话结束未收到专载释放掉话问题描述：在拉网测试过程中,通话挂机后,主叫上报BYE消息,IMS回BYE200消息前后,同时发生切换,未收到EPS专载释放请求,1s后软件统计掉话;问题分析：经分析MME log,发现MME未收到PGW下发的delete bearer request消息;当X2切换触发SGW-initiated bearer modification procedure完整信令是CCR-CCA,如果此时SIP挂机触发PCRF也发RAR给PGW,由于Gx链路时延等原因,使得RAR先于CCA到达PGW,根据协议规定,PGW会继续SGW-initiated bearer modification procedure而reject RAR result code DIAMETER_OUT_OF_SPACE; 优化措施：当前解决办法：1缩短DRA时延配置;2修改SAPC到DRA链路为主-备模式,保证CCA和RAR走同一路径和到达PGW的先后顺序;优化结果：近期调整后的网格测试,暂时没有发现BYE200消息前后发生的切换没释放QCI 1专载的情况;通话结束MME收到del bearer req,专载释放与切换冲突,基站未下发NAS问题描述：通话挂机后,主叫上报BYE消息,IMS回BYE200消息前后,同时发生切换,EPS 专载没有释放,1s后软件统计掉话;问题分析：主叫挂机后,MME收到del bearer req,下发Deactivate EPS bearer context Request给源eNB携带NAS释放专载,但同时源eNB触发X2切换,向MME响应ERABrelease response X2-Handover-Triggered,NAS消息未下发到;根据协议中有描述当eNB在触发X2切换时,eNB将不传递NAS消息;优化措施：属测试软件统计问题,建议软件加以剔除该问题;4 存在问题和建议设备功能问题：●切换冲突问题：基站无法解码SIP消息,UE专载建立完成的NAS消息上报时间无法确认,基站侧难以彻底解决,需要核心网做相应的功能优化,●呼叫过程eSRVCC：IMS不支持呼叫过程中发生eSRVCC,在4g网络覆盖达到2g规模之前,该问题都不可避免存在;终端eSRVCC测量性能提升4G弱覆盖比例较高：广州网格范围内黑点路段603个,是VoLITE业务问题多发路段,大部分需要加站解决,专项整治计划进度和质量不在项目把控范围;而目前芯片在测量GSM 邻区的时延较长,存在LTE弱信号拖死掉话的较大概率;2 案例分析典型案例案例1：LTE弱覆盖,eSRVCC切换不及时掉话10:57:基站下发异频异系统测量报告,包含2G频点及B2门限LTE:-110,GERAN:-9510:57:,主叫达到B2门限10:57:,主叫RSRP已恶化至-117dBm,SINR至-3,但终端仍没有上报B2事件10:58:,RTP包不能正常收发,10s后RTP inactivity定时器触发,会话中断,出现掉话：解决建议：①规范LTE频点配置,清理多余异频频点,缩短终端测量周期；②终端芯片提高测量能力,尽快实现CDRX休眠期测量功能;案例2：VoLTE单通现象VoLTE单通现象分为两类：一是VoLTE打VoLTE单通,二是VoLTE拨打GSM单通;经分析,第一类主要是终端问题,第二类主要是网络问题;注：红圈为RTP包抓包位置案例3：eNodeB参数配置不合理,导致eSRVCC失败问题现象：终端发生eSRVCC时,在LTE向GSM切换过程中产生掉话;问题分析：终端可以正常收到测控消息,并上报测量报告,且掉话发生在向GSM切换过程中,是GSM或者和基站侧参数设置问题;问题解决：基站BsCAccess-ID项中的管理状态为Locked,设置有误;将该状态修改为Unlock 后,对该站点进行重启后发现eSRVCC功能正常;空口信令判断案例案例1：RRC重建失败,无线网问题现象：切换失败导致RRC释放,重建RRC未成功,重新进行RRC申请,QCI=1的承载未建立成功,导致掉话分析：呼叫重建失败后,新小区重新申请RRC,未能建立VOLTE专载,导致掉话;该流程均由ENODEB控制执行;而切换失败的原因往往是无线环境问题、参数配置不合理、邻区漏配、非竞争随机接入异常等,均为无线网问题;结论：切换失败与RRC重申请流程均与EUTRAN相关,因此认定为无线网问题; 案例2：基站异常导致双端无下行信令及RTP包断传,无线网问题现象：主被叫VOLTE接通后,在同一小区同时发生缺失下行信令20秒,此后数秒发生终端上发bye request挂断;分析：丢信令之前,主被叫双端处于同一小区,且RTP包双向传输正常;丢信令期间,终端测量信息完整,但在2秒后发生RTP包只有终端向网络单向传输,未再有任何网络下发的RTP包,高度怀疑基站临时故障导致;结论：软件显示丢信令,但通过进一步分析确认应为基站故障导致;无线网问题; 案例3：VOLTE接通下发生IMS注册掉话,IMS网络问题现象：VOLTE接通后,被叫发生IMS注册且成功,此时主叫收到网络下发的bye request内含注册超时字样分析：按照3GPP协议,终端应在3000秒上发注册,本次华为SBC于3600秒才收到注册请求,此时IMS认为注册超时,对主叫下发了sip bye消息释放了;但通过进一步确认,终端实际于600秒前已上发了注册消息UDP,但此时恰好在G网下,未收到回复：注：同样类型的掉话也有600秒前处于LTE网TCP,而未收到OK或未鉴权回复的情况结论：前10分钟的注册失败,导致了后续的IMS通话中释放,虽然终端前一次的失败处理机制可能存在问题,但仍然体现出IMS对通话中发生注册时直接释放会话的措施欠妥;网元流程判断案例案例1：被叫收到寻呼但未收到INVITE请求,核心网问题现象：主叫上发了invite,被叫收到了寻呼且建立RRC成功,此时应收到下行的invite,但始终未收到;分析：被叫响应寻呼并进行了RRC申请,表明MME已收到由SGW触发的数据业务请求,即sip invite消息应由IMS网元的SBC下发给了PGW、SGW;①Sip invite消息由IMS网元SBC下发到被叫核心网网元PGW②PGW转发给SGW,SGW通过S11触发MME进行寻呼被叫③被叫被寻呼到,并完成RRC连接与建立默认承载所需RAB,接收数据结论：收到寻呼消息表示sip invite数据包已经到达了LTE核心网,未能继续下发当前怀疑是sip数据在S/PGW异常丢失;案例2：重配置消息释放DRB承载,无线网与核心网配合问题现象：被叫上发sip183后,在激活EPS承载之前,终端上报了1条A3测报,激活EPS 后,发生切换重配置消息中释放了QCI=1的DRB;分析：起呼时MME进行激活EPS承载流程过程中,恰好发生S1切换时,由于EPS 承载建立未完成,MME在切换准备阶段,对下发到目标小区的切换准备的请求消息中不携带QCI=1的VOLTE专载,导致VOLTE专载源小区完成的情况下,在目标小区被释放,切换完成后呼叫中断①切换准备时,MME向目标小区发切换请求,RAB建立请求表只有2条,无QCI=1的专载②目标小区收到MME的切换请求后,回复的切换确认消息里仅有2条RAB建立③MME向源小区下发的切换命令消息中,只建立2条承载,导致ENODEB释放了QCI=1的VOLTE专载;结论：切换与EPS激活流程碰撞,无线网与核心网配合问题;在进行激活EPS专载过程中,发生切换时,均会造成上述问题,目前还无较好的解决办法;网络设备问题案例总结案例1：中兴ENODEB异频重定向掉话,无线网问题现象：主被叫VOLTE接通后,服务小区信号较差,但未配置异频邻区；通过重定向消息RRC connection release携带频点,由D频段重定向到F频段,但VOLTE呼叫不支持重定向方式的RTP包接续,导致掉话;设备：中兴ENODEB分析：中兴设备为了防止邻区漏配情况下,影响用户在LTE数据业务下的感知质量,默认具备异频重定向功能,但未曾考虑对VOLTE呼叫的接续保持;结论：完善邻区配置,在VOLTE呼叫区域考虑关闭中兴设备的异频重定向功能;案例2：华为基站到卡特切换导致的RTP包传输中断问题,无线网问题现象：主被叫接通状态下,在发生一次由华为设备到卡特设备的切换后,20秒后主被叫终端同时上发了bye request消息,网络侧回复bye487 Request Terminated,后网络去激活了EPS承载,掉话;设备：华为ENODEB与卡特ENODEB分析：PDCP SN SIZE长度有12bit和7bit,目前华为基站配置为12bit,贝尔配置为7bit,两个厂家配置数据不统一;华为enodeb设备具有自适应功能;①在华为小区起呼时,切换到卡特小区时,卡特无自适应功能,PDCP SN不一致导致组包混乱;②当在贝尔小区起呼时,切换到华为小区时,华为PDCP SN自适应为7bit,通话正常; 结论：临时解决方案：华为PDCP SN Size修改为7bit,进行拉网测试主叫呼叫56次,未出现终端主动上发bye的掉话;异常掉话及切换后单通问题基本解决案例3：爱立信IMS网元CS域呼叫处理能力不足问题,IMS网络问题现象：在做互通测试过程中,主叫VOLTE起呼后,被叫始终在TD下未收到寻呼消息,主叫收到网络侧下发trying后,立即收到网络下发的invtie 604Does Not Exist Anywhere,呼叫失败;设备：爱立信IMS分析：空口信令仅能确认,被叫端处于TD网,发INVITE到MGCF,MGCF回复604 Does Not Exist Anywhere;该问题为爱立信IMS网元MGCF默认配置仅能同时容纳32个CS域呼叫,导致互通测试过程中,由于容量不足,造成大量连续未接通;结论：爱立信IMS网元MGCF默认配置容量偏小,发生以上问题后,经过扩容已达可处理2、3G呼叫320个;案例4：华为EPC修改EPS与切换碰撞,拒绝承载修改;核心网问题现象：主叫VOLTE起呼后,收到网络回复trying,激活了EPS承载后,又进行了1次EPS承载的修改,此时主叫侧在发生了1次LTE的切换后,收到IMS网络下发的sip503消息,服务不可得;设备：华为EPC分析：某地在激活EPS完成后,仍需要进行2次EPS承载的修改,本次呼叫时第2次EPS的修改空口信令不可见恰好与切换同时发生,当IMS要求核心网PCRF需要对EPS承载进行修改时,由于切换具有更高的优先级,华为EPC拒绝了承载更新,而只执行切换,导致IMS下发sip 503消息中断呼叫该市合适的CQI=1的EPS承载建立需要3个步骤：①CQI=1的初始EPS承载建立,GBR=40kbps但TFT无IPV6地址②修改GBR49kbps支持高清语音并对TFT内的增加IPV6地址以及UDP端口进行修改③在现有TFT中再新建两个ptf;结论：冗余的EPS承载修改TFT,一方面导致了呼叫建立时延长；同时增加了与切换发生冲突的几率；华为EPC在切换与修改EPS承载冲突时,不具备同时处理或排队处理的能力,导致直接以“资源临时不可得”拒绝了承载更新;一方面建议降低EPS 承载修改次数,减少切换碰撞几率与时延；另一方面建议华为EPC进行升级;案例5：华为EPC、中兴IMS协议理解不一致;IMS网络问题升级SBC解决故归此类现象：VOLTE起呼后,EPS承载激活完成,有一定几率1秒后直接收到网络直接下发sip 500消息Server Internal Error,中断呼叫;设备：华为EPC、中兴IMS分析：EPC按照3GPP规范产生的计费标识中包含“0a”的内容,但在IMS网络中,按照SIP协议将“0a”解析成换行符,造成对计费标识的误读;导致中兴IMS网与华为EPC网元PCRF对RX接口中字符格式理解不一致；中兴不支持PCRF通过Rx接口返回的不可见字符,导致了IMS直接下发了内部服务器错误经过IMS内部信令跟踪：①中兴IMS网元SCSCF返回500错误,原因为收到SBC转发的invite request消息携带的PCV头部有问题,发现换行符0A,导致S-CSCF网元上解码认为头部结束,从而认为不合语法规范,获取ecid失败②华为EPC网元PCRF通过Rx接口返回接入网络计费标识Access-Network-Charging-Identifier-value,至中兴IMS SBC,而后中兴SBC通过ecid参数来HEXDIG编码上述计费标识信息协议：The Access-Network-Charging-Identifier-Value AVP AVP code 503 is of type OctetString, and contains a charging identifier结论：即3GPP该计费标识可以包含字符串形式,中兴按IMS SIP协议理解ecid只能是可见字符,对字符串形式不进行HEXDIG转换,导致了上述问题;临时解决方案,中兴SBC进行相应的版本或补丁解决,支持不可见字符;。

全网CS掉话统计类型信令流程如下：描述：UE在通话过程中，NB向RNC上发RL失败指示（原因：synchronisation_failur）上行失步，致使相隔25s后，RNC向MSC上发IU Release Request（RL failure or RLC error timer expiry）解决方法：1：确认该终端所在位置，以及该区域信号覆盖是否良好（包括RSCP和C/I）2：检查终端所占小区载波及时隙的ISCP值是否符合要求（载波ISCP值可以在LMT-B 上检查，时隙ISCP值可以在OMT上检查）3：核查此小区周围没有没同频或同码组的小区。

信令流程如下:描述：UE在通话过程中，UE向RNC发送测量报告，发起切换，RNC向目标NB发送RL Addtion Request，相隔14s后源NB向RNC回复RL Failure indication，原因值synchronisation_failure，UE与网络失步导致，可能为无线环境较差导致。

20S后RNC模拟UE上报物理信道重配失败，失败原因值：Timeout。

导致掉话。

解决方法：1：确认UE所在的位置及该区域的信号覆盖（包括RSCP和C/I）是否良好；2：登LMT-B核查目标小区是否有硬件的故障。

失败时是否是同一块载波，若是的话针对此载波所对应BBU板卡休眠(针对EMB5116,18AE)3：检查源小区配置的邻区是否合适；4：检查周围是否存在与目标小区同频同码的小区；5：确认该小区邻小区的参数是否正确；6：检查目标小区主载波ISCP值（可以从LMT-B上查询）和所占时隙ISCP值（可以从OMT上查询）；7：在切换到目标小区时RSCP突降。

可以尝试降低1G,2A的测量门限，或降低邻小区的绝对导频门限。

描述：触发小区更新（RL failure）超时。

解决方法：1：确认该终端所在位置，以及该区域信号覆盖是否良好（包括RSCP和C/I）2：检查终端所占小区载波及时隙的ISCP值是否符合要求（载波ISCP值可以在LMT-B上检查，时隙ISCP值可以在OMT上检查）3：核查此小区周围没有没同频或同码组的小区。

未接通分类什么是未接通：根据CMCC规范以主叫Channel request来确定试呼开始，接着出现了Connect，Connect Acknowledge消息中的任何一条就计数为一次接通，否则就计为一次未接通。

以下是常见引起未接通的原因：1、位置更新主叫位置更新：在GSMDT正常测试中，主叫手机在idle状态下有时会发生小区重选现象，小区重选后主叫手机会有两种情况下的位置更新。

一种为在idle时间内主叫手机位置更新顺利完成，另一种为手机小区重选后还未来得及进行位置更新或位置更新未完成，主叫手机就发起起呼命令（channel request），此种情况会导致未接通，网络下发CM Service Reject（Cause＝4，IMSI unknown in VLR）。

被叫位置更新：在GSMDT测试中中是一种常见的现象，具体情况为主叫起呼后，被叫正在进行位置更新，无法正常响应主叫的寻呼命令，最后主叫网络下发Disconnect（Cause Number＝18，No User responding）。

主叫正常起呼后，TCH分配完成，被叫正在做位置更新，最后主叫网络下发Disconnect，导致未接通。

2、SD拥塞由于SDCCH拥塞导致的未接通，需要结合A接口，Abis接口信令跟踪及OMC统计分析。

具体情况为主叫手机起呼Channel Request后，网络无法对其进行正常的立即指配命令。

见网络连续对主叫进行立即指配命令，但均未成功，最后导致未接通，通过分析发现该小区存在SDCCH拥塞现象。

附SD拥塞案例如下：手机占用小区LAC：37318 CI：16807（临潼斜口街道办芷阳村马巧莉），16：11：15发起CHANNEL REQUEST，随即收到下发的IMMEDIATE ASSIGNMENT REJEC，则SDCCH分配失败。

从层3消息中，我们可以看到SDCCH拥塞时，系统会向移动台发送Immediate Assignment Reject消息。

路测的掉话定义从UE侧记录的空口信令上看，在通话过程（连接状态下）中，如果空口的消息，满足以下三个条件的任何一个：1）收到任何的BCH消息（即系统消息）2）收到RRC Release消息且释放的原因值为Not Normal3）收到CC Disconnect（呼叫控制断开），CC Release Complete，CC Release三条消息中的任何一条，而且释放的原因为Not Normal Clearing或者Not Normal，Unspecified。

正常情况下的释放是网络侧或UE主动发起disconnect或者release来发起的，如果没有看到此消息交互过程，UE直接开始读广播回到空闲状态则说明出现了掉话。

另外，路测软件中的事件栏里会给出提示掉话的原因：①弱覆盖引起的掉话②切换引起的掉话③语音质量差引起的掉话④干扰引起的掉话⑤硬件故障引起的掉话⑥传输故障引起的掉话⑦直放站引起的掉话⑧天溃原因引起的掉话TD-SCDMA掉话问题分析1 问题描述掉话率反映了系统业务的通讯保持能力，是用户直接感受的重要性能指标之一。

广义的掉话率应该包含CN和UTRAN的掉话率，由于无线网络优化重点关注UTRAN侧的掉话率指标，本文掉话率描述也重点关注UTRAN侧的掉话及优化方法。

信论坛拥有30万通信专业人员，超过50万份GSM/3G等通信技术资料，是国内领先专注于通信技术和通信人生活的社区。

掉话率的统计是建立在一定业务的基础之上的，极少的业务量所统计出的高掉话率，对网络优化是没有意义的；极高的业务量所统计出的掉话率往往是与拥塞有关。

我们优化时关注的应该是话务量处于负载正常的小区。

2 由覆盖引起的掉话一般情况下，掉话均是以下面的原因引起:服务小区由于各种原因（如无线环境好，功率过高，站点设置太高）产生越区覆盖，导致U E在移动到被越区覆盖的小区后，因无邻区关系配置，导致掉话。

越区覆盖导致的频率干扰和扰码相关性问题。

常见异常事件信令分析目录：一、日常指标中常见异常事件 (2)1、SDCCH拥塞： (2)2、SDCCH分配失败： (3)2.1无线原因引起SDCCH分配失败： (3)2.2 BSS问题引起的SDCCH分配失败： (3)2.3 SDCCH分配失败信令分析： (3)3、SDCCH掉话 (7)3.1无线问题引起SDCCH掉话： (7)3.2 BSS问题引起SDCCH掉话： (7)3.3 SDCCH掉话信令分析 (8)4、TCH拥塞 (10)5、TCH分配失败 (11)5.1无线原因引起的TCH分配失败： (11)5.2 BSS原因引起的TCH分配失败： (12)5.3 TCH分配失败信令分析： (13)6、TCH掉话 (16)6.1无线问题引起TCH掉话： (16)6.2切换失败引起TCH掉话： (17)6.3 BSS内部原因引起TCH掉话： (17)6.4传输问题引起TCH掉话： (17)6.5 TCH掉话信令分析： (18)6.5.1 MC736掉话 (18)6.5.2 MC621掉话 (19)6.5.3 MC14C掉话 (21)6.5.4 MC739掉话 (21)6.5.5 正常的挂机 (22)7、切换异常事件 (26)7.1、无线原因引起的切换失败返回信令流程（小区间异步切换）： (26)7.2、系统原因（BSS问题）引起的切换失败 (26)7.3、切换失败信令分析： (26)二、DT测试中的异常事件 (30)1、未接通 (30)1.1由于TCH拥塞 (30)1.2位置更新引起 (33)2、paging失败 (35)3、TCH掉话 (35)三、附录 (38)Abis口信令名词缩写解释： (38)一、日常指标中常见异常事件日常指标中常见异常事件主要表现为：SDCCH拥塞、SDCCH分配失败、SDCCH 掉话、TCH拥塞、TCH分配失败、TCH掉话、TCH切换失败1、SDCCH拥塞：信令流程如下：MC02a 位置更新次数MC02h 所有主叫电话占用SDCCH次数MC04 SDCCH拥塞次数当用户发起CHANNEL REQUEST时，网络发现无空闲的SDCCH信道时，BSC将会：如果小区参数En_Imm_Ass_Rej=“True”，则发Immediately Assignment Reject；否则Channel Required消息。

关于VOLTE掉话率定位分析及优化1.1.1.1.优化思路定界流程：1.1.1.2.定位及优化1.1.1.2.1.基于话统定位优化流程对小区的QCI1的ERAB异常释放原因进行统计分析。

➢对于传输层问题占比大，则需传输侧进行排查分析；➢切换流程失败原因则重点分析无线质量、邻区关系、参数配置；●排查源小区及目标小区覆盖、干扰等无线质量情况，避免切换时与目标小区同步失败。

●核查邻区关系及参数，并结合地理图层确保已完善周报邻区，保证邻区关系及参数合理性；●参数一致性：核查确保外部邻区基站标识、小区标识、频点、PCI与邻区小区实际参数一致性、避免测量上报错误小区导致切换失败。

●核查切换参数配置：现网同异频切换基本都是基于A3事件：Mn+Ofn+Ocn-Hys>Ms+Ofs+Ocs+Off。

同频切换参数，主要核查优化同频切换参数组ID的同频切换幅度迟滞、同频切换偏置、同频切换时间迟滞：异频切换参数，主要核查优化异频A3偏置、基于A3的异频A1 RSRP触发门限、基于A3的异频A2 RSRP触发门限。

异系统的切换参数，主要合理设置 A2 测量门限，避免由于测量过晚导致终端来不及测量目标小区信号无法切换掉话；➢无线层问题原因则重点排查弱覆盖、过覆盖、PCI模3干扰、外部干扰、参数配置等；●借助MR数据等措施判断弱覆盖及优化；●核查小区干扰情况并进行处理优化；●通过CQI上报指标统计各调制方式占比，可反映下行信道质量情况，正常情况是64QAM远大于QPSK占比，反之则说明无线质量存在异常。

如下为正常小区下各调制方式占比情况：●通过性能平台TA数据统计评估是否存在过覆盖问题，当TA统计距离明显大于最小站间距，则该小区极可能存在过覆盖。

对于过覆盖问题需进行增大下倾角、降低功率、站点整改等。

➢无线网络拥塞原因。

对于无线网络拥塞原因导致语音掉话，则需对拥塞原因进行排查及扩容等优化处理。

1.1.1.2.2.基于路测定位优化流程➢基于测试数据在ATU平台进行异常事件统计。

BYE 500掉话分析
1问题描述
16年4月1日CQT测试，EPC和IMS核心网进行信令跟踪期间出现主叫UE在通话结束时，上发IMS_SIP_BYE->Request后，没有收到IMS_SIP_BYE->OK信令，IMS下发BYE500，导致主叫掉话。

2问题分析
主叫信令截图
被叫信令截图
观察主叫UE信令，主叫UE在09:07:57发起IMS_SIP_INVITE->Request做语音业务，09:08:02上报IMS发ACK，在09:11:02通话180s完成后，主叫UE发起IMS_SIP_BYE->Request 结束通话，但是没有收到IMS回复的IMS_SIP_BYE->OK信令，此时主叫UE无线环境良好(RSRP:-81,SINR:30),在09:11:08收到IMS下发的IMS_SIP_BYE 500信令，信令内容为
Content = Warning: 399 10.189.231.73 "SS210100F116L311[00000] No Response From Peer" ，之后主叫UE释放专载资源，软件统计为主叫掉话，查看被叫能正常释放。

此问题连续出现2次。

3解决方法
此次CQT测试PCRF和EPC及IMS已跟踪信令，已将信令节点问题分析发给IMS、EPC、PCRF核查.对出现掉话的信令进行分析，目前初步怀疑与智能网签约有关，已经联系爱立信HSS取消智能网签约进行测试，请现场进行测试、验证在发送500错误的时候，有接收到智能网平台下发的option的消息，初步怀疑存在流程上的冲突，同智能网平台沟通，预计4月14日左右会修改option的检测方式，后续进行验证测试正常。

后续验证测试结果：。