On end to end network slicing for 5G communication...

TRANSACTIONS ON EMERGING TELECOMMUNICATIONS TECHNOLOGIESTrans. Emerging Tel. Tech. (2016)

Published online in Wiley Online Library (wileyonlinelibrary.com). DOI: 10.1002/ett.3058

RESEARCH ARTICLE

On end to end network slicing for 5Gcommunication systemsX. An, C. Zhou, R. Trivisonno*, R. Guerzoni, A. Kaloxylos, D. Soldani and A. Hecker

Huawei European Research Institute, Munich, Germany

ABSTRACT

The heterogeneity in use cases and the need to support diverse requirements from vertical markets are the main driversfor new design principles of 5G communication systems. In this paper, we review the notion of plastic architecture andpropose an end to end network slicing concept to serve new 5G capabilities and features in a flexible and efficient manner.Besides the concept definition, we address in particular the key issue of how 5G devices may be enabled to discover, selectand access the most appropriate E2E network slices. To solve the issue, we developed a novel Device Triggered NetworkControl mechanism and evaluated its performance and implementation cost with respect to alternative available schemes,where the slicing concept was applied only to the core network domain of the communication system. Simulation resultsshowed two digits gains in terms of attachment delay and signalling overhead. Copyright © 2016 John Wiley & Sons, Ltd.

*CorrespondenceR. Trivisonno, Huawei European Research Institute, Munich, Germany.E-mail: [email protected]

Received 6 March 2016; Revised 8 April 2016; Accepted 19 May 2016

1. INTRODUCTION

The International Mobile Telecommunications for 2020and beyond (5G) is envisaged to expand and supportdiverse usage scenarios and applications with respect tocurrent mobile network generations. The agreed scenariosfor 5G include [1]: ‘enhanced mobile broadband (eMBB)’,addressing human-centric use cases for access to multime-dia content, services and data; ‘Ultra-reliable-low latencycommunications’ with strict requirements for capabilitiessuch as throughput, latency and availability; and ‘mas-sive machine type communications (mMTC)’ for a verylarge number of connected devices typically transmitting arelatively low volume of non-delay-sensitive information.

The objectives of 5G include the creation of enablingtechnologies for vertical industries such as, but not lim-ited to: transport (automotive), healthcare, factories of thefuture (or industry 4.0), energy and media & entertain-ment [2]. In [3], a detailed analysis of the correspondingrequirements showed that latency (below 5 ms), relia-bility and density (up to 100 devices/m2), along withtight constraints on territory and/or population coverage,are the most crucial performance targets 5G needs toachieve for supporting all possible services of the fiveinvestigated sectors.

Additional use cases and new related requirements,which are currently not foreseen, are expected to emerge.

Hence, for 5G, flexibility of the system design and diver-sity to serve many different use cases and scenarios, aswell as a broad variety of new capabilities and a largenumber of features, which would make future InternationalMobile Telecommunications modular, reliable and secure,are required [4].

The key design principles to achieve the most impor-tant 5G goals sparked developments around the conceptsof flexible architecture and network slicing. In [5], inorder to achieve the required flexibility, diversity andmodularity, we proposed an early 5G plastic architec-ture concept, enabling the dynamic instantiation of tailoredControl Plane (C-Plane) and Data Plane (D-Plane). Thenovel approach illustrated that 5G will not be characterisedby any exact network architecture, as it was, for exam-ple, for 4G systems. Instead, it has to be designed in ahighly modular manner, with different logical architec-tures, built upon a set of basic logical functions, networkand service applications, tailored to target requirementsof group of homogeneous use cases, so that not all fea-tures will be forcibly implemented in all networks. In [6],a network slice has been defined as a composition of net-work functions (NF) and specific radio access technology(RAT) settings, combined together for a specific use caseor business model. The slice can span over all domainsof the network: software modules running on cloud nodes,

Copyright © 2016 John Wiley & Sons, Ltd.

X. An et al.

specific configurations of the transport network, dedicatedradio configurations or even a specific RAT, as well as theend devices. Actually, this concept was already elaboratedin prior art. Network slicing applied to the radio access net-work (RAN) was presented in [7], where its usage mainlyaimed at enabling spectrum sharing amongst mobile vir-tual network operators while minimising the impacts onAccess Nodes design. Hence, the ultimate goal was tooptimise the overall radio resource exploitation. Targetingsimilar goals for efficient sharing of a network infras-tructure amongst operators, in [8], authors elaborated theslicing concept introducing a multi-tenant slice controllerfor efficient active RAN sharing and related operationalaspects. With analogous intentions, but focusing on a dif-ferent segment of the system, authors of [9] designed anovel approach to core network (CN) slicing, to divideresources according to traffic demand and reduce capitalexpenditures and operational expenditure. An early con-cept of network slice is also hidden in 3GPP Décor [10],where dedicated 4G core networks are put together to meetfunctional requirements of different sets of services. Bydefining dedicated core elements, for example, mobilitymanagement entity, for different services, Décor implicitlypartitions the core network into slices, running differentservices on dedicated and isolated hardware.

