5GC学习报告2

Author Avatar
Euan 4月 20, 2022
  • 在其它设备中阅读本文章

5GC学习报告2

本周报告主要对云原生和5GC中相关概念、应用特性、关键技术进行了初步了解，由于学基于云原生的5GC经常使用服务化网络架构(SBA)，因此对云服务的相关概念进行了解。

[toc]

1.云原生

1.1Cloud Native由来

最早开始于 2010 年,提出是为了能构建一种符合云计算特性的标准来指导云计算应用的编写

云原生架构本质上也是一种软件架构，最大的特点是在云环境下运行，也算是微服务的一种延伸

1.1.1定义演化(来自CNCF[1])

2017DevOps、持续交付、微服务、容器四大特征

云原生技术有利于各组织在公有云、私有云和混合云等新型动态环境中，构建和运行可弹性扩展的应用。云原生的代表技术包括容器、服务网格、微服务、不可变基础设施和声明式API。

1.1.2总结

第一阶段：容器化封装+自动化管理+面向微服务
第二阶段：DevOps、持续交付、微服务、容器
第三阶段：DevOps、持续交付、容器、服务网格、微服务、声明式API

这些技术能够构建容错性好、易于管理和便于观察的松耦合系统。结合可靠的自动化手段，云原生技术使工程师能够轻松地对系统作出频繁和可预测的重大变更。

服务网格（Service Mesh）是一个专门处理服务通讯的基础设施层。它的职责是在由云原生应用组成服务的复杂拓扑结构下进行可靠的请求传送。在实践中，它是一组和应用服务部署在一起的轻量级的网络代理，并且对应用服务透明。

1.2容器化封装

容器：一种应用的包装形式，介于进程和虚拟机之间的一种计算单元

我曾使用过docker容器部署过爬虫项目，现在docker也很火，Docker可以将应用和依赖封装到一个可移植的容器中。Docker背后的想法是创建软件程序可移植的轻量容器，让其可以在任何安装了Docker的机器上运行，而不用关心底层操作系统。

容器生态图如下，该生态涵盖了容器应用中从镜像仓库、服务编排、安全管理、持续集成与发布、存储和网络管理等各个方面
1

CI/CD：持续集成、持续交付和持续部署
1.持续集成（CI，Continuous integration）：多名开发者在开发不同功能代码的过程当中，可以频繁的将代码行合并到一起并切相互不影响工作（之前实验室做过，用的gitalb）
2.持续部署（CD，continuous deployment）：是基于某种工具或平台实现代码自动化的构建、测试和部署到线上环境以实现交付高质量的产品。是持续交付的下一步，指的是代码通过评审以后，自动部署到生产环境
3.持续交付（CD，Continuous Delivery）：持续交付是在持续部署的基础之上，将产品交付到线上环境。github上传
Docker Registry是用来存储及管理Docker镜像的服务器。在每个Docker Registry中，镜像会被规整到仓库（repository）中，每个仓库包含不同应用程序（比如httpd、nginx、WordPress）对应的各种镜像。仓库也可以保存同个应用的多个版本，使用不同的标签来标识不同的版本。因此，Docker Registry类似于适用于容器化应用的版本控制存储方案。Docker Registry主要支持3种操作（push镜像、pull镜像以及delete镜像），这些操作都有对应的Registry API。

1.3 Pod

定义：是一种组合的多容器运行单元，也是Kubernetes里的一个基础单元。可以看作是一种容器的扩展或者增强型的容器

Pod的意义在于，它可以既保持主容器和辅助容器的的密切关系，又保持主容器的独立性。由于主容器和辅助容器的生命周期相同，可以同时被创建和销毁，因此把它们放在一个Pod中，可以使他们的交互更加高效。

1.4 服务编排

在单机上运行容器，无法发挥它的最大效能，只有形成集群，才能最大程度发挥容器的良好隔离、资源分配与编排管理的优势，而对于容器的编排管理，Swarm、Mesos和Kubernetes的大战已经基本宣告结束，kubernetes[kubə’netis]成为了无可争议的赢家，包括AliCloud、Tencent Clouf、ByteDance、Amazon、Intel都使用k8s

下面这张图是Kubernetes的架构图，其中显示了组件之间交互的接口CNI、CRI、OCI等，这些将Kubernetes与某款具体产品解耦，给用户最大的定制程度，使得Kubernetes有机会成为跨云的真正的云原生应用的操作系统。这张图也有点老了，现在k8s直接使用containerd作为容器运行时

2

Kubelet 是 kubernetes 工作节点上的一个代理组件，运行在每个节点上
CRI:容器运行时接口（Container Runtime Interface),用来隔离不同容器运行时的实现机制

