2. 连接建立流程：RRC连接建立、初始上下文建立、默认承载激活、附着流程中的信令交互

各位好，我是老周。今天咱们聊聊LTE连接建立的全流程。说实话，很多刚入行的兄弟一看到信令流程就头大，觉得太抽象。我刚开始也是这样，直到有一次在现网排障，被一个附着失败的问题折腾了三天，才真正把这些流程刻进脑子里。

连接建立，说白了就是手机从「待机」状态变成「在线」状态的过程。你想想看，手机开机后要上网、要打电话，总得先跟网络打个招呼吧？这个打招呼的过程，就是咱们今天要讲的附着流程。

2.1 整体流程概览

一个完整的附着流程，包含四个核心阶段：

  1. RRC连接建立 — 手机和基站先拉上手
  2. 初始上下文建立 — 核心网告诉基站：这个手机是谁、有什么权限
  3. 默认承载激活 — 给手机分配一条默认的数据通道
  4. 附着完成 — 手机正式注册到网络

这四个阶段环环相扣，任何一个环节出问题，手机就上不了网。我在项目中遇到过好几次，用户投诉「有信号但上不了网」，查到最后都是某个信令交互超时导致的。

核心要点： 附着流程是LTE网络优化的基础。你如果能把附着流程的信令交互背下来，排查连接断开问题就成功了一半。

LTE附着流程整体架构 阶段一 RRC连接建立 阶段二 初始上下文建立 阶段三 默认承载激活 阶段四 附着完成 参与网元：UE ↔ eNodeB ↔ MME ↔ SGW ↔ PGW 关键信令交互 RRC Connection Request RRC Connection Setup Initial UE Message Initial Context Setup Activate Default EPS Bearer Context 💡 每个阶段失败都会导致附着失败，需逐段排查

2.2 RRC连接建立

RRC连接建立，是手机和基站之间的第一次握手。嗯，这里要注意，RRC是Radio Resource Control的缩写，说白了就是无线资源控制层。

手机开机后，先做小区搜索和同步，然后读取系统消息。系统消息里有什么？有小区接入参数、随机接入配置等等。手机拿到这些信息后，就开始发起随机接入。

2.2.1 随机接入过程

随机接入分两种：竞争性和非竞争性。附着流程里用的是竞争性随机接入。过程是这样的：

  1. UE发送Preamble — 手机在PRACH信道上发一个随机接入前导码
  2. eNodeB回复Random Access Response — 基站回一个响应，带上时间提前量TA和上行授权
  3. UE发送RRC Connection Request — 手机带上自己的标识（TMSI或随机值）
  4. eNodeB回复RRC Connection Setup — 基站分配SRB1资源，建立信令无线承载
  5. UE发送RRC Connection Setup Complete — 手机确认建立完成，同时带上附着请求

实战技巧： 我个人习惯在排查RRC建立失败时，先看Preamble发送次数。如果Preamble发了十几次都没收到RAR，那大概率是上行干扰或者PRACH配置有问题。我曾经在某个高铁站遇到这种情况，最后发现是PRACH频偏参数没配好。

2.2.2 RRC建立失败常见原因

失败现象 可能原因 排查方向
Preamble无响应 上行干扰、PRACH功率不足 查上行干扰电平、调整PRACH初始功率
RRC Setup无响应 下行覆盖差、C-RNTI分配失败 查RSRP/SINR、检查C-RNTI资源池
RRC Setup Complete丢失 上行失步、TA调整异常 查TA值、检查上行同步定时器

2.3 初始上下文建立

RRC建立完成后，手机和基站之间有了信令通道。接下来，基站要把手机的附着请求转发给核心网。这个过程叫初始上下文建立。

具体信令交互是这样的：

  • eNodeB → MME： Initial UE Message（携带NAS层的Attach Request）
  • MME → eNodeB： Initial Context Setup Request（携带UE能力、安全参数、QoS信息）
  • eNodeB → UE： Security Mode Command（启动安全模式）
  • UE → eNodeB： Security Mode Complete
  • eNodeB → UE： RRC Connection Reconfiguration（配置SRB2和DRB）
  • UE → eNodeB： RRC Connection Reconfiguration Complete
  • eNodeB → MME： Initial Context Setup Response

你想想看，这个阶段涉及三个网元之间的信令交互，任何一个环节超时都会导致失败。我记得有一次排查一个「有信号但无法注册」的问题，发现是MME给eNodeB下发Initial Context Setup Request时，携带的UE安全能力跟手机实际支持的不匹配，导致Security Mode Command失败。

⚠️ 注意： 初始上下文建立阶段，如果MME下发的QoS参数跟eNodeB支持的不一致，也会导致建立失败。我建议你在排查时，重点关注MME和eNodeB之间的S1接口信令，看看有没有Cause值指示。

2.4 默认承载激活

初始上下文建立完成后，核心网要给手机分配一个默认的EPS承载。这个承载是手机上网的基础通道，说白了就是一条「默认数据管道」。

默认承载激活的信令流程：

  1. MME → SGW： Create Session Request
  2. SGW → PGW： Create Session Request
  3. PGW → SGW： Create Session Response（分配IP地址）
  4. SGW → MME： Create Session Response
  5. MME → eNodeB： 在Initial Context Setup Request中携带承载信息
  6. eNodeB → UE： RRC Connection Reconfiguration（配置DRB）
  7. UE → eNodeB： RRC Connection Reconfiguration Complete
  8. eNodeB → MME： Initial Context Setup Response

这里有个关键点：默认承载的QCI（QoS Class Identifier）通常是5、6、8或9。QCI 5用于IMS信令，QCI 6用于视频流，QCI 8/9用于普通上网。如果核心网下发的QCI跟手机期望的不一致，也可能导致承载激活失败。

核心要点： 默认承载激活失败，最常见的原因是核心网侧配置问题。比如PGW地址不可达、APN配置错误、或者用户签约数据有问题。我建议你在排查时，先看MME和SGW之间的GTP-C信令，确认Create Session Request/Response是否正常。

2.5 附着完成

默认承载激活后，手机就拿到了IP地址，理论上可以上网了。但附着流程还没完，还需要完成最后的确认步骤：

  • UE → MME： Attach Complete（通过eNodeB转发）
  • MME → UE： Attach Accept（携带GUTI、TAI List等）
  • UE → MME： GUTI Reallocation Complete（如果GUTI有变化）

附着完成后，手机进入ECM-CONNECTED状态，可以正常收发数据了。

2.6 实战排查思路

好了，流程讲完了。咱们说说实战中怎么用。如果你遇到手机无法附着的问题，我的排查思路是这样的：

  1. 先看RRC建立是否成功 — 查eNodeB侧RRC建立成功率统计，看失败原因
  2. 再看S1接口信令 — 抓S1AP信令，看Initial UE Message有没有发出去，Initial Context Setup有没有回来
  3. 然后看NAS层信令 — 看Attach Request和Attach Accept的交互，重点关注Cause值
  4. 最后看GTP-C信令 — 如果承载激活失败，查SGW/PGW之间的会话创建信令

避坑指南： 我曾经遇到过一个案例，手机能完成RRC建立，但附着总是失败。查了两天，最后发现是MME上配置的TAI跟eNodeB广播的TAI不一致。你想想看，手机附着请求里带的TAI跟MME预期的不匹配，MME直接拒绝了。所以，排查附着问题时，别忘了检查TAI、PLMN这些基础配置。

嗯，以上就是连接建立流程的核心内容。记住，附着流程是LTE网络的基础，你把这块吃透了，后面排查连接断开问题就会轻松很多。

← 上一章 📖 返回目录 下一章 →