5G-MAP: Demystifying the Performance Implications of Cloud-Based 5G Core Deployments

这是一篇典型的平台类工作

Abstract

(1) 研究背景与动机:

5G 核心网被设计为托管在商用现成 (COTS) 硬件上的虚拟网络功能 (VNFs) 集合，这使得对通用计算资源的需求不断增加

凭借其弹性的基础设施，如 Amazon Web Services (AWS) 等云服务成为满足这一需求的理想平台

因此，了解在云端部署 5G 核心网所涉及的服务质量 (QoS) 需求变得至关重要

(2) 提出的解决方案:

研究团队开发了“5G-MAP”（5G 测量与评估平台），旨在帮助理解不同部署策略之间的权衡

该框架能够在多样的部署场景中进行详细的控制平面和用户平面性能评估

(3) 实验规模与实施:

研究将 5G-MAP 与 OpenAirInterface (OAI) 5G 核心网进行了集成，并在全球范围内进行了一系列部署测试

这些测试规模宏大，跨越了 7 个国家，利用了 8 个 AWS 区域和 18 个边缘区域

该平台的性能评估覆盖了: 从 HTTP 事务 到用户平面的 吞吐量 和 丢包率 等多个维度

(4) 核心发现与应用价值:

研究识别出了特定的网络拓扑结构，这些结构通过显著减少跨站点的跳数，能够大幅降低 5G 核心网服务链的延迟

这些切实可行的性能提升方案，充分展示了运营商如何利用 5G-MAP 来优化其基于云的 5G 网络部署

Introduction

(1) 5G核心网向公有云演进的背景与挑战

• 与传统的LTE网络不同，5G网络通过逻辑隔离的“网络切片”来满足不同垂直行业的特定服务质量 (QoS) 需求
• 5G核心网利用网络功能虚拟化 (NFV)，将网络功能打包为运行在商用现成 (COTS) 硬件上的虚拟网络功能 (VNF)
• 这种虚拟化带来了对可扩展托管基础设施的巨大需求，使得如AWS、谷歌云 (GCP) 和微软 Azure 等公有云平台成为电信运营商极具吸引力的选择
  • 业内也已出现大量相关的跨界合作与概念验证项目
  • 这些合作旨在利用云平台的高级计算能力和全球可扩展性来提升蜂窝网络服务
• 随着云端部署的推进，业界对在云环境中测试和评估5G部署的需求日益增长

(2) 5G-MAP平台的提出与核心机制

• 为了满足上述测试需求，研究团队推出了5G-MAP（5G测量与评估平台），这是一个旨在评估云端大规模5G部署的延迟开销和吞吐量瓶颈的框架
• 它是一个专为 Kubernetes 环境设计的即插即用框架，充当封装的服务网格 (service mesh)
• 该框架在每个 VNF 旁部署边车代理 (SCPs)，以提供单个 HTTP 事务的详细控制平面遥测
• 通过用户设备模拟工具(gNBSIM)
  • 平台能够加载真实流量模型（如 Netflix、移动游戏、VR等），以评估不同场景下的吞吐量和丢包限制

(3) 研究的双重目标

• 展示应用价值: 演示运营商如何利用 5G-MAP 测试不同的网络切片拓扑和流量模式，从而准确表征基于云的 5G 部署性能
• 提供实证数据: 在 AWS 上开展全球性的测量研究，为使用云基础设施的 5G 运营商提供全新的见解
  • 研究表明，通过优化关键 VNF 的布局，可以显著减少跨站点跳数，使整体延迟降低 20 至 200 毫秒不等

Background

2.1 5G Core Overview

• 5G 核心网采用基于服务的架构 (SBA):
  • 其虚拟网络功能 (VNF) 被划分为: 归属网络 (HN) 和服务网络 (SN) 两个主要组件
• 介绍了各关键 VNF 的角色:
  • 接入和移动性管理功能 (AMF) 充当通信枢纽
  • 认证服务器功能 (AUSF) 以及统一数据管理/存储库 (UDM/UDR) 共同参与 5G 认证和密钥协商 (AKA)
  • 会话管理功能 (SMF) 和用户面功能 (UPF) 分别作为数据会话的 控制面 和 用户面 锚点
  • 网络存储库功能 (NRF) 则充当服务发现的元数据数据库

