1.2 MEC
为了规范形形色色的边缘计算,ETSI首先希望各厂商在做边缘计算的时候有标准可循,这便是MEC。MEC最初是移动边缘计算的简写,后来经过一段时间的演化和扩展,将边缘能力从电信蜂窝网络延伸到其他接入网络,MEC也逐渐引入了多接入边缘计算的含义,它包括以下三层含义。
·多接入:多种网络接入模式,如LTE、无线Wi-Fi、有线、ZigBee、LoRa、NB-IoT等各种物联网应用场景。
·边缘:网络功能和应用部署在网络的边缘侧,尽可能靠近最终用户,降低传输延迟。
·计算:联合云计算和雾计算,充分利用计算、存储和网络等有限资源。
MEC制定了边缘计算的一系列标准规范,主要包括:技术需求(MEC002)、框架和参考架构(MEC003)、MEC PoC过程(MEC-IEG 005)和API框架(MEC009)。后面还提出了IaaS管理、API和PaaS服务、API相关规范。目前ETSI小组已经把工作重心转向第二阶段任务,即寻找关键行业应用(如V2X、IoT、工业自动化和VR/AR)、关键用户案例和需求(如网络切片和容器支持),开展与NFV集成的标准化工作,以及把MEC集成在5G网络中等。
MEC概念的提出和相应规范的推进,从以下4方面奠定了边缘计算的基石:应用服务使能和框架完善;API定义原则;服务相关的API标准化;MEC管理和服务编排。
在应用服务使能和框架完善上,MEC考虑了应用服务的注册、发现和通知机制,规范了应用服务的安全认证和授权,还定义了服务与服务间的通信机制。在API定义原则上,MEC确保开发者使用的是一套一致且统一的API接口。特别地,在服务相关的API标准化上,关键应用服务相关的API接口更是被统一化且标准化了。在MEC管理和服务方面,MEC参考NFV,使得MEC主机管理既可以作为单独的资源进行独立管理,也可以作为NFV管理框架的一部分进行集中管理,而且可以确保MEC应用服务在合适的时间部署和编排在正确的位置上。
MEC愿景是在网络边缘侧为应用服务开发者和内容提供商提供云计算和IT服务环境能力。这种环境最大的特点便是低延迟和高带宽,同时,这种环境赋予了应用服务实时访问无线网络信息的能力。在MEC愿景里,MEC未来将孕育一个崭新的生态系统和价值链。在这个生态系统里,电信运营商可以开放无线接入网(RAN)边缘,授权第三方企业,允许第三方企业把那些面向移动租户、企业和垂直细分市场的极具创新的应用和服务快速灵活地部署上来。
虽然MEC愿景是十分美好的,但它毕竟是欧洲电信标准化协会ETSI提出来的,欧洲和电信业便是它的局限性,这个标准和参考架构并不是所有的厂商和所有的行业都认可的。有些边缘计算项目及案例不完全是遵照MEC这个标准规范来做的,甚至完全没有参考MEC去实现。尽管世界存在不同的声音,但是不得不承认,现在ETSI还是边缘计算行业的领头羊,它的MEC标准规范目前仍是边缘计算的重要基石和主要依据。
1.2.1 MEC原则
在MEC规范里,定义了MEC的7个通用原则,分别是MEC与网络功能虚拟化(NFV)对齐、移动性、部署独立性、API简单可控、智能化调度应用服务、应用与系统可脱离、功能可描述性。
MEC在移动网络边缘侧也是使用虚拟化平台运行应用服务的,这与网络功能虚拟化为网络功能提供虚拟化平台类似。因此,为了节约成本,最大化利用现有设备和资源,重用为NFV建设的虚拟化平台,让其既能支持虚拟网络功能(VNF)又能支持MEC应用服务,就显得十分有必要。但是,NFV和MEC存在一定的差异,要让虚拟化平台基础设施同时支撑NFV和MEC,就必须进行相应的增强和改进。这就是MEC与NFV对齐的原则。
移动性是第三代合作伙伴计划(3GPP)网络的一个必要特性。大多数连接到3GPP网络中的设备无时无刻不处在移动过程中。即便是固定的设备,它们也是具备移动能力的,特别是当它们位于边缘的时候,这种能力会更加显著。对于MEC的应用,有些是状态独立的,有些却是需要在移动中维护上下文(Context)的。为了支持用户设备的移动性,MEC系统需要支持服务的连续性、应用服务的移动性和用户相关信息的移动性。
部署独立性指的是MEC系统应该支持各种各样的部署场景和部署位置,而且对部署方面的需求不应该是强制的,而应该是可选的。当一个MEC平台部署到一台主机上之后,MEC服务应当收集覆盖区域内所有无线节点的信息。为了防止非法访问,需要有效建立MEC应用服务与无线节点之间的认证和安全通道。
API简单可控比较容易理解,指的是API设计和实现要尽量简单,且管理员可以动态控制访问权限。
智能化调度应用服务是指MEC系统可以根据各种条件,智能地调度MEC应用服务的位置,使MEC应用服务在合适的时候处于最适当的地方,而且MEC系统需要提供系统级的应用服务生存周期管理。
当应用服务需要保证其连续性的时候,MEC系统能够把一个应用服务从MEC系统迁移到其他云环境或从其他云环境迁移到MEC系统。迁移既包括应用服务本身,也包括它所需要的用户数据和环境上下文信息,这便是应用与系统可脱离。
最后,任何MEC系统或框架的需求都可以用文档描述出来,并且一组需求描述可以定义成一项功能,这就是功能可描述性。
1.2.2 MEC框架
MEC规范了以软件为形态的各式各样的移动边缘应用,这些应用以虚拟化技术为基础,运行在虚拟基础设施之上,位于或靠近网络边缘侧,MEC框架如图1-1所示。
图1-1 MEC框架
在MEC框架里,整个系统实体被分成三个层级:系统层、主机层与网络层。在系统层里有用户设备(UE)、第三方和移动边缘系统层管理;在主机层里有移动边缘主机、移动边缘平台、虚拟基础设施(如NFVI)和移动边缘应用,还有移动边缘主机层管理;在网络层里,有3GPP网络、本地网络及外部网络。
首先,在系统层里,用户设备指的是用户访问边缘计算应用和服务的终端,如手机,该终端里安装了用户设备应用,可以简单地把它们看作客户端,它们的顺利运行是要依靠服务器端的移动边缘应用协同工作的。这里的服务器端仍然是在边缘计算系统里的,并不是数据中心里的服务器。
第三方指的是在移动边缘计算系统外的信息系统或企业,它们也可以是消费移动边缘应用的实体。
移动边缘系统层管理是一套管理软件,我们将在后面阐述它和移动边缘主机层管理的组成部分。
在主机层里,移动边缘主机提供物理资源,在物理资源的基础上利用虚拟化管理软件(VMM)营造出一个虚拟基础设施,就像NFV里的NFVI一样。虚拟基础设施提供计算、存储和网络虚拟资源,这三者亦是云计算里的三个基础资源。
移动边缘应用则是运行在这个虚拟基础设施里的应用软件,它们与移动边缘平台交互,消费着移动边缘平台提供的服务,同时为边缘用户设备应用提供移动边缘服务。移动边缘应用是移动边缘计算里的一环,它们既是消费者,又是生产者。移动边缘应用通常跟一系列规则和需求相关联,如运行该应用需要多少资源、最大可容忍的延迟长度、还依赖什么其他服务等。这些规则和需求往往由移动边缘系统级管理组件管理和验证。
移动边缘平台是一组支撑移动边缘应用的功能集,它负责以下几点。
·提供环境,使移动边缘应用能被发现、传播、消费并生产移动边缘服务。
·从移动边缘平台管理器、应用或服务那里接收网络导流规则,并相应地传达给虚拟基础设施的数据面。
·从移动边缘平台管理器那里接收DNS记录,并相应地配置DNS服务器。
·托管移动边缘服务。
·提供永久存储访问权限和时间信息。
现在我们可以看出移动边缘主机、移动边缘平台和虚拟基础设施之间的关系。移动边缘主机包含移动边缘平台和虚拟基础设施。移动边缘主机的目标就是运行移动边缘应用。虚拟基础设施涵盖数据面,该数据面负责从移动边缘平台接收网络导流规则,并遵循规则在应用、服务、DNS、3GPP网络、本地网络及外部网络之间导流。
移动边缘系统由移动边缘主机和移动边缘管理组件组成,它的目标是确保移动边缘应用能在运营商网络里运行。这里的移动边缘管理组件由移动边缘系统层管理和移动边缘主机层管理组成。移动边缘系统层管理主要包括移动边缘编排器,而移动边缘主机层管理主要包括移动边缘平台管理器和虚拟基础设施管理器(VIM)。
1.2.3 MEC参考架构
前面提到在移动边缘计算系统里有众多实体,其中有软件,也有硬件,它们共同完成相应的职责,从而形成整个移动边缘计算系统,除此之外,实体与实体之间还有一些参照点(Reference Points),它们负责处理实体间的关系和通信。
MEC参考架构描述的就是这些实体和参照点功能组件,告诉大家如何实现这些实体功能,如何摆放它们的位置,如何处理它们之间的交互,以及如何协同工作完成边缘计算的任务等。
MEC参考架构如图1-2所示,除了前面提到的实体,它还涵盖移动边缘系统层管理组件和移动边缘主机层管理组件,以及三类组件间的参照点。
图1-2 MEC参考架构
1.移动边缘系统层管理组件
移动边缘系统层管理组件包括移动边缘编排器、运营支撑系统(OSS)和用户应用生存周期管理代理。
(1)移动边缘编排器。
移动边缘编排器是整个移动边缘系统层管理组件的核心,主要负责以下几点。
·维护整个移动边缘系统,展现全局视图,如可用的资源、可用的移动边缘服务及其拓扑。
·启动移动边缘应用包,包括检查应用包的完整性,认证应用包的可用性,验证应用规则和需求,如有必要,则根据运营商策略调整应用规则和需求,记录并跟踪已启用的应用包,并为它们准备虚拟基础设施管理软件(VIM)。
·根据各种约束条件(如延迟、可用资源和可用服务),为移动边缘应用选择合适的移动边缘主机。
·启动和终止移动边缘应用。
·根据需要重定位移动边缘应用所运行的主机,使它们能迁移到新的位置继续运行。
(2)运营支撑系统。
运营支撑系统指的是运营商的运维支撑系统,它从面向客户服务(CFS)门户界面或从用户设备接收实例化或终止移动边缘应用的请求,并对这些请求进行授权,再将它们导向移动边缘编排器进行进一步的处理。
(3)用户应用生存周期管理代理。
用户应用是指响应来自用户设备的请求,在移动边缘系统上启动的移动边缘应用。这里有两个应用的概念,切勿混淆。
·移动边缘应用,即上节里所比喻的服务器端。
·用户设备应用,是运行在用户终端设备的应用,即上节里所比喻的客户端。
用户应用生命周期管理代理允许用户设备应用请求启动、终止甚至重定位移动边缘应用。它也允许将移动边缘应用的状态通知给用户终端设备的用户设备应用。
用户应用生命周期管理代理也授权来自用户设备应用的请求,允许它们与运营支撑系统和移动边缘编排器交互,并进一步处理请求。另外,用户应用生命周期管理代理仅能在移动网络里被访问,而且只能在移动边缘系统里使用。
2.移动边缘主机层管理组件
前面讲述的都是移动边缘系统层管理组件及它们的功能。接下来我们来介绍移动边缘主机层管理组件,包括移动边缘平台管理器和虚拟基础设施管理器。
(1)移动边缘平台管理器。
移动边缘平台管理器负责以下几点。
·管理移动边缘应用的生命周期,包括通知移动边缘编排器与应用相关的事件。
·为移动边缘平台提供基础管理功能。
·管理移动边缘应用规则和需求,包括服务认证、网络导流规则、DNS配置和冲突处理。
移动边缘平台管理器也接收由虚拟基础设施管理器发送的虚拟化资源错误报告和性能评估结果,以供进一步处理。
(2)虚拟基础设施管理器。
虚拟基础设施管理器负责以下几点。
·分配、管理和释放构成虚拟平台的基础虚拟化资源,包含计算资源、存储资源和网络资源。
·配置基础设施,并接收、存储和启动软件镜像。
·快速部署移动边缘应用。
·收集和报告虚拟资源的性能和错误信息。
·迁移并重定位移动边缘应用。
这里的虚拟基础设施管理器与NFV里的虚拟基础设施管理器没有太多的不同,OpenStack和Kubernetes就是它们较典型的例子。
细心的读者会发现上述功能中有些功能有重叠,如移动边缘编排器会负责迁移和重定位移动边缘应用,虚拟基础设施管理器也负责迁移和重定位移动边缘应用。了解移动边缘编排器工作原理的人会知道,它们之间属于调用和被调用的关系,移动边缘编排器会调用虚拟基础设施管理器完成迁移的任务,而虚拟基础设施管理器则会调用更底层的虚拟化管理软件去完成相应的底层任务。
3.三类组件间的参照点
(1)第一类。
我们称第一类参照点为移动边缘平台间的参照点(Mp),分别有Mp1、Mp2和Mp3。
·Mp1:Mp1位于移动边缘平台和移动边缘应用(ME App)之间,该参照点提供服务注册、服务发现、服务间通信支持。它还提供其他功能,如应用可用性、重定位过程中的会话状态支持、网络导流规则和DNS规则激活、永久存储的访问和时间信息等。
·Mp2:Mp2位于移动边缘平台和虚拟基础设施数据面之间,该参照点被用来指导数据平台怎样在应用、网络和服务之间导流。
·Mp3:Mp3位于移动边缘平台之间,该参照点用来控制移动边缘平台之间的通信。
(2)第二类。
第二类参照点我们称之为管理参照点(Mm),分别有Mm1~Mm9。
·Mm1:Mm1位于移动边缘编排器和运营支撑系统之间,该参照点用于在移动边缘系统里触发移动边缘应用的实例化和终止。
·Mm2:Mm2位于运营支撑系统与移动边缘平台管理器之间,该参照点负责移动边缘平台的配置和性能管理。
·Mm3:Mm3位于移动边缘编排器和移动边缘平台管理器之间,该参照点用于进行应用生命周期管理、应用规则和需求管理、应用平台基础管理。
·Mm4:Mm4位于移动边缘编排器与虚拟基础设施管理器之间,该参照点用于管理应用镜像和移动边缘主机的虚拟资源,包括跟踪可用资源容量等。
·Mm5:Mm5位于移动边缘平台管理器与移动边缘平台之间,该参照点是用于执行平台配置、应用规则和需求配置、应用生命周期支持、应用重定位管理等操作的。
·Mm6:Mm6位于移动边缘平台管理器与虚拟基础设施管理器之间,该参照点是用来管理虚拟资源的,如实现应用生命周期管理。
·Mm7:Mm7位于虚拟基础设施管理器与虚拟基础设施之间,该参照点用于管理虚拟基础设施。
·Mm8:Mm8位于用户应用生命周期管理代理与运营支撑系统之间,该参照点用于处理来自用户设备的在移动边缘系统里运行应用的请求。
·Mm9:Mm9位于用户应用生命周期管理代理与移动边缘编排器之间,该参照点用于管理来自用户设备应用请求的移动边缘应用。
(3)第三类。
第三类参照点我们称之为连接外部实体的参照点(Mx),有Mx1和Mx2。
·Mx1:Mx1位于运营支撑系统和CFS门户之间,Mx1常常被第三方使用,向移动边缘系统请求在其系统里运行应用。
·Mx2:Mx2位于用户应用生命周期管理代理与用户设备应用之间,Mx2被用户设备应用使用,用于向移动边缘系统请求运行一个应用,或者请求将一个应用移入或移出移动边缘系统。而且,这个参照点只能在移动网络内被访问,且只在移动边缘系统支持的情况下可用。
至此,已经基本阐述完MEC的参考架构组件,如前面所述,虽然有众多的组件和反映组件间关系的参照点,但是规范并不要求每个边缘计算系统实现所有的组件和参照点,每个边缘计算系统也没有必要完全实现MEC参考架构里所有的组件和参照点,这在后面的开源软件项目里可以得到印证,规范仅仅是规范而已。