This paper motivates and elaborates the concept of endto end network slice, defined as instantiation of tailoredsystem architecture, over a software-defined or physicalinfrastructure, composed by a set of interconnected logicalAccess and Core NF, providing communication servicesin the intended usage scenarios. Essentially, we advocatefor an end to end slice definition and design principles, asfunctional and performance requirements are defined endto end, and hence, architecture design should coherentlyaffect both access and core networks. Additionally, end toend slicing is seen as the key design principle to guar-antee isolation, functional and performance independenceamongst services 5G system will provide.

The paper is organised as follows: Section 2 presents thenotion of end to end network slice, highlighting the ratio-nale behind it and discussing the main issues to introducethe concept in 5G systems. The paper then focuses on thespecific problem of enabling devices to select and accessend to end network slices. Section 3 introduces an innova-tive technical solution to the problem: a Device TriggeredNetwork Controlled (DTNC) slice selection mechanism.Section 4 provides design details for a possible implemen-tation of end to end network slicing and DTNC, highlight-ing 5G required enhancements with respect to LTE/SAEsystem. Performance evaluation of proposed mechanism isreported in Section 5. Finally, future work and conclusionsare drawn in Section 6.

2. 5G ARCHITECTURE ANDNETWORK SLICING: AN ENDTO END VIEW

2.1. End to end network architecture

From the agreed usage scenarios presented in [1–4], afact clearly emerged: functional and performance require-ments are defined per service and hence have an end toend perspective. For this reason, the 5G architecture designrequires a holistic approach and cannot be prescribed asfor previous system generations, as it would not efficientlysupport the much more diverse functional and performancerequirements. Evidences thereof were provided in [11],where we also presented how a tailored end to end archi-tecture, consisting of a basic set of logical functions inthe C-plane and D-plane and related interfaces, may becomposed. A logical function is an independent moduleaccessible via communication interfaces dedicated to aspecific set of network purposes. Logical functions can beclassified as Access Functions (AF) or NF, for access andnon-access strata connectivity, respectively.

The definition of a basic set of NFs was given in [5]. KeyNFs are as follows:

� Connection Management (CM): the CM termi-nates the Non-Access stratum at the Core Networkside. It controls key device procedures such asaccess CM, forwarding path management, identifiersresolution, address allocation, service request andslice attachment;

� Mobility Management: the mobility managementcontrols device reachability, tracking area man-agement, location update, paging and handoverprocedures;

� Forwarding Management: the forwarding manage-ment performs packet routing configuration for theD-Plane;

� Authentication and Authorisation: the authentica-tion and authorisation performs authentication andauthorisation of devices;

� Security Management: performing Access and Non-Access Strata security management.

The basic set of AFs can be defined analysing the keyfunctionalities of legacy mobile networks. Referring to 4Gsystems, they could be associated to Mobility, Security andSession Management functions and related protocols, forexample, as specified in [12]. Also, a number of transmis-sion functions are performed at the physical layer. The LTEarchitecture consists of a fixed yet configurable protocolstack, where interactions between peer entities are based onspecific sets of control and user plane procedures. Some ofthe protocols are quite complex and usually include morethan one function because they have been designed to caterfor general purpose end devices. However, this complexitymay be not necessary for all 5G use cases (e.g. mobil-ity management at access network is not needed for static

Trans. Emerging Tel. Tech. (2016) © 2016 John Wiley & Sons, Ltd.DOI: 10.1002/ett

X. An et al.

devices, header compression for devices using small sizeaddresses could be avoided, etc). Moreover, because theseprotocols have been primarily designed to handle generalpurpose devices (e.g. smartphones), they may not alwaysbe able to meet the strict key performance indicators (KPIs)of different vertical sectors (e.g. smartphones may tolerateseveral collisions, while using the Random Access Chan-nel (RACH), but this is not necessarily acceptable for theestablishment of connections for ultra critical services).Thus, a paradigm shift is needed to revisit the RAN archi-tecture where on a per use case level we need to optimiseexisting functions and even to introduce new ones that willserve the desired KPIs.

To move forward towards the definition of 5G-RAN, itis essential to revisit the existing 4G functions, to definetheir optimum configuration for the different use cases, toformulate new-fangled ones potentially needed by specific5G requirements (e.g. context management, accurate loca-tion estimation, etc) and to select their optimum placementin the RAN topology. Note that it is expected that someof the core network atomic functions may be needed tobe placed in the RAN domain, thus redefining the bound-aries between Core and Access network, what is nowadaysknown as the S1 interface. Especially for the RAN case,we consider the following groups of AF that will have tobe revisited or introduced:

� Radio CM performing bearer and mobility control,admission control, security functions and error con-trol functions;

� Radio QoS Management performing dynamic res-ource allocation, scheduling, inter-cell interferenceco-ordination, power control;

� Transmission Management performing channel cod-ing, modulation, scrambling, antenna mapping, map-ping between logical and physical channels, H-ARQ;

� Radio Context Awareness performing measure-ment reporting, collecting information required for5G schemes.

At this point, we need to emphasise that especiallyin the case of RAN, some functions (especially PHYand MAC functions) will keep on running on specialisedhardware optimised for performance and energy effi-ciency. On the other hand, higher layer functions (e.g.RRC/RRM) might be executed by general purpose pro-cessing units, thus allowing some level of virtualizationand a more flexible placement according to the needs of thedifferent use cases.

Mechanisms and technologies to instantiate and oper-ate C/D-planes of tailored end to end architectures are outof scope of this work. Some examples thereof may befound in [5]. Nevertheless, it is assumed each instance ofan end to end network architecture will either be realisedaccording to NFV-MANO and software-defined network-ing (SDN) paradigms, or rely on dedicated appliances [13].The C-Plane and the D-Plane may be built upon virtualand/or physical infrastructures, including wireless access

nodes, data centres, edge data centres or points of pres-ence, interconnected by a transport network realised eitherby legacy connectivity methods or by virtual links, vir-tual switches and virtual routers controlled in SDN fash-ion. However, SDN and NFV are initially expected to beintroduced mainly in the core network, with only limitedapplication on the access side.

2.2. End to end network slicing

From Section 2.1, follows the definition of network slicesas instantiation of different logical architectures, over asingle 5G infrastructure, to serve simultaneously hetero-geneous sets of services. Figure 1 shows two examples ofmobile network slices instantiated on Data Centres (DC),Points of Presence (PoP) and SDN Controller platforms(SDN-C). Slice 1 (continuous line) includes AF1 and NF1,NF2 and NF3. Slice 2 (dashed line) consists of AF2, NF4and NF5. Without digging into details, which might addunnecessary complexity at this stage, the examples aimat highlighting different sets of NF, instantiated on differ-ent infrastructure, are included in different slices. NFs canbe implemented using legacy network elements on ded-icated hardware or virtual NF executed in DC like NF1and NF5. In the second case, they may also run as appli-cations on top of an SDN controller like NF2, NF3 andNF4. The interconnections between different NFs can bedynamically provisioned following the basic SDN princi-ples. Additionally, AF1 and AF2 may refer to differentradio access technologies or to the same technology usingdifferent RAT settings and may be composed by diversesets of Access sub-functions (not shown in the picture).Finally, Figure 1 illustrates that different isolated slicesmay be coexisting over the same 5G infrastructure, simul-taneously manageable and accessible via a common set ofAccess Points (APs). These considerations provide a qual-itative evaluation of the benefits from end to end slicing:(1) architecture tailoring may be applied to any part ofthe network (Access, Core) and layer of the communica-tion system; and (2) the isolation of slices can be enforcedon different resource domains, from spectrum and otherradio functionalities to transport network resources andstorage/computing infrastructure. In particular, it worthstressing ‘end to end isolation’ allows independent C-Planeand D-Plane slices dimensioning and engineering, andit ensures slices are not impacting on each otherperformance wise.

The definition of the end to end slicing concept unravelsa set of complex issues to be addressed as well, includ-ing end to end slices design, instantiation and operation.Designing a slice for a specific use case requires the defi-nition of C-plane and D-plane architecture, procedures andprotocols upon the basic set of AFs and NFs. Instantiatinga slice necessitates mechanisms for its provisioning overthe available infrastructure, fulfilling related isolation con-straints. Finally, operating slices requires mechanisms forconfiguration, management and monitoring.


X. An et al.

Figure 1. E2E Network slice concept.

2.3. Key issue: device access to end to endnetwork slice

The need to expand the slice scope from core to accessdomains requires additional complexity for devices toselect and attach to the appropriate slice (this in compari-son with early slicing concepts limited to the Core network,like Décor, specified for 4G systems, reviewed in the fol-lowing sections). Complexity arises from a number offactors. First, multiple slices might coexist and be accessi-ble via the same APs, but at the same time, they might havepatchy coverage and may not be available over 100% of theterritory. Second, multi-slice capable 5G devices need tobe able to detect, amongst the available ones, the suitableslice for providing the required service and to attempt theconnection and attachment. Additionally, the control andthe authorisation to attach must be at the network side, toensure an efficient usage of available slices according todevice types and user credentials. Furthermore, the endto end provisioning of network slices needs the design ofdevice attachment procedures leading to reduced latencyand resource utilisation. Moreover, slices isolation is essen-tial in the access domain so that the attachment procedurefor each slice is not adversely affected by the load of otherslices of the same AP.