2.2 Side-car Proxies and Service Mesh

• 边车代理 (SCP) 允许开发人员将非功能性需求（如监控、安全等）与主应用程序隔离开来
  • SCP 与微服务, 通过服务网格集成, 的示意图如上
• 在 Kubernetes 中，SCP 与应用程序在同一个 Pod 环境中作为容器运行，提供无缝的网络和平台级抽象
• 5G-MAP 平台充分利用了 SCP 和服务网格的云原生设计原则
  • 这使得该平台不依赖于特定的基础设施，可以灵活部署在任何基于 Kubernetes 的环境
  • 无论是私有云还是公有云

Side-car proxy

在计算机网络系统，特别是现代微服务架构中，边车代理 (Side-car Proxy, 简称 SCP) 已经成为一个至关重要的组成部分

顾名思义，它的工作模式就像是摩托车旁边的“跨斗（边车）”，始终附加在主应用程序旁边协同运行

1. 解耦非功能性需求:
   • 允许开发人员将非功能性需求与主应用程序完全隔离开来
   • 这些非功能性需求通常包括系统层面的监控、安全性策略执行以及无缝的网络连接等
   • 通过这种解耦，主应用（例如 5G 核心网中的 VNF）可以纯粹地专注于自身的业务逻辑，从而实现更灵活的部署选项
2. 无侵入式的请求拦截与监控:
   • 边车代理最大的优势之一是“对代码零侵入”
   • 充当一个双向的重定向代理，自动拦截同一 Pod 内进出 5G 应用的 HTTP 消息
   • 通过这种方式，它能够提取 API 路径、创建追踪跨度 (Span)，并将详细日志发送给监控平台

2.3 AWS Architecture

• AWS 的基础设施在地理上分为:
  • 区域 (Regions)
  • 可用区 (AZ)
  • 专门用于边缘低延迟应用的 本地扩展区 (LZ)
• 为了在 5G 网络边缘提供云环境，AWS 引入了 波长区 (WZ):
  • WZ 会直接将应用部署在电信服务提供商 (TSP) 的基础设施上，非常靠近无线接入网 (RAN)
  • 由于部署策略的不同, 一般有: \(delay(AZ, WZ) \ge delay(AZ, LZ)\)
• 不同服务质量 (QoS) 敏感型的 5G 部署在混合 AZ、LZ 和 WZ 架构上的布局策略:
  • 切片 1 (任务关键型应用):
    • 由于需要高可靠性且控制面信令密集，它更侧重于降低控制面的建立时间
    • 因此部署在: 延迟更低的 LZ-AZ 连接上. 以加快 SN 和 HN 之间的交互
  • 切片 2 (对用户面延迟敏感的应用如 eMBB 和 URLLC):
    • 为了获得更好的用户面 QoS 体验（如降低 AR/VR 的数据延迟）
    • 将数据会话相关 VNF（SMF, UPF）部署在更靠近 5G 边缘的 WZ 中

5G-MAP Framework

Control Plane Tracing

主要介绍了 5G-MAP 如何在不修改底层代码的情况下，实现对 5G 核心网 HTTP 事务的分布式追踪:

(1) 监控管道架构:

5G-MAP 采用了由 Jaeger 和 OpenTelemetry 组成的仪器化管道 (instrumentation pipeline) 来追踪 5G 核心网 VNF 之间的 HTTP 事务

该管道在 Kubernetes 节点和 Pod 层级的详细分布情况:

(2) 无侵入式拦截机制:

为了避免修改 5G 核心网 VNF 的源代码，平台利用 OpenTelemetry 设计了自定义的 SCP

该代理充当双向重定向代理，实现对 Pod 内 5G 应用的 HTTP 消息的拦截与转发

(3) 消息跨度生成:

当 HTTP 请求在代理的 OpenTelemetry HTTP 服务器处被处理时，系统会根据 URL 中的 5G CAPIF 路径创建一个上下文跨度 (span)

