Control-Plane Protocol Interactions in Cellular Networks

TLDR

1. 背景

3G/4G 蜂窝网络的控制面由多个分层信令协议构成，负责移动性、会话和无线资源管理。这些协议不仅在上下层之间跨层交互，还要跨 CS/PS 两个域、跨 3G/4G 两个系统协同工作，而且协议栈和信令长期是封闭黑盒。

2. 问题与动机（Problem & Motivation）

• 问题： 单个协议各自设计良好，并不意味着它们之间的交互是正确的。协议交互中存在哪些缺陷，根因是什么？
• 动机：
  • 这类控制面缺陷比数据面故障危害更大，会导致用户断网、卡在 3G、呼叫延迟、数据速率暴跌
  • 此前的研究只关注数据面或单个协议，没人系统研究过协议之间的交互

3. 方法论

Key Insight： 问题出在交互本身

1. 必要的协作没有做好（共享状态不一致、上层依赖下层做不到的保证）
2. 不必要的耦合却被引入（操作被人为赋优先级、两个域共用同一套资源）

Methodology： 提出两阶段工具 CNetVerifier

• 先依据 3GPP 标准，把各协议建模为 UE 与网络两侧的 FSM，结合随机采样的使用场景，用 Spin 模型检查三条用户视角的服务性质，产出反例
• 再按反例在两家美国运营商上做手机端 trace 实测，验证问题并评估影响

Design Overview：

共发现 6 个问题（S1–S6），并按跨层、跨域、跨系统三个维度给出对应修复：层扩展、域解耦、跨系统协调

Introduction

1. 研究对象：蜂窝网络的控制面协议

• 与 Internet 相比，蜂窝网络的控制面信令功能更复杂
• 这些协议采用分层结构，同时运行在网络设施和终端上
  • 提供移动性支持(MM)、无线资源控制(RRC)、数据和语音的会话管理(SM)等功能
• 分层结构如 Fig.1 中间部分所示：
  • L3 从上到下为 Connectivity Management / Mobility Management / Radio Resource Control
  • 下面是 L2 / L1
  • 

2. 研究问题：协议之间的交互

• 作者关注控制面上的一组关键组件，具体列表见 Table 2
  • 
• 核心观点：每个信令协议单独看可能设计得很好，但它们在网络中能否正确交互并没有保证
• 目标是：找出协议间通信时出现的问题

3. 两个挑战

• 系统封闭：
  • 运营商不开放信令交换数据，终端在正常使用时也拿不到
• 交互模式比 Internet 丰富： 除了跨层交互，还有另外两个维度：
  • 跨域： 为了同时支持数据和运营商级语音，CS 和 PS 两个域都要用，信令协议需要同时管理两者
  • 跨系统： 3G/4G 混合部署、用户移动、CSFB 通话都会导致 3G↔4G 切换，信令协议需要跨系统工作
• 三个维度对应 Fig.1 右侧的编号 ① ② ③：
  • ① 跨层：上下层之间，例如 EMM 与 4G-RRC
  • ② 跨域：CS Domain 与 PS Domain 之间
  • ③ 跨系统：3G PS 与 4G PS 之间
  • 

CS 和 PS 什么意思? 分别表示什么含义?

缩写	英文	中文	词的拆解
CS	Circuit Switched	电路交换	circuit = 电路（一条专用线路），switched = 交换（在交换节点上把线路接通或转发）
PS	Packet Switched	分组交换	packet = 分组（国内计算机网络教材一直把 packet 译作"分组"），switched = 交换

问题 1：为什么叫"电路"交换

这个名字来自早期电话网：

• 打电话时，交换机（最早是接线员手动插线）真的在 主叫 和 被叫 之间接通一条物理电路
• 通话期间这条线路一直归你独占。挂断后线路拆掉，给别人继续用

后来网络数字化了，"电路"不再是物理铜线，而变成了专用的、固定速率的逻辑通道，比如 TDM 中的一个固定时隙，或 3G 里一条 12.2 kbps 的专用语音信道。

但核心特征没变：先建立连接，并为这次通信预留固定资源，通话期间独占这份资源，结束后释放。

（2）CS 和 PS 的对比：

	CS（电路交换）	PS（分组交换）
资源分配	建立连接时预留固定资源，全程独占	不预留，数据切成分组，统计复用共享链路
转发方式	沿已建立的通道连续传输	每个分组存储转发
时延/速率	稳定、可预测	随负载波动
效率	静默时资源也被占着，浪费	高，有数据才占资源
适合	实时语音	突发性数据（上网）
类比	包下一整条车道	所有车辆共用道路

4. 方法：CNetVerifier（详见 §3）

• 在模型检查方法中加入蜂窝网络特有的启发式规则
• 同时在终端上插桩，采集协议 trace 用于验证

5. 发现：两类问题、六个实例（汇总见 Table 1）

• 第一类：必要, 但当前有问题的协作 (§5)
  • 这类交互是必需的，驱动因素有三：运营商级语音、混合部署下的跨系统切换、移动性管理
  • S1: 4G 的关键上下文被共享，但没有保护，跨系统切换后被删除，导致暂时断网
  • S2: 上层协议对下层做了不现实的假设，用户刚被接入就被拒绝
  • S3: CS 和 PS 域的策略不一致，4G 用户卡在 3G
• 第二类：本应独立, 当前却被耦合的操作 (§6)
  • S4: 跨层动作被不当关联和排优先级，外呼因不必要的位置更新而延迟
  • S5: 两个域共用信道，PS 数据速率下降 51%–96%
  • S6: 一个系统的失败传播到另一个系统，导致断网

Background

1. 网络架构：基站 + 核心网

• 基站（BS）为终端提供无线接入; 核心网把终端连接到有线 Internet 或公共电话网 (Telephony Network)
• 4G LTE 只提供 PS 数据服务，其核心网有三个元素:
  • 4G Gateways：在 Internet 和 4G 基站之间路由 PS 数据包
  • MME：管理用户移动性，例如位置更新、寻呼（paging，即网络找到某个 UE 以便投递来电或下行数据）
    • MME: Mobility Management Entity
  • HSS：存储用户签约信息
    • HSS: Home Subscriber Server
