跳转至

Nervion: A Cloud Native RAN Emulator for Scalable and Flexible Mobile Core Evaluation

Nervion是一种用于评估移动核心系统的 云原生无线接入网络(RAN)模拟器

尽管存在各种 RAN 模拟器，但它们在 可扩展性和灵活性 方面存在局限性，并且缺乏一个公认的通用工具

Nervion 通过采用一种 新颖的云原生方法 解决了这些限制! Highlights🌟:

alt text

  1. User - Controller
    1. 启动 k8s
    2. 启动 nUE / nBS 这些 Elements
  2. Controller 两份责任
    • web-service: 让 user 访问
    • control-service: 根据用户给的 config files "呈现" 出需要的k8s环境
  3. Nervion Control Protocol (NCP)
    • Controller <-> Elements: UDP
    • nUE <-> nBS: TCP
  4. 把 UE 的 NF 重构: nUE负责数据, nBS主管控制信令
    • dataflow: nUE - Core (UE 直达核心网)
      • tricky 1: k8s 的 NAT 机制
      • tricky 2: "伪IP" + "GTP 建隧道" 形成 "UE可直达Core"
    • control-msg: nUE - nBS - Core (nBS 作为 relay)
  5. 用户根据 config json file 创建 k8s 环境
    • 4/5G 专有通信primitives -> general language -> event
    • 每个 nUE 有一个 TUN, 使得user客制化 traffic pattern

该系统支持 4G 和 5G 标准，并使用 Kubernetes 进行编排，从而能够灵活地创建和映射复杂的 RAN 仿真场景，以进行多样化的移动核心系统评估

本文也是经典的类型1论文, 行文框架参考
  1. Introduction
    1. 行业背景: "目前, RAN模拟是评估核心网的主流方法"
    2. 核心问题: "目前缺乏一个通用的、可扩展且灵活的RAN模拟器，以支持对不同移动核心网进行公平的对比评估"
    3. 解决方案: "Nervion"
    4. 评估效果, 突出贡献: "效果特别好, 贡献特别突出"
  2. Background
    1. 4G
    2. 5G
    3. 5G的虚拟化与云化趋势
    4. docker 和 k8s
  3. Nervion
    1. Targets && Challenges: General RAN 模拟器 + (可扩展/灵活性)
    2. Overview: UE重构 + 容器/k8s + 模块化RAN-Core + 用户客制化场景
    3. Detailed Design: module, system ...
    4. Implementation: workflow. data/ctrl ...
  4. Evaluation
  5. Related Work: 四种RAN类型, 都不能做到 general. 对比突出 Nervion
  6. Conclusions

Introduction 重点内容:

🎯 核心问题: 评估 Core Network 的挑战

  • 背景: Mobile CoreNet 是网络中处理关键控制功能(如会话、安全管理)和数据通信的组件。随着网络软件化和用例多样化的趋势，评估核心网变得至关重要
  • 评估方法: 目前，RAN(无线接入网)模拟是评估核心网(在可扩展性、响应性、鲁棒性等方面)的主流方法
  • 现有局限: 现有的RAN模拟器普遍存在四大缺陷.
    1. 可扩展性差(Scalability limitation)
    2. 灵活性不足(Inflexible)，例如依赖特定跟踪(Trace-based)或仅支持控制/数据平面之一
    3. 访问受限(Limited access)，如商业模拟器
    4. 功能绑定(Ad-hoc)，通常只为特定的核心网设计
  • 核心矛盾: 目前缺乏一个通用的、可扩展且灵活的RAN模拟器，以支持对不同移动核心网进行公平的对比评估

💡 解决方案: 云原生RAN模拟器 Nervion

本文设计并实现了一个名为 Nervion 的新型RAN模拟器，它采用 Cloud-Native 方法来克服现有方案的局限性

