企业官网建设流程全解析

做通信外场的兄弟应该都有过这种经历：现场报障说终端不上网、掉线频繁，你第一件事绝对不是去翻SINR和RSRP，而是先把空口信令拉出来，从RRC这一层往下一层层捋。RRC（Radio Resource Control，无线资源控制）在5G协议栈里是UE和基站之间最高层的控制信令，所有业务能不能建立、切换顺不顺、掉线怎么定位，入口都在这一层。无论你是刚转行做协议开发的，还是天天跑外场做优化测试的，RRC都是一门绕不过去的必修课——你不把它啃明白，后面看NAS、看QoS、看切换策略，基本都是空中楼阁。

我印象最深的一次地市外场保障，终端一直注册不上去，空口信令里只见RRCSetupRequest一遍一遍重发。我当时就判断，问题大概率不在核心网配置，而是接入链路某个环节卡住了。顺着这个方向，把终端log、基站侧日志和后台计数器逐级对比，最后定位到是上行覆盖边缘导致MSG3在没有被正确解调，网络根本不知道终端在发起接入。案子本身不算复杂，但把RRC在真实网络里的角色暴露得很彻底：你既要懂信令流程本身怎么走，也要知道底层随机接入、物理资源对它的影响，还得会看各种参数和定时器。这篇我就以RRC为主线，把状态机、接入流程、参数体系和排障思路一次讲透，正在为RRC信令发愁的朋友应该能省不少翻规范的时间。

1. 接入失败现场：一张RRC信令表把问题暴露得明明白白

1.1 那次只看到重发的RRCSetupRequest

先还原一下当时的排查过程。当时做的是某运营商覆盖边缘区域的定点验证，终端显示信号强度不差，但应用层一直上不了网。把信令拉出来一看，反复出现的只有一条消息：RRCSetupRequest。它的发送间隔基本是固定的，发了几轮之后要么继续重发，要么干脆回到IDLE态重新开始。

这个现象很有代表性。RRCSetupRequest是终端主动发起连接建立的“敲门声”，网络没回应时终端不会凭空收到任何后续指令，唯一能做的就是按介质访问控制层的随机接入流程重试。这时候要区分两种可能：一是这条消息在物理层就没送出去，二是基站收到了但解调失败，又或者解调出来但核心网那边不认这个身份。后面我会专门讲怎么分层排查，但当时我立刻做的一件事是把终端的log对准gNB侧物理层日志的时间戳，看每个PRACH前导码对应位置有没有检测能量。结果很清晰：终端发了很多次前导，但基站在对应资源配置上几乎没有检测到有效能量，属于典型的上行越区覆盖和弱覆盖叠加问题，调波束方向后RRCSetupRequest就不再重发了，流程马上走了下去。

这次经历给我的感受是，RRC这张信令表是所有问题最直观的“温度计”。流程走到哪一条消息、卡在哪一段，往往比看几十个KPI更先告诉你病灶在哪。

1.2 RRC在协议栈里的真实分量

很多刚从LTE转过来的人对RRC的理解停留在“就是发几条信令的事情”，其实远不止。RRC在5G空口协议栈里属于层三，往上对接NAS（非接入层）消息，往下控制RLC、MAC和PHY的资源行为。

打个比方，RRC有点像大楼前台的接待处：住客（UE）要进哪个房间（业务），不是自己直接拿钥匙闯进去，而是先到前台登记，前台确认身份后替你联系对应楼层，再把房卡（无线资源配置）发给你。NAS消息是住客随身带的证件，RRC负责验证和递交证件；而房间里的家具怎么摆（PHY参数怎么配）、走到哪个走廊（切换路径）也都是前台在指挥。所以RRC不光管“建立和释放连接”，它同时承担了系统信息广播、寻呼、连接态移动性、UE能力管理、测量控制、NAS消息转发、灾备恢复这些职能。

5G NR相对LTE变化更大的一点是RRC因为引入了新状态、新流程和更复杂的配置模型，导致你只看协议文档很容易看晕。但理解了它“整合控制面”的角色之后再回到具体流程，就会清晰很多。

