5G+边缘计算 学习笔记
OneNET EDGE
- 前言
- 我以前了解的边缘计算
- wiki名词
-
- 5GC中的一些词
- 一些没那么常见但也可以知道的词
- 边缘计算中的一些词
-
- MEC(Mobile Edge Computing)
- ECP(Edge Compute Platform)
- NFV(Network Function Vitualizaiton)
- 云网融合
- 云边协同
- docker
- Kubernetes
- 我了解的容器docker和Kubernetes（说人话）
- 一些想法
-
- 为什么是5G和边缘计算是强相关？
- 边缘EDGE的产品形态
- 边缘节点类型
- 边缘市场会有怎么样的应用
-
- 华为IEF
- OneNET EDGE
- 参考文档
（个人研究学习，不保证对哈，欢迎探讨指正！）
前言
目前新了解的边缘计算，会和我之前已知的aws greengrass core中边缘部署的lambda函数有一定的区别。OneNET Edge的侧重点，并不是一个函数计算，不是一个简单纯粹的智能网关，当温度高了低了就报警，筛选数据消息路由这些功能可以有，但并不只是这样。
我以前了解的边缘计算
我以前了解的边缘计算，无非是一个将云平台裁剪后，放在算力有限的本地机器上，以实现应用本地化，例如AWS greengrass这样的产品。
一些包装的有算法硬件模块，比如像K210这样的产品，将NPU算力放在他的小芯片里，在加载模型后，就可实现图像算法的本地化，实现例如人脸识别物体识别这样的功能。或是业务逻辑的一些本地化代码，比如数据的筛选分流，一些简单的本地化处理，都是我所理解的边缘计算。
而5g强相关的5G+MEC，也就是容器化的边缘计算平台。也可说是云网融合背景下，核心网边缘化，云算力边缘化的这样一个产品。
wiki名词
在学习培训过程中，被大量不带释义的英文首字母缩写绕晕了脑袋，都不知道在说些啥。有种萌新第一次去玩狼人杀，听到老玩家说的“金水、银水、查杀、上警”这些词的一脸懵逼的感觉。因此打算把常用的一些名词和概念做一个解释，熟悉一下。
5GC中的一些词
5G 核心网构架主要包含四大关键技术：
- SBA（基于服务的软件架构）
- CUPS（控制面与用户面分离）
- 网络切片
- 计算存储相分离
四大关键技术最终实现了 5GC 架构 化整为零、由硬变软 的演进。
| 缩写 | 释义 |
|---|---|
| 5GC | 5G Core network 5G核心网 |
| SBA | Service Based Architecture 基于服务的软件架构 |
| CUPS | 控制面和用户面分离 |
| UP\CP | User Plane\Control Plane 用户面 控制面 |
| NF | Network Function 网元 |
| AF | Application Function 应用功能 |
| UE | User Equipment 用户设备 |
| SMF | Session Management Function 会话管理功能 |
| UDM | Unified Data Management 统一数据管理 |
| UPF | User Plane Function 用户面功能 |
| UDR | 统一数据存储库 |
这些英文缩写都是干啥的？在阅读5G核心网架构的时候，就会需要知道了。
放一张5G系统架构图熟悉一下。
上面圈出来的部分就是控制面功能，下面蓝色部分是用户面功能。
可以和范桂飓大佬博客的图对比着看
一些没那么常见但也可以知道的词
| 缩写 | 释义 |
|---|---|
| UDSF | 非结构化数据存储功能 |
| NEF | 网络开放功能 |
| NRF | 网络存储库功能 |
| NSSF | 网络切片选择功能 |
| PCF | 控制策略功能 |
边缘计算中的一些词
| 缩写 | 释义 |
|---|---|
| MEC | Mobile Edge Computing 移动边缘计算 |
| MEC | Muli |
| MEP | Mobile Edge computing Platform 移动边缘计算平台 ？ |
| MEO | Multi-access edge orchestrator 多接入边缘编排器 |
| ECP | Edge Computing (Paas) Platform 边缘计算平台 |
| ECM | Edge Computing operations Management platform 边缘计算业务运营平台 |
| SBA | Service Based Architecture 基于服务的软件架构 |
| NFV | Network Function Vitualizaiton |
| OSS | Operation support system 运营支撑系统 |
| OMC | Operation and maintenance Center 操作维护中心 |
| UPF | User plane function 用户面功能 |
| CMP | Cloud Management Platform 云管平台 |
| eMBB | Enhanced Mobile Broadband 增强宽带接入 |
| mMTC | massive Machine Type Communications 大规模物联网 |
| uRLLC | Ultra Reliable Low Latency Communications 极致的实时通信 |
MEC(Mobile Edge Computing)
移动边缘计算
ECP(Edge Compute Platform)
通用意义上的边缘计算平台，也可写成MEP(Mobile Edge Platform)
NFV(Network Function Vitualizaiton)
网络功能虚拟化
云网融合
云计算中引入网络的技术，通信网中引入云计算的技术。或者说，是设备商运营商逐渐云化。5G核心网所有的服务，都构建在虚拟机和容器上。虚拟机和容器，全部都是来自云计算的技术。容器更是云原生技术之一。
可参考虎嗅的文章
云边协同
边缘计算和云计算不是两种互斥的技术，它们是相辅相成的关系。而且从场景需求上看，IoT/Edge与云数据中心有一些相似之处，例如：
- 边缘也有管理节点的计算、存储、网络等资源的需求；
- 边缘应用也想容器化和微服务化；
- 边缘计算希望能有标准的API和工具链；
- 安全，数据/信道加密和认证授权。
更多云边协同可参考这篇讲k8s和kubnet的文章
docker
Docker 是一个开源的应用容器引擎。是一个用于开发，交付和运行应用程序的开放平台。
Docker 使您能够将应用程序与基础架构分开，从而可以快速交付软件。借助 Docker，您可以与管理应用程序相同的方式来管理基础架构。通过利用 Docker 的方法来快速交付，测试和部署代码，您可以大大减少编写代码和在生产环境中运行代码之间的延迟。
Kubernetes
Kubernetes已经成为云原生的标准，并且能够在任何基础设施上提供一致的云上体验。我们经常能够看到“容器 + Kubernetes”的组合在DevOps发挥10X效率，最近也有越来越多Kubernetes运行在数据中心外（边缘）的需求。
如果要在边缘部署较复杂的应用，那么Kubernetes是个理想的选择：
- 容器的轻量化和可移植性非常适合边缘计算的场景；
- 围绕Kubernetes已经形成了一个强大的云原生技术生态圈，诸如：监控、日志、CI、存储、网络都能找到现成的工具链；
- 支持异构的硬件配置（存储、CPU、GPU等）；
缺点：
然而Kubernetes毕竟是为云数据中心设计的，要想在边缘使用Kubernetes的能力，Kubernetes或其扩展需要解决以下问题：
- ARM的低功耗和多核的特点又使得其在IoT/Edge领域的应用非常广泛，然而大部分的Kubernetes发行版并不支持ARM架构；
- 很多设备边缘的资源规格有限，特别是CPU处理能力较弱，因此无法部署完整的Kubernetes；
- Kubernetes非常依赖list/watch机制，不支持离线运行，而边缘节点的离线又是常态，例如：设备休眠重启；
关于如何在边缘使用Kubernetes，Kubernetes IoT/Edge WG组织的一个调查显示，30%的用户希望在边缘部署完整的Kubernetes集群，而70%的用户希望在云端部署Kubernetes的管理面并且在边缘节点上只部署Kubernetes的agent。
把Kubernetes从云端延伸到边缘，有两个开源项目做得不错，分别是KubeEdge和K3S
我了解的容器docker和Kubernetes（说人话）
因为不太了解这块，看了半天相关的概念和介绍，也是镜中花水中月，不知道这俩说的究竟是个啥，于是去问了同事，得到了以下答复：
- A：k8s用来管理容器，docker是一种容器，容器可以用来把无状态的服务打包成镜像快速部署发布，我知道的有关于k8s 80%的知识都在这了
- B：把容器当成虚拟机就行，虽然和虚拟机有一些差距，作用差不多
- B：就相当于你建了一个虚拟机，你部署好了开发环境，写好了程序。然后你把这个虚拟机直接拷给运维了。
- 我：相当于用docker这种东西，会更容易让开发和运维发布的环境保持一致吗？就是，可以快速部署\发布？
- C：是的。
一些想法
要发挥我在硬件侧的经验
要做对硬件友好，能落地的应用
为什么是5G和边缘计算是强相关？
我大学就是学无线电的。而从5G发布以来，我就对他可以说是毫无兴趣，因为以下两点。
- 觉得5G似乎除了网速更快，根本没啥用。而这个更快的网速能带来什么？目前来说，无非是锦上添花，因为像目前看1080P直播所需要的网速，4G完全能够满足了。
- 5G那么高的频率，波长的绕射能力极差，信号在传输过程中容易被各种物体所遮挡。需要极其大量的部署基站才能达到一定的覆盖量。在宣传的5G智能场景，比如自动驾驶中，根本无法实现全程5G信号覆盖。
我甚至觉得市场上种种吹嘘5G的根本就只是在炒作概念，不实的夸张宣传。
但在我学习过程中，我发现5G本身就是一个TO B的产品，而不是TO C的。因为在云网融合的大趋势下，核心网功能的微服务化，虚拟化在不断的进行。标准的X86服务器也能够通过虚拟机和容器来部署5G的核心网。
而许多中心化的业务，比如高清视频，VR\AR视频，本地自动驾驶网络，如果能够作为一个应用直接部署在(运营商提供的)边缘计算平台MEP上，可以实现5G的三大场景之一uRLLC，即极致的实时通信。
以自动驾驶汽车来说，即使汽车的接入网的信号不是5G，是4G或是其他协议，只要能够使用部署在边缘的本地自动驾驶网络，那么也可以认为这个汽车，其实也是一个5G应用！(吧)
边缘EDGE的产品形态
操作系统：X86-64、arm、arm64
linux，ucos，裸机，npu，FPGA
产品落地形态：
容器型云网融合终端
边缘计算盒终端（可以是低成本硬件，也可以是有AI功能的NPU）
典型的场景，有物联网和非物联网。
下一代工业自动化，智慧城市，智能家居，大型商超等）和非物联网（例如：游戏，CDN等）场景。
问：感觉目前平台主要都只是在做5G核心网云化的产品，也就是5G强相关的边缘计算产品。是否漏掉了像AWS Greengrass这种类型的产品？要不要考虑将5G边缘计算和边缘计算剥离成两个产品？
答：在《华为IEF平台对标报告中》，提到了IEF边缘应用包含两种，一种是容器应用，一种是函数应用。而我们目前只支持容器应用。
而函数应用，华为提供的有node.js/Java/Go/C#等语音SDK（2020.5的报告中IEF只支持python）。而AWS的函数应用lambda支持了Node.js/Python/Ruby/Java/Go/C#/PowerShell
而AWS Greengrass的边缘 greengrass core支持了java，nodejs,python,c这四种，并都提供的有开发包SDK
边缘节点类型
直连设备，网关设备，网关子设备
边缘市场会有怎么样的应用
华为IEF
OneNET EDGE
参考文档
- kubeedge和k3s
- 云网融合-虎嗅
- 什么是K8S service\pod\master\node的概念
- 继续看K8S
- 5g和WIFI6的探讨
（个人研究学习，不保证对哈，欢迎探讨指正！）