• 3G 同时支持 CS 和 PS，其核心网有三个元素:
  • 3G Gateways：转发 PS 数据包
  • MSC：负责寻呼并建立 CS 业务（即语音通话）
    • MSC: Mobile Switching Center
  • HSS：与 4G 的作用相同

2. 协议分层：数据面 + 控制面

• 与 Internet 一样采用分层结构:
  • 数据面: 负责实际的数据和语音传输
  • 控制面: 提供信令功能, 支撑数据面
• 控制面在 L3 分为三个子层，自上而下是:
  • CM（Connectivity Management）：创建和管理语音通话、数据会话
  • MM（Mobility Management）：位置更新，以及为通话和数据会话提供移动性支持
  • RRC（Radio Resource Control）：控制无线资源，并负责传递信令消息
• Fig.1 右侧给出每个子层在 3G CS、3G PS、4G PS 中的具体协议，与 Table 2 对应：
  • 

3. 四类主要过程

1. Attach / Detach

   • 终端开机后必须先 attach，才能使用任何业务。唯一例外是紧急呼叫
   • Attach 由 MM/GMM/EMM 执行: 两端分别是 UE，以及 MSC / 3G GW / MME
     • Attach 成功后终端处于 registered 状态
   • Detach 可由 UE 发起（如关机），也可由网络发起（如资源受限）
     • Detach 后终端进入 deregistered 状态，也就是"out-of-service"，无法使用任何业务
   • 后文 S1、S2、S6 的后果都是 UE 被 detach

2. 数据与语音业务

   • 数据： 终端必须先与核心网建立承载（bearer）
     • 4G 叫 EPS Bearer activation，由 ESM 负责
     • 3G 叫 PDP Context activation，由 SM 负责
   • bearer 建立成功后: 核心网分配 IP 地址、按 QoS 预留资源、建立路由路径
   • 这些关键信息（IP、QoS 参数) 保存在UE和GW两侧的 PDP context 或 EPS bearer context 中
   • 语音：
     • 3G 走 CS，由终端和 MSC 上的 CC 协议处理
     • 4G 原设计是走 PS 的 VoLTE
       • 但因为 VoLTE 部署成本高、复杂，多数运营商采用 CSFB [CSFB (CS Fallback)-based calls]
       • 即: 打电话时把 4G 用户切回 3G 使用 CS 语音

3. 无线资源控制（RRC）

   • 已建立的 RRC 连接是终端与核心网之间任何通信（数据、语音、信令）的前提
   • 用状态机管理，两个主状态是 RRC_IDLE 和 RRC_CONNECTED
   • 为了优化资源和节能，CONNECTED 下还有子状态：
     • 3G：FACH（低速、省资源和电量）与 DCH（高速、耗资源）
     • 4G：连续接收，以及短/长 DRX（非连续接收，UE 周期性休眠以省电）
   • 后文 S3 的 "卡在 DCH" 就基于这里的状态机

4. 移动性管理

   • 系统内切换（intra-system handover）： 终端留在 3G 或 4G 内移动，并做位置更新：
     • 3G CS：LAU (location area update)，通过 MSC
     • 3G PS：RAU (routing area update)，通过 3G GW
     • 4G：TAU，通过 MME
   • 跨系统切换（inter-system switch）： 在 3G 和 4G 之间切换。切换成功后，再用上面对应的过程向新网络更新位置。
   • 分工：移动性逻辑由 MM/GMM/EMM 实现，底层无线接入的切换（信道建立和拆除）由 3G/4G RRC 处理。

终端必须先与核心网建立 bearer. 为什么? bearer 具体是什么?

Bearer（承载）是网络在 UE 和"出口网关"之间建立的一条带 QoS 属性的逻辑"管道"

UE 的 IP 数据只能在这条管道里走

以 4G 为例，一个 EPS bearer 从 UE 延伸到 P-GW（通往 Internet 的出口网关），由三段拼成：

UE ──[无线承载]── eNB(基站) ──[S1 承载]── S-GW ──[S5/S8 承载]── P-GW ── Internet
     (空口信道)                (GTP 隧道)            (GTP 隧道)

• 空口那一段是 RRC 建立的无线承载
• 核心网里的两段是 GTP 隧道：
  • 用隧道 ID（TEID）标识，本质上是 IP-in-UDP 封装

用大家熟悉的概念类比，bearer 大致等于：

PPPoE 拨号会话（先认证、再拿到 IP，之后才能上网）+ 一条带 QoS 的隧道 / 虚电路（类似 MPLS LSP）。

Bearer context（承载上下文） 就是描述这条管道的状态，UE 和网关各存一份，包括：IP 地址、QoS 参数、隧道端点 ID 等。 3G 中对应的概念叫 PDP context，是同一回事。

建立过程 - 4G 简化版

1. UE → MME： 发起请求（在 4G 里随 Attach 一起发起）
   • 目的是: 告诉网络"我要用数据"
2. MME → S-GW/P-GW： 请求创建会话
   • P-GW 分配 IP，网关之间建立 GTP 隧道并交换 TEID
   • 目的是: 建立核心网段的转发状态
3. MME → eNB → UE： 下发 QoS 参数和 IP
   • eNB 通过 RRC 与 UE 建立无线承载
   • 目的是: 打通空口这一段
4. *UE 确认：
   • 此后 UE 和网关两端都持有 bearer context，数据可以流动

---

因此:

UE 本来没有 IP。IP 由出口网关 P-GW 分配，并锚定在 P-GW 上。 Internet 发给 UE 的包，都会先路由到 P-GW

没有 bearer，UE 就没有 IP 地址，数据面根本无法寻址

• 包到达 P-GW 后，P-GW 要知道该发往哪个基站。这靠的就是 bearer 的隧道状态
• UE 移动换基站时，只需更新隧道端点，IP 地址不变，上层的 TCP 连接不会断
• 所以 bearer 本质上是"移动场景下 保持 IP 不变 的转发路径"