3. DEVICE TRIGGERED NETWORKCONTROLLED END TO ENDSLICE SELECTION

In this work, a 5G DTNC end to end slice selectionmechanism is proposed. 5G devices can be classified intwo categories: single-slice capable and multi-slice capa-ble devices. A single-slice capable device may connect

(Access Capabilities) and attach (Non-Access Capabili-ties) to one specific slice only. Such devices have limitedcapability (e.g. sensors for Cellular IoT or MTC applica-tions). Multi-slice capable devices may also be developedin the future, capable to connect and attach to multipleslices, possibly simultaneously. Such devices have highcomputing and storage capabilities. The proposed mecha-nism covers 5G devices of both categories. The selectionprocedure consists of three phases, described in the follow-ing subsections: end to end slices advertisement, selectionand attachment.

3.1. End to end slice advertisement

The end to end slice advertisement phase informs devicesabout available slices they may attempt to attach. The sliceinformation is included in the System Information (SI)broadcast by the network APs. Generally, not all slices willbe accessible via all APs.

The SI can be dynamically configured by the relatingAFs (e.g. AFs are programmable) or pre-configured in theAFs (e.g. AFs are not programmable and integrated inthe AP). An example of slice advertisement is illustrated inFigure 2, where the SI broadcast by AP1 includes Slice 1information only, SI broadcast by AP2, AP3, AP4 and AP5include both Slices 1 and 2 information, and SI broadcastby AP6 contains Slice 2 information only.

3.2. Slice selection

After frequency tuning and cell selection, the devicedecodes SI broadcast by the corresponding AP andbecomes aware of the available slices accessible via the AP.Hence, the device is able to select the slice (s) providing the


X. An et al.

Figure 2. E2E slice information advertisement illustration.

required service and to reconfigure RAT settings accordingto SI content. Two modes of operation are possible for thisphase, to suit different device capabilities.

(a) Explicit Slice Selection (ESS): single-slice capa-ble devices may have preconfigured parameters (e.g.slice ID) indicating the slice they may attempt touse. Such information could be also obtained andstored by the device from previous attachments.In this scenario, the devices know exactly whichslice to attach to. By decoding SI, devices candetect whether the slice is accessible via the APand retrieve the radio access information required toattempt the attachment and connect.

(b) Ambiguous Slice Selection (ASS): ASS modeapplies when a device cannot univocally identifythe slice to attach to by the slice ID, or when noneof the advertised slice suits the device requirements.In the ASS mode, the device needs to fully decodethe SI to get an overview of the available slices.Additionally, the device may have the capability toselect a fallback slice in the case no slices match thespecific device requirements.

3.3. Attachment request

After the slice selection, the device triggers the attachmentrequest. Peering with transmission management and RadioCM AFs, the device initiates the access procedure. Slice-specific Radio Access mechanisms and RAT settings mayapply. Radio Access is followed by the establishment ofradio connectivity, after which, the device is able to send anAttach Request message to the AF(s), which then forwardsit to the corresponding CM.

3.4. Attachment accept/reject/redirect

The CM of the selected slice receives and processes theAttachment Request. The CM verifies whether the devicehas the right credentials and whether the slice has suffi-

cient resources to accept the request. If both conditions aresatisfied, the CM sends an Attach Accept message to thecorresponding AF(s), successfully completing the attach-ment procedure at the radio interface. Else, the CM sendsan Attach Reject message to the related AFs, and the pro-cedure concludes with a rejection. Attachment redirectionmay be also supported. If inter-slice communication issupported, the CM may alternatively re-direct the AttachRequest message to a target CM belonging to another slice,compatible with device request and credential. If the targetCM acknowledges the Attachment Redirect Request, theCM and AF(s) of the slice originally selected by the devicecomplete the procedure at the radio interface by sending anAttach Redirect Command message to the device, forcingit to attach to the target alternative slice.

4. CASE STUDY: 5G DESIGN FORE2E SLICING SUPPORT

This section provides some design guidelines to evaluatepros and cons of the proposed selection scheme. Becausethe end to end slicing affects both access and core net-work, we propose the required RAN and CN enhancementswith respect to a 4G system (i.e. LTE/EPC), which is takenas ‘baseline’. Although the ‘end to end’ slices may enjoyfull customisation (including radio AF selection), for thesake of simplicity, in this case study, we assume that allslices implement the same air interface and use the samespectrum bands.

4.1. Radio access enhancements for end toend slice support

