简介本资源为一份5G网络优化实战案例文档面向从事5G/IMS信令分析与故障排查的网优工程师及通信技术人员聚焦SEQ上报「20 Subscriber Absent」这一典型拆线原因值的定位与根因分析。文档围绕IMS未注册、用户缺席等场景梳理了从终端能力、网络侧IMS支持情况到S1-MME、N1N2单据核查的排查思路并涉及CSFB指示、Q85017 User Busy、NGAP UE Context Release、SIP信令拆线码等关键信令点帮助读者理解不同网元拆线阶段对应的根因差异尤其是AS拆线、被叫SCCAS域选及5G回4G回落异常等情形。资源包内含1个docx文档大小约96KB内容以案例记录与信令分析笔记为主结构紧凑、便于查阅。目前已有320人学习适合需要积累5G网优排错经验、提升信令解读能力的中高级技术人员参考。1. 从一份 SEQ 上报 20 Subscriber Absent 的网优案例说起VoLTE 用户投诉“打不出去也接不进来”后台一查 SEQ 信令平台满屏20 Subscriber Absent这种场景做 5G 网优的同行大概率都遇到过。Subscriber Absent是 IMS 域里一个非常典型的失败原因值字面意思是“用户不在”但它跟“用户关机”完全是两码事——用户手机明明开着、信号也满格网络却告诉主叫方“这个人不在”。SEQService Experience Quality信令软采与业务质量分析平台把这类失败按原因值聚合上报20 就是 3GPP 定义的Subscriber Absent对应的原因码。这份案例文档要解决的就是怎么从 SEQ 上报的 20 号原因值出发一步步定位到是 IMS 注册、终端行为、还是无线侧寻呼出了问题。适合做 VoLTE/5G 语音质量分析、日常盯 SEQ 指标、以及被“用户不在”这类模糊原因值坑过的网优工程师。2. Subscriber Absent 到底是谁在什么环节报出来的2.1 从 IMS 注册到被叫寻呼的信令链路要搞清楚Subscriber Absent得先把 VoLTE 一次被叫的信令链路在脑子里过一遍。主叫侧发起 INVITE经过 IMS 核心网的 S-CSCF 查询被叫的注册状态如果被叫在 IMS 域有有效注册S-CSCF 会把 INVITE 路由到被叫的 P-CSCF再经 PCRF 触发专载建立最后通过 MME 向被叫终端发起寻呼。Subscriber Absent通常出现在两个位置一是 S-CSCF 查询被叫注册状态时发现没有有效注册直接回480 Temporarily Unavailable并携带20 Subscriber Absent二是被叫注册还在但 MME 侧寻呼无响应IMS 域等不到终端的响应最终也归到这类原因值。关键点在于SEQ 上报的 20 是一个“聚合后的结果”它不告诉你根因在哪一段。同一个 20可能是终端 IMS 注册掉了可能是寻呼信道配置有问题也可能是终端在 4G/5G 互操作时 IMS 注册没跟着迁移。所以看到 20 不能直接下结论必须顺着信令链路往回倒。2.2 为什么 5G 场景下这个原因值更常见5G 引入后Subscriber Absent的出现频率明显比纯 4G 时代高原因有几个。第一是 SA 组网下语音走 EPS Fallback 或 VoNR终端在 NR 和 LTE 之间来回切换时IMS 注册状态容易和实际驻留网络不一致S-CSCF 那边看到的注册还是旧的寻呼却已经打到新制式上去了。第二是 5G 终端省电策略更激进部分终端在空闲态会主动释放 IMS 注册以省电等有呼叫再重新注册这个窗口期内被叫就会命中 20。第三是 5G 基站侧寻呼参数如果沿用了 4G 的配置在 NR 的寻呼周期和寻呼时机上不匹配终端漏寻呼的概率上升。提示SEQ 上看到的 20 是结果不是原因定位时永远先确认“被叫当时到底有没有有效 IMS 注册”这一步能砍掉一半的排查工作量。2.3 用 SEQ 把 20 拆到具体网元和接口实操上我一般按这个顺序在 SEQ 上做下钻。先按被叫号码和时间段过滤出所有带 20 的失败记录看失败是集中在某个 TAC、某个基站、还是某类终端型号。然后拉出对应的 SIP 信令流程重点看三个点被叫的 REGISTER 最后一次成功是什么时候、INVITE 到达 S-CSCF 时被叫注册状态是什么、MME 侧有没有对应的 Paging 消息。SEQ 一般支持按接口过滤把 Gm、ISC、Mw、S1-MME 几个接口的信令串起来看根因基本就浮出来了。# 在 SEQ 平台按被叫号码原因值过滤失败记录示意命令按实际平台接口调整 # 过滤出近 24 小时内被叫号码命中 20 Subscriber Absent 的记录 seq_query --type cdr \ --callee 86138xxxx1234 \ --cause-code 20 \ --time-range 2024-01-01 00:00:00,2024-01-01 23:59:59 \ --output detail # 拉取该号码对应的 SIP 注册历史确认最后一次成功 REGISTER 时间 seq_query --type register-history \ --impi 86138xxxx1234ims.mnc000.mcc460.3gppnetwork.org \ --output timeline上面第一条命令是按被叫和原因值捞失败话单--cause-code 20就是锁定Subscriber Absent--time-range控制排查窗口一般先看投诉时间点前后各两小时。第二条是拉 IMS 注册历史--impi用被叫的 IMS 私有标识输出时间线后重点比对“最后一次成功注册时间”和“失败呼叫时间”的间隔。如果失败呼叫发生在注册失效之后那根因就在注册侧如果注册一直有效那就要往寻呼侧查。3. 定位 20 原因值的四步排查法3.1 第一步确认被叫 IMS 注册是否有效排查的第一步永远是确认被叫在失败时刻有没有有效 IMS 注册。在 SEQ 上拉出被叫的 REGISTER 流程看最后一次成功注册的Expires时间和失败呼叫时间的差值。如果失败呼叫时间已经超过注册有效期那说明终端没有及时重注册问题在终端侧或注册刷新机制。如果注册还在有效期内但 S-CSCF 查询时却返回了 20那就要看 S-CSCF 的注册数据是不是和 HSS 不同步这种情况在容灾切换或网元重启后偶发。# 查询 HSS 侧该用户的 IMS 注册状态和 S-CSCF 分配信息 # 用于比对 SEQ 上看到的注册状态是否一致 hss_query --impi 86138xxxx1234ims.mnc000.mcc460.3gppnetwork.org \ --query-type registration-status \ --include-scscf-info这条命令查的是 HSS 侧记录的注册状态--include-scscf-info会带出当前分配的 S-CSCF 地址。把 HSS 的结果和 SEQ 上 S-CSCF 实际查询到的状态做比对如果不一致基本可以判定是注册数据同步问题需要查 S-CSCF 和 HSS 之间的 Cx 接口。3.2 第二步区分终端侧掉注册还是网络侧寻呼失败确认注册有效之后下一步是区分到底是终端掉了注册还是网络寻呼不到终端。方法是对比 MME 侧的寻呼记录和 IMS 侧的 INVITE 到达时间。如果 MME 在 INVITE 到达后确实发了 Paging但终端没响应那是无线侧寻呼问题如果 MME 根本没收到寻呼请求那是 IMS 到 MME 之间的路由或专载建立出了问题。# 拉取 MME 侧该用户的寻呼记录确认 INVITE 到达后是否触发寻呼 mme_trace --imsi 46000xxxxxxxxxx \ --event paging \ --time-window 2024-01-01 14:00:00,2024-01-01 14:05:00 \ --output paging-detail--event paging只过滤寻呼事件--time-window卡在失败呼叫前后五分钟。输出里重点看有没有Paging Request以及后续有没有Paging Response。有请求没响应查无线覆盖和寻呼参数连请求都没有往 IMS 侧继续倒。3.3 第三步核对 4G/5G 互操作时的注册迁移5G 场景下最常见的一类 20是终端在 NR 和 LTE 之间移动时 IMS 注册没有跟着迁移。终端从 NR 切到 LTE或者从 LTE 切回 NR如果 IMS 注册还挂在原来的接入网上S-CSCF 那边看到的注册信息就是过期的。排查方法是拉出失败时刻前后终端的制式变更记录和 IMS 注册刷新时间做比对。检查项正常表现异常表现对应根因制式变更时间变更后 5 秒内触发 IMS 重注册变更后超过 30 秒无重注册终端互操作策略问题注册刷新周期按 Expires 一半时间刷新到期才刷新或完全不刷新终端省电策略过激S-CSCF 注册数据与终端实际接入制式一致仍记录旧制式接入信息注册迁移未同步寻呼制式在终端当前驻留制式寻呼在旧制式寻呼网络侧制式信息未更新这张表是我排查互操作类 20 时必对的四项任何一项异常都可能导致Subscriber Absent。尤其是第三项S-CSCF 注册数据和终端实际接入制式不一致是 5G 互操作场景下最隐蔽的坑。3.4 第四步用 SEQ 关联信令做端到端闭环前三步是分段排查最后一步是把所有信令在 SEQ 上串成一条端到端的时间线确认根因。把 SIP 的 REGISTER、INVITE、180/183、MME 的 Paging、以及无线侧的 RRC 连接建立记录按时间戳排在一起看哪个环节断了。SEQ 一般支持多接口关联查询用被叫号码或 IMSI 做关联键把 Gm、Mw、ISC、S1-MME、Uu 几个接口的信令拉到一个视图里。# SEQ 多接口关联查询用 IMSI 做关联键拉端到端信令 seq_correlate --key 46000xxxxxxxxxx \ --interfaces Gm,Mw,ISC,S1-MME \ --time-window 2024-01-01 13:59:00,2024-01-01 14:02:00 \ --sort-by timestamp \ --output e2e-timeline--interfaces指定要关联的接口列表--sort-by timestamp保证信令按时间排序--output e2e-timeline输出端到端时间线。拿到时间线后找第一个出现异常的信令点——是 REGISTER 没刷新、INVITE 被拒、还是 Paging 无响应根因就在那个点。4. 避坑与常见问题排查4.1 把 20 当成用户关机直接结单现象SEQ 上报 20客服按“用户不在”解释工单直接关闭用户二次投诉。原因Subscriber Absent的原因值字面误导性强很多人直接等同于“用户关机或不在服务区”。解决20 只代表 IMS 域认为被叫不可达必须结合注册状态和寻呼记录判断关机只是其中一种可能且关机通常伴随User Not Registered或NotFound和 20 有区别。4.2 只看 IMS 侧不看无线侧现象IMS 侧注册一切正常但 20 持续出现排查陷入僵局。原因只盯 SIP 信令忽略了 MME 和无线侧的寻呼失败。解决注册正常但呼叫失败大概率是寻呼侧问题必须拉 MME 的 Paging 记录和基站的 RRC 连接建立成功率看是不是寻呼信道配置或覆盖问题。4.3 忽略终端型号的集中性现象某个区域 20 突然增多逐站排查没发现网络问题。原因没有按终端型号聚合分析实际是某款终端在特定版本下的 IMS 注册 bug。解决在 SEQ 上按终端型号和软件版本做聚合如果 20 集中在某一两款终端基本可以判定是终端侧问题推动终端厂商或引导用户升级。4.4 注册有效期参数设得过短现象用户反映“刚打完电话过一会儿就打不进来了”。原因IMS 注册的Expires时间设得过短终端刷新不及时注册频繁失效。解决检查 P-CSCF 下发的注册有效期一般建议 3600 秒左右过短会导致注册窗口期频繁出现过长则故障时注册状态更新不及时。4.5 4G/5G 互操作参数不匹配现象SA 区域边缘 20 高发用户移动中通话失败。原因NR 和 LTE 的寻呼周期、TAC 边界、IMS 注册迁移策略不匹配。解决核对 NR 和 LTE 的寻呼参数配置确保互操作时 IMS 注册能及时迁移必要时调整 TAC 边界或寻呼周期对齐。5. 把 20 的排查经验固化成可复用的分析模板做久了会发现Subscriber Absent的排查其实有一套固定套路与其每次从头查不如把它固化成一个 SEQ 分析模板。我的做法是在 SEQ 上建一个专门的 20 原因值分析视图预设好过滤条件和关联接口每次有投诉直接套模板把排查时间从小时级压到分钟级。具体来说这个模板包含四个固定查询被叫注册历史、MME 寻呼记录、制式变更记录、端到端信令关联。前三个是并行拉取第四个做汇总。模板里把时间窗口、接口列表、关联键都预设好只需要替换被叫号码和时间段。下面是我常用的模板参数配置查询模块关联键接口/数据源时间窗口关键输出字段注册历史IMPIGm/ISC失败前 2 小时最后成功注册时间、Expires寻呼记录IMSIS1-MME失败前后 5 分钟Paging Request/Response制式变更IMSI无线侧失败前后 10 分钟制式切换时间点端到端关联IMSI多接口失败前后 3 分钟首个异常信令点模板建好之后还有一个进阶用法是加自动告警。在 SEQ 上对 20 原因值设阈值告警比如某小区 20 占比超过 5% 就触发这样不用等投诉就能提前发现。我一般还会把告警和终端型号聚合绑在一起如果告警同时伴随某款终端占比飙升直接推终端侧排查省掉网络侧的无用功。最后说个我自己的习惯每次处理完一个 20 的案例我都会把根因和排查路径记到一个本地文档里按“注册类、寻呼类、互操作类、终端类”分四类归档。时间长了再遇到 20先看现象像哪一类直接翻对应的历史案例比从头查快得多。这个习惯帮我省了太多重复劳动也避免在同一个坑里翻车两次。希望帮到你。本文还有配套的精品资源点击获取