企业官网建设流程全解析

简介：面向5G网络工程师、通信协议开发与测试人员的《5G基础信令基础讲解》PPT课件，系统梳理了5G相对4G的新特性与无线网络架构，重点解析控制面的UE状态、RRC连接建立/重配/重建/恢复/释放/RLF、统一接入控制、系统信息、寻呼、移动性管理、SUL及EN-DC双连接；用户面部分则详细讲解整体流程、新QoS机制、PDCP split与duplication、精简RLC，以及SRB到CCCH/DCCH信道的承载映射。课件还对比了4G/5G高层协议规范框架，覆盖36系列与38系列主要协议号，便于读者按协议栈对照学习，并总结了On-demand SI、Inactive态、BWP、RNAU、Flow vs Bearer、波束管理等5G关键技术特性。资源共1个PPTX文件，大小约3.65MB，已有400人学习，适合作为5G信令流程的系统入门与工作复习参考。

1. 5G基础信令为什么值得专门讲一讲

一个新开的5G基站，现场指标什么都好，RRC建立成功率99.5%，可用户一打电话就断，核心网侧没收到任何异常告警。两边工程师坐在一起看数据，一个说终端没发起注册，另一个说网络没下发响应。这种扯皮我见过太多次，最后打开信令抓包，一句话都不用吵——谁的消息没到，到没到哪一步，一清二楚。

5G基础信令，说白了就是把UE和网络之间那些看不见的“对话”翻译成可读的流程。你不需要把3GPP规范背下来，但你需要知道一条注册流程要过几道门、每个环节等多久、失败时看哪个定时器。这份课件式的讲解，就是用来带新人、做实训室方案、或者在排查现场把责任边界划清楚的。

它适合三类人：刚转岗5G的网优和基站工程师，需要快速建立信令主线的培训讲师，以及做5G实训室方案、要把信令教学落地的技术负责人。

2. 5G协议栈详解：三层信令接口的职责与嵌套

2.1 协议栈结构：RRC、NAS、NgAP各自站在哪

先画一张控制面的地图。UE和gNB之间走的是RRC协议，UE和AMF之间走的则是NAS协议，gNB和AMF之间走的是NgAP。三层接口，两段链路，这是解读所有信令流程的地基。

很多新手看信令流程喜欢先记消息名：RRC Setup Request、Initial UE Message、Registration Accept，背得挺熟，但不知道它们之间谁嵌套谁。这个顺序一乱，后面看什么都是云里雾里。我一般建议先把“消息在哪条接口上、由谁封装、送给谁”搞清楚，再去看具体内容。

NAS层又分成两个子块：MM负责移动性管理，管注册、鉴权、位置更新；SM负责会话管理，管PDU会话的建立、修改、释放。RRC层负责空口上的资源管理和NAS消息搬运，gNB侧再把NAS消息装入NgAP的Initial UE Message送到AMF。反过来，核心网下发的NAS消息通过Downlink NAS Transport到gNB，再由RRC封装发给UE。这个“乘客-车厢”关系，比任何一条具体消息都重要。

2.2 5G协议栈详解：三层接口的信令任务与承载关系

RRC作为空口信令的老大，负责连接的建立、重配、释放，还要管测量配置、安全模式激活和切换命令。最常看到的几条：RRC Setup Request、RRC Setup、RRC Reconfiguration、RRC Release、Measurement Report。它们全部跑在SRB上，SRB0传RRC建立消息，SRB1建好后传后续RRC和NAS，SRB2专门承载高优先级的NAS消息，比如非紧急的NAS信令。

NAS走的是逻辑通道，不直接暴露在空口，而是被RRC当成负载扛过空口。典型消息包括Registration Request、Authentication Request、Identity Request、PDU Session Establishment Request。这些消息到了gNB，RRC层根本不理业务内容，只负责原封不动打包成NgAP消息继续往上送。

NgAP位于gNB和AMF之间的SCTP连接上，标准端口号通常用38412。它做的事情更偏“管理”：NG Setup完成站点注册，Initial Context Setup把用户上下文从核心网下发到基站，PDU Session Resource Setup为会话分配资源，Handover相关流程负责移动性的网络侧准备。

