OpenNESS，开源的边缘网络服务平台

《5G 与 MEC 边缘计算》
《DPDK 网络加速在 NFV 中的应用》
《数据中心网络架构的问题与演进 — NFV》

OpenNESS（Open Network Edge Services Software）是一个开源的边缘应用程序管理系统，使服务提供商和企业能够在任何网络的边缘上构建、部署和操作自己的边缘应用程序（ME APP），支持通过简易的方式将运行在 Telco/Public Cloud 中的 APP 迁移到边缘。

OpenNESS is an Open Platform that enables Service Providers and Enterprises to build, deploy, and operate an Edge Services Management System on any Network Edge.

同时，OpenNESS 还是一个边缘网络的服务平台，支持在多云环境中跨越多种类型的网络平台（Network Platform，e.g. NTS、OvS、vPP）以及多种类型的访问技术（Access Technologies，e.g. S1_U、SGi、IP）。让用户能够轻松的编排和管理运行在边缘上的应用程序，并为客户端（UE）和边缘应用程序提供端到端（End to End）的网络连接服务。

An open source software toolkit to enable easy orchestration and management of edge services across diverse network platform and access technologies in multi-cloud environments.

注：端到端是一种网络连接。网络要通信，必须建立连接，不管有多远，中间要经过有多少机器，都必须在两头（源和目的）间建立连接，一旦连接建立起来，就说已经是端到端连接了，即端到端是逻辑链路。端到端是传输层的，TCP 就是用来建立端到端连接的协议。比如你要将数据从 A 传送到 E，中间可能经过 A→B→C→D→E，对于传输层来说并不知道 B，C，D的存在，传输层只认为报文数据是从 A 直接到 E 的，这就叫做端到端。一旦通信完成，这个端到端的连接就会释放，物理线路可能又被别的应用用来建立连接了。

简而言之，OpenNESS 就是一个可以充当 ETSI MEC 参考模型中的 MEPM、MEP 以及 Data Plane 角色的平台级开源软件。

• MEPM（ME platform manager，移动边缘平台管理器）：具有 MEP 元素管理、ME APP 生命周期管理以及 ME APP 的规则与需求管理等功能。
  • ME APP 生命周期管理：包括 ME APP 的创建和终止，并且为 MEO 上报 ME APP 相关事件的指示消息。
  • ME APP 规则与需求管理：包括身份认证、流量规则、DNS 配置和 UE 切换导致的冲突协调（非合作博弈，纳什均衡算法）等。
• MEP（ME platform，移动边缘平台）：从 MEPM、ME APP 或 ME Service（支撑 MEP 的底层 Services）处接收流量转发规则（Traffic Rules），并且基于转发规则向 Dataplane（数据面）下达转发指令。另外，MEP 还支持本地 DNS 服务、代理服务器的配置，可以将数据流量重定向到预期的 ME APP 或 ME Service。MEP 还可以通过 Mp3 参考点与其他的 MEP 进行通信，在分布式 MEC 系统的协作机制中，Mp3 参考点可以作为不同 MEP 互联协作的基础。
• ME APP（移动边缘应用） ：是运行在 ME VIM 上的 Application 实例，ME APP 通过 Mp1 参考点与 MEP 相互通信。Mp1 参考点要求提供 ME APP 可用性（Availability）标识，发生 UE 切换时为用户准备或重定位 ME APP 会话状态等额外功能。

根据 ETSI MEC 参考模型，OpenNESS 采用了 Edge Controller Software（简称 Controller）与 Edge Platform Software（简称 Edge）分离的分布式软件架构设计思路。其中，Edge Controller Software 充当着 MEPM 的角色运行在 Data Center 或 Cloud 中，而 Edge Platform Software 则充当 MEP 以及 Dataplane 的角色运行在任何 Network Edge 之上，包括：uCPE（通用客户端设备）、vRAN（虚拟无线接入网）以及 NGCO（新一代的电信机房，或称中央办公室）。

Edge Controller Software 的功能清单

前端 WebUI、用户账号管理、边缘应用镜像注册、EPC CUPS核心网配置、边缘节点生命周期管理、边缘应用生命周期管理、边缘虚拟化基础设施管理、监控。

• Web UI front end
• User account management
• Edge compute application image repository
• Core Network Configuration
• Edge Node Lifecycle Management
• Edge Application Lifecycle Management
• Edge virtualization infrastructure management
• Telemetry

Edge Platform Software 的功能清单

Edge Node 注册、Edge Node 网络接口配置、本地 DNS 服务、Edge Node 虚拟化基础设施、ME APP 流量策略、数据平面服务、应用认证。

• Edge Node Enrolling（Edge Node 注册）：在 Edge Node 首次启动时，需要注册到 Controller 中。由 ELA 完成。前提是需要拿到 Controller 颁发的 CA 证书来建立 TLS API 通信。

• Edge node interface configuration（Edge Node 网络接口配置）：在 Edge Node 注册到 Controller 之后，Edge Node 会将自身的 Network Interface 信息上报到 Controller。以此作为配置 Upstream、Downstream 或者 local breakout 网口（Local Break-out Port，LBP）的依据。由 ELA 完成。

• DNS service（DNS 服务）：为 ME APP 提供 DNS 服务，属于数据面的 DNS。基于 Go DNS library 实现。

• Edge Node Virtualization infrastructure（Edge Node 虚拟化基础设施）：从 Controller/NFV-O 接收启动或停止 ME APP VI 的请求，并执行操作。由 EVA 完成。