An LTE compliant physical layer is assumed, as wellas a common Broadcast Channel (BCH) and a commonDownLink Shared Channel (DL-SCH) for all slices. Slicedifferentiation starts at transport level, where slice spe-cific transport channels are defined. (Other solutions arealso possible.)


X. An et al.

Figure 3. DL/UL RAN Enhancements.

Referring to the LTE protocol stack, Figure 3 showsslice specific AFs (white boxes), slice specific transportchannels (white circles) and transport channels commonto all supported slices (black circles). A Master Informa-tion Block (MIB) is transmitted on a Broadcast ControlChannel (BCCH), which is mapped onto a common BCHand DL-SCH (as described in Section 4.2). Slice specificfirst SIBs (SIB1s) are transmitted on slice specific DL-SCHs. Slice specific DL logical channels are mapped ontoslice specific DL-SCHs. Slice specific RACHs and UpLinkShared Channels (UL-SCHs) are also defined.

4.2. System information enhancement forslice advertisement

In 4G LTE system, after initial cell synchronisation, adevice can receive and decode SI via the BCH of an AP,which contains all information for an initial random accessto the cell. The SI has two components: the MIB and anumber of SI Blocks (SIBs) [14]. The MIB gives referencesand scheduling information to a number of SIBs in a cell.The SIBs contain the actual SI.

In order to enable an end to end slice advertisement, theSI needs to be enhanced including end to end slices accessrelated information. Hence, by decoding SI, a device getsinformation about the available end to end slices accessiblevia the related AP and can directly trigger the attach-ment attempt to the selected slice. The slice access relatedinformation included in the SI consists of two elements:(a) Slice Description Information; and (b) correspondingRadio Access Information. Slice Description Informationshall contain slice ID and slice specific E2E perfor-mance/functional descriptor. Performance description may

include guaranteed E2E latency, minimum or maximumthroughput, guaranteed reliability and availability. Func-tional descriptor refers to the C-plane and/or D-plane andmay indicate the functions supported by the slice (e.g.mobility, AS/NAS encryption parameters, local authenti-cation, etc). The Radio Access Information specifies, foreach slice, the exact RAT setting (e.g. waveform, codingschemes, modulation, specific AF or NF supported by theslice, etc.). Referring to LTE radio interface, the required SIenhancement can be achieved keeping MIB unchanged andmodifying SIB. SIB1 is extended including available slicesinformation (i.e. slice ID) and scheduling information foradditional SIBs carrying further radio access informationrequired to perform the attachment procedure. For eachslice, a new SIB is introduced to describe the necessaryRAT setting enabling the uplink channels for access. Com-mon SI, applying to all slices, is kept in the conventionalSIBs without modifications. For example, assuming an APsupports M E2E slices, SIB1 shall contain slice IDs andscheduling information necessary to decode SIB2.i (wherei D 1..M). SIB2.i shall carry RAT settings that devicesshall use to perform radio access to slice i.

4.3. SIB structure for pre ordynamic configuration

To support ESS and ASS modes, enhanced SIBs require adifferent definition. ESS support requires slice descriptioninformation to be either pre-configured in the device hard-ware (e.g. SIM card) or obtained from previous attachment.Such information allows the device to select directly theslice(s) to attach. In this case, SIB1 needs to contain sliceIDs of the supported slices only, together with the related


X. An et al.

scheduling information of the SIB2.i, where i D 1: : :N andN is the number of supported slices. SIB2.i contains radioaccess information for the i-th slice. Having slice descrip-tion information preconfigured, each device can identifythe slice to select based on its ID and retrieved radio accessinfo from SIB2.i. ASS support requires full slices descrip-tion information to be broadcast on SIB1. In this case, SIB1shall include slice IDs, slice description information andrelated scheduling information of the SIB2.i.

4.4. Core network enhancements for endto end slice support

A detailed description of the core network design will beincluded in further works. Core Networks slicing needsto be completely rethought compared with 4G EvolvedPacket Core (EPC). To analyse the DTNC slice selectionmechanism, it is sufficient to investigate the direct con-nection of slice specific AFs to slice specific CM. Asa termination of NAS signalling, the CM is responsibleto steer the slice attachment procedure by processing ofthe Attach Request message (generated by the device anddirectly transferred to the core network by AFs) and inter-acting with other involved NFs. Figure 4 depicts the endto end slice attachment procedure according to the pro-posed DTNC selection mechanism. The support of twoslices is assumed. The AP executes the Slice Advertise-ment phase broadcasting SIs on common BCCH (step 1).Upon Slice Selection, the device triggers the Attachmentprocedure, accessing slice specific RACH (step 2; wherethe device connects to AF’). After establishing radio con-nectivity to AF’ (steps 3, 4 and 5), the device sendsthe Slice’ Attach Request message to AF’, which is for-warded to CM’ (step 6). The execution of the attachmentprocedure at core network side (step 7, not describedin details and involving other NFs), includes device cre-

