5G Radio Access Network Architecture – My Assignment Tutor

See discussions, stats, and author profiles for this publication at: https://www.researchgate.net/publication/3405038255G Radio Access Network Architecture for Terrestrial Broadcast ServicesArticle in IEEE Transactions on Broadcasting · April 2020DOI: 10.1109/TBC.2020.2985906CITATIONS10READS9597 authors, including:Some of the authors of this publication are also working on these related projects:5G Broadcast View projectRF Impairments in Digital Communication Systems View projectMikko SäilyNokia46 PUBLICATIONS 379 CITATIONSSEE PROFILECarlos BarjauUniversitat Politècnica de València19 PUBLICATIONS 88 CITATIONSSEE PROFILEJordi J. Gimenez5G-MAG64 PUBLICATIONS 354 CITATIONSSEE PROFILEFasil TesemaNomor Research17 PUBLICATIONS 182 CITATIONSSEE PROFILEAll content following this page was uploaded by De Mi on 08 April 2020.The user has requested enhancement of the downloaded file.IEEE TRANSACTIONS ON BROADCASTING 1Abstract — The 3rd Generation Partnership Project (3GPP) hasdefined based on the Long Term Evolution (LTE) enhancedMulticast Broadcast Multimedia Service (eMBMS) a set of newfeatures to support the distribution of Terrestrial Broadcastservices in Release 14. On the other hand, a new 5th Generation(5G) system architecture and radio access technology, 5G NewRadio (NR), are being standardised from Release 15 onwards,which so far have only focused on unicast connectivity. This maychange in Release 17 given a new Work Item set to specify basicRadio Access Network (RAN) functionalities for the provision ofmulticast/broadcast communications for NR. This work initiallyexcludes some of the functionalities originally supported forTerrestrial Broadcast services under LTE e.g. free to air, receiveonly mode, large-area single frequency networks, etc. This paperproposes an enhanced Next Generation RAN architecture basedon 3GPP Release 15 with a series of architectural and functionalenhancements, to support an efficient, flexible and dynamicselection between unicast and multicast/broadcast transmissionmodes and also the delivery of Terrestrial Broadcast services. Thepaper elaborates on the Cloud-RAN based architecture andproposes new concepts such as the RAN Broadcast/MulticastAreas that allows a more flexible deployment in comparison toeMBMS. High-level assessment methodologies includingcomplexity analysis and inspection are used to evaluate thefeasibility of the proposed architecture design and compare it withthe 3GPP architectural requirements.Index Terms — 5G, architecture, broadcast, multicast, point-topoint, point-to-multipoint, radio access network, single frequencynetwork, signal synchronisation.I. INTRODUCTIONHE 3rd Generation Partnership Project (3GPP) finalised thefirst set of 5th Generation (5G) specifications for Release 15(Rel-15) in December 2018. This defines a new Radio AccessTechnology (RAT) known as New Radio (NR), the NextGeneration Radio Access Network (NG-RAN) and the 5G CoreNetwork which embrace several design principles such as: (i)forward compatibility with future releases; (ii) control-userplane separation (CUPS); (iii) lean and cloud-native systemThis work was supported in part by the European Commission under the5GPPP project 5G-Xcast (H2020-ICT-2016-2 call, grant number 761498). Theviews expressed in this contribution are those of the authors and do notnecessarily represent the project. Part of the material in this paper was presentedat the IEEE International Symposium on Broadband Multimedia Systems andBroadcasting (BMSB) 2019 [20].M. Säily is with the Standardization and Research Lab, Network &Architecture Group, Nokia Bell Labs, Espoo, 02610 Finland (e-mail:[email protected]).C. Barjau Estevan and D. Gomez-Barquero are with the Institute ofTelecommunications and Multimedia Applications (iTEAM), Universitatdesign. Rel-15 and Rel-16 only cover unicast, or Point-to-Point(PTP), transmissions. However, benefits of multicast andbroadcast, or Point-to-Multipoint (PTM), have been alreadyassessed as beneficial for some 5G use cases [1], [2].The support of PTM communications is not new in 3GPP.Mobile broadcast as a service is already included in Long TermEvolution (LTE) as per the enhanced Multicast/BroadcastMultimedia Service (eMBMS). The set of specifications havebeen updated to support new services such as public safety,Internet of Things (IoT) or Vehicle-to-Everything (V2X) [3].Its most recent update comes in Rel-14 [4] and Rel-16 [5], [6]in order to support the 5G requirements for broadcast, and inparticular for the provision of Terrestrial Broadcast services.This has implied severe changes at the air-interface toimplement larger Single Frequency Networks (SFNs) or theintroduction of carriers with dedicated broadcast content. Thearchitecture relies on the existing for eMBMS with theintroduction of the so-called receive-only mode for SubscriberIdentification Module (SIM)-free operation even withoutuplink, or a new xMB interface between the eMBMS systemand service providers. So far, eMBMS has proven limitedsuccess among mobile network operators due to a demandingimplementation both at the network architecture and userequipment.Under the 5G System (5GS) and NG-RAN architectures,basic support for multicast/broadcast is expected to beintroduced in Rel-17. This includes Multicast/Broadcastsupport at 5G Core Network [7] and NR-based Mixed Modetransmissions at RAN [8]. The support of Terrestrial Broadcastservices is not in the scope of these specifications. However, ageneric architectural solution that could allocate requirementsfrom different domains would be beneficial to increasedeployment opportunities.One of the 3GPP system requirements for 5G is a flexiblebroadcast/multicast service for three types of devices, be theyenhanced Mobile Broadband (eMBB), Ultra Reliable and LowPolitecnica de Valencia, 46022 Valencia, Spain (e-mail: {carbare1,dagobar}@iteam.upv.es).J. J. Gimenez is with the Future Networks Department, Institut fürRundfunktTechnik GmbH, 80939 Munich, Germany (e-mail:[email protected]).F. Tesema is with Nomor Research GmbH, Munich, 81541 Germany (email: [email protected])W. Guo is with Samsung R&D Institute UK, Staines-upon-Thames TW184QE, U.K. (e-mail: [email protected]).D. Mi is with the 5G Innovation Centre (5GIC), Institute for CommunicationSystems, University of Surrey, Guildford GU2 7XH, U.K. (e-mail:[email protected]).5G Radio Access Network Architecture forTerrestrial Broadcast ServicesMikko Säily, Carlos Barjau Estevan, Jordi Joan Gimenez, Fasil Tesema, Wei Guo, David Gomez-Barquero andDe MiTIEEE TRANSACTIONS ON BROADCASTING 2Latency Communications (URLLC) and massive MachineType Communications (mMTC) [9]. 5G should be envisionedas a system of systems, where the Core and Transport Networkalongside the RAN must accommodate a plethora of differentservices, with stringent requirements, ranging from severalgigabits/sec (think of Augmented/Virtual reality – AR/VR) tolow kilobits/sec throughput (think of mMTC), latencies rangingfrom 1 millisecond (e.g., industrial IoT) up to several seconds(e.g., best-effort data delivery), mobility support to movingdevices, from static equipment (e.g., roof-top antennas) up to500 kilometre per hour (e.g., V2X) and support for millions ofusers per square kilometre (e.g., massive IoT) [10]-[12].The 5G Infrastructure Public Private Partnership (5G-PPP)project 5G-Xcast has developed a holistic implementation of5G PTM systems [13], covering Core Network [14]-[16] andRAN developments from air interface [17], [18] to architecture[19]-[21] and protocols [21], [22]. This can facilitate thefulfilment of requirements from different applications [23],including traditional Terrestrial Broadcast deployments, whichare the scope of this work. The main contributions of this workare listed as follows:• We develop a dynamic RAN Broadcast/Multicast Areasmechanism that allows the delivery of multicast/broadcastservices wherever needed without the fixed deployment ontop of the existing RAN.• Our proposed RAN architecture design supports multi-celland SFN transmissions using NG-RAN basedsynchronization method fulfilling Quality of Service (QoS)targets defined for traffic flows.• We introduce a new RAN interface design to supportTerrestrial Broadcast and multicast with the minimalimpact on the current 5G system.• We propose a detailed procedure and deployment strategyfor our architecture design, together with high-levelevaluations including complexity analysis and inspection,providing insightful and practical instructions on thefeasibility of our design.The rest of this paper is structured as follows. First, the RANarchitecture evolution to 3GPP Rel-15 is discussed in SectionII. Next, it details in Section III our design on the new RANarchitecture for the Terrestrial Broadcast. Then, deploymentsand procedures of the proposed architecture are presented inSection IV. Section V provides a complexity analysis of ourarchitecture design for both Terrestrial Broadcast and multicastscenarios. Finally, Section VI concludes the key findings andpotential ways forward.II. PRELIMINARIES ON 5G NR RAN ARCHITECTURE IN 3GPPREL-15The key architectural element in RAN design in 3GPP Rel-15 specifications is to extend the distributed base stationarchitecture towards flexible Cloud-RAN based protocolfunctionality where the computing hardware pools are used tohandle the higher layer processing of user plane data traffic andcontrol plane signalling. The protocol functionality split of NRbase station, namely Next generation NodeB (gNB), betweenCentral Units (CUs) and Distributed Units (DUs) in 5Garchitecture enables dynamic adaptation of QoS functionsdepending on the real-time radio conditions, user density anddynamically controlled geographical area.As shown in Fig. 1, the gNB functions are split into CU andDU, where CU covers higher layer protocol functions ofService Data Adaptation Protocol (SDAP) and Packet DataConvergence Protocol (PDCP), and DU entails lower layerprotocol functions of Radio Link Control (RLC), MediumAccess Control (MAC) and Physical Layer (PHY). In a typicalCloud-RAN deployment, the CUs are placed in a computinghardware pool and thus form the cloud. The gNBs are interconnected through an Xn interface.The F1 interface provides control (F1-C) and user (F1-U)plane connectivity between the CU and DU, enablingdeployments with C/U-plane separation. The E1 interfaceprovides connectivity between the user plane CU-UP andcontrol plane CU-CP, enabling deployments with C/U-planeseparation on the CU level. The interface also providesseparation between the radio network and transport networklayers, enabling the exchange of User Equipment (UE) and nonUE associated information. When F1 is separated into F1-Cand F1-U, consequently the Xn inter-connecting the gNBs isseparated into Xn-C on the control plane and Xn-U on the userplane. A gNB-CU is further separated logically into gNB-CUCP and gNB-CU-UP, with E1 Application Protocol (E1AP)providing the signalling service between them.These architecture enhancements provide a significantopportunity to design an innovative RAN architecture formulticast and broadcast services.III. PROPOSED NEW RAN ARCHITECTURE DESIGN FORTERRESTRIAL BROADCASTA. Design PrinciplesOur prior investigations [24] and [14] set some of thelimitations found in eMBMS at the air-interface and systemFig. 1. Rel-15 NG-RAN architecture with a CU-DU split deployment.Data NetworkUPF AMFSMF gNB-CU-UP(SDAP, PDCP)gNB-CU-CP(SDAP, PDCP)gNB-DU(RLC, MAC, PHY)gNB-DU(RLC, MAC, PHY)RU(PHY)RU(PHY)RU(PHY)RU(PHY)F1-U F1-CeCPRI/xRANinterfaceF1-C F1-UgNBE1N3NG-RANN25GCN4XngNB N11N6 IEEE TRANSACTIONS ON BROADCASTING 3architecture, respectively. Even more, in [25] it collects a seriesof limitations for the provision of Terrestrial Broadcastservices.In order to overcome the overall limitations of eMBMS, weprovide novel technical developments using an enhanced NGRAN architecture based on 3GPP Rel-15, which primarilyfocuses on broadcast/multicast capabilities to addressrequirements from multiple verticals and is also able to beconfigured, in a more static fashion, to cover requirementsfocused on Terrestrial Broadcast services. The key architecturalenhancement is leveraged on CU-DU split specifications asspecified in 3GPP NG-RAN [26], and our main target is toprovide a solution with a high commonality with unicast,minimizing the additional implementation footprint.5G broadcast and multicast services should, in general, beavailable in dynamic areas where the number of users duringpopular events (e.g., in stadiums) can be high and the userdistribution within the multicast area very likely changes overthe time. In addition, seamless switching between PTP andPTM transmissions, dynamic adjustment of the RAN multicastarea based on user distribution (from one cell to severalsynchronised cells), and efficient multiplexing with PTPtransmissions in frequency and time domain should beprovided. To this end, a concept of RAN Broadcast/MulticastArea (RBMA) is developed to allow delivery of PTM serviceswherever needed without eMBMS-type of static deployment ontop of the existing RAN [19], [25]. RBMA mechanism takesaccount the user activity, user mobility, number of devices andtheir geographical distribution [19].The RAN is aware of UE’s interest to receive data fromInternet Protocol (IP) multicast group. Dynamic RBMA withsynchronization point in NG-RAN can support multitude ofdeployments from a single cell DU to multiple cells underseveral DUs, still controlled by a single CU. The proposed RANarchitecture may also support a multi-cell transmission usingNG-RAN based synchronization method, where synchronisedDUs participate to multi-cell transmission using a single CU asa point for transmission coordination. This approach enablesover the air transmission of synchronised multicast/broadcasttraffic while fulfilling the QoS targets defined for the trafficflows.B. RAN Broadcast/Multicast Area for Terrestrial BroadcastIn the context of Terrestrial Broadcast, the RBMA isconfigured according to pre-defined coverage requirements andagnostic to the QoS that UEs actually experience (either theyhave uplink capabilities or not) [19], [24], [25].A slightly different approach is followed to address therequirement on large area coverage where the use of SFNmodes are avoided when possible as this has a severe impact onthe air-interface design. To the contrary, Terrestrial Broadcastinfrastructure is usually heterogeneous and relies on local,regional or nationwide transmitter areas in SFN or in MultiFrequency Network (MFN) with some degree of frequencyreuse. The support of concurrent delivery of both unicast andPTM services to the users from the same cell, with efficientmultiplexing with unicast transmissions is also taken intoaccount. The design approach should also support fixed,portable and mobile reception [24].The RBMA for Terrestrial Broadcast Service Area, asillustrated in Fig. 2, is defined as the amount of time/frequencyresources per transmitter area (either for a single transmitter, anMFN or SFN area) reserved for the potential transmission ofTerrestrial Broadcast services. In order to adapt to a variety ofdeployments suitable for the delivery of Terrestrial Broadcastservices, the RAN may be provided via Operation andMaintenance (O&M) with the list of cells that constitute a givenRBMA with the following assumptions:• Each single cell transmitter is considered as a constituentRBMA;• A cluster of cells that constitute an SFN is regarded as aunique RBMA;• A wide coverage area comprising a variety of topologies(e.g. mixture of single and SFN transmitter areas) is formedby means of multiple RBMA;• One transmitter can be operating more than a single carrier,therefore, each cell in the list may be associated a givenfrequency (e.g., DL_EARFCN).Each RBMA is identified by means of a RBMA Index(RBMA ID) which can be selected by the service provider viaxMB interface [27], [28]. A 5G-Xcast Control plane networkFunction (XCF) is proposed to translate the RBMA ID to theactual identifiers of the gNBs [14], [19].The amount of available resources per carrier might bedifferent in each transmitter due to several circumstances suchas the presence of other services, the use of carriers of differentbandwidth or the needs of inter-transmitter scheduling (e.g.time/frequency reuse) to avoid interferences. Therefore, eachRBMA shall be informed of the specific amount oftime/frequency resources that need to be available for potentialservice scheduling via xMB. It is a design assumption in ourRAN architecture that services to be transmitted in SFN will bescheduled over dedicated resources with an adequatenumerology. The group of resources with differentnumerologies can be multiplexed by using different CarrierBandwidth Parts (Frequency Division Multiplexing – FDM;multiplexed within a given OFDM symbol) or subframes /frames (via Time Division Multiplexing – TDM).The delivery of each broadcast service, e.g. TV or radio, canbe configured according to the RBMA ID where the service isFig. 2. Deployments of RBMA for Terrestrial Broadcast Service Area.DU#1DU#2 gNB-CUAMFN2N2 gNBIntra-CU RAN Multicast AreaUPFN3 N3XnMulti-Cell-PtMInter-gNBF1 F1Terrestrial Broadcast Service AreaIEEE TRANSACTIONS ON BROADCASTING 4meant to be delivered. Associated to each broadcast service, theModulation and Coding Scheme (MCS) index that fulfils therobustness (coverage) and data rate requirements of theService-Level Agreement (SLA) is indicated together withscheduling information in terms of required time/frequencyresources for the given data rate (e.g. initial and final PhysicalResource Block – PRB).An admission control procedure will determine the allocationof a new broadcast service according to the amount of availableresources in the carrier for the allocation of TerrestrialBroadcast service (as indicated per RBMA) and the amount ofrequired resources per service.C. Synchronised Content DeliveryTo fulfil the SFN requirements, the 5G-Xcast RANincorporates two main functionalities, one involving the controlplane residing in the gNB-CU-C and the other related to the userplane inside the gNB-CU-MC (as shown in Fig. 3): The controlplane part is the setup of the SFN area inside cellular networks,deciding the physical layer parameters such as modulation,code rate and scheduling to satisfy specific QoS. This decisionis propagated using new signalling towards the relevant gNBDU, which relays this to the relevant Remote Radio Heads(RRH). In addition, the gNB-CU can take into account existingunicast measurement reports to fine tune the physical layerparameters of the SFN transmission.The second functionality is the constant encapsulation of themulticast data to provide Time-to-Air (TTA) information forthe cells involved in the SFN transmission. A modified eMBMSsynchronisation protocol (SYNC) based on [29] is used as theencapsulation protocol, but instead of manually setting theSYNC parameters between the eMBMS Core and the eNBs, theparameters are negotiated in the SFN setup process of the gNBCU [20]. More specifically, the SFN parameter negotiationorigins from the master gNB-CU that wants to activate asynchronised multicast transmission across many DUs andCUs. In this setup, relevant SYNC parameters like SYNCperiod and SYNC sequence are defined which are needed forthe SYNC protocol. The revision of SYNC is called RANSYNC and is one of the main 5G-Xcast contributions [19], [20].This approach enables fast and flexible network deploymentsand simplifies the network operating and maintenance process.In this case, the entity encapsulating the data resides inside theRAN, while in 4G eMBMS, SYNC is applied at the BroadcastMulticast Service Centre (BM-SC). Thus, the realizationcomplexity to set up the network with the proposed RANSYNC can be lower than 4G eMBMS, as in eMBMS theoperator must set up both Core and RAN but here the RAN canoperate independently from the Core and its agnostic to thetransport network used. Also note that we propose the use ofSYNC across gNBs due to the fact that it allows the underlyinggNB modules to reuse existing eMBMS technology (e.g.,Multi-cell/multicast coordination entity – MCE) thus lowers theimplementation costs.The proposed RAN architecture does not include a dedicatednetwork configuration entity, by which functionality wouldinclude the configuration of multi-cell transmission. Instead,the approach uses run-time configuration of the transmissionparameters. In the multi-cell transmission, the transmittinggNB-DUs must be synchronised. The gNB-DUs exchange theinformation about their PHY synchronization/clock and systemreference frame number, if this information is not readilyavailable. The PHY synchronization and reference clockinformation could indicate a synchronization region such asMulticast Broadcast SFN (MBSFN) synchronization areaIdentity (Id) in eMBMS. The gNB-DUs can also determinewhether they are synchronised to a common time reference (e.g.in Global Navigation Satellite System) and provide the PHYsynchronization/clock information and system frame number asan offset to the common time reference. The latter approachdoes not require additional configuration between gNB-DUs.D. New RAN Interfaces for BroadcastITU-T Recommendation I.112 [30] defines an interface as“the common boundary between two associated systems”, and3GPP follows the definition as in 3GPP TR 21.905 [31]. Anetwork interface covers all protocol layers of significance fornetwork elements at both sides of the interface. E.g. if thenetwork elements are Layer 2 entities then the interface shouldbe specified at Layer 2. In most cases, the interface specificationgoes all the way down to Layer 1, to be represented as a fullprotocol stack to enable the interconnection and even plug andplay. RAN interfaces are categorised into external and internalinterfaces. The external interfaces are those between the 5GRAN (named NG-RAN in 3GPP) and 5G Core Network (5GC),and those between the 5G RAN and the UE. The internalinterfaces are those between 5G RAN nodes. 3GPP has beencontinuously working on the definition and standardization ofthose interfaces in the 5G system. The principles for 5G RANinterface design to support Terrestrial Broadcast are:• To reuse as much as possible and to enhance current NGRAN interfaces to support broadcast and multicast to keepthe system interfaces as simple and as few as possible.Fig. 3. 5G RAN internal architecture and interfaces.5G RANgNBsupportingbroadcastandmulticastgNBsupportingbroadcastandmulticastgNB-CUCPgNB-CUUPgNB-DUgNB-CUCPgNB-CUUPXn-CXn-UgNB-DUF1-C E1F1-UIAB node supporting broadcast and multicastUn-C Un-UgNB-CUMCE1F1-MgNB-CUMCXn-UIEEE TRANSACTIONS ON BROADCASTING 5• To define new interfaces to support broadcast and multicastif it is necessary.The network interfaces should allow easy interconnection ofproducts from different vendors, and the possibility of forwardcompatibility for future evolution.3GPP has defined the interface between the 5G RAN and5GC as NG, and further specified into NG-C and NG-U for CPand UP separately [32]-[34]. NG-C maps to the reference pointN2 and NG-U to the reference point N3 [35]. Specifically, asshown in Fig. 4, N2 marks the interface between a gNB and theAccess and Mobility Management Function (AMF), and N3marks the interface between a gNB and the User Plane Function(UPF). In order to support the system architecture alternative 2described in [36], where our proposed broadcast and multicastuser plane network function (XUF) is directly connected to theRAN, a new UP interface M1-NG is introduced, marking theinterface between the broadcast and multicast supporting gNBand the XUF. M1-NG is optional and is needed only for systemarchitecture alternative 2.F1 interface [37] is defined between CU and DU. CUs areinterconnected through Xn interface [38]. In 5G UP and CP areclearly separated, and consequently F1 is separated into F1-Con CP and F1-U on UP, Xn into Xn-C on CP and Xn-U on UP.A gNB-CU is further separated logically into gNB-CU-CP onCP, gNB-CU-UP on UP, and gNB-CU-MC connected with theinterface E1 [39], where gNB-CU-MC is introduced to supportbroadcast and multicast, and a new interface F1-M is introducedto connect it with the gNB-DU. In order to support wirelessrelay by Integrated Access and Backhaul [40], the NG-RAN Uninterfaces on both CP and UP are introduced as Un-C and UnU, to connect the Integrated Access and Backhaul (IAB) nodes.The interfaces within the reference architecture are shown as inFig. 4. We also introduce Uu as the air interface between the 5GRAN and the UE, to support broadcast and multicast, as shownin Fig. 4.According to the logical architecture, N2 (NG-C), Xn-C, F1-C and E1 are interfaces on Control Plane. The networkinterfaces on CP share the same signalling transfer protocolstack, as shown in Fig. 5(a). The Transport Network Layer(TNL) is built on IP [41], [42] transport. Stream ControlTransmission Protocol (SCTP) [43] is used for the transport ofthe application layer signalling protocol.Interfaces N3 (NG-U), M1-NG, Xn-U, F1-U and F1-M areon User Plane. The network interfaces on UP share the sameGTP-U tunnelling protocol stack, as shown in Fig. 5(b). TheTNL is built on IP transport and IP Multicast is used for pointto-multipoint delivery of user packets. GTP-U [44] upon UserDatagram Protocol (UDP) [45] provides non-guaranteeddelivery of UP Protocol Data Unit (PDU) between the gNB andthe UPF. N3 fully supports the functions of the M1 interface inLTE, in the cases of 5G-Xcast architecture Alternatives 1 and 3[14], where broadcast and multicast UP data will be carried overN3 between gNB and UPF. On top of TNL, unicast, multicastand broadcast UP PDUs are multiplexed at Radio NetworkLayer (RNL).IV. 5G RAN ARCHITECTURE DEPLOYMENTS ANDPROCEDURES FOR BROADCAST AND MULTICASTAs PTM services and vertical segments set a variety of verydiverse requirements, the design of RAN protocol architectureand procedures should consider the design principles where themulti-service RAN architecture needs to be flexible and supportthe coexistence of PTP, Single-Cell PTM (SC-PTM), MultiCell PTM (MC-PTM) and broadcast transmissions. Baselinefor the RAN logical architecture design is NG-RAN Rel-15architecture.To allow deployment of existing PTM services and newservices, the overall RAN architecture and procedure need tosupport both (i) dynamic adjustment of the Multicast/Broadcastarea based on the user distribution or service requirements and(ii) allow static and dynamic resource allocation betweenunicast and Multicast/Broadcast. Further, the RAN architecturedeployment should support full allocation of downlink carrierresources for Multicast/Broadcast in large geographical areasup to the size of an entire country in SFN mode.A. ProceduresThe design target of RBMA is to enable dynamic areas basedon user geographical distribution, reusing the flexibility of theunicast architecture and basic principles of SC-PTM extendedover to MC-PTM. Users having active unicast traffic is inRRC_CONNECTED state [32] and since the UE location isknown by a single cell, it is proposed that the RAN (e.g. anchorgNB) should decide the multicast bearer configuration ordeliver the multicast traffic over unicast data radio bearers. As(a) Control Plane protocol stack (b) User Plane protocol stackFig. 5. Interface protocol stack. SCTPIPData link layerPhysical layer Signalingapplication GTP-UUDPIPData link layerPhysical layer User Plane PDUsFig. 4. Deployments of RBMA for Terrestrial Broadcast Service Area. gNBsupportingbroadcastandmulticastUEsupportingbroadcastandmulticastAMFNR Uu5GC5G RANN2UPFXUFN3M1-NG IEEE TRANSACTIONS ON BROADCASTING 6shown in Fig. 6, if the number of active users is low, themulticast traffic is delivered to UEs using unicast. When theunicast traffic of a UE is detected to have low activity, the UEis moved to RRC_INACTIVE [46] and the UE continues toreceive multicast traffic within the configured RBMA. TheRBMA, where the UE can receive multicast traffic, is definedand controlled by RAN and can be part of the Radio ResourceControl (RRC) configuration, or part of the broadcastedmulticast configuration (e.g. System Information). The anchorgNB (usually the last serving gNB) defines the RBMAconfiguration, and in case of multiple gNBs, distributes it overXn interface to the gNBs which belong to the RBMA.Depending on the number of low activity UEs receivingmulticast in a cell, the gNB can decide to keep one (or more)UEs in RRC_CONNECTED state, assuming that multicastbearer mapped to unicast bearer or direct usage of unicast beareris more spectral efficient than multicast bearer inRRC_INACTIVE state with limited feedback. The benefit ofRRC_INACTIVE over RRC_IDLE is the maintainedconnection to AMF / UPF where the connection managementstate remains in Connection Management (CM)-Connected andthe UE Context is stored in both UE and RAN. This will allowlow latency state transition between RRC_CONNECTED andRRC_INACTIVE, see Fig. 6.An example of the cell selection procedure with two RBMAIds is presented in Fig. 7, including three UEs receiving IPmulticast traffic. This can be further described with threedifferent scenarios:1. UE1 may be in RRC_CONNECTED state receiving bothunicast and PTM multicast traffic from the same DU.Location of UE1 is known by a single cell in RAN, thusenabling the transmission of unicast and multicast trafficusing only unicast bearers.2. The UE2 has completed its unicast traffic, and due to lowactivity, the RAN (e.g. anchor gNB) decides to suspend theRRC configuration and configures the UE2 intoRRC_INACTIVE state. The multicast traffic will movefrom unicast Radio Bearer (RB) to multicast RB thusallowing the UE2 to continue the reception of PTMmulticast traffic. The configuration includes theconfiguration for RRC_INACTIVE state as well as thePTM Group-Radio Network Temporary Identifier (RNTI)and RBMA Id consisting of at least one cell. The anchorgNB receives the PTM multicast traffic over the N3 datatunnel from UPF. When the UE2 identifies a new cell withbetter coverage/quality and optionally the current sourcecell is having degrading coverage/quality, the UE needs toperform a cell reselection to a new cell. As illustrated inFig. 7, two cases with UE mobility can be identified forUEs in RRC_INACTIVE state.(a) The UE2 moves inside the RBMA Id1 and performs cellreselection from one DU to another DU. The UE2 does notneed notify the network about cell reselection since it isable to receive the same multicast traffic from alltransmission points under the same RBMA. The RBMAcan consist of one or more gNBs and the UPF traffic isdistributed over F1, Xn and N3 interfaces to transmissionpoints to cover the RBMA area. Further, if the RBMAconsists of multiple gNB contributing to MC-PTMtransmission, then the F1, Xn (necessary synchronizationcan be controlled by gNB receiving the IP multicast trafficover N3) and N3 interfaces can be used to route the sameIP multicast traffic to joining gNBs.Fig. 7. UE mobility and cell selection/reselection procedure for RAN Broadcast/Multicast Area. UE2AnchorDUF1N2N3N6AMFSMFN1N11UE1 gNB CUDNN3UPFAnygNB CUXn UPF DUDUDUUE2UE3UE2 Cellreselectioninside RBMAN9UE2Tracking AreaRBMA Id2UE2 Cellreselectionoutside RBMARBMA Id1Fig. 6. Unicast activity and RRC States.UE RRC StatesHighactivityLowactivity RRCConnectedRRCInactiveRRC Idle CM-ConnectedIEEE TRANSACTIONS ON BROADCASTING 7(b) If the new target cell is outside of the RBMA Id1, UEneeds to notify the network its new location with RBMAupdate. Network will configure the UE with new RBMAId and if the new RBMA consists of more than one gNB,network performs the RAN based Multicast Area Setup toallow traffic distribution over Xn to gNBs belonging toRBMA.3. The UE3 is having low unicast activity, its connectiontowards AMF is released and therefore the UE3 isconfigured with RRC_IDLE state. In this state the CoreNetwork knows the UE’s location only within the trackingarea in AMF. Alternatively, the UE3 could be also areceive only device or in Receive Only Mode (ROM) modewithout uplink capability, thus the network does not knowits existence or location respectively. In these cases, theRBMA may be configured with multiple cells participatingin SFN broadcast mode. The RBMA becomes the same asthe tracking area or SFN service area and two or moreselected cells are participating in SFN, for exampleaccording to given pre-configuration. When the area ofRBMA Id2 is configured with SFN transmission, all theUEs in that area can benefit from the SFN transmissionregardless of their RRC state.In the case for Terrestrial Broadcast, users are unknown tothe RAN (due to the lack of uplink and, therefore, registrationinto the network) and the RAN can decide beforehand andaccording to service and coverage requirements the multicastbearer configuration for delivery. From the three scenariosshown above, Terrestrial Broadcast would be an extension ofUE3 being it a receive only device with no uplink capability. Inthis case the RBMA becomes the same as the tracking area orSFN service area. Single-cell transmission of an SFN withmultiple cells participating can be configured.B. DeploymentsOur proposed RAN deployment leverages the majorassumptions of 5G NR overall architecture described in [26]which shows RAN architecture for gNBs with and withoutfunctional splits.For the RAN deployment without functional split, all thelogical gNB functions as well as RAN interface protocolterminations are hosted in a gNB physical node. Fig. 8(a)depicts this RAN deployment scenario. Herein, the logicalnodes include CP and UP. The UP hosts the newly introducedcontrol functions including functions performed by gNB-CUMC. On the other hand, the UP logical node hosts 5G-XcastRAN function for delivery of user plane data [19]. The majorinterface protocol terminations for the aforementionedinterfaces are NG-C (to which N2 reference point is mapped),NG-U (to which N3 reference point is mapped), M1-NG, Xn-Cand Xn-U.Fig. 8(b) demonstrates our proposed RAN deploymentscenario with functional split. Herein, the figure shows logicalnodes (CU-CP, CU-UP and DU), internal to a logical gNB. Themajor interface protocol terminations for 5G-Xcast interfaces,NG-C, NG-U, M1-NG, Xn-C and Xn-U, are hosted in thecentral entity. The DU is hosted in a distributed entity. Thecentral entity and distributed entity are separate physical nodes.In this work, we further propose a Cloud-RAN baseddeployment. At high level, the DU(s) closer to the deployedcells receive information about a set of UEs to which themulticast data should be transmitted and based on thisinformation the distributed unit configures the needed unicastchannels and multicast channels. The CU being a centralisedunit and DU a local unit, the DU needs to make the decision ofthe transmission mode. When the DU receives multicast datafrom a CU, it will select either unicast or multicast channel totransmit the multicast data to the set of UEs as per theprocedures as described in the last subsection.The proposed Layer 2 radio protocol architecture for CloudRAN deployments is shown in Fig. 9. The multicast data is(a)(b)Fig. 8. The proposed RAN deployment scenario without (a) or with (b)functional split. gNB NG-C NG-UXn-UCP UPXn-CM1-NGCU-MCLogical 5G-Xcast gNBN2M1-NG N3Xn-UXn-CDistributed Entity Central Entity NG-C NG-UXn-UCU-CP CU-UPXn-CM1-NGCU-MCF1-CF1-ULogical 5G-Xcast gNBM1-NG N2 N3Xn-UDUXn-CFig. 9. The proposed L2 architecture and bearer selection in Cloud-RAN. QoS flow mappingPDCPPDCPPDCPX-cast radio beareDRBDRBRLCRLCRLCRLCMux UEDL-SCHDL-SCSwitching functionQoS flowQoS flowQoS flowRLC channelsDTCHDTCHDTCHXTCHScheduling / Priority handling HARQr (XRB)HX-cast tunnelSDAPPDCPRLCMACIEEE TRANSACTIONS ON BROADCASTING 8delivered to NG-RAN over a data tunnel, which in this case isreferred as X-cast tunnel in Fig. 9 to emphasize the dynamicselection process of RLC entities and transport channels for thetransmission. The multicast traffic can comprise of multipleQoS flows. In this case the SDAP can map the QoS flows to aset of newly introduced broadcast/multicast data Radio Bearers(XRB) to enable differentiation at lower layers for differentQoS requirements.The PDCP, which is not used in eMBMS architecture, mayprovide sequence numbering and duplication detection. In casethe UE is receiving the same data over unicast and multicastDedicated Radio Bearers DRBs, the duplication detectionshould be supported. The duplication can be used in theproposed architecture also for performance enhancement whenthe UE receives the same PDCP PDU over Dedicated TrafficChannel (DTCH) and Multicast logical Channel (XTCH) as ameans for improving packet reliability. In this case theciphering functionality used for unicast is not required formulticast. Another PDCP function relevant to the transport ofmulticast data is the header compression and decompression.Switching function in the DU is the new functionalityproposed to the architecture, where the DU selects thetransmission method. Switching function locates below PDCPbut above RLC layer, thus not placed in the same Cloud-RANcomputing hardware pool as the CU. Thus, using the F1fronthaul interface, it is natural to place the Switching functionin the DU. For a set of UE’s receiving multicast data (i.e. theUE’s which have expressed their interest in receiving multicastand the PDU session has been modified to allocate the RANresources for UEs joining in the IP multicast group), a pair ofRLC entities and logical channels (i.e., DTCH and XTCHchannels) is set up to transmit the multicast data over the air.The multicast logical channels are shared between some or allmulticast UEs.The switching between unicast and multicast can be based onthe availability of UE measurements and the reported quantitiesin the measurements, such as Synchronization Signal –Reference Signal Received Power (SS-RSRP), Channel StateInformation (CSI)-RSRP, Synchronization Signal – ReferenceSignal Received Quality (SS-RSRQ), CSI-RSRQ, according toprocedures related to RBMA. In general, if measurements arenot available, XRB switching is routing traffic though multicasttransport channels and when measurement reports indicate poorradio condition for some UEs in comparison to others, theSwitching function will select the unicast transport channel forthose UEs and the multicast transport channel for other UEs.When setting up an XRB, RRC may configure thresholds in theXRB switching function to select between unicast and multicastlogical channels, also considering the minimum number of UEsrequired for switching to multicast transport and the resultingestimated resource and spectrum efficiency gain.The gNB-DU switching function configuration includesRLC channels and logical channels for XRB bearer and DLtunnel information. The gNB-DU configures at least unicasttransport by creating an RLC entity mapped to a single RLCchannel towards PDCP and mapped to a corresponding logicalchannel in MAC according to DRB setup procedures.A new RLC entity and corresponding mapping to a XTCH iscreated if multicast transport is not configured already. Theconfiguration includes at least one of the following: logicalchannel identities, RLC configuration (e.g. mode, sequencenumber field length, timer values), MAC configuration andPHY configuration.Some examples are provided regarding the cell arrangementsfrom which a broadcast service may be transmitted, in this caseassuming TV/radio services. In Fig. 10, three differentdeployments are shown consisting of a nation-wide SFN, aregional SFN and a deployment covering the same area bymeans of single cell transmitters. A central hexagon ishighlighted, which belongs to different RBMA IDs accordingto the network planning requirements of each TV/radio service.A frame transmitted from the central hexagon is shown, where,for simplicity, TDM is used to multiplex frames containing theservices per different RBMA. The three scenarios are:• A set of transmitters configured within the same SFN area.In this case a complete carrier (or frame within a carrier) isavailable to schedule Terrestrial Broadcast services.• A set of transmitters that constitute different SFN areasrequiring synchronization and orthogonal schedulingbetween SFN areas.• A set of single-cell transmitters requiring orthogonalscheduling of resources to avoid mutual interference (inthis case on a reuse 3 basis).C. RAN Network SlicingOne of the key features for the deployment of the proposedRAN architecture in 5G is network slicing. By harnessingnetwork function virtualisation (NFV) and networksoftwarisation, RBMA can be sliced to facilitate the desired 5Gnetwork management solution. As pointed out in [15], it is notappropriate to define a pure multicast slice, as multicast isfrequently mixed and tightly integrated with unicast to transportbroadcast and multicast communication services. Furthermore,there is a requirement [9] to allow the deployment of a multicastFig. 10. Three deployments consisting of a nation-wide SFN, a regional SFNand a single cell transmitter and their association to RBMA ID for TerrestrialBroadcast Services.RBMA ID = 1Nation-wide SFNOFDM ARegional SFNOFDM BMFN/LocalOFDM CRBMA ID = 1 RBMA ID = 2 RBMA ID = 10Central Tx belongs toRBMA ID = 1 for theNationwide SFNCentral Tx belongs toRBMA ID = 2 for theRegional SFNCentral Tx belongs toRBMA ID = 10 for theMFN/Local service areaIEEE TRANSACTIONS ON BROADCASTING 9solution that can seamlessly adapt between unicast andmulticast transmission to maximise the efficiency of using radioand network resources. However, there is a need to definenetwork slices for a category of broadcast and multicastservices on the demand of Communications Service Provider(CSP) and according to the SLA signed with the NetworkOperator (NOP), or specifically Mobile Network Operator(MNO) for 5G networks.The RBMA slicing provides a framework to implement thenetwork slicing in 5G-Xcast RAN and sets the ground for futurepractical deployment as a primary option to provision andmanage broadcast and multicast services.5G RBMA network slicing is the exact solution to meet therequirement specified in 3GPP on 5G MBMS, to supportMulticast/Broadcast network sharing between multipleparticipating MNOs, including the case of a dedicated MBMSnetwork [9].V. 5G RAN ARCHITECTURE EVALUATION FOR TERRESTRIALBROADCAST AND MULTICASTA. Comparison tableTable I describes the main features of each state-of-the-artcellular broadcast technologies and on-going Rel-17 work,comparing it to the proposed solution.B. Imprint analysisModified eMBMS SYNC controlled by RAN is proposed toreside between gNB-CU-MC and DU allowing controllablefronthaul latencies. The number of new interfaces impactsdirectly the service integration and deployment complexity ofthe new broadcast/multicast system. Possibility to reuse andenhance current NG-RAN interfaces to support broadcast andmulticast will keep the complexity low. 3GPP has definedinterfaces between the NG-RAN and 5GC and specifiedreference point N2 for Control Plane and reference point N3 forUser Plane. The NG-RAN internal interfaces are those between5G RAN logical network nodes. Enabling the gNB-CU-C tocontrol the 5G broadcast/multicast and modified gNB-CU-MCas part of the gNB-DU internal interfaces minimises the needfor new interfaces [20].C. Radio Resource EfficiencyBroadcast/multicast through the 5G Physical DownlinkShared Channel (PDSCH) with basic limited uplink feedbackchannel allows dynamic deployment of SFN network. SFNtransmission involving multiple cells for group transmissionimproves the spectral efficiency especially at the cell edgeswhen the control of the SFN resides at the gNB-CU-C.D. ScalabilityBroadcast/multicast with SFN transmission requires oneresource allocation for the UE group. In case the SFN serviceareas are semi-static and no uplink channel feedback isexpected from the UEs, the amount of radio resources would beindependent of the number of UEs. When the SFN areas areoperated in a dynamic manner taking the UE interest inreceiving the broadcast/multicast, then resource allocation doneper UE group and the dynamic radio resource utilization in SFNis not proportional to the number of users even if the unlimitednumber of users may not be supported. SFN transmission inNG-RAN is natively supported feature and the SFNbroadcast/multicast architecture is integrated into the baselineunicast architecture maximizing the scalability and enablingdynamic switching between different transmission modes fortransparent 5G broadcast networks [20].E. Dimensionality analysisThe system proposed is formed by one gNB for the entiredeployment. Nation-wide SFNs for broadcast are characterisedfor having a large number of cells, both deployed in High PowerHigh Tower (HPHT) and some used as gap-fillers. Thearchitecture follows a tree-like topology, where one gNB-CUwith a gNB-CU-MC serves a large amount of gNB-DU over F1interface, and the gNB-DUs serve a large number of RRH/cells.In [14], it is specified that the maximum number of uniquelyidentified gNB-DUs under one gNB-CU allowed by thesignalling is 236-1, and the maximum number of cells that canbe served by one gNB-DU is 512 or 29. Overall, the maximumnumber of cells served is (236 – 1)*512. To the best of authors’knowledge, this value greatly exceeds any existing DigitalTerrestrial Television (DTT) deployment [20].On another vein, the biggest limiting factor for nation-wideSFN deployment in 5G is the Inter-Site Distance (ISD) allowedby New Radio numerologies. As shown in [17], maximum ISDin Rel-15 is 1.41 Km. New physical layer schemes such as thenegative numerologies proposed in 5G-Xcast [17] could extendthis up to 120 Km, perfectly fit for nation-wide SFN.F. Latency analysisLatency performance parameters in cellular networks areusually divided into Control Plane latency and User PlaneTABLE ICOMPARISON BETWEEN CELLULAR BROADCAST TECHNOLOGIES Air InterfaceSingle FrequencyNetwork ModeDynamic ServiceAreasReceive OnlyModeSynchronizationusedMBSFNLTEYesNoNoSYNCSC-PTMLTENoNoNoSYNCfeMBMSLTEYesNoYesSYNCRel-17 MixedModeNRNoYesNoTo be defined5G-Xcast RANNRYesYesYesRAN-SYNC IEEE TRANSACTIONS ON BROADCASTING 10latency. In detail, Control Plane latency is the time needed froman idle terminal to switch into a state ready to transmit and/orreceive, with enabled context information in RAN and CoreNetwork, while the User Plane latency is the time spent by apacket from the source until it is decoded by the device. Giventhat one of the design decisions of this architecture was tominimise the imprint over existing 5G solution, the resultsobtained by 3GPP can be applied to this approach. For standarddevices, this Control Plane and User Plane latency can be thesame as Rel-15 latency i.e. around 15 ms [11] and 2 ms [17] forControl and User Plane respectively. Possible upgrades to thesevalues can be the use of the newly introduced 5GRRC_INACTIVE state which can lower the overall “wake-up”latency from power-efficient state to active mode, and the useof Multi-access Edge Computing (MEC) to bring the sourcecontent closer to the user [20].In general, the latency of the proposed architecture designcompared to 4G eMBMS can be on the same grade ofmagnitude since the purpose of SYNC is to compensate for thenetwork deployment delays from geographically awaytransmitters (e.g. in a nation-wide SFN). In case that the 5GRAN architecture is used to optimise the network resources, itis expected to have a small area SFN with the same latency as5G unicast.VI. CONCLUSIONHaving the 5G NR Rel-15 RAN unicast architecture as abasis for our RAN architecture design, we have proposedarchitectural and functional enhancements allowing a flexibledeployment of 5G-Xcast RAN where the new Radio AccessTechnology (RAT) supports dynamic adjustment of theMulticast/Broadcast geographical area based on e.g. the userdistribution or service requirements. The new 5G-Xcast RANarchitecture can cover large geographical areas up to the size ofan entire country in SFN mode with content synchronization forSFN transmission. Developed RAN Broadcast/Multicast Areaand RAN based synchronization solutions can support local,regional and national multicast/broadcast areas. The support fordynamic geographical areas is enabled with the support of notonly Terrestrial Broadcast service but also a concurrent deliveryof both unicast and multicast/broadcast services to the users, aswell as support for efficient multiplexing with unicasttransmissions via seamless data bearer selection.The proposed 5G PTM RAN architecture has been shown tofulfil the 5G-Xcast use case specific requirements [23] andcover the generic architectural requirements listed in 3GPP TS38.913 [9], as compared in Table II.Leveraging the proposed solutions in this work can lead tofurther investigations on generalised RAN framework designs,including more simulations and testing to evaluate theappropriate architecture design for PTM in a more practicalscenario. For example, this work suggests that the latency of theproposed solutions can be comparable to that of the 5G unicast,thus one can carry out quantitative evaluations on the potentiallatency reduction achieved by applying RAN-SYNC orRRC_INACTIVE-assisted wake-up procedure.REFERENCES[1] 3GPP TS 22.261 v16.7.0, “Service requirements for the 5G system; Stage1 (Release 16)”, Mar. 2019.TABLE II5G-XCAST RAN ARCHITECTURE AGAINST 5G BROADCAST/MULTICASTREQUIREMENTS Broadcast/MulticastRequirement in 38.913 [9](RAN architecture related)5G-Xcast RAN ArchitecturesolutionThe new RAT shall supportexisting Multicast/Broadcastservices (e.g. download,streaming, groupcommunication, TV, etc.) andnew services (e.g. V2X, etc).1. The overall 5G-Xcast RANarchitecture supportingmulticast/broadcast and verticalsegments.2. PDU Session Modification formulticast resource allocation andmulticast bearer selection.The new RAT shall supportdynamic adjustment of theMulticast/Broadcast area basedon e.g. the user distribution orservice requirements.1. RBMA to allow dynamicmulticast area along with userdistribution, requested service, UEunicast activity, mobility andconnectivity.2. RBMA procedures to create andmodify RBMA.The new RAT shall supportstatic and dynamic resourceallocation betweenMulticast/Broadcast andunicast; the new RAT shall inparticular allow support of upto 100% of downlink resourcesfor Multicast/Broadcast (100%meaning a dedicated MBMScarrier).1. RAN based contentsynchronization supportingTransparent Multicast andTerrestrial Broadcast.2. Support for SFN with RBMAand RAN based synchronizationusing gNB-CU-MC enablingsynchronised transmission withinthe gNB-DUs.3. Multicast deployment usingCloud-RAN for seamlessunicast/multicast bearer selectionThe new RAT shall supportMulticast/Broadcast networksharing between multipleparticipating MNOs, includingthe case of a dedicated MBMSnetwork.1. Support for SFN with RBMAand RAN based synchronization.2. RAN slicing using RBMAThe new RAT shall make itpossible to cover largegeographical areas up to thesize of an entire country in SFNmode with networksynchronization and shall allowcell radii of up to 100 km ifrequired to facilitate thatobjective. It shall also supportlocal, regional and nationalbroadcast areas.1. Synchronised multicast contenttransmission using gNB-CU-MCwhich enforces the synchronisedover the air transmission ofmulticast/broadcast traffic withinthe gNB-DUs.2. Support for SFN with RANbased synchronizationThe new RAT shall supportMulticast/Broadcast servicesfor fixed, portable and mobileUEs. Mobility up to 250 km/hshall be supported.1. The overall 5G-Xcast RANarchitecture.2. Support for ROM and PDUSession Modification for multicastresource allocation and multicastbearer selection.The new RAT shall leverageusage of RAN equipment (hardand software) including e.g.multi-antenna capabilities (e.g.MIMO) to improveMulticast/Broadcast capacityand reliability.The overall 5G-Xcast RANarchitecture, e.g. based on thedesign principle of maximizing thearchitectural commonality withunicast.The new RAT shall supportMulticast/Broadcast servicesfor mMTC devices.The overall 5G-Xcast RANarchitecture is designed to supportall kind of devices, e.g. devicestargeting for IP multicast serviceswith TX/RX capability and ROMmode devices. IEEE TRANSACTIONS ON BROADCASTING 11[2] D. Gomez-Barquero et al., “5G for Broadband Multimedia Systems andBroadcasting,” IEEE Transactions on Broadcasting, vol. 65, no. 2, pp.351-355, Jun. 2019.[3] M. Fallgren et al., “Multicast and Broadcast Enablers for High-PerformingCellular V2X Systems,” IEEE Transactions on Broadcasting, vol. 65, no.2, pp. 454 – 463, Jun. 2019.[4] T. Stockhammer, “enTV Rel-14: A Transport System for Next GenerationBroadcaster Services,” in IEEE International Symposium on BroadbandMultimedia Systems and Broadcasting (BMSB), Valencia, Spain, 2018.[5] 3GPP TR 36.776 v16.0.0, “Evolved Universal Terrestrial Radio Access (EUTRA); Study on LTE-based 5G terrestrial broadcast (Release 16),” Mar.2019.[6] R. Kaliski, C. Chou and H. Wei, “Further Enhanced MultimediaBroadcast/Multicast Service in LTE-Advanced Pro,” IEEECommunications Standards Magazine, vol. 3, no. 3, pp. 44-51, Sep. 2019.[7] 3GPP TR 23.757 v0.3.0, “Study on architectural enhancements for 5Gmulticast-broadcast services (Release 17)”, Jan. 2020.[8] RP-193248, “New Work Item on NR support of Multicast and BroadcastServices,” Huawei, 3GPP TSG RAN #86, Sitges, Spain, Dec. 2019.[9] 3GPP TR 38.913 v15.0.0, “Study on scenarios and requirements for nextgeneration access technologies,” Jul. 2018.[10]Next Generation Mobile Networks (NGMN) Alliance, “NGMN 5G WhitePaper,” Version 1.0, Feb. 2015.[11]ITU-R, M.2410-0, “Minimum requirements related to technicalperformance for IMT-2020 radio interface(s),” Report, Nov. 2017.[12]ITU-R, IMT-2020/1-E, “IMT-2020 Background,” Report, Jun. 2016.[13]http://5g-xcast.eu/, 5G-Xcast project website.[14]T. Tran et al. Eds., “Mobile Core Network,” Deliverable D4.1, 5G-PPP5G-Xcast Project, Valencia, Spain, Jun. 2018.[15]J. Hart et al. Eds., “Converged Core Network,” Deliverable D4.2, 5G-PPP5G-Xcast Project, Valencia, Spain, Oct. 2018.[16]T. Tran et al., “Enabling Multicast and Broadcast in the 5G Core forConverged Fixed and Mobile Networks,” IEEE Transactions onbroadcasting, vol. 66, no. 2, Part II, Jun. 2020.[17]E. Garro et al., Eds., “Air Interface,” Deliverable D3.2, 5G-PPP 5G-XcastProject, Valencia, Spain, Nov. 2018.[18]E. Garro et al., “5G Mixed Mode: NR Multicast-Broadcast Services,” IEEETransactions on broadcasting, vol. 66, no. 2, Part II, Jun. 2020.[19]M. Säily et al., Eds., “RAN Logical Architecture and Interfaces for 5GXcast,” Deliverable D3.3, 5G-PPP 5G-Xcast Project, Valencia, Spain, Feb.2019.[20]C. Barjau, M. Säily and D. G. Barquero, “Enabling SFN Transmissions in5G Cloud-RAN Deployments,” in IEEE International Symposium onBroadband Multimedia Systems and Broadcasting (BMSB), Jeju, Korea(South), 2019.[21]M. Säily, C. Barjau, D. Navratil, A. Prasad, D. Gomez-Barquero and F. B.Tesema, “5G Radio Access Networks: Enabling Efficient Point-toMultipoint Transmissions,” IEEE Vehicular Technology Magazine, vol.14, no. 4, pp. 29-37, Dec. 2019.[22]F. Tesema et al., Eds., “RAT Protocols and Radio Resource Managementin 5G-Xcast,” Deliverable D3.4, 5G-PPP 5G-Xcast Project, Valencia,Spain, May 2019.[23]D. Ratkaj et al. Eds., “Definition of Use Cases, Requirements and KPIs,”Deliverable D2.1, 5G-PPP 5G-Xcast Project, Valencia, Spain, Oct. 2017.[24]J. J. Gimenez et al., “5G New Radio for Terrestrial Broadcast: A ForwardLooking Approach for NR-MBMS,” IEEE Transactions on Broadcasting,vol. 65, no. 2, pp. 356-368, Jun. 2019.[25]C. Menzel et al., Eds., “Analysis and Development of Terrestrial Broadcastin 5G-Xcast,” Deliverable D2.4, 5G-PPP 5G-Xcast Project, Valencia,Spain, Jul. 2019.[26]3GPP TS 38.401 v15.5.0, “NG-RAN; Architecture description (Release15)”, Mar. 2019.[27]3GPP TS 26.346 v16.3.0, “Multimedia Broadcast/Multicast Service(MBMS); Protocols and codecs (Release 16)”, Dec. 2019.[28]3GPP TS 29.116 v16.3.0, “Representational state transfer over xMBreference point between content provider and BM-SC (Release 16)”, Dec.2019.[29]3GPP TS 25.446 v15.0.0, “MBMS Synchronization protocol, (SYNC),”Jul. 2018.[30]ITU-T Recommendation I.112, “Vocabulary of Terms for ISDNs”, Mar.1993.[31]3GPP TR 21.905 v15.1.0, “Vocabulary for 3GPP Specifications (Release15)”, Dec. 2018.[32]3GPP TS 38.300 v15.5.0, “NR; NR and NG-RAN Overall Description;Stage 2 (Release 15)”, Mar. 2019.[33]3GPP TS 38.410 v15.2.0, “NG-RAN; NG general aspect and principles(Release 15)”, Dec. 2018.[34]3GPP TS 38.412 v15.1.0, “NG-RAN; NG signalling transport (Release15)”, Sep. 2018.[35]3GPP TS 23.501 v16.0.2, “System Architecture for the 5G System; Stage2 (Release 16)”, Apr. 2019.[36]Next Generation Mobile Networks (NGMN) Alliance, “Description ofNetwork Slicing Concept”, Version 1.0, Jan. 2016.[37]3GPP TS 38.470 v15.5.0, “NG-RAN; F1 general aspects and principles(Release 15)”, Mar. 2019.[38]3GPP TS 38.420 v15.2.0, “NG-RAN; Xn general aspects and principles(Release 15)”, Dec. 2018.[39]3GPP TS 38.460 v15.3.0, “NG-RAN; E1 general aspects and principles(Release 15)”, Mar. 2019.[40]3GPP TR 38.874 v16.0.0, “NR; Study on Integrated Access and Backhaul;(Release 16)”, Dec. 2018.[41]IETF STD 86 / IETF RFC 8200, “Internet Protocol, Version 6 (IPv6)Specification”, Jul. 2017.[42]IETF STD 5 / IETF RFC 791, “Internet Protocol”, Sep. 1981.[43]IETF RFC 4960, “Stream Control Transmission Protocol”, Sep. 2007.[44]3GPP TS 29.281 v15.5.0, “General Packet Radio System (GPRS)Tunnelling Protocol User Plane (GTPv1-U) (Release 15)”, Dec. 2018.[45]IETF STD 6 / IETF RFC 768, “User Datagram Protocol”, Aug.1980.[46]I.L. Da Silva, G. Mildh, M. Säily, S. Hailu, “A novel state model for 5Gradio access networks,” in IEEE International Conference onCommunications (ICC) Workshops, pp. 632-637, May 2016.Mikko Säily is a 5G research scientist andresearch project manager leading 5Gconnectivity, mobility, and positioningresearch at Nokia Bell Labs, Espoo, Finland.His current research interests include 5Gevolution for high accuracy and low-latencypositioning and mobility and connectivity for5G New Radio in millimeter-wavecommunications. He is the coauthor andcoinventor of more than 150 international publications, patents, patentapplications, and technical reports.Carlos Barjau is a R&D engineer at MobileCommunications Group (MCG) of theInstitute of Telecommunications andMultimedia Applications (iTEAM) atUniversitat Politecnica de Valencia (UPV). Hereceived a M.Sc. degree inTelecommunications engineering alongside asecond M.Sc. degree in Communications andDevelopment of Mobile Services from UPV,Spain, both in 2013. He is working at themoment on his Ph.D. degree on enabling broadcast services in 5Gnetworks and was involved in H2020 project 5G-Xcast. His currentresearch interests include synchronization of radio networks, servicebased architectures for broadcast, convergence of terrestrial broadcastand cellular networks and Cloud-RAN deployments.Jordi J. Gimenez obtained a Ph.D. inTelecommunications from the UniversitatPolitècnica de València (UPV) in Spain,while he was a Research Engineer at theiTEAM Research Institute. In 2018 he joinedthe Institut für Rundfunktechnik (IRT) asProject Manager and Research Engineer for5G-related projects in the domain of mediadistribution and contribution, being the H2020 5G-Xcast and 5GSolutions the most recent. He has been actively contributing to the3GPP RAN working groups for the standardization of LTE/5GBroadcast and participating in different project groups of the EBUStrategic Programme on Distribution such as 5G-Deployments, whichIEEE TRANSACTIONS ON BROADCASTING 12he chairs. Dr. Gimenez has a wide experience on terrestrial broadcasttechnologies, in particular on physical layer aspects and networkplanning. He has contributed to several DVB and ATSC technicalgroups on next-generation terrestrial broadcast technologies such astime-frequency slicing, channel bonding, LDM or WiB.Fasil Tesema is a senior research engineer andsimulation expert at Nomor Research GmbH,based in Munich, Germany. His researchinterests are 4G and 5G mobile networks witha focus on radio protocols and resourcemanagement for unicast, multicast, andbroadcast. He is a Member of the IEEE.Wei Guo received the B.Eng. degree incomputer communications and the Ph.D.degree in information and communicationsystems from the Beijing University of Postsand Telecommunications, China, in 1997 and2005, respectively. Since 2005, he joined anumber of EU funded ICT projects underFP6, FP7, and Horizon 2020. He is currentlywith the Samsung R&D Institute U.K., wherehe is involved in several EU funded projects. His research interestsinclude communication protocols, telecommunication networkarchitectures, and deep learning application to telecommunicationnetworks.David Gomez-Barquero is a Professor withthe Communications Department,Universitat Politecnica de Valencia, Spain.He held visiting research appointments withEricsson Eurolab, Germany, the KTH RoyalInstitute of Technology, Sweden, theUniversity of Turku, Finland, the TechnicalUniversity of Braunschweig, Germany, theFraunhofer Heinrich Hertz Institute, Germany, the Sergio ArboledaUniversity of Bogota, Colombia, the New Jersey Institute ofTechnology, USA, and the Electronics and TelecommunicationsResearch Institute, South Korea. He participated in digitalbroadcasting standardization, including DVB-T2, T2-Lite, DVB-NGHand, more recently, ATSC 3.0, as the Vice Chairman of the Modulationand Coding Ad-Hoc Group. He is the Coordinator of the 5G-PPPProject 5G-Xcast, that is, developing broadcast and multicast point-tomultipoint capabilities for the standalone 5G New Radio and the 5Gservice-enabled Core Network. His current main research interest isthe design, optimization, and performance evaluation of nextgeneration wireless communication technologies, includingbroadcasting.He is an Associate Editor of the IEEE TRANSACTIONS ONBROADCASTING. He was the General Chair of 2018 IEEESymposium on Broadband Multimedia Systems and BroadcastingDe Mi (M’17) received the B.Eng. degree ininformation engineering from the BeijingInstitute of Technology, Beijing, China, in2011, the M.Sc. degree in communications andsignal processing from Imperial CollegeLondon, U.K., in 2012, and the Ph.D. degreefrom the 5G Innovation Centre (5GIC),Institute for Communications Systems (ICS),University of Surrey, U.K., in 2017. He iscurrently a Research Fellow in future wireless communications andAcademic Ph.D. Supervisor of Engineering and Physical SciencesResearch Council (EPSRC) Industrial Cooperative Awards in Science& Technology (CASE) programme at the University of Surrey. He hasbeen the RAN work package leader of 5G-PPP project 5G-Xcast andProject Coordinator of industrial collaborative project SoftRAN in5GIC/ICS. His current main research interests include air interfacedesign, multiantenna signal processing, broadcast and multicasttechnologies, and millimetre-wave communications.View publication stats