An architecture for mobile computation offloading on cloud-enabled ...

IEEE WCNC

2014

- Workshop on Cloud Technologies and Energy Efficiency in Mobile Communication Networks

An architecture for mobile computation offloading on cloud-enabled LTE small cells Felicia LOBILLOl, Zdenek BECVAR 2, Miguel Angel PUENTEl, Pavel MACH2, Francesco LO PRESn3, Fabrizio GAMBETTI4, Mariana GOLDHAMERs, Josep VIDAL 6, Anggoro K. WIDIAWAN7, Emilio CALVANESSE8 1 ATOS, 4 Dune

Spain ([email protected]), S.R.L., Italy,

5 Four

2 Czech

G CelleX, Israel,

Technical University in Prague, Czech Rep,

6 Universitat

3 University

Politixnica de Catalunya (UPC), Spain,

7 PT.

of Rome "Tor Vergata ", Italy,

Telekomunikasi Indonesia, Tbk,

Indonesia, 8Commissariat a l'Energie Atomique et aux Energies Alternatives, France.

this latency by deploying cloudlets [2], which bring stor age/computation resources closer to the mobile user through single-hop large bandwidth links. In parallel, current trends in radio resource management in mobile heterogeneous networks also indicate that it is beneficial to approach transmitters and receivers in order to provide higher spectral efficiency. Bringing both computation and radio resources closer to the end-user are two trends this paper (produced in the framework of the European project TROPIC [4]) merges in a single frame work, which we denote as small-ceIl-cloud, where a cluster of small cells support the cloudlet functionality. The small-cell cloud access points, called "Small Cell enhanced Node B's cloud enabled" (SCeNBce), are used to provide not only short range wireless access but also proximity storage/computation resources. The small-ceIl-cloud architecture enables a series of advan tages. Firstly, it preserves the benefits offered by conventional cloudlets: i) typically energy-scarce mobile devices can offload highly demanding computational tasks into proximal fixed units; ii) strong reduction of latency compared to centralised clouds, thus facilitating the delivery of real-time applications; iii) storage of large amounts of data or software by mobile devices over neighbour SCeNBces, supporting a distributed self-managing storage; iv) the potential introduction of a wide range of proximity-based services such as home security control, augmented reality, etc. Secondly, it can exploit the joint radio and cloud side management to improve the overall performance. The de ployment of the application over the small-ceIl-cloud can contemplate not only the computational capacity of a set of candidate nodes, but also their radio features. For example, data can be exchanged directly between the mobile terminal and the computing node (which may differ from the radio serving node) through radio channels in case there is coverage and radio channels offer better performance than the wired one between the radio serving and computing node. Another possibility is also that SCeNBces can communicate Over the Air (OTA). The adoption of small-ceIl-clouds by Mobile Network Operators (MNO) involves additional investment, thus it is recommended to consider different aspects before choosing a small-ceIl-cloud deployment approach. The criteria for analy sis include, among others, the current architecture on which the small-ceIl-cloud will be based, energy-efficiency, cost, target

Abstract-Small cell networks are currently seen as a new way to satisfy the increasing wireless traffic demand. The proximity of base stations to subscribers brings many possibilities for the development of new applications, including new offerings based on cloud computing. Smartphones can directly offload applications to close base stations, provided that these are equipped with additional computational and storage resources. The cloud concept applied in the framework of small cells can also combine radio and computation aspects in order to optimise the service delivery. This paper introduces a new element called the Small Cell Manager (SCM), which optimises the overall operation of a cluster of cloud-enabled small cells. The SCM, aware of the cluster situation in terms of both radio and cloud aspects, interacts not only with the cloud-enabled base stations, but also with LTE core network components. To that end, different possibilities for the general architecture of a small-cell-cloud are analysed. Furthermore, the paper describes different evaluation criteria an LTE operator has to consider before adopting this approach in order to optimise the required investment and maximise benefits.

Index Terms-LTE, mobile cloud computing, femtocells, small cells, computation offloading, small cell manager, network archi tecture

I.

INTRODUCTION

The current trend in wireless cellular communication net working is the deployment of heterogeneous networks where macrocells coexist with small cells over the same geographical area [1]. This provides a strong improvement of system per formance thanks to a more efficient usage of radio resources. Small cell networks play a specific role in providing high bitrate and full coverage within an area. At the same time, there is a strong tendency towards mobile cloud computing as a way to extend mobile devices' capabilities and battery lifetime. Mobile devices will always remain intrinsically resource-poor in terms of storage and processing capabilities when compared to static hardware. Moreover, their size, weight and battery lifetime are higher priorities than enhancing computing power, which is an intrinsic limitation of handsets [2]. Computing offload to an external cloud can be leveraged especially for computationally intensive processing such as speech or face recognition, natural language processing, translation, etc., but one of the main challenges to overcome is the lack of control of the end-to-end delay and jitter over a Wide Area Network (WAN) such as the Internet, which is critical in the case of real-time interactive applications. One solution is to reduce