• Edge application traffic policy（ME APP 流量策略）：为 ME APP 设置数据面流量转发策略。由 EDA 完成。

• Data Plane Service（数据平面服务）：通过 Edge Node 上运行的 NTS 服务，将数据面的流量导向 ME APP 或 LBP APP。使用了 DPDK 进行 I/O 加速。

• Application Authentication（应用认证）：对 ME APP 进行身份认证/鉴权，以确定 APP 之间具有权限可被调用。只有在 ME APP 打算调用 Edge Application Authentication APIs 时才会进行认证，支持 TLS 连接。需要注意的是，Edge Application Authentication APIs 仅对 Native ME APP 有效，因为 LBP APP 和 Ported ME APP 都不会在 EAA 中进行注册。

NOTE：Edge Node 资源使用要求

• 所有非关键/非实时（non-critical/non-realtime）的微服务推荐绑定在 Core 0 上运行。
• NTS Dataplane 微服务和 DPDK PMD 推荐进行 CPU 绑定。
• 为 DPDK 库使用大页内存。
• 使用 RT kernel，在 VNFs 和 APPs 共存的场景中。

OpenNESS 提供了两种参考部署方案，On-Premise Edge 和 Network Edge。两者最明显的标准在于 VI（虚拟化基础设施）的提供形式，前者提供的是本地的 VI，即 Edge Node 之上的 Docker/Libvirt；而后者提供的则是 MEC VIM 基础设施。用户应该针对不同的场景，考虑使用不同的部署方案。

On-Premise Edge Deployment

On-Premise Edge Deployment，又称为企业级部署方式，Edge Platform Software 部署在 uCEP 上，处于企业网络范围内，而 Edge Controller Software 则部署在 Telco/Public Cloud 之上。

On-Premise Edge Deployment 面向的是将 Edge Node 作为 IaaS 子系统的应用场景，是中心业务向边缘的延伸。在该场景中，用户的需求只是单纯的希望 APP 可以尽量的靠近其服务的终端，来处理一些实时性要求比较强的业务。

所以只需要为 ME APP 提供一个可用于运行的 x86 服务器作为 Edge Node 即可，Edge Platform Software 直接通过 Edge Node 上的 Docker/Libvirt 部署 VI，无需添加 VIM。也因此，该部署方式也只能针对一个租户来使用，而并非是专门为 MEC 而设计的部署方式（MEC 要求多租户可以使用同一边缘云）。通过应用于客户办公室、工厂、体育场或其他单租户设施中。

Network Edge Deployment

Network Edge Deployment，Edge Platform Software 部署在 NFVI 之上，运行于 NGCO 或 vRAM 的无线接入聚合点（Wireless Access aggregation point）中。而 Edge Controller Software 则同样部署在 Telco/Public Cloud 之上。

该部署方式不再面向单一或小规模的 Edge Node，而是拥有针对 MEC 的虚拟化基础设施管理系统（VIM），即：边缘计算基础设施（OpenStack/Kubernets）。要求边缘计算基础设施位于网络运营商的设施内，并作为数据网络（Data Network，包含接入网，核心网以及边缘计算基础设施）的一部分，与 OSS 集成在一起。应用于多租户场景，并且规模非常大。Edge Controller Software 不仅可以管理边缘计算基础架构，还可以通过网络连接管理网络基础架构。是更加贴近于 ETSI MEC 参考模型的部署方式。

抽象架构

首先看 OpenNESS 的抽象架构与接口类型，完全符合 ETSI MEC 参考架构标准。

• 红色框为 OpenNESS 核心组件：Edge Controller Software、Edge Platform Software 以及 Data Plane；
• 绿色框为 ME APP：可以分为 Edge Native APP 和 Public Cloud APP。
  • Edge Native APP：原生在 Edge Platform 上运行的 APP，这是我们讨论的重点。
  • Public Cloud APP：即从公有云迁移到 Edge Platform 的 APP。
• 蓝色框为 OpenNESS 与蜂窝网络（Cellular Network）集成所需要的互补性商业解决方案：比如 MEO、VIM 等等。

ME APP 的类型

从 ME APP 的作用区别，又可以分为：

• Producer APP（生产者应用）：又称 Edge services，为其他 ME APP（Consumer APP）提供服务。 它不直接为最终用户提供服务。e.g. 定位服务，地图服务，代码编译服务等等。

  • 调用 Producer APP 必须要进行身份认证（Authenticate）以及获取 TLS。
  • Producer APP 必须被其他 ME APP 发现后才能够被调用，而 Producer APP 被发现的前提是要激活它们。
  • Producer APP 必须具有若干个用于提供 Notification Update（更新通知）的字段，以此来传递消息。

• Consumer APP（消费者应用）：直接为最终用户提供服务，Consumer APP 可以选择订阅若干个 Producer APP 为其提供服务。E.g. CDN 服务，AR 服务，VR 服务，视频服务等等。

  • 如果 Consumer APP 无需调用 Edge Application APIs，也就无需进行身份认证。Edge Application APIs 负责为所有 ME APP 提供 API Endpoint，继而对外提供 Services。
  • Consumer APP 可以订阅若干个 Producer APP，后续版本中要会加入创建 ACL（访问控制列表）的功能。
  • Consumer APP 与 Producer APP 之间的 Notification Update 通过 Web Socket Connection 来完成，Connection 由 Consumer APP 发起创建。这种方式还可以用于 ME APP 与其他的 NFVI 组件（e.g. OVS/VPP/NIC-VF）进行通信。