Methodology

总体思路：两阶段诊断

CNetVerifier 要找两类问题：

• 设计缺陷： 源自 3GPP 标准本身。
• 运营失误： 源自运营商的配置和实践。

对应两个阶段：

• 阶段 1：协议筛查（Protocol Screening，Fig.2 上半部分）。
  • 用模型检查在协议逻辑上搜索可能的设计缺陷，每找到一个缺陷就输出一个反例。
• 阶段 2：实测验证（Validation，Fig.2 下半部分）。
  • 针对每个反例搭建实验场景，在真实运营网络上测量，确认问题是否存在。

为什么两个阶段都需要：

• 阶段 1 找到的问题来自标准，与具体实现和测量无关。它的反例还能告诉你实验该怎么配置。
• 只靠阶段 2 找不全问题，因为结果依赖于你恰好测到了什么。
• 阶段 2 的作用是确认设计缺陷真实存在、评估影响，并额外发现运营失误和实现 bug。

作者承认的局限（§3.1）

1. 只关注控制面交互，数据面被简化了，例如忽略分组传输时间和通话时长。
2. 检查的性质都从用户视角定义，基站和核心网内部运营商关心的问题可能发现不了。
3. 使用场景靠随机采样，对参数敏感的缺陷可能被漏掉。提高采样率可以缓解。
4. 网络访问受限，部分发现无法实测验证，例如 S2。作者无法确定 S2 是罕见还是根本不是真实缺陷。
5. 实验主要围绕阶段 1 的反例设计，所以运营失误不一定能找全。

阶段 1：领域定制的协议筛查（§3.2）

工具基于 Spin 实现（Spin 是经典的模型检查器，会穷举并发状态机的所有交错执行，检查是否违反给定性质）。

需要解决三个问题：怎么建模、检查什么性质、怎么检查。

3.1 建模（§3.2.1）

(a) 协议栈建模

• 依据 3GPP 标准（TS24.008、TS24.301、TS25.331、TS36.331）建模，覆盖的协议见 Table 2
  • 
• 每个协议建模为两个 FSM：一个在 UE 侧，一个在对应的网络实体侧
  • 例如 CM/MM 在 MSC，SM/GMM 在 3G 网关，ESM/EMM 在 MME，RRC 在基站
• 对应 Fig.2 中 Cellular Standards → Protocol Model

(b) 使用场景建模（更难，对应 Fig.2 中 Common Demands → Usage Scenarios）

• 难点：标准没有正式定义使用场景，它们取决于用户需求和运营策略，而且组合无穷多，没法全部枚举。
• 处理方式：
  • 有限选项全部枚举：开关机、各类 accept/reject、所有跨系统切换方式。
  • 无限选项随机触发：移动速度、CS/PS 业务到达模式等，由一个运行时信号发生器随机激活。
  • 可配置参数随机初始化。
  • 采样率越高，暴露的缺陷越多。
• 用户侧：
  • UE 同一时刻只接入 3G 或 4G 之一，这是大多数手机的实际情况。
  • 开机后随机 attach 到 3G 或 4G。
  • 之后信号发生器随机产生用户事件：发起语音或数据、位置变化、用户主动 detach（关机）。
• 网络侧：
  • 对用户请求，accept 和 reject 都要测，reject 还要覆盖所有错误原因（仅 4G attach 就有 30 多种）。
  • 同时随机产生网络侧事件，例如跨系统切换、网络发起的 detach。

协议模型和场景模型合起来，就是 Fig.2 中的 Network Model。

3.2 定义性质（§3.2.2，对应 Fig.2 中 Cellular-specific Properties）

性质代表用户能感知到的服务，共三条：

• PacketService_OK：
  • attach 后，只要没有被显式去激活，数据服务就应一直可用。
• CallService_OK：
  • 通话服务应一直可用。没有用户的显式操作（如挂断），呼叫请求不应被拒绝或延迟。
• MM_OK：
  • 3G 和 4G 都可用时，跨系统切换请求应被满足。

只检查跨系统移动性，是因为系统内移动在实践中已经足够成熟。这三条性质在模型中作为 PS、CS、移动性状态上的逻辑约束。

3.3 性质检查（§3.2.3，对应 Fig.2 中 Model Checker）

1. 把所有协议的 FSM 交错组合，生成完整状态空间。
2. 违反三条性质的状态标记为 "error"。
3. 从初始状态（UE 尝试 attach 到 3G 或 4G）出发，在各种使用场景下做 DFS。
4. 一旦到达 error 状态，就输出一个反例，记录违反的性质。

输出分两种：Property Satisfaction，或 Property Violation + Counterexamples。后者交给阶段 2。

4. 阶段 2：基于手机的实测验证（§3.3）

核心难点：拿到协议 trace。

核心网是黑盒，运营商不提供数据。

解决办法：从终端侧采集。

• 利用 modem 厂商（高通、联发科）提供的调试模式，配合 QXDM、XCAL-Mobile 等工具抓 trace。对应 Fig.2 中 User Device + Trace Collector。
• 每条 trace 记录 5 项：
  1. 时间戳（毫秒级）
  2. trace 类型（如 STATE）
  3. 所在系统（3G/4G）
  4. 产生该 trace 的模块（如 MM、CM/CC）
  5. 事件描述（如"通话已建立"）

自动化测试工具：

• 自动拨出、接听、挂断电话，用于产生 CS 信令。
• 反复开关数据业务，用于产生 PS 信令。
• 用 Speedtest 测量上下行速率。
• 每个实验默认跑 10 次。

Overview of Findings

1. 发现的来源与定位

• 所有发现汇总在 Table 1 中
  • 
• 作者通过两条途径识别问题
  • 查阅标准规范，找出设计问题
  • 分析采集到的协议 trace，推断运营失误
• 来源分两个阶段
  • S1–S4 在筛查阶段（模型检查）发现
  • S5、S6 在验证阶段（实测）额外发现，属于运营问题
