a practical open source solution for end-to-end network slicing

This is a postprint version of the following published document: García-Avilés, Ginés; Gramaglia, Marco; Serrano, Pablo; Banchs, Albert. POSENS: a practical open source solution for end-to-end network slicing, in: IEEE Wireless Communications, 25(5), November 2018, pp. 30-37 DOI: https://doi.org/10.1109/MWC.2018.1800050 © 2018 IEEE. Personal use of this material is permitted. Permission

from IEEE must be obtained for all other uses, in any current or future

media, including reprinting/republishing this material for advertising

or promotional purposes, creating new collective works, for resale or

redistribution to servers or lists, or reuse of any copyrighted

component of this work in other works.

1

POSENS:apracticalopen-sourcesolutionforend-to-endnetworkslicing

GinesGarcia-Aviles, MarcoGramaglia,PabloSerrano,AlbertBanchs

Abstract—Networkslicingrepresentsanewparadigmtoop-erate mobilenetworks. Withnetworkslicing,theunderlyinginfrastructureis“sliced”intologicallyseparatenetworkswhichcanbecustomizedtothespecificneedsoftheirtenant.Hand-onexperimentsonthistechnologyareessentialtounderstanditsbenefitsandlimits,andtovalidatethedesignanddeploymentchoices. Whilesomenetworkslicingprototypeshavebeenbuiltfortheradioaccessnetworks(RANs),leveragingonthe wideavailabilityofradiohardwareandopensourcesoftware,thereiscurrentlynoopensourcesuiteforend-to-endnetworkslicingavailabletotheresearchcommunity.Inthispaper wefillthisgapbydevelopinganend-to-endnetworkslicingprotocolstack,POSENS, whichreliesonaslice-awareshared RANsolution.Wedesigntherequiredalgorithmsandprotocols,andprovideafullimplementationleveragingonstate-of-the-artsoftwarecomponents. WevalidatetheeffectivenessofPOSENSinachievingtenantisolationandnetworkslicescustomization,showingthatnopriceinperformanceispaidtothisend. Webelievethatourtoolwillproveveryusefultoresearchersandpractitionersworkingonthisnovelarchitecturalparadigm.

I.INTRODUCTION

5GNetworkswillchangethewayinwhichcellularcon-nectivityisprovided.Highdatarates(50+ Mbps),extensivecoverage(10+ Tbps/Km2)andlowlatencies(<5 ms)arejustfewofthetarget KeyPerformanceIndicators(KPIs)tobefulfilledbythenextgeneration mobilenetworks[1].However,notallservicesaregoingtorequirethese KPIs,asdifferentapplicationswillhavedifferentrequirements.Toefficientlyprovideservicesthatmeettheserequirements,onekeyenablingtechnologyisnetworkslicing[2].

Anetworksliceconsistsofasetofresourcesassignedtoatenanttoprovideaspecificservice.1Thoseresourcesarebothnetworkresources(e.g.,spectrum,linkcapacities),andcloudresources(i.e.,theinfrastructurerequiredtorunthe VirtualNetworkFunctions,VNFs).Tenantscouldbemobilenetworkoperatorsprovidingenhanced MobileBroadband(eMBB),orthirdpartyverticals[3]thatuseaslicespecificallytailoredtotheirneeds(e.g.,ultra-lowlatency).Tosatisfytheservicerequirementsofeachtenant,adifferentnetworkslice willbeinstantiatedtoprovidethecorrespondingservice. Thisabilitytoprovidehighlycustomizableservicesoverthesamesharedinfrastructurewillincreasetherevenueopportunities,anddrasticallyreducethecostsof5Gnetworking,duetotheimprovementsinefficiency.

Theadvantagesofnetworkslicingareclear[4],andthereisawideconsensusamongtheindustrialandstandardization

G.Garcia-AvilesandA.BanchsarewithUniv.CarlosIIIde Madrid,Spain,andwithInstituteIMDEANetworks,Spain.

M.GramagliaandP.SerranoarewithUniv.CarlosIIIde Madrid.1Inthispaper,wewilluseirrespectivelythetermsslice,tenantandservice.

communitiesontheneedtoadoptthistechnology.However,welackathoroughexperimentalvalidationofitseffective-ness,e.g.,onthegainswhenusingdifferentmechanismsfororchestrations,orunderdifferenttrafficscenarios. Whilethereareimplementationsforsomeofthetheenablersfornetworkslicing,tothebestofourknowledgethereisnosolutionthatimplementsend-to-endnetworkslicing. Morespecifically,virtualizationisamaturetechnologythathasbeenextensivelyusedforthe wiredelements, withtechnologiessuchase.g.OpenStack2andKubernetes3forvirtualmachineandcontain-ers management,respectively. However,thesituationislessmatureforthe wirelessaccesspart, Orion[8]beingamongthefewproposalstoimplementslicingattheRadioAccessNetwork(RAN)thathavebeentestedinpractice.

Inthispaper,wefillthisgapwiththedesignofPOSENS,apracticalopen-sourcesolutionforend-to-endnetworkslicingthatcomprisesalltheelementsofanend-to-end mobilenetwork:theUserEquipment,theRANandtheCoreNetwork.POSENSimplementsa“slice-awaresharedRAN”solution,enablingtheeffectiveandefficientsharingofthenetworkresourcesbetweendifferenttenantsthatcanindependentlyprovidedifferentservices.