软件架构

在看 OpenNESS 的软件架构，Edge Controller Software 和 Edge Platform Software 均由一组特定的微服务组成，微服务之间使用 gRPC（Google Remote Procedure Calls）进行通信。

• WebUI Font END：Web 前端操作界面。

• Edge Platform/Controller Gateway：Edge Controller Software 与 Edge Platform Software 之间进行通信的物理路由网关。

• EAA（Edge Application Agent）：映射到 ETSI MEC Mp1 参考点，作为 ME APP 与 MEP 交互的媒介。Mp1 参考点要求可以标识 ME APP 的可用性、会话状态重定位等功能。

  • EAA 提供了 Edge Application APIs 给 ME APP 调用，提供服务发现，服务注册，服务间通信等功能，并且支持验证 ME APP 的可用性，支持 UE 切换（基站）时需求的 ME APP 会话状态重定位。激活从 Edge Controller Software（MEPM）通过 ELA 下发的针对 ME APP 的 Traffic Rules 和 DNS rules 配置。
  • EAA 提供了 Edge Application Authentication APIs 对所有打算调用 Edge Application APIs 的 ME APP 进行身份认证，在验证了 ME APP 的身份之后会向该 APP 颁发 TLS 证书，正式建立通信通道。

• ELA（Edge LifeCycle Agent）：映射到 ETSI MEC Mm5 参考点，作为 MEPM 和 MEP 交互的媒介。Mm5 参考点要求实现对 MEP 的配置、对 Traffic Rules 的配置，并且负责管理 ME APP 会话状态重定位方式以及支持 ME APP 的生命周期管理。

  • ELA 提供了 Edge Lifecycle Management APIs 供 Edge Controller Software（MEPM）调用，进行 MEP 配置的下发（Configuration of Edge Platform）等操作；
  • ELA 通过调用 EAA 提供的 Edge Application APIs 下发的针对 ME APP 的 Traffic Rules 和 DNS rules 配置，同时也支持 ME APP 的会话状态重定位等功能；
  • ELA 通过调用 EVA 提供的 Edge Virtualization Infrastructure APIs 来完成 ME APP 的生命周期管理；
  • ELA 通过调用 EDA（NTS）来完成针对 Upstream/Downstream Interface 的 Traffic Rules 和 DNS rules 配置的下发。

• EVA（Edge virtualization Agent）：映射到 ETSI MEC Mm6 和 Mm7 参考点。其中 Mm6 作为 MEPM 和 VIM 的交互媒介，要求支持收集 VIM 虚拟资源信息以及 VIM 虚拟资源使用和管理；Mm7 作为 VIM 和 Dataplane 的交互媒介，完成数据流量的过滤和转发。

  • EVA 提供了 Edge Virtualization Infrastructure APIs，支持虚拟化资源的管理。需要注意的是，在 OpenNESS 中，虚拟化资源区分为 On-Premise Edge Deployment 中的 Edge Node（Docker/Libvirt）或者是 Network Edge Deployment 中的 MEC VIM（OpenStack/Kubernets）。为了实现后者，在 Edge Controller Software 实现了一个 External EVA Service， 该 Service 会直接调用 External Orchestrator（OpenStack/Kubernets）进行 VI 的部署。
  • 需要注意的是，OpenNESS 没有实现 Mm7 参考点，而是直接通过 EDA 对 NTS 的调用来完成数据转发规则的配置。

• EDA（Edge Dataplane Agent）：映射到 ETSI MEC Mp2 参考点，作为 MEP 和 Data plane 之间的交互媒介。在 ME APP，网络，ME Service 之间完成数据路由转发。

  • OpenNESS 实现了 EDA 来对接 NTS。NTS 本身的 API 是没有保留的，所以 EDA 可以看作是 NTS 的 API。

• NTS Dataplane（Network Transport Service Data Plane）：数据面转发模块，将指定的流量规则应用到 Edge Platform 上，实现数据分发。

• DNS Server：作为 Edge Platform DNS 服务器，应用于 ME APP。而对于不运行在 Edge Platform 的 APPs，则充当 DNS 转发器（forwarder）。

• LTE/CUPS Agent：对接 EPC Control Plane，Edge Controller 用于为 Edge Platform 配置 EPC Control Plane 和 EPC User Plane。

对于往返于 ME APP 与 EAA 之间、往返于 Edge Controller Software 与 EPC CP 之间的交互使用了 RESTful API。OpenNESS 就是通过微服务之间的交互，微服务与 ME APP 之间的交互、微服务于其他第三方商业解决方案（e.g. VIM、MEO、NFVO）之间的交互来完成其功能的。

On-Premise Edge Deployment 的软件架构：

Network Edge Deployment 的软件架构：

Edge Application APIs

• Edge Service Activation/Deactivation（边缘服务注册与激活/停用）：该 API Endpoint 使 Producer APP 可以在 Edge Platform 上注册并激活或者停用。执行此 API 之后，Producer APP 才可以被 Consumer APP 发现并使用。e.g. 当 Location Service Producer APP（定位服务提供者应用程序）部署完成后，马上就会调用此接口。

• Edge Service Discovery（边缘服务发现）：该 API Endpoint 使 Consumer APP 可以发现 Edge Platform 上所有已激活的 Producer APP 清单。e.g. CDN Application 通过此接口发现 Edge Platform 上的 Location Service Producer APP。