978-1-4799-3086-9/14/$31.00 ©2014

IEEE

1

IEEE WCNC

2014

-

Workshop on Cloud Technologies and Energy Efficiency in Mobile Communication Networks 2

users (residential, corporate), etc. Because network architec tures differ from one operator to another, a single deployment model will not suit all operators. The TROPIC project [4] proposes the inclusion of the Small Cell Manager (SCM) as a new centralised entity within the LTE architecture that manages the overall small-cell-cloud operations within a cluster of SCeNBces. The SCM is in charge of the management of the cloud resources in the small-cell-cloud, which presents certain differences compared to traditional clouds, e.g., the dynamicity of the scenario, since SCeNBces can be switched on and off at any time. This involves dynamic and elastic management of resources within the small-cell-cloud. The SCM also manages the service lifecycle -a service is understood as a collection of Virtual Machines (VMs) that are deployed over the cloud to serve a certain user-. The SCM is aware of the overall cluster context (both radio and cloud wise) and decides where to deploy a new service or when to migrate an on-going service in order to optimise the service delivery for the end user considering radio and cloud as a joint problem. For example, the SCM may decide to deploy a service in a radio neighbour node in case the SCeNBCE to which the user is attached cannot fulfil the request, thus, optimising the service delay. Since the SCM is a new element in the LTE architecture, in this paper we define several options and we highlight the convenience of these alternatives according to a set of evaluation criteria, extracting conclusions in order to guide operators willing to provide small-cell-cloud based services to their end users. The rest of the paper is organised as follows: The next section provides an overview of the LTE architecture and suitable scenarios for small-cell-cloud applications. Section III introduces the required modifications of the LTE architecture in order to enable a small-cell-cloud. Several options of the small-cell-cloud architecture are described in Section IV. Evaluation and comparison of all options are carried out in Section V along with the definition of criteria and parameters considered in the process. Major conclusions and potential future enhancements of the architecture are summarised in Section VI. II. LTE

Security GW

HeNS ________,-________�' ' �-----r----�

L-

Figure 1. LTE overall architecture

S-GW

(Serving Gateway), part of the operator's core network, serving as mobility anchor when the UE moves between base stations; the S-GW is controlled by the MME through the Sll interface. MME It processes the signalling data between the UE and EPC (Evolved Packet Core); it chooses the S-GW for a UE; it manages handover; it authen ticates and authorises the user by interacting with the HSS through the S6a interface. (Packet Data Network Gateway), connecting the P-GW user traffic from the S-GW to a general packet data network (such as the Internet), IMS and other operator services. HeNB-GW Optional gateway -only used in the case of femtocells- deployed to allow the S1 interface between the HeNBs and the EPC to support a large number of HeNBs in a scalable manner. (Home Subscriber Server), entity containing HSS user's subscription and authentication-related in formation. It also stores data for the current user's connection. Optional element for both user and control traffic Sec-GW that enables secure backhaul transmissions. Three variants are agreed by 3GPP for LTE HeNB Network Architecture [3]. In variant 1 (Figure 2), which only applies in the case of femtocells, the HeNB-GW serves as a concentrator for the control plane and also terminates the user plane towards the HeNB and towards the Serving Gateway. In variant 2 (Figure 3), which applies for small cells in general, there is no HeNB-GW; Sl-U interface terminates in S-GW and Sl MME in MME; the HeNB may have connections to multiple MME/S-GW. In variant 3 (Figure 4), again only relevant for femtocells, the HeNB-GW serves as a concentrator for the control plane (Sl-MME); the Sl-U interface terminates in S Gw.

BACKGROUND

This section briefly introduces the general LTE architecture [3], which is the reference framework in which small-cell clouds will be enabled. The following entities and logical interfaces are included: eNBs

SCeNBs

EPC

EUTRAN

The LTE base stations, serving either macro cells or small cells. The eNBs are connected: to the MME (Mobility Management Entity) through the S I-MME interface, carrying control messages; to the S-GW (Serving GW) through the Sl-U interface, transporting user data; with each other through the X2 interface, to exchange signalling information when needed. LTE small-cell-cloud enabled base stations, en hanced with computational and storage capabili ties; located in the immediate user proximity; they are interconnected by the X2 interface.

