简介这是一份VoLTE掉话分析的实战总结文档面向通信工程师、网络优化人员及4G/VoLTE技术学习者。资源为单个PDF文件压缩包大小2.58MB内容精炼聚焦。目前已有364人学习下载。文档基于广州ATU网格实际优化项目呈现掉话率自11.5%降至3.27%的改善过程并针对异频重定向、异系统重定向、TM3/8模式转换、X2接口告警等典型场景给出中兴eNodeB从P01升级至P02版本的定位与解决方案附有26次TM3向TM8转换无异常的实测验证。同时涵盖RLC优先级优化、QCI 5 PDCP丢弃定时器调整、SBC TCP重传次数修改等参数调优经验以及系统间邻区补漏、上行PUSCH功控等日常优化方法。文档还解释了X2跨站重建立原理及RRC重建成功率由50%提升至80%的成效。读者可借此掌握掉话分析思路、排障步骤与可复用的优化措施是VoLTE网络质量提升的实用参考。1. VOLTE掉话分析一个弱覆盖之外的掉话四层信令里找根因做无线网优的没有谁不怕“VOLTE掉话分析”这几个字。掉话率指标看着只是零点几用户感知却最直接一句话说到一半断了比网页打不开更容易引发投诉。很多刚接触这个方向的分析师习惯性把掉话全归到弱覆盖头上跑到现场一测RSRP、SINR全正常掉话却照旧。这类问题往往藏在RRC、S1AP、SIP、Gm四层信令的交叉区域不拉话单不对时间线根本看不出来。这篇笔记把掉话怎么分边、用什么字段定位、常见翻车点在哪讲透适合网优、核心网运维以及天天看投诉数据的一线工程师。2. VOLTE掉话先分边无线侧与核心网侧的责任边界与信令特征2.1 从QCI1承载释放看掉话归属VOLTE语音走的是QCI1承载这是GBR承载和上网用的QCI9不一样。掉话的本质是QCI1承载被异常释放或者释放后UE没能恢复会话。分析前先要回答一个问题这次释放是哪一侧发起的XDR话单里通常能找到UE Context Release信令里面带S1AP Cause值这个值直接告诉你释放来自哪一侧。UE侧发起释放多见于用户手动挂断或终端异常这类不是掉话统计时要剔掉。网络侧发起释放要分两种eNB发起和核心网发起。eNB发起释放S1AP Cause多半落在radio network层典型场景是无线链路失败RLF触发RRC重建失败核心网发起释放则是MME或SGW检测到SIP会话异常比如Precondition资源预留失败。很多新手拿到掉话小区先扑到地图上看覆盖这个习惯不好。先定发起方再决定往哪个方向查才能避免在错误层面浪费时间。实际取数时XDR表里的释放原因字段通常是字符串或码值。字符串字段常见的有NORMAL_RELEASE、RADIO_LINK_FAILURE、NETWORK_INITIATED等码值字段则需要关联码值字典。不要凭记忆猜先看数据字典否则会把切换失败统计成掉话把用户挂断也统计成掉话指标失真。2.2 无线侧掉话的信令特征与判断依据无线侧掉话最典型的是RRC重建失败。正常流程是这样UE检测到物理层失步启动T310定时器定时器超时后发起RRC重建请求重建成功呼叫能救回来不算掉话重建失败或UE压根没发起重建QCI1承载就会被eNB释放。在信令时间线上看先是空口RRC Reconfiguration带着measConfig下发随后出现N310次失步指示T310启动T310超时后出现RRCConnectionReestablishmentRequest如果网络回了RRCConnectionReestablishmentReject基本就是一次典型的无线侧掉话。分析这类问题要去对空口日志里的RSRP和SINR轨迹重点不是平均电平而是最后几百毫秒的衰落趋势。我见过不少小区平均RSRP在-90dBm以上掉话前200毫秒却掉到-110dBm以下这是移动性不足不是覆盖黑洞。还要看PHRPower Headroom Report。如果UE已经到最大发射功率还解不出PUCCH说明上行受限这时候补下行覆盖参数没用反而是越补越虚。很多无线侧掉话的根因不在下行覆盖而在上行的干扰漏检。RSRP好不等于能通话SINR好也不等于不掉话要把上行功率余量和SRS SINR一起看。2.3 核心网侧与互操作场景别把SIP层问题赖给空口核心网侧掉话在信令上往往没有空口失步痕迹而是先出现SIP消息异常。最常见的两个响应码580 Precondition Failure表示资源预留没成功网络侧主动拆线503 Service Unavailable多出现在核心网过载或编解码协商不一致时。分析核心网侧掉话不能只看eNB的KPI要把核心网SIGLOG里的SIP消息和XDR关联起来。有一个特殊场景容易被忽略SRVCC切换。用户从VOLTE覆盖边缘走到2G/3G覆盖区如果SRVCC切换信令没走完QCI1承载被释放形成一次掉话。判断方法简单在XDR里看有没有SRVCC切换请求以及切换完成消息是否回。没回完成多半是目标小区资源接纳失败或者eNodeB的SRVCC邻区配置漏配。SRVCC失败掉话和普通无线掉话在指标上都会被统计成掉话处理方式完全不同。前者要去核查BSC/RNC侧邻区表和电路资源后者才是射频优化的事。分错方向调一个月参数也压不下掉话率。以下是一张可以直接打印出来用的分边判断表释放发起方信令特征常见原因优先排查方向UE侧空口出现Disconnect或SIP BYE用户挂断、终端异常核对统计口径无需无线优化eNB侧RRC重建失败 / UE Context ReleaseeNB发起RLF、切换超时、资源拥塞空口覆盖与干扰、切换参数、邻区配置核心网侧SIP 580/503 / UE Context ReleaseMME发起Precondition失败、codec协商失败、S1链路异常核心网SIGLOG、codec配置、S1链路检查3. 用XDR话单与SIP信令回溯掉话SQL过滤、时序还原与关键字段3.1 从网管KPI里圈出掉话TOP小区一条SQL先跑起来很多平台自带掉话报表但我建议先自己拉一张带释放原因的话单明细。平台默认口径可能把切换失败和无线重建失败混在一起直接看汇总指标会误导后续分析。我一般会从XDR话单库里按天取数用SQL先圈出TOP小区SELECT cell_id, total_calls, abnormal_release_cnt, drop_rate FROM ( SELECT eci AS cell_id, COUNT(*) AS total_calls, SUM(CASE WHEN release_cause LIKE %ABNORMAL% THEN 1 ELSE 0 END) AS abnormal_release_cnt, ROUND(SUM(CASE WHEN release_cause LIKE %ABNORMAL% THEN 1 ELSE 0 END) * 100.0 / NULLIF(COUNT(*), 0), 2) AS drop_rate FROM volte_xdr WHERE start_time 2025-01-01 00:00:00 AND start_time 2025-01-02 00:00:00 GROUP BY eci ) t WHERE drop_rate 0.5 ORDER BY drop_rate DESC LIMIT 20;这段SQL做了三件事按小区统计全天VOLTE呼叫总数统计release_cause字段里带“ABNORMAL”字样的异常释放次数最后算出单小区掉话率并按降序取TOP20。WHERE条件里用start_time 和 而不是BETWEEN是为了避免边界重复计数这是SQL习惯问题在话单量大的表上能少踩不少坑。参数说明release_cause在不同厂家的XDR表里命名差异很大有的叫release_cause有的叫erab_release_cause_code有的是码值字段。用LIKE %ABNORMAL%是取巧能兼容多种文本描述但如果是纯码值表需要先JOIN码值字典。HAVING掉话率阈值0.5%是工程经验值不同地市网络质量基线不同第一次跑可以先放宽到1%圈出一批再人工复核。注意不同厂家的XDR表结构差异很大release_cause字段名和取值请先查数据字典别照抄字段名。码值表里常见的9代表radio network层释放10代表transport层11代表核心网释放具体以厂家字典为准。3.2 用tshark把SIP释放消息从pcap里抓出来圈出TOP小区之后下一步是找到这个小区某一次掉话的抓包文件。如果是路测软件导出的pcap直接丢给Wireshark或tshark处理。我习惯用tshark因为文件大时不卡而且可以一把梭把关键字段拉出来# 过滤所有SIP失败响应与BYE消息输出关键字段 tshark -r volte_call.pcap -Y sip (sip.Status-Code 580 || sip.Status-Code 503 || sip.CSeq.method \BYE\) -T fields -e frame.time -e sip.call_id -e sip.status.code -e sip.CSeq.method -e sip.To-Y后面跟的是显示过滤器逻辑是只保留SIP消息并且是580/503失败响应或者CSeq方法为BYE的消息。580代表Precondition失败503代表服务不可用BYE则是对端主动拆线。注意双引号里的BYE两侧要转义否则bash会把引号吃掉导致过滤失效。如果要从一次呼叫的完整时序里看问题先拿到话单里的Call-ID再按Call-ID把整个会话拉出来# 按call_id拉出整个会话frame.number保持抓包顺序 tshark -r volte_call.pcap -Y sip.Call-ID \a1b2c3d4192.0.2.1\ -T fields -e frame.number -e frame.time -e _ws.col.Protocol -e _ws.col.Info这里把a1b2c3d4192.0.2.1替换成话单里查到的实际Call-ID即可。输出的每一行就是该呼叫在SIP层的消息序列配合S1AP和RRC消息就能还原一次掉话的完整过程。实际抓包里SIP消息通常只占很小比例用Call-ID过滤后数据量很小分析起来非常快。提示如果现场没有pcap只有平台导出的文本话单用同样的思路过滤“释放原因”和“响应码”字段效果等价。3.3 把RRC/S1AP/SIP拉成一条时间线三个字段必须对得上掉话分析的核心不是看单条信令而是把四层信令拉成同一条时间线。关联时必须有三个字段做锚点IMSI或IMEI确认是同一个用户Call-ID关联SIP会话时间戳用于判断先后顺序。我一般先把SIP层有没有BYE和失败响应看一遍再回到S1AP找UE Context Release的原因值最后去空口看有没有RRC重建。顺序不能反因为SIP层能直接告诉我们“谁不想打了”——是用户挂断还是网络拆线。如果是网络拆线再看是MME还是eNB发起的释放条件。XDR话单字段空口log对应信息作用IMSI / IMEIUE标识确认是同一个用户call_id / session_idSIP Call-ID关联SIP会话消息S1AP释放时间戳RRC记录时间戳判断释放先后顺序release_causeS1AP Cause空口重建原因区分无线/核心网/传输侧时间线上如果发现同一个消息在两侧时间戳差了几十秒先不要怀疑抓包漏点大概率是时钟不同步或话单打点精度不同第4章会专门讲这个坑。时间线对不上时优先处理时钟偏差而不是硬靠前后关系猜因果。4. VOLTE掉话排查的五个高频坑现象、原因、解决掉话分析翻车往往不在信令难而在口径、时钟和参数细节上。以下五个坑是我在现网反复踩过的每条都按现象、原因、解决三段写方便对照排查。4.1 掉话率指标波动大但TOP小区信令正常现象某小区隔三差五掉话率超过1%信令拉出来却发现释放原因全是正常释放一条异常都没有。原因统计口径没理清。最常见的有三种一是把用户主动挂断也算进掉话二是SRVCC切换成功被统计成掉话三是话单字段映射错误把释放原因的码值对应错。平台自带的掉话率公式往往是一个黑匣子不打开看不出来里面混了什么。解决先核对平台掉话率公式确认分母是总呼叫次数还是QCI1建立成功次数分子是否剔除了正常释放和切换成功再抽查3条话单人工看释放原因。不要急着调参数先把口径洗干净指标自然回落。4.2 RSRP和SINR都很好却反复出现RRC重建失败现象现场测试RSRP在-85dBm上下、SINR超过20dB覆盖好得没话说但信令里就是有RRC重建失败。原因这类情况绝大多数不是下行覆盖问题而是上行方向失步。UE被上行干扰或者发射功率不足基站解不出上行确认触发了失步检测。只看DL指标容易漏掉这个方向。解决看PHR和SRS的SINR轨迹确认UE是否已经满功率发射。如果PHR显示UE一直贴近最大功率说明上行有问题。查同频干扰和底噪TDD制式尤其要查上下行时隙干扰。不要盲目加小区发射功率下行增益对上失步没帮助。4.3 SIP 580响应出现在核心网侧无线侧一切正常现象XDR里看到SIP 580 Precondition Failure但无线侧KPI无异常现场测试也复现不出来。原因580响应的生成点在核心网侧多为语音质量预协商资源预留失败比如codec带宽不足或者QoS协商失败。这与空口质量没有直接关系无线指标自然看不出异常。解决转核心网查Precondition相关网元配置重点看codec优先级列表是否支持对方终端的codec以及预留带宽是否够。如果只改无线参数这个方向的掉话率不会动。4.4 信令关联时间对不上同一场呼叫差了几十秒现象把SIP log和空口log按Call-ID拉出来后同一消息在两侧时间戳差了20秒甚至几分钟导致看起来像是UE先发起拆线。原因核心网网元和eNB的NTP同步漂移或者各厂家话单打点精度不一致有的是毫秒级有的是秒级。时间基线不一致因果判断就会翻车。解决做关联分析前先找一条正常释放呼叫比如用户主动挂断的对比两侧时间差作为系统偏差在SQL里做时间补偿后再关联。不要用原始时间直接判断谁先谁后否则会冤枉无线侧。4.5 切换失败掉话被算进小区掉话率优化了半天邻区没用现象邻区关系完整、切换参数合理掉话率却始终降不下来一查话单全是切换类失败。原因问题可能出在目标小区接纳失败。目标小区存在高干扰或资源拥塞UE切换信令在目标侧超时也可能是X2口配置问题或核心网S1接口数据配置错误。邻区关系只是切换链条上的一环。解决先看S1AP切换请求响应消息里的Cause值区分是radio network层还是transport层。如果多次都是transport层原因查X2和S1链路如果radio network层查目标小区的干扰和资源占用。不要反复调A3事件和CIO偏移。4.6 把上面的坑固化成一套日报动作踩过这些坑之后我习惯把排查过程固化成日报动作。每天拉一次全网QCI1异常释放明细按小区和释放原因分组看趋势出现异常点就按“先看口径、再看发起方、最后对时间线”的三步走定位无线侧原因占比高就多花时间看PHR和SRS核心网原因占比高就把Call-ID和SIP响应码整理好直接转给核心网同事。这套流程跑顺之后处理一个投诉从半天缩短到半小时靠的不是玄学是重复劳动里攒出来的判断顺序。5. 掉话率压不下来的最后一招参数核对清单与验证方法5.1 一张参数核对清单按优先级过一遍信令分析做了三轮还找不到根因时与其继续翻log不如做一次参数核对。很多掉话是配置漂移导致不是单点故障。我常用的清单是按优先级排的每次只核对受影响的小区不全局动参数。参数核对动作影响面T304与同厂家同配置小区对比切换超时会触发RRC重建T310 / N310 / N311确认失步检测与恢复门限匹配无线链路失败判定过严或过松E-RAB异常释放统计口径确认排除正常释放和SRVCC成功掉话率数值是否真实SRVCC邻区与BSC/RNC电路资源核查邻区表和电路状态SRVCC切换失败掉话核心网SIP定时器与codec优先级核查与现网终端能力匹配核心网主动拆线5.2 用“原因码分布不变”来验证参数改得对不对验证参数调整是否有效我的方法比较笨但可靠挑一个掉话集中的路段只把嫌疑参数恢复到与周边正常小区一致连续观察三天同一时段掉话率同时拉话单确认释放原因码分布。指标改善幅度可以不大但释放原因码的分布一定要变。如果原因码分布完全没变化说明参数不是根因不要为了KPI硬压参数。我现在的习惯是每周五拉一次全网QCI1异常释放明细按释放原因码分组看趋势。哪个码上涨就查哪一类配置而不是等投诉到门口再翻黑匣子。这套方法和核对清单适合大多数VOLTE现网写下来也是希望帮到你。本文还有配套的精品资源点击获取
VoLTE掉话分析：从信令分边到参数核对的完整排查指南
简介这是一份VoLTE掉话分析的实战总结文档面向通信工程师、网络优化人员及4G/VoLTE技术学习者。资源为单个PDF文件压缩包大小2.58MB内容精炼聚焦。目前已有364人学习下载。文档基于广州ATU网格实际优化项目呈现掉话率自11.5%降至3.27%的改善过程并针对异频重定向、异系统重定向、TM3/8模式转换、X2接口告警等典型场景给出中兴eNodeB从P01升级至P02版本的定位与解决方案附有26次TM3向TM8转换无异常的实测验证。同时涵盖RLC优先级优化、QCI 5 PDCP丢弃定时器调整、SBC TCP重传次数修改等参数调优经验以及系统间邻区补漏、上行PUSCH功控等日常优化方法。文档还解释了X2跨站重建立原理及RRC重建成功率由50%提升至80%的成效。读者可借此掌握掉话分析思路、排障步骤与可复用的优化措施是VoLTE网络质量提升的实用参考。1. VOLTE掉话分析一个弱覆盖之外的掉话四层信令里找根因做无线网优的没有谁不怕“VOLTE掉话分析”这几个字。掉话率指标看着只是零点几用户感知却最直接一句话说到一半断了比网页打不开更容易引发投诉。很多刚接触这个方向的分析师习惯性把掉话全归到弱覆盖头上跑到现场一测RSRP、SINR全正常掉话却照旧。这类问题往往藏在RRC、S1AP、SIP、Gm四层信令的交叉区域不拉话单不对时间线根本看不出来。这篇笔记把掉话怎么分边、用什么字段定位、常见翻车点在哪讲透适合网优、核心网运维以及天天看投诉数据的一线工程师。2. VOLTE掉话先分边无线侧与核心网侧的责任边界与信令特征2.1 从QCI1承载释放看掉话归属VOLTE语音走的是QCI1承载这是GBR承载和上网用的QCI9不一样。掉话的本质是QCI1承载被异常释放或者释放后UE没能恢复会话。分析前先要回答一个问题这次释放是哪一侧发起的XDR话单里通常能找到UE Context Release信令里面带S1AP Cause值这个值直接告诉你释放来自哪一侧。UE侧发起释放多见于用户手动挂断或终端异常这类不是掉话统计时要剔掉。网络侧发起释放要分两种eNB发起和核心网发起。eNB发起释放S1AP Cause多半落在radio network层典型场景是无线链路失败RLF触发RRC重建失败核心网发起释放则是MME或SGW检测到SIP会话异常比如Precondition资源预留失败。很多新手拿到掉话小区先扑到地图上看覆盖这个习惯不好。先定发起方再决定往哪个方向查才能避免在错误层面浪费时间。实际取数时XDR表里的释放原因字段通常是字符串或码值。字符串字段常见的有NORMAL_RELEASE、RADIO_LINK_FAILURE、NETWORK_INITIATED等码值字段则需要关联码值字典。不要凭记忆猜先看数据字典否则会把切换失败统计成掉话把用户挂断也统计成掉话指标失真。2.2 无线侧掉话的信令特征与判断依据无线侧掉话最典型的是RRC重建失败。正常流程是这样UE检测到物理层失步启动T310定时器定时器超时后发起RRC重建请求重建成功呼叫能救回来不算掉话重建失败或UE压根没发起重建QCI1承载就会被eNB释放。在信令时间线上看先是空口RRC Reconfiguration带着measConfig下发随后出现N310次失步指示T310启动T310超时后出现RRCConnectionReestablishmentRequest如果网络回了RRCConnectionReestablishmentReject基本就是一次典型的无线侧掉话。分析这类问题要去对空口日志里的RSRP和SINR轨迹重点不是平均电平而是最后几百毫秒的衰落趋势。我见过不少小区平均RSRP在-90dBm以上掉话前200毫秒却掉到-110dBm以下这是移动性不足不是覆盖黑洞。还要看PHRPower Headroom Report。如果UE已经到最大发射功率还解不出PUCCH说明上行受限这时候补下行覆盖参数没用反而是越补越虚。很多无线侧掉话的根因不在下行覆盖而在上行的干扰漏检。RSRP好不等于能通话SINR好也不等于不掉话要把上行功率余量和SRS SINR一起看。2.3 核心网侧与互操作场景别把SIP层问题赖给空口核心网侧掉话在信令上往往没有空口失步痕迹而是先出现SIP消息异常。最常见的两个响应码580 Precondition Failure表示资源预留没成功网络侧主动拆线503 Service Unavailable多出现在核心网过载或编解码协商不一致时。分析核心网侧掉话不能只看eNB的KPI要把核心网SIGLOG里的SIP消息和XDR关联起来。有一个特殊场景容易被忽略SRVCC切换。用户从VOLTE覆盖边缘走到2G/3G覆盖区如果SRVCC切换信令没走完QCI1承载被释放形成一次掉话。判断方法简单在XDR里看有没有SRVCC切换请求以及切换完成消息是否回。没回完成多半是目标小区资源接纳失败或者eNodeB的SRVCC邻区配置漏配。SRVCC失败掉话和普通无线掉话在指标上都会被统计成掉话处理方式完全不同。前者要去核查BSC/RNC侧邻区表和电路资源后者才是射频优化的事。分错方向调一个月参数也压不下掉话率。以下是一张可以直接打印出来用的分边判断表释放发起方信令特征常见原因优先排查方向UE侧空口出现Disconnect或SIP BYE用户挂断、终端异常核对统计口径无需无线优化eNB侧RRC重建失败 / UE Context ReleaseeNB发起RLF、切换超时、资源拥塞空口覆盖与干扰、切换参数、邻区配置核心网侧SIP 580/503 / UE Context ReleaseMME发起Precondition失败、codec协商失败、S1链路异常核心网SIGLOG、codec配置、S1链路检查3. 用XDR话单与SIP信令回溯掉话SQL过滤、时序还原与关键字段3.1 从网管KPI里圈出掉话TOP小区一条SQL先跑起来很多平台自带掉话报表但我建议先自己拉一张带释放原因的话单明细。平台默认口径可能把切换失败和无线重建失败混在一起直接看汇总指标会误导后续分析。我一般会从XDR话单库里按天取数用SQL先圈出TOP小区SELECT cell_id, total_calls, abnormal_release_cnt, drop_rate FROM ( SELECT eci AS cell_id, COUNT(*) AS total_calls, SUM(CASE WHEN release_cause LIKE %ABNORMAL% THEN 1 ELSE 0 END) AS abnormal_release_cnt, ROUND(SUM(CASE WHEN release_cause LIKE %ABNORMAL% THEN 1 ELSE 0 END) * 100.0 / NULLIF(COUNT(*), 0), 2) AS drop_rate FROM volte_xdr WHERE start_time 2025-01-01 00:00:00 AND start_time 2025-01-02 00:00:00 GROUP BY eci ) t WHERE drop_rate 0.5 ORDER BY drop_rate DESC LIMIT 20;这段SQL做了三件事按小区统计全天VOLTE呼叫总数统计release_cause字段里带“ABNORMAL”字样的异常释放次数最后算出单小区掉话率并按降序取TOP20。WHERE条件里用start_time 和 而不是BETWEEN是为了避免边界重复计数这是SQL习惯问题在话单量大的表上能少踩不少坑。参数说明release_cause在不同厂家的XDR表里命名差异很大有的叫release_cause有的叫erab_release_cause_code有的是码值字段。用LIKE %ABNORMAL%是取巧能兼容多种文本描述但如果是纯码值表需要先JOIN码值字典。HAVING掉话率阈值0.5%是工程经验值不同地市网络质量基线不同第一次跑可以先放宽到1%圈出一批再人工复核。注意不同厂家的XDR表结构差异很大release_cause字段名和取值请先查数据字典别照抄字段名。码值表里常见的9代表radio network层释放10代表transport层11代表核心网释放具体以厂家字典为准。3.2 用tshark把SIP释放消息从pcap里抓出来圈出TOP小区之后下一步是找到这个小区某一次掉话的抓包文件。如果是路测软件导出的pcap直接丢给Wireshark或tshark处理。我习惯用tshark因为文件大时不卡而且可以一把梭把关键字段拉出来# 过滤所有SIP失败响应与BYE消息输出关键字段 tshark -r volte_call.pcap -Y sip (sip.Status-Code 580 || sip.Status-Code 503 || sip.CSeq.method \BYE\) -T fields -e frame.time -e sip.call_id -e sip.status.code -e sip.CSeq.method -e sip.To-Y后面跟的是显示过滤器逻辑是只保留SIP消息并且是580/503失败响应或者CSeq方法为BYE的消息。580代表Precondition失败503代表服务不可用BYE则是对端主动拆线。注意双引号里的BYE两侧要转义否则bash会把引号吃掉导致过滤失效。如果要从一次呼叫的完整时序里看问题先拿到话单里的Call-ID再按Call-ID把整个会话拉出来# 按call_id拉出整个会话frame.number保持抓包顺序 tshark -r volte_call.pcap -Y sip.Call-ID \a1b2c3d4192.0.2.1\ -T fields -e frame.number -e frame.time -e _ws.col.Protocol -e _ws.col.Info这里把a1b2c3d4192.0.2.1替换成话单里查到的实际Call-ID即可。输出的每一行就是该呼叫在SIP层的消息序列配合S1AP和RRC消息就能还原一次掉话的完整过程。实际抓包里SIP消息通常只占很小比例用Call-ID过滤后数据量很小分析起来非常快。提示如果现场没有pcap只有平台导出的文本话单用同样的思路过滤“释放原因”和“响应码”字段效果等价。3.3 把RRC/S1AP/SIP拉成一条时间线三个字段必须对得上掉话分析的核心不是看单条信令而是把四层信令拉成同一条时间线。关联时必须有三个字段做锚点IMSI或IMEI确认是同一个用户Call-ID关联SIP会话时间戳用于判断先后顺序。我一般先把SIP层有没有BYE和失败响应看一遍再回到S1AP找UE Context Release的原因值最后去空口看有没有RRC重建。顺序不能反因为SIP层能直接告诉我们“谁不想打了”——是用户挂断还是网络拆线。如果是网络拆线再看是MME还是eNB发起的释放条件。XDR话单字段空口log对应信息作用IMSI / IMEIUE标识确认是同一个用户call_id / session_idSIP Call-ID关联SIP会话消息S1AP释放时间戳RRC记录时间戳判断释放先后顺序release_causeS1AP Cause空口重建原因区分无线/核心网/传输侧时间线上如果发现同一个消息在两侧时间戳差了几十秒先不要怀疑抓包漏点大概率是时钟不同步或话单打点精度不同第4章会专门讲这个坑。时间线对不上时优先处理时钟偏差而不是硬靠前后关系猜因果。4. VOLTE掉话排查的五个高频坑现象、原因、解决掉话分析翻车往往不在信令难而在口径、时钟和参数细节上。以下五个坑是我在现网反复踩过的每条都按现象、原因、解决三段写方便对照排查。4.1 掉话率指标波动大但TOP小区信令正常现象某小区隔三差五掉话率超过1%信令拉出来却发现释放原因全是正常释放一条异常都没有。原因统计口径没理清。最常见的有三种一是把用户主动挂断也算进掉话二是SRVCC切换成功被统计成掉话三是话单字段映射错误把释放原因的码值对应错。平台自带的掉话率公式往往是一个黑匣子不打开看不出来里面混了什么。解决先核对平台掉话率公式确认分母是总呼叫次数还是QCI1建立成功次数分子是否剔除了正常释放和切换成功再抽查3条话单人工看释放原因。不要急着调参数先把口径洗干净指标自然回落。4.2 RSRP和SINR都很好却反复出现RRC重建失败现象现场测试RSRP在-85dBm上下、SINR超过20dB覆盖好得没话说但信令里就是有RRC重建失败。原因这类情况绝大多数不是下行覆盖问题而是上行方向失步。UE被上行干扰或者发射功率不足基站解不出上行确认触发了失步检测。只看DL指标容易漏掉这个方向。解决看PHR和SRS的SINR轨迹确认UE是否已经满功率发射。如果PHR显示UE一直贴近最大功率说明上行有问题。查同频干扰和底噪TDD制式尤其要查上下行时隙干扰。不要盲目加小区发射功率下行增益对上失步没帮助。4.3 SIP 580响应出现在核心网侧无线侧一切正常现象XDR里看到SIP 580 Precondition Failure但无线侧KPI无异常现场测试也复现不出来。原因580响应的生成点在核心网侧多为语音质量预协商资源预留失败比如codec带宽不足或者QoS协商失败。这与空口质量没有直接关系无线指标自然看不出异常。解决转核心网查Precondition相关网元配置重点看codec优先级列表是否支持对方终端的codec以及预留带宽是否够。如果只改无线参数这个方向的掉话率不会动。4.4 信令关联时间对不上同一场呼叫差了几十秒现象把SIP log和空口log按Call-ID拉出来后同一消息在两侧时间戳差了20秒甚至几分钟导致看起来像是UE先发起拆线。原因核心网网元和eNB的NTP同步漂移或者各厂家话单打点精度不一致有的是毫秒级有的是秒级。时间基线不一致因果判断就会翻车。解决做关联分析前先找一条正常释放呼叫比如用户主动挂断的对比两侧时间差作为系统偏差在SQL里做时间补偿后再关联。不要用原始时间直接判断谁先谁后否则会冤枉无线侧。4.5 切换失败掉话被算进小区掉话率优化了半天邻区没用现象邻区关系完整、切换参数合理掉话率却始终降不下来一查话单全是切换类失败。原因问题可能出在目标小区接纳失败。目标小区存在高干扰或资源拥塞UE切换信令在目标侧超时也可能是X2口配置问题或核心网S1接口数据配置错误。邻区关系只是切换链条上的一环。解决先看S1AP切换请求响应消息里的Cause值区分是radio network层还是transport层。如果多次都是transport层原因查X2和S1链路如果radio network层查目标小区的干扰和资源占用。不要反复调A3事件和CIO偏移。4.6 把上面的坑固化成一套日报动作踩过这些坑之后我习惯把排查过程固化成日报动作。每天拉一次全网QCI1异常释放明细按小区和释放原因分组看趋势出现异常点就按“先看口径、再看发起方、最后对时间线”的三步走定位无线侧原因占比高就多花时间看PHR和SRS核心网原因占比高就把Call-ID和SIP响应码整理好直接转给核心网同事。这套流程跑顺之后处理一个投诉从半天缩短到半小时靠的不是玄学是重复劳动里攒出来的判断顺序。5. 掉话率压不下来的最后一招参数核对清单与验证方法5.1 一张参数核对清单按优先级过一遍信令分析做了三轮还找不到根因时与其继续翻log不如做一次参数核对。很多掉话是配置漂移导致不是单点故障。我常用的清单是按优先级排的每次只核对受影响的小区不全局动参数。参数核对动作影响面T304与同厂家同配置小区对比切换超时会触发RRC重建T310 / N310 / N311确认失步检测与恢复门限匹配无线链路失败判定过严或过松E-RAB异常释放统计口径确认排除正常释放和SRVCC成功掉话率数值是否真实SRVCC邻区与BSC/RNC电路资源核查邻区表和电路状态SRVCC切换失败掉话核心网SIP定时器与codec优先级核查与现网终端能力匹配核心网主动拆线5.2 用“原因码分布不变”来验证参数改得对不对验证参数调整是否有效我的方法比较笨但可靠挑一个掉话集中的路段只把嫌疑参数恢复到与周边正常小区一致连续观察三天同一时段掉话率同时拉话单确认释放原因码分布。指标改善幅度可以不大但释放原因码的分布一定要变。如果原因码分布完全没变化说明参数不是根因不要为了KPI硬压参数。我现在的习惯是每周五拉一次全网QCI1异常释放明细按释放原因码分组看趋势。哪个码上涨就查哪一类配置而不是等投诉到门口再翻黑匣子。这套方法和核对清单适合大多数VOLTE现网写下来也是希望帮到你。本文还有配套的精品资源点击获取