• Edge Service Subscription/Unsubscription（边缘服务订阅/取消订阅）：该 API Endpoint 使 Consumer APP 可以订阅/取消订阅指定的 Producer APP，并以此获取 Producer APP 的更新通知。e.g. CDN Application 可以订阅 Location Service Producer APP 以获得更新通知。

• Edge Service Notification update（边缘服务更新通知）：该 API Endpoint 的本质是 Web Socket，Socket Connection 由打算订阅 Producer APP 的 Consumer APP 创建。当 Producer APP 有更新时，就通过该 Connection 通知（推送）给 Consumer APP。e.g. 当 Location Service 有更新时，就会推送给订阅了 Location Service Producer APP 的 CDN Application。

• Edge Service data update（边缘服务数据更新发布）：该 API Endpoint 使 Producer APP 可以将其更新的数据发布到 Edge Platform。e.g. Location Service Producer APP 使用该 API 将用户的位置更新数据发布到 Edge Platform。

• Edge Service list subscription（边缘服务订购列表）：该 API Endpoint 使 Consumer APP 获得其可以使用的 Producer APP 清单。e.g. CDN Application 可以通过该 API 得知其是否订阅了 Local Service Application。

Edge Application APIs 作为 Producer APP 与 Consumer APP 之间的消息总线：

OpenNESS（Open Network Edge Services Software）是一个开源的边缘应用程序管理系统，使服务提供商和企业能够在任何网络的边缘（Network Edge）上构建、部署和操作自己的边缘应用程序（Edge APPs），并且支持简易的方式将云中的应用程序迁移到边缘。

边缘应用下发（Onboarding）

Controller 通过 HTTP 方式来提供应用镜像（APP Image）的下载，支持 Docker Image（tar.gz）和 QOCW2 Image 两种格式，ME APP 支持 VM/Container/Pod 三种 APPs 运行方式，对应 OpenStack/K8S/DockerCompose。

1. 在 Controller ui Container 上运行 HTTP/HTTPS Image server。
2. 通过 WebUI 将 APP Images 上传到 Image server。
3. 通过 WebUI 将 APP Images 下载到 Edge Platform 并进行部署。
4. 通过 WebUI 启动 ME APP（VM/Container/Pod）。

边缘应用控制以及流量策略下发

检索 Edge Platform 上所有的 ME APP

ME APP 云适配器（Cloud Adapter）

所谓 ME APP 云适配器，即 APP 通过 Connector（各厂家有不同的实现方式）的方式与 AWS/Baidu Cloud 提供的服务连接起来。例如：Amazon Greengrass 通过 AWS lambda functions 部署到 Edge，并且可以通过 GreenGrass service 作为 IoT 网关回连到 AWS cloud。该功能常被应用于 IoT 场景中，用于数据的收集与回传。

起初要实现这个效果，就需要配合 AWS Edge 解决方案来完成。而 OpenNESS 则提出了一个通用的框架来解决这个问题。OpenNESS 将 Greengrass Core 作为一个 ME APP。可以是一个 Ported Edge APP，保持原来的运行方式；也可以将其修改后的 Native Edge APP 并利用 Edge Application APIs 的优势。

通过 OpenNESS 解决方案，可以在同一个 Edge Node 上运行来自多个不同云厂商（暂时支持 AWS cloud 和 Baidu cloud）的 APPs，轻松的为用户提供多云体验。

NOTE：对于 Public Cloud APP。用户只需要将公有云中的 APP Upload 到 Controller，然后选择 Edge Node 并执行部署即可。该场景中，APP 不可以调用任何的 Edge Application APIs，即不可以与 Edge Node 中的其他 APP 进行交互，仅仅直接为最终用户提供服务而已。

OpenNESS 作为一个边缘网络的服务平台，支持在多云环境中跨越多种类型的网络平台（Network Platform）以及多种类型的访问技术（Access Technologies），例如：LTE 网络、IP 网络。让用户能够轻松的编排和管理运行在边缘上的应用程序，并为客户端（UE）和边缘应用程序提供端到端（End to End）的网络连接服务。

NTS（Network Traffic Service）

NTS 的前身是 Intel NEV SDK。架构图如下：

NTS 提供以下功能：

• Provide Reference API for REST/grpc to C API：提供可供 REST/grpc 调用的 C API。

• Implement Scatter and Gather in upstream and downstream：定义 Edge Platform 的 Upstream/Downstream 接口，并在 Upstream/Downstream 上实现 Scatter（分发）和 Gather（汇聚）。

• Reference Packet forwarding decision independent of IO：独立于 I/O 的分组转发策略。

• Provide Reference ACL based Application specific packet tuple filtering：提供基于数据包五元组（5 Tuple）的 ACL 过滤方式。

• Implement KNI based interface to Edge applications running as Containers/POD：为运行在 Containers/Pod 的 ME APP 提供基于 KNI（Kernel Network Interface）的 interface。

• Implement DPDK vHost user based interface to Edge applications running as Virtual Machine：为运行在 VM 中的 ME APP 提供基于 DPDK vHost user 的 interface。

• Reference implementation which does not depend on EPC implementation：不依赖 EPC 的实现。

• Provide reference Simultaneous IP and S1 deployment：提供 Simultaneous IP（SGi） 和 S1_U deployment 方式。

• Provide reference GTPU base packet learning for S1 deployment：为 S1_U deployment 提供基于分组学习（Packet Learning）的 GTP-U 协议封装/解封装。