(1) 如何实现可扩展性

  • 抽象(Abstraction): Nervion 抽象掉了对核心网评估不重要的RAN内部协议和细节，从而实现了RAN元件(UE和BS)的轻量化
  • 重构(Refactoring): Nervion 重新设计了UE的功能
    • 将UE的控制平面功能(Control Plane)代理给其关联的基站(nBS)处理
    • UE自身(nUE)只处理数据平面(Data Plane)流量
  • 容器化(Containerization):
    • 基于上述重构, nUE和nBS可以被实现为独立的容器(Containers)
    • 并通过k8s, 按需在多个物理机或虚拟机上大规模部署和扩展

(2) 如何实现灵活性

  • 自定义模拟场景: Nervion 允许用户通过“模拟规范”详细定义评估场景
    • 包括: RAN元件的数量、配置，以及控制平面事件("用户定义的事件序列")和数据平面工作负载
  • 支持任意数据流量: 为每个 nUE 容器附加一个 TUN 设备
    • Nervion 允许研究人员使用任意应用程序(iperf / vlc ...)在UE上生成真实的数据平面流量
  • K8s 编排:
    • Nervion 依赖 Kubernetes (K8s) 来自动部署和管理容器化的RAN元件
    • 使得模拟场景可以轻松地在任何支持K8s的计算集群(本地集群/Powder平台)之间移植
  • 模块化接口:
    • RAN与核心网之间的接口是模块化的, 可以方便地替换, 以支持不同的接口标准 (甚至是过时或非标准的接口)

🔬 实施与评估

  • 原型实现: 作者开发了一个Nervion的原型, 支持4G和5G标准(兼容3GPP), 可同时模拟控制平面和数据平面(或仅控制平面)
  • 公开可用: 该原型已集成到 Powder 平台, 并提供了一个包含六种不同移动核心网(如OAI, Free5GC, Open5GS等)的配置文件, 便于社区复现和使用
  • 评估结果: 通过与OAI、srsLTE、OpenEPC和UERANSIM等代表性模拟器进行广泛比较, 实验证明 Nervion 在效率、轻量化和可扩展性方面均显著优于现有方案

🚀 贡献与用例

  • 用例展示: 本文展示了Nervion的多个评估用例, 包括:
    1. 对比六种不同核心网设计的可扩展性
    2. 研究不同核心网的控制平面延迟
    3. 灵活创建不同服务(如移动宽带和物联网IoT)的数据平面流量
  • 核心贡献: 本文提供了一个迄今为止最全面、通用的RAN模拟器, 它通过云原生的设计, 为社区提供了一个可扩展、灵活且高保真的移动核心网评估工具

Background 重点内容:

🧬 4G (LTE) 架构: EPC

alt text

  • 基本构成: 4G 网络由 RAN(无线接入网)和核心网(EPC)组成. RAN 中的 eNB(基站)负责连接 UE(用户设备)到 EPC
  • EPC 核心组件:
    • MME (Mobility Management Entity):
      • 移动管理实体. 负责控制平面功能, 如身份验证、会话和移动性管理
    • HSS (Home Subscriber Server):
      • 归属用户服务器. 存储用户身份信息的中央数据库
    • SGW/PGW (Serving / PDN Gateway):
      • 服务网关/PDN 网关. 合称 SPGW. 负责处理用户数据流量, 并将 EPC 连接到外部互联网
      • PS: PDN 表示的是 Packet Data Network, 分组数据网络, 可以理解成 5G 里的 "UPF"
  • 关键接口 (S1):
    • S1-C (控制平面): MME 和 RAN 之间的信令接口 (S1AP 和 NAS 协议)
    • S1-U (用户平面): SPGW 和 RAN 之间的数据接口 (GTP/UDP 协议)
4G Net 名词汇总
  1. EPC: Evolved Packet Core. 就是 CoreNet in 4G
  2. eNB: eNodeB. 就是 Base Station in 4G
  3. MME: Mobility Management Entity
  4. HSS: Home Subscriber Server
  5. SPGW: Serving && PDN Gateway
  6. GTP: GPRS Tunneling Protocol. 基于 UDP
  7. S1AP: S1 Application Protocol
  8. LTE: Long Term Evolution