三个接口有清晰的职责边界：RRC管无线侧的状态和资源，NAS管移动性与会话业务逻辑，NgAP管核心网与基站的协作。这样拆分之后，看流程图就不会再纠结消息该出现在哪一层。

2.3 信令超时参数：先认识这几个数字

信令流程能跑通，一半靠消息正确，另一半靠定时器别乱跳。定时器就是每条流程的“等待时长”，超时之前没等到预期响应，就直接判定失败。

终端侧的定时器里，T300等RRC Setup响应，T304等切换完成响应，T310判断无线链路是否彻底失步。NAS层T3510等Registration Accept，T3512控制周期性注册更新，T3520等Service Accept。网络侧也有对应定时器，gNB侧T300反向等待UE的RRC Setup Complete，AMF侧则跟踪整条注册流程的处理超时。做排查时，谁先超时，问题边界基本就在谁身上。

这些参数在商用设备里基本都可配，常见值T300从100ms到2000ms不等，T3510是15秒左右，T3512默认300秒以上。讲解信令时，把这些数字放进流程图对应位置，比单独列一页参数表好懂得多。

3. 三大流程拆解：注册、会话建立与切换的信令时序

3.1 注册流程：从RRC Setup到Registration Accept的一整条链路

注册流程是理解5G信令的“hello world”。终端开机后先做小区搜索，然后随机接入，接着发起RRC连接建立。RRC Setup Request里携带的是初始UE身份，如果终端之前注册过，带的是5G-GUTI，否则会用SUCI。gNB回复RRC Setup，给终端分配SRB1，UE回RRC Setup Complete，这一步开始，NAS消息就上车了。

RRC Setup Complete里封装着第一条NAS消息Registration Request。gNB收到后不做业务解析，直接把它封装进NgAP的Initial UE Message发给AMF。到了AMF，才真正开始核心网侧的处理：如果带了GUTI就直接识别用户，如果没有就先触发身份请求，走鉴权流程，然后下Security Mode Command激活NAS和AS安全。空口侧的安全由RRC Reconfiguration完成，其中带上安全配置参数。

AMF回Registration Accept时，路径是反的：NgAP Downlink NAS Transport到gNB，gNB把它放进RRC UL Information Transfer的下行版本发给UE。UE回Registration Complete，整条注册流程闭环。从头到尾，消息跨了三条接口，但真正的业务逻辑只在NAS层发生，RRC和NgAP都只是搬运工。

3.2 PDU会话建立流程：用户面打通前发生了什么

注册成功后，用户要上网，还需要建立PDU会话。终端发起NAS的PDU Session Establishment Request，里面带上PDU会话ID、S-NSSAI、DNN、请求的QoS类别。AMF收到后会先和SMF确认切片和会话策略，用户面网关准备好之后再通过AMF下发PDU Session Resource Setup Request给gNB，消息里包含核心网分配的用户面隧道信息、QoS Flow和对应的承载参数。

gNB这时候要干一件关键事：把核心网的会话参数翻译成空口配置，通过RRC Reconfiguration下发给UE。里面会带DRB的建立配置，比如DRB标识、QoS映射关系、PDCP配置、RLC模式，以及MAC和物理层相关参数。UE收到后配置好底层协议栈，回RRC Reconfiguration Complete。gNB确认空口承载建立成功，再给核心网回PDU Session Resource Setup Response，带出gNB侧的用户面隧道信息。

这条流程里最容易出问题的字段都在RRC Reconfiguration里：QoS Flow到DRB的映射如果没下发，终端就不知道哪个业务走哪条承载；DRB的RLC模式如果配错，高清视频可能会断断续续。信令讲解到这里时，要跟峰值速率的计算结合起来看——PDCP层吞吐、MAC调度周期、MCS等级这些参数最终决定了用户面能跑多快，这也是5G信令和4G信令在讲解深度上一个明显的分水岭。

3.3 切换流程：A3事件测量与T304的配合

移动性管理是5G基础信令里看起来简单、实际最容易翻车的一块。首先是测量阶段，gNB通过RRC Reconfiguration下发测量配置，里面包含测量对象、上报周期、事件阈值，最常用的是A3事件。A3事件的进入条件可以写成这个形式：邻区RSRP加上偏置，高于当前服务小区RSRP再加上迟滞。小区偏置和迟滞这两个参数直接决定切换的灵敏程度，调小了频繁切换，调大了容易掉话。