• Future enhancement of UE based traffic steering for authentication (not there now)：将来会增加为了身份认证（Authentication）而提供的基于 UE 的流量控制（Traffic Steering）。

NOTE：

• Upstream：从客户端到接入点。
• Downstream：从接入点到客户端。

Upstream Traffic

Edge Platform 可以部署在 LTE 或 IP（Wireless/Wireline，无线/有线）网络上。Edge Platform 在 NTS Dataplane 上提供了一个网络抽象层，将多种协议的差异进行了抽象与封装，所以，无论在什么网络环境中部署，ME APP 都只会看见解封装之后的 IPv4 流量。Edge Node 上的 EDA 与 NTS 提供了配置网络和数据平面的方法，以提供流量控制和进行任何所需要的协议传输单元封装。

• S1_U：Edge Platform 从 LTE eNodeB 挂接到 S1 接口上。该模式下，流量会首先被 NTS Data Plane 截获，再由 NTS 将流量重定向到 ME APP 或上游 EPC。 在该过程中，NTS 需要对 Upstream 流量根据需要进行 GTP-U 封装与解封装。

• SGi：Edge Platform 直接挂接到 SGi 接口上，EPC 出来的 Upstream IP 流量到达 NTS Data Plane，NTS 根据 Traffic Rule 进行转发到 ME APP 或 PDN。

Downstream Traffic

• Native：OpenNESS 原生（Native）支持将流量引导到 Edge Node 上运行的 ME APP 或 IoT GW。ME APP 运行在 Container/VM 上，通过实现 ETSI MEC & NFV 参考架构，ME APP、IoT GW、VNFs 实际上是可以共存、共享 VIM 平台资源的。

• Local Breakout：OpenNESS 支持将流量引导到在用户现存的 IT 基础设施上运行的 LBP APP，即 Applications On Local Breakout Port（LBP）。如下图，用户可以使用 Controller 配置流量转发规则（Traffic Rules），将 Downstream 导向企业 TOR Switch 最终流入 LBP。这种部署方式可以在不修改企业 IT 基础设施的前提下接入 Edge Node，并对原有的 APP 进行创新。

• Packet Data Network（PDN，分组数据网）：统称提供数据服务的网络，例如：因特网。OpenNESS 支持将流量引导至 PND，假如不对这些数据不感兴趣的话。

Traffic Rule Setup

TrafficPolicy 的数据结构如下：

• TrafficPolicy：为指定的 Interface（e.g. ME APP Interface、ME Host Interface）定义一组 TrafficRule。

• TrafficRule：单个流量规则，内含 TrafficSelector 。

• TrafficSelector：定义了需要处理的数据流量类型。

  • MACFilter：指定 Frame 的相关过滤参数。
  • IPFilter：指定 Packet 的相关过滤参数。
  • GTPFilter：指定 GTP 协议封装包的相关过滤参数。

• Add Traffic Rule
  

• Delete Traffic Rule
  

LTE CUPS 流量策略配置

Controller LTE/CUPS Agent（Core Network Configuration APIs edge compute）通过 HTTP RESTful 的方式与 EPC CP 进行通信，以此来配置 EPC CUPS 的流量策略，将 EPC UP 的流量导向 Edge Platform。

NOTE：由于 ETSI MEC 并没有给出 MEPM和 4GEPCControlPlane之间的接口标准，但最起码 HTTP REST 这一调用方式是满足标准的。EPC 可以很方便的将自己的 API 集成到 OpenNESS Controller 中，这里面需要一些定制开发的工作。这样就做到了 MEPM 和 OAM Agent 的完全解耦。

NOTE：

• OAM：操作（Operation）、管理（Administration）、维护（Maintenance）

同时，当 EPC UP 和 Edge Platform 处于同一物理位置（用户面下沉）的情况下，MEAO 会调用 NFVI 资源来为 EPC UP NF 提供VI。在 NFV & MEC 混合的场景中，OpenNESS 建议通过 Controller 来配置和管理这些 NF，MEO 直接调用 Controller API 就可以管理运行在各个 Edge Platform 上的 NF 了。即完全由 OpenNESS Controller 充当 MEPM 角色。

OpenNESS 通过 Controller API 来配置和管理运行在各个 Edge Platform 上的 NF。即完全由 OpenNESS Controller 充当 MEPM 角色，这样就做到了 MEPM 和 OAM Agent 的完全解耦。

• LTE CPUS Traffic setup
  
  

OpenVINO

OpenVINO 是英特尔基于自身现有的硬件平台开发出的一款可以加速高性能计算机视觉和深度学习视觉应用开发速度的工具包，支持在各种英特尔平台的硬件加速器上进行深度学习，也支持异构计算。 支持 Windows/Linux 操作系统，支持 Python/C++ 编程语言。简而言之，OpenVINO 工具包可以快速部署模拟人类视觉的应用程序和解决方案。

OpenVINO 的特点：

• 在英特尔硬件平台上提升计算机视觉相关深度学习性能达 19 倍以上。
• 解除 CNN-based 的网络在边缘设备的性能瓶颈。
• 对 OpenCV，OpenXV 视觉库的传统 API 实现加速与优化。
• 基于通用 API 接口在 CPU、GPU、FPGA 等设备上运行加上。

OpenVINO 工具套件能够：