While POSENS isbasedonstate-of-the-artopen-sourcesolutionsformobilenetworks,thesearesubstantiallyextendedwiththefollowingadditionalimplementations: (i)a multi-slice UE,(ii)aslice-awareshared RANsolution,and(iii)specific multi-slice ManagementandOrchestration(MANO)capabilities,allofwhichareneededtoprovideanend-to-endsolutionfornetworkslicing.

POSENSprovidesacompletesolutiontoinstantiateend-to-endslices,usingcommodityhardwareandSoftwareDefined-Radio(SDR)boardsfordevelopment.Ourresultsshowthatitsupportstheefficientinstantiationofindependent,customiz-ablenetworkslices.Thisopen-sourcesolutionisavailable4fordeveloperstoputtheirslicingideasinpractice.Thistoolwillthussupportresearchersandpractitionersexperimentingwithdifferentalgorithmsandmechanismsfornetworkslicing.Thecodebaseincludesthe mostimportantnetworkelementsandthe MANOpart.POSENScanrunonanycompliantphysicalhardware,independentlyofthedeployedtransportnetwork.

Therestofthispaperisorganizedasfollows.SectionIIprovidesadiscussiononthebuildingblocksneededtoimple-mentthenetworkslicingconcept,includingareviewofopen-sourcesoftwareprojectsinthefieldofvirtualized wireless

2https://www.openstack.org3https://kubernetes.io4Thesourcecodeanddetailedinstallationguidelinesareavailableathttps:

//github.com/wnlUC3M/

2

mobilenetworking. Wedescribethedesignof POSENSinSectionIII,andvalidateitsefficiencyinprovidingisolationacrossslicesinSectionIV.Finally,SectionVconcludesthepaper.

II. THEPATHTOWARDSEND-TO-ENDNETWORKSLICING

Networkslicingcanbeseenasaconsequenceofthesoftwarizationoftheprotocolstack. Wenextreviewthepathtowardsthissoftwarization,highlightingthecomplexityinvolved withsharing RANresourceacrosstenantsduetothetightsynchronisationrequired.Then,wereviewdifferentapproachestosharetheRAN,eachoneimposingadifferenttrade-offbetweenefficiencyandisolation.Finally,wereviewthemostpromisingsoftwaresolutionstoinstantiateamobilenetwork,identifyingthebuildingblocksforthedesignandimplementationofPOSENS.

A.Softwarizationofnetworks

4Gandpreviousnetworksareusuallycomposedofmono-lithicphysicalboxes,eachoneprovidingaveryspecificfunctionalityandrunningspecialisedsoftwareonspecialisedhardware.5Gandfuturenetworkswillbebasedonnetworkfunctionvirtualization(NFV)andsoftwaredefinednetworking(SDN),thesetechnologiesenablingflexiblenetworkdeploy-mentsthankstonetworkprogrammability.5

Inthisnewapproach,anetworkisdecomposedintothreelayers:(i)infrastructure, whichconsistsingeneral-purposehardware(e.g.,cloudcomputingservers),(ii)network,com-posedbyallthenetworkingfunctions,virtual(VNFs)orphysical(PNFs),and(iii)managementandorchestration,thatextendsthelegacy managementlayer(e.g.,theElementManagersdefinedby3GPP)tosupporttheinstantiationandorchestrationofnetworkfunctions.

ThisapproachisrepresentedinFig.1,whichillustratesoneconfigurationofthetestbedthatweusetovalidatePOSENS,wherethesameUserEquipment(UE,inPOSENSa“Multi-SliceUE”)runstwoindependentslices(blueandred)overthesamesetofphysicalresources.Theinfrastructurelayeriscom-posedbyalaptop,twoSDRcards(USRPB210boards)thatprovidetheRFfrontend,andasmallsetofservernodes.Thenetworklayerrunsoverthisinfrastructure,andiscomposedoftherequirednetworkfunctionssuchastheRAN,HSS,S/P-GW.6Finally,themanagementandorchestrationalsorunsoverthesameinfrastructure,andisinchargeofinstantiatingandconnectingthenetworkingfunctionscomposingtheslices.

Tosupporttheabovevision,datafromdifferentslices(andnotnecessarilyfromdifferentUEs)hastobe(de)multiplexedoverasetofsharedresources.Thatis,the mobilenetworkprotocolstackhastobedividedinto VNFsthatexplicitlybelongtoonetenant(i.e.,usuallythecorenetwork),andfunctionsthataresharedacrossthem(i.e,usuallytheaccessnetwork,tolowerthedeploymentcosts).Thisimposessome

5Infact,oneofthemostrelevantfeaturesoffuture5GNetworksistoreducethetimeneededtodeployanewservicefrom90minutesto90seconds.

6InPOSENSweuseLTE/EPCVNFsastheyarecurrentlytheonlyopen-sourceoptionavailable. However,POSENSmayeasilyintegrateother5GVNFs,especiallytheonesrelatedtotheCN.

novelrequirementsonvariouselements,inparticular,ontheRANfunctionstosupporte.g.,theexistenceofmultipleCoreNetworks(CNs),orforthe UEtoattachto multipleslicesatthesametime. Allowing UEstosimultaneouslyaccessdifferentslicesisessentialfor manyscenariosenvisionedin5G,includingthesimultaneousaccesstoservicessupportedbydifferentslicesas wellastheprovisioningofaservicethatemploysmultipleslices.Forinstance,for“Industry4.0”scenarios,augmentedrealitydevicescouldconnecttoan“industrial”sliceandtoanenhancedmobilebroadbandslice;forvehicularscenarios,differentslicescouldbeusedforautomateddrivingandforinfotainmentservices.Thisisinlinewiththe3GPPSA2standardizationwork,whichenvisionsa5Gcorenetworkthatcanattachtoupto8networkslicesinstancesatthesametime.This multi-slicesupportrequiresthattrafficfromdifferenttenantshastobehandledoverthesamespectrum, which makesit morecomplextohavededicated/customizedRANsfordifferentslices.Inwhatfollows, wediscusshowtoperform RANslicingfromanarchitecturalpointofview.

