5G SA信令分析全流程实战：从开机入网到切换完成-北京尧图网络

简介面向5G网络优化与信令分析人员这份指导书以端到端信令流程为主线系统梳理终端从开机入网到会话建立、切换及NAS信令的完整过程可帮助读者快速建立5G信令分析框架解决网优现场常见流程定位问题。资源为单个docx文档压缩包仅含1个文件大小4.24MB结构清晰、便于按目录检索。目前已有61人学习下载。文档重点覆盖小区搜索与选择、系统消息获取/更新与ODOSI过程、竞争/非竞争随机接入、RRC建立/拒绝/重发处理以及初始上下文建立、5G QoS架构、PDU会话建立/修改/释放、5GC/RAN寻呼等关键环节包含MIB、SIB1、SI关键消息解读切换部分详解站内、Xn、N2及LNR切换与重定向NAS流程则涉及注册、去注册及主被叫业务请求。对需要系统掌握5G信令流程、开展日常信令跟踪与故障分析的网优工程师而言是一份高密度的案头参考资料。1. 5G SA信令分析从“开机入网”到“切换完成”到底要过几道关做网优的人多半有过这种时刻抓了一堆5G信令单看每条消息都认识串起来就卡壳。比如被叫没接通到底是寻呼丢了还是RRC重配慢了用户投诉速率上不去是QoS Flow映射错位还是DRB承载没建起来。这份《5G信令分析指导书》把5G SA从UE开机入网、随机接入、RRC建立、上下文管理、PDU会话、寻呼、切换到NAS全流程按3GPP规范重新拆了一遍每个关键消息的字段都做了标注。适合刚转5G的网优新人建立信令流程骨架也适合老手在参数核查和故障定界时当速查手册。2. 开机入网从PSS/SSS检测到RRC连接建立的五步链路2.1 小区搜索与PCI识别同步栅格、SSB波束和MIB的读取顺序UE开机后要做的第一件事不是读系统消息而是先把小区“找出来”。指导书里把小区搜索拆成五个步骤这五步的顺序不能乱按同步栅格搜频点频点编号走的是GSCN规则而不是普通信道栅格目的就是减少搜索候选位置尝试检测PSS/SSS取得下行时钟同步并获取PCI如果失败就转到下一个频点继续搜读取MIB拿到SSB波束信息、系统帧号和SIB1的时频域位置读取SIB1拿到上行初始BWP、公共信道配置、TDD半静态配比以及OSI搜索空间读取OSI获取邻区、重选等移动性相关信息。这里有个容易忽略的点PCI的计算是3乘以辅同步信号组号再加主同步信号号PSS只有三组、SSS有336组组合出来1008个PCI。现场排查PCI混淆或PCI冲突时不光要看PCI数值还要看SSB波束方向。PSS/SSS检测失败一般不是覆盖问题就是频点配错如果PSS/SSS检测成功但MIB读不出来大概率是SSB子载波间隔和CORESET0配置对不上。MIB里的几个字段对后续流程影响很大ssb-SubcarrierOffset决定SSB和CRB网格的偏移pdcch-ConfigSIB1里面8个bit同时指示了CORESET0的频域位置和时域符号数还有SIB1的搜索空间周期。这几个参数任何一个配错SIB1就解不出来后面的流程全是白搭。我在现场排查“能搜到小区但无法驻留”的Case时第一步永远是让测试终端打出MIB解析结果先排除CORESET0配置问题。2.2 系统消息获取与更新MIB、SIB1、OSI与ODOSI按需订阅系统消息按照3GPP分类可以拆成MSI和OSI两大类。MSI是最小系统消息包含MIB和SIB1也叫RMSIOSI是其他系统消息从SIB2一直排到SIBn。两者的下发方式和承载内容差别很大整理如下大类承载下发方式承载内容MSIMIB周期广播周期通过SSB周期参数配置初始接入信息和SIB1的捕获信息MSISIB1周期广播周期通过SIB1周期参数配置OSI捕获信息、小区接入参数、TDD配比OSISIB2~SIBn周期广播或按需订阅广播邻区、重选、ETWS、CMAS等扩展信息UE什么时候读系统消息指导书里写得很清楚开机选网、小区重选、切换完成、从其他RAT进入NR、从无覆盖区回到覆盖区这五种场景都会主动拉取。但拿到一次之后不会反复读只有三种情况会重新读收到寻呼指示系统消息变化、收到寻呼指示有ETWS/CMAS广播、距离上次正确接收满3小时。3小时这个数字来自协议里的SIB有效期规则我在实际排查里确实遇到过终端长时间不刷新系统消息导致重选异常的问题时间点就和这个有效期高度相关。ODOSI是这段内容里最有实操价值的部分。OSI里的SIB并不全是周期广播gNB可以配置成“订阅广播”UE先在SIB1里读si-SchedulingInfo看到某个SI消息的广播状态是“not broadcast”就发起订阅请求。订阅有两条路Msg1方式和Msg3方式。Msg1方式是UE发一个专用的随机接入前导码来请求SIMsg3方式是在RRCSetupRequest消息里带上si-Request信息。现网配置里如果某个SIB是非周期广播而UE还按老思路死等就会出现“邻区信息拿不全但手机不自知”的情况这类问题在高铁重选场景里最容易翻车。2.3 随机接入基于竞争与非竞争的RA流程与关键参数随机接入是UE从“下行同步”跨到“上行同步”的关键一步。指导书把RA分成两大类基于竞争的随机接入和基于非竞争的随机接入。流程差异很直观类型触发场景核心步骤竞争风险基于竞争初始接入、RRC重建、上行失步后的数据到达Msg1前导→Msg2 RAR→Msg3 RRC请求→Msg4竞争解决多个UE选同一前导码时冲突基于非竞争切换、波束失败恢复、网络主动要求上行同步网络分配专用前导→UE发Msg1→gNB回Msg2无竞争专用前导唯一基于竞争的RA里Msg3和Msg4是关键。Msg3承载RRCSetupRequest或RRCResumeRequestMsg4用于竞争解决UE只有收到Msg4且冲突解决成功才算真正完成随机接入。参数层面要注意prach-ConfigurationIndex决定前导格式和时域位置、msg1-FDM频域复用因子可配1/2/4/8、preambleReceivedTargetPower初始目标接收功率常见配置为-104dBm附近、powerRampingStep每次失败后的功率爬升步长现网多用2dB或4dB。如果终端反复在Msg1上失败且没有功率爬升迹象优先怀疑prach时频资源配置冲突而不是无脑加功率。2.4 RRC连接建立与注册从RRCSetupRequest到注册完成的完整路径RRC建立过程是UE入网的最后一道空口工序。正常路径是UE发RRCSetupRequestgNB回RRCSetup建立SRB1UE再回RRCSetupComplete携带NAS层的注册请求。RRCSetupRequest里有两个值得看的字段establishmentCause和ue-Identity。前者区分紧急呼叫、高优先级接入、被叫接入、主叫信令、主叫数据等场景后者在现网里常见是I-RNTI或者5G-S-TMSI的截断值。如果排查被叫未接通先看establishmentCause是不是mt-Access不是的话大概率是UE侧业务发起时机的问题。RRC拒绝和重发是网优分析里容易漏掉的两个分支。RRCReject消息里带waitTime参数UE收到后要等这个时间再发起范围是1到16秒。如果waitTime配置过大被叫用户会明显感觉“手机怎么拨不出去了”。RRC重发则受T300定时器控制UE发出RRCSetupRequest后启动T300T300超时还没收到RRCSetup或RRCReject就判定RRC建立失败可能触发RRC重建或直接返回空闲态。现场调整T300的经验值是覆盖差的边缘小区适当调大比如1000ms容量紧张的小区调小500ms甚至更小但调小后要盯着掉话率变化。注册流程是开机入网的收尾。UE在RRCSetupComplete里携带NAS Registration Request网络侧做AMF选择、安全校验后回Registration Accept。这个流程如果失败多数不是空口问题而是核心网侧签约数据或切片配置的问题看到注册失败时建议直接跳到NGAP消息去查原因值。3. 上下文与会话管理从初始上下文建立、QoS参数到PDU会话的关键信息3.1 初始上下文建立与安全模式NGAP消息与RRC安全激活UE完成注册后网络侧要开始“正经”维护这个UE的上下文了。初始上下文建立过程由核心网发起AMF给gNB下发NGAP INITIAL CONTEXT SETUP REQUEST里面带UE上下文ID、安全能力、PDU会话资源列表等信息。gNB收到后要做两件事一是建立UE上下文二是触发空口安全激活。安全激活的顺序有讲究先完整性保护后加密。RRC SecurityModeCommand里携带完整性算法和加密算法的选择结果UE校验通过后回SecurityModeComplete密钥在AS层生效。之后gNB认为空口链路是安全的才会继续下发UE能力查询和后续承载配置。算法选择上有个常见认知NIA0/NEA0代表不开启完整性/加密现网里运营商策略不同有些场景为了省终端功耗或兼容老终端会允许NEA0但完整性保护一般都会开。安全模式失败在现网里的典型现象是RRC连接频繁重建排查方向是核对核心网下发的安全能力列表和gNB支持的算法交集是否为空。UE能力查询过程紧跟在安全激活之后。gNB发RRC UECapabilityEnquiryUE回RRC UECapabilityInformation里面包含支持的频段组合、载波聚合能力、MIMO层数、调制方式等。这个信息直接影响后续调度决策。网优排干扰时经常要看UE能力里的band组合比如n78n79双连接的场景终端如果不支持这个组合CA和载波聚合相关的速率指标就会异常。初始上下文建立完成后gNB回INITIAL CONTEXT SETUP RESPONSE这个响应里会带PDU会话建立的结果没建立成功的会话也会在失败列表里给出原因值。3.2 5G QoS架构QoS Flow参数、ARP与到DRB的映射规则5G QoS的核心概念从“承载”变成了“QoS Flow”。一个PDU会话里可以有多条QoS Flow每条Flow由核心网在PDU会话建立或修改时下发参数gNB再把QoS Flow映射到DRB上。对网优而言最关心的是三个参数参数含义网优关注点5QI标准化的QoS等级标识决定时延、丢包率和优先级VoNR语音通常用5QI1IMS信令用5QI5ARP分配与保留优先级值越小优先级越高抢占能力决定资源紧张时谁被踢GFBR/MFBR保证流比特率/最大流比特率GBR型业务语音、实时视频才有非GBR业务不配置GFBRGFBR和MFBR都区分上下行。现场排查“上行速率不达标”时先看SMF下发的QoS参数里有没有GFBR限制上行GFBR被卡住的情况比无线信道差更常见。ARP的作用在容量拥塞场景才体现出来语音和视频的ARP优先级通常比普通数据高资源不足时低优先级Flow先被释放。QoS Flow到DRB的映射是SDAP层完成的。映射规则不难理解优先一对一即一条QoS Flow映射到一条DRB多条Flow只要5QI相同、ARP相同、GBR类型一致就可以合到同一条DRB里。现场排查业务互抢速率的问题时重点看两条Flow是否被错误合并在同一个DRB下。比如一个PDU会话同时承载视频和普通上网流量如果两条Flow被映射到同一个DRBPSP包丢弃优先级差异就无法体现视频就可能和普通流量一起被降速。反射QoS是SDAP层的另一个特性UE根据下行数据包里的QoS Flow ID自动生成上行映射规则减少网络侧配置量但开反射QoS的场景里UE空闲后再激活必须重新获取映射关系否则上行数据走默认Flow容易丢QoS标记。3.3 PDU会话建立、修改与释放NGAP消息里的关键字段PDU会话的建立、修改、释放三条路径在信令分析里对应三类NGAP消息。先说建立。核心网AMF下发的NGAP PDU SESSION RESOURCE SETUP REQUEST里最核心的字段是这几个PDU Session ID、SNSSAI切片标识、PDU Session TypeIPv4/IPv6/Ethernet、QoS Flow Setup Request List每条Flow的5QI/ARP/GFBR/MFBR、以及UPF面的传输层信息上行GTP-U TEID和IP地址。gNB收到后要做准入判断小区带宽够不够、切片支不支持、QoS能力能不能满足。决定接受后gNB分配自己的下行GTP-U TEID通过RRCReconfiguration把DRB配置DRB ID、QoS Flow列表、PDCP/RLC参数下发给UEUE回RRCReconfigurationComplete后gNB通过PDU SESSION RESOURCE SETUP RESPONSE把上行TEID回给核心网。到这里用户面通路才算完全打通。修改过程用的是PDU SESSION RESOURCE MODIFY REQUEST/RESPONSE典型场景是语音业务发起时需要把一条默认的Non-GBR Flow升级为GBR Flow或者某个Flow的GFBR/MFBR需要重配。不建议在现网里高频触发QoS修改一旦MODIFY REQUEST里带的QoS参数和当前DRB能力冲突要重建DRB甚至重建PDU会话用户侧表现就是语音中断或数据面瞬断。释放过程相对简单核心网发Release CommandgNB释放DRB和上下文回Release Complete。网优侧更关心的是释放原因是UE主动发起比如用户挂机、还是核心网侧释放Tracking Area更新失败、会话超时、还是gNB侧异常释放空口失步、资源过载。看到异常释放时优先去NGAP响应里的Cause字段定位radioNetwork层的原因值基本都能直接对应到具体故障类型。4. 寻呼与切换5GC/RAN寻呼触发条件、Xn/N2切换与LNR重定向4.1 5GC寻呼与RAN寻呼触发条件、消息字段与相关参数寻呼是“被叫从无到有”的第一环。5G里寻呼分两种来源5GC寻呼核心网发起和RAN寻呼gNB发起。两者的适用状态完全不同区别如下维度5GC寻呼RAN寻呼UE状态CM_IDLE空闲态RRC_INACTIVE去激活态触发实体AMF收到UPF转发来的下行数据通知gNB收到下行数据或UE移动出当前gNB覆盖核心消息NGAP PAGINGRAN PAGINGUE标识5G-S-TMSII-RNTI寻呼范围注册范围内的TA listRAN Notification Area内的小区集合5GC寻呼消息里有三个字段要重点看ue-Identity-Index-Value决定UE在哪个寻呼帧醒过来、paging-DRX寻呼周期、TAI list寻呼范围。UE侧计算寻呼时机时用到的是5G-S-TMSI尾号加DRX周期寻呼帧SFN满足SFN加偏移量对T取模等于某个值的条件寻呼时机由UE_ID对N取模再除以Ns决定。T是DRX周期nB决定每个寻呼帧里放几个寻呼时机。调参时记住一个原则周期越大越省电但寻呼时延越长VoNR被叫接续时延实测可以从几十毫秒拉到一两秒。如果核心网PAGING里paging-DRX配置过大被叫用户会明显感觉到“响铃变慢”。RAN寻呼针对的是RRC_INACTIVE态UE。UE在gNB下发RRCReleasesuspend配置后进入去激活态但上下文还留在gNB里。当下行数据到达时gNB根据最后登记的RAN Notification Area范围向周边小区发RAN PAGING携带I-RNTI。网优排查Inactive态寻呼问题时最常踩的坑是RAN Notification Area配置过小UE移出范围后gNB还在原区域寻呼自然叫不醒最终超时后需要回退到核心网寻呼甚至触发UE发起RRC重建。4.2 Xn切换与N2切换流程差异与切换决策参数切换的源头是测量报告。UE检测到邻区满足事件条件后上报MRgNB做切换决策。5G里最重要的同频切换事件是A3邻区RSRP加offset加小区个体偏移CIO大于服务小区RSRP并且持续TTT时间才上报。offset、TTT、CIO三个参数在网优脚本里最常见offset控制触发难度TTT防抖动CIO用于“定向”抬高或压低某个小区被切出的概率。现网翻车最多的场景是把TTT调太小造成乒乓切换建议TTT不低于160ms。Xn切换是源gNB和目标gNB直接通过Xn接口交互的切换不走核心网。流程分三个阶段准备源gNB发Handover Request目标gNB做准入控制并回Ack、执行源gNB下RRCReconfiguration包含目标小区配置UE在目标小区做随机接入、完成目标gNB通知源gNB释放资源。要注意Handover Request里带的QoS Flow信息目标gNB准入判断的依据就是这些Flow的5QI和GFBR如果目标小区带宽不足准入会拒绝原因是radioNetwork层的“insufficient resources”。N2切换则是经AMF转发的跨gNB切换。当两个gNB之间没有Xn连接或者Xn链路故障时源gNB发Handover Required给AMFAMF选好目标后发Handover Request给目标gNB。N2切换多了核心网这一段时延比Xn切换大几十毫秒对VoNR这类时延敏感业务的体验影响更明显。站内切换则最简单同一个gNB内部不同小区间的切换不涉及Xn/N2信令只有内部上下文搬迁和RRC重配。4.3 LNR切换与LNR重定向跨系统互操作的两条路LNR切换和LNR重定向都是LTE与NR之间的互操作但实现路径完全不同。LNR切换是“带业务迁移”的切换源RAT和目标RAT之间先做好切换准备UE在目标RAT完成随机接入后业务才能恢复流程和Xn/N2切换类似只是跨了系统通常要经核心网转发。重定向则是“先释放再驻留”的方式源侧直接下RRCRelease消息里带redirectedCarrierInfo指明目标频点UE释放后自己在目标频点上重新做小区选择和驻留再发起业务。维度LNR切换LNR重定向目标小区准备有先建立目标RAT上下文无UE自己重新驻留时延较短业务连续性高较长业务会中断后恢复触发场景高速移动跨RAT覆盖、VoLTE切VoNR等负荷均衡、盲重定向、覆盖欠佳区域回落到4GUE实现目标小区随机接入上下文恢复目标RAT重新驻留重新注册现场排查LNR切换失败时有个惯用思路先看测量控制里有没有下发异系统测量配置再看B1/B2事件的门限值。门限设太高UE迟迟不报邻区NR信号切换拖到信号已经很差才触发失败率自然高。LNR重定向在5G建网初期用得更多主要场景是NR覆盖边缘快速把用户“倒”回LTE。重定向配置查两个地方RRCRelease里的redirectedCarrierInfo是否指向正确的目标频点、目标频点的邻区关系是否配置完整。这两个地方任何一个出错UE重选后都找不到合适小区用户直接脱网。5. 常见问题排查网优信令分析中绕不开的四类坑5.1 被叫寻呼丢失终端叫不醒现象主叫正常拨打被叫终端没有振铃核心网侧确认已经下发PAGING但空口抓不到RRC PAGING消息。现象 → 原因 → 解决。原因这类问题在现网里集中在三个方向。一是eDRX配置过大UE处于扩展DRX长周期监听gNB按普通DRX周期发寻呼终端正在“睡觉”没监听二是UE的PO/PF计算和gNB下发时机错位常见于T和nB参数在核心网和gNB两侧配置不一致三是UE处于RRC_INACTIVE态gNB在RAN Notification Area内做了RAN寻呼但UE已经移动到范围外的另一个小区gNB放的“网”没罩住它。解决先抓NGAP PAGING和空口RRC PAGING做时间对齐确认有没有下发、在哪个小区下发。然后核对核心网paging-DRX和gNB侧寻呼参数是否一致重点检查nB和T值。最后查RAN寻呼范围配置对移动性强的用户把RAN Notification Area扩大或者缩短RRC Inactive态超时回退到Idle的时间让核心网接管寻呼。5.2 SIB1解析失败能测到小区但驻留不上现象测试终端能读到SSB、能看到PCI和RSRP但一直做小区选择失败事件列表里反复出现“SIB1 acquisition failure”或“cell selection failed”日志。现象 → 原因 → 解决。原因最常见的元凶是MIB里pdcch-ConfigSIB1配置带出的CORESET0频域位置和带宽与gNB实际调度SIB1的PDCCH搜索空间不匹配UE按MIB指示去盲检PDCCH结果什么都解不出来。另一个常见原因是SIB1周期配置过长UE开机后首次读取时延大在弱场下容易反复失败还有就是CellBarred字段被置为barred小区被禁止接入但广播功率仍然正常测试软件看不出异常。解决先在网管侧核查SIB1的周期和pdcch-ConfigSIB1配置确认CORESET0的频域起始位置、带宽和SIB1的搜索空间周期匹配。同时检查小区的barred状态。在覆盖边缘区域建议把SIB1周期缩短比如从160ms改到80ms能明显减少终端首次接入时延代价是广播开销增加需要按小区容量权衡。5.3 PDU会话建立失败业务起不来现象UE发起PDU会话建立请求后NGAP侧的PDU SESSION RESOURCE SETUP RESPONSE里带上失败列表用户面上显示业务不可用但RRC连接是正常的。现象 → 原因 → 解决。原因从信令上看有几个高发原因。一是核心网下发的SNSSAI切片标识和gNB配置的切片列表对不上gNB在准入阶段直接拒绝二是QoS Flow参数里GFBR超出小区能力典型场景是视频类GBR业务在容量受限小区申请高保障速率被拒三是PDU Session Type不匹配比如核心网要求IPv4v6双栈但gNB或终端只支持单栈。解决先解析RESPONSE里失败列表的Cause值radioNetwork层原因值能直接区分是切片拒绝、资源不足还是协议错误。然后核对gNB的available SNSSAI列表和核心网签约数据是否一致切片数据不一致的改配置比扩容量快得多。GFBR超限的场景先看小区PRB利用率和带宽配置必要时在SMF侧收紧GFBR值比在gNB侧调准入策略更可控。5.4 切换失败或乒乓切换用户速率断崖现象终端在A、B两个小区交界处频繁上报A3切换次数暴增伴随切换失败次数上升用户下行速率在切换点掉到接近零。现象 → 原因 → 解决。原因乒乓切换大概率是offset或TTT设置太小UE很容易满足A3条件并很快上报切换失败则要先区分是准备阶段失败还是执行阶段失败。准备阶段失败常见于目标小区邻区漏配、PCI混淆、或者目标小区接纳准入拒绝执行阶段失败常见于目标小区的随机接入资源配置不足、切换命令下发过晚导致UE到达目标小区时信号已经太弱。解决先看MR统计里A3上报频次和切换请求次数A3上报多但切换准备失败率高问题出在邻区配置和PCIA3上报正常但执行失败率高问题出在目标小区随机接入资源和切换门限。调参建议是offset在0.5到2dB之间、TTT保持160ms以上、CIO按单小区方向调整而不是全局改避免“为了修一个小区拖垮整条链”。6. 信令分析实战技巧从端到端消息到问题定界的收敛方法6.1 四层信令联动分析把RRC、NAS、NGAP、QoS Flow串起来看单看一张信令流程很难定界我在现场的习惯是“三层联动”RRC层看空口交互NAS层看终端和核心网之间的业务状态NGAP层看gNB和核心网之间的资源协商。比如用户报“能打电话但上不了网”先看NGAP有没有PDU Session Resource Setup请求没有就是核心网没发起有请求但Response里失败就看Cause值Response成功但速率不达标再转去查QoS Flow到DRB的映射关系。按这个顺序走大多数问题能控制在一刻钟内定界。用Wireshark抓NGAP消息时过滤条件和后面的分析步骤配合效率更高# 第一步把pcap里的NGAP消息全部导出只看消息类型和关键字段 tshark -r 5g_信令.pcap -Y ngap -T fields \ -e frame.number -e ngap.procedureCode -e ngap.pduSessionID \ -e ngap.SNSSAI_SST -e ngap.qosFlowIdentifier ngap_summary.txt # 第二步在导出结果里定位PDU会话建立相关的帧号 grep -E PDUSessionResourceSetup ngap_summary.txt | head -50第一条命令用-Y过滤出所有NGAP消息再用-T fields把procedureCode、PDU Session ID、切片SST、QoS Flow ID一次性输出。第二条命令把终端的PDU会话建立请求和响应帧号定位出来再回到原始pcap里逐条展开字段。我一般会把grep结果前50行过一遍先看有没有“PDUSessionResourceSetupResponse”落地的帧没有Response基本就是核心网侧没响应省去空口排查。6.2 信令问题定界的“三段式”思路与参数核对清单我处理信令类工单的固定动作是问三个问题信令有没有发起网络侧有没有响应空口侧有没有执行业务信令没发起查终端状态和NAS层网络侧没响应查核心网的Cause值和切片签约空口侧没执行查RRC重配和随机接入。这套“三段式”看起来简单但它逼着人先看有没有、再查为什么而不是拿到一包信令就从第一条消息开始往下啃。参数核对阶段常备一个小清单寻呼类看paging-DRX、nB、T、eDRX周期随机接入类看prach-ConfigurationIndex、powerRampingStep、preambleReceivedTargetPower系统消息看SIB1周期和pdcch-ConfigSIB1QoS类看5QI、ARP、GFBR、MFBR和SDAP映射关系切换类看offset、TTT、CIO和B1/B2门限。这张清单我贴在手边排查时逐项勾选比临时翻协议快得多。那次之后我给自己定了个死规矩不管用户报的问题听起来多像空口覆盖拿到抓包先按“信令发起—网络响应—空口执行”三段走一遍跳步排查翻过好几次车后来再也没跳过。这份《5G信令分析指导书》我放在下载区了里面从开机入网到NAS全流程都有关键消息的字段也做了标注配合Wireshark的NGAP/RRC过滤器一起用排查效率会有一个很明显的提升。希望帮到你。本文还有配套的精品资源点击获取