III.

DEPLOYMENT OF THE

SCM

IN AN

LTE

ENVIRONMENT: ARCHITECTURAL OPTIONS

This section intends to provide architectural approaches an MNO can embrace for taking full advantage of the small-cell cloud concept. The most suitable option is strongly related to the strategy and preferences of the operator. Criteria such

2

IEEE WCNC

2014 - Workshop on Cloud Technologies and

Energy Efficiency in Mobile Communication Networks

Uu

UE

Figure 2. LTE Variant 1 (only for HeNBs)

Uu

UE

Figure 5. SCM as an extension of the HeNB-GW

Figure 3. LTE Variant 2

�

as the current deployment of the own LTE architecture on which the small-cell cloud will be based, the target segment (residential, corporate), energy efficiency or cost are criteria that need to be analysed. The architecture options explained in this work are studied under several assumptions that help establish a simplified framework reducing the number of alternatives: •

•

�

•

Sl-U

Uu

UE

Figure 6. Standalone SCM

The framework is 3GPP architecture, according to release 11 [3]. All SCeNBces in the architecture belong to the same MNO.

MNO's network. As mentioned above, variants 1 and 3 are only applicable in the case of femtocells.

All options are built taking into account the following require ments: •

Uu

UE

B. Standalone SCM

Another option (for all variants) is to place the SCM as a standalone element as close as possible to the cluster (Figure 6 depicts this case for variant 2, although this option is possible with variants 1 and 3 in the case of femtocells as well). In this case, a new Sec-GW is needed to secure the conununications between SCM and SCeNBces. The SCM is not located at the MNO's core network and it communicates to the EPC's components through the Z' interface.

Avoid functional duplicity by taking as much advantage as possible from LTE features (for example, for user authentication the HSS should be used by contacting the MME). Avoid as much as possible the modification of existing interfaces. The SCM, as a new component in the network, will interface with LTE legacy nodes through dedicated interfaces when required.

As the SCM is a new component, the Z interface is introduced to connect the SCeNBces and the SCM. Moreover, an addi tional Z' interface is introduced to support cOlmnunications between SCM and MME. The next subsections describe three possible architectures for the placement of the SCM.

C. SCM as an extension of the MME

Another interesting deployment is to locate the SCM at the MME (Figure 7 depicts this case for variant 2 although this option is also possible for variants 1 and 3). The Sec GW present at the EPC is used to secure the communications between SCM and SCeNBces. In this case, there is not Z' interface since the SCM is an extension of the MME and it can be accessed directly.

A. SCM as an extension of the HeNB-GW

In case a HeNB-GW exists (variants 1 and 3), one option is to leverage its existence and place the SCM as an extension of this node (Figure 5 depicts this case for variant 1). The Z interface communicates HeNBces and SCM traversing the existing security gateway at the HeNB-GW. The SCM can communicate with the other EPC components within the

[] ...

Uu

UE

UE

Figure 4. LTE Variant 3 (only for HeNBs)

Figure 7. SCM as an extension of the MME

3

IEEE WCNC

2014

-


End User

Manufacturer

Operator

• ••• •••

•• • ••

••• •• ••

SCM computational capacity requirements

•

•••

••

Cost of deployment and maintenance

•

•••

•••

Implementation complexity

•

••

•••

Impact on current LTE deployments

•

••

•••

Energy consumption

•

••

•••

Signalling Overhead Latency Computation/Storage performance

4) UE population: medium to high for FUEs and medium to high for MUEs in the corporate building. 5) SCeNEs operator, i.e., MNO: the femtocells network in the building operated by a single MNO serving one corporate customer with closed SCeNBs for registered UEs. 6) Mobile Backhaul operator (i.e. FNO): the backhaul network can be provided by one or several operators. 7) Application Servers are provided by a single Cloud Application Service Provider. 2) Public scenario: In this scenario, the small cells cloud solution serves public users inside public buildings such as train stations, airports or malls, with specific location cloud solution offered to all visitors. The related network topology is characterised by:

Table I WEIGHTED EVALUATION CRITERIA FOR DIFFERENT STAKEHOLDERS

I V.