🚀 5G 架构: NGC

alt text

  • 核心特性: 5G 核心网(NGC)采用了新的架构，其关键特性包括:
    1. 控制与数据平面分离 (CUPS)
    2. 更彻底的功能分解 (Disaggregation)
    3. 采用服务化架构 (SBA)
  • 功能映射 (4G vs 5G):
    • MME 对应 AMF (接入和移动性管理功能)
    • HSS 对应 UDM (统一数据管理)
    • SPGW(控制部分) 对应 SMF (会话管理功能)
    • SPGW(数据部分) 对应 UPF (用户平面功能)
  • 关键接口 (N2/N3):
    • N2 (控制平面): RAN (gNB) 和 NGC (AMF) 之间的接口 (NGAP 协议)
    • N3 (用户平面): RAN 和 UPF 之间的数据接口 (GTP/UDP)
5G Net 名词汇总
  1. NGC: Next Generation Core. 就是 5G 的 CoreNet
  2. gNB: gNodeB. 就是 Base Station in 5G
  3. SBA: Service-based Architecture
  4. AMF: Access and Mobility management Function
  5. UDM: Unified Data Management
  6. SMF: Session Management Function
  7. UPF: User Plane Function
  8. NGAP: Next Generation Application Protocol

💡 变革的驱动力: 替代核心网设计

  • 背景: 传统的 4G EPC 架构在面对设备规模增长、服务多样性、新的接入模式以及网络软件化(虚拟化和云化)趋势时，暴露了局限性.

  • 研究方向:

    这些局限性催生了对“替代核心网设计”的研究，其目标包括:

    • 解决可扩展性、延迟和可靠性问题
    • 利用 SDN 和 NFV(网络功能虚拟化)
    • 支持在 云环境 或 边缘 部署核心网

🔧 核心使能技术: 容器与 K8s

  • 容器:
    • 定义: 一种轻量级的操作系统虚拟化技术 (e.g. Docker)
    • 作用:
      • 它将应用程序及其依赖项打包隔离, 使其可以在任何地方运行
      • 与虚拟机 (VM) 相比，它避免了管理整个操作系统的开销
  • Kubernetes:
    • 定义: 一个开源的容器编排系统
    • 作用:
      • 用于在计算集群上自动部署、扩展和管理容器化应用程序
      • 它通过 Pod、Service 等抽象概念，实现了 "主-从"(Master-Slave) 架构的资源控制和调度

Nervion 重点内容:

🎯 设计目标与挑战 (3.1)

本章节的核心目标是设计一个 Scalable + Flexible 的 RAN 模拟器, 用于评估移动核心网

  1. 可扩展性 (Scalability)
    • 目标: 需要能够模拟大规模的 RAN 场景 (大量 UE 和高负载)
    • 挑战:
      • 在 "仿真规模[usability]" 与 "仿真真实性[fidelity]" 之间做出权衡
      • 利用多台机器/进程来扩展模拟规模
  2. 灵活性 (Flexibility)
    • 目标: 需要能通过“编程接口”(而非手动)自动实现任意规模和工作负载的 RAN 场景
    • 挑战:
      • 将用户期望的 RAN-Config 自动映射到可用的计算资源
      • 如何通过模块化设计, 支持不同(甚至非标准)的 RAN-CoreNet 接口

💡 Nervion 核心设计 (3.2)

Nervion 提出了一套云原生(Cloud-Native)的设计方案来应对上述挑战

(1) 为可扩展性 (Scalability) 而设计