1.3 接下来你会看到什么

我下面分成四块讲：状态机、空口建立流程、参数配置、排障套路。状态机告诉你RRC在什么时候处于什么境地；空口流程告诉你一次接入到底踩了哪些台阶；参数配置告诉你网络怎么通过SIB和专用配置“设定规则”；排障套路则是结合实战告诉你：信令卡住时，先翻哪个表、对比哪类日志、大概率是什么原因。

对于完全没基础的朋友，我建议顺序阅读；已经有一定经验的，可以直接跳到第4、5章，里面很多排查细节是我踩坑踩出来的。

2. RRC状态机：从4G到5G，多出来的RRC_INACTIVE是怎么工作的

2.1 IDLE、INACTIVE、CONNECTED，三态分别管什么

RRC状态机是整个RRC体系的地基。5G NR定义了三个RRC状态：RRC_IDLE、RRC_INACTIVE和RRC_CONNECTED。

RRC_IDLE状态下，终端和网络之间没有专用无线资源，也没有RRC连接。终端自己做PLMN选择、小区选择重选，按网络广播的寻呼周期醒来听Paging。这种状态功耗最低，但代价是每次要从零开始建立连接，信令开销最大。

RRC_CONNECTED状态下，终端和gNB之间建立了完整的RRC连接，有SRB和DRB，网络可以下发专用配置，做测量、切换、载波聚合。这个状态下终端的移动性完全由网络控制，业务体验最好，但终端功耗和空口信令开销也最高。

RRC_INACTIVE是5G新增的中间态。它和IDLE的相似之处是：UE在空中接口上处于“暂停”状态，没有活跃的SRB/DRB，按配置的寻呼周期监听网络寻呼，可以做小区重选。但和IDLE的本质区别是：gNB和核心网之间仍然保留UE的上下文，UE侧也保存一份配置的快照，一旦有上行数据需要发送，可以直接发送RRCResumeRequest进行快速恢复，而不用像IDLE那样重新走一套完整的初始接入和NAS流程。

拿睡眠来对比可能更好记：IDLE是晚上睡死过去，第二天起床要洗脸刷牙才能出门；INACTIVE是中午趴在工位上眯二十分钟，桌上东西都没收，手机订好闹钟，醒来直接干活。

2.2 为什么5G非要加一个INACTIVE

这个问题在面试里被问过很多次，其实答案就是三个词：省电、省信令、省时延。

5G网络面向大量物联网和手机后台业务，很多应用只是每几十秒传一个心跳包或状态更新。如果每次这种小流量都从IDLE重新建立RRC连接，每次都要经历随机接入、RRCSetup、NAS鉴权/加密、DRB建立这一整套流程，对空口资源和终端电池都是巨大浪费。RRC_INACTIVE直接复用gNB里保留的UE上下文，恢复流程只需要一次RRCResumeRequest和RRCResume就能回到CONNECTED，省掉了NAS层重新鉴权的往返时间。实测中恢复时延通常明显低于完整重建流程，并且终端功耗也远低于一直保持连接。

所以从设计动机上，INACTIVE是对“连接始终保持”和“完全释放”两种极端策略的折中。现实中不少网络KPI对信令负荷很敏感，INACTIVE引入之后，大量小流量业务被约束在“睡一会、醒一下”的节奏里，对整网稳定性很有帮助。

2.3 状态切换路径与关键定时器

三种状态之间的切换不是随便跳的，每条路径都有对应的RRC过程：

• IDLE到CONNECTED，走RRCSetup过程。终端发送RRCSetupRequest，网络回RRCSetup，终端回RRCSetupComplete。
• CONNECTED到IDLE，走RRCRelease过程，网络下发RRCRelease，不带suspendConfig，直接释放全部上下文。
• CONNECTED到INACTIVE，同样是RRCRelease，但消息里带了suspendConfig参数，UE侧保留配置并配置I-RNTI，进行Paging监听。
• INACTIVE到CONNECTED，走RRCResume过程。UE发送RRCResumeRequest，网络回RRCResume或者RRCSetup。
• INACTIVE回IDLE，可能因为网络侧上下文释放、RRCRelease、寻呼失效等原因触发。

