4. RRC连接建立流程：UE发起RRC连接请求、网络侧响应与配置、SRB1建立与初始上下文设置
RRC连接建立，说白了就是UE跟基站之间第一次“握手”。这个流程要是走不顺，后面什么都别谈。我刚开始做LTE协议栈那会儿，最怕的就是RRC连接建立失败——你想想看，用户手机连不上网，第一反应就是骂运营商，而运营商第一个查的就是RRC层日志。
今天咱们就掰开揉碎了讲这个流程。我会结合我实际调试中的踩坑经历，把每个关键点都说到位。
4.1 流程总览：三步走
整个RRC连接建立，可以概括为三个核心步骤：
- UE发起RRC连接请求——UE说“我要上网”
- 网络侧响应与配置——基站说“好的，给你分配资源”
- SRB1建立与初始上下文设置——双方正式建立信令通道，开始传正经数据
下面这张图是我自己画的，把整个信令交互和状态机变化都串起来了。建议你保存下来，调试时对照着看。
4.2 UE发起RRC连接请求
UE在什么情况下会发起RRC连接？说白了就是有数据要传了——可能是用户打电话、刷网页，也可能是TAU（跟踪区更新）这类信令业务。
UE会在CCCH（公共控制信道）上通过SRB0发送RRCConnectionRequest消息。注意，这时候还没有专用资源，所以用的是公共信道。
关键点：RRC连接请求消息里携带了InitialUE-Identity，这个值可以是IMSI、TMSI或者随机值。我见过不少调试案例，问题就出在这个Identity上——比如TMSI过期了，网络侧不认，直接拒绝连接。
消息体长这样（ASN.1描述）：
RRCConnectionRequest ::= SEQUENCE {
criticalExtensions CHOICE {
rrcConnectionRequest-r8 RRCConnectionRequest-r8-IEs,
criticalExtensionsFuture SEQUENCE {}
}
}
RRCConnectionRequest-r8-IEs ::= SEQUENCE {
initialUE-Identity InitialUE-Identity,
cause EstablishmentCause,
spare BIT STRING (SIZE (1))
}EstablishmentCause有几种取值：mo-Signalling（移动发起的信令）、mo-Data（移动发起的数传）、mt-Access（网络侧触发的接入）、emergency（紧急呼叫）。
我的调试习惯：抓日志时，第一眼看cause值。如果UE上报的是mo-Data但实际是信令流程，那大概率是上层应用层传参错了。我曾经排查过一个诡异问题——手机一直发mo-Data，但核心网侧就是不给建DRB，最后发现是NAS层把信令业务类型填错了。
4.3 网络侧响应与配置
eNB收到请求后，会做两件事：
- 资源分配——给UE分配C-RNTI（小区无线网络临时标识）
- SRB1配置——在
RRCConnectionSetup消息里携带SRB1的配置参数
eNB通过CCCH上的SRB0回复RRCConnectionSetup。这个消息里包含了：
radioResourceConfigDedicated：专用资源配置，包括SRB1的RLC、MAC、PHY参数masterCellGroup：主小区组配置，包含MAC层配置、SpCell配置等
注意：RRCConnectionSetup消息是在CCCH上发的，但用的是临时C-RNTI加扰的PDCCH来调度。如果UE没收到这个调度，就会一直等，直到定时器超时重发请求。我遇到过一种情况——eNB发了Setup但UE没收到，原因是PDCCH的DCI格式配错了，UE解不出来。
这里有个容易踩坑的地方：SRB1的RLC模式。规范里SRB1必须用AM（确认模式），但有些实现里默认配成了UM。我刚开始做协议栈时就在这上面栽过跟头——UE收到Setup后，RLC层发现模式不匹配，直接丢弃了消息。
4.4 SRB1建立与初始上下文设置
UE收到RRCConnectionSetup后，会做以下动作：
- 配置底层（MAC、RLC、PDCP）建立SRB1
- 切换到RRC_CONNECTED状态
- 在SRB1上（DCCH信道）发送
RRCConnectionSetupComplete
RRCConnectionSetupComplete消息里携带了NAS PDU，这个NAS PDU会被eNB透传给MME。NAS PDU里包含什么？通常是ATTACH REQUEST或TAU REQUEST，取决于UE发起连接的原因。
核心逻辑：SRB1建立完成后，UE和eNB之间就有了一个可靠的信令通道。后续所有的RRC信令（重配置、释放等）都在SRB1上走。而NAS消息则通过SRB1透传，eNB不解析，只负责转发。
MME收到NAS PDU后，会触发初始上下文建立流程。MME通过S1-AP接口发送INITIAL CONTEXT SETUP REQUEST给eNB，里面包含了：
- UE能力信息（如果MME有缓存）
- 安全上下文（密钥、加密算法）
- EPS承载列表（包括默认承载的QoS参数）
eNB收到后，会发起RRCConnectionReconfiguration，给UE配置：
- 安全激活——启动PDCP层的加密和完整性保护
- SRB2建立（如果需要）——用于NAS消息传输
- DRB建立——用户面数据承载
UE完成配置后，回复RRCConnectionReconfigurationComplete。至此，整个RRC连接建立流程才算真正走完。
| 步骤 | 消息 | 信道/承载 | 关键内容 |
|---|---|---|---|
| 1 | RRCConnectionRequest | CCCH / SRB0 | InitialUE-Identity, EstablishmentCause |
| 2 | RRCConnectionSetup | CCCH / SRB0 | C-RNTI, SRB1配置, MAC配置 |
| 3 | RRCConnectionSetupComplete | DCCH / SRB1 | NAS PDU (ATTACH/TAU REQUEST) |
| 4 | INITIAL CONTEXT SETUP REQUEST | S1-AP | 安全上下文, EPS承载, UE能力 |
| 5 | RRCConnectionReconfiguration | DCCH / SRB1 | 安全激活, SRB2/DRB配置 |
| 6 | RRCConnectionReconfigurationComplete | DCCH / SRB1 | 确认配置完成 |
避坑指南：我曾经遇到过一个现场问题——UE发完SetupComplete后，eNB一直没收到Initial Context Setup Request。查了半天，发现是MME侧SCTP链路断了，S1-AP消息根本没发过来。所以调试时，不要只盯着空口日志，S1接口的抓包同样重要。
嗯，这里还要提一句：定时器。RRC连接建立过程中有好几个定时器在跑：
- T300：UE侧等待RRCConnectionSetup的定时器，超时则重发请求
- T301：UE侧等待RRCConnectionReconfiguration的定时器
- T302：eNB侧用于拥塞控制，告诉UE“等会儿再试”
调试时，如果发现UE反复发请求，先看T300有没有超时。如果T300超时了，说明eNB的Setup消息没下来，问题大概率在eNB侧或者空口质量上。
最后总结一句：RRC连接建立是整个LTE协议栈的基石。你把这个流程吃透了，后面学移动性管理、承载建立都会轻松很多。我每次带新人，第一件事就是让他们对着日志把RRC连接建立的每一步都画出来——什么时候发什么消息、用什么信道、状态怎么变，画到滚瓜烂熟为止。