introducing mobile edge computing capabilities through
TRANSCRIPT
Introducing Mobile Edge Computing Capabilitiesthrough Distributed 5G Cloud Enabled Small Cells
Jose Oscar Fajardo1 & Fidel Liberal1 & Ioannis Giannoulakis2 & Emmanouil Kafetzakis3 &
Vincenzo Pii4 & Irena Trajkovska4 & Thomas Michael Bohnert4 & Leonardo Goratti5 &
Roberto Riggio5 & Javier Garcia Lloreda6 & Pouria Sayyad Khodashenas7 &
Michele Paolino8 & Pavel Bliznakov8 & Jordi Perez-Romero9 & Claudio Meani10 &
Ioannis Chochliouros11 & Maria Belesioti11
# Springer Science+Business Media New York 2016
Abstract Current trends in broadband mobile networks areaddressed towards the placement of different capabilities atthe edge of the mobile network in a centralised way. On onehand, the split of the eNB between baseband processing unitsand remote radio headers makes it possible to process some of
the protocols in centralised premises, likely with virtualisedresources. On the other hand, mobile edge computing makesuse of processing and storage capabilities close to the air in-terface in order to deploy optimised services with minimumdelay. The confluence of both trends is a hot topic in the
* Jose Oscar [email protected]; http://det.bi.ehu.es/nqas/joseoscar.fajardo
Fidel [email protected]
Ioannis [email protected]
Emmanouil [email protected]
Vincenzo [email protected]
Irena [email protected]
Thomas Michael [email protected]
Leonardo [email protected]
Roberto [email protected]
Javier Garcia [email protected]
Pouria Sayyad [email protected]
Michele [email protected]
Pavel [email protected]
Jordi [email protected]
Claudio [email protected]
Ioannis [email protected]
Maria [email protected]
1 University of the Basque Country (UPV/EHU), Almda Urquijo s/n,48013 Bilbao, Spain
2 N. C.S.R. BDemokritos^, Patr. Gregoriou & Neapoleos, 15310 AgiaParaskevi, Greece
3 ORION INNOVATIONS, Ioulianou, 56 10439 Athens, Greece4 Zurich University of Applied Sciences (ZHAW), Obere Kirchgasse
2, 8400 Winterthur, Switzerland5 CREATE-NET, Via alla Cascata 56D, 38123 Trento, Italy6 ATOS, Albarracín, 25 28037 Madrid, Spain7 i2cat, Barcelona, Spain8 Virtual Open Systems, Grenoble, France9 Universitat Politecnica de Catalunya (UPC), Campus Nord, C/Jordi
Girona 1-3, 08034 Barcelona, Spain10 ITALTEL, Via Reiss Romoli - Località Castelletto 20019, Settimo
Milanese, (Mi), Italy11 Hellenic Telecommunications Organization S.A. (OTE), 1, Pelika &
Spartis,, Maroussi, Athens, Greece
Mobile Netw ApplDOI 10.1007/s11036-016-0752-2
definition of future 5G networks. The full centralisation ofboth technologies in cloud data centres imposes stringent re-quirements to the fronthaul connections in terms of through-put and latency. Therefore, all those cells with limited networkaccess would not be able to offer these types of services. Thispaper proposes a solution for these cases, based on the place-ment of processing and storage capabilities close to the remoteunits, which is especially well suited for the deployment ofclusters of small cells. The proposed cloud-enabled small cellsinclude a highly efficient microserver with a limited set ofvirtualised resources offered to the cluster of small cells. Asa result, a light data centre is created and commonly used fordeploying centralised eNB and mobile edge computing func-tionalities. The paper covers the proposed architecture, withspecial focus on the integration of both aspects, and possiblescenarios of application.
Keywords Centralised mobile networks . Light data Centre .
Small cells . Mobile edge computing . 5G
1 Introduction
In the framework of evolved 4G Long Term Evolution (LTE)and future 5G mobile network architectures, different pro-posals are emerging aimed at overcoming the capacity limita-tions of current Radio Access Networks (RANs). The conceptof Network Softwarization is being proposed to move someRAN-related functions back to shared hardware (HW) ele-ments with high computational capacities, taking into accountseveral trends such as Software Defined Radio (SDR),Software Defined Networking (SDN) and Network FunctionVirtualization (NFV). Complex future content centric Internetand the 5G paradigm suggest the introduction of intelligentnetwork nodes that will enable more powerful adaptation andprioritization frameworks over the whole transmission chain,and especially at the edge of mobile network segments [1].
A Centralised RAN system concentrates different process-ing resources together to form a pool in a central data centre.This aggregation of HWresources in shared locations not onlyreduces deployment costs, but also leverages low latency con-nections between different RAN processing units enabling a
series of enhanced capabilities such as advanced RadioResource Management (RRM) coordination and interferencemanagement [2]. When these resources run over virtualisedinfrastructures, adding flexible and scalable HW resourcemanagement capabilities, the Centralised RAN becomes aCloud RAN (C-RAN) [3]. According to 3GPP terminology,this high degree of centralisation entails a network architecturewhere all the baseband processing is made by BaseBand Units(BBU) at centralised data centres, and radio signals are ex-changed with the Remote Radio Heads (RRH) over high-speed low-latency connections that constitute the mobilefronthaul.
Figure 1 below illustrates different alternatives for thecentralisation of RAN functions. In the Bfully centralisedRAN^ case, the RRH only performs the radiofrequency(RF)-related operations such as the transmission and receptionof the radio signals. The whole upper layer protocol stack isperformed in the centralised entity. Different functions arerequired to become a fully functional evolved Node B(eNB): the physical (PHY) functions, the medium access con-trol (MAC) functions including the scheduling of transmissionopportunities and the Hybrid Automatic Repeat Request(HARQ) functions for coping with radio transmission errors,the Radio Link Control (RLC) protocol, and two distinct pro-tocols for data transmission, including Packet DataConvergence Protocol (PDCP) for the data plane and RadioResource Control (RRC) for the control plane. Besides thesecore functionalities, the eNBmay implement other higher lev-el operations such as Operations, Administration andManagement (OAM) procedures, Self Organizing Networks(SON) features and other types of application-related (APP)functions.
As explained in [4], the requirements of the fronthaul interms of high data throughput and low delays makes this fullycentralised solution nowadays feasible only when optical fibreconnections are deployed. Since this technology is not avail-able everywhere, and its complete deployment entails costlyoperations, other alternatives for partial centralisation are alsoconsidered. The Next Generation Mobile Networks (NGMN)Alliance released a document concerning the fronthaul re-quirements associated to the centralisation of the MAC entity[5]. In order to cope with the typical HARQ timing of 8 ms,
Fig. 1 Fully centralised vs.partially centralised RANfunctional architecture
Mobile Netw Appl
only fronthaul delays of up to 250 μs (in terms of one-waylatency) are acceptable. Higher latency fronthaul technologiesrequire the application of HARQ interleaving, in orderto delay the HARQ process. Similarly, the Small CellForum performed a comprehensive analysis includingother possible functional splits between centralised andremote functions [6, 7]. Concerning the MAC-PHYsplit, the conclusion for the standard HARQ processingis the same than in the NGMN case: fronthaul delays of up to250 μs are acceptable.
Alternatively to the Bfully centralised RAN^ case, theBpartially centralised RAN^ approach allows splitting theeNB functionalities in a flexible way. Depending on the select-ed functional split, the associated requirements for the remoteand central HW and for the fronthaul connection are variable.
Beyond the pure centralisation of an eNB functions, thecurrent trends towards Bcloudification^ of the RAN also al-lows reusing the available HW infrastructure for deployingservice instances at the edge of the mobile network. One ofthe emerging technologies to cope with more personalised anduser-centric service provisioning is the novel Mobile EdgeComputing (MEC) industry initiative [8], a promising ap-proach to solve these types of problems from an operator-supported perspective. This initiative proposes that mobilenetwork operators would provide an API to third-party part-ners, offering them access to critical features such as locationawareness and network context information. This informationmay be exploited to deploy proximity-enabled services withclose-to-zero latency characteristics, in order to optimise themanagement of future mobile networks. Regardless of theadopted architecture for C-RAN, MEC-driven service in-stances must be deployed over the cloud resources availableat the RAN side. Taking Fig. 1 as a reference, these types ofMEC services would be deployed as BAPPS^ features. Thus,the degree of coupling between service-level instances andother RRM functions may differ.
Besides the logical split of the RAN and MEC functions,the physical distribution of the HW resources must be alsotaken into consideration. Figure 2 illustrates two different al-ternatives considering centralised and distributed HW re-sources. Focusing on the problem of deployingMEC services,only the upper layers of the protocol stack are considered forcentralisation in Fig. 2.
In the first case (Fig. 2a), the upper RAN functions arelocated in powerful data centres that are ideally connected tothe RRHs through high-speed and low-latency fronthauls.According to [6, 7], fronthaul delays of up to 30 ms can betolerated for a proper operation of the LTE stack. Yet, highfronthaul delays may degrade the performance of certain nov-el edge services that require close-to-zero latencies as pre-scribed by 5G objectives.
In these scenarios, the second alternative in Fig. 2b maybecome better suited for deploying mobile edge services. Inthat case, some processing and storage resources are placedclose to the RRH, and thus the fronthaul delay is significantlyreduced. Deploying huge data centres implies a series of re-quirements in terms of space, energy, etc. Hence, this secondoption envisages the deployment of a series of HW resourceswith limited capacity and requirements and in a distributedconfiguration, which may ideally collaborate to provide someedge computing capabilities.
This second solution is especially relevant to enable flexi-ble deployment of Small Cells, and particularly attractive fortargeting currently deployed network architectures and speciallimited-access scenarios. In the former case, a Small Cell op-erator may think about endowing its deployed network withnovel mobile edge capabilities by gradually upgrading theCustomer-Premises Equipments (CPE) without requiringchanging wired connections. In the latter case, some speciallocations such as rural areas may face specific problems forupgrading the network access. In both scenarios, the introduc-tion of distributed computing and storage capabilities associ-ated to the CPEs arises as an affordable and scalable solution.
However, the deployment of centralised functions over dis-tributed data centres imposes a series of challenges related tocoordination and synchronization of tasks, which at the sametime may impact the performance of the whole system. Theexplosion of cloud computing systems deployment has lead toa number of studies that identifies the main performance chal-lenges and that proposed different systems architectures [9,10]. Some of the key aspects related to this paper are thepossibility of using geo-distributed data centres and the asso-ciated challenges [11] and the introductions of mobile cloudcomputing [12] and fog computing principles [13].
This paper describes the solution developed in the scope ofthe European H2020 5GPP project Small cEllS coordinAtion
Fig. 2 Geographical alternativesfor the data centre: centralised vs.distributed
Mobile Netw Appl
for Multi-tenancy and Edge services (SESAME), and pro-vides some insights on the deployment of mobile edge ser-vices over the proposed architecture. The remainder of thepaper is organised as follows. Section 2 presents the mainconcept of the cloud enabled Small Cells architecture anddefines the main functional elements. Section 3 focuses onthe provision of mobile edge services over the proposed ar-chitecture. Section 4 presents a series of target scenarios wherethe proposed solution introduces significant benefits, andstates some open issues. Finally, Section 5 provides the con-clusions to the paper, highlighting the foreseen benefits of theproposed solution and identifying several open issues.
2 Cloud-enabled small cells: conceptand architecture
The main novelties and innovations of the proposed solutionare achieved by placing intelligence in the network’s edgethrough the employment of NFV and edge cloud computingdirectly to the Small Cell part. The consolidation of multi-tenancy in communications infrastructures is also in scope,allowing several operators/service providers to engage innew sharing models of both access capacity and edge com-puting capabilities. To that end, this paper proposes the use ofcloud-enabled Small Cells as a new multi-operator enabledSmall Cell that integrates a virtualised execution platform(i.e., a microserver) for deploying Virtual NetworkFunctions (VNFs) and also to execute novel applications andservices inside the access network infrastructure.
This solution consolidates the concept of delivering SmallCell coverage, coupled with a virtualised execution platform,according to the ‘as-a-Service’ fashion. By enhancing SmallCells with an execution infrastructure, the inclusion of mobileedge computing capabilities emerges and this leads to increas-ing responsiveness from the edge of the network. This allowsenriching the end users’ experience and at the same time, oper-ators can open the radio network edge to third-party partners,allowing them to rapidly deploy innovative applications andservices.
Figure 3 demonstrates the proposed concept. An importantaspect of this approach is that a service provider may exploitthe proposed architecture to compose and operate on an end-to-end basis its own ‘virtual’ network, provided by differentmobile operators and infrastructure owners on top of a set ofdiverse physical infrastructure. Another instance could be athird party (as e.g., a virtual mobile network operator, a datacentre provider or another business entity) that would act asend-to-end provider, without actually owning any physicalinfrastructure. That part would sign agreements with physicalinfrastructure owners, for instance municipalities, big stadi-ums, etc., in the areas it wishes to provide network serviceswithout deploying infrastructure, in order to cover sporadic
large scale events for example. The same would be the casefor contracting data centre operators in strategic locations andin order to complete a full network solution.
Figure 4 illustrates the main elements in the proposed ar-chitecture, as well as a possible split of the different layers ofthe protocol stack in VNFs and Physical Network Functions(PNFs).
The different elements are defined as follows:
& Small Cell: Low-powered radio access node that operatesin licensed and unlicensed spectrum with restricted rangebetween some meters to 1 or 2 km.
& Microserver (μS): Specific hardware that is placed insidethe Small Cell and provides a virtualised computing infra-structure i.e., processing power, hardware accelerators,memory and storage capabilities. In other words, the μSprovides the execution infrastructure.
& Cloud Enabled Small Cell (CESC): The Small Cell devicewhich has been enriched with a microserver.
& Cluster of CESCs: A group of CESCs within a commonintended coverage area (exchanging information betweenthem, properly coordinated).
& Light Data Centre (Light DC or LDC): Cloud entity com-posed by the microservers of the CESCs forming a cluster.
& CESC Manager (CESCM): The architectural componentin charge of managing and orchestrating the cloud envi-ronment of the Light DC and the radio access functional-ities of the CESC. It can manage at the same time multipleclusters, a cluster or a single CESC.
CESCs are equipped with a virtualised execution environ-ment, materialised in the form of the microserver, which al-lows the provision of mobile-edge computing capabilities tothe mobile operators for enhancing the user experience and theagility in the service delivery. Although the HW platform istransparent to applications, Small Cell environment imposessevere physical constraints in term of power consumption,thermal dissipation and available space. For these reasonsthe proposed μS architecture is based on a very efficientSystem on Chip (SoC) with multi-core ARM CPU and inter-nal HWaccelerators. For high computational requirements the
Fig. 3 System concept and impact on service deployment
Mobile Netw Appl
μS is able to host external standard PCI Express (PCIe) Cardsequipped with different HW accelerators (FPGAs, DSPs,GPUs) or a Disk Controller with related disks in case of highcapacity storage requirements. This feature adds the necessaryflexibility for the HW platform to be used with maximumefficiency in various scenarios. The μS will also support theexecution of VNFs for carrying out the virtualisation of theSmall Cell access. In this respect, both network functions fea-tures, along with ‘Service’ VNFs, will be executed there.Moreover, the microserver VNFs will benefit from specifichypervisor extensions which enable computing and network-ing accelerations for virtual machines. Finally, backhaul andfronthaul transmission resources will be also part of CESC,allowing for the required connectivity.
Up to now, several attempts have been initiated targeting tofind an optimal solution for the part of the small cell whichneeds to be virtualised, running as one or more VNFs, and thepart of it that should remain to run as PNFs. The right-handside of Fig. 4 shows one possible case of this debate. In thisexample, the Small Cell network functions above Packet DataConvergence Protocol (PDCP) layer have been transferred tothe Light DC and are executed as VNFs. Examples of SmallCell VNFs may be related to Operations, Administration andMaintenance (OAM) and Self-Organizing Network (SON)capabilities within the cluster of CESCs. This may not how-ever be confused with the case that the Light DC also executesother BAPPS^ or BService VNFs^, like for example, virtualfirewall, virtual caching and so on.
The proposed execution platform of the μS is used to sup-port the required VNFs that implement the different features/capabilities of the Small Cells, as well as the computing sup-port for the mobile edge applications of the end-users.According to the proposed architecture, the virtual machineshosting the VNFs will be controlled by the local Hypervisor.Nevertheless, the overall management and coordination ofVNFs will be assigned to higher layers. Depending on theactual virtualisation capabilities, clusters will be assigned toone or more Virtual Infrastructure Managers (VIM) – in linewith the current ETSI NFV ISG approach and terminology[14] –i.e., entities that will be responsible for managing thevirtualised resources required for proper VNF deployment.
Monitoring data from all active VIMs will be combined formanaging the whole process of VNF restructuring (e.g., mi-gration, rescaling, etc.) in a dynamic and efficient way.
3 Introducing mobile edge servicesinto cloud-enabled small cells
In this section we address how these types of mobile edgeservices can be implemented within the infrastructure of amobile network operator, taking into account the current3GPP LTE architecture and the possible path towardsvirtualization. Specifically, taking into account the possibleprotocol split presented in Fig. 4, this section focuses on theimplications of the LTE user data plane and the possible solu-tions to implement the data path.
According to [8], the main features to be covered for properdesign of MEC services are:
& Traffic Offload Function (TOF), which allows the properforwarding of data packets between the mobile data pathand the MEC applications.
& Radio Network Information Services (RNIS), whichmakes it possible for MEC application to obtain ChannelState Information (CSI) associated to the mobile users andperformance statistics of the cell. This information is crit-ical for the accurate provisioning of services tailored to theusers’ context of use.
The data path resulting from the standard 3GPP LTE net-work architecture is depicted in Fig. 5 (upper plot). All theuser data traverses the Evolved Packet Core (EPC) throughdedicated tunnels based on the GPRS Tunneling Protocol(GTP) protocol. These GTP-U tunnels exchange user datapackets from the Packet Data Network Gateway (PGW) tothe eNB, going through the Serving Gateway (SGW). TheeNB is able to decapsulate the IP packets from the GTP-Utunnel and to forward them towards the corresponding UserEquipment (UE).
The standard data path entails two main issues. First, all theIP datamust traverse the EPC to the PGW for its forwarding to
Fig. 4 High level systemcomponents
Mobile Netw Appl
external applications. Second, taking into account the protocolsplit proposed in Fig. 4, the VNFs are not able to access the IPpackets without breaking the GTP-U tunnel.
Different solutions exist to cope with both problems. Forthe first problem, the 3GPP introduced in Release 10 the con-cept of local breakout. Two main solutions are currently avail-able: Local IPAccess (LIPA) and Selected Internet IP TrafficOffload (SIPTO) [15–17]. Both options allow offloadingsome user traffic from the PGW through the addition of a localgateway with different alternative architectures. The SIPTO atthe local network (SIPTO@LN) solution is the best candidatefor Small Cells, the local breakout is not fully integrated intothe Home eNB (HeNB).
In the scope of the proposed architecture, the applicationsare designed to run within the Light DC following the MECconcepts. Therefore, using local breakouts within the SmallCells would entail significant advantages both from the man-agement perspective and from the standpoint of reduced la-tency in the data path. The desired operation environment(lower plot in Fig. 5) would entail that the VNFs of theSmall Cell (SC VNFs) are capable of handling the data pathto/from the BService VNFs^ without going out of the CESCcluster.
The proposed solution for the local data path managementis illustrated in Fig. 6, and involves the coordinated use of theCESCM and an SDN controller.
The CESCM is the component that is in charge of thedeployment, monitoring, configuration and administration ofthe mobile edge services instantiated over the hardware of theLightDC (resulting from the aggregation of the CESCs). Asingle CESCM can generically operate over a cluster of
CESCs and consequently acquire an overall knowledge ofthe status of the virtual and physical resources across the dif-ferent infrastructures.
The main functional components that build edge servicesare VNFs and it is therefore the role of the system orchestrator(in particular the NFV Orchestrator located within theCESCM) to manage their deployment over the virtualisedinfrastructure offered by the VIM. This deployment of VNFsand their interconnection into composed edge services (thevirtual infrastructure exposed by the VIM is made of theedge-deployed CESCs) is made with the awareness of differ-ent parameters and metrics that ensure an optimal allocation ofcompute resources and an efficient use of the radio accessnetwork in scenarios where end-users demand high perfor-mance and multiple network operators share the sameinfrastructure.
It is in this context that the proposed architecture exploitsthe innovative aspect of RAN-aware cloud computing (a keyconcept for the convergence of mobile networks and cloud[18]), in which, together with processing, networking andstorage, radio resources are also considered at the service leveland as part of the execution platform.
Building over these principles, the CESCM obtains theability to dynamically compose edge services and applyreal-time monitoring procedures that allow the enforcementof the agreed Service Level Agreements (SLAs) between thedifferent entities (CESC operators, mobile network providers,end-users). As a consequence ofmonitoring and taking advan-tage of the virtualised infrastructure, the CESCM can applypolicies to mandate the reconfiguration, migration, and scale-out of the existing services in order to comply with the serviceagreements while dynamically maximizing the utilization ofthe resources.
As an input for the deployment of the requested edge ser-vices, the CESCMwill draw from an infrastructure repositorydescribing both the computational and radio capabilities of theCESCs of the cluster(s) and a service graph specifying theservice to be deployed, its interconnection and dependencieswith other services.
A fundamental role in the interconnection of the deployedVNFs is played by the SDN controller as a key entity toenforce the rules of traffic steering and chaining.
The emergence of the NFV concept and the expansion ofVNF solutions have materialised service function chaining
Fig. 5 Data path in typical LTEconnection and in the proposedsystem approach
Fig. 6 Solution for traffic forwarding at mobile edge
Mobile Netw Appl
(SFC) among virtualised functions as a legitimate use case fora cloud data centre (DC). Yet in a premature state, applyingSFC concepts in a fully virtualised environment requireschanges and adaptations on the existing protocols in order tobe able to apply the same concepts and achieve the desiredbehaviour on a network level. A typical burden in environ-ments with fully virtualised functions running on virtual end-points is the aggregated protocol encapsulation in the packets’headers added as they traverse those endpoints.
Currently there are two key approaches to implement SFCsolution in virtualised scenario: packet based and flow based.The first requires manipulation of the packets, for instance byintroducing some changes in the header field (packet taggingor rewrites) [19] or simply by applying protocols that intro-duce one more layer of abstraction on the top of the existingheader fields – designed especially for this type of service.Such dedicated protocols has been ultimately introduced byCisco and leveraged in the Open Daylight (ODL) communityto support the ODL SFC integral project. In this case an addi-tional header called NetworkServiceHeader (NSH), is intro-duced in order to enforce end-to-end traffic as an overlayconnection above the service chain path. The problem of suchsolution is that it alters the datagrams and this can potentiallycause a problem in the case where the VNF that runs on someof the virtual machine (VM) hops along the chain, requires thedatagrams in their original structure. One example is a virtualfunction such as vDPI (virtual deep packet inspection) thatrequires the packets in their original structure in order to en-force a correct behaviour.
The advantage of SDN is that based on the Open Flow(OF) protocol, the routing can be steered over a specific net-working path by programmatically applying OF based rules(flows) from the SDN controller to the virtual switch (OVS)inside the VM hosting the VNF. This is the second approachto implement SFC, based on flow programming rules, thatleaves the packets untouched while applying actions on theOF ports of the switches, in order to gear the desired route ofthe packets in the chain. This routing logic is simplified com-pared to the first one, as it avoids unnecessary overheads onthe top of the already existing ones (ex. in the scenario of intertenant communication in OpenStack [20]) and the packets areleft intact, completely agnostic of the existing chain. A solu-tion based on this approach requires that the network environ-ment is fully SDN capable in order to apply the chain rulesalong the full virtual network graph. The resulting routingflows need to be maintained to reflect alterations in the func-tion chain (e.g. a VNF altering the packet header could invalidthe end-to-end chain). Higher level chaining abstractions andprogramming languages are needed in order to allow servicedevelopers to programmatically declare the sequence the VNFtraffic should follow, leaving to the underlying runtime systemthe actual implementation of such rules [21, 22]. For the chainrouting to be deterministic, there has to be a field that keeps
track of the chain hops. Using the VLAN ID as a workaroundfor this purpose could be one possible approach, since thechain routing does not follow the standard Ethernet routing.
Extending the concept of SFC for the scope of the proposedsystem and in the context of the 5GPPP ecosystem, requiresdeeper understanding on the NFV concepts in such a scenarioand carefully elaborating the requirements to establish thedesired functionality in environment that is not fully preparedto support it. Today there exist VNFs deployments as substi-tutes for the EPC integral blocks as well as on the radio accessfront haul side. SFC concepts based on SDN can be applied inLTE environment to enforce the packets among a logical net-work graph and achieve certain service functionality amongthe virtualised components such as BSS, HSS, RAN etc. [23].The role of the controller in this holistic approach has beenanalysed in the literature and some experimental and industryimplementations already have been presented [24–28].However SFC solution based on SDN in this scenario is anunexplored area and potentially one of the use cases to beaddressed.
From a single data centre point of view, the SDN controllerstands in between the components such as CESCM / VIM andthe light DC. In this case, the previously described approachfor SFC applies if the SDN controller takes the charge of asingle light DC deployment. The steering and rule enforce-ment policy are kept within the controller application logicand enforced over the network that hosts the light DC specificNFVs. If the routing happens across different light DCs, thenthe SFC approach may alter depending on the placement ofthe controller within the given architecture. This has to be inaccordance with the networking protocols to be adopted inthat case, for example MPLS and BGP as used today for intradata-centre routing.
4 Scenarios of applicability
Three initial target scenarios have been identified as promisingfields for the applicability of the cloud-enabled small cellsconcept, which can be used as the basis for the formulationof a number of specific use cases. A description of the threescenarios is given in the following, highlighting which are themain challenges, the applications and services in-scope andthe components and capabilities.
4.1 Scenario 1 - Multi-tenant enterprise services
A typical scenario in which the proposed system can beexploited is shown in Fig. 7. The figure depicts a situationof one CESC provider that owns, deploys and maintains thenetwork infrastructure of Small Cells and Light DC (i.e. en-semble of microservers) inside the premises where differententerprises are hosted. In this case the CESC provider shall
Mobile Netw Appl
establish a SLA)with each customer enterprise to enable en-terprise users to access different services, including Internetaccess, voice communications, video conferencing, access tomail system and repositories, web browsing and open andclosed subscriber groups with embedded high security creden-tials , just to name a few. The deployment of μSs can lead toachieve close-to-zero latency, with clear benefits for enhancedQuality of Experience (QoE) of media flows. Indeed this canbe achieved resorting to content caching at the level of theLight DC, or in other words storing content at different μSlocations. It is also worth stressing the fact that in a headquar-ter, hosting different enterprises traffic may fluctuate greatlydepending on the time of the day and on the nature of specificevents held, thus requiring a flexible system which can bescaled up and down depending on the situation. As shown inFig. 7, the enterprise scenario will leverage on key featuressuch as intrinsic support of multi-tenancy since Small Cellsoperators can provide network services and connectivity overthe network owned by the infrastructure provider.Furthermore, the proposed system will optimise service deliv-ery to the enterprise end users adapting the network behaviourby means of self-organizing network techniques.
4.2 Scenario 2 - Enhanced service experience on the move
In this scenario, a CESC provider manages three distributedCESC clusters deployed in geographically adjacent areas andsupports a single mobile network provider that is offeringservices to his end users through the CESC infrastructures.The relationship between the entities is regulated by differentSLAs which are established between the CESC operator andthe service provider and between the service provider and itsend-users. The main actors and interactions of this scenarioare depicted in Fig. 8.
To demonstrate different capabilities in this setup, themobility of a reference end user is taken into accounttogether with his requirements for service continuity andquality as he handovers across the different CESC clus-ters. The type of traffic generated by the user is as-sumed to be high-definition real-time content that re-quires low-latency data access times.
The application of the MEC paradigm, implemented in theproposed architecture through hardware and software compo-nents running at the edge of the network and in the proximityof the moving user, allows for an efficient monitoring of theuser location and its related radio conditions, with real-timereporting and the actuation of coordination actions with closeto zero latency.
The enhanced handling of the end-user mobility is thus aconsequence of the SON or self-x features of the CESC clus-ters, which take advantage of edge monitoring capabilities toseamlessly manage the handover process across neighbouringcells. As for decision making, limiting the processes withinthe boundaries of a CESC (or CESCs cluster), allows for thefast application of policies aimed at increasing the overallquality perceived by the user. In order to take into accountmore stringent requirements (for example across all users),some decision making processes resulting in the reconfigura-tion of services for the fulfilment of the SLAs can also becompleted at the level of the CESCM, which has a wider viewof the status of the resources across the CESC clusters.
With respect to user traffic, the scenario highlights howlow-latency edge caches can be deployed across the CESCinstallations to allow the end user an uninterrupted access tocontent. Pre-provisioning cached data while anticipating theuser handover (monitored through signal inspection) is aneffective way to offload the user equipments from the taskof storing data locally.
Fig. 7 Proposed system formulti-tenant enterprise services
Mobile Netw Appl
4.3 Scenario 3 – Management of flash events
Another relevant scenario addressed by the proposed systemis presented in Fig. 9 in which the sudden concentration ofpeople at a specific geographical location and time of the daycreates an unexpected hot spot zone in which a variety ofdifferent traffic types require proper management. The suddengathering of crowds can be due to unexpected live events oremergency situations. This scenario is relevant to leverage theCESC cluster resources, which are essentially the collection of
a number of CESCs (i.e. Small Cells with their microservers).In addition, the scenario allows showing that multi-tenancycan be considered a built-in function of the system. In the firstplace indeed, the CESC infrastructure deployed by an infra-structure provider shall support different mobile operators inserving their customers. In such a situation CESC cluster re-sources have to be provisioned to each tenant operator, and inorder to efficiently handle the unexpectedly intense trafficgenerated by the users, self-organizing network techniquesare required. At the beginning, the CESCM shall interface
Fig. 8 Proposed system forenhanced service experience onthe move
Fig. 9 Proposed system for flashevents
Mobile Netw Appl
with an operator’s OSS/BSS to retrieve tenant configurationparameters; afterwards, communications and QoS are sup-ported at the CESC level. It is interesting to notice that thisscenario is built on the edge computing capability of the sys-tem since computationally intensive tasks can be offloadedfrom the mobile terminals to the μSs, while at the same timeoptimizing the use of backhaul resources. The twomain traffictypes which need to be supported and optimised by the CESCcluster are live video streaming (e.g. users film and postingvideo contents in social media) and real-time group commu-nications (e.g. small community of users exchanging files orvideos). Deep packet inspection, video transcoding and dataanalytics can be enabled in the CESC cluster whereby hard-ware accelerators in order to optimise the management of thetraffic from/to the CESCs.
5 Conclusions and further work
This paper presents a solution for the inclusion of mobile edgeservices in scenarios where an aggregation of small cells isable to share certain processing and storage resources in alocal perspective. Therefore, rather than centralising RANand MEC functions into big data centres, the proposed solu-tion creates a distributed light data centre by coordinating themicroservers associated to different small cells in a cluster.
The proposed solution is based on the architecture of theH2020 SESAME project, which integrates concepts of mobileedge virtualization and multi-tenancy to provide a unified co-ordination for the cluster of Cloud-enabled Small Cells. Fromthis architecture, we analyze the problem of handling user datapackets within the CESC cluster according to the standardLTE user data path, and especially when the virtualization splitis made above the PDCP layer. The proposed solution in-cludes a coordinated management of the VNFs from theCESC Manager element, and the implementation of the dataforwarding functions through an SDN Controller. This solu-tion provides the foundations for the implementation of ad-vanced SFC.
After the proposed architecture and the possible introduc-tion of mobile edge services are discussed, the paper presentsa series of possible scenarios where the solution would pro-vide significant enhancements over the current network man-agement strategies. In order to exemplify the expected perfor-mance improvements of the proposed solution, preliminarysimulation studies have demonstrated the associated benefitsfor the problem of general flow scheduling [29] and for mul-timedia delivery [30] in multi-user scenarios.
In the framework of this work, several open issues areidentified as further work.
The presented overall architecture provides a step forwardtowards the integration of the 3GPP LTE and ETSI NFV ap-proaches. However, a detailed definition is required for the
NFV management elements according to the standardizationefforts such as ETSI NFV Management and Orchestration(NFV-MANO) [31] or the recently initiated 3GPP approachfor management of mobile networks that include virtualisednetwork functions (MAMO-VNF) [32].
The proposed multi-tenant virtualised infrastructure ofcloud-enabled small cells brings new opportunities to the busi-ness ecosystem. For example, the role of the small cell pro-vider that supports multiple mobile network operators shall beexplored. In this sense, not only the management and perfor-mance aspects but also the security and privacy of the multipletenants need to be carefully studied.
Finally, a series of research challenges that need to be prop-erly addressed remain open for discussion, such as the VirtualNetwork Embedding (VNE) problem in mobile edge comput-ing networks [33] and the dynamic coordination of CESCclusters in terms of virtualised RRM and SON.
Acknowledgments The research leading to these results has been per-formed in the scope of the H2020 5G-PPP project SESAME. This projecthas received funding from the European Union’s Horizon 2020 researchand innovation programme under grant agreement No 671596.
References
1. Soldani D, Manzalini A (2015) Horizon 2020 and beyond: on the5G operating system for a true digital society. IEEE Veh TechnolMag 10(1):32–42
2. Chih-Lin I, Huang J, Duan R, Cui C, Jiang J, Li L (2014) Recentprogress on C-RAN centralisation and cloudification. IEEE Access2:1030–1039
3. Wu J, Zhang Z, Hong Y,Wen Y (2015) Cloud radio access network(C-RAN): a primer. IEEE Netw 29(1):35–41
4. Rost P, Bernardos CJ, Domenico AD, Girolamo MD, Lalam M,Maeder A, Sabella D, Wübben D (2014) Cloud technologies forflexible 5G radio access networks. IEEE Commun Mag 52(5):68–76
5. Next Generation Mobile Networks (NGMN) Alliance (2015)Project RAN Evolution: Further Study on Critical C-RANTechnologies https: / /www.ngmn.org/publicat ions/al l-downloads/article/project-ran-evolution-further-study-on-critical-c-ran-technologies.html
6. Small Cell Forum (2015) Document 106.05.1.01: Virtualization forSmall Cells: Overview. http://scf.io/doc/106
7. Small Cell Forum (2015) Document 159.05.1.01: Small CellVirtualization Functional Splits and Use Cases. http://scf.io/doc/159
8. ETSI Industry Specification Group Mobile-edge Computing,http://www.etsi.org/technologies-clusters/technologies/mobile-edge-computing
9. Faizul Bari Md, Boutaba R, Esteves R, Zambenedetti Granville L,Podlesny M, Golam Rabbani Md, Zhang Q, Faten Zhani M (2013)Data center network vi r tua l iza t ion: a survey. IEEECommunications Surveys & Tutorials 15(2):909–928
10. Hammadi A, Mhamdi L (2014) A survey on architectures and en-ergy efficiency in data center networks. Comput Commun 40:1–21
11. Jennings B, Stadler R (2015) Resource Management in Clouds:survey and research challenges. J Netw Syst Manag 23:567–619
Mobile Netw Appl
12. Dinh HT, Lee C, Niyato D, Wang P (2013) A survey of mobilecloud computing: architecture, applications, and approaches. WirelCommun Mob Comput 13:1587–1611
13. Oueis J, Calvanese Strinati E, Sardellitti E, Barbarossa S (2015)Small Cell Clustering for Efficient Distributed Fog Computing: AMulti-User Case. In 2015 I.E. 82nd Vehicular TechnologyConference (VTC Fall), pp- 1-5.
14. ETSI Industry Specification Group for Network FunctionVi r t u a l i s a t i o n , h t t p : / /www. e t s i . o rg / t e chno l og i e s -clusters/technologies/nfv
15. 3GPP TR 23.829: Local IPAccess and Selected IP Traffic Offload(LIPA-SIPTO)
16. 3GPP TR 23.859: LIPA Mobility and SIPTO at the Local Network17. 3GPP TR 22.828 Study on co-ordinated Packet data network
GateWay (PGW) Change for Selected IP Traffic Offload (CSIPTO)18. Taleb T, Corici M, Parada C, Jamakovic A, Ruffino S, Karagiannis
G,Magedanz T (2015) EASE: EPC as a service to ease mobile corenetwork deployment over cloud. IEEE Netw 29(2):78–88
19. Service Function Chaining in Open Daylight using NSH protocol:https://wiki.opendaylight.org/view/Service_Function_Chaining:Main
20. Overlay encapsulation in DC network http://docs.openstack.org/developer/neutron/devref/openvswitch_agent.html
21. Anwer B, Benson T, Feamster N, Levin D (2015) Programmingslick network functions. In Proc. the 1st ACM SIGCOMMSymposium on Software Defined Networking Research (SOSR'15), ACM, New York, NY, USA, article 14, 13 pages
22. Riggio R. et al (2016) Programming Wireless Network Functions.In Proc. IEEE NOMS 2016, Istabul, Turkey
23. Riggio R, Bradai A, Rasheed T, Ahmed T, Slawomir K, Schulz-Zander J (2015) Virtual Network Functions Orchestration in
Wireless Networks. In Proc.11th International Conference onNetwork and Service Management (CNSM), Barcelona, IFIP/IEEE
24. Akyildiz IF, Wang P, Lina S-C (2015) SoftAir: a software definednetworking architecture for 5G wireless systems. Comput Netw 85:1–18
25. Basta A, Kellerer W, Hoffmann M, Hoffmann, K; Schmidt E-D(2013) A Virtual SDN-Enabled LTE EPC Architecture: A CaseStudy for S−/P-Gateways Functions. In Proc. 2013 I.E. SDN forFuture Networks and Services (SDN4FNS), pp. 1–7
26. Malik A, Qadir J, Ahmad B, Alvin Yau KL, Ullah U (2015) QoS inIEEE 802.11-based wireless networks: a contemporary review. JNetw Comput Appl 55:24–46
27. Chourasia S; Sivalingam KM (2015) SDN based Evolved PacketCore architecture for efficient user mobility support. In Proc. 20151st IEEE Conference on Network Softwarization (NetSoft) pp. 1–5
28. He J, SongW (2015) Smart routing: fine-grained stall managementof video streams in mobile core networks. Comput Netw 85:51–62
29. Fajardo JO, Taboada I, Liberal F (2015) Radio-aware service-levelscheduling to minimize downlink traffic delay through mobile edgecomputing. In Proc. MONAMI 2015. LNICST 158:1–14
30. Fajardo JO, Taboada I, Liberal, F (2015) improving content deliv-ery efficiency through multi-layer mobile edge adaptation. IEEENetwork November/December 2015
31. ETSI GS NFV-MAN 001 V1.1.1 (2014) Network functionsvirtualisation (NFV); Management and Orchestration
32. 3GPP TS 28.511: Telecommunication management; ConfigurationManagement (CM) for mobile networks that include virtualizednetwork functions; Procedures
33. Beck MT, Maier M (2014) Mobile Edge Computing: Challengesfor Future Virtual Network Embedding Algorithms. In Proc. TheEighth International Conference on Advanced EngineeringComputing and Applications in Sciences (ADVCOMP 2014)
Mobile Netw Appl
View publication statsView publication stats