简介面向4G网络优化工程师的VoLTE掉话分析文档聚焦中兴eNodeB场景下VoLTE掉话的根因定位与解决路径适合有一定VoLTE基础、负责网络质量提升的优化人员参考。压缩包内为单个PDF文件大小2.58MB内容基于广州某网格四月至七月的实测数据系统梳理掉话率从11.5%降至3.27%的优化过程。已有365人学习下载。文档重点分析了异频重定向、异系统重定向、TM3/8模式转换、X2接口开启及跨站重建立、RLC优先级冲突等典型问题并结合P01/P02版本对比给出可落地的处理思路。针对每一项问题均包含现象、原因、版本措施与验证结果如通过升级P02版本禁止QCI1业务重定向、调整QCI5的RLC优先级减少未接通、优化PDCP DiscardTimer时长改善SIP信令丢包等。此外还整理了系统间邻区拟合补漏与SBC TCP重传配置经验。适合从事VoLTE网络优化、掉话专题分析及中兴设备维护的工程师参考可快速对照排查类似故障场景。1. VoLTE掉话分析是什么一份文档背后的排查体系深夜值班电话响起来某片区的VoLTE掉话率从0.2%抬到了0.8%翻来覆去就那几个小区指标却说不明白是无线断了、核心网拆了会话还是手机自己掉了。这份标题为《(重点)VOLTE掉话分析》的PDF落到工程上就是一套把「通话断了」从用户感知变成可定位、可量化、可复现问题的排查体系。它重点回答三个问题用统一口径判定掉话按场景分类定位根因用参数与信令验证结论。适合网优、核心网维护和终端协议栈三拨人照着做新手能顺着流程走熟手可以直接跳开基础去查参数边界和判定口径。2. 从定义到落点掉话的判定口径、分类与数据源2.1 掉话不是「通话断了」先统一判定口径VoLTE掉话在工程上有一个和用户感知不太一样的定义。用户说「断了」可能是对方挂机、可能是自己没信号、也可能只是听不到声音。而在网络统计里掉话指一次已经建立的话音会话没有经过正常释放流程就被异常拆掉。正常释放的标志很明确SIP层有主叫或被叫发出的BYE且收到了200 OK响应随后QCI 1承载被有序释放。只要不是沿着BYE200 OK这条路径关闭会话无论它在哪个网元发生都应该被纳入掉话分析的候选范围。麻烦的是同一个事件在不同部门眼里长得不一样。无线侧看eNB关注的是QCI 1承载的释放原因值和RRC连接状态弱覆盖导致T310超时、切换失败导致RRC重建失败都会直接体现在设备日志里。核心网看SBC/P-CSCF和EPC侧关注的是SIP会话以什么状态码终结比如480、500、503或者是EPC侧发起PDN连接释放。终端侧则是看AP和CP的日志芯片异常、modem重启、天线失谐都会留下痕迹。三侧的数据源、字段、原因编号都不一致如果不先统一口径同一通电话可能无线侧判正常、核心网判掉话、终端判故障。所以拿到这类「重点」材料我做的第一件事不是翻原因分类而是把判定口径钉死以哪种会话集合作为分母以哪种终结方式作为掉话分子。行业里常见做法是用SEQ信令平台把SIP会话作为主口径凡是承载建立成功但没有BYE200 OK正常终结的会话都算掉话候选无线CHR和终端日志作为佐证用来在候选里再做侧向定界。这样定义的优势在于它不依赖单侧日志的完整性SIP会话是核心网和终端都要参与的任何一侧异常都会反映在会话记录里。口径统一以后掉话率这个数字才有意义。实际工作里经常看到无线侧报0.5%、核心网侧报1.2%的对不上的情况很多不是数据错了而是分子分母根本不是同一批会话。这个问题后面避坑章节还会展开但在这里要记住一条原则讨论掉话率之前先问清楚彼此的判定口径和统计网元不然整个分析过程都在对着数字猜谜。2.2 四类掉话场景拆解无线、核心网、终端、互操作掉话原因在工程上可以粗归为四类无线侧、核心网侧、终端侧和互操作侧。分类本身不是目的是为了让排查顺序有优先级。从CHR、SEQ和DT数据里可以总结一个经验无线侧原因占大多数但纯无线原因并不是每次都是真凶很多时候是互操作或核心网配置问题在无线侧表现成了「信号不好」。无线侧的典型特征是覆盖和质量相关。弱覆盖、SINR差、上行失步最后走到T310超时、RRC重建失败或切换执行失败。这类问题最直观MR数据一拉出来基本能对上RSRP在-115dBm以下的采样点占比和掉话时段往往高度重合。处理方向也比较明确要么补覆盖要么调整切换参数让用户尽早切到更强的小区。核心网侧的特征是无线环境看着正常但SIP会话在中途被打断。常见的有SBC上会话保持超时、DNS解析失败导致呼叫流程异常、EPC侧因为策略或计费触发释放承载。这类问题有一个共同点单看eNB日志释放原因值通常指向「核心网发起」但具体是哪一段SIP信令异常必须到SEQ或SBC侧看状态码才能确认。排查时最怕的就是在MR里找不到问题还硬要在无线侧找理由。终端侧相对隐蔽。芯片日志里AP崩溃、modem重启、射频校准异常会让整个会话突然消失无线和核心网两侧可能连释放原因都留不下。DT测试里偶尔会碰到这种「三侧正常但就是掉线」的案例最后追到终端固件版本。处理办法通常是复现并抓终端日志和厂商协议栈对齐。这类问题占比不高但每次都是硬骨头。互操作侧最常见的就是eSRVCC。语音在LTE和2G/3G之间的连续性全靠这个机制LTE信号低于A2阈值开始测量异系统满足B2条件后触发切换。参数配慢了、邻区漏了、GSM侧质量差都会造成切换失败、切过去之后又掉。体验上就是用户走到边缘还在打电话声音断断续续最后彻底断开屏幕上信号栏从LTE跳成2G然后又消失。把这四类按发生概率排优先级常规做法是先排除无线再查互操作然后看核心网最后才动终端。因为无线和互操作的数据最齐全CHR加MR基本够用核心网需要SEQ权限终端要用户配合抓日志成本最高。这个顺序能保证每一步都有数据支撑不会一上来就陷入终端黑洞。2.3 分析数据从哪来CHR、MR、SEQ、DT四类数据源掉话分析的数据源并不神秘常用到的就是CHR、MR、SEQ和DT这四类每一类能回答的问题都不一样。选错数据源是很常见的翻车原因拿着MR去证明SIP会话被核心网拆掉无论如何都论证不出来。数据源能回答什么回答不了什么获取与使用成本CHR呼叫历史记录承载什么时候建立、什么时候释放、释放原因值、切换流程是否完整SIP层的会话状态码、用户主观感知设备侧导出按IMSI/号码关联中等MR测量报告覆盖水平RSRP、干扰水平SINR、上下行质量会话级信令、核心网动作OMC拉取量大需要聚合统计低SEQ信令追踪平台SIP会话建立与释放码、QCI1承载时序、端到端时延空口质量细节、终端内部状态需要平台权限部分区域无覆盖中高DT路测实际用户感知、事件级复现、终端行为大规模统计趋势需要出车和测试终端高CHR是无线侧最常用的一手数据。它记录了每通电话的呼叫流程、切换链、释放原因能精确到小区和用户。短板也很明显它只反映无线接入网视角SIP会话中间被拆掉这种事在CHR里只能看到「核心网释放承载」这一类模糊原因具体哪一条SIP信令出了问题还得去SEQ确认。MR的作用是补环境。CHR告诉你哪通电话掉了MR告诉你当时那个地方信号是什么状态。把MR的RSRP、SINR分布和掉话时段对齐就能判断覆盖与质量是不是元凶。海量MR数据直接分析效率太低通常先在OMC侧聚合出小区级分布再按重点关注小区拉明细。要注意MR是事件触发的采样不是周期性均匀分布结论要和CHR互相印证。SEQ是定界神器。它把PS域和CS域的信令按用户关联起来从注册、IMS PDN建立、SIP INVITE到BYE全链路回放。掉话分析只要能用SEQ基本能在一个小时里把问题从「掉话小区」推进到「无线、核心网、终端」三选一。局限是部署覆盖和权限不是每个区域每条话都能在平台上看到完整信令。DT是最后的兜底手段。SEQ和CHR都拿不定结论时派车去现场复现带上扫频仪和测试终端把事件、信号、终端日志拉到同一个时间轴上。成本最高但争议最大的case最终还是要靠DT说话。四类数据源配合使用的基本逻辑是CHR圈事件、MR判环境、SEQ定边界、DT做仲裁。3. 掉话分析的标准流程指标聚合、原因定位与信令回溯拿到一份掉话分析任务不建议直接钻进信令细节。标准流程的价值在于让排查有顺序、有依据每一步都能排除一部分可能性。下面这套三步走的方法是从实际项目中反复打磨出来的CHR圈范围、MR验无线、SEQ定边界半天内能完成大多数定界任务。3.1 第一步用KPI和CHR快速圈定问题小区第一步永远是全局扫描掉话率有没有趋势性抬升、集中在哪些拓扑区域、涉及的小区名单是什么。KPI层面一般看两个口径一是会话维度的掉话率二是按小区聚合的QCI1释放次数。趋势上从日粒度看到小时粒度再定位到具体时段往往能直接避开一堆干扰信号。CHR在第一步就派上用场。设备侧导出的CHR通常是一个包含用户标识、小区标识、呼叫流程和释放原因的表格。先按释放原因做一次聚合看清楚问题主要是集中在无线链路失败、切换失败、还是核心网释放再按小区做Top排序。这里给一段常用的处理思路假设CHR已经导出成CSV字段里有call_id、imsi、cell_id、release_cause、qci1_duration。# 统计各释放原因的出现次数定位主要掉话原因类型 awk -F, NR1 {count[$4]} END {for (cause in count) print cause, count[cause]} chr_export.csv | sort -k2 -rn # 按小区和释放原因二维聚合输出Top 20的问题组合 awk -F, NR1 {key$3|$4; count[key]} END {for (k in count) print k, count[k]} chr_export.csv | sort -k3 -rn | head -20第一段命令的作用是把所有掉话记录按释放原因字段统计让你在十秒内看出问题是单一原因主导还是分散分布。第二段命令把小区和释放原因拼成组合键再统计输出的是「哪些小区、以什么原因在掉话」这是下一步现场排查的任务清单。要注意字段序号必须和实际导出的表头一致多数情况下CHR导出的列顺序是可以配置的如果列有调整就把后面的序号改掉。做完聚合以后我一般会再做一个简单的时间分布把一天按小时切成24桶统计每个小时的问题小区数。如果掉话集中在早晚忙时大概率是容量或上行干扰如果集中在某个固定的低业务时段反而要去查配置和外部干扰。这个步骤花五分钟但对后续排查方向的判断价值很大。提示CHR导出后先确认覆盖的时间范围和小区集合避免把历史遗留数据混进本次分析窗口。3.2 第二步MR与切换参数验证无线侧圈出问题小区之后第二步是验证无线侧成不成立。验证工作分两条线并行一条是看覆盖与干扰一条是看切换链路。覆盖与干扰直接拉MR。从OMC导出问题小区的测量报告统计RSRP和SINR分布重点看两个比例RSRP低于-115dBm的采样点占比以及SINR小于0dB的采样点占比。前者反映覆盖后者反映干扰和信号质量。如果掉话时段和这两个比例的抬升时段重合无线侧就有了实锤。# 从MR采样中统计问题小区cell_12345的覆盖质量分布 # mr_data.csv 字段cell_id, rsrp, sinr awk -F, NR1 $1cell_12345 { if ($2 -115) weak; else if ($2 -105) mid; else good; if ($3 0) sinr_bad; total } END { printf 弱覆盖占比(-115以下): %.2f%%\n, weak*100/total; printf 边缘覆盖占比(-115~-105): %.2f%%\n, mid*100/total; printf SINR为负占比: %.2f%%\n, sinr_bad*100/total; } mr_data.csv这段脚本的核心是阈值设置。-115dBm是行业里常用的弱覆盖分界-105dBm是边缘覆盖分界SINR 0dB以下通常认为质量不可用。真实项目中阈值要根据当地传播模型和终端接收灵敏度微调比如密集城区和开阔区域的覆盖绝对值会有差异。脚本输出的三个占比如果明显偏高比如弱覆盖采样超过5%、SINR为负超过10%无线侧就要列入重点排查。切换链路方面我习惯同时看三个指标切换请求次数、切换准备成功率、切换执行成功率。再配合A3偏移量、TTT触发时间这些事件参数判断切换是否过于激进或过于保守。切换准备失败要怀疑目标小区配置或资源准备成功但执行失败要怀疑随机接入、T304超时或目标小区拥塞。切换失败导致的掉话在CHR里通常会留下明显的「切换失败→RRC重建→重建失败」序列和MR一对照就能定性。需要提醒的是MR验证有它的盲区采样点是事件触发的不是周期性均匀分布。无线环境好时UE可能不上报测量导致MR里看到的都是「差采样」。所以MR结论最好和CHR释放原因互相印证单靠MR分布下结论容易误伤。这一步做完无线侧成不成立基本有数了。3.3 第三步SEQ信令把无线问题与核心网问题分开无线侧验证完剩下两类情况需要SEQ进场一是无线侧原因不成立掉话集中发生在好点二是CHR显示「核心网释放承载」但不知道核心网为什么要释放。SEQ信令平台能按用户把IMS会话和承载事件排成时间线直接看SIP层释放码是区分无线与核心网责任最可靠的依据。在SEQ平台上我一般先按IMSI或MSISDN拉出目标时段所有VoLTE会话过滤出SIP释放码不是200的会话再做侧向定界。SIP 200是正常终结这是硬规则。非200状态码里480表示用户暂时不可达500/503表示服务器内部错误或服务不可用408表示请求超时每种码对应的排查方向差别很大。-- 从SEQ平台话单表查询某时段内SIP释放码非200的会话 -- seq_voLte_sessions 字段session_id, imsi, sip_release_code, -- sip_release_side, start_time, end_time, last_rf_cell SELECT session_id, imsi, sip_release_code, sip_release_side, start_time, end_time, last_rf_cell FROM seq_voLte_sessions WHERE start_time 2025-01-06 18:00:00 AND start_time 2025-01-06 19:00:00 AND sip_release_code 200 ORDER BY start_time;这条SQL做的事情很简单把某一小时内非正常终结的会话全部列出来附带释放侧和释放码。sip_release_side字段很关键它标记了释放是哪一侧发起的是UE侧、P-CSCF/SBC侧还是IMS应用服务器侧。配合last_rf_cell字段就能判断这个会话最后附着在哪个小区、无线侧有没有发生过异常。如果非200码会话集中在同一台SBC或同一个接入侧网元基本可以锁定核心网责任如果释放码多样且每个会话都有无线异常前兆责任还是在无线侧。边界情况也要留意。SEQ上SIP释放码正常是200但QCI1承载在SIP结束前就被无线侧释放了这种情况下需要在时间轴上确认承载释放和SIP结束的先后关系。先释放承载再BYE说明无线侧已无法维持语音承载是无线问题先BYE再释放承载是正常流程。SEQ的价值正是这种毫秒级的时序确认日志和KPI都给不了这么精确的因果。到这里一个标准的三步流程就闭环了KPI加CHR圈范围MR加切换参数验无线SEQ定边界。实际项目中这三步通常半天内能完成剩下的工作是根据定界结果进入各自的专项排查。拿到掉话分析任务时不要一上来就翻参数先把流程走完让数据自己说话。4. 参数与定时器掉话率最容易踩的配置点掉话分析做到最后大概率会落到参数核查。参数配置的问题有个特点表面上看只是数字大小实际上决定了无线链路、互操作和承载调度的整个节奏。下面按无线定时器、eSRVCC触发、QCI1调度三个层面拆开讲。4.1 无线链路定时器组T310、N310、T311怎么协同无线侧最常被翻出来的是RRC定时器组尤其是T310、N310、T311和T304。这四个参数决定了无线链路从出问题到被宣判死亡的节奏配得太紧会放大瞬时波动配得太松会掩盖问题甚至恶化用户感知。参数含义常见配置范围对掉话的影响N310收到失步指示的最大次数达到后触发RLF评估110次越小越敏感瞬时波动易触发RLFT310RLF后被判不可恢复前的等待定时器1s3s超时后eNB释放RRC或启动重建T311RRC重建过程的等待定时器5s15s超时则回RRC IDLE会话随之释放T304切换执行定时器目标小区接入超时保护1s2s超时判切换失败回退源小区这四个参数是协同工作的。UE检测到物理层失步连续N310次之后启动T310T310内如果能恢复同步就一切照旧不能恢复就判定无线链路失败进入RRC重建流程由T311约束重建时间。切换场景里则由T304约束UE在目标小区的接入时间。任何一个环节超时结果都是RRC连接异常VoLTE的QCI1承载跟着被释放用户感受到的就是掉话。有一个血泪经验要提为了压低掉话率指标把T310从1s调到3s、T311从10s调到15s指标确实能变好看但用户听到的是十几秒的杂音或对方「喂喂喂」之后才断线。这不是修复问题是把问题从统计指标里藏到了用户感知里。参数调整必须配合覆盖和干扰整治同步做而不是单方面去糊指标。反过来T310配得太短也有问题瞬时快衰落会频繁触发RLF小区边缘掉话率反而上升。参数核查的顺序也很重要。先看N310和T310的配合是否合理再看T311是否给了重建足够的时间窗口最后检查T304在各场景下有没有为小区边缘单独配置。很多设备支持按场景或按小区配置差异化定时器边缘小区用宽松值、城区密集小区用标准值这种做法比全局一套参数更接近最优解。注意动T310这类定时器前先留一份当时的KPI快照调整后对比同小区同时间段数据否则指标变化说不清是参数效果还是场景变化。4.2 eSRVCC触发链路A1/A2与B2的配合VoLTE用户走到LTE边缘时能否平滑切换到2G/3G保住通话完全取决于eSRVCC这条链路的配置。整个触发机制里最关键的事件是A1/A2和B2。A2事件负责启动异系统测量B2事件负责执行到2G/3G的切换判决。它们的阈值和迟滞配错是互操作掉话最常见的原因。A2事件的服务小区门限决定了多早开始测2G/3G。门限设得太低比如RSRP低于-115dBm才触发测量留给执行切换的时间窗口就很短门限设得太高比如-100dBm就触发在城区主信号尚好的区域就会频繁测量增加终端耗电和无效切换。VoLTE业务下A2通常结合语音业务的优先级来设置常见区间在-105dBm到-112dBm之间具体依当地弱覆盖分布决定。A1事件用于回到好点后关闭异系统测量避免乒乓。B2事件是真正的执行开关两个门限构成一个条件服务小区RSRP低于门限1同时目标系统信号高于门限2。门限1一般比A2再低一点确保在切换执行前给无线环境留出余量门限2则要能代表目标2G/3G小区的可用性。GSM侧RxLev低于-95dBm时即使切换过去了也大概率是坏点可能造成切过去就掉。事件作用常见设置区间踩坑点A2启动异系统测量RSRP -105-112dBm设太低触发太晚来不及执行B2门限1LTE侧判决条件RSRP -110-118dBm与A2间隔过小B2迟迟不触发B2门限22G/3G侧可用性条件GSM RxLev -90-95dBm门限过严边缘场景无可用目标邻区与频点目标系统配置按现网扫频配置漏配主用频点切换永远失败实际排查时我一般会在问题路段做一次DT回放eSRVCC相关事件在时间轴上的位置。正常的节奏应该是A2触发后很快进入B2测量B2上报后在几百毫秒内完成切换执行。如果A2和B2之间时间间隔过长说明门限间隔或迟滞参数有问题如果B2上报了但切换失败要转去查目标小区资源和频点配置如果整个eSRVCC序列根本没出现先查功能开关有没有打开。这类问题用CHR也能看切换准备和执行的完整流程都会记录在案但用DT配信令回放更直观。围绕eSRVCC还有一个老生常谈的点邻区配置。门限配得再合理2G/3G邻区里漏了实际覆盖的频点eSRVCC也一样会失败。所以检查参数的同时要拉一次扫频数据把目标区域实际存在的GSM/UMTS频点和邻区配置做差集这一步能解决大量「参数没问题但eSRVCC就是失败」的玄学case。4.3 QCI1承载调度PBR、丢包率与RTP阈值掉话分析的终点往往是话音质量而话音质量与QCI1承载的调度表现直接绑定。QCI1是GBR承载调度器要保证它的优先比特率和时延要求否则语音包在空口排队过长或丢包过多即便没有触发掉话流程用户也已经无法忍受了。调度层面影响最大的两个参数是QCI1的调度优先级和保证比特率。保证比特率决定了调度器为这个承载预留的无线资源下限设置过低时小区拥塞情况下语音包会被其他业务抢占。常见配置是语音承载优先于普通数据承载配合半持续调度来降低控制信道开销。对VoLTE来说行业里通常以RTP丢包率小于1%、时延小于150ms、抖动小于30ms作为质量目标超过这个区间MOS值会出现可感知的下降。RTP层面的表现在CHR或终端日志里可以看到统计。丢包率在1%到3%之间时语音出现断续超过3%可能出现单通或长时间听不到声音持续高丢包可能导致网元侧的RTP定时器超时主动释放承载这种情况在SEQ上看到的SIP释放码往往是408或480。所以丢包率不仅是质量指标也是掉话的前置预警指标。参数核查时还要看PBR和上下行调度的配合。上行语音包需要终端有足够的授权去发送下行则依赖eNB的调度器及时下发给终端。小区里同时存在大量VoLTE用户时调度器要处理好QCI1和其他承载之间的资源池划分划分不当会在忙时出现群体性的语音质量劣化。这一层排查做完掉话分析的参数面基本覆盖完整了无线定时器管链路生死eSRVCC管跨系统延续QCI1调度管质量底线。三者的配置要作为一个整体来评估单独调任何一个参数都可能把问题挪到另一个环节。5. 避坑指南VoLTE掉话分析的5个常见误判掉话分析做得越多越会发现大部分返工不是因为数据不够而是因为误判。误判来回折腾一次至少浪费半天。下面这5条是项目里最常遇到的坑每一条都有过深刻的教训。5.1 eSRVCC成功切换后的正常挂机被当成掉话现象某区域掉话率持续偏高但现场DT复测没有发现明显断话用户感知投诉也没有增加。翻看统计数据掉话集中在2G/3G覆盖良好、LTE边缘的小区。原因统计口径把eSRVCC切到2G/3G后正常结束的通话也计入了掉话。eSRVCC是把VoLTE会话从LTE迁到CS域继续保留通话在2G侧正常结束时释放流程走的是CS域释放很多统计逻辑只看LTE侧没有看到SIP BYE就误判成会话异常终结。解决先把统计口径修正以SEQ信令平台的SIP会话终结类型为准确认会话最终是在哪个域、以什么方式释放。对eSRVCC成功且后续正常挂机的会话在统计里单独归类成「互操作成功延续」不计入掉话分子。修正后重新看指标往往问题面积会缩小一大半。5.2 只看RRC释放原因把核心网问题误判成无线问题现象CHR数据显示大量QCI1承载由核心网发起释放无线环境MR分布正常但分析报告却写成弱覆盖导致后续派人去现场补站问题依旧。原因eNB侧的释放原因值只能说明「谁发起了释放」不能说明「为什么释放」。核心网因为会话保持超时、DNS问题或策略异常释放承载时落到无线侧就是一个「核心网释放」的模糊原因它和无线侧本身没有因果关系。只盯CHR不看SIP层很容易被这个假象带偏。解决对这类释放原因统一走SEQ确认SIP层状态码。如果释放码集中在408、480、500等特定类别并且和无线侧指标没有时间相关性问题定界到核心网。无线侧只需要配合确认在释放发生前的几秒内信号质量没有劣化即可。5.3 A2与B2门限间隔过小eSRVCC触发太慢现象用户从LTE覆盖区走向2G边缘通话在信号还有两格时突然断开时间轴上eSRVCC事件出现在掉话前几百毫秒执行根本来不及完成。原因A2门限设得比B2门限1还低或者两者间隔只有12dB导致终端很晚才开始异系统测量测完还没上报B2LTE链路已经崩了。这类问题的特征是eSRVCC尝试次数稀少失败率反而不高因为大多数通话根本没走到eSRVCC那一步就断了。解决把A2门限抬高留出至少5dB的余量给测量和执行同时检查B2门限2是否过于严格确保在边缘位置能找到可用的2G/3G小区。调整后用DT在问题路段复测观察A2到B2的时间间隔是否在合理范围内建议控制在1秒以内。5.4 终端日志抓了半天是空数据现象投诉用户配合抓日志传回来一个几MB的文件打开后关键时间段内容是空的或者log里只有AP侧记录modem侧信令一个都没有。原因多半是抓取工具没开工程模式调制解调器日志通道没有打开也可能是抓取前没有做时间同步回放时对不上事件时点还有一类是用户在中途重启了手机或退出了抓取进程导出的是一个已经断开通道的空壳文件。解决抓日志前先做三项检查是否进入工程模式且modem日志通道状态为RECORDING、终端时间是否已和网络时间同步、存储空间是否充足。抓取完成后在导出前先回放一小段确认日志在持续写入再打包。这属于流程问题养成习惯后基本不会再拿回黑匣子一样的乱码文件。5.5 掉话率分子分母口径不一两边数字对不上现象无线部门晨会上报某片区掉话率0.5%核心网侧口径统计出1.2%两边都确认自己没算错会议在互相质疑中结束。原因分子上有的口径包含eSRVCC失败回退有的不包含有的包含未接通就释放的会话有的只统计接通后掉话。分母上有的用VoLTE主叫次数、有的用全部已建立会话。统计时段也可能差一个小时或一个网元维度数字自然对不上。解决在优化启动阶段就建立一份「掉话统计口径说明书」明确判定为掉话的SIP释放码清单、是否含eSRVCC延续会话、分母用接通数还是试呼数、统计时区和TOP维度。所有部门和不同阶段的分析都以此为准个别需要对比的场合才单独说明差异。口径统一之后很多所谓的「数据冲突」根本不是冲突。6. 一个实战技巧三段式时间轴快速定界真正处理掉话投诉时最耗时间的环节是定界无线、核心网、终端各说各话谁都不认账。我习惯用一个三段式时间轴来压缩这个环节把同一通电话在CHR、MR、SEQ三侧的关键事件按时间戳对齐十分钟内就能划出责任范围。做法不复杂取一次典型掉话事件的起始时间在CHR里找到对应的承载释放原因和时间戳在MR里找到同一时间点前后最近的采样点的RSRP和SINR在SEQ里找到SIP释放码和释放侧。三个事件点放在同一行记录里人工判断比对着三份独立报告要快得多。时间戳CHR侧事件MR侧采样SEQ侧信息定界倾向18:15:32.110RLC重传耗尽RSRP -112dBm / SINR -3dB随后SIP 479无线侧18:32:07.845核心网释放承载RSRP -88dBm / SINR 8dBSIP 480释放侧P-CSCF核心网侧18:41:52.300无异常记录采样正常会话突然消失无释放码终端侧判断规则也很朴素CHR有无线异常且MR同步显示差覆盖或差质量定无线CHR无异常但SEQ有明确非200释放码且释放侧在核心网网元定核心网两侧都正常而会话凭空消失定终端返回去抓模组日志。这套方法对单个用户投诉和成片掉话都适用只是后者要先把典型事件从小集合里筛出来。我拿到《(重点)VOLTE掉话分析》这类材料时顺着流程走完最后习惯性存一个自己的参数边界笔记T310、A2、B2的区间、SIP释放码的含义、MR判据阈值。下次遇到同类问题不需要重新翻资料按时间轴套一遍基本能定界遇到定不了的再去抓DT和终端日志做补充验证。这也是我从反复处理这类问题里攒下的习惯先把口径和流程固定住剩下的就是数据量的问题了。希望帮到你。本文还有配套的精品资源点击获取