这些状态切换背后还有一批定时器在把关：T300限制“发起RRC建立后最长等多久”，T319限制“发起RRC恢复后最长等多久”，T310负责物理层失步后的监测窗口，T311是重建过程中的小区选择等待时间。它们的作用我在第4章的表里统一说。

3. 从RRCSetupRequest到RRCSetupComplete，空口上到底走了哪些消息

3.1 入口第一棒：Paging把终端叫醒

终端从IDLE态接入，有时候是UE主动要发数据，比如你打开一个App；有时候是被动被叫，比如来一通电话或一条推送。被叫场景的第一步是网络侧通过Paging消息把UE叫醒。

Paging是RRC层在寻呼信道上广播的消息，基站不需要知道UE具体在哪个物理位置，只要知道UE所在的寻呼登记区。UE根据自己UE_ID算出寻呼时机（PO）和寻呼帧（PF），在对应时刻醒来侦听。IDLE态的Paging里携带的是UE的ng-5G-S-TMSI，INACTIVE态的Paging则可能携带I-RNTI。UE收到匹配自己身份的寻呼后，就会触发RRC连接建立或者RRC连接恢复流程。

很多工程师容易忽略寻呼时机是有限且宝贵的，所以现场做被叫测试的时候，如果发现终端没反应，不要只盯着Paging看，还要检查核心网是否发出了寻呼，以及终端是不是在错误的非连续接收周期里“睡过头了”。

3.2 MSG3里的RRCSetupRequest到底写了什么

终端主动发起连接建立时，会先通过PRACH发前导码，收到基站的RAR（随机接入响应）并获得上行授权后，在MSG3中发送RRCSetupRequest。这是RRC在空口上传出的第一句话。

RRCSetupRequest本身非常精简，因为在没有专用配置和安全上下文之前，它只能走公共控制信道CCCH，能装的信息非常有限。具体内容由下面这段ASN.1描述：

RRCSetupRequest ::= SEQUENCE { criticalExtensions CHOICE { rrcSetupRequest RRCSetupRequest-IEs, criticalExtensionsFuture SEQUENCE {} } } RRCSetupRequest-IEs ::= SEQUENCE { ue-Identity UE-Identity, establishmentCause EstablishmentCause, spare BIT STRING (SIZE (1)) } UE-Identity ::= CHOICE { ng-5G-S-TMSI-Part1 BIT STRING (SIZE (39)), randomValue BIT STRING (SIZE (40)) }

其中ue-Identity用来让网络识别发起接入的终端身份。如果UE有有效的5G-S-TMSI，就会用39比特的S-TMSI用户标识部分；如果没有有效标识，就退而使用40比特的随机数。网络在收到这条消息后，根据身份决定是走初始上下文建立还是恢复原有的上下文。

establishmentCause则告诉网络这次接入为什么而来：紧急呼叫、高优先级接入、被叫、移动发起的信令、移动发起的业务、异常数据等。网络可以根据这个原因决定是否接纳、是否配置不同优先级。RRCSetupRequest里不会携带任何用户数据，它纯粹是“我来了，原因如下，请给我开门”。

3.3 网络回话：RRCSetup与终端应答RRCSetupComplete

网络收到RRCSetupRequest后，如果同意终端接入，会在RRCSetup消息里下发初始配置。这条消息同样走CCCH，不需要终端先有密钥，因为此时安全上下文还没建立。RRCSetup里最关键的是radioResourceConfigDedicated，它会配置SRB1的PDCP/RLC/MAC参数，以及主小区组的物理层配置。简单说，网络在RRCSetup这条消息里告诉终端：“你的第一个信令承载SRB1按这个参数建起来，后续我们就能用专用信令对话了。”

RRCSetupComplete则是终端在网络完成接入后回传的应答。这条消息已经走DCCH，在SRB1建立后的专用控制信道上传输，终端会通过dedicatedNAS-Message字段把核心网的注册请求或服务请求捎带给基站，由基站封装后转发给核心网AMF。除此之外，RRCSetupComplete还会携带终端选择的PLMN标识、注册AMF标识等信息。