dential verification, address allocation and basic D-Planesetup. The procedure is concluded at core network sidewhen CM’ sends the Slice Attach Accept message to AF’(step 8), which then completes the whole procedure at theradio interface.

5. PERFORMANCE EVALUATION

As important preamble to this section, it is essential to re-state the key benefit from the introduction of end to endslicing lays in allowing full isolation and independenceamongst slices. The performance of each slice accordingto its target KPIs is not influenced by C-Plane and D-Planeload of any other slice coexisting over the same physi-cal infrastructure. For this reason, it becomes relevant toassess how fast and at which cost each device can selectand access to the wanted slice.

The performance evaluation herein presented aims atdemonstrating both performance and costs of the DTNCend to end slice selection mechanism, in a 5G scenariowhere multiple slices for diverse services are to be sup-ported. For sake of simplicity, the system is assumed tosupport two slices only: mMTC slice and eMBB slice.

The evaluation focuses on latency reduction during sliceselection and attachment and on resource consumptionrequired to support the DTNC mechanism.

5.1. Performance benchmark: DécorC

As performance benchmark, an alternative slice selectionmechanism has been considered, denoted in the followingas DécorC. Conceived as an evolution of Décor procedures(as specified in [10]), it allows the RAN tailoring accordingto slice requirements, albeit it does not support the end toend slicing concept.

Figure 4. DTNC slice selection and attachment procedure.


X. An et al.

Figure 5. Décor compliant slice attachment procedure.

Figure 6. DécorC slice attachment procedure.

To be compliant to Décor principles, network slicingshould apply to Core Network only. Additionally, the com-mon RAN AF would forward the slice Attachment Requestto a common CM, which would verify device credentialsand re-route the message to the concerned slice specificCM. A Décor compliant Attachment procedure is shown inFigure 5.

DécorC slice selection and attachment procedure com-plies with Décor principles, and at the same time, it enablesslice specific RAN tailoring. The procedure, simplifiedand illustrated in Figure 6, assumes the slice attachmentattempt to be re-routed directly by a common AF to whichall devices preliminary access to. After receiving availableslices information from the Common AF (allowing attach-


X. An et al.

ment rerouting), each device re-submits the Attach Requestmessage to the concerned slice specific AF.

5.2. Traffic mix and system configuration

As already stated, only the support of mMTC and eMBBslices is assumed. The mMTC deployment scenario con-siders a number of devices ranging between 30k and 300kdevices per cell [15]. As far as concerning the mMTCsignalling traffic model, two attach patterns have beenconsidered. For the first one (moderate RAN load case),device attachment requests are uniformly distributed with10 s Inter-Arrival Time (IAT). For the second (congestedRAN case), device attachment requests follow a Beta-distribution (with parameters ’ D 3, “ D 4, IAT D 10 s).In both cases, it is assumed that the deployed mMTCdevices generate signalling traffic several orders of mag-nitude higher than the eMBB devices, as few hundredsof eMBB devices per cell with attachment rate �10�1hare assumed. For this reason, eMBB signalling traffic isnegligible when compared with the mMTC signalling.

In the DécorC case, both mMTC and eMBB devicesneed a preliminary access to the common RACH and thecommon AF, in order to perform an attachment, beforebeing redirected to the slice specific RACH and AF. In theDTNC case, differently, devices can directly access to theslice specific AF via the slice specific RACH.

Tri-sector cells with 1000 m inter site distance and10 MHz bandwidth have been considered. In the ran-dom access procedure, LTE preamble format 0 is used.Sixty-four preambles can be randomly selected by thedevices for the network access request. If two devicesselects the same preamble at the same time, the networkcannot identify the devices individually; thus, the pream-ble has to be reselected and retransmitted again. The timewindow that the device should wait for the network ran-dom access response is set to 5 ms. In case of collision, thedevice reattempts the random access after a back-off timeuniformly distributed between 0 and 25 ms. Flat Rayleighfading, ideal channel estimation and error-free uplink anddownlink signalling channels have been assumed.

Message transfer delay across all system interfaces isassumed equal to 1 ms; the message processing time at eachAF and NF increases with the signalling load and rangesbetween 0 and 3 ms. At core network side, the averagedelay contribution for device authentication and address-ing is set to 50 ms, while the average D-Plane set up timeis assumed equal to 20 ms.

5.3. Performance analysis

The analysis primarily focuses on the mMTC slice perfor-mance. The first KPI examined is the mMTC attachmentdelay. Figure 7 illustrates the average slice attachmentdelay for DécorC and DTNC selection mechanisms for anincreasing number of devices. Both the moderate load andcongested cases are depicted. From the graph, it resultsthat DTNC gives approximately a 25% delay reduction