• CNetVerifier 实际还发现了其他问题，但它们不属于"协议交互"问题，所以没有写进论文
• 这些问题不全是运营失误，因此不能只靠更新实现来修复。设计问题需要修订 3GPP 标准

2. 按"交互是否必要"分为两类

对应 Table 1 的 Category 列

类别	含义	实例
必要但有问题的协作（necessary yet problematic cooperations）	这些交互本身是必需的，但执行时出错	S1、S2、S3
独立却被不必要耦合的操作（independent yet unnecessarily coupled operations）	这些协议本不需要交互，实际却发生了交互并带来负面影响	S4、S5、S6

两类问题的后果都是功能错误或性能下降。

3. 按交互维度组织

对应 Fig.1 右侧 ①②③ 与 Table 1 的 Dimension 列

两类问题在三个维度上都有出现，每个维度各有两个实例：

维度	必要但有问题	独立却被耦合
① 跨层	S2	S4
② 跨域	S3	S5
③ 跨系统	S1	S6

① 跨层：分层原则没有被遵守

上下层协议通过层间接口直接交互。

• S2（§5.2）：
  • 下层 RRC 不能提供上层 EMM 所需要的可靠、有序的信令传递。
  • EMM 本应自己实现端到端的可靠机制，却没有实现。
  • 结果：信令丢失或延迟后，EMM 做出错误反应，刚接受用户接入就又将其拒绝。
• S4（§6.1）：
  • 3G 中 CM/SM 与 MM/GMM 处在不同层，本应独立并发地处理外呼/数据请求和位置更新。
  • 实际上位置更新被赋予了更高优先级，造成队头阻塞，外呼和数据请求被无谓地延迟。

② 跨域：两个域被"一视同仁"

CS 和 PS 是面向不同域的协议变体，它们通过共同的下层协议（如 RRC）间接耦合在一起。

两个域的需求本不相同：数据要高吞吐，语音要及时交付，理应区别对待。

但在下面两个实例中，两个域的流量都被做了相同处理：

• S3（§5.3）： RRC 对 CS 和 PS 的聚合流量只维护一个状态
  • CS 通话结束后，PS 数据会话仍然让 RRC 停留在连接态，结果卡在 3G 回不到 4G
• S5（§6.2）： 运营商用 RRC 把 CS 和 PS 放在同一个共享信道上，并使用同一种调制方式，导致 PS 数据速率大幅下降

③ 跨系统：共享状态与失败信息处理不当

3G↔4G 切换时，两个系统需要共享甚至依据某些状态采取行动。

• S1（§5.1）： "正确的信息应被妥善保护和共享"这一面没做到。
  • PDP context（3G）和 EPS bearer context（4G）是数据服务的必要状态，但在跨系统切换中没有得到保护。
  • 3G 可能删除 PDP context，回到 4G 后无法恢复 EPS bearer，用户断网。
• S6（§6.3）： "失败处理应限定在系统之间"这一面没做到。
  • 3G 和 4G 共享位置更新失败的信息，这本身没问题，但处理动作本应只发生在 3G/4G 各自的网络以内。
  • 实际上 4G 在处理 3G 传来的失败信号时，直接对 UE 采取了动作，用户因此失去网络接入。

Improper Cooperation

本节主题： 三个"必要但有问题的协作"实例 S1–S3，分别对应跨系统、跨层、跨域+跨系统三种情形

每个实例都按同一结构展开：现象 → 过程 → 根因 → 实测验证 → Insight

5.1 S1：3G/4G 共享上下文缺乏保护（跨系统）

现象： UE 从 3G 切回 4G 时（例如 CSFB 通话结束，或漫游回到 4G 基站），可能暂时断网，持续几秒到几十秒，而且在实际中相当常见。

涉及协议： 3G 的 SM/GMM，4G 的 ESM/EMM。

(1) 正常的跨系统切换（§5.1.1）

切换发生的三种场景：

• 3G/4G 混合部署下，UE 离开当前系统的覆盖范围，进入另一系统，之后又回来；
• CSFB 通话：开始时 4G→3G，结束后 3G→4G，一共两次切换；
• 运营商为负载均衡等目的主动发起切换。

数据上下文如何迁移： 如果移动数据开着，切换时 PDP context 和 EPS bearer context 会相互转换并保持一致，例如 IP 地址在切换前后保持不变。

4G→3G 的信令流程

如 Fig.3 所示，图中圆圈编号对应步骤；采用的是 "RRC connection release with redirect" 机制）

1. ① 4G RRC → EMM
   • UE 的 4G RRC 收到基站命令，断开与 4G 基站的 RRC 连接，并通知 EMM
2. ② 3G RRC → MM 与 GMM
   • 3G RRC 利用上一步命令中携带的信息，连接到 3G 基站，然后通知 MM（CS 域）和 GMM（PS 域）
   • MM 和 GMM 随即分别在 CS、PS 域发起位置更新
   • 如果之前在 4G 有数据业务，网关和 MME 会在位置更新过程中把 EPS bearer context 转换成 PDP context，转换完成后释放 4G 侧预留的资源
3. ③ MM/GMM → EMM
   • 通知 EMM 切换成功

3G→4G 的流程类似： PDP context 在 4G 的位置更新（TAU）过程中被迁移回 EPS bearer context

(2) 问题过程（§5.1.2，违反 PacketService_OK）

1. UE 在 4G，已激活 EPS bearer
2. 切换到 3G，4G 侧的 EPS bearer 被删除以释放资源
3. 在 3G 期间，PDP context 因各种原因被去激活，原因见 Table 3
   • 
4. 切回 4G 时，因为 4G 只支持 PS，要求必须有 EPS bearer，而此时没有可迁移的上下文，UE 无法注册
5. UE 自行 detach，进入 out-of-service

(3) 根因分析：三个角度

为什么 3G 会删除 PDP context？

• 在 4G，EPS bearer 是数据和信令交换的必需品，无法建立就不提供任何服务
• 在 3G，PDP context 不是必需的：没有它照样能用 CS 打电话
• 因此 3G 中去激活 PDP context 很常见，网络和 UE 都可以发起
  • Table 3 列出的原因有：资源不足、QoS 不被接受、底层失败、常规去激活、上下文不兼容、运营商禁止

