简介围绕5G网络中SEQ系统上报的20 Subscriber Absent错误码这份案例文档从现象触发到根因定位呈现了一套完整排障链条适合5G与VoLTE网络优化工程师、核心网运维人员以及投诉处理团队参考。文档先解释IMS未注册导致用户缺席的基本含义再分步展开终端能力核查、网络侧IMS支持性确认、S1-MME与N1N2信令单据审查、SIP拆线网元归属判断等关键动作并特别讨论5G回落4G时触发该原因值的可能场景指出接入侧回落问题与IMS域拆线码之间的区分要点。内容兼顾原理说明与实战案例可帮助读者建立按阶段拆解问题的思路从信令数据入手分辨关机、数据业务异常和VoLTE能力不足等不同根因。资源为单个docx文档压缩包仅96KB下载后即可阅读。目前已有321人学习适合需要快速理解该错误码的网优人员作为备查资料。1. 一次SEQ上报让我盯了三个晚上20个Subscriber Absent背后不只是覆盖问题某天例行巡视我在SEQ信令分析平台上看到一张寻呼失败统计表数据一夜之间冒出了20条“Subscriber Absent”记录集中在同一个TA区。上报的含义是网络向这20个用户发起了寻呼但用户始终没有响应。当晚投诉就有三起都反映“别人打电话来手机不响等几十分钟后才看到未接来电”。我第一反应是查覆盖可后台看每个用户的驻留小区RSRP都在-100dBm以上信号并不差。真正让我坐不住的是这20条不是零散分布而是同一个小时间段内连续上报像是有规律地被“挤”出来。这背后可能涉及终端省电、核心网状态不一致、寻呼参数配置等多重因素光靠加站、调天线解决不了。本文从这条SQL一样的排查线索出发完整走一遍“看懂报表—拉取清单—逐项定位—参数调优—验证效果”的流程适合正在做5G网络优化、投诉处理或核心网信令分析的朋友。如果你也是半夜被SEQ报表叫醒的人这篇能帮你少走不少弯路。2. Subscriber Absent在5G信令里是怎样产生的先搞懂寻呼响应链2.1 寻呼流程中的“最后一环”失败为什么网络侧记为Subscriber Absent5G网络里一次最简单的被叫流程是这样走的主叫侧触发对目标UE的业务请求后服务该用户的AMF会先查用户上下文里保存的TA list和基带标识再通过N2接口向可能覆盖到用户的gNB下发Paging消息。gNB收到后把寻呼消息装配进空口的Paging信道用P-RNTI调度终端在RRC_IDLE或RRC_INACTIVE下按DRX周期醒来监听。UE如果监听到自己的IMSI或S-TMSI就发起RRC连接建立随后网络继续往下走。这一环只要有一处对不上——UE没醒、醒晚了、广播携带的PO计算参数不一样、或者UE已经移动到另一个TA但还没做位置更新——就会出现“网络发了寻呼UE没有任何响应”。最终AMF侧的寻呼等待定时器超时AMF把这条失败记成Subscriber Absent。Subscriber Absent这个原因值在标准里属于“用户不可及”这一类。它只说明结果被叫用户在当前网络状态内不可达。它不告诉你为什么不可达。这是排查看似简单、实际最容易跑偏的地方。比如一个终端插着SIM卡屏幕看起来也注册上了但用户开启了超级省电模式终端把寻呼监听从每个DRX周期醒一次改成几十秒甚至几分钟才醒一次网络按默认32个无线帧周期寻呼连续找两三次都找不到此时上报Subscriber Absent就非常合理。这种情况在夜间特别多。另一个常见场景是移动性带来的状态陈旧。5G网络使用基于TA list的注册机制用户在一个TA list内移动不需要每次更新但Paging还是会下发到该list内所有小区。如果用户实际已经离开这个TA list却因为定时器还没到期、没有触发新的TAU那么AMF存的位置就是旧的。按旧位置寻呼用户根本听不到。在高密度城区TA边界处这一步很容易出问题。看现象用户区域信号很好、测试拨号也通但后台就是持续出现Subscriber Absent。因此拿到这个原因值不要第一时间去开修改单。先把寻呼响应链的每个环节拆开终端有没有在监听无线侧的寻呼内容有没有送出去核心网知不知道用户在哪这三个问题对应不同数据域而SEQ正好把这三个域的信令都归拢到了一张表里。这就是我们后续分析的基础。2.2 “20”这个数字是怎么统计出来的看清口径再动手SEQ平台的报表通常从N2接口或服务化接口采集原始信令再按时间、网元、原因值做聚合。不同厂家的“上报”口径存在差异有的按寻呼尝试次数计数有的按寻呼失败消息条数计数还有的按IMSI去重后计数。我这边的平台当时默认是“每次失败记一条”所以报表里“Subscriber Absent20”只能代表20次失败并不直接等于20个用户。我把明细拉出来后做了去重发现只有13个IMSI其中7个用户重复失败。重复失败的用户有一个共同点第一次失败之后网络重发了寻呼依然失败于是又积累了几条记录。这个统计口径差异是第一个坑。如果不先做去重而是直接用20除以全天寻呼成功次数算比例会把问题放大。更稳妥的做法是先导出原始明细确定三件事一是这20条分布在多长的时间跨度内二是涉及多少个IMSI、多少个gNB三是这些失败是不是由寻呼重传产生的重复计数。只有去掉了重传和重复计数你手里的数字才接近真实受影响人群。在5G里寻呼重传本身由AMF控制通常是2到4次每次间隔若干秒。如果AMF配置了在多个TA或gNB下重试每一次尝试都会产生一条独立的信令记录。我在之前的项目里最开始看到某个用户一晚上有9条Subscriber Absent以为小区出了问题后来对照消息时间戳才发现那其实是同一次被叫在9个寻呼周期内依次失败。把9条按时间戳串起来才看到是一条连续失败的完整轨迹而不是9个孤立事件。所以拿到一张“20 Subscriber Absent”的报表我的习惯是先做成一张透视表横轴是时间纵轴是IMSI看失败点是不是集中在某个时间段或某个TAC下。这种散点分布能告诉你问题的性质集中在凌晨0点到6点大概率是终端省电或网络节能集中在用户上下班路径上大概率是TA边界和移动性问题完全随机散布则要考虑覆盖盲区和干扰。这一步做完再进入明细查询效率会高很多。2.3 Subscriber Absent与其他寻呼失败原因别把最终原因当成根因在SEQ的失败原因字典里Subscriber Absent只是一个“最终结论”。真正失败过程中还可能看到radioNetworkLayer-cause、timeout、noResponse等中间原因。我在这里放一张简化的对比表方便你后续拿到报表时快速归类原因值出现的位置典型含义下一步重点查的方向Subscriber AbsentAMF侧寻呼结果UE无响应不可及终端状态、寻呼时机、TA一致性radioNetworkLayer-causegNB向AMF上报无线层失败如资源不足、干扰覆盖、拥塞、P-RNTI质量NAS cause #26等NAS流程无线资源不足或用户拒绝空口质量、终端侧行为User Inactive核心网会话管理用户无活动网络释放资源业务模型、保活机制注意一个事件链上可能会先出现“gNB reported radioNetworkLayer-cause”随后AMF才在后续重寻呼失败后判定Subscriber Absent。所以SEQ输出只把最终的Subscriber Absent呈现出来不代表无线侧没有问题。反过来如果无线侧一切正常、干扰也低但Subscriber Absent持续高发就要往终端和核心网状态上去想。表里的每一种原因值其实都代表一个排查入口不要抓住最后一个就收工。3. 把SEQ表里那20条捞出来过滤条件、聚类查询和一条可抄的SQL3.1 按时间窗和TA过滤先圈定现场再开查打开SEQ平台的明细查询界面通常会有“信令类型”“时间范围”“用户/网元”这几组条件。我的建议是先做窄过滤信令类型选“寻呼失败”或“Paging Failure”原因值选Subscriber Absent时间范围覆盖前一天0点到24点TA/TAC填报表上该问题区域对应的值网元层面先不过滤等明细出来再看gNB分布。这样做是为了避免一开始就把范围拉得太大把全国其他偶然发生的Subscriber Absent都混进来。有些SEQ平台支持类似SQL的查询或者在导出功能里自带筛选。如果只有图形界面操作顺序一般是进入“寻呼失败明细表”时间选“自定义”开始时间填前一天00:00:00结束时间填23:59:59然后在“失败原因”下拉框里选择“subscriberAbsent”在“位置信息”里填入目标TA。导出CSV时字段至少要包含IMSI、UE标识、gNB ID、小区ID、TA/TAC、首次尝试时间、最后尝试时间、失败原因、关联注册状态。如果平台支持勾选记得勾上“包含重寻呼记录”否则可能丢失重复失败数据。这一步的目标是拿到干净的原始数据集。我一般会把导出文件命名为“日期_TA_subscriberAbsent.csv”放到当天的分析目录下。后面每一轮分析都以这个文件为基础不反复回到平台里手动翻看。一来可复现二来万一你被其他事情打断回来也能继续。3.2 按IMSI去重统计把“20条”还原成“13个用户”拿到CSV之后第一件事是去重。很多时候平台导出的数据里同一个用户的同一次连续失败会被拆成多条记录。下面这段SQL是在支持SQL接口的SEQ系统上常用的一种聚合方式逻辑能在大多数关系型数据库上跑通SELECT imsi, COUNT(*) AS fail_times, COUNT(DISTINCT gnb_id) AS involved_gnbs, COUNT(DISTINCT tai) AS involved_tas, MIN(first_fail_time) AS first_fail, MAX(last_fail_time) AS last_fail FROM paging_failure_detail WHERE failure_reason subscriberAbsent AND failure_time BETWEEN 2025-03-10 00:00:00 AND 2025-03-10 23:59:59 GROUP BY imsi ORDER BY fail_times DESC;代码逻辑说明先按IMSI分组计算每个用户失败次数、涉及多少个gNB、涉及多少个TA以及第一次和最后一次失败的具体时间。重点看fail_times大于1的记录因为这意味着同一个用户被寻呼了多次都失败问题可能出在终端或核心网状态上而不是偶发覆盖问题。如果involved_gnbs也大于1说明网络在多个基站下都试图呼叫该用户依然没找到那就可以更坚定排除单一小区覆盖问题。参数说明failure_time字段按你的平台命名调整如果上面的表里没有imsi但有s-tmsi那就先按s-tmsi聚合并看是否能结合NAS上下文映射到IMSI。一定要把时间范围写成完整的一天不要直接写“最近24小时”因为“最近24小时”会随着查询时刻漂移无法和前天、后天的数据对齐。执行完这段SQL后你应该得到一张用户级别的失败分布表。拿我那次数据举例20条记录去重后得到如下结果用户组用户数失败次数平均首次失败时间A类9102:15B类3301:40C类1500:52从这个表格已经能看出B类和C类用户是被反复寻呼都失败的属于核心矛盾。接下来要关联他们最后一次成功注册/TAU的位置看和寻呼目标位置是否一致。3.3 关联注册上下文看用户失败前最后一次有效活动只有去重后的IMSI还不够得从用户上下文表里取出每个用户最后一次成功注册或TAU时的位置这样才能判断“网络在哪儿找他”和“他实际应该在哪儿”是否匹配。很多SEQ平台会把注册流程和寻呼流程放在同一张宽表里或者至少通过IMSI关联到“用户会话日志”。下面是最常见的关联查询模板SELECT p.imsi, p.fail_times, p.first_fail, s.last_reg_time, s.last_tau_time, s.last_gnb_id, s.last_tai, s.last_rrc_release_time FROM paging_failure_summary p LEFT JOIN subscriber_session_log s ON p.imsi s.imsi WHERE p.fail_times 1 ORDER BY p.fail_times DESC;逻辑说明LEFT JOIN保证即使是平台里没留下最近会话记录的用户也能出现在结果集中方便你发现“完全没有注册记录”的异常用户。last_reg_time和last_tau_time用于判断用户有没有定期向网络报告位置如果last_tau_time距离寻呼失败已经超过了一个周期那核心网存的位置可信度就很低。last_rrc_release_time则告诉你用户上一次从连接态进入空闲态的时间和小区那个小区大概率是他离开网络前“最后出现的地方”。参数说明subscriber_session_log是用户上下文历史表有的平台叫user_context_history或ue_mobility_log按实际表名替换。如果平台非实时接口也可以用CSV里的“上一次TAU时间”字段代替。我倾向用SQL是因为方便在同一份数据里完成多表关联并且能重复执行。如果你们平台只有图形界面那就把明细导出到本地后用Excel的VLOOKUP做类似关联但要注意表数据量过大时Excel会卡这时候换用数据库工具更稳。得到关联结果后逐一对照发现某个用户last_tai与寻呼目标tai不一致或者last_rrc_release_time发生在TA边界附近那基本就把问题指向位置陈旧的路线如果所有字段都指向同一个小区且该小区没有异常就把重心转向终端侧。4. 根因逐个拆终端假在线、覆盖空洞还是核心网状态不一致4.1 终端侧从IMEI和终端行为特征识别省电导致的“假在线”如果第3章的关联查询显示用户位置信息没问题、最后活动时间也不陈旧下一个要查的是终端类型和行为。去重后的IMSI列表里如果存在明显的IMEI/TAC集中比如20个用户在问题时段都附着在某款热门手机机型上或者同一TAC下的比例超过60%那就要怀疑终端省电策略或系统版本Bug。终端“假在线”的意思是网络侧看用户是注册状态用户也确实附着在网络上但实际已经进入深度睡眠寻呼监听周期比网络配置的长很多于是错过了呼叫。判断方法有两条。一条是看时间分布把失败时间按小时画柱状图如果集中在晚上21点到次日6点省电嫌疑最大因为用户此时不会主动解锁手机系统进程在后台周期性唤醒的几率更低。另一条是看重复失败的次数同一终端如果连续失败3次以上且每次都间隔固定比如每10分钟一次很可能是终端在每次网络寻呼后短暂醒来但没有正确响应又被网络当成了无响应。我遇到过一次问题根源是某款终端在低电量模式下把5G空闲态DRX周期强制拉长到640ms而网络侧配置的是128ms。终端每640ms醒一次网络侧按128ms周期寻呼每次寻呼时机终端都还没到监听点。这种问题靠网络侧加寻呼重传次数只能部分缓解根治要推动终端厂商调整低电量策略或者网络侧把寻呼周期和该型号终端的省电周期匹配起来。所以对于终端侧问题我们的动作通常是先把IMEI/TAC和对应版本登记成清单再交给终端测试组做复现而不是直接在无线参数上反复试。4.2 无线侧检查SINR、覆盖和寻呼参数信号满格为什么还是收不到终端排查排除了省电原因后回到无线侧看。信号满格不等于寻呼一定能解调成功。5G寻呼信道使用的P-RNTI是公共标识调度信息承载在PDCCH上如果PDCCH的SINR低或者存在同频干扰即使RSRP看着不错UE也可能漏检寻呼信息。因此这个阶段要拉三组数据问题小区寻呼时刻的PDCCH SINR分布、PDCCH BLER、以及同频邻区的干扰情况。另外多波束场景下寻呼时机也值得看清。5G使用SSB波束扫描Paging消息可以在多个波束上重复发送。如果波束覆盖有缺口某个波束指向上UE解调失败但其他波束覆盖不到该UE就会表现为信号不差、寻呼失败。还有一种情况是小区开启了寻呼增强或节能策略在深夜自动把寻呼周期从128ms拉长到256ms或512ms同时减少了重复次数。这不是为了省电吗对但会增大被叫响应时延严重时直接漏呼。节能导致的Subscriber Absent一般在时段上非常规整而且会随季节晚高峰后出现看清楚时间规律再改参数。排查时我会把每个问题小区按“寻呼次数/寻呼成功次数/失败原因码”汇总并和同区域其他小区对比。如果只有这20个用户涉及的几个小区异常则看PDCCH干扰如果整个TA都异常大概率是寻呼参数或核心网配置问题。注意不要只盯RSRP要同时看SINR和小区级Paging成功率趋势。比较好的方式是用下方这张映射表把用户失败对应到小区级指标用户失败特征重点查的小区指标集中在某几个小区SSB覆盖率、PDCCH SINR、寻呼拥塞集中在同一时刻定时任务、节能策略、波束扫描配置整个TA平均分布TA list设计、位置更新定时器、AMF寻呼策略4.3 核心网侧比较注册TA与实际位置更新记录挖出“幽灵注册”最后一类是核心网状态不一致业内也管它叫“幽灵注册”——用户实际上已经离开了某个TA但核心网上下文里还记着旧位置寻呼下发到旧的位置区用户自然听不到。验证步骤很简单把第3章关联出的last_tai和寻呼下发时使用的tai做比对。正常情况下这俩应该一致或位于同一个TA list内。如果发现last_tai与寻呼目标tai相差很远或者last_tau_time已经超过T3412周期性位置更新定时器很久就能确定是位置信息过期。这里需要特别留意一个容易混淆的点用户最近一次TAU成功并不等于位置一定准确。如果T3412配置过长比如62分钟用户在这62分钟内从TA1移动到TA2但没有跨越TA list边界就不会触发TAU。AMF在寻呼时基于过期TA list发寻呼结果找不到人。这种情况下Subscriber Absent报表在TA边界会形成一条明显的“带状高发区”从地图上看正好沿着两个TA list接缝处分布。优化方向是修改TA list的分配策略让边界形状规避高移动性区域同时缩短周期性位置更新周期但也要权衡信令负荷。还有第三种不常见的情况UDM里用户关联的AMF已释放但用户设备没有主动去注册网络侧没有同步删除旧上下文导致寻呼请求被发到了一个已经不再服务的AMF。这种需要看N2口消息流中Paging message是来自当前服务AMF还是旧AMF排查时要结合AMF变更日志。如果确认是这类通常要检查不同AMF之间的用户上下文同步机制并推动核心网厂商打补丁。我们在实际项目里遇到的频率不高但一旦发生报表上会是一个大范围内的零散Subscriber Absent且无线和终端参数都正常很容易让人浪费很多时间在调天线上。5. 避坑清单5个让排查走弯路的Subscriber Absent误判现场5.1 现象加站后问题依旧别急着怀疑覆盖某一类用户集中出现在弱覆盖区域投诉也确实说信号不好优化人员很快加了个站。然而三个月后回看Subscriber Absent报表并没有下降。原因这些用户在弱覆盖场景下自动开启了“极致省电”模式网络寻呼周期和终端监听周期不一致加站只是改善了RSRP没有解决终端不按时醒来的问题。解决加站前先按IMEI/TAC看终端型号是否高度集中如果集中先做终端侧省电策略的适配而不是先动无线。这次案例里20个用户里有16个手机型号相同这是最大的一条线索我一开始却花了一周去调天线算是一次血泪教训。5.2 现象同一个IMSI反复出现但现场测试拨号正常某开发者拿着测试机在现场做了几十次被叫测试每次都通。后台Subscriber Absent却连续三天出现同一个用户。原因测试机系统配置和问题用户不同现场测试没有结算用户真实的省电或移动轨迹后台失败发生时段是凌晨测试在白天。解决按IMSI导出该用户24小时的注册、TAU、寻呼失败时间线看是否存在周期性时间窗口。看到凌晨3点连续失败、白天正常基本确定是夜间终端行为白天测试天然无法复现。后来我们让用户开着自动开关机、关掉省电模式再观察Subscriber Absent立刻消失证实了判断。5.3 现象20条全部出现在凌晨白天一条没有如果报表里Subscriber Absent在时间维度上“整齐划一”不要只盯着终端还要查小区节能策略。原因某厂家基站开启基于负荷的节能在凌晨把寻呼周期从128调整到512同时寻呼次数从3降到1正好撞上终端默认的省电监听窗口。解决先看网管中该小区凌晨的寻呼周期实际值和终端期望值做对比。调优时不要直接关掉节能而是把寻呼周期上限设为256、保证至少2次寻呼重传这样对节能收益影响很小被叫感受却好很多。5.4 现象从报表里看到的TA和用户实际活动信令的TA对不上有一些Subscriber Absent失败记录里用户最后注册的TA和寻呼发往的TA并不一致但时间上只差几分钟。原因用户在高移动性场景下跨过了TA list边界却没有触发TAU或者TAU消息在核心网侧处理延迟位置更新还没完成寻呼请求已经发出来了。解决检查TA list配置避免在高铁/快速路沿线划出过长的线性TA边界同时核对核心网位置更新至寻呼流程之间的延迟统计。如果是周期性TAU定时器太长把T3412从54分钟调到36分钟观察TAU信令负荷虽然有增加但Subscriber Absent下降明显。5.5 现象Subscriber Absent与“正常释放”同时出现被报表误伤解析CSV时发现一些记录标明结果是Subscriber Absent但同时又有一条Separation Complete或De-registration消息紧随其后时间差不到1秒。原因用户主动关闭5G功能或拔出SIM卡但没有按流程发起显式去注册网络侧在随后被叫时才发现用户不在。解决查询时过滤掉后续10秒内有De-registration的记录把这些归入“非真实寻呼失败”。重新统计后真实Subscriber Absent数量从20降到了14少掉的6条根本不值得优化。把这类干扰项摘干净能避免后台指标虚高、让团队空耗力气。6. 从20条到0条参数验证、监控复跑和让问题“隐身”的方法问题定位到主因后调优动作要带验证闭环。以我那次案例最终确定为“终端省电小区节能叠加”为例我分成三步做。第一步先做参数回退验证把涉及小区的寻呼周期上限从512ms改回256ms重传次数从1改为2同时把该区域TAU周期从54分钟缩短到36分钟射频侧不动。第二步观察一个完整的业务晚高峰到凌晨再跑同一条明细查询SQL看覆盖相同时间窗口的Subscriber Absent是否从20条降到5条以内。第三步如果下降不明显回头查终端型号联系终端侧关闭低电量模式下的“5G空闲态超长DRX”开关。最终那次问题在调整后第二天降到6条两周后降到0条且没有新增“寻呼次数明显增加”的副作用。验证阶段建议用下面这张参数记录表每次都留档参数域参数名调整前调整后生效范围无线寻呼Paging周期512ms256ms问题小区无线寻呼最大重传次数12问题小区核心网移动性T341254min36min问题TA区节能开关节能时段寻呼策略与日常相同按调整后值夜间节能小区回看这次排查我最大的教训是别被“Subscriber Absent”里“Absent”这个词带偏以为就是用户不在。用户其实一直在网络里只是他的终端不愿意在那个时刻醒来。SEQ平台给你的是一个黑匣子的单点输出你要是只守着这个出口看会花很多时间在无线侧做无效功而把信令链路上的IMEI/TAC、TAU时间、节能参数、寻呼周期并到一起看真相往往几分钟就能浮出来。从那以后我每天早上看SEQ报表时都会先看一眼Subscriber Absent绝对值有没有突增再按IMSI去重并按TAC聚合成一张小表。如果突增且集中在夜间我会先去翻该时段节能策略和寻呼参数的变更记录而不是急着派单让外场去测覆盖。希望这篇笔记里的查询模板和排查顺序能帮你下一次面对那张报表时不用再熬三个晚上。本文还有配套的精品资源点击获取
简介围绕5G网络中SEQ系统上报的20 Subscriber Absent错误码这份案例文档从现象触发到根因定位呈现了一套完整排障链条适合5G与VoLTE网络优化工程师、核心网运维人员以及投诉处理团队参考。文档先解释IMS未注册导致用户缺席的基本含义再分步展开终端能力核查、网络侧IMS支持性确认、S1-MME与N1N2信令单据审查、SIP拆线网元归属判断等关键动作并特别讨论5G回落4G时触发该原因值的可能场景指出接入侧回落问题与IMS域拆线码之间的区分要点。内容兼顾原理说明与实战案例可帮助读者建立按阶段拆解问题的思路从信令数据入手分辨关机、数据业务异常和VoLTE能力不足等不同根因。资源为单个docx文档压缩包仅96KB下载后即可阅读。目前已有321人学习适合需要快速理解该错误码的网优人员作为备查资料。1. 一次SEQ上报让我盯了三个晚上20个Subscriber Absent背后不只是覆盖问题某天例行巡视我在SEQ信令分析平台上看到一张寻呼失败统计表数据一夜之间冒出了20条“Subscriber Absent”记录集中在同一个TA区。上报的含义是网络向这20个用户发起了寻呼但用户始终没有响应。当晚投诉就有三起都反映“别人打电话来手机不响等几十分钟后才看到未接来电”。我第一反应是查覆盖可后台看每个用户的驻留小区RSRP都在-100dBm以上信号并不差。真正让我坐不住的是这20条不是零散分布而是同一个小时间段内连续上报像是有规律地被“挤”出来。这背后可能涉及终端省电、核心网状态不一致、寻呼参数配置等多重因素光靠加站、调天线解决不了。本文从这条SQL一样的排查线索出发完整走一遍“看懂报表—拉取清单—逐项定位—参数调优—验证效果”的流程适合正在做5G网络优化、投诉处理或核心网信令分析的朋友。如果你也是半夜被SEQ报表叫醒的人这篇能帮你少走不少弯路。2. Subscriber Absent在5G信令里是怎样产生的先搞懂寻呼响应链2.1 寻呼流程中的“最后一环”失败为什么网络侧记为Subscriber Absent5G网络里一次最简单的被叫流程是这样走的主叫侧触发对目标UE的业务请求后服务该用户的AMF会先查用户上下文里保存的TA list和基带标识再通过N2接口向可能覆盖到用户的gNB下发Paging消息。gNB收到后把寻呼消息装配进空口的Paging信道用P-RNTI调度终端在RRC_IDLE或RRC_INACTIVE下按DRX周期醒来监听。UE如果监听到自己的IMSI或S-TMSI就发起RRC连接建立随后网络继续往下走。这一环只要有一处对不上——UE没醒、醒晚了、广播携带的PO计算参数不一样、或者UE已经移动到另一个TA但还没做位置更新——就会出现“网络发了寻呼UE没有任何响应”。最终AMF侧的寻呼等待定时器超时AMF把这条失败记成Subscriber Absent。Subscriber Absent这个原因值在标准里属于“用户不可及”这一类。它只说明结果被叫用户在当前网络状态内不可达。它不告诉你为什么不可达。这是排查看似简单、实际最容易跑偏的地方。比如一个终端插着SIM卡屏幕看起来也注册上了但用户开启了超级省电模式终端把寻呼监听从每个DRX周期醒一次改成几十秒甚至几分钟才醒一次网络按默认32个无线帧周期寻呼连续找两三次都找不到此时上报Subscriber Absent就非常合理。这种情况在夜间特别多。另一个常见场景是移动性带来的状态陈旧。5G网络使用基于TA list的注册机制用户在一个TA list内移动不需要每次更新但Paging还是会下发到该list内所有小区。如果用户实际已经离开这个TA list却因为定时器还没到期、没有触发新的TAU那么AMF存的位置就是旧的。按旧位置寻呼用户根本听不到。在高密度城区TA边界处这一步很容易出问题。看现象用户区域信号很好、测试拨号也通但后台就是持续出现Subscriber Absent。因此拿到这个原因值不要第一时间去开修改单。先把寻呼响应链的每个环节拆开终端有没有在监听无线侧的寻呼内容有没有送出去核心网知不知道用户在哪这三个问题对应不同数据域而SEQ正好把这三个域的信令都归拢到了一张表里。这就是我们后续分析的基础。2.2 “20”这个数字是怎么统计出来的看清口径再动手SEQ平台的报表通常从N2接口或服务化接口采集原始信令再按时间、网元、原因值做聚合。不同厂家的“上报”口径存在差异有的按寻呼尝试次数计数有的按寻呼失败消息条数计数还有的按IMSI去重后计数。我这边的平台当时默认是“每次失败记一条”所以报表里“Subscriber Absent20”只能代表20次失败并不直接等于20个用户。我把明细拉出来后做了去重发现只有13个IMSI其中7个用户重复失败。重复失败的用户有一个共同点第一次失败之后网络重发了寻呼依然失败于是又积累了几条记录。这个统计口径差异是第一个坑。如果不先做去重而是直接用20除以全天寻呼成功次数算比例会把问题放大。更稳妥的做法是先导出原始明细确定三件事一是这20条分布在多长的时间跨度内二是涉及多少个IMSI、多少个gNB三是这些失败是不是由寻呼重传产生的重复计数。只有去掉了重传和重复计数你手里的数字才接近真实受影响人群。在5G里寻呼重传本身由AMF控制通常是2到4次每次间隔若干秒。如果AMF配置了在多个TA或gNB下重试每一次尝试都会产生一条独立的信令记录。我在之前的项目里最开始看到某个用户一晚上有9条Subscriber Absent以为小区出了问题后来对照消息时间戳才发现那其实是同一次被叫在9个寻呼周期内依次失败。把9条按时间戳串起来才看到是一条连续失败的完整轨迹而不是9个孤立事件。所以拿到一张“20 Subscriber Absent”的报表我的习惯是先做成一张透视表横轴是时间纵轴是IMSI看失败点是不是集中在某个时间段或某个TAC下。这种散点分布能告诉你问题的性质集中在凌晨0点到6点大概率是终端省电或网络节能集中在用户上下班路径上大概率是TA边界和移动性问题完全随机散布则要考虑覆盖盲区和干扰。这一步做完再进入明细查询效率会高很多。2.3 Subscriber Absent与其他寻呼失败原因别把最终原因当成根因在SEQ的失败原因字典里Subscriber Absent只是一个“最终结论”。真正失败过程中还可能看到radioNetworkLayer-cause、timeout、noResponse等中间原因。我在这里放一张简化的对比表方便你后续拿到报表时快速归类原因值出现的位置典型含义下一步重点查的方向Subscriber AbsentAMF侧寻呼结果UE无响应不可及终端状态、寻呼时机、TA一致性radioNetworkLayer-causegNB向AMF上报无线层失败如资源不足、干扰覆盖、拥塞、P-RNTI质量NAS cause #26等NAS流程无线资源不足或用户拒绝空口质量、终端侧行为User Inactive核心网会话管理用户无活动网络释放资源业务模型、保活机制注意一个事件链上可能会先出现“gNB reported radioNetworkLayer-cause”随后AMF才在后续重寻呼失败后判定Subscriber Absent。所以SEQ输出只把最终的Subscriber Absent呈现出来不代表无线侧没有问题。反过来如果无线侧一切正常、干扰也低但Subscriber Absent持续高发就要往终端和核心网状态上去想。表里的每一种原因值其实都代表一个排查入口不要抓住最后一个就收工。3. 把SEQ表里那20条捞出来过滤条件、聚类查询和一条可抄的SQL3.1 按时间窗和TA过滤先圈定现场再开查打开SEQ平台的明细查询界面通常会有“信令类型”“时间范围”“用户/网元”这几组条件。我的建议是先做窄过滤信令类型选“寻呼失败”或“Paging Failure”原因值选Subscriber Absent时间范围覆盖前一天0点到24点TA/TAC填报表上该问题区域对应的值网元层面先不过滤等明细出来再看gNB分布。这样做是为了避免一开始就把范围拉得太大把全国其他偶然发生的Subscriber Absent都混进来。有些SEQ平台支持类似SQL的查询或者在导出功能里自带筛选。如果只有图形界面操作顺序一般是进入“寻呼失败明细表”时间选“自定义”开始时间填前一天00:00:00结束时间填23:59:59然后在“失败原因”下拉框里选择“subscriberAbsent”在“位置信息”里填入目标TA。导出CSV时字段至少要包含IMSI、UE标识、gNB ID、小区ID、TA/TAC、首次尝试时间、最后尝试时间、失败原因、关联注册状态。如果平台支持勾选记得勾上“包含重寻呼记录”否则可能丢失重复失败数据。这一步的目标是拿到干净的原始数据集。我一般会把导出文件命名为“日期_TA_subscriberAbsent.csv”放到当天的分析目录下。后面每一轮分析都以这个文件为基础不反复回到平台里手动翻看。一来可复现二来万一你被其他事情打断回来也能继续。3.2 按IMSI去重统计把“20条”还原成“13个用户”拿到CSV之后第一件事是去重。很多时候平台导出的数据里同一个用户的同一次连续失败会被拆成多条记录。下面这段SQL是在支持SQL接口的SEQ系统上常用的一种聚合方式逻辑能在大多数关系型数据库上跑通SELECT imsi, COUNT(*) AS fail_times, COUNT(DISTINCT gnb_id) AS involved_gnbs, COUNT(DISTINCT tai) AS involved_tas, MIN(first_fail_time) AS first_fail, MAX(last_fail_time) AS last_fail FROM paging_failure_detail WHERE failure_reason subscriberAbsent AND failure_time BETWEEN 2025-03-10 00:00:00 AND 2025-03-10 23:59:59 GROUP BY imsi ORDER BY fail_times DESC;代码逻辑说明先按IMSI分组计算每个用户失败次数、涉及多少个gNB、涉及多少个TA以及第一次和最后一次失败的具体时间。重点看fail_times大于1的记录因为这意味着同一个用户被寻呼了多次都失败问题可能出在终端或核心网状态上而不是偶发覆盖问题。如果involved_gnbs也大于1说明网络在多个基站下都试图呼叫该用户依然没找到那就可以更坚定排除单一小区覆盖问题。参数说明failure_time字段按你的平台命名调整如果上面的表里没有imsi但有s-tmsi那就先按s-tmsi聚合并看是否能结合NAS上下文映射到IMSI。一定要把时间范围写成完整的一天不要直接写“最近24小时”因为“最近24小时”会随着查询时刻漂移无法和前天、后天的数据对齐。执行完这段SQL后你应该得到一张用户级别的失败分布表。拿我那次数据举例20条记录去重后得到如下结果用户组用户数失败次数平均首次失败时间A类9102:15B类3301:40C类1500:52从这个表格已经能看出B类和C类用户是被反复寻呼都失败的属于核心矛盾。接下来要关联他们最后一次成功注册/TAU的位置看和寻呼目标位置是否一致。3.3 关联注册上下文看用户失败前最后一次有效活动只有去重后的IMSI还不够得从用户上下文表里取出每个用户最后一次成功注册或TAU时的位置这样才能判断“网络在哪儿找他”和“他实际应该在哪儿”是否匹配。很多SEQ平台会把注册流程和寻呼流程放在同一张宽表里或者至少通过IMSI关联到“用户会话日志”。下面是最常见的关联查询模板SELECT p.imsi, p.fail_times, p.first_fail, s.last_reg_time, s.last_tau_time, s.last_gnb_id, s.last_tai, s.last_rrc_release_time FROM paging_failure_summary p LEFT JOIN subscriber_session_log s ON p.imsi s.imsi WHERE p.fail_times 1 ORDER BY p.fail_times DESC;逻辑说明LEFT JOIN保证即使是平台里没留下最近会话记录的用户也能出现在结果集中方便你发现“完全没有注册记录”的异常用户。last_reg_time和last_tau_time用于判断用户有没有定期向网络报告位置如果last_tau_time距离寻呼失败已经超过了一个周期那核心网存的位置可信度就很低。last_rrc_release_time则告诉你用户上一次从连接态进入空闲态的时间和小区那个小区大概率是他离开网络前“最后出现的地方”。参数说明subscriber_session_log是用户上下文历史表有的平台叫user_context_history或ue_mobility_log按实际表名替换。如果平台非实时接口也可以用CSV里的“上一次TAU时间”字段代替。我倾向用SQL是因为方便在同一份数据里完成多表关联并且能重复执行。如果你们平台只有图形界面那就把明细导出到本地后用Excel的VLOOKUP做类似关联但要注意表数据量过大时Excel会卡这时候换用数据库工具更稳。得到关联结果后逐一对照发现某个用户last_tai与寻呼目标tai不一致或者last_rrc_release_time发生在TA边界附近那基本就把问题指向位置陈旧的路线如果所有字段都指向同一个小区且该小区没有异常就把重心转向终端侧。4. 根因逐个拆终端假在线、覆盖空洞还是核心网状态不一致4.1 终端侧从IMEI和终端行为特征识别省电导致的“假在线”如果第3章的关联查询显示用户位置信息没问题、最后活动时间也不陈旧下一个要查的是终端类型和行为。去重后的IMSI列表里如果存在明显的IMEI/TAC集中比如20个用户在问题时段都附着在某款热门手机机型上或者同一TAC下的比例超过60%那就要怀疑终端省电策略或系统版本Bug。终端“假在线”的意思是网络侧看用户是注册状态用户也确实附着在网络上但实际已经进入深度睡眠寻呼监听周期比网络配置的长很多于是错过了呼叫。判断方法有两条。一条是看时间分布把失败时间按小时画柱状图如果集中在晚上21点到次日6点省电嫌疑最大因为用户此时不会主动解锁手机系统进程在后台周期性唤醒的几率更低。另一条是看重复失败的次数同一终端如果连续失败3次以上且每次都间隔固定比如每10分钟一次很可能是终端在每次网络寻呼后短暂醒来但没有正确响应又被网络当成了无响应。我遇到过一次问题根源是某款终端在低电量模式下把5G空闲态DRX周期强制拉长到640ms而网络侧配置的是128ms。终端每640ms醒一次网络侧按128ms周期寻呼每次寻呼时机终端都还没到监听点。这种问题靠网络侧加寻呼重传次数只能部分缓解根治要推动终端厂商调整低电量策略或者网络侧把寻呼周期和该型号终端的省电周期匹配起来。所以对于终端侧问题我们的动作通常是先把IMEI/TAC和对应版本登记成清单再交给终端测试组做复现而不是直接在无线参数上反复试。4.2 无线侧检查SINR、覆盖和寻呼参数信号满格为什么还是收不到终端排查排除了省电原因后回到无线侧看。信号满格不等于寻呼一定能解调成功。5G寻呼信道使用的P-RNTI是公共标识调度信息承载在PDCCH上如果PDCCH的SINR低或者存在同频干扰即使RSRP看着不错UE也可能漏检寻呼信息。因此这个阶段要拉三组数据问题小区寻呼时刻的PDCCH SINR分布、PDCCH BLER、以及同频邻区的干扰情况。另外多波束场景下寻呼时机也值得看清。5G使用SSB波束扫描Paging消息可以在多个波束上重复发送。如果波束覆盖有缺口某个波束指向上UE解调失败但其他波束覆盖不到该UE就会表现为信号不差、寻呼失败。还有一种情况是小区开启了寻呼增强或节能策略在深夜自动把寻呼周期从128ms拉长到256ms或512ms同时减少了重复次数。这不是为了省电吗对但会增大被叫响应时延严重时直接漏呼。节能导致的Subscriber Absent一般在时段上非常规整而且会随季节晚高峰后出现看清楚时间规律再改参数。排查时我会把每个问题小区按“寻呼次数/寻呼成功次数/失败原因码”汇总并和同区域其他小区对比。如果只有这20个用户涉及的几个小区异常则看PDCCH干扰如果整个TA都异常大概率是寻呼参数或核心网配置问题。注意不要只盯RSRP要同时看SINR和小区级Paging成功率趋势。比较好的方式是用下方这张映射表把用户失败对应到小区级指标用户失败特征重点查的小区指标集中在某几个小区SSB覆盖率、PDCCH SINR、寻呼拥塞集中在同一时刻定时任务、节能策略、波束扫描配置整个TA平均分布TA list设计、位置更新定时器、AMF寻呼策略4.3 核心网侧比较注册TA与实际位置更新记录挖出“幽灵注册”最后一类是核心网状态不一致业内也管它叫“幽灵注册”——用户实际上已经离开了某个TA但核心网上下文里还记着旧位置寻呼下发到旧的位置区用户自然听不到。验证步骤很简单把第3章关联出的last_tai和寻呼下发时使用的tai做比对。正常情况下这俩应该一致或位于同一个TA list内。如果发现last_tai与寻呼目标tai相差很远或者last_tau_time已经超过T3412周期性位置更新定时器很久就能确定是位置信息过期。这里需要特别留意一个容易混淆的点用户最近一次TAU成功并不等于位置一定准确。如果T3412配置过长比如62分钟用户在这62分钟内从TA1移动到TA2但没有跨越TA list边界就不会触发TAU。AMF在寻呼时基于过期TA list发寻呼结果找不到人。这种情况下Subscriber Absent报表在TA边界会形成一条明显的“带状高发区”从地图上看正好沿着两个TA list接缝处分布。优化方向是修改TA list的分配策略让边界形状规避高移动性区域同时缩短周期性位置更新周期但也要权衡信令负荷。还有第三种不常见的情况UDM里用户关联的AMF已释放但用户设备没有主动去注册网络侧没有同步删除旧上下文导致寻呼请求被发到了一个已经不再服务的AMF。这种需要看N2口消息流中Paging message是来自当前服务AMF还是旧AMF排查时要结合AMF变更日志。如果确认是这类通常要检查不同AMF之间的用户上下文同步机制并推动核心网厂商打补丁。我们在实际项目里遇到的频率不高但一旦发生报表上会是一个大范围内的零散Subscriber Absent且无线和终端参数都正常很容易让人浪费很多时间在调天线上。5. 避坑清单5个让排查走弯路的Subscriber Absent误判现场5.1 现象加站后问题依旧别急着怀疑覆盖某一类用户集中出现在弱覆盖区域投诉也确实说信号不好优化人员很快加了个站。然而三个月后回看Subscriber Absent报表并没有下降。原因这些用户在弱覆盖场景下自动开启了“极致省电”模式网络寻呼周期和终端监听周期不一致加站只是改善了RSRP没有解决终端不按时醒来的问题。解决加站前先按IMEI/TAC看终端型号是否高度集中如果集中先做终端侧省电策略的适配而不是先动无线。这次案例里20个用户里有16个手机型号相同这是最大的一条线索我一开始却花了一周去调天线算是一次血泪教训。5.2 现象同一个IMSI反复出现但现场测试拨号正常某开发者拿着测试机在现场做了几十次被叫测试每次都通。后台Subscriber Absent却连续三天出现同一个用户。原因测试机系统配置和问题用户不同现场测试没有结算用户真实的省电或移动轨迹后台失败发生时段是凌晨测试在白天。解决按IMSI导出该用户24小时的注册、TAU、寻呼失败时间线看是否存在周期性时间窗口。看到凌晨3点连续失败、白天正常基本确定是夜间终端行为白天测试天然无法复现。后来我们让用户开着自动开关机、关掉省电模式再观察Subscriber Absent立刻消失证实了判断。5.3 现象20条全部出现在凌晨白天一条没有如果报表里Subscriber Absent在时间维度上“整齐划一”不要只盯着终端还要查小区节能策略。原因某厂家基站开启基于负荷的节能在凌晨把寻呼周期从128调整到512同时寻呼次数从3降到1正好撞上终端默认的省电监听窗口。解决先看网管中该小区凌晨的寻呼周期实际值和终端期望值做对比。调优时不要直接关掉节能而是把寻呼周期上限设为256、保证至少2次寻呼重传这样对节能收益影响很小被叫感受却好很多。5.4 现象从报表里看到的TA和用户实际活动信令的TA对不上有一些Subscriber Absent失败记录里用户最后注册的TA和寻呼发往的TA并不一致但时间上只差几分钟。原因用户在高移动性场景下跨过了TA list边界却没有触发TAU或者TAU消息在核心网侧处理延迟位置更新还没完成寻呼请求已经发出来了。解决检查TA list配置避免在高铁/快速路沿线划出过长的线性TA边界同时核对核心网位置更新至寻呼流程之间的延迟统计。如果是周期性TAU定时器太长把T3412从54分钟调到36分钟观察TAU信令负荷虽然有增加但Subscriber Absent下降明显。5.5 现象Subscriber Absent与“正常释放”同时出现被报表误伤解析CSV时发现一些记录标明结果是Subscriber Absent但同时又有一条Separation Complete或De-registration消息紧随其后时间差不到1秒。原因用户主动关闭5G功能或拔出SIM卡但没有按流程发起显式去注册网络侧在随后被叫时才发现用户不在。解决查询时过滤掉后续10秒内有De-registration的记录把这些归入“非真实寻呼失败”。重新统计后真实Subscriber Absent数量从20降到了14少掉的6条根本不值得优化。把这类干扰项摘干净能避免后台指标虚高、让团队空耗力气。6. 从20条到0条参数验证、监控复跑和让问题“隐身”的方法问题定位到主因后调优动作要带验证闭环。以我那次案例最终确定为“终端省电小区节能叠加”为例我分成三步做。第一步先做参数回退验证把涉及小区的寻呼周期上限从512ms改回256ms重传次数从1改为2同时把该区域TAU周期从54分钟缩短到36分钟射频侧不动。第二步观察一个完整的业务晚高峰到凌晨再跑同一条明细查询SQL看覆盖相同时间窗口的Subscriber Absent是否从20条降到5条以内。第三步如果下降不明显回头查终端型号联系终端侧关闭低电量模式下的“5G空闲态超长DRX”开关。最终那次问题在调整后第二天降到6条两周后降到0条且没有新增“寻呼次数明显增加”的副作用。验证阶段建议用下面这张参数记录表每次都留档参数域参数名调整前调整后生效范围无线寻呼Paging周期512ms256ms问题小区无线寻呼最大重传次数12问题小区核心网移动性T341254min36min问题TA区节能开关节能时段寻呼策略与日常相同按调整后值夜间节能小区回看这次排查我最大的教训是别被“Subscriber Absent”里“Absent”这个词带偏以为就是用户不在。用户其实一直在网络里只是他的终端不愿意在那个时刻醒来。SEQ平台给你的是一个黑匣子的单点输出你要是只守着这个出口看会花很多时间在无线侧做无效功而把信令链路上的IMEI/TAC、TAU时间、节能参数、寻呼周期并到一起看真相往往几分钟就能浮出来。从那以后我每天早上看SEQ报表时都会先看一眼Subscriber Absent绝对值有没有突增再按IMSI去重并按TAC聚合成一张小表。如果突增且集中在夜间我会先去翻该时段节能策略和寻呼参数的变更记录而不是急着派单让外场去测覆盖。希望这篇笔记里的查询模板和排查顺序能帮你下一次面对那张报表时不用再熬三个晚上。本文还有配套的精品资源点击获取
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