B.AddressingtheRANslicing

Wenextpresentthethreearchitecturaloptionsthathavebeenproposedintheliterature[4]forRANNetworkSlicing.Theseoptionsarepresentedinorderof“increasingdepth”inFig.2, wherethedeepertheslicing(the“MUX”blockrepresentsthisdepth),thelessfunctionsaresharedbydifferenttenants.

Theleftmostoption(“Option1”)istheso-called slice-awaresharedRAN,whichbasicallyconsistsinsharingthecomplete RAN,andtheneachtenantisresponsibleforitsCN. Withthisoption,thesameUEcanusedifferentslices,andthereforeconnecttodifferentCNs.Thissolution,whichcanbeconsideredasthe“basic”solutiontosupportnetworkslicing,providesrelativelylittleisolationacrosstenants,butalsoleadstothehighestpotentialgainsintermsofefficiency.Thissolutioncanberelated withsomecurrentproposalssuchas3GPPLTEeDECOR[10],introducedtosupporttheinstantiationofdedicatedCNs. However,eDECORrequiresintroducingchangestotheCNandnewsignaling messagesfortheconnectionsetup(somethingthatPOSENSdoesnot).Wealsoremarkthat3GPP RAN3 Working Group[11]isconsideringafunctionalsplitperformedatthislevel.Thisapproachnicelyfits withthesharedRANslicingoption,inwhich multiplenetworkslicesarehandledbyacentralizedunit. While withthisoptionthe RANissharedtoalargeextentbydifferentslices,thecoreinstancesarecompletelyindependentamongtenants,allowingper-tenantconfiguration,orchestrationand(cloud)resourceassignment.

Thecentraloptioninthefigure(“Option2”)istheslice-specific Radio Bearerconfiguration. Withthisoption,theslicinggoesdeeperinthenetworkstack,andbasicallyonlycell-specificfunctionalityareshared,i.e.,thePHYand MAClayersintheuserplane,andtheRRCinthecontrolplane.Thisconfigurationincreasestheresourceisolationbetweentenants,atthepriceofahighercomplexityatthe MAClayer(forinstance,tofullyexploitthisresourceisolation,slice-awareschedulingalgorithmsarerequired).

3

!"#$%&!'%$#(#$&!%)*#$%+ !"#$%&!'%$#(#$&!%)*#$%+

!,-./0

112 3!!

!,-./0

112 3!!45)%

456'78%&95:%&;<

456'78%&95:%&;=

45>8)5""%)&95:%

!/ !/

!"#$%&'

("#$%&'

17"8#.!"#$%%9?

17"8#.!"#$%@2

@!A-&?=<B@!A-&?=<B

!"#$%&!'%$#(#$&4"#%>8

!"#$%&!'%$#(#$&4"#%>8

1C>CD%6%>8&C>:&E)$F%+8)C8#5>