alt text

  • 抽象 (Abstraction):
    • 核心思想: 核心网只能看到 S1/N2/N3 接口
    • 因此, Nervion 抽象并省略了 RAN 内部对核心网评估“不可见且不重要”的协议(RRC, PDCP, RLC)
    • 实现轻量化的 nUE(模拟UE)和 nBS(模拟基站)
  • UE 功能重构 (Refactoring):
    • 核心思想: 这是 Nervion 最关键的设计之一! 在标准 RAN 中，基站是数据平面的瓶颈
      • nUE: 只负责处理自己的数据平面 (Data Plane)
      • nBS: 负责处理自己的控制平面, 并代理其下所有 nUE 的控制平面 (Control Plane)
    • 结果:
      • data-plane 流量绕过 nBS, 直接从 nUE 发往核心网, 彻底解决了 nBS 的数据瓶颈
      • 两者之间, 通过自定义的 "Nervion 控制协议 (NCP)" 协调
  • RAN 元件容器化 (Containerization):
    • 核心思想: 使用轻量级的容器, 而非 VM, 来封装 nUE 和 nBS. 这使得模拟元件可以被分发到多台机器上，实现集群化扩展
    • 控制平面专用模式 (Control-Plane Only Mode): 为了实现极致的控制平面扩展, Nervion 还 支持一种特殊模式, 即在一个容器内使用多线程 (Multi-threading) 来模拟多个 nUE 的控制平面，规模得以成倍增加

(2) 为灵活性 (Flexibility) 而设计

  • 通过 JSON 定义"模拟场景":
    • 核心思想: 用户通过一个 JSON 配置文件来详细“声明”整个模拟场景
      • 包括: nUE/nBS 的数量、配置、每个 nUE 的控制平面行为(如attach后等待 10 秒再detach)、数据平面工作负载(运行 iPerf 命令)
  • 通过 K8s 自动编排:
    • 核心思想: Nervion 利用 K8s 作为底座
    • Nervion 的 Controller 负责解析用户的 JSON 配置文件, 并调用 K8s API, 自动在计算集群中部署、管理和扩展所需数量的 nUE/nBS Pods
  • 模块化的 RAN-Core 接口:
    • 核心思想: Nervion 使用基于事件 (Event-based) 的内部接口
    • 通过可插拔的“RAN-Core 接口模块”(如 S1AP 模块或 NGAP 模块), Nervion 可以将 内部的通用事件(e.g. "Attach") 转换为 4G/5G 的具体协议消息, 从而灵活适配不同的核心网

🔧 关键实现细节 (3.3)

本节介绍了 Nervion 的具体技术实现.

alt text

  • 两大组件：
    • Controller: Python 实现. 负责解析 JSON、通过 K8s API 部署 Elements、管理整个实验的状态
    • Element: C 语言实现. 这是实际运行的容器镜像. 启动时，Controller 会为其分配角色(nBS 或 nUE)
  • Nervion 控制协议 (NCP):
    • nUE <-> nBS: 使用 TCP. 因为 nUE 必须等待 nBS 同步完成控制平面动作(如 Attach)
    • Elements <-> Controller: 使用 UDP. 因为元件向控制器汇报状态是异步的
  • 控制平面 (nBS 实现):
    • nBS 作为多线程服务器运行, 通过 SCTP 模块建立与核心网 (MME/AMF) 的 S1-C/N2 连接
    • 实现了 S1AP (4G) 和 NGAP (5G) 两个 RAN-Core 接口模块, 用于处理具体的信令
  • 数据平面 (nUE 实现):
    • 核心Idea:
      • 在 Attach 过程中, nBS 在回复核心网的信令中, 谎称数据平面(GTP 隧道)的端点 IP 是 nUE 的 IP, 而不是 nBS 的!
      • 使得核心网 (SGW/UPF) 会直接与 nUE 建立 GTP 隧道
    • TUN 设备:
      • 每个 nUE 容器内都会创建一个 TUN 虚拟网卡
      • 用户在 JSON 中指定的应用(e.g. iPerf), 其产生的数据包会被该网卡捕获, 然后由 nUE 的数据平面模块封装成 GTP-U 包发往 CoreNet
  • K8s NAT 问题与 Multiplexer 方案:
    • 问题: 由于 K8s 的 NAT 机制, 从核心网返回的下行数据包, 无法被 K8s NAT 正确路由到对应的 nUE 容器
    • 解决方案: Nervion 引入了一个叫 Multiplexer (多路复用器) 的组件. aka: "一个 C 语言实现的反向 NAT"
      • 上行: nUE 的 GTP 包先发给 Multiplexer, Multiplexer 记录 (TEID -> nUE-IP, nUE-Port) 的映射关系, 然后再转发给核心网
      • 下行: 核心网将包发回 Multiplexer, Multiplexer 根据包中的 TEID, 从映射表中查出 (nUE-IP, nUE-Port), 然后将包准确地转发回去

