简介一份聚焦 5G 核心网与 VoLTE/VoNR 业务信令分析的网优案例面向网络优化工程师、5G 核心网维护人员及通信专业学习者。案例以 SEQ 平台上报的 20 Subscriber Absent 原因值为切入点系统拆解从 IMS 注册状态确认、SIP 信令拆线网元定位到 UE 能力与网络侧 EPS Network Feature Support 字段核查的完整排障路径重点说明 AS 拆线、用户关机、被叫域选以及 5G 回落 4G 异常等不同场景下该原因值的差异化根因并介绍如何借助 invite 消息中的终端型号、S1-MME 单证与 N1N2 单证数据交叉验证用户是否发生去激活流程帮助读者建立可复用的信令分析思路。资源为单篇 docx 技术文档共 1 个文件压缩包约 96KB结构紧凑、定位链条完整便于在故障现场快速对照排查。目前已有 321 人学习可直接作为 5G 网优日常投诉处理与信令专题分析的随身参考资料。1. 凌晨两点SEQ弹了20个Subscriber Absent这不是运气问题是网络问题凌晨两点值班电话把你从半睡半醒里拽起来某区域陆续有用户反映“手机信号正常但别人打进来要么提示关机要么响一声就断”。后台网管平台——也就是你每天盯着的SEQ系统——刚刚弹出一条聚合记录过去24小时内该区域累计上报了20次“Subscriber Absent”事件。如果不熟悉这套代号你会把这20条当成噪声直接忽略但干过5G网优的人都知道这20条记录背后通常藏着一类可以被定位、被修复的网络问题而不是什么玄学故障。Subscriber Absent直译叫“用户缺席”在5G信令里指的是核心网发起了寻呼但最终没有找到这个用户。它可能是无线覆盖盲区造成的也可能来自核心网寻呼策略、终端省电机制甚至是统计口径本身。这篇文章我就按实际排查顺序把这20条样本从SEQ导出、字段拆解、根因分类到网管参数核查讲透最后再送你一套可以直接复用的排查模板。适合正在处理批量被叫不可达工单的网优工程师也适合刚接触SEQ信令分析、想搞懂这套数据怎么用的新手。2. 读懂Subscriber Absent在5G信令里的真实含义从SEQ原始字段到根因树2.1 Subscriber Absent对应哪一条信令失败Paging失败与UE不可达Subscriber Absent不是一条空口消息而是核心网在寻呼流程中给出的结论。在5G SA信令链路里AMF通过N2口向gNB下发一条Paging消息gNB在空口用P-RNTI加扰的寻呼DCI告诉UE“你有被叫请求请接入”。如果gNB等待了很久仍没有收到UE的RRCSetupRequest或RRCResumeRequest就会把这次寻呼标记为失败。AMF在重试一轮后若UE依然不可达便在用户上下文里打上“Subscriber Absent”标记后续任何针对这个用户的呼叫请求都会被拒绝对方听到的就是“暂时无法接通”。这里有个很容易误判的地方不同厂商的SEQ平台对这条原因的命名并不统一。有的直接写“Subscriber_Absent”有的显示“user_unreachable”还有的只给一个数字Cause值比如“C15”或“No_paging_response”。所以你拿到SEQ导出后第一件事不是去看数量而是去确认平台里这个Cause到底对应哪一条原始信令。常见的映射关系是Paging失败 → AMF发起寻呼重试 → 最终UE仍无响应 → 触发Subscriber Absent。要分清是无线侧没有收到寻呼响应还是核心网主动放弃寻呼需要同时拉取gNB的信令跟踪和AMF的寻呼记录来对照。2.2 SEQ上报的20个样本字段拆解IMSI、TAC、小区、时间戳、Cause拿一份脱敏后的SEQ导出来看标准的CSV通常包含下面这些字段字段名示例值说明EventTime2024-05-12 00:03:21事件发生时刻IMSI460XXXXXXXXXX用户标识已脱敏TAC12345跟踪区码gNBID1001基站标识CellID100101小区标识FailureCauseSubscriber_Absent上报原因InterfaceN2信令接口MsgTypePaging_failure消息类型这20个样本乍一看时间都在凌晨到早上6点之间且集中在两三个小区。但如果你只看平均值就会漏掉一个关键细节有的样本时间间隔只有几十秒IMSI完全相同说明是同一个用户在反复被叫失败有的样本则在时间轴上彼此独立是随机路人路过时触发的一次性事件。我一般会先按IMSI做去重把20条记录拆成“20个用户各失败1次”和“5个用户各失败4次”两种形态。前者的排查重点在无线覆盖后者的排查重点就要转向终端状态和寻呼参数。另一个不能忽略的字段是TAC。5G的寻呼是在核心网下发的TA List范围内进行的如果TAC配置过大寻呼消息会在很多个小区同时广播导致空口寻呼信道拥塞反而降低了每个UE收到寻呼的成功率。因此如果20条样本全都集中在同一个TAC先怀疑无线侧下发覆盖和寻呼时机如果样本跨了好几个TAC则要联动核心网查看寻呼消息下发的范围是否异常。2.3 把20个样本按照“位置时间终端类型”做第一层聚类拿到数据后别急着去现场先写一个简单的Python脚本把样本按“小区小时用户”做聚合。下面是用Pandas做摘要分析的代码import pandas as pd df pd.read_csv(seq_subscriber_absent.csv, parse_dates[EventTime]) df[hour] df[EventTime].dt.hour # 按小区、小时统计去重用户数 summary df.groupby([CellID, hour])[IMSI].nunique().reset_index(nameunique_ue) print(summary.sort_values(unique_ue, ascendingFalse).head(10)) # 统计重复失败的IMSI判断是否存在同一用户反复尝试 duplicated_imsi df.groupby(IMSI).size().reset_index(nametotal_cnt) print(duplicated_imsi.sort_values(total_cnt, ascendingFalse).head(10))这段脚本的核心逻辑有两个一个是用nunique()去掉重复用户得出每个小区每个小时的真实受影响人数另一个是用groupby(IMSI).size()找出反复失败的个体用户。第一个统计用于判断空间聚集性——如果某个CellID在凌晨的去重用户数很高说明该区域存在批量用户寻呼失败第二个统计用于判断个体异常——如果某个IMSI出现多次且间隔只有几分钟那大概率是终端处于异常状态而不是网络整体劣化。参数说明parse_dates保证时间字段被正确解析dt.hour是用 Pandas 的 datetime 访问器提取小时。如果你的CSV里没有IMSI只有TMSI或IMEI也可以用TMSI替换但要注意TMSI会随位置更新变化统计结果可能偏大。最稳妥的方式是导出时同时带上原始IMSI和临时标识用IMSI做最终去重。3. 把20个Subscriber Absent样本分门别类覆盖、干扰、参数、终端四选一3.1 先做几何定位把小区经纬度和MR覆盖数据叠加当确认样本在某个或某几个小区聚集后下一步就是把“信令事件”落到“地理点”。最直接的方法是将SEQ样本里的CellID匹配到工参表再把MR覆盖率、RSRP均值、上行干扰电平等小区级指标拉出来看这个小区本身是不是已经在覆盖黑名单里。工参表至少要包含CellID、经度、纬度、站型宏站/室分/隧道、天线方位角和下倾角。我习惯用下面这段脚本把SEQ样本、工参和MR日指标合并成一张宽表import pandas as pd param pd.read_excel(site_param.xlsx) mr pd.read_csv(mr_daily_report.csv) df pd.read_csv(seq_subscriber_absent.csv, parse_dates[EventTime]) # 提取日期用于关联MR指标 df[Date] df[EventTime].dt.date mr[Date] pd.to_datetime(mr[Date]).dt.date # 关联工参 df df.merge(param[[CellID, Lon, Lat, SiteType]], onCellID, howleft) # 关联MR覆盖指标 df df.merge(mr[[CellID, Date, RsrpMean, CoverRate]], on[CellID, Date], howleft) # 聚焦出现次数最多的小区 hot_cells df.groupby(CellID).size().sort_values(ascendingFalse).head(3).index print(df[df[CellID].isin(hot_cells)][[CellID, Lon, Lat, SiteType, RsrpMean, CoverRate]].drop_duplicates())这段脚本做的是典型的“多表关联”。工参表提供小区坐标和类型MR表提供当天该小区的平均RSRP和覆盖率SEQ表提供出现问题的用户事件。三张表通过CellID和Date关联后每条Subscriber Absent记录就有了地理和覆盖标签。如果某个热点小区的MR覆盖率低于95%且RSRP均值低于-105dBm那基本可以判定是覆盖盲区如果MR显示覆盖很好但上行干扰电平偏高就要考虑干扰导致终端无法完成随机接入进而导致寻呼响应丢失。3.2 再看时间规律夜间批量出现往往不是覆盖问题而是省电机制这是整个排查过程里最容易让人走弯路的地方。如果那20条样本全部集中在凌晨0点到5点先别急着怀疑基站栅格或者天线倾角因为5G终端在夜间普遍进入空闲态深度睡眠寻呼监听周期会被拉长比如从默认的320ms变成1280ms甚至2560ms。更极端的情况是有些手机的系统省电策略会直接冻结调制解调器的一部分任务导致网络侧发了寻呼但终端的基带还没来得及监听。实际操作时把样本按小时做直方图。如果曲线是“夜间高、白天低”优先检查该小区/TA下的寻呼参数DefaultPagingCycle和nB。在5G网管里DefaultPagingCycle定义了空闲态UE监听寻呼的周期nB定义了寻呼帧的密度。如果这个区域为了降低无线信令开销把DefaultPagingCycle设成了2560ms而周边其他区域是1280ms那在凌晨这种重负载较低但终端深度休眠的时段被叫失败率会明显上升。验证方法很简单抓取样本里每个IMSI最后一次驻留小区的“Last UE Activity Time”如果距离被叫发起超过10分钟而且该小区白天的失败次数很少基本就能锁定到空闲态寻呼周期配置过长。3.3 关联参数核查寻呼周期、T300、N310与Subscriber Absent的关系很多人会把Subscriber Absent和无线掉话、重建失败混在一起实际上它们不是一回事。T300是UE发起RRCSetup请求后等待网络响应的定时器如果你改了T300影响的是呼叫建立成功率一般不会触发Subscriber Absent。而寻呼失败发生在UE还没有发起RRCSetup之前属于“网络根本没联系上UE”因此排查清单要围绕寻呼参数而不是RRC建立参数。需要查的参数我按优先级列一下DefaultPagingCycle空闲态寻呼周期越大越省电但被叫时延越大夜间失败率越高。nB寻呼帧密度可选值1/8、1/4、1/2、1、2、4nB越小无线资源开销越小但UE在给定周期内可用的寻呼机会越少。Paging Retry CountAMF侧寻呼重试次数常见值为2或3。TAC List范围如果寻呼消息覆盖的TAC过多会导致空口容量瓶颈。N310/N311下行失步和同步恢复的计数影响到UE判定无线链路失败进入IDLE的速度。举例来说如果N310被上一轮优化从20改小到6终端稍一进入电梯或者地下室就会因为连续收不到下行信号而判定失步快速回到空闲态。这时候核心网如果正好下发寻呼UE已经在另一个频点或另一个小区自然不会有响应。所以在网管上看到N310特别小同时Subscriber Absent样本又多就要翻历史变更记录看是不是有人为了提升掉话指标而埋下了这个坑。4. 动手复现排查流程从SEQ导出、脚本清洗到网管验证的完整命令4.1 SEQ导出Subscriber Absent过滤规则别把其他Cause混进来SEQ平台新建“信令查询”任务时默认的接口条件可能会包含多个消息类型。如果你直接导出“Paging失败记录”很容易把非Subscriber Absent的二次原因混入比如“Paging_rejected_by_network”“No_paging_response_from_UE”“Paging_temporary_failure”。这会导致20条变成120条后续分析的精准度大打折扣。我一般会在导出界面设置这样的过滤条件接口: N2 消息类型: Paging 原因值: Subscriber_Absent (有些平台叫 User_No_Response) 时间范围: 问题发生前后24小时 用户标识: 不限 站点/小区: 不限关键点在于原因值字段要选得足够精确。若平台的下拉菜单里没有现成的“Subscriber Absent”就先导出所有Paging消息再用下面的Python脚本二次过滤import pandas as pd raw pd.read_csv(all_paging_records.csv) # 兼容不同Cause命名匹配包含absent/unreachable/no_response的记录 absent raw[raw[cause_text].str.contains( absent|unreachable|no_response, caseFalse, naFalse )] absent.to_csv(subscriber_absent_filtered.csv, indexFalse) print(过滤后样本数, len(absent))这段脚本的作用是做“宽容匹配”因为各平台字段里的原文可能是SUBSCRIBER_ABSENT、ue_unreachable或Paging_no_resp。用str.contains一次性覆盖。但要注意no_response可能会把某些非Subscriber Absent但同样是寻呼无响应的记录也带进来建议在结果里抽查几条用原始会话ID回订到信令原始码流里确认。4.2 使用Python脚本整合SEQ原始CSV、工参表和MR覆盖率这一步的核心目标是把分散在不同系统里的数据拼成一张可筛选的表SEQ导出记录提供事件工参表提供地理信息MR日汇总提供无线质量。下面这段脚本我通常命名为merge_analysis.py每次新项目直接改文件路径就能用。import pandas as pd import numpy as np seq pd.read_csv(seq_export.csv, parse_dates[EventTime]) site pd.read_excel(site_info.xlsx) stats pd.read_csv(cell_daily_stats.csv, parse_dates[Date]) # 从EventTime提取日期便于关联日指标 seq[Date] seq[EventTime].dt.date stats[Date] stats[Date].dt.date # 关联工参和日统计 merged seq.merge(site[[CellID, Lon, Lat, SiteType]], onCellID, howleft) merged merged.merge( stats[[CellID, Date, PdcchBler, RsrpMean, UlInterfLevel]], on[CellID, Date], howleft ) # 标记是否为凌晨时段 merged[is_night] np.where(merged[EventTime].dt.hour.between(0, 5), 1, 0) merged.to_csv(merged_analysis.csv, indexFalse) print(总共样本, len(merged)) print(夜间占比, f{merged[is_night].mean():.1%}) print(关联到MR数据的小区数, merged[CellID].nunique())这段脚本的path含义seq_export.csv是最初的SEQ导出site_info.xlsx是工程参数表cell_daily_stats.csv是小区每日的MR汇总。howleft表示保留SEQ样本的所有行防止因为工参或MR缺失而丢事件。最后生成merged_analysis.csv每一行就是一条Subscriber Absent记录附带小区经纬度、站型、平均RSRP、PDCCH BLER和上行干扰电平。接下来做任何条件筛选都不需要再频繁切换平台。需要注意的是MR日指标在凌晨业务低谷时的表现通常优于全天平均值。因此更严谨的做法是用同一时段比如0点到5点的小区RSRP均值参与关联而不是用全天日均值。如果你能从网管导出“分时段MR”是最理想的没有的话先用日均值初筛再安排路测或扫频复测。4.3 在网管侧核对寻呼参数和RRC配置这三条命令看清参数下面这组命令不是某家厂商的原生MML而是把常见网管系统里的核心查询语句做了一个语义化汇总。实际操作时请对照你所使用的网管平台的命令行或菜单树。# 查询小区寻呼参数输出DefaultPagingCycle、nB LST NRCELLPAGING:NRCELLID101; # 查询RRC连接相关定时器重点看T300、N310、N311 LST NRCELLRRC:NRCELLID101; # 查询TA配置信息确认当前寻呼范围 LST NRTAC:TAC12345;第一行查寻呼参数重点记录DefaultPagingCycle和nB。如果DefaultPagingCycle是1280ms而相邻区域是320ms就值得怀疑。第二行查RRC层计数器尤其看N310是否小于常规的15或20。第三行确认TAC配置看该TAC下挂了哪些小区是否有小区被规划到错误的TA里。拿到这些数据后还要做一件事看参数变更记录。很多这类问题都不是初始规划失误而是中期优化改出来的。比如为了降低无线资源消耗把nB从1改成了1/4或者为了提升掉话率把N310从20改成了6。这类变更在当时可能优化了一个指标但副作用就是批量出现Subscriber Absent。如果变更记录里能看到谁在什么时候改了什么直接恢复并回退验证往往是最快的解法。5. 避坑指南排查Subscriber Absent时最容易翻车的5个细节5.1 现象20个样本集中在同一个TAC但覆盖指标完全正常你以为问题在无线侧带着扫频仪到了现场RSRP和SINR都很好现场测试一遍通过回去之后第二天又报20条。这种案例我遇到过不止一次真正的根因在核心网AMF对该TAC下的用户配置了过大的TA List寻呼消息需要下发到所有TA内的小区造成无线侧寻呼信道的容量被挤爆gNB根本没机会把寻呼在合适的时机发出去。解决方法是确认AMF寻呼策略缩小TA List或者增加寻呼重试的间隔从5秒改到8秒给无线侧留出足够的时间处理前一轮寻呼。5.2 现象多个小区同时上报而且都集中在白天忙时如果样本分布跨多个小区且集中在忙时别再逐个小区查覆盖了。我遇到过一次机房断电AMF上部分用户上下文丢失核心网触发批量用户重新注册。在用户完成注册前任何被叫请求都被暂存最终在寻呼超时后计为Subscriber Absent。这种场景下RAN侧所有小区指标都是正常的。正确做法是先看AMF日志统计是否存在短时间内大量UE context释放的事件再看传输层是否有SCTP断链告警同时联系核心网侧确认寻呼表是否重建。排查重心必须从无线切换到核心网。5.3 现象同一IMSI在一小时里重复出现5次被当成5个用户统计这是统计口径的坑。SEQ平台如果按“事件发生次数”而不是“去重用户数”统计那么同一个用户反复被叫失败会被计成多条。我见过一张报表声称“20个用户遭遇呼损”实际通过IMSI去重后只有3个真实用户。所以在做任何汇报前一定先按IMSI去重。去重后的数量直接决定了问题的严重等级20个独立用户肯定要上会5个用户重试则可以先按单用户异常处理甚至先让用户换机测试。5.4 现象Cause显示Subscriber Absent但终端其实就在本小区驻留这类情况最难缠因为网络侧寻呼消息确实发了UE也监听了但就是不响应。根因通常在终端的省电机制尤其是Android的Doze模式和厂商定制省电策略。某些机型在熄屏后会把寻呼监听的周期拉得很长甚至暂时关闭部分蜂窝功能。验证方法很简单统计样本里的IMEI/TAC对应的终端型号分布如果20条记录里某一两款机型占了八成那就基本锁定终端侧。网络侧的补救办法是把寻呼重试次数从2次提高到3次但最终必须联合终端厂商验证固件行为。5.5 现象现场单验证通过回来后还是复现怀疑是“随机”事件有些Subscriber Absent本质上是一次性触发比如用户在行驶中穿越弱覆盖区恰好此时被叫到达寻呼信号没有成功下发到UE驻留的频点上。这个位置可能只有几十米宽路测车速快一点就错过了。解决方法是使用SEQ的单用户信令追踪把这一条Subscriber Absent涉及的信令消息ID串起来找到空口寻呼帧号再关联该UE当时的随机接入上行信号质量。如果信令显示gNB确实在对应帧发了寻呼而UE没有回应就把嫌疑锁定在终端或瞬时的深度衰落上网络侧能做的调整空间不大需要靠后续多轮MR迭代优化填补覆盖空洞。这5个场景有一个共同的提示不要因为Cause字面上叫Subscriber Absent就把所有问题都算到无线头上。真正高效的思路永远是先按用户去重再按时间和小区聚类最后用核心网和RAN两侧的信令记录交叉验证。你可以把下面的内容转化为自己项目里的排查模板。6. 把Subscriber Absent排查固化成一个可复用的核查模板我每结束一个类似的项目都会把整个分析过程沉淀成一套脚本加一份决策清单。这样下次再碰上“SEQ上报20条Subscriber Absent”这类任务时不需要重新翻平台菜单直接套模板跑一遍半小时内就能给出初步结论。我的模板分成四步。第一步清洗统计用正则匹配“absent/unreachable/no_response”过滤原始SEQ导出按IMSI去重分别输出“尝试次数”和“去重用户数”。第二步聚类定位按CellID、hour、TAC三个维度做透视找出聚集组合优先输出“夜间低RSRP高PDCCH BLER”的小区清单。第三步关联核查合并工参表、MR分时段指标和参数变更日志重点检查DefaultPagingCycle、nB、N310是否偏离基线。第四步场景判定如果样本白天多且分布广拉AMF日志如果深夜多且集中安排现场复测和终端型号分析。我习惯把这个模板的最后输出做成一张Markdown表格每行一条记录列包含“无线侧嫌疑”“核心网嫌疑”“终端嫌疑”和“下一步验证动作”。这套东西不需要复杂的依赖Pandas和Openpyxl就够。真正让我回想了很久的不是脚本本身而是每次排查完成后把最终根因和整改措施写回工单备注的习惯。很多网优问题不是查不出来而是查完之后不记三个月后同样问题再来时又得重新走一遍分析流程白白浪费一夜。如果你所在的团队有条件建议把“寻呼周期、N310变更记录”和SEQ的Subscriber Absent指标做成每周自动核查哪怕只是一个简单的定时任务也能让你在问题恶化前就看到苗头。希望这套方法能帮你在面对下一个Subscriber Absent案例时少走点弯路别再靠玄学拍脑袋。本文还有配套的精品资源点击获取