AG9

)$*('+,

)$*('+-

Fig. 1: A multi-slice network architecture. We also used thisblueprintfor the evaluation ofPOSENS.

!"##"$%&'(%)$*+(,-.+

!"##"$%/-0+1-$2%3(".+00'$4

56!

37!3

56!

37!3

55! 55!

8&9 8&9

9:'.+%; 9:'.+%<!"(+

5&8

=>?

=&!

56!

37!3

=&!

56!

37!3

55! 55!

8&9 8&9

9:'.+%; 9:'.+%<

@A*'"$%B@A*'"$%<

=>?!"##"$%+8/

55! 55!

8&9 8&9

9:'.+%; 9:'.+%<

@A*'"$%;

=>?

!"#$%&'"()#$*+,-$.

/0+&-.1("22-'-".'3

Fig. 2: Different RAN slicing options.

Finally, the last option (“Option 3”) is the so-calledslice-specific RAN. In this case, only the air interface is sharedamong network slices, while all the other functionality isinstantiated specifically for each tenant. This configurationprovides the maximum degree of freedom, given that eachnetwork slice can be customized down to the physical layer.However, this option also requires a tight synchronizationbetween the multi-tenancy policies implemented by a commonpart, and the per-slice (dedicated) implementation.This option could be particularly useful in scenarios where

different radio access technologies coexist within the sameshared spectrum, e.g., 4G and 5G. Since it may be verychallenging to dynamically reallocate spectrum resources at afine time granularity, this option may potentially harm resourceutilization and limit the potential multiplexing gains.The above options can be regarded as a “roadmap” to enable

a fully configurable protocol stack to support any networkslicing option, where each option presents a different trade-off between efficiency, isolation and complexity. For the firstrelease ofPOSENS, we decided to implement “Option 1,”which can bring the maximum efficiency gains and providesend- to-end slicing, in this way providing researchers with a

tool to experiment with different algorithms and mechanisms.Although options 2 and 3 provide a higher degree of isolationbetween slices, “Option 1” already enables key features with-out requiring the complexity of more advanced RAN schema.7

More specifically, this option readily supports experimentationon fundamental research items in 5G, such as(i)per-tenantService Function Chaining (SFC), as the network slices flowsgo through chains that contains instantiations of differentVNFs, or(ii)per-tenant orchestration, as different tenants canimplement their own MANO using their preferred software ontheir cloud, enforcing thus service specific management andorchestration policies regardless of other tenants’ ones.

C. Software building blocks

There are several recent initiatives to prototype mobile net-works in software, with most solutions building on the GNURadio development suite and the Ettus Research USRP SDRplatforms, and running on standard Linux-based computingequipment (Intel x86 PC architectures).8We next provide ashort review of the current ecosystem of open solutions.Concerningthe RAN part, three of the most popular SW

solutions to run LTE over SDR are Eurecom’s OpenAirIn-terface (OAI),9openLTE,10and srsLTE.11OAI [12] providesan implementation of a subset of LTE Release 10 elements,including the UE and the eNB. Its performance is consideredrelatively good, although is also acknowledged that the codestructure is complex and difficult to customize. It is also worthmentioning that the eNB and UE RAN are licensed under aspecific OAI Public License.

7While Options 2 and 3 require very tight synchronization among slices,this is not an issue for Option 1 since it employs a conventional RAN stackthat already provides the required synchronization.8We note that there are complete commercial products such as the AmariLTE 100 (a fully softwarebased LTE BS solution), its closed license makesit unsuitable for research activities.9http://www.openairinterface.org/10http://openlte.sourceforge.net/11https://github.com/srsLTE/srsLTE

4

openLTEisanopen-sourceprojectprovidinganimplemen-tationofLTEspecifications,whichincludesaClibrary,Octavecodefortestingdownlinkanduplinkphysicalrandomaccesschannel(PRACH)functionalities,GNURadioapplicationsforDLfunctionalities,bothsimulatedandusingHWplatforms,andasimpleimplementationofaneNBusingUSRP. Whileitscodeisconsideredasrelativelywellorganized,documentedandwouldresulteasiertomodify,itdoesnotprovideanUE,andmanyfeaturesarestillunstableorunderdevelopment.

Finally,thesrsLTE[13]open-sourceprojectprovidesaplatformforLTE Release8experimentation,designedformaximummodularity.TheRANpartprovidesacompleteUEapplicationandacompleteeNodeBapplication.Theprojectis morerecentthan OAI,andingeneralthesourcecodeisconsideredeasytocustomize,althoughitalsoconsumesmoreCPUresourcesthantheotheralternatives.ThecodeisprovidedunderanAGPLv3.0license.

Giventhatouraimistodevelopasolutiontovalidateend-to-endslicing,andnotanefficientsoftwaretoputinproduc-tion,codemodularityandre-usabilityaredeterminantfactorswhenselectingaplatform,andthereforewedecidedtodesignoursolutionasanextensionofthesrsUEandthesrsENB(theapplicationsfortheUEandeNodeB,respectively).

WewereconvincedbythesrsUEsourcecodeavailability,ashavingastableUEsoftwareimplementationisbeneficialforseveralreasons,e.g.,itsupportsthedevelopmentofmulti-sliceinsidetheUE,andspeedsupthedeploymentandtestingofneworchestrationsolutions.

Concerning thecore network,apartfromcommercialsolutionssuchasOpenEPC12(alsosupportingsharedsourcecodelicensing),twoofthemostrelevantsolutionsaretheonesassociatedwiththesameinitiativesmentionedabove.Firstly,srsLTEhasveryrecentlyreleasedsrsEPC,alight-weightCNimplementation,includingthe mobility managemententity(MME),homesubscriberserver(HSS),packetandservinggateways(P-GWandS-GW,respectively),underthesamelicense.Secondly, OAIalsoprovidesthesameelementsforabasicEPCsolution,inthiscasereleasedunderastandardApachev2.0license. Giventhat when westartedour workonlythelatterwasavailable,weusedOAICNasthesoftwaresolutionfortheCN.

OneadditionaladvantageofourPOSENS,whichcontrastseDECOR(seeSectionII-B)isinteroperability:oursolutionworkswithanyimplementationsupportingtheS1APprotocol(weconfirmedthatPOSENSiscompatiblewithdifferentdif-ferentcommercialEPCs,whosenameswecannotdisclosureduetoconfidentialityagreements).

Finally,concerningMANO,ithasreceivedalotofattentionfromboththeopen-sourcecommunityandtheenterprises[14].Thereisawiderangeoffully-fledged MANOtoolssuchasOpenBaton,13Open-O14orOSM,15thatprovidetherequiredfunctionalitiesrelatedtotheVNFlife-cyclemanagement,in-cludingtheirscalingonavirtualinfrastructure.TheyrelyonaVirtualInfrastructure Manager(VIM),asoftwarethatismore

12https://www.openepc.com13https://openbaton.github.io/14https://wiki.open-o.org/15https://osm.etsi.org/

mature,asithasbeenalreadyemployedinproductioncloudcomputingenvironmentssincemanyyears.AmongVIMs,wecanlistsolutionssuchasOpenStack16orOPNFV.17However,askeyrequiredfeaturessuchasper-tenantorchestrationarenotavailablewithexistingopen-sourcesolutions,wedecidedtoimplementPOSENSMANOusingadedicatedsoftwarethatdirectlyleveragesontheVIMAPIs.

Wefinishthissectionbyreviewingstate-of-the-artsolutionson NetworkSlicingthathaverecentlyappeared, which welistinTableI.Tothebestofourknowledge,POSENSisthe mostcompletesolutionasitincludesanopen-source,endtoend,networkslicing-awaremobilenetworkstack,thatincludesalsoa Managementand Orchestrationframework.OthersolutionsareeitherconsideringtheRANonly[5],[6],[7]orneglectingtheUErole[8].Furthermore,POSENSistheonlycompletelyopen-sourcesolutionthatisreadilyavailableinapublicrepository(GitHub).

III. DESIGNOFPOSENS

POSENSprovidesanimplementationofallthe modulesneededforanend-to-endnetworkslicing-aware mobilenet-work.Thisincludeselementsbelongingtoalltherealmsofa mobilenetwork(UE,RANandCN),plusanorchestrationframework.Still,themostimportantenablerofanend-to-endnetworkslicingsetupisRANslicing.

Inthefollowing,wedescribethedesignofoursolutiontosupportRANslicing.Thissolutionconsistsonintroducinganumberofchangesandnew modulestothesrsLTEUEandeNBimplementations.Theresultingsoftwarearchitecture,forthecaseoftwoslices,isillustratedinFig.3,whereeachsliceisdepictedwithadifferentcolor(weconsiderthecaseoftwoslicesforsimplicity,butthesoftwarecanbeeasilyextendedtosupport moreslices). We willalsoassumeforsimplicitythateachsliceisassociatedwithadifferenttenant.

AsdiscussedinSectionII, wedecidedtoimplementinourfirstreleaseofPOSENSthe“Option1”forRANslicing,whereslicesaremultiplexedanddemultiplexedatthePDCPlayer.ThisoptionhastheadditionaladvantageofrequiringlesschangesintheeNBsoftwareimplementation, whichisthe maincauseofinstabilitiesinaSDR-basedtestbed.Thecornerstonesofthesolutionarethe“slicecoalescer”modules,locatedatthePDCPlayerandabove.Thesemodulesforwardingthecontrolanddatalayerinformationforeachsliceoverthecommoncommunicationchannel.AnotherkeyfeatureofourimplementationisthateachsliceattheUEhasitsown RRC module,anddoesnotrequireanyadditionalfunctionalityinsidethe CN. Conversely,attheeNBthereisonlyone RRC module,as withitsdefaultbehavioriscapableofmanagingmultipleNon-accessstratum(NAS)fromvarioususerssimultaneously.Inwhatfollows,weprovideamoredetaileddescriptionoftheenhancementsrequiredbyoursolution,bydescribingthebehavioroftheUEandtheeNB.

A. UserEquipment

The UEplaysafundamentalroleinthenetworksliceselectionprocedure.AsdepictedinFig.3,onesliceperforms

16https://www.openstack.org17https://www.opnfv.org/

5

TABLEI:Recentsoftwarecontributionsfornetworkslicing.

Work BaseSoftware Mainpurpose MainFeature Limitations OpenSource

Mendesetal.[5] srsLTE RANSlicingMultiple,pertenant,eNBvirtualization

.ImplementationonlyuptoMAClayer.

No

Changetal.[6] OAI RANSlicingThoroughevaluationofslicesutilization

RANSlicingonly. No

Foukasetal.[7] OAI RANSlicing SDN-basedRANslicing Itdoesnotincludeacore. Downloaduponrequest

Foukasetal.[8] OAI End-to-endslicingCoreNetworkhandlingmultipleslices

SingleSliceUEonly. No

POSENS srsLTE End-to-endslicing SliceawaresharedRAN. OneRANsplitavailable. Yes

PHY

MAC

RLC

PDCPRRC

MUX

SRB DRB

Slice Coalescer

NAS

USIM

DATA

NAS

USIM

DATA

RRC

S1AP S1APGTPU

RRCSlice Coalescer

GTPU

Slice 1

Slice 2

u-plane

c-plane

Shared

Slice-enabling functions

PHY

MAC

RLC

PDCP

MUX

SRB

Slice Coalescer

DRBDRBDRB

UE

eNB

Fig.3:DesignofPOSENS:changesintroducedattheUEandtheeNodeB.

afullradioconfigurationofalltheRANlayers(includingPHYand MAC),whiletheotheronereliesontheRRCconfigurationparameterssetbythefirstsliceandpreparesthePDCPentitiesandtheRLCchannelmanagers(Acknowledgedmodefortheu-planeandTransparent modeforsignalingmessages).

OncetheUEhasbeenpoweredon,the(unmodified)PHYperformstheusualcellsearch(followingtheconfigurationprovidedwithinthe MIB,SIB0,SIB1andSIB2messages)andsynchronization.Then,theRRCmodulecorrespondingtothefirstslicesetsuptheinitialconnectionwiththeeNBbyperformingtheRandom-Accessprocedure(RA)togetaninitial ULgrant,i.e.,avalidconfigurationforPDCP,RLC, MACandPHY.Thisconfigurationissharedacrossslices,andthereforesubsequentRRCmodules(correspondingtootherslices)willnotrequestit.ThismotivatesthattheRRCConnectionSetupmessagethatarrivesduringtheRAprocesshastobestoredwithinthePDCPmodule,forsubsequentslicestobeabletoestablishtheirsessionwiththeCN.

FollowingtheinitialULgrant,theNASprotocolofthefirstsliceestablishesasession withthe CN,generatingaRRCConnectionSetupCompletemessagenestingtheinitial NAS messagesinthesamepacket.Theselectionofdifferentsliceshappensinasequentialfashion,afterthefirstsliceRRChasconfiguredthe wirelesslink,thesubsequentslicesareconfiguredusingthereceptionofa

RRCConnectionSetupCompleteastriggeringevent.Thatis, upona RRCConnectionSetupCompletethePDCPsendstothenextsliceapreviouslystoredRRCConnectionSetupmessage,containingthedetailsoftheRRCchannel.This,inturn,triggerstheNASauthentica-tionprocedureinthenewslice.EachtimeaslicefinishesitsNASconfiguration,theRRCcallsaslice_configuredfunctionwithinthePDCP,includingthe(slice_id,IPaddress)tupleoftheslice,whichwillsupporttheproperforwardingofinformationwithinthe module(thisisonlyneededforreceivinginformation).Besidescoordinatingthec-plane,theslicecoalescerintheUEalsohastomultiplexanddemultiplextheu-plane.ThisisachievedbyexploitingthedatamultiplexeravailableattheMACfortheuplink:thisfunctiondemultiplexesthedatacomingfromthelowerlayersandforwardstotheappropriatesliceinstanceatthePDCPonaper-destinationIPprefixbasis.

B.eNodeB

ThechangesintheeNBarethecounterpartoftheonesintroducedintheUE.Thatis,theslicecoalescerhandlesthemultiplexinganddemultiplexingofthec-andu-plane.Themulti-sliceupdatesintheeNBarelesselaboratedthantheonesintheUE,astheeNBisalreadycapableofhandlingparallelauthenticationscomingfromdifferentUEs. Weremarkthatmultipleauthenticationscomingfromthesamemulti-sliceUE

6

(suchastheonedescribedinSectionIII-A)canbeconsideredasatomicoperations,astheyhappensequentially.

ThissimplifiestherequiredenhancementsattheeNB,astherearenoconcurrent NASproceduresforthesame UErunningsimultaneously,andthereforeeachonecanusethesameinnerdatastructureavailableattheRRC.Inthisway,weuseaflagto markthesliceunderconfiguration, whichenablesforwardingthecontroltraffictothecorrespondingCNviatheappropriateS1APinterface.

Like withthe UEimplementation,theu-plane multiplex-inghappensinthePDCP,followinganIP-prefix matchingapproach,i.e.,datatrafficisforwardedtotherightCNbyconsideringthesourceaddressofIPpackets.

C. Coreand MANO

ThemainenablerofourslicingsolutionistheRANslicing.Therefore,toallowaneasierexperimentationwithunmodifiedsoftwaresolutions, wedidnottackleCN VNFs,leveragingonavanillaimplementationsuchastheoneprovidedinthe OpenAirInterfacesuite.Similarconsiderationsholdforthe MANOpart:oneofourobjectivesistoallowtheopenexperimentationof MANOalgorithmsontopofthePOSENSstack.

The MANOofVNFs,afundamentalpartofthefuture5GNetworks,isbeingstandardizedbythe3GPPSA5andwillleverageonthealreadyconsolidatedelementsoftheETSINFV MANOarchitecture[15]. Weincludein POSENS abaselineimplementationofthis MANOfunctionality,whichbuildsontopofaopensource VIM(OpenStack),andpro-videsaper-sliceorchestration(whichisthefunctionalroleplayedbythe VNF Managerandthe NFV OrchestratorintheETSIarchitecture)throughanad-hocJavasoftware.Thisimplementationleveragesdirectlyonthe Novaand NeutronAPIstoprovidealightweightversionoftheVNFM-ViandOr-VireferencepointsdefinedbyETSI.

IV. EVALUATION

WenextvalidateandevaluateoursolutionbydeployingasmalltestbedconsistingofoneUEimplementingtwoslices,andoneeNBconnectedtotwodifferentCN(oneperslice).ThetestbedarchitectureisdepictedinFigure1.TheUErunsoveranEttusUSRPB210boardconnectedtoanHPOMENlaptop,running Ubuntu Linux16.04. TheeNBrunsoveranotherB210board,connectedtoaIntel NUCrunningthesameLinuxdistribution.TheTXandRXportsofoneB210boardareconnectedtotheRXandTXports,respectively,oftheotherboard,usingcoaxialcables withSMCconnectorstopreventanyinterference.ToimplementtheCN, weruntwoinstancesoftheOAICNimplementation,whichcontainsthe MME,HSS,S-GW,andP-GW.TheOAI-CNVNFsarepackagedin Ubuntu16.04 VM,runninginan OpenStackmanagedcloudcomposedofthreecomputenodesandonecontrollernode.

BeforeperformingtheactualvalidationofPOSENS,wefirstconductanextensiveevaluationofthebestRAN(i.e.,srsLTE)parametersthatleadtothe mostreliableconfiguration.Tofindagoodtrade-offbetween RANperformance(interms

ofthroughput)andstability,wesetthechannelbandwidthto10 MHzanda RXgainof60dBforthe UEand60dBfortheeNB. WeusedtheLTEchannel7(centeredaround2600 MHz).

A.Independencebetweenslices

Wefirstvalidatethattheslicescanrunsimultaneouslyandindependently,inthis waysupportinge.g.,experimentationinscenarios with multipleslices,eachonepotentiallyre-configuredinreal-time.Tothisaim,theexperimentstartswithtwoconfiguredslices,eachoneimplementingaperiodicrequest-responseservicebetweentheUEandaserver. Weem-ulatethattheseserversarerelativelyfarawaybyintroducinganextradelayof100msviathetccommand.Then,after20s,theserverofthesecondsliceismovedtotheeNB,simulatinge.g.theuseofa MEC-likesolution. WerepresenttheobtainedperformanceintermsofaverageRoundTripTimes(RTTs)across10repetitionsinFig.4a.

Asthefigureillustrates,atthebeginningoftheexperimentbothslicesexperiencethesameRTTofapprox.120ms,withafewoutliersacrossexperiments.There-allocationoftheserverinthesecondslicehasanobviousimpactonperformance,withtheRTTsimmediatelyreducedtoapprox.20 ms, whiletheperformancewiththefirstsliceremainsunaltered. Withthisexperiment,wethusconfirmthatresearcherscouldprototypescenarioswheredifferentservicesareprovidedwithdifferentslices,andeachservicecouldbeindependently modifiedwithoutalteringtheothers.

B.Throughputperformance

Wenextassessquantitativelytheperformanceofoursolu-tion,toanalyzeiftheoverallefficiencyisdegradedbecauseoftheuseofslicing,andiftheslicesarefairlysharingtheavailableresources.Tothisaim,westartourexperimentwithbothslicesconfigured,butonlyone(“Slice1”)performingaTCPdownloadfromaserver.Then,after20s,anotherdownloadisperformedonthesecondslice(“Slice2”),fromadifferentserver. Weillustratetheper-slicethroughputandthetotalthroughput(“Aggregated”)averagedoverwindowsof1sinFig.4b. Wealsorepresentinthefigurethethroughputperformancewhennoslicingisdone,i.e.,boththeUEandtheeNBusethevanillaversionofsrsLTE(“SingleSlice”).

Thefigureillustratestwo mainresults:first,thereisprac-ticallynodifferenceintotalthroughputbetweenourimple-mentationandtheuseofthevanillaversionofsrsLTE,whichconfirmstheefficiencyofthedevelopedsolution.Second,whenbothslicesareactive,theyfairlysharethe medium,eachoneobtainingapproximately50%ofthetotalthroughput(werepeatedtheexperimentseveraltimesandinallcasestheperformancewasverysimilar).

C.Slicecustomizationandorchestration

Wenextshowhowoursolutionsupportsaper-sliceorches-trationandcustomizationofservices,aswellastheadjustmentoftheresourcesthatasliceconsumes. Wedemonstratethiscapabilityby modifyinginreal-timethechainofVNFsthat

7

0 10 20 30 40

Time [s]

0

50

100

150

Delay [ms]

Slice 1

Slice 2

(a) Independence between slices

0 10 20 30 40

Time [s]

0

5

10

15

Throughput [Mbps]

Single Slice

Slice 1

Slice 2

Aggregate

(b) Total and per-slice throughput performance

0 5 10 15 20 25 30 35 40

Time [s]

0

5

10

15

Throughput [Mbps]

Aggregate

Slice 1

Slice 2

(c) Independent Service Function Chaining

Fig. 4:POSENSevaluation experiments

build a service. In particular, we insert two additional userplane functions into an operating slice: a traffic shaper and afirewall. Our experiment works as follows. We start with twoslices serving downlink traffic to the UE, fairly sharing thechannel as illustrated in Fig. 4c. Then, after 20 s, we add into“Slice 2” a firewall function to block incoming connectionsand a traffic shaper function to limit the bandwidth to 2 Mbps.As the figure illustrates, the effect is immediate and “Slice 1”receives a higher throughput. We also confirmed that connec-tions were blocked immediately. This shows that, even thoughthe our slicing solution cannot allocate RAN resources directly,it can control the overall resource consumption (includingRAN) as long as terminals employ some congestion-awaresending mechanism.

D. Compatibility with commercial equipment

In this section, we confirm that our solution is compat-ible with commercial equipment. To this aim, we performa connectivity test using a Nexus-5 phone, equipped with aSysmocom programmable SIM card.18To support this test,we slightly modified the hardware setup, attaching an antennato the eNB SDR card, and using isolation hardware (Ramseyelectronics shielded enclosures19) to prevent interference.We confirmed that POSENSsupports both modified UEsand commercial UEs, namely, slice-aware and slice-unawareUEs. In this way, we support scenarios where several UEs canbe attached to the same slice (e.g., eMBB), and only a fewUEs, in need of specific services, require the instantiation of adifferent slice (e.g., an URLLC service). This further extendsthe applicability of our solution, opening it to a very widerange of testing scenarios.

V. CONCLUSIONS

We have presented POSENS, an open-source solution forpractical end-to-end network slicing based on slice-awareshared RAN. This tool includes all the software componentsneeded to deploy a multi-slice network setup.POSENSenablesthe slicing of the RAN as well as the core, which arefundamental building blocks for achieving end-to-end networkslicing. We validatedPOSENSin a lab deployment, showing

18http://shop.sysmocom.de/products/sysmousim-sjs119http://www.ramseyelectronics.com/productlist.php?category=1&series=1

how it can obtain per-slice customization without paying aprice in terms of performance. Our ultimate goal is to providea tool that allows researchers and practitioners to experimentwith per-tenant MANO algorithms, using the now widelyavailable SDR and cloud hardware commodities.

ACKNOWLEDGEMENTS

This work has been performed in the framework of theH2020-ICT-2014-2 project 5G NORMA (Grant AgreementNo. 671584) and within the 5G-MoNArch project, part of thePhase II of the 5th Generation Public Private Partnership (5G-PPP) program partially funded by the European Commissionwithin the Horizon 2020 Framework Program.

REFERENCES

[1] D. Bega, M. Gramaglia, C. J. Bernardos Cano, A. Banchs, X. Costa-Perez,“Toward the network of the future: From enabling technologies to 5Gconcepts,”in Transaction on Emerging Telecommunications Technology,2017.

[2] I. Afolabi, T. Taleb, K. Samdanis, A. Ksentini and H. Flinck,“NetworkSlicing & Softwarization: A Survey on Principles, Enabling Technologies& Solutions,” in IEEE Communications Surveys & Tutorials, 2018.

[3] K. Samdanis, X. Costa-Perez and V. Sciancalepore,“From networksharing to multi-tenancy: The 5G network slice broker,”in IEEE Com-munications Magazine, vol. 54, no. 7, pp. 32-39, July 2016.

[4] P. Rostet al.,“Network Slicing to Enable Scalability and Flexibility in5G Mobile Networks,”in IEEE Communications Magazine, vol. 55, no.5, pp. 72-79, May 2017.

[5] J. Mendes, X. Jiao, A. Garcia-Saavedra, F. Huici and I. Moerman,“AccessMulti-Tenancy Through Small Cell Virtualization and Common RF Front-End Sharing,”in Proc. of ACM WiNTECH, October 2017.

[6] C. Chang, N. Nikaein and T. Spyropoulos,“Radio Access NetworkResource Slicing for Flexible Service Execution,”in Proc. of IEEEINFOCOM workshop on RS-FCN, April 2018

[7] X. Foukas,et al. “FlexRAN: A flexible and programmable platform forsoftware-defined radio access networks,”in Proc. of ACM CoNEXT,2016.

[8] X. Foukas, M. K. Marina, K. Kontovasilis,“Orion: RAN Slicing for aFlexible and Cost-Effective Multi-Service Mobile Network Architecture,”,MobiCom ’17, October 2017.

[9] C. Hoymannet al.,“LTE release 14 outlook,”in IEEE CommunicationsMagazine, vol. 54, no. 6, pp. 44-49, June 2016.

[10] 3GPP TR 23.711 V14.0.0, Technical Specification Group Services andSystem Aspects,“Enhancements of Dedicated Core Networks selectionmechanism”, (Release 14), Sept. 2016.

[11] 3GPP TS 38.300 V15.0.0,“NR; Overall description; Stage-2,”, (Release15), Jan. 2018.

[12] N. Nikaein, M. Marina, S. Manickam, A. Dawson, R. Knopp, C. Bonnet,“OpenAirInterface: A Flexible Platform for 5G Research,”, in ComputerCommunication Review, vol 44, pp. 33-38, 2014.

[13] I. Gomez-Miguelez, A. Garcia-Saavedra, P. D. Sutton, P. Serrano,C. Cano, D. J. Leith,“srsLTE: An Open-Source Platform for LTEEvolution and Experimentation,”ACM WiNTECH 2016, New York,USA, Oct. 2016.

8

[14]ETSIPlugtestsReport,“1stETSINFVPlugtests,”Madrid,Spain,Mar.2017.

[15]ETSI,“NetworkFunctionsVirtualisation(NFV); ManagementandOrchestration,”ETSIGSNFV-MAN001,v1.1.1,Dec.2014.

PLACEPHOTOHERE

GinesGarcia-AvilesisaPhDcandidateatIMDEANetworksInstituteandheispursuinghisPhDatUniversityCarlosIIIof Madrid.Gines’researchinterestsareSDNandNFVtechnologiesforfuture5Gnetworks.

PLACEPHOTOHERE

MarcoGramaglia isapost-docresearcheratUni-versityCarlosIIIof Madrid(UC3M).Hereceivedan M.Sc(2009)andaPh.D(2012)inTelematicsEngineeringfromthesameuniversityandaM.Sc.degree(2009)in ComputerScienceengineeringfromPolitecnicodiTorino.BeforejoiningUC3M,heheldpost-doctoralresearchpositionsatIstitutoSuperioreMarioBoella(Torino,Italy),theInstituteofElectronics,Computer,andTelecommunicationsEngineering(IEIIT)oftheNationalResearchCoun-cilofItaly(CNR,Torino,Italy)andattheIMDEA

Networksinstitute(Madrid,Spain).Helikesresearchingonseveralaspectsofmobilenetworks,rangingfromvehicularnetworkingtofuture5GNetworks.HeisalsointerestedinBigDataanalyticsandenduserprivacy.

PLACEPHOTOHERE

PabloSerrano(M’09,SM’16)receivedhisde-greeintelecommunicationengineeringandhisPh.D.from Universidad CarlosIIIde Madrid(UC3M)in2002and2006,respectively.Hehasbeen withtheTelematics Departmentof UC3Msince2002,wherehecurrentlyholdsthepositionofassociateprofessor.Hehasover80scientificpapersinpeer-reviewedinternationaljournalandconfer-ences.HehasservedasguesteditorforComputerNetworks,andontheTPCofanumberofcon-ferencesandworkshopsincludingIEEEINFOCOM

andIEEEWoWMoM.

PLACEPHOTOHERE

Albert Banchs (M’04-SM’12) received hisM.Sc.andPh.D.degreesfromthePolytechnicUniversityof Catalonia(UPC-BarcelonaTech)in1997and2002,respectively.HeiscurrentlyaFullProfessorwiththeUniversityCarlosIIIofMadrid(UC3M),andhasadoubleaffiliationasDeputyDirectoroftheIMDEANetworksinstitute.BeforejoiningUC3M,hewasatICSIBerkeleyin1997,atTelefonicaI+Din1998,andatNECEuropeLtd.from1998to2003.Prof.BanchsisEditorofIEEETransactions on Wireless Communications and

IEEE/ACMTransactionsonNetworking.Hisresearchinterestsincludetheperformanceevaluationandalgorithmdesigninwirelessandwirednetworks.