• 在边缘启用基于 CNN 的深度学习推理。
• 支持跨英特尔 CPU，英特尔集成显卡，英特尔 FPGA，英特尔 Movidius 神经计算棒，英特尔神经计算棒 2 和采用英特尔 Movidius VPU 的英特尔视觉加速器设计的异构计算。
• 通过易于使用的计算机视觉功能库和预优化的内核，加快产品上市速度。
• 包括针对计算机视觉标准的优化调用，包括 OpenCV，OpenCL 和 OpenVX。

OpenVINO 工具套件包括：

• 深度学习部署工具包（DLDT）
  • 深度学习模型优化器：一种跨平台的命令行工具，用于导入模型并使用推理引擎为最佳计算做好准备。模型优化器导入，转换和优化模型，这些模型在流行的框架中进行训练，例如：Caffe、TensorFlow 、MXNet、Kaldi 和 ONNX 等。
  • 深度学习推理引擎：一种统一的 API，允许对许多硬件类型进行高性能计算，例如：英特尔 CPU，英特尔集成显卡，英特尔 Movidius 神经计算棒等。
  • 演示和示例：一组简单的控制台应用程序，演示如何在应用程序中使用推理引擎。
  • 工具：一组简单的控制台工具，用于校准和测量模型的精度。
  • 预先训练的模型：一套用于学习和演示目的的预训练模型或开发深度学习软件。
• OpenCV：一个为英特尔硬件编译的 OpenCV 社区版本，包括用于计算机视觉的 PVL 库。
• OpenCL 2.1 版本的驱动程序和运行时。
• Intel®MediaSDK
• OpenVX：英特尔针对在英特尔硬件（CPU，GPU，IPU）上运行而优化的 OpenVX 部署。

OpenVINO 的架构

OpenVINO 工具包主要包括两个核心组件，模型优化器（Model Optimizer）和推理引擎（Inference Engine）。

模型优化器（Model Optimizer）

模型优化器将给定的模型转化为标准的 Intermediate Representation（IR） ，并对模型进行优化。支持一下深度学习框架：

• ONNX
• TensorFlow
• Caffe
• MXNet
• Kaldi

推理引擎（Inference Engine）

推理引擎支持硬件指令集层面的深度学习模型加速运行，同时对传统的 OpenCV 图像处理库也进行了指令集优化，有显著的性能与速度提升。支持以下硬件设备：

• CPU
• GPU
• FPGA
• VPU

OpenNESS & OpenVINO 运行原理

• OpenVINOProducer APP：服务于 Consumer APP，借助于 OpenNESS EAA 更改通知的方式，将 OpenVINO模型优化器输出的标准的 IR 推送到 Consumer APP 中。
• OpenVINOConsumer APP：服务于最终用户，通过 OpenVINO 推理引擎应用 IR结合各种硬件加速设备对输入的视频流进行图像识别分析。
• 视频流从嵌入式 Linux 客户端设备（UE）上安装的网络摄像头捕获（绿线）。
• 视频流在 OpenNESS Edge Platform上推理分析完成之后再次传输回到 UE 继续进一步的数据分析与应用（红线）。

部署架构

EPC（4G 核心网络）

4G 作为第四代移动通信技术，有着无法比拟的优越性，它能够快速传输语音、文本、视频和图像信息，能够满足几乎所有用户对于无线服务的要求，国际电信联盟对于 4G 系统的标准为符合 100 Mbit/s 数据传输速度的系统，当之无愧的被称为机器之间的高速对话。

LTE（Long Term Evolution）主要研究 3GPP 无线接入网的长期演进技术，升级版的 LTE Advanced 将最终满足国际电信联盟对 4G 系统的要求。SAE（System Architecture Evolution）则是研究核心网的长期演进，它定义了一个全 IP 的分组核心网 EPC（Evolved Packet Core，分组核心演进），该系统的特点为仅有分组域而无电路域、基于全 IP 结构、控制与承载分离且网络结构扁平化，其中主要包含 MME、SGW、、PCRF 等网元。其中 SGW 和 PGW 常常合设并被称为 SAE-GW。

• MME（Mobility Management Entity，移动管理实体），管理会话（Session）状态和认证并追踪网络上的用户。
• SGW（Serving Gateway，服务网关），通过访问网络路由数据。
• PGW（Packet Data Node Gateway，分组数据节点网关），作为 LTE 网络和其它分组数据网络间的端口，管理服务质量（QoS）并提供深度数据包检测（DPI）。
• PCRF（Policy and Charging Rules Function，策略及收费规则功能），支持服务数据流检测、策略执行和计流量收费方式。

uCPE（通用客户端设备）

uCPE（Universal Customer Premise Equipment，通用客户端设备）：uCPE 一词来源于 CPE，后者指位于用户端的网络终端设备（Customer premises equipment，CPE），用于与电信运营商对接服务，是用户端服务提供商解决方案的重要组成部分，这些解决方案提供商通过使用专用集成链路（ASIC）来提供各种服务。

但是，传统 CPE 缺乏灵活性并且成本高昂，安装和维护要求服务提供商部署网络技术人员，耗时很长且非常昂贵。此外，网络基础设施的设备长期以来都是由不同厂商的专用设备构成，例如，一家厂商提供路由器，另一家厂商提供防火墙、WAN 加速器和无线局域网控制器等。因此，业界提出了在通用硬件上来实现不同功能，将两个或更多的网络功能放在标准硬件上来减少购买的设备。以期消除需要不同技能来安装、配置、测试和维护的专有设备，还能降低总体功率和 HVAC 要求。由此，业界产生了现在大行其道的 uCPE。