复盘 control-plane 和 data-plane 的 dataflow

(1) Control-Plane:

核心逻辑: nBS 充当 nUE 的全权代理. nUE 只下达"命令", nBS 负责执行所有与核心网的信令交互

这是一个以 nUE 发起“Attach”为例的 workflow:

alt text

  1. [nUE] 客户端下达命令

    • nUE (作为客户端) 通过 Nervion 控制协议 (NCP) 向其关联的 nBS 发送一个内部请求（例如: “帮我 Attach”）
    • (如文中所述，这是一个 TCP 连接，监听在 nBS 的 2233 端口)

  2. [nBS] 模块接收并分发

    • nBS 模块 接收到这个请求它充当一个“前台”，将请求转发给“后台”的 RAN-Core 接口模块

  3. [nBS] 转换为 4G/5G 协议

    • RAN-Core 模块 (例如 S1AP 模块) 将这个内部请求“翻译”成一个真实的 4G S1AP 信令 (例如 Attach Request 消息)

  4. [nBS] 通过 SCTP 发送

    • SCTP 模块 负责管理与核心网的“信令高速公路”
    • 它将 S1AP 消息打包，通过已建立的 SCTP 连接，发送到核心网 MME 的 36421 端口 (如果是 5G，则是发给 AMF 的 38412 端口)

  5. [核心网] 处理与响应

    • MME/AMF 收到信令，执行所有标准的附着流程（如鉴权、建立承载...）
    • MME/AMF 将响应（例如 Attach Accept, 以及 分配给 UE 的 IP / TEID 等信息）通过 SCTP 发回给 nBS

  6. [nBS] 接收并解包

    • SCTP 模块 收到响应 -> RAN-Core 模块 解译 S1AP 消息，提取出关键信息 (IP, TEID 等)

  7. [nBS] 向 nUE 返回结果

    • nBS 模块 将执行结果（“Attach 成功，这是你的 IP 和 TEID”）通过 TCP 2233 端口的连接，发回给 nUE

  8. [nUE] 收到结果

    • nUE 获知自己已附着成功，并保存 nBS 转发来的 TEID 和 UE IP，准备用于数据平面

(2) Data-Plane:

核心逻辑: nUE 完全绕过 nBS, 自己直接与核心网 (SGW/UPF) 进行数据通信

这之所以能实现，依赖于一个关键设置和一个关键组件:

  • 关键: 在上述控制平面（步骤5）中, 当 nBS 向核心网回复 Initial Context Setup Response 消息时, 它“谎报”了数据平面的 IP
    • 它没有上报 nBS 自己的 IP
    • 而是上报了 nUE 的 IP
  • 结果: 核心网 (SGW/UPF) 被“欺骗”了它认为数据隧道 (GTP Tunnel) 的终点就是 nUE 的 IP, 因此会直接将数据包发给 nUE

alt text

Uplink: nUE -> WAN

