简介5G网优案例文档聚焦UE不活动定时器超时导致的EPSFB应答掉话问题以某地市古镇区域实际投诉为背景完整还原从SEQ定界、拨测复现、CTR信令定位到参数调整验证的排障全流程。面向从事5G/VoLTE网络优化、投诉处理及信令分析的工程师适合作为EPSFB语音质量专题的实战参考。文档为docx格式共1个文件资源包大小2.04MB内容包含问题现象、测试手段、关键定时器参数说明及全网整改方案并附调整前后ASR掉话率等核心指标对比便于读者快速掌握同类问题的定位思路与优化方法。当前已有360余人浏览学习。1. 5G网优排障UE不活动定时器超时EPSFB应答掉话到底卡在哪做5G网优的人最怕一种投诉领导在景区逛着逛着电话响铃超过10秒没接通话直接断。这种掉话极难复现自动拨测往往全是绿的人工一打就翻车。这份案例讲的就是南通港闸唐闸古镇的同类问题——iPhone 13 Pro Max走EPSFB从5G回落4G后被叫振铃满10秒自动挂断。核心指向一个平时没人会正眼看的参数基站侧UE不活动定时器tInactivityTimer。这篇笔记会把从投诉受理到信令定位、再到参数整改的全过程拆开重点讲清楚为什么振铃期间无信令交互会导致EPSFB应答掉话以及爱立信设备里tInactivityTimer和inactivityTimerOffset怎么配合才不踩坑。适合正在做5G VoLTE/VoNR日常优化的工程师也适合刚接触EPSFB掉话分析、想找一条完整排查路径的新手。2. 问题复现自动拨测200次全绿手动拨打暴露10秒规律这个case最折磨人的不是掉话本身而是它极难复现。拿到投诉后第一反应是先用SEQSmart Expert Query信令查询平台把问题小区圈出来再派人去现场做拨测。结果外场同事用测试软件跑自动拨测主被叫打了200次一次掉话都没抓到。这里有个很多新手容易忽略的点自动拨测的拨测脚本往往把被叫自动接听延迟设得很短常见是3~5秒振铃一响手机立刻自动接听根本没有给定时器超时的机会问题自然无法暴露。随后改为人工手动拨打异常现象才浮出水面被叫振铃后超过10秒不接听电话自动挂断10秒内接听则通话正常。这个现象非常规律反复验证计时确认了边界。工程师第一反应是检查测试软件的被叫自动接听延时参数当时设置为5秒于是把自动接听时长改为15秒再试。注意这里有个逻辑如果问题是被叫侧测试软件主动挂断那么自动接听时长改到15秒后被叫振铃超过10秒时应该仍然保持振铃直到15秒才接听但实测结果是振铃超过10秒后依然自动断说明挂断行为与被叫软件无关而是网络侧主动释放了呼叫。基本排摸思路如下通过SEQ话单确认问题小区为南通-港闸-唐闸公园东南-E5H5G站点回落目标为南通港闸唐闸公园东南FD4G站点主叫侧多次拨打确认主叫流程正常发出呼叫核心网已到振铃阶段被叫侧振铃超过10秒自动断10秒内接听正常说明问题在振铃保持阶段测试软件自动接听延时修改为15秒后仍然复现排除终端软件设置问题对唐闸区域做拉网遍历未发现其他站点存在相同现象初步锁定问题站点为个例这里有一个重要判断自动拨测打200次不出现、手动拨打一次就现形说明这不是一个概率性无线问题而是带触发条件的确定性逻辑问题。触发条件大概率是时间维度——只要振铃时长达到某个阈值网络就会释放。这个思路引导后续排查从「无线质量」转向「定时器参数」。外场测试的另外一个经验是手动拨测时要把主叫和被叫的振铃行为分开记录。本文案例里被叫振铃超过10秒就断但如果只看主叫侧界面很容易把问题误判为主叫侧异常释放。实际排查时要两侧同时打点记录振铃起止时间戳才能确认释放方向。3. 信令定位从CANCEL消息反推承载释放链路现场复现只是第一步真正让根因浮出水面的是CTRCall Trace Record呼叫跟踪记录和SEQ话单的联合分析。先看核心网侧的信令P-CSCFProxy-Call Session Control Function代理呼叫会话控制功能多次主动发送CANCEL消息携带原因值为Insufficient Bearer Resource也就是承载资源不足。这个原因值初看像是无线侧资源不够但结合SEQ话单的原始信令流程看发现异常掉话已经走到了180 Ringing阶段——也就是说主叫侧已经收到被叫振铃的确认呼叫建立过程本身是通的。问题出现在振铃保持阶段。用SEQ对问题话单打点可以清晰看到以下时间线主叫发起呼叫核心网将呼叫路由到IMS域IBCFInterconnection Border Control Function互连边界控制功能收到180 Ringing消息被叫开始振铃振铃期间无任何信令交互这是关键特征约10秒后基站侧发起RRC连接释放释放原因为user-inactivity用户不活动基站向MME发送用户不活动释放请求核心网侧随之终止会话P-CSCF发送CANCEL消息呼叫未接通即被释放产生ASR应答掉话这个链路里最反常的是第4步——一次正常通话流程中被叫振铃时UE处于RRC连接态但没有任何上行或下行数据交互。在爱立信设备的默认机制里UE不活动定时器从最后一次信令交互开始计时如果计时器超时前没有新的信令或数据到达基站会认为UE已经离开或者业务已经结束主动发起UE上下文释放流程将RRC连接拆除。这里要单独解释一下为什么振铃期间会「无信令交互」。语音呼叫走EPSFB时5G侧先建立QCI5默认承载用于IMS信令传输回落4G后再建立QCI1专载用于语音。振铃阶段主叫和被叫之间的媒体面尚未建立被叫未接听没有RTP报文IMS信令除了最开始的INVITE和180 Ringing之外也不需要持续的心跳或保活消息。于是整个振铃区间就成了一个信令空白期——对业务来说这是正常的但对基站的不活动定时器来说这个空白期恰好是触发释放的窗口。从CTR话单中还能看到基站侧释放RRC后MME侧删除了该用户的GBR承载包括QCI1对话音专载和QCI5默认承载。问题在于后续如果用户再次发起呼叫或网络尝试恢复承载因为之前的QCI参数上下文已经在MME侧被清除无法重新建立QCI1专用承载核心网只能下发CANCEL终止呼叫。也就是说表面上看是「应答掉话」实际上是「振铃期间无线侧释放了承载导致后续无法完成通话建立」。信令定位这一步有两个容易踩的坑。第一个坑是只看到P-CSCF的CANCEL消息就认为是IMS核心网问题实际上CANCEL只是结果触发源在基站侧的user-inactivity释放。第二个坑是把「承载资源不足」直接理解为无线资源拥塞或干扰从而去查干扰、查容量走偏方向。判断依据很简单如果是无线拥塞CANCEL应该发生在呼叫建立初期寻呼或RRC建立阶段而不是振铃了10秒之后如果是不活动定时器问题信令时间线上必然存在一个「长时间无信令交互后基站主动释放」的特征点。有一个实用技巧是在SEQ里直接筛选释放原因值找RRC Connection Release消息里携带的release cause字段。user-inactivity释放的特征是主叫侧先收到了被叫的振铃通知随后中间有一段时间的信令静默之后基站直接下发RRC释放。这类释放原因往往是「定时器类」而不是「拥塞类」从原因值就能快速区分。4. 参数整改与全网核查tInactivityTimer和inactivityTimerOffset如何配合根因定位到基站侧UE不活动定时器后下一步是核查具体参数配置。问题站点的参数值如下tInactivityTimer设置为10秒inactivityTimerOffset设置为0。爱立信设备的UE不活动定时器机制由两部分组成理解这两部分的关系是整个整改的关键。tInactivityTimer面向全部业务的通用不活动定时器默认值常见为10秒~20秒它从最后一条信令或数据传输结束后开始计时超时则基站发起UE上下文释放inactivityTimerOffset仅当开启ServiceSpecificInactivityTimer功能时才生效它允许按照不同QCI类型设置个性化定时器偏移值。最终生效的不活动释放时长 tInactivityTimer inactivityTimerOffset本次问题场景中问题站点tInactivityTimer10sinactivityTimerOffset0s累计不活动判定时长为10秒。被叫振铃后无信令交互10秒一到基站就发起释放掉话随之产生。另一个关键点在于QCI5承载承载着IMS信令包括180 Ringing等SIP消息在EPSFB回落场景里主叫侧收到180 Ringing后QCI5承载仍然保持着连接状态。但由于SIP信令不像TCP那样有保活机制振铃期间没有周期性信令来刷新不活动定时器所以QCI5承载反而成了「最容易超时的承载」。整改方案需要做两个决定一是把整体不活动释放时间拉长到多少二是如何让QCI1/5语音与IMS信令与其他承载区分对待。方案如下修改前参数参数项修改前修改后说明tInactivityTimer10s5s通用不活动定时器面向全部业务inactivityTimerOffsetQCI1/50s25s仅对QCI1/5生效的个性化偏移QCI1/5实际不活动释放时长10s30stInactivityTimer inactivityTimerOffset其他QCI实际不活动释放时长10s5sQCI2/3/4等未加偏移缩短释放回收时间这里有个反直觉的设计tInactivityTimer从10秒降到5秒但整体释放时长反而延长到30秒。原因是把通用定时器缩短后普通数据业务网页浏览、视频缓冲等QCI9/8承载不活动5秒即可释放更有利于资源回收而对于QCI1/5这类需要长振铃容忍的业务通过inactivityTimerOffset补偿25秒让语音用户在振铃期间有充足时间接听电话。这个「通用收紧、特定放宽」的思路比粗暴地把所有业务统一拉长到30秒更合理因为统一拉长会导致大量用户在线闲置信令长期占用无线资源尤其是在景区、商超等大话务场景下会明显抬升RRC连接保持率指标。修改操作本身并不复杂在爱立信网管上开启ServiceSpecificInactivityTimer功能然后将QCI1/5的inactivityTimerOffset从0调至25tInactivityTimer统一配置为5秒。要注意的是不同版本的网管对参数的命名有差异部分版本里inactivityTimerOffset是按QCI映射表配置的需要先确认当前网管版本支持QCI级别的差异化配置否则修改后不生效。常见问题与踩坑记录现象一只改了tInactivityTimer发现无效 原因未开启ServiceSpecificInactivityTimer功能inactivityTimerOffset根本不参与计算又或者网管上配置了offset但功能开关未使能导致参数虽然下发但基站侧未执行。 解决先确认功能开关状态再核查参数下发前后基站的配置回读值。爱立信网管上可以通过检查ServiceSpecificInactivityTimer的开关状态来确认。现象二把tInactivityTimer直接改成30秒而不是配合offset使用 原因没有理解参数的分工逻辑把所有业务的不活动定时器都拉长了。这样做的后果是视频缓冲、网页停留等场景下RRC长时间不释放导致小区平均用户数和RRC连接数虚高。 解决优先使用「通用定时器收紧重点QCI加偏移」的方式既保证语音振铃不释放又防止数据业务长时间占用资源。现象三修改后现场复测仍然在10秒左右掉话 原因核查时发现网管参数已改但基站侧配置未生效或者该参数在无线侧有独立的小区级覆盖工参上虽然改了但硬件板卡版本过老不支持。 解决修改参数后强制复位相关基带板或等待配置同步周期完成然后再次用SEQ话单确认释放原因是否从user-inactivity变成了正常接听后的释放。如果仍不行检查该站点的软件版本与参数feature支持情况。现象四全网核查时漏掉同配站点 原因本次修改只针对投诉站点但排查发现全网有42个站点存在相同的参数配置组合tInactivityTimer10sQCI1/5的inactivityTimerOffset0s存在同样隐患。 解决不要只改出问题的小区要把相同版本、相同参数组合的所有小区一次性纳入整改范围统一修改后做全网话单抽查。现象五振铃保持不满30秒就断但释放原因不是user-inactivity 原因存在核心网侧其他定时器参与释放链路例如MME侧的UE上下文保持定时器、或者PCRF侧的会话保活时间这些定时器一旦先于基站侧超时同样会主动删除承载释放原因则会显示为其他值。 解决排查时不止看基站侧释放原因还要看核心网侧是否先发了Delete Bearer Request或Abort Session消息。如果核心网侧先行动作基站侧释放只是跟随结果。整改操作完成后还需要在网管侧做一轮配置复核重点确认已修改站点列表与全网参数基线的一致性。可以用批量导出命令核查所有eNodeB的参数配置筛选条件设为tInactivityTimer ! 5 或 QCI1/5 offset ! 25确保没有遗漏站点。5. 验证方法与EPSFB掉话复测技巧这一章直接给出最终效果和验证方法。调整后现场复测结果被叫振铃超过30秒不接听才会自动挂断符合预期设定。对于正常用户行为来说30秒足够覆盖绝大多数接听场景一般振铃35秒后系统侧本身也会超时释放。从全网指标看EPS FB应答掉话率从0.13%下降到0.06%VoLTE呼叫ASR掉话率从0.28%下降到0.05%指标改善非常明显。复测时要关注三个维度。第一是现场手动拨测按修改前相同的测试方法重复执行——被叫振铃不接听分别卡10秒、20秒、30秒三个时间点观察挂断行为确认释放边界已经从10秒迁移到30秒。第二是SEQ话单复核抽取问题时段的问题号码逐一确认释放原因值不再是user-inactivity而是「正常释放」或「呼叫超时释放」。第三是全网指标观察拉取修改前后两周的EPSFB应答掉话率和VoLTE ASR掉话率日均趋势排除个别日期的波动干扰。关于参数下发的验证技巧建议修改后不要立即做拨测先等配置同步完成一般15分钟左右然后通过SEQ的信令追踪功能实时查看目标小区内用户的RRC释放原因值分布。如果看到释放原因值中user-inactivity的占比明显下降说明参数已生效。如果仍有零星user-inactivity释放优先核查是否是非目标QCI的承载触发例如数据业务承载的定时器释放这是正常行为。从那以后我每次处理EPSFB应答掉话类问题都会强制走一遍完整流程先查SEQ话单确认释放原因值再核查UE不活动定时器参数组合最后对比全网同类站点参数基线。这个case里最值钱的不是那几行参数修改而是「自动拨测无法覆盖长振铃场景」这条血泪经验——后续再遇到类似投诉第一反应就是让外场手动拨测、拉长振铃不接听时间而不是盲目压测。希望这篇拆解对你有帮助遇到同类掉话时能少走几步弯路。本文还有配套的精品资源点击获取