uCPE 由在开放服务器上托管的标准操作系统上运行的 VNF 组成，理想的 uCPE 部署需要支持多厂商多组件构建。因此，uCPE 将云引入电信网，并成为推动创新的动力。通常情况下，服务提供商希望通过单个通用平台上运行的 VNF 替换专用设备，从而简化用户现场部署，uCPE 提供了通过使用 NFV 将以云计算为核心的技术一直延伸到电信网络接入部分来实现这一愿景的途径。

长期以来，NFV 部署的主要推动力之一是 vCPE，后者能简化操作，减少资本支出和运营成本，加速服务交付。但由于这些设备成本低廉，因此它们通常不够快速或者功能不够强大，并且会限制一些更复杂的服务。uCPE 同样也是一种运行 VNF 的软件解决方案，作为一个可远程管理的平台，托管服务提供商可以通过 WAN 轻松部署、修改或删除客户端 VNF。uCPE 设备同样基于商用硬件，但是它比 vCPE 提供的功能更加强大。因此，uCPE 可以视为 vCPE 的进一步演进的结果。

目前，业界都已认可，uCPE 的真正价值在于按需服务，它具备的优势包括、简化硬件安装，可以在各个站点之间交替混合和匹配、消除对专有网络设备和相关技能的需求、开放式架构使企业能够更快更高效地推出新应用程序、快速有效地部署按需虚拟网络功能、可远程管理的平台简化操作并降低运营成本、单个平台承载多个 VNF、与 OpenStack 等多个主要的第三方编排器兼容。

在部署企业级 uCPE 时，随着带宽消耗的增加，与 SD-WAN 的集成变得至关重要。 SD-WAN 提供了一种在 Internet 上分层的网络结构，因此企业可以自由选择廉价的带宽而不是昂贵的 MPLS 服务。但是，在某些服务级别协议的情况下，公司需要有保证的服务，可能仍然需要 MPLS。在这些情况下，uCPE 仍然可以通过简单地部署适用的 VNF 来处理每项服务来处理 SD-WAN 覆盖网络和 MPLS。企业领域的这种灵活性使得 uCPE 设备确实非常有利。

随着 NFV 进程推进，NFV 项目已覆盖所有核心网网元，5G 成为 NFV 新的最大驱动力，也必将对于网络设备的灵活性提出更高要求。可以预见，在这一背景下，uCPE 市场还将迎来进一步的繁荣。

简单来说 uCPU 就是放在企业内部的 “类路由器” 网关设备，通过 VNF 的方式来代替传统的网络设备，例如：防火墙设备。因为 uCPU 通常是 x86 架构的服务器，所以也可以在之上运行 Edge Platform Software。

vRAN（ 虚拟无线接入网）

vRAN（虚拟无线接入网）是移动网络发展的新趋势，致力于智能化提升容量，大幅降低成本并提升用户体验。它还将提供支持未来服务和应用所需的灵活性和动态可扩展性。基于网络功能虚拟化（NFV）的原则，vRAN 架构通过在商用服务器硬件上运行虚拟化基带功能，超越了集中式 RAN（C-RAN）的最新迭代版本。

由于 CSP（通信服务提供商）面临着满足容量需求的压力，并需在竞争异常激烈的移动服务市场推出差异化产品，因此此时将 NFV 的优势从核心网络扩展到 RAN 的时机恰到好处。

http://www.windriver.com.cn/downloads/files/WP-vRAN-The-Next-Step-in-Network-Transformation-White-Paper-CN.pdf

简单来说，vRAN 就是运行在 RAN 设备上的 VNF。UE 发送的信号会被 RAN 设备接收，然后再封装为标准数据包后发送到 UPF，最终进入核心网。因为现在 RAN 设备也可以是 x86 架构所以也可以在之上运行 Edge Platform Software。

NGCO（新一代中央办公室）

NGCO（Next Gen Central Offices，新一代中央办公室），又称新一代电信机房，是以软件为中心的网络基础架构。通常每个小区都会由一个 CO，每个区镇会有一个更大的 CO。CO 是一个 x86 服务器机房所以也可以运行 Edge Platform Software。

GTP 协议

GTP（GPRS Tunnelling Protocol，GPRS 隧道协议）是一组基于 IP 的通信协议，用于在 GSM 、UMTS 和 LTE 网络中承载 GPRS（General Packet Radio Service，通用分组无线业务）。

GTP 协议目前有 3 个版本：

• Version 0：是早期版本，被 1999 年标准化的 Version 1 替代；
• Version 1：使用于 GSM 和 UMTS 网络，也应用于 LTE 网络中以传输用户面数据；
• Version 2：使用于 LTE 核心网（EPC）。

GTP 协议的用途：GTP 是 GPRS 核心网中使用的主要协议。它使得 GSM 或 UMTS 网络的终端能够在网络中移动位置，同时能持续的通过同一个 GGSN 连接到因特网。为了实现这一功能，GTP 协议总是将用户面数据从用户位置所属的 SGSN 传输到它开户信息所对应的 GGSN。

GPRS 核心网使用三种 GTP 协议：

• GTP-U：用于为每个 PDP 上下文提供一个或多个隧道，用以传输用户数据。
• GTP-C：用于控制目的。包括：PDP 上下文的建立和删除；GSN 可及性验证；位置更新。例如，当签约用户从一个 SGSN 移动到另一个 SGSN。
• GTP’：用于从各个 GSN 传送计费数据到计费网关功能（CGF，Charging Gateway Function）。

