MEC Architectural Implications for LTE/LTE-A Networks
Total Page:16
File Type:pdf, Size:1020Kb
MEC Architectural Implications for LTE/LTE-A Networks Chia-Yu Chang, Konstantinos Alexandris, Navid Nikaein, Kostas Katsalis and Thrasyvoulos Spyropoulos Communication Systems Department, EURECOM, France fi[email protected] ABSTRACT point, remote radio units (RRU) of C-RAN) aggregated in Towards 5G mobile networks, the low-latency and high- a (nano-)data center, called Mobile Edge Host (ME host), bandwidth services are highly anticipated; however, legacy that is hierarchically located above the RAN/C-RAN archi- 3G and 4G networks now suffers from the mobile data surge. tecture. The placement of the ME host and its supported In this sense, pushing network services to the network edge services depends not only on the cell deployment (macro- has the potential to improve the traffic latency, user experi- cell, heterogeneous) and backhaul network, but also on the ence, and offload Internet traffic. Although the LTE/LTE-A service requirements and the subscriber distribution of the network can highly benefit from the Mobile Edge Comput- service. While MEC exploits the relevant technologies and ing (MEC) principle, a detailed MEC architecture is not follows general SDN [9] and Network Function Virtualiza- currently in place. In this work, we propose a modular ar- tion (NFV) [7] principles, it aims to go beyond the standard chitecture for the Mobile Edge Host that is ETSI compli- SDN and NFV concepts. For instance, the MEC can adopt ant and describe the functional mapping of the architecture the SDN based unified control-plane architecture to retrieve to LTE systems. Proof-of-concept demonstrations based on and reconfigure real-time network control information for the OpenAirInterface (OAI), a software implementation of its data-plane use case, and also consider Virtual Network LTE/LTE-A systems, present significant benefits of adopt- Functions (VNFs) for the implementation of its components. ing the MEC concept in data caching use case. One of the key challenges to enable the vision of MEC is the design of a framework that is open to high-layer application CCS Concepts development, considers for easy associated services deploy- ment and defines the relevant communication interfaces. •Networks ! Network architectures; Cloud computing; Mo- The contributions of our work are the followings. We bile networks; propose a ETSI compliant modular MEC architecture with Keywords plug-in design; we originally realize the concept of ME host in the proposed architecture and define the services and Mobile Edge Computing, Decentralized Cloud, Caching, 4G, 5G. components' functionalities of the proposed MEC frame- work. These are necessary for higher-layer application de- 1. INTRODUCTION velopment. Then, we demonstrate the mapping of the archi- In order to enable ubiquitous and personalized mobile In- tectural components to the LTE/LTE-A system. Finally, a ternet, it is required to push the boundaries of the existing proof of concept is shown based on OpenAirInterface (OAI) [1] network and service infrastructures. Based on the existing under the distributed content caching use case considering deployment model, endpoint services are deployed in a num- different placements of ME host. To our best knowledge, this ber of (virtualized) data centers, that serve a large number of is the first work aims to provide the ME host architecture users, connected to various Radio Access Networks (RANs). considering the real RAN impact. Our initial focus stays on However, the centralization of resources results in a long sep- the applicability of the proposed architecture to LTE and aration between end users and the associated service, that its evolution; however, the proposed modular architecture brings large end-to-end (E2E) network delays. It restricts remains valid for heterogeneous RAN (e.g., mmWave, Wi- the rapid provisioning of new low-latency and real-time com- Fi) via appropriate modifications on the RAN-specific MEC munication services that require instant contextual informa- functions to enable software-defined 5G that are based on tion about the network and users. For example, in the area SDN/NFV and the Network Slicing concept [10]. of Internet-of-Thing (IoT), sensing and/or actuating devices The remainder of this paper is as follows. Background in- and objects generate a tremendous amount of data and are formation and the proposed MEC architecture are described managed in real-time. This calls for a low-latency communi- in Section 2. MEC communication interfaces and applica- cation interface to efficiently control and share information tion development framework of the proposed architecture for among different networks, providers and geographical areas. LTE are in Section 4. The proof-of-concept demonstration is Mobile-Edge Computing (MEC) [8, 12] is considered as a in Section 5. Conclusions and future work are in Section 6. key enabler to the cloud-computing capabilities at the net- work edge to remedy the delay-sensitive applications and 2. MEC CONCEPT AND RELATED WORK high-bandwidth requirement of current and future RAN ar- MEC provides a low-latency and high-bandwidth collabo- chitecture, such as cloud-RAN (C-RAN). The edge refers to rative cloud environment for application, services, and con- one or multiple RAN nodes (e.g., LTE eNB, Wi-Fi access tent to be placed in close proximity to the network and user. Due to several benefits of MEC to mobile networks, like low port plug-in ME host architecture with following main com- latency, high bandwidth, instant access to the RAN, ETSI ponents: the MEC RAN abstraction interface, MEC appli- launched the MEC industry specification group (ISG) and cation development framework that interplays with higher- provided the standardization initiatives (ETSI MEC 001- layer MEC applications through higher layer API. See Fig- 005) that aim to move from a simple bit pipe to a smart ser- ure 2 for a visual representation of the proposed ME host vice pipe [8,12]. Further, the MEC allows operators to open architecture. Our design complies with ETSI MEC architec- their RAN edge service environment to authorized third- ture and is modular enough to support six use-cases stated parties to rapidly deploy innovative application and service by ETSI [12] following steps in [6]. Further, this design endpoints for the mobile subscribers, enterprises and ver- can inherently supports C-RAN architecture with flexible tical segments [12]. Such applications can be classified into functional split among edge nodes, i.e., RRU and baseband Network-centric (e.g., local connectivity, caching), Informati- processing units (BBU). on-centric (e.g., content optimization) or Device-centric (e.g., MEC RAN abstraction interface: It is in charge of es- client computation offload) [12] (see Figure 1). In summary, tablishing communication channels with the underlying net- the features of MEC are: (i) proximity to end-users, (ii) work(s) to facilitate the control and monitoring of the RAN direct access to real-time network information, (iii) spatio- nodes from the ME host. It abstracts the details of network temporal context awareness, (iv) mobility support, (v) RAN by providing only the necessary information to the MEC agnostic, and (vi) network application distribution platform. application development framework. There are three types Several works consider applications and advantages of ado- of communication channels belonging to the proposed MEC pting the MEC concept. Ref. [12] provides six use-cases and RAN abstraction interface: (a) Radio information interface: the architecture blueprint of the MEC. Ref. [4] categorizes provides direct access to real-time radio information through the applications for deploying services at the mobile edge. a predefined communication protocol, (b) Control-plane in- The REPLISOM architecture in [2] is to deploy cloud com- terface: processes or captures control messages between the puting resources near IoT nodes and apply Device-to-Device RAN and the CN through RAN-specific protocols and (c) links to neutralize the backhauling and routing bottlenecks. Data-plane interface: processes data plane packets between Ref. [5] proposes to offload encoding tasks from mobile de- the RAN and CN. vices to ME host and reduce the power consumption of mo- MEC Application Development Framework: It pro- bile devices. Note that MEC is a complementary approach vides services and APIs for high-layer MEC applications, to the future cellular architecture and an explanation of how and it is composed of four types of services: a real-time context-aware application can be built by col- • Common services: These services are the key services of laborating MEC and 5G RAN is in [11]. Moreover, several ME host and facilitate the usage of the real-time network similar concepts are proposed to enable the edge computing and radio information. On the control plane, the Radio capabilities such as fog computing and cloudlet. A compar- Network Information Service (RNIS) provides an abstract ison between MEC, fog computing and cloudlet is in [13]. view of the network status (e.g., topology, connectivity) by Most of aforementioned studies focus on a top-down view extracting the parameters of interest from the RAN with and examine the MEC concept from the application per- the required level of granularity. On the data plane, the spective; however, the underlying framework inside the ME Edge Packet Service (EPS) brings a native IP service end- host is not fully specified. The ETSI MEC ISG initiates point to the MEC applications. It acts as a local IP agent the ME host framework standardization; however, only the performing network functions, like IP forwarding, packet data-plane part is considered. This paper focuses on the encapsulation/decapsulation and data transcoding. A lo- overall ME host architecture and the associated applica- cal data base exists in both RNIS and EPS to store the tion development framework towards 5G. These will be used underlying network status and configuration. to enable the necessary network abstractions, considering control-plane, data-plane and radio info APIs, application • Platform services: Provide physical and/or virtual re- development and interaction with other network entities.