[应用] -> [TUN] -> [nUE 封装] -> [Multiplexer] -> [K8s NAT] -> [SGW/UPF]

  1. [应用]: 用户指定的 iPerf 程序在 nUE 容器内运行, 它产生一个标准 IP 包 (例如发往 8.8.8.8)
  2. [TUN 设备]: 该 IP 包被 nUE 容器内的 TUN 虚拟网卡捕获
  3. [nUE 封装]: nUE 的数据平面逻辑 (C 语言实现)
    • A. 从 TUN 设备读取这个原始 IP 包
    • B. 使用从 nBS 获取的 TEID 和 SGW/UPF IP, 将该 IP 包封装成一个 GTP-U 包 (GTP-U 本质上是一个 UDP 包)
  4. [Multiplexer]: (解决 K8s NAT 问题的关键组件)
    • nUE 将此 GTP-U 包发往 Multiplexer
    • Multiplexer 收到包后，在一个哈希表中记录: Key = UE TEID, Value = (nUE_IP 和 K8s_Port)
    • Multiplexer 将该 GTP-U 包转发出去
  5. [K8s NAT]: K8s 的 NAT. 将包转发到WAN
  6. [SGW/UPF]: 核心网的 SGW/UPF 在 2152 端口收到 GTP-U 包, 解包, 将原始 IP 包发往WAN

Downlink: 互联网 -> nUE

[SGW/UPF] -> [Multiplexer] -> [K8s NAT] -> [nUE 容器] -> [TUN] -> [应用]

  1. [SGW/UPF]: 核心网收到一个发往 UE IP 的 IP 包（例如 8.8.8.8 的响应）
  2. [SGW/UPF]: SGW/UPF 将此 IP 包封装成 GTP-U 包
    • 关键: 由于"设置"中 nBS 的“谎报”（上报了 Multiplexer 的 IP 地址），SGW/UPF 会将这个 GTP-U 包发往 Multiplexer
  3. [Multiplexer]: Multiplexer 在 2152 端口收到下行 GTP-U 包
  4. [Multiplexer]: Multiplexer 行为
    • A. 检查包中的 TEID
    • B. 查询哈希表，根据 TEID 找到之前记录的 nUE 容器的真实 IP 和 K8s 随机端口
    • C. 将该 GTP-U 包准确转发到 K8s NAT（目标是该 IP:Port）
  5. [K8s NAT]: NAT 发现这个包的目标是它已知的 IP:Port（在上行时创建的 NAT 表项），于是将其正确转发到...
  6. [nUE 容器]: nUE 容器收到 GTP-U 包
  7. [nUE 解包]: nUE 的数据平面逻辑解包，提取出原始 IP 包
  8. [TUN 设备]: 原始 IP 包被写入 TUN 设备
  9. [应用]: iPerf 程序通过 TUN 设备收到了 8.8.8.8 的响应

Related Work 重点内容:

回顾现有的 RAN 模拟器，并将它们归纳为四大类:

  1. 全栈模拟器
  2. 商业RAN模拟器
  3. 基于trace的模拟器
  4. 专用于特定Core的模拟器

通过逐一分析这四类方案的关键缺陷, 来论证当前领域缺乏一个兼具可扩展性、灵活性、通用性和可访问性的 RAN 模拟器

类别 代表工具 核心特点 主要局限性
1. 全栈模拟器 (Full stack emulators) OAI [27], srsLTE [23] 实现了完整的 LTE 协议栈, 高保真度 存在明显且严重的可扩展性限制
2. 商业 RAN 模拟器 (Commercial RAN emulators) OpenEPC, [28], [48-52] 商业软件或硬件解决方案 成本高昂; 研究界的访问受限; 只有OpenEPC是个例外
3. 基于跟踪的模拟 (Trace based emulation) [7, 8, 11, 12, 17, 21] 1. 跟踪重放: 简单重放捕获的数据包
2. 跟踪驱动: 从跟踪中提取模式并建模, 再生成流量		 灵活性差! 无法模拟trace中未包含的流量模式, 不具备泛化能力
4. 专用模拟器 (Ad-hoc RAN emulators) UERANSIM [33], UE SIM [18], S1APTester [32] 为特定研究项目临时设计和开发的工具 1. 与特定项目紧密绑定: 不具备通用性，难以移植复用
2. 可扩展性差: 大多采用多线程模型，规模被限制在单台机器(单进程)上, 包括 UERANSIM