UE上报Measurement Report之后，源gNB判断需要切换，会通过NgAP发起切换准备，目标gNB做准入控制并准备好资源，返回切换命令相关信息。源gNB把这些封装成RRC Reconfiguration下发给UE，这条消息里带上目标小区的同步配置，UE在目标小区发起随机接入，成功之后上报RRC Reconfiguration Complete，目标gNB再通过NgAP通知核心网切换路径，把用户面从源侧改到目标侧。

整个过程中T304是核心的兜底定时器。UE从收到切换命令开始计时，如果在T304内没完成目标小区接入，就会判定切换失败，进入RRC重建，用户业务中断。排查切换问题时，先看Measurement Report有没有上报，再测目标小区的PRACH配置和随机接入前导，最后看T304是否超时，这几步能筛掉80%的切换问题。

4. 用5G信令定位问题：抓包入口、过滤语法与排查逻辑

4.1 抓包前的准备：日志入口在UE、DU/CU、AMF哪里找

信令排查第一步不是打开Wireshark，而是先知道日志从哪里导。商用基站的硬件通常按AAU、DU、CU三级部署，信令跟踪入口也分散在这几个层级：AAU侧一般只有射频指标和告警，信令细节很少；DU侧能看到调度、RLC、MAC和部分RRC日志；CU侧才有完整的RRC和NgAP。也就是说，你要查空口建链问题，DU日志优先；要查核心网交互问题，CU的NgAP日志才是关键。如果用的是开源研究环境，比如OpenAirInterface这类5G实现，日志输出会更透明，也能看到每条NAS消息的原始内容。终端侧的抓包通常用商用测试工具导出空口日志，里面能同时看到RRC和NAS消息，是确认“终端到底发了什么”的最直接证据。

工程人员最容易犯的错是只抓一端。UE侧报了注册失败，就去抓空口；基站侧说是核心网问题，就去抓CU日志。实际上注册流程跨了UE、gNB、AMF三段，至少需要空口日志和NgAP日志配合着看，才能锁定丢消息的位置。

4.2 Wireshark过滤5G信令的常用语法

拿到日志并转成pcap后，Wireshark的过滤语法值得记几条。下面这组是实战里最常用的：

# 只抓NgAP消息，38412是最常用的SCTP端口 sctp.port == 38412 || tcp.port == 38412 # 只看5G NAS层消息（新版本Wireshark的协议名） nas-5gs # 只看RRC空口信令 rrc # 在NgAP消息里过滤带NAS负载的帧 ngap.NAS-PDU

逻辑说明：NgAP跑在SCTP之上，所以先按端口抓协议；NAS消息被封装在RRC和NgAP里面，直接过滤协议名只能看到独立解析的NAS帧，想要看它被哪个RRC或NgAP消息携带，就得用承载协议字段去定位。最后一行的ngap.NAS-PDU，就是把gNB和AMF之间传递的NAS消息单独挑出来，配合上下行方向信息，能快速看清核心网回给终端的到底是Accept还是Reject。

参数说明：端口过滤适合核心网侧抓包；nas-5gs是较新版本Wireshark的协议名，旧版本可能叫NAS，实际用的时候以协议解析窗口里显示的名为准。现场如果发现NAS过滤不出来，先确认pcap里协议解析器有没有加载5G相关配置。

4.3 排查实操：按“NAS失败还是RAN失败”定边界

实战排查我习惯先做“边界划分”：看失败消息出现在哪条链路上。如果RRC Setup都完成了，但NAS的Registration Reject直接下发，问题大概率在核心网侧；如果RRC建立过程本身就超时中断，问题大概率在空口或基站。

用注册失败举例。先抓CU侧NgAP日志，看到Initial UE Message有没有正常送到AMF；如果送了，再看Downlink NAS Transport里带的是Accept还是Reject；如果是Reject，看cause code，网络侧拒绝和终端侧拒绝的原因值含义完全不同。如果下行NAS消息迟迟不来，这时候回到UE侧看T3510是否超时，T3510超时意味着AMF没在时间内给响应，可能是AMF过载、切片不匹配或者安全流程没走完。

PDU会话失败也走同样的逻辑：PDU Session Resource Setup Request如果没到gNB，是核心网和切片协商的问题；到了gNB但RRC Reconfiguration没完成，就是空口承载建立问题。先划边界，再看具体字段，这是信令排查的固定动作。