GGSN 和 SGSN（合称为 GSN），在 UDP 端口 2123 上监听 GTP-C 消息，在端口 2152 上监听 GTP-U 消息。GTP 协议通信可以通过 GPRS 漫游交换（GPRS Roaming Exchange）发生在不同运营商之间。

计费网关功能（CGF，Charging Gateway Function）在 TCP/UDP 端口 3386 上监听发送自 GSN 的 GTP’ 消息。核心网发送计费信息到 CGF，计费信息至少包含 PDP 上下文激活次数以及终端用户传送的数据量。与 GTP-C 和 GTP-U 不同，GTP’ 协议承载的报文通常只在单个运营商网络内部使用，因此并不那么标准化。运营商可以做特殊的配置，使用特别的编码，甚至使用完全不同的系统来完成计费。

GPRS 核心网和 UMTS 接入网之间的 Iu-PS 接口上，用户面也使用 GTP-U 协议。然而在控制面上并不使用 GTP-C，而是用 RANAP 协议。GTP-U的 隧道在 Iu-PS 接口上也是以 RANAP 协议管理的。

LTE 网络中的 GTP 协议功能与 GSM/UMTS 网络中基本相同。在控制面上 LTE 网络使用 GTPv2-C，用户面上使用 GTP-U，计费相关功能使用 GTP’。在 S1 接口（eNodeB 和 SGW 之间）上，用户面使用 GPT-U 协议。在接入网 X2 接口（两个 eNodeB 之间）上，用户面也使用 GTP-U 协议，控制面使用 X2AP。

S1 接口

S1 接口是 LTE eNodeB（基站）与 EPC（分组核心网）之间的通讯接口。将 LTE 系统划分为无线接入网和核心网。

S1 接口沿袭了承载和控制分离的思想，又分成两个接口，一个用于控制平面（S1-MME），一个用于用户平面（S1-U）。

• 控制平面接口 S1-MME 将 eNodeB 和移动性管理实体（MME）相连，主要完成 S1 接口的无线接入承载控制、接口专用的操作维护等功能。
• 用户平面接口 S1-U 将 eNodeB 和服务网关（S-GW）连接，用于传送用户数据和相应的用户平面控制帧。
  

PDN

PDN（Packet Data Network，分组数据网）是对提供数据服务的网络的一般描述。分组交换（Packet switching）是一种数据传输的模式，这种模式下，一条消息被分成若干部分，这些部分通过对每个分组最合适的路由独立发送，并在目的地重新组合起来。因特网就是一个典型的 PDN。

PGW 与 SGi 接口

P-GW（PDN Gateway，PDN 网关），是面向 PDN 终结于 SGi 接口的网关，如果 UE 访问多个 PDN，UE 将对应一个或多个 P-GW。P-GW的 主要功能包括基于用户的包过滤功能、合法侦听功能、UE 的 IP 地址分配功能、在上/下行链路中进行数据包传输层标记、进行上/下行业务等级计费以及业务级门控、进行基于业务的上/下行速率的控制等。另外，P-GW 还提供上/下行链路承载绑定和上行链路绑定校验功能。

在移动网络中，P-GW 的主要功能是向 UE 分配 IP 地址。UE 可以通过多个 P-GWs 连接到多个 PDN，也可以连接到旧的、不符合 3GPP 的 IP 网络。在 LTE 架构中，P-GW 充当着 user plane mobility 的锚点。用户流量可以在 P-GW 处被过滤，以区分 packet flows 之间的 QoS（服务质量）。P-GW 会收集到充值信息并转发到 CDRs（Charging Data Records）进行处理。

• EPS Bearer：这是与 P-GW 相关联的 UE 的接口。它是一个隧道，用于 IP 地址分配。

• Rx：虽然不与 P-GW 直连，但该接口用于策略和收费规则功能（PCRF，policy and charging rules function），并作为 PCRF 与 IP 多媒体子系统（IMS，IP Multimedia Subsystem）网络之间的交互媒介。IMS 向用户设备提供诸如 IP 语音（VOIP，Voice Over IP）之类的服务。该接口使用 Diameter 协议，通过 Steam 控制传输协议（SCTP）和 TCP 实现，并将 PCRF 权限传递给服务网络。

• SGi：这是 P-GW 与 PDN 之间的接口，通常在这里提供服务。例如用于语音的 IMS、Web、Internet 访问等等。所有流量都是以 IP 数据包和流的形式存在。

• S5：这是与 P-GW 相关联的 S-GW 之间的接口。支持用户平面（User Plane）的 GPRS 隧道协议（GTP）。

LTE CUPS

LTE CPUS（Control and User Plane Separation of EPC nodes），代表 EPC 的控制和用户平面分离。3GPP 为此提出了用于分离演进 SGW、PGW 和 TDF 的功能架构增强。CUPS 使得网络的部署和操作更加灵活，在分布式或集中式的部署场景中，控制平面和用户平面均可以独立进行伸缩，而不影响现有 EPC 节点的功能。

https://www.3gpp.org/cups

OAM

OAM（Operation Administration and Maintenance，操作、维护、管理）是指根据运营商网络运营的实际需要，通常将网络的管理工作划分为 3 大类：操作（Operation）、管理（Administration）、维护（Maintenance），简称 OAM。操作主要完成日常网络和业务进行的分析、预测、规划和配置工作；维护主要是对网络及其业务的测试和故障管理等进行的日常操作活动。

LTE 网格架构

http://dasheyuan.com/post/lte-network-architecture/