AWS — AWS 上的 5G 网络

目录

文章目录

• 目录
• AWS 上的 E2E 5G 网络
• AWS 上的 5G Core Network

• Service Based Architecture

• CP 的高可用部署
• UP 的多网络平面

• Stateless Architecture
• CUPS Architecture

AWS 上的 E2E 5G 网络

将 5G 网络部署在 AWS 上，既可以满足要求严格的 SLA，又可以充分的利用公有云带来的弹性、可扩展性、高可用性效益。

AWS 上的 5G Core Network

Service Based Architecture

微服务架构不一定基于容器来实现。不过，与基于虚拟机来实现相比，容器提供了更好的可扩展性和高可用性。但随着而来的挑战是，用户需要管理复杂度更高的容器集群。通常的，可以使用 Kubernetes 容器编排器平台来简化这个问题。

基于微服务架构，可以深度拆解多个 5G NFs 中可重用的、具有单独可扩展性的功能模块，来作为公共服务，以此来最小化代码冗余。

通过以下 AWS 服务来支持 containerized-microservice 的 5GC SBA：

1. ​容器编排（Amazon ECS、Amazon EKS）​：承载 CNF（Cloud Native Network Function）。
2. ​服务网格（Amazon App Mesh、Istio/Envoy）​：为 CNFs 之间的东西接口通信，提供 Service Mesh 功能，例如：流量控制、流量可观察性、安全功能。
3. ​服务发现（Amazon Route 53、Amazon Cloud Map）​：充当 NRF（服务注册功能，R15）或 SCP（服务通信代理，R16）的角色。
4. ​消息中间件（Amazon MSK、Amazon API Gateway、Amazon MQ、Amazon SNS、Amazon SQS）​。

CP 的高可用部署

在传统的核心网架构设计中，要求具有跨 DC 的故障隔离特性。如下图 (a)，NF 被设计成为一个逻辑组（e.g. 4G MME-Pool、5G AMF-Set）。以此来满足网络的安全等保需求，但也需要付出昂贵的 DC 建设费用。

AWS 则提供了更好的方式。可以选择在属于同一个 Region 中的、多个跨 DC 的 AZ（可用区）上构建容灾解决方案，简化了建设复杂度和成本。 如下图 (b)。

1. ​编排层：跨多个 AZ 的 EKS Worker Nodes 冗余​：基于 EKS 创建一个跨多个 AZ 的 Worker Node Group。对于这种模式，NF 的 SBI 可以使用 AWS Elastic Load Balancing，它可以在每个 AZ 创建，并为每个 AZ 提供 Local Endport。对于 N2 接口，可以使用 3GPP 23.501 中定义的多个 TNLA（Transport Network Layer Association，传输网络层关联）功能。这意味着我们可以在每个 AZ 都创建 SCTP 锚点，以便当一个 SCTP 锚点或整个 AZ 故障时，NGAP 可以切换到其他活动的 SCTP connection。
2. ​业务层：跨多个 AZ 的 NF-Set 冗余​：使用 3GPP 定义的 5G NF-Set 冗余机制。在跨多个 AZ 部署 NF-Set 后，针对每个参考点（e.g. N2），可以设置为一个 NF 或整个 AZ 故障时，将流量重新路由到另一个 AZ 中的同类型 NF。
3. ​数据层：跨多个 AZ 的 Data Store 冗余​：使用 AWS DynamoDB 和 Amazon RDS 作为 Stateless NFs 的共享数据存储。可以让每个 AZ 中的 NFs 访问同一个公共数据库。对于这种模式，DynamoDB 是一种可扩展且可靠的数据库解决方案。DynamoDB 会自动完成跨多个 AZ 间的同步复制，从而提供内置的高可用性和数据持久性。

UP 的多网络平面

UPF 的 N3、N4、N6、N9 接口具有多网络平面需求，所以 UPF Pod 应该被设计成一个 Multi-homed Pod 类型。