5G SA信令分析全流程实战：从开机入网到切换完成

相关推荐

基于《人工智能简述》课件：PPT结构提取与二次开发实战

Claude 写了 90% 的 Claude Code：Anthropic 公开评审流水线，人类只做『最后防线』

计算机网络综合实验方案：VLAN、OSPF、NAT与抓包分析全链路

更多资讯

从参数化建模到七彩渐变：3D打印鹦鹉螺魔方制作实战指南

时间序列预测实战：Excel、Matlab、SPSS三工具对比与避坑指南

SpringBoot整合JTA+Atomikos实现跨库分布式事务实战

C语言数据结构底层原理：内存布局、指针语义与算法安全实现

ABB机器人上位机开发实战：从通信方案到C#代码与现场排障

废掉一个前端最快的方式：让他只会手动写UI！用TaoToken统一Key接入Gemini 3 Pro实现UI自由

今日更新

金融AI落地指南：从调研报告到技术选型与工程实践

大模型上下文成本与注意力优化技术深度解析——为何O(n²)平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测

基于GMM的语音识别系统原理与MATLAB实现详解

本周精选

金融AI落地指南：从调研报告到技术选型与工程实践

大模型上下文成本与注意力优化技术深度解析——为何O(n²)平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测

基于GMM的语音识别系统原理与MATLAB实现详解

本月热门

我发现了一个新思路：用 Remotion + Claude Code 像写代码一样自动化生成短视频

Windows下 Codex 中 Chrome 和 Computer Use 插件不可用问题排查及解决参考方式：TaoToken 统一 Key 配置与验证

2026 大模型集体涨价：用 Python 做企业 Token 成本测算与选型避坑（附配置）

读完文章，想聊聊您的网站？