这使得 5G-MAP 能够区分单个控制面消息，并识别发送和接收的 VNF

以 AMF 向 SMF 发起 API 调用为例, 单次 HTTP 事务拦截和重定向的详细流程:

(4) 代理性能开销:

研究评估了引入 SCP 对核心网操作造成的延迟开销，结果如图:

数据显示，在大多数操作（如 SMF 发现和 PDU 会话建立）中，代理引入的额外延迟极小（低于 3 毫秒）

虽然由于多次拦截导致 5G-AKA 链中的开销略高，但总体延迟增加依然很低，不影响跨站点云评估的准确性

积累常见事件流程/开销

User Traffic Recreation

介绍了 5G-MAP 如何捕获并回放真实的应用程序流量，以对 5G 用户平面进行压力测试:

(1) 流量捕获与回放系统:

除了控制面追踪，5G-MAP 还能在 5G 用户平面上重现应用流量

通过可编程路由器捕获特定应用的上下行流量模式，并将其存入测试容器中以供回放

(2) 模拟节点设置:

在架构中，gNBSIM 作为一个黑盒实体，在单个容器内同时模拟基站 (gNB) 和用户设备 (UE)

另一个独立的容器 DNN (数据网络节点) 则用于代表现实生活中的应用服务器

• 上行链路模式: 放置在目标 gNBSIM 容器内回放
• 下行链路模式: 在目标 DNN 容器内回放

(3) 丰富的测试应用配置:

为了实现多样化的测试，平台录制了广泛的真实流量模型. 这包括:

• 代表 eMBB 切片类型的 Netflix 视频和 TikTok 浏览流量
• 代表 URLLC（超可靠低延迟）的 Fortnite 游戏流量
• 兼具 eMBB 和 URLLC 混合需求的 Oculus Quest 2 VR 流量
• 代表 VoIP 服务的 Zoom 视频会议流量

Discussion

(1) LZ-WZ Inter-Connectivity

• 现状与局限:

  • 目前，AWS 的本地扩展区 (LZ) 和波长区 (WZ) 之间没有直接的通信连接
  • 这意味着对于任何网络部署，只能同时使用其中一种边缘区域方案

• 混合部署的潜力:

  • 论文建议 AWS 应该考虑建立这种互连性，从而为运营商解锁更具弹性的混合部署方案（例如结合波长区、本地扩展区和中心可用区）

• 架构优化案例:

  • 以无人机实时流媒体用例为例，如果启用了 WZ 和 LZ 之间的互连，就可以将用户面功能 (UPF 和 SMF) 部署在 WZ 内以提供高吞吐量（最靠近 RAN）
  • 同时将控制面功能 (AMF 和 NRF) 放置在 LZ 内以维持低控制面延迟（相比 WZ，LZ 距离中心归属网络 HN 更近）
  • 这种混合设计能完美兼顾数据传输效率与信令交互速度

(2) Comparing SCP and eBPF

• eBPF 的优缺点对比:

  • eBPF 是一种在内核级别运行的监控方法，它可以绕过网络处理栈，因此处理速度极快且开销更低
  • 然而，它的功能集和灵活性有限，难以应对复杂的应用层协议

• 5G-MAP 的技术取舍:

  • 相比之下，5G-MAP 采用了服务网格和边车代理 (SCP)，在应用层无缝注入监控
  • 这赋予了平台广泛的定制能力（例如动态的 HTTP 头部操作）
  • 如果试图通过更底层的 eBPF 来直接实现这些高级功能，将会导致效率低下且不易扩展

• 未来的结合方向:

  • 虽然单纯依靠 eBPF 无法提供所需的功能深度，但未来的演进可以考虑将用户空间的服务网格/SCP 与内核空间的 eBPF 结合起来
  • 以在降低开销的同时保持功能的多样性

我学到了什么

1. 用户设备模拟工具 gnbsim
2. Side-car Proxy 是一个很好的"中间件代理"
   • 适合"monitor"
   • 设计"hijack"
3. AWS 的基础设施级别: region, az, lz, wz