1) Availability of macrocells, but not enough indoor cov erage and capacity for all users. 2) Backhaul availability: metro-Ethernet, FTTX (GPONIGEPON). 3) SCeNE deployment: from one to many SCeNEs. 4) UE population: medium to high for FUEs, medium to high for MUEs in the public building. 5) The SCeNEs belong to a single MNO (A) and may serve other users from other MNOs (at least one operator, let say B) provided that there is a roaming agreement between A and B. 6) Mobile Backhaul operator (i.e. FNO): the backhaul network can be provided by one or several operators. 7) Application Servers are provided by a single Cloud Application Service Providers and possible multi SCV .

EVALUATION OF INDIVIDUAL ARCHITECTURE OPTIONS

In this section, we first define the criteria for comparison of the architectural options and their relevance for users, manufacturers and operators. Then, the options are evaluated and compared to one another using these criteria. Finally, architectures are matched to different scenarios. A. Evaluation criteria

The architectural options need to be compared in order to select the best one for each scenario. The comparison needs to take into account that the different criteria cannot be all equally considered. Different stakeholders can consider one of these aspects as critical or not that relevant. For instance, latency is more critical for the end user than for a device manufacturer whereas energy consumption in the network is more important for an operator than for an end-user. This is why these different criteria can be weighted according to what should be more important for each of these stakeholders and this has been included in the evaluation as a dimension to consider. Table I contains the relevance of each criterion for each stakeholder (. not relevant, •• relevant, ••• very relevant).

3) Residential scenario : In this scenario, small cells cloud solution serves residential users inside their premises (apartments or landed houses), supporting their daily home activities. The related network topology is characterised by: 1) Availability of macrocells, but not enough indoor cov erage and capacity for residential users. 2) Backhaul availability: FTTX (GPONIGEPON), xDSL. 3) HeNB Deployment: one - two HeNEs (in this case, SCeNEs are femtocells). 4) UE Population: low for FUEs, low to medium for MUEs. 5) The HeNEs belong to a single MNO (A) and may serve other users from other MNOs (at least one operator, let say B) provided that there is a roaming agreement between A and B. 6) Access method: Closed to Hybrid from same operator.

B. Scenarios

From the deployment point of view, we can differentiate three main scenarios for LTE SCeNBs: corporate, public and residential. These scenarios differ in transmission power, number of users, type of backhaul connectivity and access mode (open, closed, or hybrid) and each of them have different implications when analysing the most suitable architecture for the small-cell-cloud deployment. 1) Corporate scenario: In the corporate scenario, the small cells cloud solution serves corporate users inside an office building, supporting daily office activities. The related network topology is characterised by:

C. Comparison of architectural options

The SCM as an extension of the HeNE-GW (only valid for femtocells) brings several advantages such as less implemen tation complexity and less impact on current LTE systems. However, this approach might increase the latency perceived by the end user, since operations involve a distant node. The standalone SCM option is a suitable option mostly in corporate scenarios, which allow the deployment of the SCM in the customer's premises. This option may potentially improve latency and reduce the signaling overhead in the

1) Availability of macrocells, but not enough indoor cov erage and capacity for corporate users. 2) Backhaul availability: corporate intranet, metro Ethernet, FTTX (GPONIGEPON). 3) SCeNEs deployments: from one to many SCeNEs.

4

IEEE WCNC

2014

-

Workshop on Cloud Technologies and Energy Efficiency in Mobile Communication Networks

SCM as an extension of HeNB-GW

Standalone SCM

SCM as an extension of the MME

Requirements coverage

•••

•••

•••

Signalling overhead

•• ••• •

•• ••• •

••• • •••

Cost of deployment and maintenance

•

•

•••

Implementation complexity

•

•

•••

Impact on current LTE deployments

••

••

•••

Energy consumption

•

•

•••

Latency Computational/Storage performance

LTE-Uu air interface and SCeNBce - SCM communications through the Z-interface. The functionality provided by the Z-protocol over LTE-Uu is the foLLowing: • •

•

The functionality provided by the Z-protocol over the Z interface is the following: • •

Table II COMPARISON OF ARCHITECTURES FOR LTE

•

• • •

MNO network. Moreover, it is reasonable for an MNO to control and manage the SCM which, for a standalone mode, is possible in a corporate scenario but not feasible in a residential one. The SCM as an extension of the MME decreases complexity and aLLows for a greater control of the operation by the MNO. Besides, in case of microceLLs-as a public indoor scenario-, where the use of a gateway is not required, the MME is a reasonable choice for placing the SCM. FinaLLy, since the number of MMEs is smaller than the number of HeNB-GWs for an operator, the number of required SCMs is smaLLer than in the case in which the SCM is placed at the HeNB-GW and the number of SCeNBces managed by one SCM is greater, which increases computing and storage capabilities. Table II shows the suitability of the different architectural options with regards to different comparison aspects. (••• very suitable, •• suitable, • less suitable). The best deployment choice for a MNO depends on the operator's strategy and preferences: •