核心网确认UE身份后，gNB收到初始上下文建立请求，接下来会通过RRCReconfiguration给终端配置SRB2、DRB、测量配置等。到这一步，一个完整的接入流程才算真正走完，用户面数据才开始流动。

整个过程用表格串起来会更清晰：

3.4 消息里藏着UE和网络各自的小算盘

把这几条消息拆开看，你会发现UE和网络每一步的选择都有潜在逻辑。

UE在RRCSetupRequest里优先使用5G-S-TMSI，而不是随机数，是为了让网络更快找到它在核心网登记的上下文，减少后续信令。如果没有TMSI，用随机数也能接入，只是网络后续要花费额外信令去完成身份识别。establishmentCause为什么值得注意？因为高层优先接入、MPS/地震告警这类原因会影响网络的接纳策略和后续参数选择，网优调整时也会参考这个字段的统计分布。

RRCSetupComplete里也一样。selectedPLMN-Identity是UE从SIB1广播的PLMN列表里自己挑出来运营商标识，这项信息决定了gNB把NAS消息转发到哪一个核心网节点。registeredAMF则是终端上次注册的AMF标识，如果网络侧发现UE注册的AMF已经变了，就需要通过RRCRelease或者后续流程重新注册。很多接入异常问题，最后查来查去居然卡在这些字段不匹配上，所以读信令时别只扫一眼消息名，关键字段一定要展开看。

4. 网络侧配置和参数，决定了RRC这个“接待前台”的接待规则

4.1 驻留期参数：看不见的“门槛”

终端开机后能不能驻留在一个小区、之后在空闲态怎么重选到别的频点，都由系统消息广播的一组参数决定。这些参数分布在SIB1和重选相关的SIB里，像是前台门口写着的“准入规则”。

比较常看的一个是q-RxLevMin，它代表UE接入小区要求的最低接收电平。这个值如果配得太高，覆盖边缘用户就算看得到小区，也因为没有达到门限而驻不进去；配得太低又可能让UE驻留在信号质量很差的弱小区上，后续接入体验拖垮。真正处理现场问题时，我见过不少“有信号但上不了网”的投诉，其中一类就是q-RxLevMin和q-QualMin设置不合理导致的。

重选参数也很好理解，threshServingLowQ决定服务小区信号低于什么水平允许UE往邻区重选，s-nonIntraSearchP则是空闲态下要不要去搜索异频邻区的开关阈值。这些参数直接影响终端在空闲态“愿意不愿意”留在一个小区里，也会影响接入后的RRC建立成功率和寻呼成功率。做RRC相关工作不要只看连接态，驻留期参数错了，一切后续流程都无从谈起。

4.2 连接态参数：测量、DRX、定时器

进入CONNECTED态后，RRC的角色变成“高频对话”。它通过RRCReconfiguration给终端下发测量配置、DRX配置、承载配置和物理层参数。

测量配置MeasConfig包含测量对象（频点、邻区列表）、上报配置（事件类型、迟滞、触发时延）和测量量（RSRP、RSRQ、SINR）。最常见的A3事件含义是“邻区信号比服务小区好一点”，当终端上报A3测量报告后，网络根据测量结果决定是否发起切换。若A3门限配得太小，切换会很频繁，乒乓效应明显；配得太大又可能导致切换太晚，用户掉话。优化这类参数时，RRC信令里的MeasConfig一定是要逐条核对的对象。

DRX（非连续接收）参数也存在RRCReconfiguration里，它让连接态的终端不用一直监听PDCCH，能周期性地“眯眼”，是以牺牲时延为代价换功耗。有些网络下业务对时延不敏感，可以把DRX周期拉长；但如果配成了长周期又被直播、游戏类业务使用，用户感知就会出问题。

定时器参数更是RRC的“命门”，下面这张表是排障时最常碰到的几个：