100

120

140

160

180

200

220

240

260

0 0.5 1 1.5 2 2.5 3 3.5

)sm(

yaleD

tnemhcatt

AecilS

Number of MTC Devices (105)

DTNC, Moderate RAN Load

DTNC, Congested RAN

Figure 7. mMTC slice attachment average delay.

1

1.5

2

2.5

3

3.5

4

4.5

5

5.5

0 0.5 1 1.5 2 2.5 3 3.5

PD

SCH

Ove

rhea

d (k

b)



DTNC, Congested RAN

Figure 8. PDSCH signalling: DTNC vs. DécorC overhead.

compared with DécorC. This applies to both cases, regard-less the load. Also, the figure highlights that both schemesmay suffer from heavy signalling load, although the mMTCattachment delay for DTNC is less influenced. Simulationresults also highlighted benefits relating to slices isola-tion at Radio Access. Although not shown in charts, whereonly mMTC performance is reported, in the DTNC case,the eMBB average attachment delay was not affected bythe mMTC heavier load, whereas, in the DécorC case,the two slices showed comparable attachment delay per-formance (as devices access the same RACH to connectto both slices). This demonstrates the benefit of the end toend slicing concept, which allows earlier isolation amongstslices (enabling slice access using a slice specific RACH).For this reason, the DTNC performance of the eMBB slicein terms of attachment delay was not deteriorated by thesignalling pattern characteristic of the mMTC traffic.

The PDSCH and PUSCH signalling overhead are alsoshown in Figures 8 and 9, respectively. The overhead gainprovided by the DTNC scheme is about 50% comparedwith the corresponding results attained with DécorC algo-rithm. In the congested RAN case, more than one enddevices may use the same preamble for access. The APsends UL resource grant in PDSCH, and then more thanone end devices send RRC connection setup using thesame RB in PUSCH, which results in collisions. There-fore, retransmission is triggered; hence, more collisions


X. An et al.

0.3

0.4

0.5

0.6

0.7

0.8

0.9

0 0.5 1 1.5 2 2.5 3 3.5

PU

SCH

Ove

rhea

d (k

b)



DTNC, Congested RAN

Figure 9. PUSCH signalling, DTNC vs. DécorC overhead.

20

30

40

50

60

70

80

90

100

0 5 10 15 20 25 30 35 40

)s/bk(eta

RtsacdaorBIS

Number of Supported Slices

DTNC (ESS)

DTNC (ASS)

Figure 10. SIB overhead, DécorC, ESS, ASS.

result in more repeated messages in PDSCH and PUSCH,regardless the slice selection scheme in use.

However, it is worth mentioning that the aforementionedgains come at the expenses of a slightly reduced sys-tem capacity, as some additional bandwidth is requiredfor slice advertisement. For the DécorC case the stan-dard LTE SIB format was assumed, where 2216 bit SIB1is broadcast every 80 ms. Each slice attachment requires52 bits for uplink grant, 1112 bits for RRC ConnectionSetup Response (PDSCH), 80 bits for RRC ConnectionSetup Request and 208 bits for RRC Connection Setupcomplete (PUSCH). Additionally, slice description infor-mation needs to be transferred to the device after attachingto a default slice (128 bits). Hence, to support N slices,2N � 128 bits need to be transmitted. The proposed DTNCmechanism needs to extend the SI with slice information.The length of SIB1 (Le) is extended with the slice informa-tion and can be computed as Le D Ls C N.nC log2.N C19//2, where Ls is the standard SIB1 length, n representsthe additional bits used in SIB1 to describe the periodicityof the new SIBs; and log2.NC 19/ bits is used to index thenew SIBs under the assumption that SI have in total N newSIBs plus LTE standard SIBs [14]. Further, we considerthe code rate (2, 1) to protect the period length and SIBindex. If the slice description information is pre-configuredin the device (ESS), each additional SIB contains 128 bitsof radio access information. If the device does not have the

slice description information in advance (ASS), additional128 bits should be used in each new SIB.

The BCH signalling overhead for the two modes of oper-ation (ESS and ASS) of DTNC mechanism is comparedwith the DécorC baseline in Figure 10, for an increas-ing number of supported slices. The SIB Broadcast Rateremains constant at 30 kb/s for the DécorC case, while itsurges linearly when the DTNC scheme is used and reaches�70 and �95 kb/s in the ESS and ASS cases, when up to35 slices are supported, resulting �2 and �3 times higherthan the baseline, respectively.

6. CONCLUSIONS

In this article, we reviewed the notion of Flexible (Plastic)Architecture and proposed a novel concept of End toEnd Network Slicing for next generation communica-tion systems. Both solutions are required to developnetwork architectures tailored to 5G use cases and toinstantiate and operate them separately on top of 5Gvirtual/physical infrastructures.

Paired with those concepts, we explored the crucial issueof network slice selection and attachment, and we proposeda solution to the problem: a novel DTNC mechanism.

Considering a scenario where separated network slicesfor eMBB and mMTC were supported, we evaluated theDTNC performance, in terms of slice attachment delayand signalling overhead, and we estimated its drawbacks,in terms of additional capacity required to broadcastenhanced SI required by the DTNC mechanism. Perfor-mance improvements and deterioration were comparedwith a 4G compliant method, denoted as DécorC, whereslicing applies to the core network only. Quantitativeresults reinforce arguments in favour of the proposed E2Eslicing concept: in the simulated scenario, DTNC yields toup to 25% attachment delay and 50% signalling overheadreduction, while drawbacks appear to be negligible, as longas the number of supported slices remains tied up with themost plausible 5G usage scenarios.

REFERENCES

1. ITU-R. IMT Vision – Framework and overall objec-tives of the future development of IMT for 2020 andbeyond. M Series, September 2015. Available from:http://www.itu.int/rec/R-REC-M.2083 [Accessed onFebruary 2016].

2. Tech4i2, Real Wireless, Trinity College Dublin, andInterDigital. Identification and quantification of keysocio-economic data to support strategic planning for theintroduction of 5G in Europe. SMART 2014/0008, StudyPrepared for the European Commission, March 2016.

3. 5G-PPP, ERTICO, EFFRA, EUTC, NEM, CON-TINUA and Networld2020 ETP. 5G empowering ver-tical industries. White Paper, February 2016. Availablefrom: https://5g-ppp.eu/roadmaps/ [Accessed on February2016].


http://www.itu.int/rec/R-REC-M.2083https://5g-ppp.eu/roadmaps/

X. An et al.

4. 3GPP. Technical Specification Group Services andSystem Aspects; Feasibility Study on New Services andMarkets Technology Enablers; Stage 1 (Release 14),v0.1.0. Technical Report.

5. Trivisonno R, Guerzoni R, Vaishnavi I, Soldani D.SDN-based 5G mobile networks: architecture, functions,procedures and backward compatibility. Transactionson Emerging Telecommunications Technologies 2015;26(1): 82–92.

6. NGMN. 5G white paper. White Paper, v1.0, February2015.

7. Kokku R, Mahindra R, Zhang H, Rangarajan S. Cell-Slice: cellular wireless resource slicing for active RANsharing. In Fifth International Conference on Communi-cation Systems and Networks (COMSNETS), Bangalore,2013; 1–10.

8. Caballero Garces P, Costa Perez X, Samdanis K, BanchsA. RMSC: a cell slicing controller for virtualizedmulti-tenant mobile networks. In IEEE 81st VehicularTechnology Conference (VTC Spring), Glasgow, 2015;1–6.

9. Van Giang N, Young HK. Slicing the next mobilepacket core network. In 11th International Symposium onWireless Communications Systems (ISWCS), Barcelona,2014; 901–904.

10. 3GPP TR 23.707 V13.0.0 (2014-12). Technical Specifi-cation Group Services and System Aspects; ArchitectureEnhancements for Dedicated Core Networks; Stage 2.

11. Trivisonno R, Guerzoni R, Vaishnavi I, Soldani D.Towards zero latency software defined 5G networks. InIEEE International Communication Conference (ICC),London, 2015; 2566–2571.

12. 3GPP TS 36.300 R13. Evolved Universal TerrestrialRadio Access (E-UTRA) and Evolved UniversalTerrestrial Radio Access Network (E-UTRAN); Overalldescription; Stage 2.

13. ETSI GS NFV-MAN 001. Network Functions Virtuali-sation (NFV); Management and Orchestration.

14. 3GPP TS 25.331, V13.0.0. Radio Resource Control(RRC); Protocol specification.

15. METIS. Scenario, requirements and kpis for 5g mobileand wirelss system, September 2014.


On end to end network slicing for 5G communication systemsABSTRACTIntroduction5G Architecture and Network Slicing: an End to end ViewEnd to end network architectureEnd to end network slicingKey issue: device access to end to end network slice

Device Triggered Network Controlled End to End Slice SelectionEnd to end slice advertisementSlice selectionAttachment requestAttachment accept/reject/redirect

Case Study: 5G Design for E2E Slicing SupportRadio access enhancements for end to end slice supportSystem information enhancement for slice advertisementSIB structure for pre or dynamic configurationCore network enhancements for end to end slice support

Performance EvaluationPerformance benchmark: Décor+Traffic mix and system configurationPerformance analysis

ConclusionsREFERENCES

On end to end network slicing for 5G communication...

Documents

Transcript of On end to end network slicing for 5G communication...