简介：一份针对5G网络优化中语音回落流程的实战案例文档，面向网优工程师与VoLTE/EPSFB问题定位人员，围绕UE不活动定时器超时导致EPSFB应答掉话的现象，完整还原南通港闸唐闸古镇区域的排查过程。内容从问题描述、自动与人工拨测验证到CTR和SEQ话单分析，定位P-CSCF发送CANCEL及基站释放RRC的根因，并给出tInactivityTimer与inactivityTimerOffset参数调整方案，处理前后EPS FB应答掉话率由0.13%降至0.06%、VoLTE呼叫ASR掉话率由0.28%降至0.05%。包体为1个docx文档，约2.04MB，结构清晰，含问题背景、深入分析、原因定位、解决措施与全网核查建议，可直接作为5G网优案例整理的参考模板。该案例已有362人学习下载，适合需要掌握信令分析、定时器参数优化及EPSFB掉话排查思路的工程师借鉴。
1. 5G语音优化里最容易被误判的掉话：EPSFB应答阶段被UE不活动定时器“安静释放”
5G语音优化里最让人头疼的掉话是“看不到原因”的掉话：EPSFB回落成功、LTE信号正常、SIP信令已经走到180振铃，但在对端摘机之前，UE被网络侧安静地释放，随后200 OK迟迟不来，呼叫以掉话收场。UE不活动定时器超时就是这类问题的常见黑手。它本来是5G基站用来回收无业务用户、节省空口资源的一项机制，却可能在EPSFB的应答等待窗口里把正在建立呼叫的用户误伤。本文就顺着这个案例，把信令时序、参数位置、核查步骤和验证方法拆开讲，适合做5G接入网优化、EPSFB语音质量保障的工程师参考。
2. EPSFB应答阶段UE不活动定时器怎么介入：从NG-RAN到LTE侧QCI1承载的衔接
2.1 先对齐EPSFB呼叫在应答阶段的状态机
当UE在5G覆盖下发起点对点语音业务或被叫到来，满足EPSFB条件时，gNB会执行回落。常见做法是重定向或带切换准备的回落到LTE，重定向在现网里更常见：gNB给UE下发带redirectedCarrierInfo的RRCRelease，UE随即到LTE侧重新发起随机接入，再由LTE侧建立QCI1语音承载。呼叫是否成功到这个阶段已经不完全由NR覆盖决定，而是要看LTE承载是否建好、IMS信令能否走到200 OK。
应答掉话一般就落在“180振铃到200 OK”这一段。对端还没摘机之前，语音媒体面没打通，空口上没有VoIP数据包，只有少量SIP信令。此时UE的RRC连接长期处于“有连接、无数据活动”的状态，RRC层的UE不活动定时器如果设置得短，就会在振铃等待窗口里计数到期，主动向UE发RRC释放，把用户踢回空闲态。释放之后，后续的SIP 200 OK到达时，无线承载已经被拆除，呼叫最终被网络侧判为掉话。
明白这个状态机后，看问题就有了坐标。下面这张表是我复盘EPSFB掉话时习惯先画的：
| 阶段 | RRC状态 | 空口数据活动 | UE不活动定时器是否计数 |
|---|---|---|---|
| 5G下发INVITE | NR RRC_CONNECTED | 仅有SIP信令 | 是，信令活动会刷新，但窗口可能不够 |
| 重定向/切换过程 | 中间态/迁移态 | 控制面活动 | 一般不计或延后，取决于厂商实现 |
| LTE侧建立QCI1承载 | LTE RRC_CONNECTED | 信令+少量媒体探测 | 是，eNB侧同样计数 |
| 振铃等待 | LTE RRC_CONNECTED | 无媒体面数据 | 是，最容易超时 |
| 对端摘机通话 | LTE RRC_CONNECTED | 语音RTP/ROHC持续流量 | 持续活动，不触发 |
这张表的重点在“振铃等待”一行。语音建立阶段不是空口持续有数据，对端摘机前媒体面根本没通，很多定时器是在这个窗口里走到头的。排查时如果直接把注意力放在覆盖上，往往会绕远路。
2.2 定时器计数起点和终点：它挂在哪一层
UE不活动定时器在协议上属于RRC层状态管理参数，是gNB侧每UE级别的配置，实际起效位置在gNB的DU调度器上。5G基站设备里，参数一般写在DU或CU侧的RRC配置组里，不同厂商对参数命名有差异：有的叫UE Inactive Timer，有的叫User Inactivity Timer，语义一样：UE处于RRC_CONNECTED状态、无上下行数据、也无RRC信令活动时，网络侧能容忍的静默时长。超过这个时长，gNB下发RRCRelease，释放原因常带inactivity或ue-inactivity字段。
关键要分清“最后活动时刻”的刷新机制。任何RRC信令、用户面数据、甚至周期性测量上报都会刷新定时器，而EPSFB应答等待阶段恰恰没有这些活动。另一个更容易忽略的点是EPSFB流程自身是否有“定时器豁免”能力：很多厂商在EPSFB触发后，会有一段保护期，通用不活动定时器不接管会话，等呼叫建立完成再恢复计数。如果版本升级后这个保护特性默认关闭、或者网管批量数据把相关算法开关关掉，EPSFB呼叫就直接暴露在通用定时器下，掉话就成了必然。
重定向和切换两种回落方式对定时器的敏感度也不一样。切换方式在LTE侧预建了上下文，NR侧RRC释放对承载影响相对小；重定向方式下，UE到LTE是全新随机接入，NR侧一旦释放，等待中的SIP消息只能靠UE在LTE重建NAS上下文续上，出问题的概率明显更高。所以分析第一步要确认回落方式是哪种：看路测信令里RRCRelease是否携带redirectedCarrierInfo，有就是重定向，没有则可能是切换或条件切换。
2.3 搭一套能看清定时器超时的分析环境：信令、counter和参数三路对齐
定位这类问题，光靠路测软件看一遍信令远远不够。我一般会同时拉三路数据：路测软采集的RRC/SIP信令、OMC话统里的QCI1/E-RAB相关counter、网管参数配置导出。读取参数时要记得，5G基站设备里DU和CU分工不同，定时器参数在不同版本里可能放在不同功能节点下，别只盯着NR小区配置表找，gNB Function或DU调度参数组里也有相关配置。
采集清单以表格形式整理如下：
| 数据源 | 看什么 | 用途 |
|---|---|---|
| 路测软件（Probe/Qcat类） | RRCRelease信令及cause、SIP INVITE/180/200时间、重定向目标LTE小区 | 还原时序，定位释放落在SIP哪一段 |
| OMC话统 | QCI1 E-RAB建立成功率、异常释放次数、RRC连接释放cause分布 | 判断是单站问题还是全网批量问题 |
| 网管参数导出 | UE Inactive Timer、EPSFB流程定时器豁免开关、LTE侧eNB定时器 | 和信令时间差对比，确认参数实际值 |
| 核心网/IMS信令跟踪 | SIP 200 OK、CANCEL、BYE的源和原因码 | 区分无线侧释放和核心网主动拆线 |
拿到CSV格式的信令导出后，我习惯先写一个小脚本把关键时间点自动对齐，而不是肉眼翻日志。下面是一个最小可用的时间关联脚本，适合路测软件导出的信令列表：
import csv, sys from datetime import datetime def parse_ts(s): # 路测导出时间格式一般为 2025-01-01 10:00:00.123 return datetime.strptime(s.strip(), "%Y-%m-%d %H:%M:%S.%f") invite = ringing = ok = rrc_rel = None release_cause = "" with open(sys.argv[1], encoding="utf-8") as f: for row in csv.DictReader(f): msg = row["message"].upper() ts = parse_ts(row["time"]) if "INVITE" in msg and invite is None: invite = ts elif "180" in msg and ringing is None: ringing = ts elif "200 OK" in msg: ok = ts elif "RRCRELEASE" in msg: rrc_rel = ts release_cause = row.get("cause", "") if rrc_rel and invite: print(f"INVITE到RRC释放: {(rrc_rel - invite).total_seconds():.3f}s") if ok and rrc_rel < ok: print(f"RRC释放发生在SIP 200 OK前 { (ok - rrc_rel).total_seconds():.3f}s") if release_cause and "inactivity" in release_cause.lower(): print("命中: RRC释放原因带 inactivity，需要进一步对比定时器配置")这个脚本的逻辑很简单：按时间先后找INVITE、180、200 OK和RRCRelease四个关键点，算RRC释放是否发生在SIP 200 OK之前。它不替代判断，只是帮你把“释放点”和“SIP阶段”钉在同一张时间轴上，减少人工翻信令的遗漏。参数说明：输入CSV必须有time、message、cause三列，time格式要统一；如果终端和网管时间不同步，做减法前先对齐时区，否则差出来的几百毫秒会误导判断。
三路数据齐了之后，再进下一步定位：信令时差、counter细分、参数核查。
3. 定位定时器超时的三个必查步骤：信令时差、counter和参数核查一样不能少
3.1 第一步：用信令时差把“释放点”钉在SIP哪个阶段
拿到一条掉话样本后，第一步不要急着看参数，先把SIP消息和RRC释放放在同一时间轴上看。核心基准点是INVITE的发出时间，然后分别标出180、RRCRelease、200 OK的位置。释放点出现在不同阶段，指向的原因完全不同，我习惯按下面这张表快速分类：
| 释放点位置 | 典型现象 | 第一怀疑对象 |
|---|---|---|
| INVITE之前 | 呼叫根本没建立起来 | 回落失败、5G侧无NAS上下文、重定向配置错误 |
| INVITE与180之间 | 有呼叫请求但没进入振铃 | QCI1承载建立慢、核心网SIP路由异常 |
| 180与200 OK之间 | 振铃到应答阶段掉线 | UE不活动定时器、核心网Alerting定时器、LTE弱覆盖 |
| 200 OK之后 | 通话中断 | 空口质量、切换失败、eNB侧承载异常 |
定时器超时典型命中第三行：RRC释放时间点在180之后、200 OK之前，而且RRCRelease携带的release cause是inactivity相关字段。如果释放点在180之前，那大概率不是UE不活动定时器，因为此时SIP还在建立过程中，信令活动相对丰富，定时器被刷新的可能性更大。
实际操作里，我会把同一时段所有掉话样本都在这个分类表里过一遍。如果发现掉话样本里80%以上都落在“180与200之间”，并且RRC释放cause带inactivity，那基本可以锁定是定时器问题，而不是偶然的射频波动。单条样本的cause字段可能因为厂商实现差异而写法不同，但时间窗口的规律性不会骗人。
3.2 第二步：用话统counter把掉话细分到QCI1承载建立前后
信令时差锁定了单个样本，接下来用OMC话统做批量验证。这里要看三个核心counter，各厂商命名有差异，但逻辑对应：
- RRC连接释放次数按cause细分：确认全网inactivity释放占比是不是在同一时段异常抬升；
- QCI1 E-RAB建立成功率：如果建立成功率正常，说明回落和承载建立没问题，问题集中在后续保持阶段；
- QCI1 E-RAB异常释放次数：按时间窗统计，看异常释放是否集中在振铃等待时段。
我见过不少实际案例，QCI1建立成功率一直是99.8%以上，但VoLTE掉话率超标，初看很矛盾。把counter按时间窗拆开后就会发现，E-RAB异常释放的尖峰和RRC inactivity释放的尖峰完全重合，而且都集中在某一批gNB配置了较短定时器的小区。这时候问题已经很清楚了：承载能建起来，但承载保持阶段被无线侧主动拆除，不是核心网问题，也不是覆盖问题。
还有一点值得注意：counter趋势要看相对变化，而不是只看绝对值。如果全网inactivity释放数量一直很多，但掉话不多，说明大多数被释放的用户没有语音业务，释放是正常行为。只有把inactivity释放和“QCI1承载存在期间的释放”两条counter叠加起来看，才能把误伤概率算出来。这个叠加条件在SQL或网管自定义报表里都能做，关键是时间窗要一致，别拿24小时聚合数去看短时掉话尖峰。
3.3 第三步：参数核查清单与调整次序
信令和counter都指向定时器后，再动参数。参数核查建议按这张清单走，顺序不能乱：
| 参数对象 | 位置 | 典型默认范围 | 与掉话的关系 |
|---|---|---|---|
| NR侧UE Inactive Timer | gNB DU/CU RRC配置组 | 常见6～10秒，各厂商不同 | 直接影响5G连接态保持时长 |
| EPSFB定时器豁免开关 | gNB算法特性配置 | 各厂商默认值不同 | 关闭时EPSFB呼叫被通用定时器接管 |
| LTE侧eNB Inactive Timer | eNB RRC配置组 | 常见5～10秒 | 回落LTE后同样可能释放UE |
| 核心网T_Alerting/无应答定时器 | IMS/业务平台 | 常见30～60秒 | 超时后核心网主动拆线，容易被误判到无线侧 |
调整次序上，我的经验是先在单个TOP问题站做实验，不要一上来就全网刷参数。操作节奏大概是：把该站gNB的UE Inactive Timer从默认值调到20秒左右，同时确认EPSFB定时器豁免开关已打开，观察24到48小时，看掉话样本是否消失、RRC inactivity释放是否还在QCI1承载存在期间出现。确认有效后再按同配置基站批量推广。
这里有个值得反复强调的注意点：NR侧定时器不是唯一变量。EPSFB是双网协同流程，UE回落到LTE后，eNB侧同样有UE不活动定时器。如果LTE侧定时器比NR侧还短，即使5G侧调长了，UE还是可能在振铃等待期被eNB释放，掉话依旧。所以参数调整要NR侧和LTE侧一起看，按“核心网Alerting窗口以内、两侧都覆盖住”的原则去配，而不是单独改某一个网元。
4. 避坑：判断UE不活动定时器掉话时四个常见误诊
4.1 把弱覆盖下的正常释放当成定时器超时
现象：路测显示5G重定向到LTE后，UE的LTE信号在边缘小区急剧变差，信令里同时看到RRC释放且cause含inactivity，掉话被归给定时器。原因：UE落到了LTE弱覆盖区，业务无法建立，网络侧长时间收不到有效数据，定时器超时只是结果而不是根因。解决：先查重定向目标LTE小区是否漏配邻区、目标小区选择是否不合理，再看这个LTE小区在问题时段是否有大量下行质差样本。如果SINR持续很差，应该先处理覆盖或补邻区，改定时器治标不治本。判断技巧很简单：看所有inactivity释放样本里，释放前最后几秒的LTE测量报告，质量差占比高就有覆盖嫌疑。
4.2 只调NR侧定时器，忽略LTE侧eNB定时器
现象：改了gNB的UE Inactive Timer后，掉话率从1.2%降到了0.6%，但仍然超标，而且剩下的掉话依然发生在振铃等待阶段。原因：EPSFB回落完成后，UE挂在LTE小区，eNB侧自己的UE Inactive Timer还没有调，默认值比NR侧短，用户在LTE侧等待对端摘机时又被eNB释放。解决：NR侧和LTE侧两个定时器要同步调整，而且要按最长的等待窗口兜底。一般核心网Alerting窗口默认30到60秒，两侧无线定时器至少要覆盖到“200 OK可能到达的时刻”，但又不需要大于核心网定时器，否则会拖住无业务用户。调整后要复看inactivity释放的比例，确认释放集中段已经移到通话结束后，而不是振铃中。
4.3 把核心网无应答超时误判成基站定时器超时
现象：信令里看不到gNB或eNB发出RRCRelease，反而是IMS核心网主动下发SIP CANCEL或DISCONNECT，随后无线侧才释放用户，掉话指标却记在了接入网头上。原因：呼叫长时间处于振铃状态，对端一直未摘机，IMS侧的T_Alerting/NoAnswer定时器先到期，业务平台主动终止会话。无线侧释放是跟随核心网指令产生的，不是自己主动触发。解决：核心网信令跟踪里查CANCEL的来源和原因码，如果是“无应答”类字段，说明是业务层行为。无线侧能做的最多是适当延长定时器配合，但不能根治，也不该把考核压力全压在基站参数上。区分方法不复杂：看释放是先有SIP层消息还是先有RRC释放，先有SIP层消息就是核心网主导。
4.4 调大定时器后不做“释放后行为”回归
现象：调大UE Inactive Timer后，应答掉话指标确实转好了，但LTE侧用户平均占用时长上升，5G驻留比下降，还出现新的投诉。原因：定时器调大后，呼叫结束后UE依然留在RRC_CONNECTED状态，没有业务也不释放，白白占用LTE空口资源；如果这时没有快速返回NR的机制，UE还会继续待在LTE侧，等下一次RRC释放或重选。解决：参数优化不是把定时器越调越大，而是要在“会话窗口内放大、会话结束后快速释放”之间找平衡。常见做法是打开语音呼叫结束后的立即释放或快速返回NR功能，让UE挂断电话后尽快回5G。这个联动点很多人忽略，调完参数只看掉话率，不看驻留质量，最后顾此失彼。
5. 定时器优化的关键联动：语音结束后如何让UE快速回到5G而不是赖在LTE
5.1 为什么不能把定时器无限调大
把UE不活动定时器当作“越大越安全”是典型的误区。定时器调大，确实能给振铃等待留出空间，但代价是：没有业务的用户一直在RRC_CONNECTED状态空占资源，终端耗电增加，LTE侧语音用户长时间滞留还会抬高VoLTE小区负载。更麻烦的是，一旦用户呼叫结束后还挂在连接态，5G网络无法通过正常的RRC释放引导回流，5G分流比会慢慢恶化。所以成熟的优化思路不是单点改一个定时器，而是配一组联动动作：会话保护、呼叫结束释放、快速回NR。
5.2 推荐的联动配置与验证方法
推荐的配置组合有三步。第一步，确认EPSFB呼叫期间定时器豁免已开启，让通用不活动定时器不打断语音建立流程；第二步，把NR侧和LTE侧UE Inactive Timer都设置为覆盖核心网Alerting窗口的值，注意两侧取一致；第三步，打开语音呼叫结束后的RRC释放或fast return相关配置，让UE在通话结束、承载释放后立刻进入异频测量并返回NR。验证不能只看掉话率，要同时看释放原因分布和5G驻留比：
| 验证项 | 优化前典型表现 | 优化后期望表现 |
|---|---|---|
| 应答掉话率 | 集中在180-200等待段 | 该段释放明显下降 |
| inactivity释放时段 | 振铃等待期出现 | 转移到呼叫结束后 |
| LTE侧平均占用时长 | 呼叫结束后长时间驻留 | 挂断后短时间内返回NR |
| 5G分流比/驻留比 | 不升或下降 | 止跌回升 |
整个过程里，最值得养成的习惯是：每次改完参数，把同一个TOP小区的复测数据留档，信令截图、counter导出、参数改动记录放一起存。我处理过几次类似案子，最后能顺利定位，都靠这些留档把“改了哪些、换来什么、丢了什么”讲清楚。有一次我只调了NR侧定时器，没配fast return，掉话率降了但用户长时间赖在LTE侧，后来补上快速回NR的配置才算闭环。这条弯路走过后，我再也不敢只盯单一参数，总要先问一句：这个改动对用户释放后的行为有什么影响。希望帮到你。
本文还有配套的精品资源，点击获取