注意这些定时器并不全是RRC层自己的，它们很多是跨层联动的。T310依赖MAC/PHY上报的失步状态，T311又和小区选择最终结果相关。所以看定时器的时候，别只盯RRC消息，底层上报也很关键。

4.3 配置查看与验证的常见姿势

协议开发和网优测试里查RRC参数，最常见的方式是三路并看：第一路是后台配置导出的参数表，第二路是空口信令里SIB和专用配置的实际下发值，第三路是终端的内部log显示出的生效值。这三路经常出现不一致，比如后台改了参数但基站没编译成功，或者基站下发版本和终端支持的能力不匹配。

我自己的经验是，任何参数问题最后都以“空口实际下发值”为准，后台配置只能是参考。因为后台显示“已配置”，不代表基站确实按这个配置发了信令。验证时要找到对应消息里的TAG，把ASN.1解码后的实际值和预期值并排对比，往往能发现很多文档里没写清楚的问题。

5. 排查信令卡死和异常释放，我从日志里总结的几个通用套路

5.1 四路日志对照，先定位断点在哪个节点

RRC问题最怕“只看一头”。终端log里显示“发了RRCSetupRequest没收到回应”，可能是基站没收到，也可能是基站回了但终端没解出来，也可能是核心网迟迟没下发初始上下文导致gNB没继续给终端配置。空口只是老传送带，背后每一级都可能掉链子。

所以我排障时习惯同时打开四路信息源：终端log、基站侧日志、核心网N2信令、路测工具数据。终端log回答“终端发没发、收没收”；基站log回答“基站收没收到、解没解调出有效消息”；核心网N2信令回答“gNB有没有把NAS交给AMF、AMF有没有回上下文建立”；路测数据回答“空口环境支不支持这个流程”。

四路日志一定要先对时钟，把同一时刻的事件对齐到一条时间轴上。我看到过太多误判，就是因为终端log用的是终端慢时钟，基站log是高精度时钟，两边不对齐就硬下结论。

5.2 问题一：RRCSetupRequest发出去没人理

这类现象在弱覆盖和干扰场景最常见。排查分三步走。

第一步看终端是否收到了RAR。如果终端连MSG2都没收到，说明问题在随机接入前导阶段，可能是RSRP低到MSG1不可检测，也可能是PRACH资源被干扰或残留配置错误，这时不能去RRC流程里找原因。第二步看基站侧有没有检测到MSG3。终端发出了RRCSetupRequest，但基站若没有解调到有效的数据包，常见原因包括上行定时不准、干扰导致解码CRC失败、波束赋形选择错误。第三步才看RRC层本身，比如establishmentCause对应的接纳控制策略有没有拒绝、小区是否被禁止接入等。

我处理过一个案例，终端RRCSetupRequest重发了十多次，基站log里对应时间点却有多次MSG3解码失败记录，最后排查发现是上行干扰，不是覆盖也不是配置问题。所以别一看到RRC重发就调频点，先分层通断。

5.3 问题二：RRCSetup下来了终端不回

如果gNB侧明明下发了RRCSetup，但终端始终不回复RRCSetupComplete，问题往往在“终端能不能正确解析这条消息”。

一个很常见的坑是终端能力不支持RRCSetup里携带的某个配置。比如网络配置了终端不支持的加密算法、不支持的Band组合、或某些物理层参数越界，终端在ASN.1解码阶段就失败了，根本进不到正常响应流程。这时终端log里通常会留下解码失败的错误码，但很多抓log的人不展开那一段，只看到“网络发了RRCSetup”就觉得网络没问题。

正确姿势是把RRCSetup消息的原始比特流按协议版本重新解码，逐字段核对。有时候网络侧升级了新协议版本，新增了一个可选字段，终端软件用的是旧版本没升级，解出来就是错。因此在多厂商对接测试中，最容易暴露这类兼容性问题，排查时一定记得确认两边的协议版本基准。

5.4 问题三：INACTIVE恢复过程中的上下文丢失