AWS 支持使用 Multus CNI Plugin 为 Pod 在 Kubernetes Network 中提供多个 Interfaces，目前提供了 3 种 Multi-homed Pod 实现：

1. Using host networking (or privileged mode). This applies to the DPDK interface.
2. Using Multus meta CNI plugin with IPvlan CNI.
3. Using Multus meta CNI plugin with host-device CNI (applicable to DPDK interface).

并且，在 EC2 Nitro 系统中，所有的 Host Elastic Network Interfaces（主机弹性网络接口）都是 SR-IOV VF resource。因此，SR-IOV CNI Plugin 不是必须的。

如上图的 option1 和 option3 所示，一旦 Pod 通过 HostNetworking 或 host-device CNI Plugin 连接到 Host Elastic Network Interface（主机弹性网络接口），那么这个 Pod 就可以直接启用 DPDK PMD 驱动程序来加速数据包处理了。

需要注意的是，当使用 Multus CNI 多网络平面时，必须使用 Kubernetes Label ​

​node.Kubernetes.amazonaws.com/no_manage=true​

​，使其不受 AWS VPC CNI 插件控制。该标签由 aws-node daemonset 读取，以确定附加到 instance 的 elastic network interfaces 是否受 VPC CNI 插件控制。

另外，由于 UPF N3/4、AMF N2 依旧沿用了参考点接口，无法使用常规的 TCP 高可用方案。所以，在 N2、N3、N4、N6、N9 接口的高可用需求上，需要使用 CNF 供应商提供的 LB 解决方案。

Stateless Architecture

Stateless 是在微服务架构中流行的设计模式，它使用外部数据存储，将应用层和数据存储层进行了解耦。

3GPP 引入了 Stateless Architecture，并在 TS 21.195 中定义了 UDR 和 UDSF，以实现更好的可靠性和弹性。

通过以下 AWS 服务来支持 5GC Stateless Architecture：

• ​内存数据库（Amazon ElastiCache）​：提供了 Redis 和 Memcached database。
• ​关系型数据库（Amazon RDS、Aurora）​：充当 UDR 的角色。
• ​非关系数据库（Amazon DynamoDB、Amazon DocumentDB）​：充当 UDSF 的角色。

CUPS Architecture

5G SA Core Network 支持 CUPS 架构。

同样的，5G RAN 也支持 CUPS 架构，CU 和 DU 的分解使得传统 BBU 更容易重构为 VNF 或 CNF，根据 3GPP TS 38.401 的定义，CU 可以继续分为两部分：CU-CP（Central Unit Control Plane）和 CU-UP （Central Unit User Plane）。

• ​AWS Regions​：

• 可用于部署全部 CP NFs。
• 可用于部署部分集中类 CP NFs。
• 可用于部署 NFVO。
• 可用于部署 MEAO。

• ​AWS Local Zone​：

• 可用于部署部分分散类 CP NFs。
• 可用于部署高容量人网 UPF。
• 可用于部署 RAN CU-CP。
• 可用于部署 VNFM。
• 可用于部署 MEPM。

• ​AWS Outposts​：使用一组 AWS Outposts 作为 Local Central Office（本地中心办公室，局所）或 Distributed Data Center（分布式数据中心）。

• 可用于部署 RAN CU-CP。
• 可用于部署 RAN CU-UP。
• 可用于部署 RAN DU。
• 可用于部署低容量物网 UPF。
• 可用于部署 MEP

值得注意的是，无论是 UPF（Outposts）与 SMF（Local Zone 或 Regions）之间的 N4 接口，还是 RAN CU-CP（Outposts 或 Local Zone）与 AMF（Local Zone 或 Regions）之间的 N2 接口，要求具有高带宽、低抖动、低延迟保障的网络连接，用于支撑会随着用户量增长而增长的信令传输。

所以建议使用 AWS Direct Connect over VPN 的方式来建立高性能、高可靠的云边网络连接。支持通过 Service Link 来管理 AWS Outposts 与 AWS VPC（例如 N2 和 N4 接口）之间的信令流量。