1.5 Kubernetes在仓库中移除Docker的两个原因

Kubernetes 在早期版本中引入 CRI 摆脱依赖某个具体的容器运行时依赖，屏蔽底层的诸多实现细节，让 Kubernetes 能够更关注容器的编排。

Docker 本身不兼容 CRI 接口，而且官方并没有实现 CRI 的打算，所以 Dockershim 的维护成为了社区的想要摆脱负担。现在有很多实现CRI接口的运行时可用，Kubernetes保持对Docker的特殊支持就不再有意义。

看了相关博客后我了解了容器(container)和编排系统(k8s)的传统处理流程和新型处理流程

1.6 微服务

微服务是指系统的不同单元或功能运行不同的容器，每一个服务的容器数量可以根据自己的负载进行调整。

微服务中应该关心的主题：
3

微服务带给我们很多开发和部署上的灵活性和技术多样性，但是也增加了服务调用的开销、分布式系统管理、调试与服务治理方面的难题。

1.7 服务网格

依存于MicroService微服务架构存在的，因为微服务之间需要通信，需要数据交换同步等操作。在没有ServiceMesh之前微服务的通信，数据交换同步也存在，也有比较好的解决方案，如Spring Clould，OSS，Double这些，但他们有个最大的特点就是需要你写入代码中，而且需要深度的写很多逻辑操作代码，这就是侵入式。而ServiceMesh最大的特点是非侵入式，不需要你写特定代码，只是在云服务的层面即可享受微服务之间的通信，数据交换同步等操作，这里的代表如，docker+K8s，istio，linkerd等。

1.7.1 理解服务网格

如果用一句话来解释什么是服务网格，可以将它比作是应用程序或者说微服务间的 TCP/IP，负责服务之间的网络调用、限流、熔断和监控。对于编写应用程序来说一般无须关心 TCP/IP 这一层（比如通过 HTTP 协议的 RESTful 应用），同样使用服务网格也就无须关系服务之间的那些原来是通过应用程序或者其他框架实现的事情，比如 Spring Cloud、OSS，现在只要交给服务网格就可以了。

5

1.8 DevOps

DevOps是指开发者、测试、生产过程流水线化。包括自动化发布管道、CI工具；快速部署到生产环境；开发、运维协同合作。

1.9 落实具体的工具

如图，使用Kubernetes构建云原生架构

3

合这12因素对开发或者改造后的应用适合部署到Kubernetes之上，基本流程如下图所示：

4

2 5G核心网络(5GC)（主要参考华为5GC的PPT介绍）

2.1 定义

随着 5G 的出现，行业专家定义了核心网络应如何演进以支持 5G 新无线电 (NR) 的需求及其支持的高级用例。他们共同为核心网络开发了新的 3GPP 标准，称为 5G 核心网 (5GC)。

区别：5G NR讲述的是从移动设备到RAN之间的无线网络，而5GC讲述的则是从基站到网络运营商/事业单位的内部网络结构（UPF），当然有时候5GC也可以描述为设备到网络运营商。
无线接入网（RAN）：如基站；

5G 核心网 (5GC) 是 5G 移动网络的核心。5G 核心网络功能完全基于软件并设计为云原生，这意味着它们与底层云基础设施无关，从而实现更高的部署敏捷性和灵活性。

新的 5GC 架构基于所谓的基于服务的架构，借鉴了云原生设计方法，采用了微服务、网络功能虚拟化、控制面与用户面分离、网络切片、边缘计算、网络能力开放等技术，将演进分组核心网（EPC，Evolved Packet Core）中的网元（Network Element，NE）进一步拆分为网络功能（Network Function，NF）,包括NSSF、NEF、NRF、PCF、UDM、AUSF、AMF、SMF、UPF、AF,最终实现了 5GC 架构化整为零、由硬变软的演进

华为，中兴，爱浦路IPLOOK厂商
NFV：网络功能虚拟化
边缘计算（Multi-access Edge Computing，MEC）

全景图：
5

  1. AMF(Core Access andMobility Management Function)接入及移动性管理，主要负责用户接入控制和移动性管理等；
  2. SMF(Session ManagementFunction)会话管理，主要负责会话管理，同时包括路由控制、地址分配和合法监听等控制功能；
  3. UDM(Unified DataManagement)统一数据管理，主要负责用户数据和签约信息的存储，但是不具备鉴权功能；
  4. UPF(User Plane Function)用户面功能，只做纯转发面，实现用户面的大数据量转发功能；
  5. PCF(Policy ControlFunction)策略控制功能，主要负责5G网络基于流的QoS控制等；
  6. NRF(NF RepositoryFunction)网络功能仓库，主要用于5G网络各种网元功能的注册管理；
  7. NEF(Network ExposureFunction)能力开放功能，便于与各类互联网和物联网应用对接和扩展；
  8. UDR(Unified DataRepository)统一数据仓库，主要为所有NF提供非结构化数据信息的存储和检索功能；
  9. NSSF( Network SliceSelection Function)网络切片选择，其主要功能是5G网络中为了实现切片管理新增的功能；
  10. AUSF(AuthenticationServer Function)认证服务器功能，主要是为了便于互联网业务鉴权的整合，实现5G网络的统一鉴权功能。