INACTIVE态是5G的新常态，恢复失败问题也成了排障单上的常客。UE在INACTIVE态发RRCResumeRequest，消息里带I-RNTI和短MAC-I。gNB收到后要做两件事：根据I-RNTI找到存下来的UE上下文，然后用短MAC-I做完整性验证。如果gNB找不到上下文，或MAC-I校验失败，gNB不能直接回RRCResume，而是回退到RRCSetup，让UE重新走完整接入。

频繁出现这种“Resume回退到Setup”的情况，对用户影响就是业务恢复变慢。根因通常集中在几个位置：gNB上下文保留定时器配得太短，UE的INACTIVE等太久上下文被清了；或者移动过程中UE重选到了另外一个gNB区域，新gNB没有原gNB的上下文接口信息；还有的纯粹是核心网上下文和gNB保存的上行业务面信息不一致。排查这种问题时，RRCResumeRequest里的I-RNTI和小区标识是定位两个gNB之间交互的关键参数，配合Xn接口日志看上下文拉取情况会比较快。

5.5 排查RRC问题的通用四步

我自己把RRC排障压缩成四步法，按顺序走，能有效避免乱枪打鸟。

第一步，拉通完整的RRC状态转移图。先确认UE当前在什么RRC状态、目标状态是什么、从哪个过程开始断的。第二步，看失败前的最后一条成功消息和失败消息本身。最后一条成功消息决定了哪里是“上游”，失败消息里的cause和参数才是真正线索。第三步，拉KPI校对。RRC建立成功率、E-RAB建立成功率、掉线率、重建比例、切换成功率这五个指标能帮你判断是个例还是系统性问题。第四步，固定环境复测。同一频点同一位置反复抓几遍log，很多偶发问题都是这样才被复现出来的。

这四步走完，绝大多数RRC问题都能定位到具体某一层。剩下那些确实反复复现但找不到根因的，往往是多参数组合导致，需要拉上协议开发和芯片厂商一起过会。

6. 一点土经验：把RRC学成“状态机+消息表”胜过大段背书

6.1 怎么快速建立RRC的知识框架

接触5G RRC这一大摊内容，我不建议一上来就啃TS 38.331的全部文本。规范是按字段维度写的，适合查，不适合入门学。我更推荐三层递进法。

第一层先把状态机背熟：IDLE、INACTIVE、CONNECTED三态之间每一条箭头上挂的是哪个过程、哪条消息，心里要有一张图。第二层把ATOMIC流程背下来：寻呼流程、初始接入流程、恢复流程、释放流程、重建流程，每个流程从触发条件到结束条件能默写。第三层再去啃ASN.1和字段细节，这时候你会发现很多字段是服务于状态转移和流程触发的，不需要死记。

这个框架还有个好处，5G在持续演进，RedCap、NTN、多卡协同这些新特性来了之后，RRC的修改最终都会反映在状态转移和新增流程上。你只要把基础模型建好，新版本更新就只是往模型里插分支。

6.2 几个值得长期保留的工作习惯

最后分享几个我在项目里留下的习惯，不一定高级，但很管用。

第一个习惯：抓到任何log，先保存原始文件再截图。RRC信令的原始十六进制流是排障时的“案发现场”，截图只保留了解码后的文本，丢了原始内容就等于毁证据。第二个习惯：抓log时打marker，记录时间、频点、小区、操作步骤。如果某个问题复现了，没有marker你就得在几个小时的日志里大海捞针。第三个习惯：写问题描述时，至少附上三条信令轨迹——收到什么、发出什么、卡在哪，而不是一句“上不了网”。很多跨团队协作的效率问题，都是因为描述信息太少导致反复拉扯。第四个习惯：定期用规范验证自己的知识，TS 38.331的版本更新得很快，别总是凭老经验判断新功能，现网遇到的现象永远是最新规范“翻译”出来的结果。

这些东西说起来都是琐碎的小事，但在RRC这个极其依赖精确信息的领域，小习惯往往决定排查效率。也正因为这样，我每次带新人，第一课从来不灌大道理，只让他们先把“状态机图”和“消息表”贴在工位上，遇到问题先归属到流程里的具体位置。就是这条最简单的建议，让我和不少一起干活的同事少走了很多弯路。