影响有多严重？

• 大多数手机是单射频，同一时刻只能接入一个网络
• 被 4G detach 后，UE 既用不了 4G 也用不了 3G
• UE 会反复尝试重新注册 4G，直到达到最大重试次数，之后才会转去尝试 3G

能否消除？ 能。因为这是设计缺陷，有两种修法：

1. 不必总是删除 PDP context：
   • "QoS not accepted"：可以改用较低的 QoS，而不是删除
   • "Incompatible PDP context"：可以修改上下文，而不是删除
   • "Regular deactivation"：可以保留到成功切回 4G 之后再删
2. 即使删除了也不必 detach：
   • UE 在 4G 仍处于注册状态，可以直接重新激活一个 EPS bearer

Warning

Insight 1： 在不同系统间共享的上下文，各系统对它的操作和策略必须一致，否则就会出现跨系统问题。

5.2 S2：层间通信中的乱序信令（跨层）

涉及协议： 4G 的 EMM 与 RRC

核心矛盾： EMM 依赖 RRC 传递信令，并假设传递是可靠、有序的，但 RRC 并不提供这种保证。更糟的是，EMM 的设计完全没有考虑信令丢失或延迟的情况

结果： UE 刚 attach 成功就被从 4G 上 detach

(1) 问题过程（§5.2.1，违反 PacketService_OK）

UE 在收到 attach reject 或位置更新 reject 后，会进入 deregistered 状态。具体有两种情形。

情形 (a) 信令丢失（如 Fig.5(a) 所示）：

1. UE 的 EMM 向 MME 发送 Attach Request
2. MME 回复 Attach Accept
3. UE 建立 EPS bearer，回复 Attach Complete
   • 这条消息经 RRC 发往基站时在空口丢失（图中 × 处）
   • 此时 UE 认为 attach 已成功，MME 认为尚未完成，两端状态不一致
4. 之后触发 TAU（4G 的位置更新），UE 发送 TAU Request
5. MME 认为 attach 还没完成，不处理这个请求，以 "implicitly detach" 拒绝，并删除 EPS bearer
   • UE 收到拒绝后，只能自行 detach

情形 (b) 信令重复（如 Fig.5(b) 所示）：

1. UE 经 BS1 发出 Attach Request。BS1 负载较重，延迟了转发
2. UE 移动到 BS2，因超时未收到回复而重传 Attach Request
3. MME 回复 Attach Accept
4. UE 发送 Attach Complete，双方都完成 attach
5. 这时经 BS1 延迟的旧请求终于到达 MME。按标准，MME 会删除 EPS bearer 并重新处理这个请求：
   • 如果拒绝: UE 断网
   • 如果接受: 需要重建 EPS bearer，重建期间数据服务不可用

MME 这样处理有它的道理

• attach 未完成时，没有理由继续保留 bearer
• 在已注册状态下收到新的 attach 请求必须重新处理，因为可能是 UE 之前没电关机、现在重新开机，只有重新处理才能恢复两端的一致

(2) 两个根因

1. EMM 本身没有为乱序信令做准备： 它假设下层可靠有序，设计中没有考虑丢失和重复
2. 端到端（UE → 多个基站 → MME）的可靠传递本来就无法保证：
   • 即使 UE 到基站、基站到 MME 每一跳都是可靠的，在移动过程中信令可能经由两个不同的基站中继，到达 MME 时仍可能失去原有顺序

Warning

Insight 2： 在跨层交互中，上层协议的关键功能不应仅仅依赖下层那些"并不总能保证"的特性，否则就要承担失败的风险。

5.3 S3：跨域/跨系统协议状态转换不一致

现象： 4G 用户打完 CSFB 电话后，如果仍有高速数据会话，会卡在 3G，失去 4G 连接和高速接入。这与用户是否在移动无关，也违背了 CSFB 的设计初衷（通话结束后应回到 4G）。

与作者前作的关系： 这是对 [27] 的补充。[27] 只发现了低速数据下的类似问题。

根因： RRC 在跨系统切换过程中同时处理 CS 语音和 PS 数据，状态转换不一致。

(1) 问题过程（§5.3.1，违反 MM_OK）

问题发生时有两个现象：PS 数据会话仍在进行（PDP context 处于激活状态）；3G RRC 处于 FACH 或 DCH（即连接态）。

三种跨系统切换方式（如 Fig.6(a) 所示，三种线型分别对应三种方式）：

方式	Fig.6(a) 线型	适用状态	特点
RRC connection release with redirect	红色点线	从非 IDLE 态出发	先强制释放 RRC 连接再切换，能回到 4G，但会中断数据
Inter-system handover	绿色实线	3G DCH ↔ 4G CONNECTED 直接转换	减少数据中断，但运营商开销大（需要缓存、转发分组）
Inter-system cell reselection	蓝色虚线	仅 IDLE 态	由 UE 发起，寻找更好的 3G/4G 小区

3GPP 标准允许运营商在这三种方式中自由选择

CSFB + 高速数据下的状态转换（如 Fig.6(b) 所示）：

1. ① CSFB 通话开始，由于有高速数据，RRC 从 4G CONNECTED 迁移到 3G DCH
2. ② 3G CS 域的通话结束，但高速数据仍在进行，RRC 停留在 DCH
3. 如果运营商选用的是 inter-system cell reselection（只在 IDLE 态触发），UE 就会一直卡在 3G，直到数据会话结束

(2) 深层原因

• RRC 状态由 CS 语音和 PS 数据共同决定
  • CS 和 PS 两个域不直接交互，但都依赖 RRC 进行控制，共享同一个 RRC 状态
  • 所以两个域之间的信令交互是通过 RRC 间接完成的
• 这种跨域交互本身是必要的：通话进行时，PS 数据必须留在 3G；只有通话结束后才能迁回 4G
• 运营商没有责任，它们遵守了标准。 选择 cell reselection 也是合理的：
  • 由 UE 触发，网络不必监控每个 CSFB 通话的状态，负载更低；
  • 不中断正在进行的数据会话。
