好的,我们继续跟随工程师阿哲的脚步,深入3GPP TS 38.331规范的殿堂。在上一篇我们对第四章“总则”进行了深入剖析,理解了RRC协议的顶层架构、核心状态机和服务模型后,阿哲对RRC的“骨架”有了清晰的认识。现在,他将翻开第五章“流程”(Procedures),开始探索RRC这座宏伟大厦内部具体的“运作流程”。
根据规范拆解规则,由于5.1节“总则”内容较为简短,主要规定了所有RRC流程应遵循的通用准则,为了保证文章的深度和内容的逻辑连贯性,我们将5.1节与5.2节“系统信息”合并解读。这好比在学习具体的法律条文(5.2)之前,先了解通用的“释法原则”(5.1),为后续的深入理解打下坚实基础。
深度解析 3GPP TS 38.331:5.1 General & 5.2 System Information (万物之始:UE如何“睁眼看世界”)
本文技术原理深度参考了3GPP TS 38.331 V18.5.1 (2025-03) Release 18规范中,关于“5.1 General (流程总则)”和“5.2 System Information (系统信息)”的核心章节,旨在为读者详细拆解UE从开机到成功驻留小区前,必须执行的第一个、也是最基础的RRC流程——系统信息获取的全过程。
阿哲将他的全新5G手机关机,准备从最原始的状态开始,模拟一次完整的开机入网过程。他知道,当他按下电源键的那一刻,手机内部的RRC协议实体将苏醒,并严格遵循第五章定义的流程,开始它与网络世界的第一次对话。在千头万绪的流程中,RRC首先要做的,就是“睁开眼睛,看清世界”——也就是获取系统信息。但在开始这个具体流程之前,阿哲首先仔细阅读了5.1节,了解所有流程都必须遵守的“金科玉律”。
1. RRC流程的“最高行为准则” (解读5.1 General)
5.1节虽然篇幅不长,但地位崇高。它为后续所有RRC流程(如连接建立、切换、测量等)立下了规矩,确保了UE在处理纷繁复杂的RRC信令时,行为一致、可预测且健壮。
1.1 流程处理的基本原则 (5.1.2 General requirements)
The UE shall: 1> process the received messages in order of reception by RRC, i.e. the processing of a message shall be completed before starting the processing of a subsequent message;
深度解析:这是RRC流程处理的顺序性原则。阿哲将其理解为CPU的指令流水线,但更为严格。RRC层必须按照消息到达的先后顺序,串行处理每一条消息。处理完一条消息的所有动作(包括配置更新、定时器操作等)之后,才能开始处理下一条。这保证了配置的确定性,避免了因消息乱序处理而导致的逻辑混乱。例如,如果网络先发了一条添加小区的消息,紧接着又发了一条修改该小区配置的消息,UE必须保证先完成“添加”动作,再去执行“修改”,否则就会出错。
1> set the rrc-TransactionIdentifier in the response message, if included, to the same value as included in the message received from the network that triggered the response message;
深度解析:这是事务标识符匹配原则。在很多请求-响应式的RRC流程中(如UE能力查询),网络发起的请求消息会带有一个rrc-TransactionIdentifier,就像一个请求的“票号”。UE在回复时,必须在响应消息中回填相同的“票号”。这使得网络能够准确地将收到的响应与之前发出的众多请求对应起来,尤其是在网络同时与多个UE进行交互时,避免了张冠李戴。
1.2 多制式双连接(MR-DC)的特殊要求 (5.1.3 Requirements for UE in MR-DC)
5G的一个重要特性是支持多种双连接技术,特别是与4G LTE的紧密协同。5.1.3节明确了UE如何判断自己正处于何种双连接模式下。
In this specification, the UE considers itself to be in:
- EN-DC, if and only if it is configured with nr-SecondaryCellGroupConfig according to TS 36.331, and it is connected to EPC,
- NGEN-DC, if and only if it is configured with nr-SecondaryCellGroupConfig according to TS 36.331, and it is connected to 5GC,
- NE-DC, if and only if it is configured with mrdc-SecondaryCellGroup set to eutra-SCG,
- NR-DC, if and only if it is configured with mrdc-SecondaryCellGroup set to nr-SCG,
深度解析:这段定义极其关键,它区分了四种主流的双连接模式:
- EN-DC: 4G(eNB)作为主节点,连接到4G核心网(EPC),5G(gNB)作为辅节点。这是5G NSA(非独立组网)的典型部署方式。
- NGEN-DC: 4G(eNB)作为主节点,但连接到5G核心网(5GC),5G(gNB)作为辅节点。
- NE-DC: 5G(gNB)作为主节点,连接到5G核心网(5GC),4G(eNB)作为辅节点。
- NR-DC: 5G(gNB)作为主节点,另一个5G(gNB)作为辅节点,通常用于毫米波和Sub-6GHz的聚合。
RRC协议的许多流程在这几种模式下的行为会有差异。因此,UE必须首先根据RRC配置消息中的关键信息元素(如nr-SecondaryCellGroupConfig来自4G RRC还是mrdc-SecondaryCellGroup来自NR RRC)以及当前连接的核心网类型(EPC或5GC),准确判断自己所处的模式,以便后续能够正确地执行相应的流程。
阿哲在心中记下:“进入具体流程前,先要明确行为准则和自身所处的网络环境,这是严谨的工程思维。” 准备工作完成,他正式启动手机,开始追踪RRC的第一个实战流程。
2. 睁眼看世界:系统信息获取流程 (解读5.2 System information)
阿哲按下手机的电源键。屏幕亮起,logo闪现。在这看似平静的几秒钟里,手机的基带芯片正在全速运转,执行着一场精心编排的“信息探索芭蕾”——系统信息获取。这是UE与无线世界建立联系的第一步,也是后续所有行为的基础。
2.1 系统信息的宏观结构与角色 (5.2.1 Introduction)
系统信息(System Information, SI)被划分为两大类:MIB和一系列的SIBs。
System Information (SI) is divided into the MIB and a number of SIBs and posSIBs where:
- the MIB is always transmitted on the BCH… and it includes parameters that are needed to acquire SIB1…
- the SIB1 is transmitted on the DL-SCH… SIB1 includes information regarding the availability and scheduling … of other SIBs…
- SIBs other than SIB1… are carried in SystemInformation (SI) messages, which are transmitted on the DL-SCH.
阿哲用一个图书馆的比喻来理解这个体系:
- MIB (MasterInformationBlock):就像是图书馆大门口的一块小小的指示牌。它不告诉你任何书的具体位置,但它告诉你“索引目录查询台”(即SIB1)在哪里。MIB在物理广播信道(PBCH)上以80毫秒的固定周期广播,内容恒定且精简。
- SIB1 (SystemInformationBlockType1):这就是图书馆的“总索引目录”。它提供了关于整个图书馆(小区)的基本信息(如开馆时间、规则等),最重要的是,它提供了所有其他专业书籍(其他SIBs)的“索书号”和“所在区域”(即调度信息)。SIB1在物理下行共享信道(PDSCH)上发送,相比MIB,它的内容更丰富,周期也更长(160ms)。
- 其他SIBs (SystemInformationBlockType n):这些是图书馆里分门别类的专业书籍,如“历史区”(SIB3/4/5,小区重选参数)、“外语区”(SIB5,异系统参数)、“新兴技术区”(SIB12,Sidelink配置)等。它们被打包在不同的“SI消息”(SI Message)中,在DL-SCH上根据SIB1的调度信息在各自的“传输窗口”(SI-window)内发送。
Figure 5.2.2.1-1: System information acquisition 这个流程图形象地展示了UE获取SI的基本交互:UE先读取MIB和SIB1,如果需要其他SIB但小区并未广播,UE可以通过发送SystemInformationRequest来“按需点播”。
2.2 SIB的“保鲜期”与“更新通知” (5.2.2.2 SIB validity and need to (re)-acquire SIB)
阿哲想到,他每天上下班都会经过同一个基站,难道手机每次都要重新读取一遍所有系统信息吗?5.2.2.2节解答了他的疑惑。
2.2.2.1 SIB的有效性 (SIB validity)
UE可以将之前成功接收的SIB存储起来。当UE重选回一个小区时,它可以检查存储的SIB是否依然“有效”,从而避免重新接收,加快驻留速度。
The UE shall store the associated areaScope, if present, the first PLMN-Identity…, the cellIdentity…, the systemInformationAreaID, if present, and the valueTag…
判断一个SIB是否有效,需要比对一系列的“标签”:
- PLMN ID / SNPN ID:网络身份是否匹配。
- Cell Identity:小区身份是否匹配。
- Area ID & Area Scope:如果SIB是区域性的(area specific),需要检查区域ID是否匹配。
- Value Tag:这是一个版本号。如果网络更新了某个SIB的内容,就会增加其
valueTag。
只有当所有这些标签都与当前小区广播的信息一致时,UE才能认为存储的SIB是有效的。此外,规范还规定了一个“绝对保质期”:
delete any stored version of a SIB after 3 hours from the moment it was successfully confirmed as valid;
任何SIB在成功验证后,最多只能存储3小时,过期作废。
2.2.2.2 SI变更与PWS通知 (SI change indication and PWS notification)
网络如果需要更新系统信息,会提前发出“变更通知”。
A modification period is used, i.e. updated SI message … is broadcasted in the modification period following the one where SI change indication is transmitted.
- Modification Period (修改周期):网络更新SI是在特定的周期边界进行的。这个周期由SIB1中的
modificationPeriodCoeff定义。 - SI Change Indication (SI变更指示):在当前修改周期内,如果网络计划在下一个修改周期更新SI,它会在寻呼消息中(通过PDCCH上的DCI)将
systemInfoModification比特置位。处于IDLE/INACTIVE状态的UE通过在自己的寻呼时机监听PDCCH来检测这个指示。 - PWS (公共告警系统):同样,如果有ETWS(地震海啸)或CMAS(公共告警)消息,网络也会通过寻呼DCI中的
etwsAndCmasIndication比特来通知UE。
场景模拟: 阿哲的手机在口袋里处于IDLE态。突然,附近发生紧急情况。网络在下一个寻呼时机,向该区域所有UE发送了带有PWS指示的寻呼DCI。阿哲的手机“醒来”检测到该指示,立即唤醒协议栈,紧急去读取SIB1以获取PWS相关SIB(如SIB6/7/8)的调度信息,并接收告警内容,最终发出警报声。
2.3 获取系统信息的详细步骤 (5.2.2.3 Acquisition of System Information)
这是整个流程的核心,阿哲打起十二分精神,一步步追踪手机的动作。
2.3.1 获取MIB和SIB1 (5.2.2.3.1)
这是开机后的第一步,也是最关键的一步。
-
盲搜SSB: UE在开机后,对其支持的频段进行扫描,寻找同步信号/物理广播信道块(SS/PBCH Block)。SSB包含了用于小区同步的主/辅同步信号(PSS/SSS)和承载MIB的PBCH。
-
解码MIB: 成功同步到一个SSB后,UE解码出PBCH承载的MIB。
Upon receiving the MIB the UE shall: … 3> apply the received systemFrameNumber, pdcch-ConfigSIB1, subCarrierSpacingCommon, ssb-SubcarrierOffset and dmrs-TypeA-Position.
MIB中最关键的信息是
pdcch-ConfigSIB1。它定义了一个特殊的CORESET (Control Resource Set),UE必须在这个CORESET中寻找用于调度SIB1的DCI。 -
解码SIB1: UE根据
pdcch-ConfigSIB1的配置,在对应的时频资源上监听PDCCH。一旦成功解码出由SI-RNTI加扰的DCI,该DCI就会指示SIB1所在的PDSCH资源。UE随即在指定的PDSCH上解码出完整的SIB1消息。
2.3.2 获取其他SI消息 (5.2.2.3.2)
SIB1到手后,获取其他SIB就变得“有章可循”。
When acquiring an SI message, the UE shall: 1> determine the start of the SI-window for the concerned SI message as follows: 2> if the concerned SI message is configured in the schedulingInfoList: 3> for the concerned SI message, determine the number n… 3> determine the integer value x = (n – 1) × w, where w is the si-WindowLength; 3> the SI-window starts at the slot a, where a = x mod N, in the radio frame for which SFN mod T = FLOOR(x/N)…
阿哲仔细研究了这段计算公式。SIB1中的si-SchedulingInfo是一个列表,列出了所有其他SIB的调度信息。UE想获取SIB2,就会在这个列表中找到SIB2对应的条目,其中包含了:
si-Periodicity(T): SIB2的广播周期。si-WindowLength(w): 接收SIB2的传输窗口长度。
UE根据SIB2在列表中的顺序n,以及窗口长度w,计算出一个偏移量x。再结合周期T,就能精确计算出接收SIB2的SI-Window的起始帧(SFN)和起始时隙(slot)。在这个窗口内,UE再次监听由SI-RNTI加扰的PDCCH,以获取调度SIB2的PDSCH资源。
2.3.3 按需请求SI (5.2.2.3.3)
如果SIB1指示某个SIB(比如SIB13,V2X信息)是onDemand模式,UE如果需要它,就必须主动发起请求。
if SIB1 includes si-SchedulingInfo containing si-RequestConfig… 2> trigger the lower layer to initiate the Random Access procedure…
这个请求过程是一个简化的随机接入过程(RACH)。UE使用SIB1中为SI请求专门配置的PRACH资源(si-RequestConfig),向gNB发送一个“我需要某某SIB”的请求。gNB收到后,会在后续的SI窗口中广播该SIB,或者通过专用信令下发。
2.4 收到SIB后的动作 (5.2.2.4 Actions upon receipt of System Information)
获取到SIB只是第一步,更重要的是正确地应用其中的配置。
- 收到MIB后:立即应用其中的参数(如
pdcch-ConfigSIB1)去寻找SIB1。 - 收到SIB1后: 这是最复杂的一步。UE需要:
- 存储SIB1。
- 检查
cellBarred字段,如果小区被禁,则立即停止接入,开始寻找其他小区。 - 将PLMN列表等信息上报给NAS层,由NAS层决定是否在此网络驻留。
- 应用
servingCellConfigCommon中的公共信道配置。 - 解析
si-SchedulingInfo,为获取其他SIB做好准备。
- 收到SIB2-SIB25后: UE会解析并存储这些SIB中的参数,供后续的特定流程使用。例如,存储SIB2中的RACH配置,为后续的RRC连接建立做准备;存储SIB3的同频重选参数,用于IDLE态移动性管理。
2.5 关键信息缺失的处理 (5.2.2.5 Essential system information missing)
if the UE is unable to acquire the MIB or SIB1: 3> consider the cell as barred… 3> perform cell re-selection…
如果UE经过多次努力,仍然无法成功解码MIB或SIB1,这意味着它无法在这个小区正常工作。根据规范,UE必须将此小区视为“禁止”小区,并立即启动小区重选流程,去寻找其他可用的“避难所”。
结语:从混沌到有序的第一步
阿哲长舒了一口气。他通过追踪系统信息获取的完整流程,亲眼见证了一部手机是如何从一个对周围电磁环境一无所知的“盲人”,通过解码MIB、SIB1、其他SIBs,最终在脑海中构建起一幅关于当前小区的完整“数字地图”的。
这个过程,是从混沌到有序的第一步,也是所有后续高级通信行为(连接、切换、高速数据传输)的绝对基石。没有成功的SI获取,就没有后续的一切。第四章的架构和第五章的流程在这里完美地结合在了一起。
阿哲的手机屏幕上已经显示出了信号格和运营商名称,这标志着系统信息获取成功,UE已经成功在小区“安家落户”(Camped on the cell),进入了RRC_IDLE状态。他的手指已经悬停在了拨号键上,下一步,他准备发起一次呼叫,来触发更为激动人心的“RRC连接建立”流程。我们将在下一篇文章中,继续跟随阿哲,深入探索5.3节的奥秘。
FAQ
Q1:MIB和SIB1在物理信道和内容上有何本质区别? A1:本质区别在于承载信道、广播方式和信息作用。
- MIB:承载于物理广播信道(PBCH),与主/辅同步信号(PSS/SSS)一起组成SSB块。它以固定的80ms周期、在固定的时频位置广播,内容极度精简,主要作用是提供最基本的小区同步信息,并“指路”告诉UE如何找到SIB1。
- SIB1B:承载于物理下行共享信道(PDSCH),需要通过PDCCH进行动态调度。它的内容非常丰富,是小区的“总纲”,定义了小区身份、接入控制以及所有其他SIB的调度信息。它的作用是为UE提供驻留和接入所需的核心参数,并充当其他所有系统信息的“目录”。
Q2:5G的“按需(on-demand)”SIB机制相比4G有什么优势? A2:优势在于极大地提升了空口资源的利用效率。在4G中,所有SIB(除了少数特定SIB)都需要周期性广播,无论小区内是否有UE需要它们。而在5G,许多不常用的SIB(如用于V2X的SIB13、用于卫星通信的SIB19等)可以被配置为“按需”模式。这意味着小区平时不广播这些SIB,节省了大量的PDSCH资源。只有当某个UE(如一辆车联网汽车)确实需要这些信息时,它才会通过一个轻量级的随机接入过程向网络发起请求,网络再临时广播或通过专用信令下发给它。这种机制使得网络可以根据实际业务需求动态分配资源,非常适合5G多样化的业务场景。
Q3:UE是如何知道系统信息(SI)发生了变化,从而去获取新版本的SI?
A3:UE通过在寻呼(Paging) 时机监听PDCCH上的DCI(下行控制信息)来得知SI的变化。网络在决定于下一个“修改周期”(Modification Period)更新SI内容时,会在当前修改周期内,通过DCI中的一个特定比特(systemInfoModification)向区域内的UE发送通知。当UE在其寻呼时机监听到该比特被置位,它就知道SI即将变更,并会在下一个修改周期开始时重新获取SIB1,并根据新的SIB1调度信息去更新其他发生变化的SIB。
Q4:SIB的valueTag字段起什么作用?
A4:valueTag可以理解为SIB内容的版本号。当网络更新了某个SIB(除SIB1外)的内容时,它不仅会更新SIB本身,还会更新SIB1中对应于该SIB的调度信息里的valueTag字段。当UE重选到一个小区并准备使用缓存的旧SIB时,它会先读取最新的SIB1,然后比较SIB1中记录的valueTag和自己缓存SIB时记录的valueTag。如果两者相同,说明SIB内容没有变化,缓存可用;如果不同,则说明SIB内容已更新,UE必须丢弃缓存,重新接收新版本的SIB。这个机制确保了UE总能使用最新、最准确的系统信息。
Q5:如果一个小区被设置为cellBarred,UE会有什么行为?
A5:如果UE在SIB1中读到cellBarred字段被设置为“barred”(禁止),它会立即停止在该小区上的任何接入尝试。根据3GPP TS 38.304规范,UE会认为该小区在一段时间内(由T302定时器控制)是不可用的,即使其信号质量是最好的。UE会立即启动小区重选流程,忽略这个被禁止的小区,去评估和选择其他邻区进行驻留。这是一种重要的网络控制手段,用于实现负载均衡、网络维护或紧急情况下的接入管制。