企业官网建设流程全解析

简介：面向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开机后要做的第一件事不是读系统消息，而是先把小区“找出来”。指导书里把小区搜索拆成五个步骤，这五步的顺序不能乱：

1. 按同步栅格搜频点，频点编号走的是GSCN规则，而不是普通信道栅格，目的就是减少搜索候选位置；
2. 尝试检测PSS/SSS，取得下行时钟同步并获取PCI，如果失败就转到下一个频点继续搜；
3. 读取MIB，拿到SSB波束信息、系统帧号和SIB1的时频域位置；
4. 读取SIB1，拿到上行初始BWP、公共信道配置、TDD半静态配比以及OSI搜索空间；
5. 读取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（也叫RMSI）；OSI是其他系统消息，从SIB2一直排到SIBn。两者的下发方式和承载内容差别很大，整理如下：

UE什么时候读系统消息，指导书里写得很清楚：开机选网、小区重选、切换完成、从其他RAT进入NR、从无覆盖区回到覆盖区，这五种场景都会主动拉取。但拿到一次之后不会反复读，只有三种情况会重新读：收到寻呼指示系统消息变化、收到寻呼指示有ETWS/CMAS广播、距离上次正确接收满3小时。3小时这个数字来自协议里的SIB有效期规则，我在实际排查里确实遇到过终端长时间不刷新系统消息导致重选异常的问题，时间点就和这个有效期高度相关。

ODOSI是这段内容里最有实操价值的部分。OSI里的SIB并不全是周期广播，gNB可以配置成“订阅广播”：UE先在SIB1里读si-SchedulingInfo，看到某个SI消息的广播状态是“not broadcast”，就发起订阅请求。订阅有两条路：Msg1方式和Msg3方式。Msg1方式是UE发一个专用的随机接入前导码来请求SI；Msg3方式是在RRCSetupRequest消息里带上si-Request信息。现网配置里如果某个SIB是非周期广播，而UE还按老思路死等，就会出现“邻区信息拿不全但手机不自知”的情况，这类问题在高铁重选场景里最容易翻车。

2.3 随机接入：基于竞争与非竞争的RA流程与关键参数

随机接入是UE从“下行同步”跨到“上行同步”的关键一步。指导书把RA分成两大类：基于竞争的随机接入和基于非竞争的随机接入。流程差异很直观：

基于竞争的RA里，Msg3和Msg4是关键。Msg3承载RRCSetupRequest或RRCResumeRequest，Msg4用于竞争解决，UE只有收到Msg4且冲突解决成功，才算真正完成随机接入。参数层面要注意prach-ConfigurationIndex（决定前导格式和时域位置）、msg1-FDM（频域复用因子，可配1/2/4/8）、preambleReceivedTargetPower（初始目标接收功率，常见配置为-104dBm附近）、powerRampingStep（每次失败后的功率爬升步长，现网多用2dB或4dB）。如果终端反复在Msg1上失败且没有功率爬升迹象，优先怀疑prach时频资源配置冲突，而不是无脑加功率。

2.4 RRC连接建立与注册：从RRCSetupRequest到注册完成的完整路径

RRC建立过程是UE入网的最后一道空口工序。正常路径是UE发RRCSetupRequest，gNB回RRCSetup建立SRB1，UE再回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后启动T300，T300超时还没收到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 UECapabilityEnquiry，UE回RRC UECapabilityInformation，里面包含支持的频段组合、载波聚合能力、MIMO层数、调制方式等。这个信息直接影响后续调度决策。网优排干扰时经常要看UE能力里的band组合，比如n78+n79双连接的场景，终端如果不支持这个组合，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上。对网优而言，最关心的是三个参数：

GFBR和MFBR都区分上下行。现场排查“上行速率不达标”时，先看SMF下发的QoS参数里有没有GFBR限制，上行GFBR被卡住的情况比无线信道差更常见。ARP的作用在容量拥塞场景才体现出来：语音和视频的ARP优先级通常比普通数据高，资源不足时低优先级Flow先被释放。

QoS Flow到DRB的映射是SDAP层完成的。映射规则不难理解：优先一对一，即一条QoS Flow映射到一条DRB；多条Flow只要5QI相同、ARP相同、GBR类型一致，就可以合到同一条DRB里。现场排查业务互抢速率的问题时，重点看两条Flow是否被错误合并在同一个DRB下。比如一个PDU会话同时承载视频和普通上网流量，如果两条Flow被映射到同一个DRB，PSP（包丢弃优先级）差异就无法体现，视频就可能和普通流量一起被降速。反射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 Type（IPv4/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参数）下发给UE，UE回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 Command，gNB释放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寻呼消息里有三个字段要重点看：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下发RRCRelease（suspend配置）后进入去激活态，但上下文还留在gNB里。当下行数据到达时，gNB根据最后登记的RAN Notification Area范围，向周边小区发RAN PAGING，携带I-RNTI。网优排查Inactive态寻呼问题时，最常踩的坑是RAN Notification Area配置过小，UE移出范围后gNB还在原区域寻呼，自然叫不醒，最终超时后需要回退到核心网寻呼甚至触发UE发起RRC重建。

4.2 Xn切换与N2切换：流程差异与切换决策参数

切换的源头是测量报告。UE检测到邻区满足事件条件后上报MR，gNB做切换决策。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给AMF，AMF选好目标后发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切换失败时有个惯用思路：先看测量控制里有没有下发异系统测量配置，再看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上报多但切换准备失败率高，问题出在邻区配置和PCI；A3上报正常但执行失败率高，问题出在目标小区随机接入资源和切换门限。调参建议是：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-ConfigSIB1；QoS类看5QI、ARP、GFBR、MFBR和SDAP映射关系；切换类看offset、TTT、CIO和B1/B2门限。这张清单我贴在手边，排查时逐项勾选，比临时翻协议快得多。

那次之后我给自己定了个死规矩：不管用户报的问题听起来多像空口覆盖，拿到抓包先按“信令发起—网络响应—空口执行”三段走一遍，跳步排查翻过好几次车，后来再也没跳过。这份《5G信令分析指导书》我放在下载区了，里面从开机入网到NAS全流程都有，关键消息的字段也做了标注，配合Wireshark的NGAP/RRC过滤器一起用，排查效率会有一个很明显的提升。希望帮到你。

本文还有配套的精品资源，点击获取