Difference between revisions of "Apmec"
(→Apmec - OpenStack MEC Orchestration) |
|||
Line 3: | Line 3: | ||
= Apmec - OpenStack MEC Orchestration = | = Apmec - OpenStack MEC Orchestration = | ||
− | Apmec stands for an Automated Platform for Multi-access computing, which is OpenStack based MEC Orchestration framework. Apmec is motivated by ETSI MEC framework and reference architecture [ | + | Apmec [1] stands for an Automated Platform for Multi-access computing, which is OpenStack based MEC Orchestration framework. Apmec is motivated by ETSI MEC framework and reference architecture [2] in order to aim at providing the lifecycle management of MEC applications. |
− | |||
= Architectural Design = | = Architectural Design = | ||
+ | |||
Line 92: | Line 92: | ||
* Launchpad project page: https://launchpad.net/apmec | * Launchpad project page: https://launchpad.net/apmec | ||
+ | |||
+ | = References == | ||
+ | |||
+ | [2] https://arxiv.org/abs/1805.09251 | ||
+ | |||
+ | [1] http://www.etsi.org/deliver/etsi_gs/MEC/001_099/003/01.01.01_60/gs_MEC003v010101p.pdf |
Revision as of 11:53, 8 June 2018
Apmec - OpenStack MEC Orchestration
Apmec [1] stands for an Automated Platform for Multi-access computing, which is OpenStack based MEC Orchestration framework. Apmec is motivated by ETSI MEC framework and reference architecture [2] in order to aim at providing the lifecycle management of MEC applications.
Architectural Design
MEC Catalog
- MEA Descriptors
- MEC Services Decriptors
MESO
It is responsible for jointly coordinating the operations of MEO’s and MANO’s orchestrators. This module becomes the unique entry points to APMEC for user requests on resource of both MEC application and NS. Without MESO, users need to interact with two frameworks for provisioning a service. MESO’s single interface simplifies further the operations of APMEC’s users. MESO provides dispatching functionalities to forward separately the requirements for APMEC and MANO modules. Since MESO has a broader view on both MEC and NFV, it is responsible for smart decisions on the placement of MEC applications as well as NSs to optimize for a set of requirements. The use of MESO also make it simpler for APMEC to interact with different MANOs. For each additional MANO framework, MESO might need to develop an adapted interface, while keeping the internal operations unchanged. Using a unified data model, MESO allows users to describe the MES whose description contains information for both the requested NS and MEA.
MEO
It is mainly responsible for coordinating resources across various VIMs and deciding where to deploy MEAs. Through the API provided by MEM, MEO can make requests for the life cycle of the MEAs (initiation, deletion, update, etc.). Since MEO has global view of resources across multiple VIMs, MEM can also make a request to obtain VIM access from MEO so that the life cycle of the MEAs can be performed on the specific infrastructure. Such a design helps MEO to avoid bottleneck when managing the life cycle of the MEAs accross multiple VIMs.
MEM
It is in charge of MEA instances’ life cycle, which includes automated provisioning, monitoring, configuration, healing, and scaling. They are managed by several modules as follows. The automated provisioning functionality is in charge of receiving and dispatching users’ requests for MEC applications. MEM provides an API for APMEC users to send their requests on MEC application’s resources (CPU, memory, network, etc.). Then, the module translates those requests into a VIM’s understandable format. Finally, MEM converts requests into VIM’s function calls to actually instantiate MEA instances.
Use Cases
Virtual Reality & Augmented Reality (VR & AR)
VR & AR are two main use cases in APMEC. Using APIs provided by Apmec, OSS/BSS could deploy these applications efficiently.
Edge Content Caching
Apmec supports APIs to automatically deploy Edge Content Caching services. With the support of multi-VIM, Apmec takes into account the deployment of Edge Content Caching services closely to end users. That could help significantly reduce latency when using Apmec.
vCPE
Apmec supports a set of APIs that allows OSS/BSS to manage the life-cycle of MEC services and applications. Besides, Apmec is planning to make container services (Kubernetes, Docker,..) become the main focus in the future. Such enhancement could help to deploy vCPE closely to end users.
Connected Cars
Since connected cars require low-latency communication, deploying the connected car controller at the edge is essential in aiding the development of the connected cars. Apmec is willing to support them by enabling the acceleration technologies to lower the latency.
Robotics
Since robotics also require low-latency communication, deploying the connected car controllers at the edge is essential in aiding the development of the robotics. Apmec is willing to support them by enabling the acceleration technologies to lower the latency.
Documentation
TOSCA for MEC
Since MEC is immature and is now becoming one of main use cases in OpenStack, the initial step is now in-progress to adopt TOSCA for the automated provisioning of MEC applications: https://review.openstack.org/#/c/570797/
Repos
Git | |
---|---|
Apmec Server | https://git.openstack.org/cgit/openstack/apmec/ |
Apmec Python Client | https://git.openstack.org/cgit/openstack/python-apmecclient/ |
Apmec Horizon | https://git.openstack.org/cgit/openstack/apmec-horizon/ |
Gerrit | |
Apmec | https://review.openstack.org/#/q/status:open+project:openstack/apmec,n,z |
Apmec Python client | https://review.openstack.org/#/q/status:open+project:openstack/python-apmecclient,n,z |
Apmec Horizon | https://review.openstack.org/#/q/status:open+project:openstack/apmec-horizon,n,z |
Reviews
Bugs
https://bugs.launchpad.net/apmec
Points of contact
- Launchpad project page: https://launchpad.net/apmec
References =
[2] https://arxiv.org/abs/1805.09251
[1] http://www.etsi.org/deliver/etsi_gs/MEC/001_099/003/01.01.01_60/gs_MEC003v010101p.pdf