• 根本问题在于 3G/4G 标准没有设计出能够处理所有跨域、跨系统场景的健壮 RRC 协议

Warning

Insight 3： 原本设计良好的功能，在启用新功能（这里是 CSFB）后可能变得容易出错。设计选项应经过审慎论证、测试和规范；否则，各种不受规范约束的选项选择可能抵消原本想要的好处。

Problematic Coupled Actions

本节主题： 三个"本应独立、却被不必要耦合"的实例 S4–S6，分别属于跨层、跨域、跨系统

• S4 是设计问题；S5、S6 是运营问题（S6 也部分源于标准没有规定清楚）
• 每个实例的结构依次为：现象 → 过程与根因 → 实测 → Insight

6.1 S4：独立的位置更新造成队头阻塞（跨层，3G）

现象： 3G 中，底层正在做位置更新时，上层发起的外呼或数据请求会被延迟，也就是出现 HOL（队头）阻塞

涉及协议： CS 域是 CM/MM，PS 域是 SM/GMM

(1) 背景：位置更新是什么、何时触发

• 作用： 网络必须知道 UE 的位置，才能把来电（inbound）路由给它。
• "位置区 / 路由区"： 由若干小区组成的区域。网络按区域寻呼 UE，UE 跨越区域边界时要向网络报告。
• 触发场景见 Table 4，共 6 种：
  • 跨位置区、周期性位置更新、CSFB 通话结束 → 位置区更新
  • 跨路由区、周期性路由更新 → 路由区更新
  • 切换到 3G 系统 → 两种都要做
  • 
• 执行者：
  • CS 域："UE 上的 MM" 向 MSC 发起位置区更新（LAU）。
  • PS 域："UE 上的 GMM" 发起路由区更新（RAU），由 3G GW接受或拒绝。

(2) 问题过程

1. UE 的 MM 正在执行位置更新。
2. 用户发起外呼，CM 向 MM 发送 CM service request，用于在 UE 与 MSC 之间建立呼叫所需的信令连接。
3. 按标准，MM 正在做位置更新时，这个请求会被延迟，甚至被拒绝。
4. PS 域的 GMM 与 SM 之间存在同样的问题。

注意：本例中外呼请求和位置更新都是由 UE 发起的

(3) 为什么说这种优先级"看似合理、实则没有依据"

• 看似合理的理由： 位置不更新，别人就找不到这个 UE，所以位置更新应当优先
• 实际上站不住：
  • 外呼和数据请求是出站（outbound）方向，UE 随时都能发出，不依赖网络知道它在哪
  • 如果先处理呼叫请求，MSC 在处理呼叫时会顺带隐式更新 UE 的位置，而且不需要额外资源
  • 因此，无论先处理哪个，来电都不受影响，位置更新没有必要加急
• 结论：
  • 上层 CM/SM 的业务请求与下层 MM/GMM 的位置更新本来相互独立
  • 人为地把它们关联起来并排定优先级，只会给用户请求增加不必要的时延

Insight 4： 上下层的某些过程看起来相互独立，实际上会因为执行顺序而耦合在一起。设计不够审慎时，就可能出现 HOL 阻塞。

WHY: 处理外呼请求时, 网络会顺带知道 UE 的位置

(1) 位置更新到底是为了什么

关键点：网络只在 UE 空闲时才需要 "位置区" (Location Area, LA) 信息

手机有两种状态：

• 连接态：
  • 正在通话或传数据，和某个基站之间有活跃的无线连接
  • 网络精确知道它在哪个小区，UE 移动时通过切换持续跟踪
• 空闲态：
  • 没有连接，处于省电状态
  • 网络不跟踪它具体在哪个小区

UE 空闲时如果有来电，网络必须先找到它。做法叫寻呼（paging）：在一片区域内的所有基站上广播"某某号码请回应"

• 这片区域就是位置区（Location Area，LA），由若干小区组成，用 LAI（Location Area Identity，位置区标识）编号
• 如果对每个小区都广播，开销太大
• 如果按小区跟踪每个空闲手机，手机每跨一个小区就要上报一次，又太费电
• 位置区是两者之间的折中

所以: 位置更新（LAU）的唯一目的，是让网络（具体是 MSC 和它的用户数据库 VLR）记住"这个用户当前在哪个位置区"，以便来电时知道该在哪片区域寻呼

一条 LAU 消息实质上告诉网络两件事：我是谁（用户标识）+ 我现在在哪个位置区（LAI）

(2) 外呼时，网络收到了什么

以 3G CS 域的外呼为例，UE 与网络之间的交互如下：

1. UE ↔ 基站： UE 在当前所在的Cell建立 RRC 连接
   • 这时基站就知道这个 UE 在自己的覆盖范围内
2. UE → MSC： UE 的 CM 通过 MM 发出 CM Service Request（TS 24.008 NAS Msg）
   • 消息里包含 UE 的身份标识（TMSI 或 IMSI）
3. 基站控制器（RNC）→ MSC： RNC 不会原样转发这条消息，而是把它装进 RANAP 协议的 Initial UE Message 中再发给核心网（TS 25.413）
   • 这条外层消息里，RNC 会填上 UE 当前所在的 LAI，以及更精确的服务区标识 SAI（小区级）

所以 MSC 收到外呼请求时，同时拿到了"这是谁"和"它在哪个位置区，甚至哪个小区"，也就是 LAU 要传达的全部内容

此外还有两点:

• 通话建立后，UE 处于连接态，网络按小区级精度跟踪它，根本不需要位置区信息
• 通话结束、UE 回到空闲态时，网络知道它最后是在哪个位置区结束连接的

这就是论文所说的"隐式位置更新"：出站请求本身就携带了位置信息，服务这个请求就等于完成了一次位置报告，不需要额外的资源。

(3) 4G 中的对应机制

4G 中也是同样的道理。UE 发起业务时，基站发给 MME 的 S1AP Initial UE Message（TS 36.413）同样携带 UE 当前的 TAI（跟踪区标识）和 E-CGI（小区标识）。MME 由此得知 UE 的位置，并把这个位置信息（ULI）传给网关。

