Mobile Edge Computing (MEC) is a key piece of the 5G architecture (or 5G type claims on a 4G RAN). MEC can already make a huge difference in video latency and quality for video streaming multiple feeds within a sporting environment. For example Intel, Nokia and China Mobile video streams of the Grand Prix at Shanghai International Circuit.
A 5G mobile operator will be introducing virtualised network functions as well as mobile edge computing infrastructure. This creates both opportunities and challenges. The opportunities are the major MEC use cases included context-aware services, localised content and computation, low latency services, in-building use cases and venue revenue uplift.
The challenges include providing the Mobile Edge Compute Platform in a virtualised 5G world. Mobile operators are not normally IaaS / PaaS providers so this may become a challenge.
The ETSI 2018 group report Deployment of Mobile Edge Computing in an NFV environment describes an architecture based on a virtualised Mobile Edge Platform and a Mobile Edge Platform Manager (MEPM-V). The Mobile Edge Platform runs on NFVI managed by a VIM. This in turn hosts the MEC applications.
The ETSI architecture seems perfectly logical and reuses the NFVO and NFVI components familiar to all virtualisations. In this architecture the NFVO and MEPM-V act as what ETSI calls the Mobile Edge Application Orchestrator” (MEAO) for managing MEC applications. The MEAO uses NFVO for resource orchestration and for the element manager orchestration.
The difficulty still lies in implementing the appropriate technologies to suit the MEC use cases. Openstack (or others) may provide the NFVI and Open Source Mano (or others) may provide the NFVO; however what doesn’t exist is the service exposure, image management and software promotion necessary for a company to on-board MEC.
If MEC does take off what is the likelihood that AWS, GCP and Azure will extend their footprint into the telecom operators edge?
Smart M2M devices require authentication & registration with the mobile network. Standardisation of service is proposed by the ETSI Service Capability Layer deployed to the Mobile Internet Device / Gateway. Security between the network and the mobile internet device requires authentication, key agreement and establishment that enable M2M Service Bootstrap, provisioning and M2M Service Connection procedures that are grounded on a clearly defined key hierarchy of the M2M Node.
The European Telecommunications Standards Institute’s M2M Release 1 provides standardised security mechanism for the reference point mobile internet device. This architecture is based upon the following principles:
- ETSI M2M adopted a RESTful architecture style with information represented by resources structured as a tree
- ETSI M2M standardises resource structure that resides on an M2M Service Capability Layer (SCL) where each SCL contains a resource structure where the information is kept
- M2M Application and/or M2M Service Capability Layer exchange information by means of these resources over the defined reference points
- ETSI M2M standardises the procedure for handling the resources
The SCL is deployed to the M2M mobile Internet device (mId) / gateway and requires authentication & registration with the M2M network. ETSI M2M provides standardised security mechanisms for the reference point mId. Mobile Internet Devices/gateways hold secret keys protecting the connection in a “secured environment” and are provisioned with the key M2M Root Key (Kmr).
This requires using RESTful operations over the mobile internet device:
- M2M Service Bootstrap: provision M2M service provider assigned ID & M2M Root Key (Kmr)
- M2M Service Connection: mutual AuthN of mobile internet device end points & generation of M2M Connection Key (Kmc – derived from Kmr)
- (Optional) Mobile Internet Device security: establishment of secure communication over mobile internet device based on Kmc (and sub-keys)
ETSI M2M Security Standards