•

•

•

Secure channel creation between SCeNBce and SCM. SCeNBce registering in the cluster. SCeNBce monitoring. The SCM must have an overaLL view of the cluster situation. SCeNBce cloud management. Cloud services deployment, management and monitoring. Dynamic re-aLlocation of cloud services. Data transmission among SCeNBces and SCM.

The SCM also needs to gather user data stored in the HSS. This data is queried and returned over the Z' interface. An example of user's data the SCM may need is: • • •

Authentication information. Subscription information. Communication information. For example, current serv ing access point. VI. C ONCLUSIONS

AND FUTURE WORK

In this paper, we have introduced a new concept named smaLL-ceLL-cloud by merging the paraLLel trends of smaLL-ceLLs and cloudlets. The smaLL-cell-cloud nodes are small ceLLs equipped with enhanced computation and storage capabilities. Small-cell-clouding enables to offload mobile computing load, extending mobile device's battery life; it also reduces latency, bringing computing nodes closer to the end user. The smaLL ceLL-cloud concept requires modifications in the conventional architecture of cellular networks as a new entity (SCM) must be integrated for the purpose of coordinating the overaLL cluster operation. We have analysed different architectural options the operators may choose to implement the smaLL-ceLL-cloud within existing LTE deployments. Further studies not included in this paper involve scenarios with multiple smaLL-ceLL-clouds in which resources of different clusters can be combined for greater computation and storage capabilities or even for bursting and offloading. Moreover, backhaul delays may be reduced by introducing advanced approaches in which the SCM's features are carried out by in a hierarchical way or by the SCeNBces themselves. This seems chaLLenging and its efficiency needs further study, since the dynamic scenario of smaLL-ceLL-clouding requires the duplication of information across aLL SCeNBces and increased signalling within the cluster. FinaLLy, as for the SCeNBce SCeNBce communication, the use of the backhaul seems to be the simplest choice provided that it can cope with the traffic requirements although, alternatively, Over the Air communication can be used when SCeNBces belong to a smaLL cluster and have visibility of one another.

In a residential scenario with femtoceLLs, the best ap proach seems to be the placement of the SCM as an extension of the HeNB-GW. In corporate scenarios: the best possible approaches are 1) to place the SCM as an extension of the HeNB-GW or 2) to deploy a Standalone SCM (provided that the latency between SCM-SCeNBs is acceptable). In a public indoor scenario: the best possible approaches are 1) to place the SCM as an extension of the HeNB GW, 2) to deploy an In-cloud standalone SCM (provided that the latency is acceptable) or 3) SCM as an extension of MME (if microceLLs are considered).

V.

Offloading support for the VE. SignaLLing. Exchange of control messages between UE and SCeNBce. Transmission of user application data to and from the serving SCeNBce.

SMALL-CELL-CLOUD PROTOCOL S

The new capabilities and management functionalities intro duced by the smaLL-ceLL-cloud are not addressed by the current protocols used in LTE. Therefore, we introduce an application layer protocol, denoted as Z-protocol, to cover the smaLL-ceLL cloud functionalities. This protocol has two main transport segments: UE -SCeNBce communications over the existing

5

IEEE WCNC

2014

-


ACKNOWL E DGMENT

This work has been performed in the framework of the FP7 project TROPIC IST-318784 STP, which is funded by the European Community. The Authors would like to acknowledge the contributions of their colleagues from TROPIC Consortium (http://www.ict-tropic.eu). REFERENCES [1] J. G. Andrews, H. Claussen, M. Dohler, S. Rangan, M. C. Reed, "Femtocells: Past. Present, and Future,"IEEEJournal on Selected Areas in Communications, Vol. 30, No. 3, April 2012. [2] M. Satyanarayanan, P. Bahl, R. Caceres, N. Davies, "The Case for V M Based Cloudlets in MobileComputing," IEEE Pervasive Computing, Vol. 8, No. 4, October 2009. [3] 3GPPTS 36.300 v 11.3.0, "3rd Generation Partnership Project; Technical Specification Group Radio Access Network; Evolved Universal Terres trial Radio Access (E-UTRA)and Evolved Universal Terrestrial Radio Access Network (E-UTRAN); Overall description; Stage 2 (Release 11)," September 2012. [4] FP7 project TROPIC: "Distributed computing, storage and radio resource allocation over cooperative femtoceUs," ICT-318784, www.ict-tropic.eu.

6