(4) 一句话总结

Location Area Update 传递的是 "我是谁 + 我在哪"

而 UE 发起任何上行业务时，接入网都会在转发给核心网的初始消息里附上 UE 当前的位置区和小区标识

因此，一次外呼，天然就让网络知道了 UE 在哪里！在同一 MSC 范围内，先完成呼叫、再补做位置更新（甚至不做），并不会让来电找不到人

6.2 S5：语音与数据"命运共享"

"Fate Sharing" for Voice and Data

现象： 在 3G 中，同时使用 PS 和 CS 时，PS 数据速率比只用 PS 时显著下降

性质： 这是运营商实现层面的跨域耦合，不是标准的设计缺陷

(1) 测量结果

如 Fig.9 所示：(a)(b) 分别为 OP-I、OP-II 的下行，(c)(d) 分别为 OP-I、OP-II 的上行；横轴是一天中的不同时段，柱状图显示有无通话时速率的最大值、中位数和最小值。

• 语音和数据同时进行时，下行和上行速率都下降，只有 OP-I 的上行例外
• 两者竞争共享的无线资源，速率下降本身看似合理。但 3G CS 语音最高也只需 12.2 kbps，理应只造成轻微下降
• 实际下降幅度：
  • 下行：下降 3.5–5.8 Mbps，OP-I 约 73.9%，OP-II 约 74.8%
  • 上行：OP-II 下降达 96.1%；OP-I 观察到一次 51.1% 的下降

(2) 根因：不恰当的跨域信道共享

[1] 先解释调制方式： 调制决定每个符号携带多少比特

• 64QAM：每个符号携带 6 比特，速率高，但对信号质量要求高、更容易出错
• 16QAM：每个符号携带 4 比特，速率低，但更稳健

[2] 两个域的需求不同：

• CS 语音要求高韧性、低丢包，以保证及时交付并减少重传，所以偏好稳健的低阶调制，如 16QAM
• PS 数据追求高速率，偏好高阶调制，如 64QAM

[3] 运营商的实际做法：

• 两家运营商都通过 RRC 配置手机，让 CS 和 PS 流量走同一个共享信道，并使用同一种调制方式
• 调制方式的选择以先满足 CS 为准，代价由 PS 承担

Trace 证据（如 Fig.10 所示，这是 OP-I 的一段协议 trace，图中方框标出了 ON/OFF/ON 三个阶段）：

1. ON：通话前 64QAM 处于 Active，数据速率可达 21 Mbps
2. OFF：通话接通后，64QAM 变为 Inactive，最高调制降为 16QAM，理论下行速率降到 11 Mbps
3. ON：通话挂断后，64QAM 恢复为 Active，速率回到 21 Mbps

(3) 作者提出的替代方案

• 按域聚类共享：
  • 一个共享信道本来就可以由多个用户使用，每个用户用自己的调制方式，并随信号强度变化调整
  • 一个设备也可以使用多个信道
  • 因此，可以不再把同一设备的 CS 和 PS 绑在一起，而是：
    • 把多个设备的 PS 会话放在同一个信道上
    • 把 CS 会话聚在另一个共享信道上，使用相同的调制方式
• 或者让 CS 和 PS 各自采用自己的调制方式
  • 同时满足两者不同的需求

Insight 5： 两个域的目标和特性不同时，应尽可能解耦它们的服务，否则至少有一个域的需求会被牺牲

6.3 S6：3G 的失败传播到 4G 系统（跨系统，运营问题）

现象： 在实验中发现的跨系统耦合问题

• 涉及协议： 3G 的 MM 和 4G 的 EMM
• 场景： LTE 手机在 4G 打电话，使用 CSFB
• 过程概述：
  • CSFB 引起的系统切换中，3G 和 4G 都要做位置更新，而更新可能失败
  • 在两家运营商中，3G 的位置更新失败都会被传递到 4G，导致 4G 用户断网，运营商却没有从中得到任何好处
• 性质： 一部分是运营做法不当，一部分是标准没有规定这个过程该怎么处理
• 位置更新除了由用户移动触发，也会由周期性刷新或 CSFB 通话触发

(1) CSFB 中的两次 3G 位置更新

1. 第一次： 通话开始、完成 4G→3G 切换后，由 UE 发起
   • 标准允许把这次更新推迟到通话结束后再做 [5]，以减少在 3G 中建立通话的时延
2. 第二次： 通话结束、UE 切回 4G 后，由网络发起
   • 更新先由 4G 的 MME 处理，再由 MME 转发给 3G 的 MSC

因此，按照标准，一次 CSFB 通话会在 3G 中激活两次位置更新。

(2) 问题过程：两次中有一次是多余的，哪一次出问题取决于运营商

OP-I：第一次更新出问题

1. 被推迟的第一次更新，在通话结束时才开始执行
2. OP-I 切回 4G 很快，这次由 UE 发起的更新被中断
3. 这个"未完成"状态从 3G 传递到 4G，4G 向 UE 发送错误原因为 "implicitly detach" 的消息
4. UE 进入 out-of-service
   • 而实际上 3G 已经完成了第二次更新，第一次本来就不需要

OP-II：第二次更新出问题

1. OP-II 从 3G 切回 4G 比较慢，所以第一次更新先完成
2. 第一次成功后，MSC 可能会拒绝 MME 转发来的第二次更新，并向 MME 回复 "MSC temporarily not reachable"
3. 4G 随即向 UE 发送 detach request
4. UE 进入 out-of-service

(3) 根因：失败处理被暴露给了 UE

• 运营商的理由：
  • 如果 3G 位置更新失败，4G 用户可能会漏接来电，因为 CSFB 的来电要经由 3G MSC 路由
  • 所以：两家运营商都选择让 3G 和 4G 共享位置更新失败的信息，并据此采取行动
• 问题所在：
  • 这种错误处理应当限定在网络内部的 3G MSC 与 4G MME 之间，两者完全可以协作解决失败，而不应把处理动作施加到 UE 上