5. 讲清基础信令最容易踩的五个坑

5.1 把无线链路失败和切换失败混为一谈

现象：一个问题用户上报“切换失败”，排查时直接把T304和A3事件翻来覆去调，但实际问题出在源小区无线链路质量太差，UE早就触发T310进入无线链路失败流程，连测量报告都没来得及发。原因：两类失败在现象上接近，终端都会出现短暂的业务中断，但信令触发点完全不同。解决：先看Measurement Report有没有上报。有上报再查切换参数；没有上报，重点看T310和物理层失步告警，这两个方向差得很远。

5.2 只看NAS消息，不看RRC上下文

现象：抓空口日志看到Registration Reject，直接下结论“核心网拒发”。原因：NAS Reject虽然是核心网发的，但触发原因可能是RRC安全模式配置没有完成。AMF下发了安全参数，UE侧AS层没生效，核心网判定终端不具备接入条件，才会回Reject。解决：看Reject之前有没有完整的RRC Reconfiguration完成消息，安全上下文有没有建立。信令流程是一环扣一环的，跳过中间环节直接看结果，很容易误判。

5.3 参数记串：T3510和T3520不分

现象：排查终端无法驻网问题，看到终端发了Registration Request就盯着T3510，等不到超时却发生在新流程重发。原因：两个定时器名字太像，T3520管Service Request流程，和注册流程完全不是一回事。解决：做速查表时按流程分组而不是按数字排列。注册流程组里放T3510、T3502；服务请求组里放T3520；RRC组里放T300、T304、T310。分组记忆之后，现场查参数基本不会再错。

5.4 课件里消息方向画反

现象：PPT里把RRC Setup画成UE发给gNB，把Registration Accept画成gNB直接发给UE。原因：画流程图时按“谁先发起就谁先出”的习惯走，忽略了接口封装关系。解决：每一条信令消息都要按“接口-方向-承载消息”三个维度核对。比如Registration Accept一定是AMF经NgAP下发给gNB，再由gNB通过RRC下发给UE，中间有两个方向的转换，画成一条线直接连到UE就是错的。这类小问题在现场技术评审时最容易暴露。

5.5 过度依赖信令抓包，忽略物理层底噪

现象：信令流程全都正常，核心网也回了Accept，用户就是上不了网。原因：信令只证明了控制面通了，用户面吞吐还受制于射频底噪、MCS调度和天线通道状态。信令分析不是万能的，遇到控制面全绿但速率上不去的情况，要从物理层指标入手，检查信道质量、下行MCS分布和AAU告警。信令负责画清楚链路，射频负责解释速率，两者缺一不可。

6. 一个进阶习惯：先画时序图，再记参数

讲5G基础信令，或者自学5G基础信令，最值钱的一个习惯是：先把每个流程的时序图画到能默写，再往图上填参数。具体做法是准备两张纸，第一张纸上只画消息名和接口方向，UE在左，gNB在中间，AMF在右，把注册流程从头到尾用箭头串起来。不看任何资料，能一次画对RRC Setup Request、RRC Setup Complete、Initial UE Message、Registration Accept的先后顺序，再进入第二张纸：在每个箭头旁边标定时器，RRC Setup旁边标T300，切换命令旁边标T304，注册请求旁边标T3510。

这个习惯厉害在哪？它逼你把信令从“消息列表”变成“链路关系”。很多人在现场查了半小时日志，都没意识到消息根本没到gNB，就是因为脑子里没有这张时序图。我自己带新人，第一周不让他们碰任何告警和统计，只要求把注册、PDU会话建立、切换三条时序图默写一遍，写完再给真实抓包。这个方法是血泪换来的——当年排查一个VoNR呼叫失败，我盯着NAS重传看了眼花，最后是同事看了一眼时序图，说“消息压根没到AMF”，一验证果然如此。从那以后，我经手的每一个信令课件的开头都是时序图，不是参数表。

你做完这份5G基础信令讲解材料后，不妨把最后三页改成：一页注册时序图、一页PDU会话时序图、一页切换时序图，再附一张定时器速查表。用的时候先看图，再对参数，效率和正确率都会明显好于逐条记消息。希望帮到你。

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