2.2 目的（Rel-16版本）

增强5G对于增强移动宽带（enhanced Mobile Broadband，eMBB）、超高可靠和低延迟通信（ultra Reliable and Low Latency Communication，uR LLC）和海量机器类通信（massive Machine Type of Communication，mMTC）场景的支持能力

2.3 解决方案

  1. Cloud Native:具有软件微服务化、数据分布式存储等特征，与5G不谋而合。华为5G核心网软件架构借鉴了Cloud Native的设计理念实现了软件微服务化
  2. 服务化网络架构(SBA)：3GPP协议将控制面网络功能(NF)全面解耦，摒弃了传统点对点组网的通信方式．采用服务化架构组网模式，5G核心网采用了基于服务化架构的SBI(service based interface）串行总线接口协议，传输层采用HTTP/2协议．
  3. 网络切片(Network Slices)：为了满足不同行业用户对网络资源的不同指标要求，实现按业务需要灵活分配网络资源（类似微服务思想，负载均衡）有UeMBB切片和FWA切片两种
  4. 极简融合：华为5G核心网实现了2/3/4/SG网络的全面融合，打造极简融合的核心网，图片同时兼顾存量网络的平滑演进
  5. 边缘计算：使业务就近本地分流，使用户实现业务数据的本地运营，在边缘网络位置为用户提供差异化服务，带给用户超低时延的业务体验

2.3.1 Cloud Native

轻量级虚拟化隔离，支持多云部署（包括公有云的部署形式）是未来电信网络发展的趋势．容器是Linux操作系统内核自带能力，容器实现了轻量级高性能资源隔离机制，5G Core产品基于Docker容器来部署和运行，使产品汇聚了Docker容器的各方面优势：

  • 通过镜像的方式进行产品软件打包．加快产品部署升级，实现秒级的弹性伸缩和HA.
  • 通过容器方式进行应用的部署，和通过虚拟机相比开销很小，能够节约资源。
  • 通过将除Linux内核外的环境信息都打包到镜像中，移植能力强，支持跨云部署，无厂商锁定。不管是华为私有云还是第三方公有云，产品均能部署上线．不虚要再次进行镜像的定制发布。
  • 通过容器粒度的资源隔离定制．产品可以针对不同级别的SLA，进行资源的专属定制和规划。

5G Core部署在华为电信级Fusionstage平台上．Fusionstage平台的核心是封装系统云化，微服务化的分布式复杂性，Fusionstage平台定义了以下几大功能：

  • 微服务治理框架：为应用提供自动注册、发现、治理、隔离、调用分析等一系列分布式/微服务治理能力．屏蔽分布式系统的复杂度。
  • 应用调度与资源管理框架：打通从应用建模、编排部署到资源调度、弹性伸缩、监控自愈的生命周期管理自动化．
  • 应用开发流水线框架：打通从编写代码提交到自动编泽打包、持续集成、自动部署上线的一系列CI/CD全流程自动化。
  • 云中间件服务：应用云化所需的数据库、大数据、通信和应用中间件服务；通过服务集成管控可集成传统非云化的中间件能力。

产品微服务化容器化的过程中：

  • 通过应用调度与资源管理框架进行容器资源的调度管理，实现一健式的实例化、弹性和升级。
  • 通过微服务治理框架，屏蔽产品服务化拆分后，新引入的分布式系统的复杂度。
  • 通过应用开发流水线框架，构建DevOps能力系统。
  • 通过云中间件服务．未来产品或引入第三方服务，支排产品在特定领域的功能。

SLA是服务等级协议（Service Level Agreement），是通信服务中的基础服务，通俗讲，就是服务商在提供的服务中确定要达到一个怎么样的等级的协议。但并不是每个产品都有SLA。
HA:高可用(High Availability)

2.3.2 微服务业务架构

6

  • 业务微服务：上层业务逻辑相关的微服务，例如AM承载了移动性管理，接入管理功能
  • 链路及接口微服务：负责外部请求到微服务间的消息分发。
  • 公共微服务：为系统提供公共服务的微服务。例如CSLB负责消息的转发和负载均衡处理,CSDB负责微服务的分布式数据存储．
  • 微服务框架：管理微服务上线注册、微服务间通信、微服务发现及订阅、注销等．保证系统正常、可靠运行。
  • 操作运维框架：负责发给微服务以及将微服务的状态信息（告苦、过理数据等）上拓倒网管或

AM(Access and Mobility Management,接入与移动性管理)
SLB:负载均衡（Server Load Balancer）

3 云服务

对云服务相关概念进行了解

云计算、云服务就是一种更优化的服务器功能，从只是个服务器硬件本身，升级到在这个硬件中集成了很多方便使用，或者开箱即用服务，不需要你知道怎么安装，怎么配置，你只要花钱买了，就开箱即用。即有硬件使用，也有服务提供，这就是云服务。

3.1 IaaS

基础设施服务，Infrastructure as a service，如果把软件开发比作厨师做菜，那么IaaS就是他人提供了厨房，炉子，锅等基础东西，如租服务器

3.2 PaaS

平台服务，Platform as a service，还是做菜比喻，比如我做一个黄焖鸡米饭，除了提供基础东西外，那么PaaS还给你提供了现成剁好的鸡肉，土豆，辣椒，你只要把这些东西放在一起，加些调料，用个小锅子在炉子上焖个20分钟就好了。如oj系统上的ide

3.3 FaaS

函数服务，Function as a Service，同样是做黄焖鸡米饭，这次我只提供酱油，色拉油，盐，醋，味精这些调味料，其他我不提供，你自己根据不同口味是多放点盐，
还是多放点醋，你自己决定。如IBM Cloud Functions

3.4 SaaS

软件服务，Software as a service，同样还是做黄焖鸡米饭，这次是直接现成搞好的一个一个小锅的鸡，什么调料都好了，已经是个成品了，你只要贴个牌，直接卖出
去就行了，做多是在炉子上焖个20分钟。

3.5 MicroService

微服务，Micro service，微服务是服务整体的细化，如果还是做黄焖鸡米饭，就好比一家供应商提供好了所有调料，一家供应商提供好了所有的鸡块等食材，你只要把这两
家供应商提供的东西做成黄焖鸡米饭就行了。

3.6 Serverless

无服务，Server less，说是无，其实有，无服务就是一种没有感知的服务，你不需要知道它怎么实现的。如果还是做黄焖鸡米饭，无服务在这里可以比喻为买一袋已经调味好的调料包，你直接往黄焖鸡里倒就行了，至于怎么调出的口味你不需要知道。

3.7 Serverless的历史

“无服务器”指的是我们的代码不会明确地部署在某些特定的软件或者硬件的服务器上。运行代码托管的环境是由例如阿里云或者腾讯云这样的云计算厂商所提供。其实这听上去又很像Paas,SaaS,FaaS,所以他们之间也充满了联系。

3.8 Serverless 与 PaaS

PaaS是平台即为服务，Serverless相当于平台提供了更加细粒度和碎片化的服务，从这个层次来说，Serverless=PaaS。

3.9 Serverless 与 SaaS

SaaS是软件本身即为服务，Serverless相当于软件提供了更加细粒度和碎片化的服务，因为Serverless也是一种软件，从这个层次来说，Serverless=SaaS。

3.10 Serverless 与 FaaS

FaaS是函数即为服务，Serverless相当于提供的更加细粒度和碎片化服务是一种函数，从这个层次来说，Serverless=FaaS。

3.11 Serverless 与 MicroService

MicroService是微服务，是一种专注于单一责任与功能的小型服务，Serverless相当于更加细粒度和碎片化的单一责任与功能小型服务，他们都是一种特定的小型服务，从这个层次来说，Serverless=MicroService。

这几个之间有这么多联系，但是从架构的定义范围也有个包含关系，PaaS > SaaS > FaaS > MicroService > Serverless

4 参考文献

[1]云原生计算基金会（CNCF）定义

[2]CNCF微信推文

[3]华为5GC PPT介绍

[4]Jimmy Song(云原生社区创始人)博客介绍云原生

[5]张皓然. 基于微服务的5G核心网管理与编排技术研究[D].西安电子科技大学,2021.DOI:10.27389/d.cnki.gxadu.2021.002059.

[6]李铭轩,童俊杰,刘秋妍.基于云原生的5G核心网演进解决方案研究[J].信息通信技术,2020,14(01):63-69.

本文使用 CC BY-NC-SA 3.0 中国大陆 协议许可
具体请参见 知识共享协议
本文链接：https://zyhang8.github.io/2022/04/20/report2/