• 这是一种可以避免的错误做法

Insight 6： 不同网络中的同类功能应当相互协调以减少冲突。尤其是，一个网络的内部失败不应传播到另一个网络。

Solution

1. 总体框架：三个模块

Fig.11 按"终端 / 基站 / 核心网"三个位置，标出了三个修复模块各自插在协议栈的哪里：

模块	在 Fig.11 中的位置	解决的问题	核心思路
Layer Extension（层扩展）	终端侧：3G 中 CM/SM 与 MM/GMM 之间的虚线框；4G 中 EMM 下方的 "Layered Extension" 虚线框	S2、S4	补上下层缺失的功能；把被错误耦合的操作并行化
Domain Decoupling（域解耦）	基站侧：3G-RRC 上方的虚线框	S3、S5	在 RRC 中切断 CS 与 PS 两个域之间的相互干扰
Cross-system Coordination（跨系统协调）	核心网：MSC/3G Gateway 与 MME 之间的虚线框	S1、S6	3G 与 4G 共享信息并协作，不把问题推给 UE

这张表与三个交互维度正好一一对应：层扩展处理跨层问题，域解耦处理跨域问题，跨系统协调处理跨系统问题。

2. Layer Extension

S2 + S4

(1) 针对 S2：在 EMM 与 RRC 之间插入可靠传输层

• 问题回顾： EMM 假设底层传输可靠、有序，而 RRC 不提供这种保证。
• 做法： 在 EMM 和 RRC 之间插入一个轻量的 shim 层，由它提供可靠传输，确保手机与 MME 之间端到端、按序地交换信令。
• 兼容性： 这个 shim 层桥接 EMM 与 RRC 之间原有的接口，把可靠传输所需的信息封装在自己内部，不改动现有系统的其他部分。
• 与 Insight 2 的呼应： 下层不提供的功能，由新增的一层来补上，上层不再依赖下层做不到的保证。

(2) 针对 S4：把位置更新和业务请求并行化

• 问题回顾： MM/GMM 做位置更新时，会阻塞 CM/SM 发来的外呼和数据请求
• 做法： 在 MM（CS 域）和 GMM（PS 域）中，把位置更新与业务请求解耦。每个协议维护两个并行线程：
  • 线程 1：处理 Location Update
  • 线程 2：处理其余所有功能，包括外呼和数据等业务请求
• 优先级反转： 让业务请求优先于位置更新
  • 理由是业务请求在被服务时，网络会顺带隐式完成位置更新。

3. Domain Decoupling

S3 + S5

出发点： CS 和 PS 两个域是在 RRC 层耦合在一起的，所以解耦模块也放在 RRC 中。它的目标是消除一个域对另一个域不必要的干扰，包括 S3 中被另一个域阻塞的状态转换，以及 S5 中被迫降级的调制方式。

(1) 针对 S3：CSFB 结束后，回 4G 不再被 PS 域阻塞

• 原则： 一个域不应被另一个域约束
• 做法：
  • CS 域触发了 CSFB，那么通话结束时就应执行 3G→4G 切换。
  • 只要切换条件满足（例如 4G 可用），就执行切换，不因 PS 域正在进行的数据会话而被阻塞。
  • 实现方式： 基站给这次连接打上一个 CSFB 标记，用于辅助后续的跨系统切换。有了这个标记，RRC 就知道这次停留在 3G 是 CSFB 造成的，通话结束后应当回到 4G。

(2) 针对 S5：给 CS 和 PS 分配不同信道

• 做法： 3G RRC 为 PS 和 CS 业务分配不同的信道，这样两者就可以使用不同的调制方式，例如 PS 用 64QAM，CS 用 16QAM。
• 具体包括两件事： 先区分 CS 和 PS 流量，再为它们独立分配无线资源。
• 现有标准已经支持，不需要修改标准：
  • RLC 层可以根据流量来源区分语音和数据，因为 CS 和 PS 使用的是不同的模块和接口
  • 标准本身就允许给一个设备分配多个无线信道，并且每个信道可以单独配置

4. Cross-system Coordination

S1 + S6

出发点： 不同系统中的同类功能服务于相似的目的，只是各系统的实现方式略有不同，所以理应协调。关键有两点：

1. 系统之间共享信息
2. 系统之间协作，确保操作正确执行

(1) 针对 S1：删除一个 detach 条件（需要修改标准）

• 依据：
  • 4G 的 EPS bearer context 和 3G 的 PDP context 对数据服务同等关键
  • UE 在 3G 和 4G 之间切换时，两个系统应当保证状态正确过渡
• 建议：
  • 从标准中删除这样一个 detach 条件：没有激活 PDP context 的 UE 从 3G 切换到 4G 时，被要求 detach
• 替代行为：
  • UE 在 3G→4G 切换后立即激活 EPS bearer，而不是让自己 detach。这样就能保证系统切换无缝进行

(2) 针对 S6：失败由网络内部协助恢复，不把 UE 踢下线（需要修改运营做法）

• 原则： 一个系统出现失败时，另一个系统应尽可能帮助恢复
• 做法： 3G 位置更新失败时，4G 的 MME 不应 detach UE，而应代表 UE 与 3G MSC 完成位置更新的恢复
• 说明： 标准中并没有规定 MME 在 3G 失败时必须 detach UE，这是运营商自己的做法。因此作者建议运营商取消这种做法

5. 各修复方案需要改动的层面

问题	修复手段	需要改动的对象
S1	删除"无 PDP context 就 detach"的条件，改为直接激活 EPS bearer	3GPP 标准
S2	在 EMM 与 RRC 之间加入可靠 shim 层	协议栈（终端与 MME 两端）
S3	基站加 CSFB 标记，通话结束即切回 4G	基站的 RRC
S4	MM/GMM 双线程，业务请求优先	协议实现
S5	CS 和 PS 分信道、分调制	运营商配置（现有标准已支持）
S6	MME 不 detach，改为代 UE 向 MSC 恢复	运营商做法（标准未强制）