d3.1 initial concepts on 5g architecture and …...document: h2020-ict-671650-mmmagic/d3.1 date:...

Document Number: H2020-ICT-671650-mmMAGIC /D3.1

Project Name: Millimetre-Wave Based Mobile Radio Access Network for Fifth Generation Integrated

Communications (mmMAGIC)

Deliverable D3.1

Initial concepts on 5G architecture and integration

Date of delivery: 31/03/2016 Version: 1.0 Start date of Project: 01/07/2015 Duration: 24 months

Document: H2020-ICT-671650-mmMAGIC/D3.1

Date: 31/03/2016 Security: Public

Status: Final Version: 1.0

Deliverable D3.1

Initial concepts on 5G architecture and integration

Project Number : ICT-671650

Project Name: Millimetre-Wave Based Mobile Radio Access Network for Fifth Generation Integrated Communications

Document Number : H2020-ICT-671650-mmMAGIC/D3.1

Document Title: Initial concepts on 5G architecture and integration

Editor(s): Krystian Safjan (NOK-PL), Arnesh Vijay (NOK-PL), Hardy Halbauer (ALUD), Mehrdad Shariat (SRUK), Joerg Widmer (IMDEA)

Authors: Anton Ambrosy (ALUD), Maria Fresia (Intel), David Gutierrez Estevez (SRUK), Hardy Halbauer (ALUD), Javier Lorca Hernando (TID), Yilin Li (HWDU), Jian Luo (HWDU), Honglei Miao (Intel), Filippou Miltiadis (Intel), Patrik Rugeland (EAB), Marcin Rybakowski (NOK-N(PL)), Krystian Safjan (NOK-N(PL)), Mehrdad Shariat (SRUK), Isabelle Siaud (Orange), Maciej Soszka (TUD), Anne-Marie Ulmer-Moll (Orange), Arnesh Vijay (NOK-N(PL)), Nikola Vucic (HWDU), Joerg Widmer (IMDEA), Yaning Zou (TUD)

Dissemination Level: PU

Contractual Date of Delivery: 31/03/2016

Security: Public

Status: Final

Version: 1.0

File Name: D3.1.docx

Abstract

The use cases envisioned for the future are dictating demanding and very diverse requirements for 5G mobile communication systems. State of the art systems, such as LTE-A, cannot meet future network requirements in terms of data rate, latency, reliability and ability to support many devices. Further, the envisioned ultra-dense deployments bring challenges of complex network management and the provisioning of backhaul to a large number of network nodes. For the future proofness, the 5G architecture should be flexible enough to support new usages of the networks. We study these challenges and approach them mainly from the RAN architecture perspective. We provide initial concepts that will be further evaluate in the course of the project. We found, that integration of mm-wave system with systems operating below 6 GHz (e.g. LTE-A) on the lowest possible level of the network architecture could solve most of identified problems. While the proposed initial solutions outline the direction for further development of the 5G architecture, many questions are still open and require further study.

Keywords

mm-wave, backhaul, fronthaul, network architecture, requirements, 5G, energy efficiency, cost efficiency, spectrum, mobility, multi-connectivity, self-backhaul, test scenario, test case, use case, protocol stack, network slicing, access point clustering, initial access

Acknowledgements

We would like to acknowledge the following people for the valuable reviews to the deliverable: Mark Doll, Valerio Frascolla, Christian Gallard, Patrick Marsch, Maziar Nekovee, Jyri Putkonen, Kei Sakaguchi, Icaro da Silva and Miurel Tercero.

mmMAGIC Public vi




mmMAGIC Public vii

Executive summary This document discusses a range of architectural aspects that are critical for the integration of mm-wave technology, and specifically mm-wave Radio Access Technology (RAT), in 5G mobile networks. While radio spectrum above 6 GHz offers contiguous high bandwidth resources for high capacity radio links, it also gives rise to new challenges in terms of user mobility and interference due to the harshness of the radio environment and the use of highly directional links. These are important considerations for the design of efficient network architectures at these frequencies. The document first gives a brief overview of the main mm-wave related use cases and related deployments and requirements. Then it outlines the requirements and initial concepts envisioned for 5G mm-wave architecture in 6–100 GHz frequency band, and discuss some crucial aspects of its integration within the 5G networks. The proposed concepts include:

• Network slicing to address needs of 5G use cases with highly divergent requirements. By operating on logical instead of physical elements network slicing provides architecture flexibility and future proofness.

• Multi-connectivity with multiple mm-wave base stations and as a way to integrate multiple RATs. Multi-connectivity between mm-wave and <6 GHz RATs addresses challenges related to performance requirements in terms of capacity, coverage and reliability. One out of the possible practical realizations might be an evolution of LTE-A Dual Connectivity.

• Mobility related aspects such as mm-wave cell clustering to make small scale mobility of the UE transparent to the CN and the introduction of a novel inactive RRC state in order to minimize amount of control signaling needed when user’s mobile broadband data traffic consists of many infrequent small bursts of traffic interspersed by relatively long waiting periods, e.g., during web browsing or short video or music streaming.

• Multi-RAT multi-layer management scheme which introduces abstraction at different layers of the protocol stack for flexible and scalable multi-RAT management that can be deployed jointly with multi-connectivity.

• User and control plane aspects for mm-wave and low-band integration such as: efficient control signalling that minimize control overhead or RRC diversity to improve reliability.

• Division of initial access control information that in multi-connectivity case should be send over low-band (<6 GHz) system.

• MAC and RRM solutions that introduces inter-node coordination mechanisms to minimize inter-cell interferences in presence of beamforming. Early triggered MAC-level retransmissions addresses low latency requirements. Maximizing coverage range with beamforming, and techniques to minimize beam-training time are addressed with proposed efficient multi-user rate scheduling methods based on coordinated beam frequency scheduling.

• Architectural aspects of single- and multi-hop self-backhauling e.g. resource allocation for access and backhaul, and multi-hop routing.

While the proposed initial solutions outline the direction for further development of the 5G architecture, many questions are still open and require further study.




mmMAGIC Public viii

Contents 1 Introduction ...................................................................................................................... 1

1.1 Background ............................................................................................................... 1 1.2 Scope of work ........................................................................................................... 1

1.3 Relevant EU projects ................................................................................................ 2

1.4 Definitions of technical terms .................................................................................... 4 2 Use cases, deployments and requirements ...................................................................... 8

2.1 Use cases ................................................................................................................. 8

2.2 Test scenarios for system evaluation ...................................................................... 10 2.3 Envisioned deployments and traffic model assumptions ......................................... 11

2.4 Requirements derived from use cases, deployments and traffic assumptions ......... 12

2.4.1 High level requirements ...................................................................................... 12

2.4.2 Requirements specific for access in standalone mm-wave systems .................... 13

2.4.3 Requirements specific for access in non-standalone mm-wave systems............. 13

2.4.4 Design requirements for backhaul ....................................................................... 14

2.4.5 Requirements for air interface ............................................................................. 14 2.4.6 Requirements for multi-antenna transceivers ...................................................... 15

2.5 Design principles for architecture ............................................................................ 15

2.5.1 Design to support both standalone and non-standalone mm-wave system deployments ................................................................................................................... 16

2.5.2 Efficient control signalling to support system access and mobility ....................... 17

2.5.3 Network slicing .................................................................................................... 18

2.5.4 Synchronous and asynchronous functions distinction ......................................... 18

2.5.5 Device capabilities signalled from the CN ........................................................... 18

3 Integration for 5G networks ............................................................................................ 19 3.1 Scope of integration and architecture work ............................................................. 19

3.1.1 Division between RAN and CN ........................................................................... 19

3.2 The state-of-the-art integration based on hard-handovers between the RATs ......... 20 3.2.1 Drawbacks of the integration based on hard-handovers between the RATs ........ 21

3.2.2 Motivation to design new, more efficient schemes for integration ........................ 21

3.3 Integration as a remedy for challenges coming from 5G requirements .................... 22 3.3.1 Enabling network capabilities adequate to fulfil 5G use cases requirements ....... 22

3.3.2 Managing Ultra Dense Networks and providing sufficient backhaul solution ....... 22

3.3.3 Design of flexible RAN architecture ..................................................................... 23

3.4 RAN architecture ..................................................................................................... 23

3.4.1 Protocol stack for 5G system .............................................................................. 23

3.4.2 Logical architecture of 5G network ...................................................................... 25 4 Solutions (technology components) ............................................................................... 28

4.1 Network Slicing ....................................................................................................... 28

4.1.1 Introduction ......................................................................................................... 28 4.1.2 Impact on the RAN design .................................................................................. 29

4.1.3 Network functions from network slicing perspective ............................................ 30

4.2 Review and redesign of the protocol stack for the mm-wave integrated system ...... 31 4.2.1 Review of the RRC states ................................................................................... 31

4.3 Multi-connectivity and multi-RAT ............................................................................. 33

4.3.1 Multi-connectivity types ....................................................................................... 33

4.3.2 Base station support through low frequency band ............................................... 43

4.3.3 Metro-like deployment with coverage from multiple base stations, with support from lower frequency bands ........................................................................................... 44

4.3.4 The single/multi-connectivity optimization schemes for standalone and non-standalone RAN ............................................................................................................. 46

4.3.5 Energy efficiency in single/multi-connectivity optimization ................................... 48

4.3.6 Multi-layer multi-RAT management ..................................................................... 48 4.3.7 Energy efficient multi-RAT link adaptation system design ................................... 50




mmMAGIC Public ix

4.4 mm-wave access point clustering............................................................................ 51

4.4.1 Cluster structure .................................................................................................. 52

4.4.2 Deployment variants ........................................................................................... 53 4.4.3 Mobility in cell clusters ........................................................................................ 57

4.4.4 Cluster management ........................................................................................... 59

4.5 Initial access, mobility management and handovers ................................................ 62 4.5.1 Low frequency RAT assisted initial access .......................................................... 62

4.5.2 Energy efficient initial access .............................................................................. 64

4.5.3 Fast handover/scheduling in standalone mm-wave RAN .................................... 64

4.5.4 Fast handover/scheduling between technologies ................................................ 65

4.5.5 Active mode mobility ........................................................................................... 66

4.5.6 Mobility on demand ............................................................................................. 67

4.6 MAC and RRM ........................................................................................................ 67

4.6.1 Coordination mechanisms to minimize inter-cell interferences in the presence of beamforming .................................................................................................................. 68 4.6.2 Early triggering of MAC-level retransmissions in fully or partially centralized deployments ................................................................................................................... 71

4.6.3 Dynamic resource sharing for directional beamforming using Listen-Before-Talk 72 4.6.4 Multi-antenna techniques to support media-on-demand use cases ..................... 74

4.6.5 Coordinated beam frequency scheduling ............................................................ 75

4.7 Self-backhauling ..................................................................................................... 80 4.7.1 Introduction ......................................................................................................... 80

4.7.2 Design targets for self-backhauling ..................................................................... 80

4.7.3 Realizing self-backhaul cases ............................................................................. 81

4.7.4 Dynamic multi-hop self-backhauling .................................................................... 83

4.7.5 SDN-based self-backhauling ............................................................................... 86

4.7.6 Resource allocation for backhaul and access links that involves spatial multiplexing .................................................................................................................... 88

4.7.7 Resource allocation for access and self-backhaul in dynamic half-duplex TDD system ........................................................................................................................... 89

4.7.8 Dynamic Interleaving codes for self-backhauling and RRM ................................. 90

5 Summary and highlights ................................................................................................. 93

6 References..................................................................................................................... 98

7 Annex A: Partners Input ................................................................................................106

8 Annex B: Test scenarios ...............................................................................................108

9 Annex C: Coordination mechanisms to minimize inter-cell interferences in the presence of beamforming ........................................................................................................................110 10 Annex D: Cell cluster examples .....................................................................................113




mmMAGIC Public xi

List of Figures Figure 1-1 List of related EU projects pertaining to mm-wave technology ............................... 2

Figure 2-1 Relation between considered use cases defined in Table 2-1. The colours indicate whether the use case is considered for outdoor (O, blue), indoor (I, yellow) or outdoor-to-indoor (green, O-I). .......................................................................................................................... 10

Figure 2-2 Two primary modes of network operation studied in mmMAGIC and exemplary problems to solve for each mode .......................................................................................... 16

Figure 3-1 SAE Architecture .................................................................................................. 19

Figure 3-2 CN/RAN split architecture for mm-wave RAT as standalone and non-standalone using same interfaces as LTE-A ............................................................................................ 20

Figure 3-3 The mm-wave and LTE-A protocol stacks. The inter-RAT handover is being done on CN level (out of scope of this figure showing RAN part) ........................................................ 21

Figure 3-4 Three main directions of challenges for architecture evolution from LTE-A to 5G . 22

Figure 3-5 User-plane protocol stack ..................................................................................... 24

Figure 3-6 Control plane protocol stack ................................................................................. 25

Figure 3-7 Baseline logical architecture for 5G system. ......................................................... 25

Figure 3-8 Network virtualization: distributed scenario – only CN is located in the cloud, full radio protocol stack is located 5G-NBs. ......................................................................................... 26

Figure 3-9 Network virtualization: centralized scenario (with RRHs). Core and Radio Access parts are in separate clouds. From the radio part in Remote Radio Heads there is only RF functionality located. .............................................................................................................. 27

Figure 4-1 Network Slicing idea, main components and their relations [NGMN15] ............... 29

Figure 4-2 Three types of radio network functions envisioned in context of Network Slicing .. 31

Figure 4-3 Novel RRC state RRC Connected Inactive and state transition diagram between three RRC states: RRC Idle, RRC Connected Inactive and Connected. ................................ 33

Figure 4-4 Classification of different multi-connectivity types ................................................. 34

Figure 4-5 Selected Intra-frequency multi-connectivity solutions: Single Frequency Network, Joint-Transmission CoMP, Dynamic Point Selection CoMP .................................................. 35

Figure 4-6 Layer 2 connectivity potential solutions. ............................................................... 37

Figure 4-7 LTE – 5G interworking architecture based on LTE-A Dual Connectivity. Blue colour existing LTE protocols with minimum necessary updates and white colour new 5G protocols/extended LTE-A protocols. ..................................................................................... 38

Figure 4-8 User plane architecture option 1a ......................................................................... 38

Figure 4-9 User plane architecture option 3c ......................................................................... 39

Figure 4-10 Radio Protocol Architecture for 5G dual connectivity – all flows and splits considered in this section: flows from 1a, 3c and additional RFL split in SeNB (not allowed in 1a and 3c). .............................................................................................................................................. 39

Figure 4-11 Enabling RRC multi-connectivity for 5G ............................................................. 40

Figure 4-12 User and control plane connected to both LTE-A and the mm-wave RAT .......... 41

Figure 4-13 LTE-A and mm-wave user plane switch while control plane is in “dual connectivity” with both LTE-A and 5G ........................................................................................................ 42

Figure 4-14 LTE-A and mm-wave CP and UP switch. The common PDCP layer allows faster switching between RATs compared to hard-handover........................................................... 43




mmMAGIC Public xii

Figure 4-15 Multi-base-station coverage on mm-waves ........................................................ 45

Figure 4-16 Multi-layer multi-RAT management architecture ................................................. 49

Figure 4-17 The power efficiency metric (GLB metric) ........................................................... 50

Figure 4-18 The temporal occupation metric used for energy efficient metric definition ......... 51

Figure 4-19 mm-wave cluster elements ................................................................................. 52

Figure 4-20 Network topology for ideal backhaul ................................................................... 53

Figure 4-21 Network topology for non-ideal wired backhaul .................................................. 54

Figure 4-22 Clusters in wireless self-backhaul ...................................................................... 55

Figure 4-23 Network topology for wireless self-backhaul ....................................................... 55

Figure 4-24 Cluster architecture for standalone mm-wave cells in single-RAT scenario. ....... 56

Figure 4-25 Cluster architecture for the multi-RAT scenario .................................................. 57

Figure 4-26 Common time slots for beam tracking purpose .................................................. 58

Figure 4-27 Addition of cells served by secondary APs to the cluster set .............................. 62

Figure 4-28 Principle of mobility on demand. ......................................................................... 67

Figure 4-29 Simple condition for the appearance of inter-cell interferences with strong beamforming, in the absence of reflectors ............................................................................. 69

Figure 4-30 General condition for the appearance of inter-cell interferences with strong beamforming, in the presence of reflectors ............................................................................ 69

Figure 4-31 Acquisition of beam indicators by an interfered UE for the proposed inter-cell beam coordination mechanism ....................................................................................................... 70

Figure 4-32 Decoupling of retransmissions from FEC decoding for the proposed early triggering of MAC-level retransmissions in centralized deployments ..................................................... 72

Figure 4-33 Problem illustration of directional Listen-Before-Talk: a) Hidden node problem, b) Exposed node problem ......................................................................................................... 73

Figure 4-34 Deployment scenario for modified Manhattan grid scenario ............................... 74

Figure 4-35 Benefits of using MU-MIMO: a base station can schedule multiple users at the same time and frequency resource ................................................................................................. 75

Figure 4-36 Decentralized scheduling algorithm .................................................................... 78

Figure 4-37 Centralized scheduling algorithm ....................................................................... 79

Figure 4-38 Concept of self-backhauling ............................................................................... 80

Figure 4-39 Different cases in self-backhauling ..................................................................... 82

Figure 4-40 Illustration of envisioned multi-hop self-backhauling case .................................. 84

Figure 4-41 An example ringed-tree backhaul networking ..................................................... 87

Figure 4-42 Backhaul networking with high-level network elements ...................................... 87

Figure 4-43 FDD operation mode of self-backhauling ........................................................... 88

Figure 4-44 Heterogeneous cellular networks exploits spatial multiplexing ............................ 89

Figure 4-45 Resource allocation in frequency and time between self-backhaul and access part .............................................................................................................................................. 89

Figure 4-46 Resource allocation for self- backhaul and access links in single-hop dynamic TDD systems ................................................................................................................................. 90




mmMAGIC Public xiii

Figure 4-47 Dynamic Interleaving code processing for self-backhauling processing and virtual multi-band process ................................................................................................................ 91

Figure 8-1 Manhattan grid test scenario .............................................................................. 108

Figure 8-2 Madrid grid test scenario .................................................................................... 108

Figure 8-3 Asian city grid test scenario ................................................................................ 108

Figure 8-4 Virtual reality office test scenario (left) and WINNER indoor office test scenarios (right) ............................................................................................................................................ 109

Figure 8-5: Shopping mall test scenario .............................................................................. 109

Figure 8-6 Dual-stripe model as used in 3GPP. It consist of two multi-floor and multi-room buildings located in close vicinity. ........................................................................................ 109

Figure 9-1 Possible structure of the Automatic Interference Relation Report (AIRR) for the proposed inter-cell beam coordination mechanism .............................................................. 110

Figure 9-2 Periodic/aperiodic reporting of AIR reports upon request from the 5G NB, for the proposed inter-cell beam coordination mechanism .............................................................. 111

Figure 9-3 Automatic Interference Relation Table (AIRT) showing the beam indicators BIij as reported back by user i related to cell j, for the proposed inter-cell beam coordination mechanism ............................................................................................................................................ 111

Figure 9-4 Illustration of a simple time-domain coordination between cells A and B each coordinating different beams, for the proposed inter-cell beam coordination mechanism .... 112

Figure 10-1 Cluster of cells example #1: The Cluster head is an AP serving a cell in the cluster set. UE1 selects and connects to cell C12 (strongest cell). In case the link to C12 is blocked, the user data and control planes are re-routed to AP2 to serve the UE1 via cell C23 .......... 113

Figure 10-2 Cluster of cells example #2: The Cluster Head is an AP which is not serving any cell in the cluster set ............................................................................................................ 114




mmMAGIC Public xv

List of Tables Table 1-1 Definitions of technical terms ................................................................................... 4

Table 2-1 Use cases to be considered for 5G architecture ...................................................... 9

Table 2-2 The Access requirements and parameters required for derivation of BH requirements .............................................................................................................................................. 14

Table 4-1 General definitions for clustering logical and functional architecture ...................... 53

Table 4-2 Access/backhaul link combinations for outband backhauling ................................. 83

Table 4-3 Access/backhaul link combinations for flexible multi-backhauling .......................... 83

Table 7-1 Details on deployments addressed by the partners ............................................. 106




mmMAGIC Public xvii

List of Abbreviations

2G Second Generation 3G Third Generation 3GPP Third Generation

Partnership Project 4G Fourth Generation 5G Fifth Generation 5GPPP The 5G Infrastructure Public-

Private Partnership AAS Active Antenna System ACB Access Class Barring ACK Acknowledgement AIRR Automatic Interference

Relation Report AIRT Automatic Interference

Relation Table ALUD Alcatel-Lucent Deutschland

AG AMC Adaptive Modulation Coding AoA Angle of Arrival AoD Angle of Departure AP Access Point ARQ Automatic Repeat request AWGN Additive White Gaussian

Noise BB Baseband or Basic Beam BBU Baseband Unit BER Block Error Rate BF Beamforming BH Backhaul BLER Block Error Rate BS Base Station BW Bandwidth CA Carrier Aggregation CH Cluster Head CN Core Network CoMP Coordinated Multi-Point CP Cyclic Prefix CPE Customer premises

equipment CPRI Common Public Radio

Interface CQI Channel Quality Indication CRC Cyclic Redundancy Check CRS Common Reference

Symbols

C-RS Cell Specific Reference Symbol

CS Control Signaling CSI Channel State Information CSM Cluster Set Manager DC Dual Connectivity DFT Discrete Fourier Transform DL Downlink DN Destination Node DRX Discontinuous Reception E2E End to end EAB Ericsson AB Eb/No Bit Energy on the Spectral

Noise Density eDC Enhanced Dual Connectivity EHF Extremely High Frequency EIRP Effective Isotropic Radiated

Power EM Electromagnetic eNB Evolved NodeB EPS Evolved Packet System ETSI European

Telecommunications Standards Institute

EU European Union E-UTRA Evolved Universal Terrestrial

Radio Access E-UTRAN Evolved Universal Terrestrial

Radio Access Network FB Full Buffer Or Feedback FBMC Filter Bank Multicarrier FDD Frequency-Division

Duplexing FDMA Frequency Division Multiple

Access FEC Forward Error Correction FFT Fast Fourier Transform FH Fronthaul FP7 7th Framework Programme

Fs Fronthaul split logical interface

FST Fast Session Transfer FTP File Transfer Protocol Gbps Gigabits per second GFDM Generalized Frequency

Division Multiplexing




mmMAGIC Public xviii

GLB Green Link Budget GoB Grid of Beams GPRS General Packet Radio

Service GSM Global System for Mobile GW Gateway H2020 Horizon 2020 HARQ Hybrid Automatic Repeat

request HO Handover HPBW Half Power Beamwidth HSS Home Subscriber Server HTTP Hypertext Transfer Protocol HWDU Huawei Technologies

Dusseldorf GmbH I2I Indoor to Indoor

(propagation) ID Identifier IEEE Institute of Electrical and

Electronics Engineers I-MAC Isochronous MAC IMDEA IMDEA Networks Institute IMT International Mobile

Telecommunications IP Internet Protocol ISD Inter-Site Distance ITU International

Telecommunication Union JT Joint Transmission KPI Key Performance Indicator L1 Layer-1 (Physical Layer) L2 Layer-2 (Data link Layer) L2.5 Layer 2.5 L2S Link to System (interface) L3 Layer-3 (Network Layer) LA Link Adaptation LAA Licensed Assisted Access LAN Local Area Network LBT Listen Before Talk LDPC Low Density Parity Check LF Low Frequency L-GW Local Gateway LLC Logical Link Control LMDS Local Multipoint Distribution

Service LNA Low-Noise Amplifier LOS Line of Sight

LTE Long Term Evolution LTE-A Long Term Evolution

Advanced M5G-NB Master 5G-NB MAC Medium Access Control MBB Mobile Broadband Mbps Megabits per second MC Multi-Connectivity MCG Master Cell Group MCM Multipath Channel Margin MCS Modulation and Coding

Scheme MEC Mobile Edge Computing MEF Maintenance Entity Function MeNB Master eNB MIB Master Information Block MIMO Multiple Input Multiple

Output MLO Multiple Link Optimization MME Mobility Management Entity MNO Mobile Network Operator MPLS Multiprotocol Label

Switching MRC Maximal Ratio Combining MRS Mobility Reference Signal MS Mobile Station MTC Machine Type

Communication MU-MIMO Multi User MIMO NACK Negative Acknowledgement NAS Non-Access Stratum NB NodeB NC Network Controller NF Network Function NFV Network Function

Virtualization NGMN Next Generation Mobile

Networks NLOS Non Line of Sight NM Network Management NOK-N(PL)

Nokia Networks Poland

NW Network O2I Outdoor to Indoor

(propagation) O2O Outdoor to outdoor

(propagation)




mmMAGIC Public xix

OFDM Orthogonal Frequency Division Multiplexing

OTT Over-The-Top PCell Primary Cell PDCCH Physical Downlink Control

Channel PDCP Packet Data Convergence

Protocol PDN Packet Data Network PDU Protocol Data Unit P-GW Packet Data Network

Gateway PHY Physical layer PLM Path-Loss Margin PoP Point of Presence PSM Power Saving Mode PSS Primary Synchronization

Signal PUCCH Physical Uplink Control

Channel QAM Quadrature Amplitude

Modulation QoE Quality of Experience QoS Quality of Service RACH Random Access Channel RAN Radio Access Network RAT Radio Access Technology RB Resource Block ReTX Retransmission RF Radio Frequency RFL Radio Flow RLC Radio Link Control RRC Radio Resource Control RRH Remote Radio Head RRM Radio Resource

Management RSRP Reference Symbol Received

Power RSRQ Reference Signal Received

Quality RTT Round Trip Time Rx Receive S5G-NB Secondary 5G-NB SAE System Architecture

Evolution SAP Service Access Point sBH Self-backhaul SB-NB

SC Small Cell SCell Secondary Cell SCG Secondary Cell Group SC-LDPC Spatially Coupled Low-

Density Parity-Check SDN Software Defined Network SeNB Secondary eNB SFN Single Frequency Network S-GW Serving Gateway SHF Super High Frequency SIB System Information Block SINR Signal to Interference plus

Noise ratio SLO Single Link Optimization SN Source Node SNR Signal To Noise Ratio SoTA State of The Art SRS Sounding Reference Signal SRUK Samsung Research UK SS Synchronization Signal SSS Secondary Synchronization

Signal STDMA Space Time Division Multiple

Access SU-MIMO Single User MIMO TCO Total Cost of Ownership TCP Transmission Control

Protocol TDD Time-Division Duplexing TDMA Space Time Division Multiple

Access TID Telefónica Investigación y

Desarrollo SAU TM Transmission Mode TP Transmission Point TR Technical Report TS Technical Specification TTI Transmission Time Interval TUD Technische Universität

Dresden Tx Transmit UDN Ultra Dense Network UDP User Datagram Protocol UE User Equipment UL Uplink uMTC Ultra-reliable MTC UMTS Universal Mobile

Telecommunications System




mmMAGIC Public xx

UP User Plane V2X Vehicle-to-anything VNF Virtual Network Function WA Wide Area WAN Wide Area Network

WLAN Wireless LAN WP Work package WRC World Radio Congress xMBB extreme Mobile Broadband




mmMAGIC Public 1

1 Introduction

1.1 Background Radio technology has been greatly evolving and expanding on yearly-basis ever since its introduction in the late 19th century. With its rapidly advancing technological trends, it is anticipated that beyond 2020, radio networks will be composed of a range of diverse technologies and cell types, making it imperative to prepare the next generation mobile architectures. For seamless network evolution, future radio systems should integrate conventional systems. These highly important topics are attracting the attention of researchers around the globe; and more recently, considerable effort and resources have been allocated for the investigation on the expansion of radio systems into higher frequency bands of the electro-magnetic (EM) spectrum. One such venture is the EU-funded mmMAGIC project on “Millimetre-Wave based Mobile Radio Access Networks for Fifth Generation Integrated Communication”.

As a brief introduction, the mmMAGIC project was launched in mid-2015, with the main goal to design and develop a new 5G multi-RAT ecosystem to target ultra-dense deployments and ultra-high capacity mobile data services. The overall objective of the project is to research, design and develop mobile radio access techniques operating in the mm-wave bands. When mentioning mm-wave in this report, it implies, waves in the frequency bands ranging from 6–100 GHz, unlike the usual ITU terminology which classifies 3-30 GHz (Super High Frequency, SHF) as Centimeter waves and 30–300 GHz (Extreme High Frequency, EHF) under millimetre waves group of Electromagnetic spectrum [ITUR Rec]. The foundational aspects describing the project use cases characterization, KPIs and preferred frequency bands have already been covered in the first deliverable of work package one (WP1) [MMMAG15-D11]. This report will instead focus on the initial 5G architecture concepts and network integration aspects covered by WP3. An essential element of this WP is to investigate the techniques required to integrate mm-wave technology with other 5G system components and to secure seamless mobility between mm-wave base stations [EUCNC15].

This deliverable is organized into five major sections with further sub-divisions. Section one introduces the project and outlines the scope of this document. Next, section two provides a list of various use cases, deployment and test scenarios considered in this project. This section further continues with the requirements derived from these envisioned deployment scenarios and traffic model assumptions. Further ahead, the subsequent section will cover in detail the integration challenges pertaining to the project, with the latter segment explaining the solutions envisaged to be implemented during the course of this project. Here, broad range of technical solutions under different aspects related to architecture and integration will be discussed. Finally, the report ends with concluding remarks highlighting the future roadmap of this project.

1.2 Scope of work The aim of this particular WP is to develop network architectural elements and functions that will enable full integration of mm-wave technology with other 5G system components. The main intention is to provide robust mobility and multi-connectivity between mm-wave and other 5G access nodes, thereby providing an 'edge-less' end user experience. As it is well known to the technical community, spectrum over 6 GHz provides wider contiguous allocations for wireless access and backhaul links. However, the expansion into higher frequency bands gives rise to new challenges in terms of user mobility and interference, requiring novel intra- and inter-RAT cooperation schemes for network integration. Furthermore, it is clearly anticipated that mm-wave technology can enable other advanced technologies in future 5G systems. For this, work will be conducted investigating the various possibilities for mm-wave wireless backhaul and




mmMAGIC Public 2

fronthaul technologies that can be combined with LTE-A and 5G radio systems. The primary focus here is to fully enable flexible and scalable network deployments to reduce network costs, and increase their adaptability to dynamic conditions.

The main scope of this report is to outline the initial concepts envisioned for the architecture and integration of mm-wave access with other 5G radio systems that shall be carried out within this specific work package. A broad range of topics addressing mobile architecture and network integration will be covered, such as: multi-connectivity, mobility, self-backhauling, energy and cost efficiency etc. The prime intention of this document is to list key challenges and discuss its technical solutions. System level simulation plans and concrete performance results will be part of future deliverables.

1.3 Relevant EU projects The growing demand for high bandwidth services has captured the interest of several research groups, consortia and projects to study 5G technologies—and specifically to explore the possibility for the integration of mm-wave technology into future mobile telecommunication systems. In this section, we will present a brief overview of ongoing EU projects related to mmMAGIC— the list of which is illustrated in Figure 1-1. The main intention here is to provide a concise review of the technical work carried out in different projects related to mm-wave technology.

Figure 1-1 List of related EU projects pertaining t o mm-wave technology

MiWaveS: MiWaveS is an industry driven collaborative project developing mm-wave wireless communication technologies for future heterogeneous cellular mobile networks. Specifically, it demonstrates how low-cost or advanced mm-wave technologies can provide multi-Gigabit per second access to mobile users, and investigates and demonstrates key enabling technologies

mm-wave Related Projects

MiWaveS

MiWEBA

FANTASTIC 5G

5G XHAUL

5G NORMA

METIS-II

TWEETHER

5G CROSSHAUL




mmMAGIC Public 3

and functionalities supporting the integration of mm-wave small cells in future heterogeneous networks. While it is a stand-alone project, some similarities can be drawn with mmMAGIC. As an example, both projects will consider wide frequency bands, taking into account dense urban scenarios. Also, the two projects have similar goals of high throughput, low latency, low interference, high QoS, etc., with the common interest to investigate frequency bands in 71-86 GHz. MiWEBA: The main intention of this project is to extend the network capacity by 1000 times, to resolve the issue of scarce capacity without diminishing the QoE to the end users. MiWEBA is developing research and proof of concept for a mm-wave overlay in dense heterogeneous networks (HetNet), in which mm-wave ultra-broadband base stations employing recent state-of-art technology will be introduced and integrated into conventional cellular networks. The architecture proposed by MiWEBA will provide a basic solution for enabling data and control plane splitting at 60 GHz to overcome the restricted coverage problem of mm-wave links, and will also introduce power efficient multi-RAT deployments. In the project, massive lens antenna arrays have been developed for 60 GHz operations, alongside advanced spatial processing techniques for backhaul and mobile access scenarios. Fantastic-5G : This project aims at the design of a modular air interface operating below 6 GHz, which simultaneously can support a variety of heterogeneous services and use cases like mobile broadband, massive machine-type communication or mission critical communication. The focus here is on a flexible and scalable PHY and MAC layer implementation, and its integration into an overall framework achieving the adaptability to diverse service needs. In relation to mmMAGIC, this project’s air interface forms a suitable candidate for a complementary system for low frequency band support for mm-wave connections. 5G-XHaul: The 5G-XHaul project aims at build an ambitious converged optical and wireless network solution, which relies upon a flexible infrastructure capable of supporting fronthaul and backhaul networks, required to cope with the future challenges imposed by the RAN. 5G-XHaul will provide an efficient, reconfigurable, modular and highly scalable platform to support RAN processing, depending on different architectural solutions, network elements and devices. Furthermore, another intention of this project is to perform a joint backhaul and RAN optimization, with exhaustive topology control and load balancing for future 5G systems. 5G NORMA: The project aims at developing a novel mobile network architecture that provides multi-service and context aware adaptability of network functions to support varying and dynamically changing traffic and deployment scenarios. The 5G NORMA approach is to apply concepts from software-defined networking (SDN) and network function virtualization (NFV), to define the architecture framework, comprising generic network functions and interfaces, to establish flexible 5G networks. METIS-II: This aims at developing an overall 5G RAN architecture (including radio functions) and considers issues pertaining to the core network, such as the CN/RAN split and network slicing within the RAN. One of the major goals of this project is the integration of multiple air interface variants, which shall be developed in mmMAGIC project. To highlight the close relation between the two projects, we note that some architectural aspects of mm-wave RAT with lower frequency air interface variants (such as the evolution of LTE) proposed in mmMAGIC is partly covered in METIS-II. In addition, METIS-II is already in collaboration with mmMAGIC to drive a series of 5G-PPP internal and external workshops on RAN architecture, design and integration. TWEETHER: The main intention of this project is to realize wide band (92- 95 GHz) wireless system in millimetre wave technology for the everywhere distribution of high speed internet. The TWEETHER project aims to realize millimetre wave multi-point segments to link fibre, and sub-6 GHz distribution for a full three segment hybrid network, with a cost-effective architecture to reach mobile or fixed individual clients. With more towards an integrated approach, this project




mmMAGIC Public 4

will allow the capacity and coverage challenges of the current backhaul and access solutions to be overcome, which complements the overall objective of mmMAGIC. 5G-CROSSHAUL: The 5G-Crosshaul project aims at developing integrated 5G backhaul and fronthaul transport elements, enabling flexible and software-defined reconfiguration of all networking elements. The transport network element in the project is envisioned to comprise high-capacity switches and a combination of heterogeneous transmission links, such as: fibre, high capacity copper and mm-wave systems; interconnecting remote radio heads, 5G micro and macro cells, and cloud-processing units. Although this project will more closely look into the flexibility of the transport network in 5G systems, the topologies and techniques adopted for mm-wave backhaul and fronthaul wireless access are related to those adopted in mmMAGIC.

1.4 Definitions of technical terms The following section provides a list of definitions of various technical terms that will be used in the document and in future work within WP3.

Table 1-1 Definitions of technical terms Term Definition

Access link The wireless link connecting the access point and user equipment. Backhaul These are portions of the network comprising intermediate connections between the core

networks and the sub-networks (i.e. radio access nodes) attached to the macro-cell, and connections in-between the radio access nodes.

Backhaul network

Serves as the transport medium for a mobile radio access network (RAN) and connects the access points to core network. In case of multi-hop backhaul, connections between access points are also part of the backhaul network.

Control Plane The part of the network that carries control information (also known as signalling) to provide functionalities such as connectivity management, mobility management, radio resource control etc..

Deployment Characterization of the network layout (i.e., physical and logical locations); but also RAN configuration like antennas, Tx power, frequency band, bandwidth, system features and supporting architectural solution.

Dedicated Backhauling

Physical connection between specific radio access nodes and the core network are only used for backhauling.

Dynamic Backhauling

The backhaul network topology can be adaptively changed based on certain load balancing and service-aware routing schemes to avoid congestion and optimize quality of service statistics, especially in case of multi-hop and mesh topologies.

Edge-less This defines new ways of connection and interaction; whereby, the devices are no longer just end-points, but are integral part of the mobile network, experiencing uniform coverage (where there is no perception of cell-edges); combined with greater capacity and high quality uninterrupted mobile services.

Fronthaul Connections between a network architecture of centralized baseband controller and remote standalone radio heads at cell sites.

Hybrid Network

A network topology that uses a combination of two or more different topologies, in such a way that the resulting network exhibits an advanced functionality than those of the standard networks.

In-Band Backhauling

Wireless backhaul connection which occupies the same frequency band as the access network, and possibly the same technical solutions.

Integrated backhaul

The wireless backhaul technology is combined/integrated with other traditional backhauling technologies such as optical fibre systems. Also, in some context, the term is used as a backhaul solution that is (tightly) integrated with the access point.

Key Performance Indicator (KPI)

A quantifiable measurement, agreed beforehand, that reflects the critical success factors of a proposed solution; it reflects the goals captured by each use case. The KPIs are linked to the use case, so as to link the proposed solutions with the usage driven test cases.

Layer Model Functional division of communication tasks. The task of each layer is to provide services for the layer immediately above it, using the services provided by the underlying layer to do so. The services within a layer are mapped to entities.

Network element

A facility or equipment used as a manageable logical entity uniting one or more physical devices. Network element is a system that can be managed, monitored, or controlled in a




mmMAGIC Public 5

Term Definition telecommunications network that has one or more standard interfaces, and is identified by a unique management address.

Network layers

In a single-RAT scenario, a network layer could refer to either macro cell or small cells deployed in the same area. On the other hand, in a co-deployed multi-RAT scenario, a network layer refers to a communication network supporting a unique radio access technology.

Network segments

Group of network nodes of a communication network, which is physically or logically separated from the rest of the network.

Out-band Backhauling

Wireless backhaul connection which occupies different frequency band to that of the access network, and possibly the same or different technical solutions

Propagation environment

The medium and propagation conditions between the Access Point (AP) and the User Equipment (UE).

Radio Access Network Architecture

RAN architecture defines a number of logical RAN node and their functionalities, the way that they are grouped and the interfaces between end users and RAN node; between the core and RAN node, and between RAN nodes.

Radio Interface Interface between the User Equipment (UE) and the radio equipment in the network, defined by functional characteristics, common radio (physical) interconnection characteristics, and other characteristics, as appropriate. Radio interface spans over PHY and MAC layers.

Radio Access Technology

Technology that is used to connect different terminals and applications to telecommunication networks by using radio frequency signals.

Requirement Each use case is characterized by different needs in terms of KPIs. The quantified needs are called requirements.

Self-backhauling

The radio access node autonomously establish backhaul connectivity to the existing network infrastructure and start operation in a plug-and-play fashion.

Standalone Network

A network which is capable of operating independently of any other device or system.

Test scenario Practical aspect formulated from an end-users’ perspective. It defines the physical properties of the environment where the end users are located when having particular services. Hence, each test case contains a set of assumptions, constraints and requirements. A use case may cover several concrete test cases; conversely, a test case may have several challenges and therefore belong to several use cases

Use case General account of a situation or course of actions that may occur in the future. It is described from an end-user perspective and illustrates fundamental challenges. It provides an example on how, when and where end users can utilize mobile communication for having particular services

User Plane The part of the network that mainly carries user traffic (also known as data plane) coupled with minimized control signalling such as multiple access information.

Ultra-lean transmission

Transmission which minimizes energy consumption of network nodes.




mmMAGIC Public 7




mmMAGIC Public 8

2 Use cases, deployments and requirements

As a basis to derive the initial concepts for the 5G architecture, this section shortly revisits the use cases as identified in mmMAGIC deliverable D1.1 [MMMAG15-D11]. In Subsection 2.1 the relation between the different use cases is highlighted and possible test scenarios are explained in Section 2.2.

The details on the deployments and the expected traffic models assumed for the different use cases provide requirements impacting the design of mm-wave systems. Therefore they are an essential input for the architecture definition of a 5G mm-wave system. Section 2.3 provides an overview on the deployments considered as relevant for 5G mm-wave communication systems. Several access and backhaul topologies for outdoor and indoor scenarios will be described.

In Section 2.4 high level requirements are formulated, which are needed to operate a 5G mm-wave system for a specific use case within a specific deployment. First the generic requirements are addressed, then specific functionalities and performance targets for backhaul and access part of the system are described in a qualitative way. Full quantitative requirements, however, can only be given at a later stage, when the different initial concepts are defined in detail.

Finally, in Section 2.5 design principles for network architecture are formulated. First, two main scenarios for mm-wave system operation are defined: standalone and non-standalone followed by specification of requirements towards efficient control signalling and Network Slicing. Then distinction between synchronous and asynchronous functions is made. The section closes with requirement of device capabilities signalled from the CN.

2.1 Use cases The definition and design of a suitable architecture for 5G mm-wave systems will be oriented at the eight use cases to be addressed, as identified and defined in [MMMAG15-D11] and shown in Table 2-1.




mmMAGIC Public 9

Table 2-1 Use cases to be considered for 5G archite cture

Explanation of deployment: O: outdoor, I: indoor, O-I: outdoor to indoor, I-I: indoor to indoor

The functional blocks, architectural elements and enablers to be designed in mmMAGIC have to meet the technical requirements and fulfil the KPIs of these use cases. At this point, it should be noted that these use case definitions mainly represent services to be provided, partially related to one or more specific deployment scenarios. These use cases do not necessarily reflect a specific network architecture. However, we aim at defining an architecture with elements scalable and adaptable to meet the requirements of all relevant use cases.

The use case 8 seems to be one of the most challenging cases. Therefore, we limit the requirements to the main goals of Tactile Internet i.e. the reliability and latency from Table 2-1. The solutions shall be applicable in environments with controlled conditions e.g. factories, squares (free-space). The consideration contains a couple of machines with small distances to the Access Points. There is no necessity to provide high throughput requirements while the machine type communication is considered. The relation between considered use cases and envisioned typical propagation case is shown in Figure 2-1.

Broadband

access

everywhere

High user

mobility

E-real time

communication

and

Ultrareliable

Use Case 1 Use Case 2 Use case 3 Use case 4 Use Case 5 Use case 6 Use case 7 Use Case 8

Media on

demandCloud services

Dense urban

Society with

distributed

crowds

Smart Office

Immersive

early 5G

experience in

tagrgeted hot-

spots

50+Mbps

everywhere

Moving Hot

Spots

Tactile internet

/ Video

augmented

robotic control

and Remote-

robot

manipulation

surgery

User Data Rate in

DL [Mbps]15 300 25 (up to 50)

1000

(average load

0,2 Gbps/user)

100 50 50 50

User Data Rate in

UL [Mbps]Very low 50 50

500

(average load

0,027 Gbps/user)

50 25 25 1

Connection

density

[user/km2]

4000 250030000 (with

peaks of 150000)75000 10000 400-2500 2000 330

Traffic Density

DL/UL

[Gbps/Km2]

60 750 / 150peaks :

3750/750015000/2000

1700 / 850 per

hotspot area

(0,1km²)

28/14 100/50 16 / 0,32

mobility [km/h]

Stationary

/

Pedestrian

100

Stationary

/

Pedestrian

Pedestrian

Stationary

/

Pedestrian

Pedestrian to

50Km/h30-500Km/h

Stationary

/

Pedestrian

Availability[%] 95 95 95 95 95 95 95 99.999

Reliability[%] 95 95 95 95 95 95 95 99.999

Latency [ms] 50 10 10 10 10 10 10 1

Deployment O-I All All O-I and I-I O-I and I-I All All I-I and O-I

Broadband access in dense Areas




mmMAGIC Public 10

Figure 2-1 Relation between considered use cases de fined in Table 2-1. The colours indicate

whether the use case is considered for outdoor (O, blue), indoor (I, yellow) or outdoor-to-indoor (green, O-I).

2.2 Test scenarios for system evaluation A “test scenario” defines the physical properties of the environment where the end users are located when having particular services. It therefore describes the practical aspects seen from an end user’s perspective in a 3D environment. Hence, each test scenario contains a set of assumptions, constraints and requirements. A use case may cover several concrete test scenarios; a test scenario may also belong to several use cases.

Test scenarios can be roughly grouped into outdoor, outdoor-to-indoor and indoor. A more detailed description of the test scenarios contains building arrangements and densities or wall structures in indoor scenarios. The test scenarios envisaged to be used by mmMAGIC have been derived in other projects like WINNER-I and -II [WIN1D7.2], [WIN2D6.13.11], METIS [MET13-D61] or are defined in 3GPP recommendations [3GPP TR 36.931]. These test scenarios describe different characteristic environments for the provision of services.

Among the outdoor scenarios typical representatives are Madrid grid, Manhattan grid, Asian city grid or simplified Madrid grid. “Manhattan grid” is the strictly regular building placement on a rectangular grid, representing a dense urban area [BWR14]. “Madrid grid” [MET13-D61] is an urban environment model that consists of buildings which are not as homogeneously placed as in the very regular “Manhattan grid” and comprises also elements like metro entrances, bus stops free squares and more. This more realistic building layout better captures e.g. real life

Movinghotspots(O, O-I, I)

50+ Mbpseverywhere

(O, O-I, I)

Dense urban society

(O, O-I, I)

Tactileinternet(O-I, I)

Immersiveearly 5G

experience(O-I, I)

Cloudservices(O, O-I, I)

Smart office(O-I, I)

Media on demand

(O-I)

higher datarate

conn

ectio

nde

nsity

mobilitylo

wde

lay,

hi

ghre

liabi

lity

outdoor (O)

out – indoor (O-I)

indoor (I)

color code




mmMAGIC Public 11

behaviour of users in motion, diversity of SINR distribution or heterogeneity of cellular network deployment. There is also a proposal for “simplified Madrid grid” which does not model all of the “Madrid grid” elements (e.g. the building entrances, bus stops, traffic lights are not included). “Asian city grid” is a dense urban model with higher density and larger spatial extension than “Madrid grid”. It contains non-homogenously placed buildings with varying sizes. In addition, it also contains a downtown region with high-rises. This gives a larger diversity of the propagation environments allowing for both outdoor and outdoor-to-indoor scenarios.

Typical indoor scenarios are e.g. virtual reality office, shopping mall or other suitable scenarios. “Virtual reality office” environment covers multiple offices within a building and explicitly contains walls, screens, desks, chairs and people [MET13-D61]. More simplified and strictly regular approaches are proposed e.g. by WINNER-I [WIN1D7.2] and 3GPP [3GPP TR 36.931]. “Shopping mall” models an indoor area with shops and passage ways between them [MET13-D61]. “Stadium” is a scenario reflecting a dense crowd scenario [MET13-D61]. The environmental model comprises a space of about 50000 m2, with roofed and tiled spectators’ platforms and a playground in the centre.

For mixed outdoor/indoor evaluation one possible test scenario is the so called dual-stripe. Such a scenario is also used in 3GPP [3GPP R4-092042]. Graphical outlines of the different test scenarios can be found in the given references and in Annex B of this document.

2.3 Envisioned deployments and traffic model assump tions A deployment is the characterization of the network layout (i.e., physical and logical locations). This comprises BS and UE densities, propagation characteristics, and cell sizes. In addition it also covers RAN configurations like antennas, Tx power, frequency band, bandwidth, system features and supporting architectural solution. It also comprises the two basic modes of operation, standalone operation (indicated “without low band support” in the following text) and operation supported by a simultaneous connection with a low frequency band, e.g. LTE or 5G low band system (indicated as “low band support”).

The classification of the large scale deployments according to the classes “rural, suburban, urban, dense urban” and also “urban macro / urban micro” leads to geometrical extension of cells, related number of users and expected propagation properties. It reflects mainly statistical parameters and results.

We want to analyse architectural impacts of deployment of the different use cases within the different test scenarios as described in the previous section. The goal is to derive the network architecture needed for different use cases, and to identify the related requirements for the network elements and the interfaces and way of interaction between them. Therefore, detailed assumptions on BS and UE locations, cell sizes, backhaul capabilities and structure, UE mobility and traffic types need to be taken into account.

In the following, the addressed test scenarios and deployments are shortly described per use case. Based on the intended scenarios, the backhaul requirements will be derived in the subsequent section. A more detailed presentation of the deployments can be found in the Annex A.

Use case “50+ Mbps everywhere” is considered as a baseline use case. It is the starting point from which on the capabilities of mm-wave access and backhaul will be explored. Therefore, various outdoor, outdoor-to-indoor and indoor access and backhaul scenarios are in the focus, with and without low band support. Typical deployments are macro-like cellular with ISD of 50 m up to 250 m, as well as small cells and relay approaches. Also centralized baseband processing with distributed antennas, fronthaul links, low band support by co-located and non-co-located BS are specific architectural flavours to be analysed. Beamforming at BS and UE, random UE location and full and finite buffer traffic models are assumed. With this use case the baseline capabilities of mm-wave systems will be assessed. Further, cell-edge throughput, mobility management, capability and impact of low band support, and Hybrid Automatic Repeat




mmMAGIC Public 12

request (HARQ) latency reduction are some of the basic system parameters which will be assessed.

The use case “Dense urban society” extends the capability of the baseline use case towards higher user density. Outdoor and outdoor-to-indoor scenarios with and without low band support are considered. Cellular dense deployments with ISD of tens of meters up to 100 meters, random UE location, beamforming at BS and partially at UE, no or low mobility and full buffer traffic will be investigated. One major focus of this use case is the inter-node interference coordination.

The use case “Media on demand” covers the outdoor-to-indoor scenario with and without low band support. A cellular deployment with about 200 m inter-site distance (ISD), large antenna array at BS and uniform UE distribution with low mobility (3 km/h) is envisaged. FTP traffic model will be considered. The focus of investigation is on verification of high area capacity.

Use case “Cloud services” focuses on outdoor and outdoor-to-indoor scenarios with and without low band support. Cellular dense and ultra-dense deployments with cell sizes between 50 m and 200 m ISD, antenna arrays at BS and UE, uniform UE distribution without mobility and full buffer as well as finite buffer traffic models will be investigated. Multi-connectivity capability is assumed. For backhaul the mm-wave band at 73 GHz will be used to analyse coverage and performance. Main focus is on requirements for increase of capacity and throughput.

Use case “Smart office” is an indoor access scenario with cellular ultra-dense deployment of small cells, beamforming capability at BS and UE, and limited mobility. Focus is on cell-edge throughput maximization and delay minimization.

Use case “Immersive early 5G experience” is an outdoor scenario with low band support and ultra-dense small cells. Beamforming at BS and UE and no mobility is assumed. Focus is on high rate experience in a hot spot like environment supporting also high user density.

Use case “Moving hot spots” addresses a specific case of outdoor backhaul deployment with low band support and involving relay structures. It extends the baseline scenario towards mobility.

Use case “Tactile internet ” is related to access indoor/outdoor scenario with or without low band support, mainly addressing small cells with high reliability and low latency.

2.4 Requirements derived from use cases, deployment s and traffic assumptions

2.4.1 High level requirements From a high level view, the mmMAGIC RAT must support higher frequency bands and wider contiguous bandwidths than in current LTE systems. Further, it is required to support very dense deployments, energy efficient deployments, and extensive use of multi-antenna schemes with large antenna arrays to realize high gain beamforming and massive MIMO schemes. In addition, new mobility handling features are required to support seamless frequent handover among the small mm-wave cells of a dense deployment, also reflecting the specific channel behaviour due to the sudden blocking events by user body or moving obstacles disturbing the mm-wave channel. Ideally, the transmissions should be self-contained, i.e., it should be able to transmit in time and frequency dimension relying only on reference signals within this transmission subframe together with the corresponding user data. Besides this, where beneficial, mm-wave systems should be able to make use of low band communication systems (new 5G RAT operating in frequency bands below 6 GHz or LTE-A) to make initial link setup, synchronization and mobility




mmMAGIC Public 13

handling more efficient and fast. So, the mmMAGIC project will consider two modes of operation for the mm-wave access systems: standalone and non-standalone operation (see: Section 2.5.1). Strict timing relations across subframes should be avoided. These requirements would allow for more flexibility in resource allocation and TDD frame structure, thus supporting ultra-lean transmission to minimize always-on transmissions. The need to support lower latency requires shorter and more flexible TTI structures, leading to new numerology and frame structure. The main benefit of avoiding strict timing relation is the support of multiple functional splits under non-ideal backhaul conditions. Enhancements to better support new use cases such as Machine-Type Communication (MTC) scenarios including Vehicular-to-X (V2X, where “X” stands for anything, e.g. can be V for Vehicle or I for Infrastructure) should also be considered.

2.4.2 Requirements specific for access in standalon e mm-wave systems

Standalone mm-wave systems must be able to be deployed and operated without the need of any fundamental support from another access technology or system on RAN level. They should also provide means for coordination between multiple APs, so as to reduce the interferences that are likely to be seen in ultra-dense network deployments.

2.4.3 Requirements specific for access in non-stand alone mm-wave systems

Non-standalone mm-wave systems make use of RATs in the lower frequency bands, like LTE-A or 5G low band systems. Ideally, these RATs benefit from the co-deployment for both co-sited and non-co-sited deployments. Preferably, the system would even work without necessarily having awareness on co-siting or non-co-siting of the cooperating RATs. Thus, even if the mm-wave RAT is deployed as non-standalone, it should be able to operate standalone without the need to redesign the architecture.

Further, the non-standalone RATs should also allow for fast seamless and reliable mobility and aggregation handling between the RATs, with efficient management and pooling of resources for optimum performance performed by help of the lower frequency band coverage layer. Therefore, a UE needs the capability to provide two types of measurements, i.e. on the lower frequency and mm-wave frequency, to support a UE assisted, but network controlled handover procedure.

The initial access could be either supported through low frequency systems such as LTE-A or another 5G low band system, or through the mm-wave RAT itself. The decision will be done depending on the device capabilities, availability of low band system and deployment; e.g. highly mobile UEs in outdoor deployments may have significantly better coverage to the low-frequency bands and will advantageously use that as an anchor point before accessing the high capacity mm-wave systems.

The mm-wave RAT should support quick deployment for both stand-alone and non-standalone cases, requiring minimum planning/configuration and optimization complexity. They should support operation in licensed, unlicensed and licensed shared spectrum, both TDD and FDD1.

The mm-wave RAT should also try to minimize broadcast signalling (e.g. System Information Blocks, SIBs) and the usage of cell specific reference signals and other cell specific signalling

1 Due to the fact that FDD needs specifically paired frequency bands and is thus less flexible, the priority will be on TDD.




mmMAGIC Public 14

in order to reduce interference, power consumption and to maximize the possibility to perform beam-forming (requirement also partly supported by NGMN [NGMN15]).

They also should be able to support a very high density of access points, allowing the presence of long fronthaul links in centralized deployments without impairing HARQ performance.

2.4.4 Design requirements for backhaul The design requirements for backhaul (BH) on planned use cases could be derived based on the specific requirements for access side of the network and planned deployment of the radio system. In this section, we list the required information needed to calculate backhaul requirements and selection of backhaul type (dedicated or self-backhaul). In the Table 2-2, we show the basic and most important access parameters and deployment information needed to derive the specific backhaul requirements.

Table 2-2 The Access requirements and parameters re quired for derivation of BH requirements Access Requirement or Parameter BH Requirement or Parameter

Average DL data rate per AP [Mbps] Average BH data rate [Mbps]

Peak DL data rate per AP [Mbps] Peak BH data rate [Mbps]

Average UL data rate per AP [Mbps] Average BH data rate [Mbps]

Peak UL data rate per AP [Mbps] Peak BH data rate [Mbps]

Latency [ms] BH latency [ms], Number of Hops

Reliability [%] BH Reliability [%], Number of Hops

Availability [%] BH Availability [%], BH redundancy

Access Deployment type [O2O, I2I, O2I]

BH type [dedicated wireless, self-BH, dedicated fiber] – depends on scenario

The listed parameters are only basic requirements needed for derivation of backhaul design parameters. Other relevant parameters are: available frequency bands, spectrum regulations and access mobility requirements, which are important to derive backhaul link switching requirements. Another group of parameters comprise access deployment details like number of sectors, antenna height, Tx and Rx parameters. Available MCS levels are needed for self-BH dimensioning, and traffic types will also have impact on the backhaul requirements.

2.4.5 Requirements for air interface This section contains preliminary considerations on how the physical layer requirements, will be derived from the backhaul and access requirements. They can be grouped according to requirements depending on use case, depending on deployment scheme, and depending on hardware capabilities. However, detailed quantitative values for these requirements can only be derived when investigating the detailed system approaches. With respect to use case dependent parameters , the requirements have to be derived for the number of simultaneous users to be supported, throughput and data rate in DL and UL, signal bandwidth, access latency and availability.

Deployment scheme dependent requirements are related to support for frequency coordination and reuse to be able to deal with co-channel interference in multi-cell deployment. Further, the support for multi-hop backhaul gives requirements for latency and efficient and flexible resource management. Delay spread and channel variation due to different mobility assumptions must be handled and therefore lead to specific air interface requirements.




mmMAGIC Public 15

Requirements will be derived also related to the flexibility of the PHY layer with respect to multi-carrier parameter values. It is considered to support multiple subcarrier spacing and variable symbol length adapted to the propagation scenario, to operate at highest possible spectral efficiency in different deployments. Finally, requirements for multi-antenna schemes need to be defined.

Since it is foreseen that the mm-wave RAT will accommodate high gain beamforming at the APs and UEs, efficient initial access schemes are required to reduce the overheads. Another important requirement for standalone operation is the mobility management. High beamforming gain, fast beam-tracking, scheduling as well as handover between APs are needed to support use cases with high requirements in availability and reliability.

With respect to hardware capabilities , most important requirements address the support of advanced receivers and the level of computational complexity and latency. Requirements for power consumption to achieve longer battery life, as well as overall energy efficiency of the system, will be derived.

2.4.6 Requirements for multi-antenna transceivers In this Section the requirements for multi-antenna transceiver technologies are presented. These requirements need to be derived from the requirements discussed in the previous sections.

The mmMAGIC RAT should be able to work with different antenna types, e.g. omni-directional antenna patterns, low/high gain beam forming antenna pattern, flexible/fixed beam forming pattern, and analog/digital/hybrid beam forming, depending on the use case and deployment scenario. It is assumed that channel reciprocity can be exploited where beneficial.

For the different antenna types, relevant transceiver parameters are achievable gain, dynamics of beam forming to support mobility, transmit power, receiver sensitivity. Robust beamforming algorithms are required to deal with hardware imperfections and/or estimation errors. Beamforming schemes should allow good area coverage.

2.5 Design principles for architecture Before presenting specific solutions for the architecture and integration the generic 5G architectural prerequisites are defined:

• The system will need to be future proof in terms of extendibility, modularity and adaptability

• There is a requirement to be flexible in business scenarios and value chains: an option for administrative domains with reference points in-between

• It must fit into a diverse set of deployment scenarios

• Support of heterogeneity (multi-vendor networks); and leave room for vendor-specific innovation and product differentiation

• Support for local / low latency “mobile” services requires the capability to relocate access gateways and optimize the service topology

• Support for a variety of different deployments in terms of services (e.g. IP, MEF and 802.xx Ethernet; local, central, data centre), transport networks (e.g. LAN, WAN, IPv6, MPLS, Carrier Ethernet) and number of administrational domains (user, access, transport, service, application) requires architectural flexibility (e.g. multi-protocol, function virtualization)




mmMAGIC Public 16

2.5.1 Design to support both standalone and non-sta ndalone mm-wave system deployments

The 5G network deployment and integration work planned for the mmMAGIC project will be considered for two operation sets: standalone and non-standalone operation of the mm-wave RANs as shown in Figure 2-2.

In the standalone scenario, the mm-wave RAT will only use mm-wave frequencies and the deployment of Access Points. The deployment of one (5G) RAT operating both low-band and high-band carrier, where high-band carrier need low-band carrier for operations, for purpose of studies in this project is considered as non-standalone deployment even if it is a single-RAT deployment. In standalone deployment AP coordination will be optimized to mitigate coverage and mobility issues related to the mm-wave propagation. For example: methods will be proposed to organize mm-wave cells into dynamic cell clusters where the APs included in the cluster may be updated during UE mobility. The proposal will be complemented with new network functions and logical elements to manage such cell types.

In contrast, the non-standalone scenario will utilize joint deployment of mm-wave nodes with nodes operating at lower frequencies (in the form of multi-RAT APs or neighbouring APs of different RATs); to propose deployments, which fulfil requirements for the selected use cases. Note that joint deployment means overlapping coverage, not necessarily co-located nodes”. The non-standalone deployments will be used to evaluate solutions for full integration of various RATs performed in the lower layers of the network protocol stack.

Operation mode Work on solutions for Standalone mm-wave access with multi-link and opportunistic serving

deployment and relations optimization for overcoming spotty coverage and mobility issues.

Non-standalone mm-wave access, lower frequency assisted

utilize joint deployment of mm-wave nodes with nodes operating on lower frequencies.

Figure 2-2 Two primary modes of network operation s tudied in mmMAGIC and exemplary problems to solve for each mode

The mm-wave system should be designed as a single logical architecture that can be deployed as either standalone or non-standalone, where it is capable to fully operate without any fundamental support from legacy systems but will benefit from co-deployment with e.g. LTE-A or low-frequency 5G RAT. If the system is primarily designed to operate as non-standalone, it




mmMAGIC Public 17

may preclude the operation in areas where there is no legacy radio technology, or for an MNO that does not possess any legacy cellular network. For non-standalone deployment, the latencies associated with first connecting to the low frequency RAT before accessing the high throughput mm-wave RAT might be too large to fulfil service requirements. As the likely limitation for the mm-wave frequencies will be the limited coverage, especially at the higher frequencies in scenarios with rapidly varying propagation conditions due to device mobility, rotation, or blockage, the system may require support from lower frequency RATs e.g. LTE-A or low-frequency 5G RAT to ensure connectivity and system access. However, in the absence of low frequency support, the mm-wave RAT needs to be able to provide system access and connectivity and the design of the logical architecture should be flexible enough to allow both deployments and be able to utilize the benefits of co-deployment. Naturally, if the mm-wave coverage is reduced, the connectivity may only be provided within a limited area, with possibly increased latencies associated with initial access and mobility which should be taken into account when deploying the system. The system need to be able to accommodate a wide range of 5G scenarios to allow e.g. ubiquitous coverage with energy efficient connectivity to fulfil the identified requirements and KPIs of the use cases. For instance, the stringent latency requirements may need a reduced and more flexible Transmission Time Interval (TTI) to be able to achieve the short round-trip times.

2.5.2 Efficient control signalling to support syste m access and mobility

In order to support very dense, energy efficient deployments relying on beam forming, legacy limitations regarding e.g. CRS or common downlink channels will need to be revised – e.g. one of the possibilities could be refraining from transmitting CRS. For instance, as the frequency range for the RAT design in this project spans from 6–100 GHz - in some deployments, different AP within the same network operate at different frequency bands. In such cases, some UEs may be connected to multiple frequencies simultaneously. It would be very inefficient if the CRS were transmitted across the entire deployed frequency range. Instead, a more efficient way would be to include the CRSs or corresponding reference signals and control channels with the UP data and have self-contained transmissions. As the transmissions would likely be beam-based, most of the time only the beams serving the affected UE would carry these control signals. In order to minimize the energy consumption and interference, the always-on broadcasted common signals should be avoided, and the control signals should be primarily dedicated. For initial access, before the UE have connected to the network, it may necessitate some level of broadcasted information to determine how the UE can access the network and receive dedicated signal. More details on this topic will be covered in following sections.

The operating frequency of the mm-wave RAT is significantly higher than legacy systems, and will rely more heavily on beam forming where the benefits of broadcast signals are less pronounced. In the non-standalone deployments, certain system information may be preferably transmitted over the lower frequencies to ensure prompt and reliable reception at the UEs. However, as the system needs to be able to operate standalone without support from systems at lower frequencies, all control information need to possibly be transmitted over the mm-wave RAT. In this case, the control information should preferably be transmitted as dedicated signals to each UE to avoid omnidirectional broadcasting inducing significant interference. Nevertheless, the UE needs some ways to access the system and determine the optimal beam, both during initial access and during UE mobility. To foster future-proofness, the mm-wave RAT should avoid hardcoded timing constraints on the transmission (e.g. like HARQ RTT) as this will limit the flexibility to optimize the usage of those resources.

In LTE, the system access was obtained by monitoring the PSS/SSS, CRS, and decoding the MIB/SIBs. However, these signals were periodically broadcasted by all eNB regardless of whether there is any traffic through that eNB, which will be inefficient in a beam-based solution. In addition, for mobility, the UE monitored CRSs of the neighboring cells to determine when to perform handover. In a beam-based solution the mobility may require the neighboring APs to provide dedicated transmission to the UEs to foster the channel evaluation need for handover




mmMAGIC Public 18

procedures. Additionally, as the mm-wave RAT shall support operation in very different frequency band, between 6–100 GHz, it will be necessary to distinguish which frequencies the UE shall consider accessing as it is not feasible to continuously monitor bands in before mentioned range allowed for licensed/unlicensed/lightly-licensed usage for mobile communications.

When designing the mm-wave system, there are several issues that need to be settled and we will evaluate (among other things) the following:

• What signals will be used to support system access? (In LTE-A we have PSS/SSS, C-RSs, MIB/SIBs.)

• What signals will be used to support mobility / connection control? (In LTE-A we have C-RSs for neighbour cell measurements.)

• In which ways will beamforming change the design of these signals?

• In LTE, these signals are broadcasted all the time, how will these signals be designed for the mm-wave system.

• Will these signals be transmitted all over the bandwidth? What about leaving empty spaces for future-proofness?

2.5.3 Network slicing It should be possible to deploy multiple simultaneous logical end-to-end network slices, each managed as an independent network by the slice owner serving one or several specific use cases and each using the same infrastructure. In the radio access, the different slices will support dynamic usage of the shared resources in an efficient way (see Section 4.1).

2.5.4 Synchronous and asynchronous functions distin ction When designing the mm-wave system it will be important to distinguish between synchronous and asynchronous functions and their impact on the system, e.g., scalability and the implication of where in the network the functionality can be implemented. For instance, the mm-wave RAT will benefit from connecting network nodes through excellent backhaul (e.g. dedicate fiber /lambda) which enables latency-free coordination between the nodes but it must also work with non-ideal backhaul between the nodes (which introduces latencies or jitter). There should be gradual performance degradation as a function of transport quality on the backhaul so that the system can benefit even from a moderate connection.

2.5.5 Device capabilities signalled from the CN As the different use cases have very varying requirements regarding e.g. capacity, mobility, latency, and device density, the device complexity will be very varying and will be optimized for different scenarios (e.g. high throughput, low battery consumption, high reliability). The information about the device capabilities is assumed to be signalled to the mm-wave RAN from the core network or the UEs. If the mm-wave is deployed as non-standalone with low frequency support, the information could also be relayed by the RAN through the low frequency eNB.




mmMAGIC Public 19

3 Integration for 5G networks

3.1 Scope of integration and architecture work The main objective of this deliverable is to study solutions aiming at the integration of the mm-wave system with the rest of 5G ecosystem – operating both new and legacy radio interfaces. In order to have a clear understanding of what these studies refer to, in this section we clarify what integration (or “tight integration”) means to us and how it is different from state-of-the-art e.g. in 3GPP LTE-A. In this deliverable we are not investigating the overall architecture but mostly focusing on the RAN part, i.e. what corresponds to E-UTRAN part in SAE Architecture [3GPP TS 23.401], depicted in Figure 3-1. The following sub-sections indicate our considerations on CN and RAN split – which might be helpful for understanding which functions we would like to investigate.

Figure 3-1 SAE Architecture

3.1.1 Division between RAN and CN Diversity of use cases and requirements lays a foundation for most studies that are being done in mmMAGIC project. This perspective for 5G is also claimed by relevant organizations paving the way for 5G such as NGMN [NGMN15], 4GAmericas [4GA14].

It is initially assumed that the split between the core network and the RAN will be similar to that of LTE-A, where the services and functionalities of each can evolve independently to introduce new features to speed up technology progress and time-to-market. Any modifications and differences to the mentioned split, are subject for the studies in this and other related projects. The split has been enabled through a standardized interface (S1*) which among other things allow for multi-vendor inter-operability. Figure 3-2 shows the architecture of the CN/RAN split, where the mm-wave RAT can be deployed as standalone or collocated with LTE-A and use the same standardized interfaces S1* and X2* as LTE-A.

S1-C

eNB

S1-U

Serving Geteway

PDN Gateway

HSS

MME

S5 SGi

S1-U

S1-C S11

IMS/InternetEvolved Packet Core

(EPC)

Radio Network

(E-UTRAN)

eNB




mmMAGIC Public 20

Figure 3-2 CN/RAN split architecture for mm-wave RA T as standalone and non-standalone using

same interfaces as LTE-A

For support of mobility in Ultra Dense Networks (UDN) environment and for special services such as mobility on demand (see Section 4.5.6) the division between RAN and CN might be modified and some functions related to mobility might be delegated to local controllers located logically in the RAN. Similarly, UE context storage might be revisited and located in the RAN part closer to UE.

3.2 The state-of-the-art integration based on hard-handovers between the RATs

The state-of-the-art integration between different RATs is currently based on hard-handovers between the RATs, where the UE selects access based either on some signal based metric (e.g. signal strength) or traffic load. The same technique could be used to integrate the mm-wave RAT with other RATs, such as low frequency 5G systems or LTE-A. The UE would then select whichever access provides the best instantaneous service and fall-back to the low frequency RAT when the mm-wave connection is lost. Figure 3-3 is a schematic picture of the protocol stacks of inter-RAT hard handover between LTE-A and the mm-wave nodes which means that the user connection is either over LTE-A or mm-wave.

The connectivity solutions such as Dual Connectivity in LTE-A makes this system open for inter-RAT integration on PDCP level, however in practice Dual Connectivity is not used to integrate LTE-A with other RATs due to lack of other compatible system. This might change when there will be 5G deployed (if only 5G will be able to exploit potential of integration with LTE-A using existing or evolved dual connectivity).




mmMAGIC Public 21

Figure 3-3 The mm-wave and LTE-A protocol stacks. T he inter-RAT handover is being done on

CN level (out of scope of this figure showing RAN p art)

3.2.1 Drawbacks of the integration based on hard-ha ndovers between the RATs

There are a number of drawbacks with the hard handover. The major drawback is the rather long delay and service interruption, for instance during varying channel conditions. The hard handover delay depends on various parameters, for instance cell search and synchronization time as well as the extensive RRC signalling required. The amount of signalling between CN and RAN can be also significant. As the mm-wave system will be beam-based, the time required to find a suitable beam may be longer compared to today’s situation as there is no coordination between the RATs prior to the hard handover. Another drawback with inter-RAT hard handover is the rather low reliability as well as Ping-Pong effect to achieve optimal resource utilization since the mm-wave channel quality is expected to dynamically vary.

3.2.2 Motivation to design new, more efficient sche mes for integration

Even if it would be possible to integrate new 5G RATs with LTE-A using existing mechanisms for integration, tight requirements for the envisioned use cases are the motivation to rethink and design new, more efficient schemes for integration that will not have abovementioned drawbacks. These requirements will likely drive an integration of 5G RATs with the evolution of LTE-A in a RAN level e.g. via the usage of common RAN protocols such as RRC and PDCP [SMJ+15]. Full details on the possible level of integration are still under study. As part of integration work, it is important to group / map different features such as mobility or system access into network elements and design logical and physical interfaces between them. Apart from the actual design, we will aim at providing requirements for the interfaces impacting air interface, multi-antenna and transceiver design.




mmMAGIC Public 22

3.3 Integration as a remedy for challenges coming f rom 5G requirements

The new use cases with demanding requirements drive changes in the RAN architecture to boost network performance in different dimensions compared to the current systems. The challenges for architecture evolution from LTE-A to 5G might be grouped in three main directions depicted in Figure 3-4: (1) providing network capabilities for new services; (2) Managing complex ecosystem of different radio technologies; (3) Keeping the flexibility and configurability for any emerging services in the future. The subsection 3.3 serve as reference – provides information which parts of the deliverable address each of three identified directions of challenges.

Figure 3-4 Three main directions of challenges for architecture evolution from LTE-A to 5G

3.3.1 Enabling network capabilities adequate to ful fil 5G use cases requirements

In order to provide proper network capabilities in terms of data rate, latency, reliability and support for handling many devices, in mmMAGIC, we investigate flexible split of RAN functions among network nodes; RAN functions are grouped into network protocol layers and protocols organized in the stack. In Section 3.4 baseline protocol stack is presented. Several sections e.g. Section 4.2 (on potential modifications in protocol stack) or Section 4.4 (on clustering of mm-wave cells) discuss potential distribution of network layers among different network elements.

We also envision emergence of smart edge nodes, where nodes can actively carry out some of the core network functionalities or additional services such as caching. Examples of such integration are shown in Section 4.5.6.

3.3.2 Managing Ultra Dense Networks and providing s ufficient backhaul solution

If the Network Slicing approach will be implemented as part of network architecture, the management of the network can focus on different aspects when compared to today’s networks - there will be a network management based on logical instead of physical resources, see: Section 4.1). The change in approach to network management will bring a need for new flow of the management information in the network. The management and orchestration part of the network will need information from RAN part of the slices in order to control network function. Embedding unified and configurable means of reporting measurements, counters, KPIs, super KPIs (derived from multiple lower-level KPIs) will make managing such a complex network feasible (more on Network slicing in Section 4.1).

4G Ultra dense Network 5GFlexibility

Network capabilities

Network

management

Backhaul




mmMAGIC Public 23

Apart from complex network management, the Ultra Dense Network comes with the challenge of proper backhaul provision i.e., transport solution that will suffice to handle various use cases while being at the same time feasible from the cost and deployment perspective. In paragraphs below, we study self-backhauling related challenges.

The first group of challenges are related to general Radio Resource Management (RRM). One major challenge that can arise is to obtain the optimal resources distribution between the access and backhaul links ensuring that the resource allocation will be also non-conflicting. In self-backhauling, the available resources must be multiplexed in time and frequency, to avoid any interference between the two links — designing such efficient systems can be a major challenge. Part of the resource management tasks is done via scheduling. In the context of self-backhauling, it is important to decide on type of scheduling: centralized or distributed. In case of centralized scheduling, the scheduling decision for the individual UE are made at the central scheduling entity, that is transparent to the donor AP and sBH node. In this case, the backhaul and access links are centrally scheduled. For the decentralized scheduling decisions for individual sBH nodes are made by the scheduling entities that are transparent to the donor AP, while the individual access links are controlled by the sBH nodes

The maximum number of supported hops in targeted scenarios has important impacts on self-backhauling design. When considering the design, installation and network planning of the sBH access points, it becomes necessary to consider the determining factors for the number of hops between the sBH points and proper network planning to consider the optimal route to the UE in case of multi-hop architecture becomes important.

In terms of architectural modification: will need to consider the visibility of sBH nodes to the core network and define some new functions to the existing protocol stack. Also it is important to consider the mobility aspects influencing backhauling, e.g. the handling of IDs for moving cells, hand-over from one sBH node to another.

3.3.3 Design of flexible RAN architecture RAN architecture should be designed in such a way that it supports different network and transport topologies ranging from ideal backhaul deployments with optimized centralized processing to non-ideal backhaul or self-backhauling with distributed architectures. In addition the architecture should also support the possibility to co-locate RAN and CN functions e.g. to optimize the latency for specific use cases. Some of these network functions are expected to be deployed as VNFs (Virtual Network Functions). The architecture should also support network slicing (see: Section 4.1) as a way of supporting new use cases or business opportunities with optimized slice-specific network functionalities.

3.4 RAN architecture This sub-section gives a high-level overview of the protocol stack design and logical architecture for the 5G system operating in 6–100 GHz frequency range. The protocol stack presented in 3.4.1 is further discussed in Section 4.2 “Review and redesign of the protocol stack for the milimeter-wave integrated system”.

3.4.1 Protocol stack for 5G system The protocol stack presented in this section is in line with protocol stack defined for LTE-A [3GPP TS 36.300], however we study modifications and extensions needed for the mm-wave system. We assume that most of our readers will be familiar with terminology used in LTE-A therefore, for the ease of understanding, we are using the similar terms for the protocols and interfaces wherever possible. There is no doubt that modifications and extensions to existing protocols will be needed thus we introduced “star notation”, i.e. we marked with star (asterisks




mmMAGIC Public 24

character) the protocols and interfaces that are to be extended when compared to their LTE-A equivalents. As an example, PDCP* denotes modified and extended PDCP protocol.

User plane The user plane protocol architecture for 5G is depicted in Figure 3-5. It is the same for all different radio interface solutions.

Figure 3-5 User-plane protocol stack

For 5G networks, the LTE-A PDCP functionality might need an extension. Similarly as in LTE-A PDCP, the (5G) PDCP* should perform header compression, ciphering and be responsible for in-sequence delivery to upper layers. The PDCP* should additionally provide multi-connectivity anchoring. In the overall radio protocol architecture, the PDCP* layer acts as a multi-connectivity anchor - thus is providing functionalities as traffic routing, splitting and duplication depending on the configuration obtained from higher layers. PDCP* has also another envisioned extension comparing to LTE’s PDCP : ability to receive feedback from the lower layers of each multi-connectivity leg that allows the PDCP* to determine how much traffic can be handled by each multi-connectivity leg – this might include need for new KPIs reported from lower layers.. In overall RAN protocol architecture PDCP* is a key element responsible for RAT integration since it can become the common user plane protocol for all RATs tightly integrated in a common 5G architecture. The location of PDCP* can be optimized based on operators transport network and RAN deployment. Below PDCP* protocol layer there exists a common RLC* protocol layer specification for all radio interfaces . There are no radio interface specific functions; however, certain parameterization may be radio interface specific, i.e. certain parameter values may e.g. not be possible for certain radio interfaces.

There is also a common MAC protocol layer specification for all radio interfaces. However, certain functions and parameters can be radio interface specific functions, i.e. certain function or parameter values may e.g. not be possible for certain radio interfaces.

Control plane The control plane protocol architecture for 5G is depicted in Figure 3-6 and it is the same for all different radio interface solutions. The NAS* protocol provides non-access stratum between a UE and it is controlling MME. NAS* can be separated into network access control and service control function. NAS* messages are transferred between a UE and the core network by RRC messages.

UE 5G-NB

PHY

MAC

RLC*

PDCP*

PHY

MAC

RLC*

PDCP*




mmMAGIC Public 25

Figure 3-6 Control plane protocol stack

3.4.2 Logical architecture of 5G network Baseline logical access network architecture of 5G system is following E-UTRAN design and consists of network access nodes (5G-NBs) as shown in Figure 3-7. This is a baseline, flat model – i.e. there is no central element.

Figure 3-7 Baseline logical architecture for 5G sys tem.

Besides flat architecture, the centralization for network virtualization, efficient mobility and other purposes should be also supported – two exemplary 5G architectures supporting network virtualization are shown in Figure 3-8 and Figure 3-9. In the baseline architecture 5G-NBs are connected via X2* interface. Nodes are connected to the core network via S1* interface. S1*C connects to the control plane part of core network – and it is terminated in MME. S1*U connects to the user plane part of core network – and it is terminated in S-GW.

Following three paragraphs briefly describes roles of network elements with the envisioned differentiation to LTE.

An 5G-NB provides users with the radio interface(s) and performs Radio Resource Management (RRM) functions such as dynamic resource allocation (scheduler), measurement

UE 5G-NB MME

PHY

MAC

NAS*

RLC*

RRC

PDCP*

PHY

MAC

RLC*

RRC

PDCP*

NAS*

5G RAN5G-NB

5G-NB

5G-NB

X2*

MME S-GW




mmMAGIC Public 26

configuration and provision, radio admission control, connection mobility control and interference coordination. Comparing to LTE’s eNB, 5G-NB can consist of one or more radios i.e. it can simultaneously serve cells operating on different air interfaces or even different RATs e.g. 5G-NB can serve 5G mm-wave and LTE-A cells.

The main control entity (MME) communicates with an HSS for user authentication and user profile download, and provides UEs with Mobility Management and Session Management functions using NAS signaling. The main functions supported by a MME are NAS signaling, User authentication and roaming, mobility management (paging, Tracking Area List management and handover management), and bearer management. Comparing to EPS (Evolved Packet System) MME, new functionalities such as support for “session on demand” or “mobility on demand” are considered [NOK15].

CN user plane (S-GW) terminates the interface towards a 5G RAN. It serves as the local mobility anchor point of data connections for inter-site and inter-RAT handover.

Architectural configurations supporting network vir tualization The 5G architecture should support virtualization of the network and implementation of cloud RAN. There is whole range of several potential levels of “cloudification” that spans from distributed scenario - where only CN is in the cloud, to centralized scenario where also RAN is in the cloud.

In the distributed scenario all radio protocols are collocated in 5G-NB and 5G-NB are connected to 5G packet core with standardized S1* interface and to neighbouring 5G-NB with standardized X2* interface. The transport network carrying the X2* logical interface is assumed to be non-ideal. In such case the RRC protocol is terminated in 5G-NB. In order to provide local breakout, the S-GW can be co-located with 5G-NB. The overview of the distributed scenario is shown in Figure 3-8.

Figure 3-8 Network virtualization: distributed scen ario – only CN is located in the cloud, full

radio protocol stack is located 5G-NBs.

In centralized scenario with RRHs all radio protocols are collocated in the 5G radio cloud and it may host multiple 5G-NBs. Local site is only RRH, which is connected with a CPRI-like (CPRI - Common Public Radio Interface) interface. The physical interface between Access Cloud and RRH is “ideal” fibre connection able to carry 5G physical layer signal. 5G-NBs in radio cloud are connected with standard S1* interface to 5G packet core. The centralized scenario is depicted in Figure 3-9.

5G-NB 5G-NB

X2*

MME S-GW

S1*U

S1*U

S1*C

S1*C

Evolved core cloud




mmMAGIC Public 27

Figure 3-9 Network virtualization: centralized scen ario (with RRHs). Core and Radio Access parts are in separate clouds. From the radio part i n Remote Radio Heads there is only RF

functionality located.

It is worth noting that protocol names depicted in access cloud in Figure 3-9 are following current LTE-A design and are serving as an example. The main message here is that in centralized case all radio protocols are located in the cloud and RRHs are handling only RF part. Between distributed and centralized scenarios, there are multiple possibilities for intermediate solutions characterized by different level of centralization – e.g. Layer-2 centralization is discussed in Section 4.4.2, where architecture for non-standalone deployment is being presented.

Access cloud

RRH RRH

MME S-GW

S1*US1*C

Evolved core cloud

RRC, PDCP, RLC,MAC, PHY

FronthaulFronthaul




mmMAGIC Public 28

4 Solutions (technology components)

4.1 Network Slicing 4.1.1 Introduction Network slicing is an important part of the NGMN’s vision for the overall 5G architecture [NGMN15] that addresses the deployment of multiple logical networks as independent business operations on a common physical infrastructure. The ultimate goal would be to provide “network slices on an as-a service basis” and to meet the wide range of use cases that the 2020 time frame will demand e.g., for different industries [E15]. The creation of network slices is mainly business driven and should also address the needs of different 5G use cases with highly diverging requirements. A network slice is envisioned to support the communication service of a particular connection type possibly with a specific way of handling control plane and user plane for this service. To this end, a “5G slice” could be composed of a collection of 5G network functions (NF) and specific air interface / RAT settings that are combined together for a specific use case and/or business model.

According to [NGMN15], [E15], a slice is seen from an end customer perspective or slice customer as an independent network. However, in contrast to deploying an independent network infrastructure, each slice will be realized together with other slices on a common infrastructure (also referred to as “virtual network”), also including assets such as licensed spectrum. In this way, the infrastructure and assets utilization will be much more cost and energy efficient compared to present realizations. The idea of the Network Slicing, main components and their relations are depicted in Figure 4-1.

The concept of network slicing has initially been proposed for the 5G core network (CN) [E14]. By exploring SDN and NFV principles, a fully virtualized CN instance optimized per business purpose could be defined. Some progress in the industry and standardization is ongoing in that area in parallel to research activities. Some of these aspects have been captured in 3GPP TR 22.891 [3GPP TR 22.891].

The concept is currently called by NGMN “end-to-end (E2E) network slicing” in order to take into account the overall system design, including the RAN aspects. This is somewhat underlined through statements in 3GPP such as “the network slicing primarily targets a partition of the CN, but it is not excluded that RAN may need specific functionality to support multiple slices or even partitioning of resources for different network slices”.

The work in 3GPP about the overall 5G system has recently been kicked-off with an approved study item in the 3GPP Working Group SA2 [3GPP TR 23.799]. The support for E2E network slicing appears as one of the key requirements. Even though the first 5G Radio Access Network (RAN) study items in 3GPP start in 2016 and despite the introduction of the notion of E2E slicing, it is still being elaborated what network slicing would represent e.g., to the RAN design, which comprise both network side and User Equipment (UE).




mmMAGIC Public 29

Figure 4-1 Network Slicing idea, main components a nd their relations [NGMN15]

Orienting from a single base architecture, network slicing involves using logical instead of physical resources for the generation of various network instances. Here, the slicing configuration, congestion and overload should not impact the other sliced networks. An advantage is that the network functions can have more closely shared radio resources, hardware and software resources, and offer the flexibility to allocate and reallocate resources according to specific needs. The performance of the network slice can be measured by a number of parameters which govern the coverage area, capacity, speed, latency, robustness, security and availability.

4.1.2 Impact on the RAN design To implement the functionality required for network slicing there are several baseline assumptions that can be made on the architecture and RAN design.

• Sharing: Most of the network resources in the 5G RAN are shared by multiple slices by default

• Differentiation: The 5G RAN enables mechanisms for per slice traffic differentiation

• Visibility: The 5G RAN should have the necessary visibility to apply slice differentiation

• Protection: The 5G RAN should provide protection mechanisms to minimize inter-slice effects

• Management: The 5G RAN should provide the needed support for slice-specific network management

The concept of network slicing introduces novel features on the core network as discussed earlier, where various network functions can be instantiated virtually at different logical locations within the core network. This helps to fulfil different requirements such as latency, computation, buffering, etc. As different slices which operate over the same RAN may have significantly different requirements for e.g., QoS it will be necessary to implement an evolved interface between the CN and RAN (S1*) which would be able to differentiate between the different slices. Similarly, the inter-node communication, currently carried out by the X2 interface in LTE-A would need to be extended to cope with multiple slices. This interface (X2*) is currently evaluated in 3GPP and it would be beneficial to harmonize with this work to enable interoperability with LTE-A. The mmMAGIC baseline for the functional split between the RAN and CN is the same as in




mmMAGIC Public 30

the Evolved Packet System (EPS) (see also Section 3.1.1), while alternative CN/RAN splits or cross layer optimizations could be considered. In particular, it is assumed that the CN functionality includes:

• Mobility anchoring (e.g., for inter-RAN node mobility, including inter-RAT mobility), addressing, roaming functionality;

• QoS control, charging, policy enforcement, context awareness;

• Attach and authentication signalling including security key generation.

These are very different functions in terms of requirements compared to RAN functions such as scheduling, measurement handling, load control, beamforming, etc. Therefore, when analysing the abovementioned overall system requirements associated to network slicing there should be clear differences between the CN and RAN specific assumptions.

Depending on which type of services each slice and parallel slices support, the requirements on the joint resources will vary. However, the architecture of the Network Slices should be flexible enough to allow different optimizations of the resource utilizations while maintaining independent slices in order to reduce cost and energy consumption compared to deploying separate physical networks for different use cases or business scenarios. This should be assumed for both CN and RAN where examples of network resources are hardware platforms (which could either be cloud-based platforms or dedicated hardware equipment), software resources (such as memory, processing power, databases, etc.), transport bandwidth, and others. In the particular case of the RAN, additional radio-specific resources to be considered are e.g. radio resources, antenna architectures, backhaul and/or fronthaul. The fact that resources should be shared as a default case does not preclude the possibility to assign dedicated (static) resources in very special cases where it might be mandatory e.g., due to regulatory issues. However, dedicated usage of resources should be carefully considered since it could lead to resource usage inefficiency. As each slice may have multiple services, with different Quality-of-Service (QoS) requirements, the RAN needs to be able to differentiate traffic between different slices and/or different services in multi-service slices. This differentiation could be achieved by making the RAN aware of the different slices, e.g., by providing a slice-ID . In addition, the RAN needs to ensure that the traffic in one slice does not degrade the performance of other slices during e.g., congestion by protecting the common channels and the shared resources. In current 3GPP systems, there are protection mechanisms such as Access Class Barring (ACB) methods and implementation-specific admission controls. However, since the network slicing for the mm-wave RAT supports a wide range of services with very differing requirements, the legacy ACB will need to be extended to consider which types of services should have priority, especially when the different slices are unaware and should remain unaffected by each-other.

As the demand for different slices will evolve over time, the RAN should be designed to support efficient management of different slices and enable efficient introduction of new slices or adding services to existing slices, while maintaining the performance of the incumbent services. The RAN should also support incremental improvements of the common infrastructu re, e.g., subsequent densification of the network, to benefit the different slices in an efficient manner.

4.1.3 Network functions from network slicing perspe ctive Network functions can be decomposed based on slice requirements as shown in Figure 4-2. Shared (or common to multiple slices) functions are envisioned to be by default the ones handling common radio resources. This has the advantage of maximizing the usage of radio resources. For example, if PRACH is a common channel for multiple slices and initial access procedures are similar to a certain extent to the different slices the PRACH capacity is maximized so traffic fluctuations can be captured very fast. On the other hand, coordinated




mmMAGIC Public 31

functions have the advantage to enable the optimization of network operations, per slice despite the risk of wasting capacity in unbalanced traffic scenarios. Functions related to Radio Resource Management, e.g., Radio Bearer Control, Radio Admission Control or Dynamic allocation of resources to UEs could either be defined as shared or coordinated. Coordinated functions have yet another drawback: they require inter-slice coordination, in particular, as physical resources are inherently limited and any allocation / mapping to one slice should be in coordination with others to ensure satisfying per slice requirements. This would ensure more agile operations with minimal signalling overhead. It is still unclear whether there will remain a group of functions that can be independent between the slices. This group of independent functions will be slice-specific based on features and characteristics of a certain radio interface, e.g., the specific initial access scheme. However, there can be several parallel slices with similar features and characteristics which share these network functions. In the next section, the challenges and technology components relevant to such radio interfaces are explored.

Figure 4-2 Three types of radio network functions e nvisioned in context of Network Slicing

4.2 Review and redesign of the protocol stack for t he mm-wave integrated system

In order to fulfil the objective of ubiquitous connectivity envisioned by 5G systems, it is important to integrate and extend the deployment of higher frequency bands into the next generation mobile telecommunication systems. When it comes to integrating other technologies, a fundamental aspect will be reviewing the structure and functionality of the existing protocol stack for its adaptability for newer systems. For this, the communication architecture and protocols in the MAC layer will be specifically revised, to adapt signalling and resource allocation and to cope with the other challenges of attenuation, directionality and blockage encountered by mm-wave systems. Research will be conducted in defining some added features to the RRM present in the MAC layer, alongside explicitly describe the operation of mm-wave access points in a 5G system. In addition, the possibility for newer features and extended functionality of the RLC, PDCP and RRC to incorporate mm-wave technologies will be explored. Yet, another fundamental aspect that will be touched upon here, are the parameters influencing the re-design of protocol stack for the synchronization of MAC layer in mm-wave systems with other technologies.

Next, we will overview one proposed revision in protocol stack in line with envisioned 5G traffic characteristics.

4.2.1 Review of the RRC states Overview of the LTE-A RRC states It has been observed in existing systems such as LTE-A that some of the mobile broadband data traffic consists of many infrequent small bursts of traffic interspersed by relatively long

RAN function typesSlice #1 Slice #2 Slice #3

NF 1

NF 2 NF 2 NF 2

NF 3

NF 1

NF 3 NF 3

Shared between some slices

Independent across all slices

Coordinated across some slices




mmMAGIC Public 32

waiting periods, e.g., during web browsing or short video or music streaming, while the UE remains either static or within a small area. During the inactivity periods, the UE would benefit from turning off its transmitter and receivers in order to save battery power. In LTE, this is possible to achieve by using a discontinuous reception (DRX) which is applicable in both RRC_IDLE and RRC_CONNECTED states. In the RRC_IDLE state, only the CN context is preserved, while the RAN context is discarded and the UE only monitors the paging channels once per DRX cycle. In LTE-A the UE will camp on a best cell based on configurations from the network, but a high mobility UE which moves beyond the cell may incur significant delays to reconnect to the network. For a UE in RRC_CONNECTED state, the UE is known by the RAN and the mobility is fully controlled by the network through handovers. The UE may use DRX to turn off the receivers for “micro sleeps” when the traffic is very bursty, e.g., during a web session, where the UE can turn off the receiver, while the content of the web page is being read. However, if the DRX period is too long, there may be significant delays if the network needs to reach the UE when e.g., DL traffic has arrived [SMS+16].

Currently the most prominent use of DRX is in RRC_IDLE, with inactivity timers on the order of 10-60 s. This results in a significant amount of transitions between RRC_IDLE and RRC_CONNECTED, which is quite costly in terms of network signalling. If the DRX traffic amount is small, this signalling will result in a large overhead. Additionally, this signalling results in a large delay before the traffic can be received, which could be detrimental in certain scenarios.

Novel RRC state: RRC Connected Inactive A similar traffic pattern is expected to occur in 5G RAN deployments with high frequency carriers above 6 GHz i.e., there will also be applications with infrequent small bursts. In addition to that, it is expected that due to the high amount of narrow / high gain beamforming the coverage will be more unstable so that the beam coverage might need to be updated more often if the UE remains all the time in RRC_CONNECTED. As it is not advisable to keep all devices in RRC_CONNECTED since significant network signalling will occur during handovers / beam-switching, even when the UE does not have any traffic ongoing, a novel 5G RRC state called RRC_CONNECTED_INACTIVE is introduced as the primary sleep state. The main characteristics of this sleep state would be that the UE and the network maintain the UE context however, the mobility is UE controlled. Maintaining the UE context in the RAN is especially reasonable in scenarios with higher frequencies for semi-static users that will exist both in outdoor and indoor scenarios. As long as the UE remains within a pre-defined RAN area, there will be no handovers.

Additionally, the DRX periodicity would be widely configurable, as the sleeping periodicities would differ significantly between different use cases where some devices would need to wake up every couple of minutes, while others may sleep for several days.

As the RRC_CONNECTED_INACTIVE state maintains some of the UE context, it will be possible to optimize the state transition to RRC_CONNECTED once there is data available and it should be possible to use data heuristics to predict the state transition, if e.g., the mobility of the UE is known by the network. As the mm-wave RAT will support and rely on multi-connectivity, both for multi-frequency, and multi-RAT, it should be possible to configure the UE to camp on either of the RATs or both of them simultaneous if the use case calls for very low latencies.

Figure 4-3 shows the novel RRC state RRC_CONNECTED_INACTIVE, and the state transitions between the states.




mmMAGIC Public 33

Figure 4-3 Novel RRC state RRC Connected Inactive a nd state transition diagram between three

RRC states: RRC Idle, RRC Connected Inactive and Co nnected.

It will be important that the state transition between RRC_CONNECTED and RRC_CONNECTED_INACTIVE is very lightweight to reduce signalling and overhead as it is predicted to occur frequently. When the UE transitions to RRC_CONNECTED_INACTIVE from RRC_CONNECTED it keeps the RAN context it received during the setup of the initial RRC_CONNECTED, e.g., when the UE attaches to the network or transitions from RRC_IDLE to RRC_CONNECTED. The transition from RRC_CONNECTED_INACTIVE to RRC_CONNECTED is only considered successful if the target node can find the RAN context. If it fails, the UE transitions to RRC_IDLE and will need to reattach to the network. As the UE context is maintained in the RAN, the CN/RAN connection is kept and the transition to RRC_CONNECTED_INACTIVE is transparent to the CN and will not require any CN signalling.

Another advantage of the approach relates to the harmonization of solutions for the UE states in a wider range of frequency bands, not only mm-wave ones. In the RAN Design workshop co-organized by mmMAGIC and other projects (such as METIS-II) in Valencia in 2016 some similar principles have been discussed. Herein the aspects related to the mm-wave details were provided, showing that a harmonized solution for the UE states is feasible.

4.3 Multi-connectivity and multi-RAT In order to fulfil the stringent requirements for throughput, coverage, mobility, reliability, and latency it will be required to utilize multi-connectivity, both between different mm-wave nodes, as well as between different RATs. As the mm-wave operates at higher frequencies compared to legacy mobile networks, increased directionality and outdoor-to-indoor penetration loss will result in more challenging coverage. As the mm-wave RAT will in many cases be deployed within the coverage of lower frequency RATs (e.g., LTE-A), it will be beneficial to integrate the different RATs.

4.3.1 Multi-connectivity types Multi-Connectivity is a key technology to fulfil 5G requirements on data-rate, latency, reliability and availability. The term multi-connectivity can accommodate a broad range of techniques that have one thing in common: operation, where, for a given UE, radio resources are configured from two or more different network points.

In Figure 4-4 there is one among the many possible classifications of multi connectivity shown and exemplary techniques that implement the multi-connectivity idea, are given.




mmMAGIC Public 34

Figure 4-4 Classification of different multi-connec tivity types

Inter-frequency multi-connectivity refers to the case where a UE is connected to two radios on different carrier frequencies. Different RATs could also utilize these frequencies. In contrast, intra-frequency multi-connectivity refers to transmission on the same frequency.

It is worth mentioning, that the additional dimension of differentiation between MC cases is co-location i.e., having the case where network points that the UE is connected to are co-located in the same physical site (intra-site multi connectivity) or they are in different physical sites (inter-site multi-connectivity).

The next paragraphs will briefly characterize technical solutions included in Figure 4-4 for both intra- and inter-frequency cases.

Intra frequency The intra frequency solutions typically need common MAC layer due to coordination in terms of modulation and coding and/or coordination in scheduling. As this requires strict synchronization between the nodes, the latencies between the nodes need to be very small. Figure 4-5 captures some key Intra-frequency schemes counted as multi-connectivity.

Multi-connectivity

Intra frequency

SFN CoMP

JT DPS CS

Inter frequency (Intra-RAT/Inter-RAT)

Low layer integration (e.g. Carrier Aggregation)

High layer integration (e.g. enhanced Dual

Connectivity)

User Plane

Control plane Full




mmMAGIC Public 35

Single Frequency Network

Joint-Transmission CoMP Dynamic Point Switching CoMP

Figure 4-5 Selected Intra-frequency multi-connecti vity solutions: Single Frequency Network,

Joint-Transmission CoMP, Dynamic Point Selection Co MP

Single Frequency Network (SFN)

In the SFN transmissions multiple network nodes are synchronized so that their transmissions on the same frequency are received inside the Cyclic Prefix (CP) of the OFDM symbol at the UE receiver. This means that different network nodes need to transmit identical content and to utilize identical Modulation and Coding Schemes (MCS) as well as frequency and timer resources with high timing accuracy without the UE specific channel information.

Joint Transmission CoMP (JT-CoMP)

In the JT-CoMP transmissions, transmissions from multiple network nodes in the same frequency are synchronized and weighted based on the channel state information of the UE to obtain optimum coherence combining at the UEs receiver. This transmission mode requires a centralized scheduling and ideal front hauls towards different transmission points as well as transmission weight calculations in 5G-NB.

Dynamic Point Selection CoMP (DPS-CoMP)

In the DPS-CoMP transmission, transmissions from different transmission points are alternated in TTI level based on the channel quality. As the UE is receiving single transmissions and does not perform coherent combining, the DL synchronization is relaxed to the DL frame timing level compared to JT-CoMP. Additionally, this scheme can utilize different frequency resources and MCSs for different transmissions and if different cell carriers are used this scheme becomes one specific operation of carrier aggregation.

Coordinated Scheduling/Coordinated Beamforming CoMP (CS/CB CoMP):

In CS/CB CoMP, multiple coordinated Transmission Points (TP) share only Channel State Information (CSI) for multiple UEs and the data packet that is destined to a specific UE is available only at one TP. In CB, power level and the beamforming coefficients are calculated to achieve some common SINRs in the system or to maximize the minimum SINR. When applying CS, a network is divided into multiple clusters and centralized scheduling is applied within each cluster in order to determine which TPs in the cluster should transmit in each time slot and to which UE.

As an alternative flavour of intra-frequency multi-connectivity, a single user might be simultaneously connected to several 5G-NBs of the same RAT at the same frequency, mainly

UE

Data

MCS, Waveform

UE

Data

MCS, Waveform

w2*w1*

UE

Data

MCS, Waveform

MCS, Waveform




mmMAGIC Public 36

for the sake of improved reliability, but possibly also for increased throughput. Improved reliability calls for sharing the same data flow amongst multiple 5G-NBs, possibly involving some form of space-time coding (or simple repetition as in soft handover). For increased throughput, multiple data flows could be directed to/from the same user from/to a set of 5G-NBs (with one beam per 5G-NB), thus creating multiple spatial streams to be received /transmitted by the user. In any case beamforming would be a key element at least in the network side, exploiting the channel sparsity to create sharp beams over defined directions (e.g., by means of appropriate phase shifters in hybrid beamforming). Beamforming at the UE side increases complexity although also benefits from the small wavelengths involved, making it possible to achieve some gains. Spatial multiplexing, however, could introduce excessive complexity because of the need to track multiple beams.

In cases as above multi-connectivity implementations can differ depending on whether the user has beamforming capabilities or not. In the affirmative case, the UE would be able to transmit/track as many beams as RF chains are implemented within the UE, hence being able to transmit/receive multiple spatial layers (in SU-MIMO, MU-MIMO, or diversity modes). In the negative case, the UE simply benefits from increased diversity without being able to increase throughput.

Inter-frequency

Carrier aggregation (CA)

In carrier aggregation, the network utilizes two or more carrier frequencies to transmit and receive data to/from the UE in downlink and uplink, respectively. The data split between different carriers is done at the transport block level as the MAC provides separate transport blocks, which can be of different sizes, to each carrier. Each carrier can utilize different transmission modes, MCSs or even SU-MIMO modes (in LTE-A each SU-MIMO receives separate transport blocks from the MAC). CA is typically dedicated for the scenarios where both carriers are served from the same site or where the backhaul between nodes is good enough.

Enhanced Dual connectivity (eDC)

Dual connectivity (DC) is a LTE Rel-12 feature for small cell throughput enhancement. DC allows the UE to receive data simultaneously from different eNBs in order to boost the performance in a heterogeneous network with dedicated carrier deployment. DC can be used in cases where nodes are physically separated and non-ideal backhaul is assumed or when the two nodes are functionally or architecturally different at the lower layers to allow CA. Unlike CA, in DC, the split is done on PDCP level which allows a more relaxed coordination and synchronization within a single RAT or between different RATs.

In the DC or PDCP-anchored multi-connectivity, a single user data flow is transmitted via multiple cells operating on different carrier frequencies potentially supporting different radio interfaces at the PDCP layer (bearer split) or above. DC could have different variants depending on whether multi-connectivity is applied to user plane or control plane as shown in Figure 4-6.




mmMAGIC Public 37

Figure 4-6 Layer 2 connectivity potential solutions .

When having user plane multi-connectivity – the radio resources from more than one 5G-NB are aggregated for user plane data transmission. In case of control plane multi-connectivity, handover related RRC signalling is transmitted via more than one 5G-NB. When combined both user and control plane multi-connectivity - radio resources from more than one 5G-NB are aggregated for both user and control plane data transmission.

Depending on the deployment and use case requirements, the different options may be selected based on a trade-off between e.g., throughput, reliability, or latency on one hand and signalling overhead and complexity on the other hand. Therefore, the latest option which allows for both UP and CP multi-connectivity is specifically interesting for exploration where multi-connectivity may be enabled or disabled for either plane independently for each UE.

User plane architectures and options

In this part, we will look into various Radio Flow (RFL) configurations. In particular, two 3GPP dual connectivity options as shown in Figure 4-7 and their combinations will be detailed. These two options: 1a (bearer level split at S-GW) and 3c (packet level split as PDCP PDUs at MeNB), were already explored in 3GPP TR 36.842 [3GPP TR 36.842]. As an extension of these studies, we will also look into other combinations of bearer split that are beyond 1a and 3c.

User Plane Multi-connectivity

UE

AP1

AP2

AP3

• Aggregating radio resources from more than one APs for user plane data Tx

• Control plane as well as mobility still in one cell only

• Adopted in LTE e.g. CoMP, cell aggregation, CA, Dual connectivity

UE

AP1

AP2

AP3

Control Plane Multi-connectivity

•Handover related RRC signalling could additionally be transmitted from or to a potential target cell e.g. RRC diversity, or multiple RRC

•User plane still in one cell only•Not used in LTE yet.

UE

AP1

AP2

AP3

User PlaneControl Plane

Control and User Plane Multi-connectivity

•Both CP and UP connected to multiple cells

•E.g. Inter-node radio resource aggregation + RRC diversity

•Not used in LTE yet




mmMAGIC Public 38

Figure 4-7 LTE – 5G interworking architecture based on LTE-A Dual Connectivity. Blue colour

existing LTE protocols with minimum necessary updat es and white colour new 5G protocols/extended LTE-A protocols.

In option 1a, we have no bearer split at eNB or 5G-NB level. Master Cell Group Service Flow (MCG SF) and Secondary Cell Group Service Flow (SCG SF) will have independent Radio Link Control (RLC) and Packet Data Convergence Protocol (PDCP), MAC layers as it is shown in Figure 4-8.

In option 1a, only data split mode is possible because S-GW does not support duplicating the data over S1-U. The option 1a has some advantages over 3c since, firstly, it has low requirements on the backhaul link between MeNB and SeNB, and secondly, MeNB does not need to buffer traffic for an EPS bearer of SeNB.

Figure 4-8 User plane architecture option 1a

MeNB

MAC

RLC

PDCP

SeNB

MAC

RLC

PDCP

S1* S1*

MCG SF

SCG SF




mmMAGIC Public 39

In option 3c, we have split bearer at PDCP level at Master eNB (M5G-NB Split SF) as can be seen in Figure 4-9.The S1-U terminates in MCG and RLCs are independent. Option 3c can be used both for data split and data duplication purposes. The 3c option has several advantages such as: SeNB mobility is hidden to CN and there are no security impacts as ciphering being required in MeNB only. Additionally, there is no need for data forwarding between SeNBs when SeNB changes but these advantages are not for free as MeNB needs to route, process and buffer all the dual connectivity traffic.

Figure 4-9 User plane architecture option 3c

Based on these two options, there can be several combinations investigated in context of application to 5G. One possibility could be merging flows from 1a and 3c i.e. having MCG RFL (as in both 1a and 3c) + SCG RFL (as in 1a) + MCG split RFL (as in 3c). Other option that is envisioned for future investigations is extending option 3c by allowing the RFL split in SeNB that will result in having MCG RFL + SCG RFL + SCG split RFL (see Figure 4-10). It is worth noting the differences between Master versus Secondary 5G-NB Split:

• In Master 5G-NB split Service flow (M5G-NB split SF) S1-MME terminates at Master 5G-NB and therefore act as mobility anchor towards the CN.

• In Secondary 5G-NB split Service flow (M5G-NB split SF), Secondary 5G-NB provides additional radio resources for the UE, not the Master 5G-NB.

Master 5G-NB can be low frequency RAT (e.g. LTE-A) or mm-wave RAT depending on the scenario and similar applies to the Secondary.

Figure 4-10 Radio Protocol Architecture for 5G dual connectivity – all flows and splits

considered in this section: flows from 1a, 3c and a dditional RFL split in SeNB (not allowed in 1a and 3c).

MeNB

MAC

RLC RLC

PDCPPDCP

SeNB

MAC

RLC

S1*

X2*

MCG SF

M5G-NB split SF

MeNB

MAC

RLC RLC RLC

PDCPPDCP

SeNB

MAC

RLCRLCRLC

PDCP PDCP

S1* S1*

X2*

MCG SF

SCG SF

M5G-NB split SF

S5G-NB split SF




mmMAGIC Public 40

Comparison between 5G CA and Dual Connectivity user plane

Dual Connectivity has more relaxed requirements regarding the deployment scenarios and network synchronization. In addition, DC has better compatibility including inter-vendor operability using the open X2 interfaces as well as inter-RAT integration where technologies with differing numerologies can be used.

On the other hand, CA can be used to aggregate the radio resources from asymmetric bands as well as unlicensed spectrum due to the support of single uplink or downlink (i.e., cross-carrier scheduling). Therefore, both CA and Dual Connectivity will be evaluated as options for 5G multi-connectivity.

Control-plane multi-connectivity

It is assumed that there is only one S1*-C Connection per Dual Connectivity UE. The 5G-NB which terminates at least S1*-C is called M5G-NB. Each 5G-NB should be able to handle UEs independently, i.e. provide the PCell to some UEs while providing SCell(s) for SCG to others. Each 5G-NB involved in Dual Connectivity for a certain UE controls its radio resources and is primarily responsible for allocating radio resources of its cells. Respective coordination between M5G-NB and S5G-NB is performed by means of X2* interface.

In LTE, dual connectivity is specified to enhance the throughput by aggregating the resources for user-plane transmission. It is not applied to control plane, i.e., there is a single RRC entity located in MeNB and all the RRC messages are generated from MeNB and sent to the UE directly. Considering the diverse use cases in 5G, RRC multi-connectivity is expected to improve the CP performance in terms of mobility, robustness, reliability and latency as depicted in Figure 4-11.

Figure 4-11 Enabling RRC multi-connectivity for 5G

Single RRC In this alternative, only the Master 5G-NB (M5G-NB) generates the final RRC messages to be sent towards the UE after the coordination of RRM functions between M5G-NB and Secondary 5G-NB (S5G-NB). The UE RRC entity sees all RRC messages coming only from one entity and replies back to that entity in the M5G-NB. One RRC message is sent from M5G-NB directly to

LTESingle RRC

Single RRCSingle TX path

5GConnectionRobustness

Seamless Mobility

Fast and FlexibleConfiguration

RRC diversity

Master/Slave RRC

• Less connection failure• Ultra reliable RRC TX

• Invisible cell/eNB change• Service continuity

• Separate configuration• Direct RRC signaling Tx

Single RRCMultiple Tx path

Multiple RRCSeparate configuration

Single RRC

Single RRCSingle TX path




mmMAGIC Public 41

the UE via the single transmission path. It is the same as in LTE-A Dual Connectivity and inherited as one of the candidate solutions for RRC transmission in 5G multi-connectivity, especially for the conventional use cases targeting throughput enhancement only.

RRC diversity Due to single RRC, it shares the same architecture option as Single RRC. The distinction is that the RRC messages are additionally routed via X2* to S5G-NB and transmitted via multiple paths from both M5G-NB and S5G-NB to the UE in the same way as user plane data transmission. Because of the multiple transmission paths available, the alternative helps to improve the mobility robustness and ensures the seamless mobility in extreme MBB (xMBB) scenario.

Master/secondary RRC This alternative enables multiple RRC entities as well as multiple RRC connections in distributed scenario of 5G. Both M5G-NB and S5G-NB can generate final RRC messages to be sent towards the UE after the coordination of RRM functions between M5G-NB and S5G-NB and may send those directly to the UE and the UE replies accordingly. Since it enables the direct RRC message transmission from S5G-NB to the UE, it minimizes the configuration delay and improves the connection robustness typically for ultra-reliable MTC (uMTC).

Tight integration with LTE-A with PDCP layer multi connectivity.

As the mm-wave system will in many cases be deployed in areas already covered by LTE, it will be beneficial to utilize the support of the evolution of LTE-A. A similar approach as described in the previous section could be used to integrate the mm-wave RAT with LTE-A where the PDCP split would allow the lower layers to remain independent. A schematic of this architecture can be seen in Figure 4-12. In the figure, the LTE-A is depicted as Master-eNB and the mm-wave as Secondary-NB, but as this is viewed from a UE perspective may simultaneously serve some UEs as Master-NB and other UEs as Secondary-NB depending on the configurations

Figure 4-12 User and control plane connected to bot h LTE-A and the mm-wave RAT

In scenarios where the throughput capacity of the mm-wave RAT is significantly larger than that of LTE-A, e.g., when the mm-wave RAT has several 100 MHz of bandwidth, whereas LTE-A only has a few tens of MHz, there is little gain in utilizing both accesses for UP traffic. Especially for typical web based traffic or video streaming, the throughput may actually be throttled by the slower connection as packets may get stuck in the SeNB and the reordering mechanism at the UE PDCP needs to wait for them to arrive. Instead, it would be possible to enable a rapid switch




mmMAGIC Public 42

of the UP between the MeNB and the SeNB when the channel conditions change as can be seen in Figure 4-13.

Figure 4-13 LTE-A and mm-wave user plane switch whi le control plane is in “dual connectivity”

with both LTE-A and 5G

As there are several different options for multi-connectivity proposed for the mm-wave RAT, it is possible that a multitude of them will be employed simultaneously. For instance, if the mm-wave RAT utilize CA between different mm-wave APs, adding dual connectivity at the PDCP layer between the mm-wave RAT and LTE-A would increase the complexity. Additionally, if the data traffic is small, the overhead would increase by having multiple flows.

To avoid these coordination difficulties and signalling overhead, it could be possible to switch both CP and UP as seen in Figure 4-14 which could be made much faster than the current LTE-A handover if the two RATs have a common PDCP layer.




mmMAGIC Public 43

Figure 4-14 LTE-A and mm-wave CP and UP switch. The common PDCP layer allows faster

switching between RATs compared to hard-handover.

Depending on the scenario, topology, performance of the access nodes, and requirements, the optimum choice of coordination feature may vary but it should be possible to select either of the solutions based on the current needs of the network.

4.3.2 Base station support through low frequency ba nd 5G or legacy LTE-A systems operating in the low frequency band below 6 GHz usually have larger area coverage than the one expected for 5G mm-wave systems and better reliability due to the different propagation properties of these frequencies. This fact suggests making use of an already existing low band connection to support mm-wave connections where they have specific weaknesses. In the following, a short assessment on the possibilities and limitations is given.

Signals which require transmission on mm-wave chann el: For initial access the UE requires signals for

• DL time and frequency synchronization

• mm-wave BS identification

• beam indication and beam selection.

For data transmission the UE requires

• in DL: pilot signals for channel estimation and demodulation

• In UL: synchronization signal for time adjust

Since these signals are closely related to the physical properties of the used channel, they must be transmitted within the mm-wave channel and cannot be offloaded to a different channel. In contrast to low band transmission, due to the higher path loss, these signals cannot be transmitted as broadcast signals, but need to use directional beams. This may lead to additional challenges and require a procedure even more complex than in low frequency bands.




mmMAGIC Public 44

Further, if we assume that the mm-wave has MAC and PHY layers independent of low frequency band layers, all delay-sensitive PHY/MAC control signalling has to be exchanged also on mm-wave channel. Especially when assuming shorter TTI lengths than low bands, this need becomes more obvious.

Delay sensitive control signals can be classified as below:

• Scheduling grants

• HARQ ACK/NACK

• UL scheduling requests

• CQI

Signals which could be transmitted on an existing l ow frequency band connection: For transmission on low frequency band it remains less delay sensitive or insensitive control information.

Delay insensitive control information ca be categorised as:

• Mm-wave system configuration information

• Cell search assisting information, e.g., mm-wave BS located within low band coverage area

• UE specific RRC signalling

• UL reporting of selected beam and related CQI

Due to the dynamic behaviour of the mm-wave system it can be advantageous if the most promising mm-wave BS can be identified and reported to the UE through the low frequency RAT. This may restrict the search time or handover time in case of mobility of the UE and simplifies a dynamic mm-wave BS cluster definition. Also UE-specific RRC signalling or the UL reporting of selected beam and related CQI could be transmitted with higher reliability over the low frequency band at a stage where the mm-wave link setup has not fully been completed. For a standalone system all this low band signalling has to be exchanged on mm-wave link. The main difference between standalone and non-standalone mm-wave systems is on the functionality of the higher layer protocols. In case of non-standalone operation the part of the higher layer protocols which exchanges delay insensitive control information from the categories described above will be transmitted between UE and low-band base station. The impact on mm-wave system operation will be on link setup and mobility handling performance or related signalling overhead. The relevance of this difference probably depends on the deployments and use cases.

4.3.3 Metro-like deployment with coverage from mult iple base stations, with support from lower frequency bands

Due to the specific propagation properties mm-wave links are susceptible to sudden blocking effects by cars or persons crossing the signal path. To increase reliability and the overall cell throughput even in case of such blocking events, it is assumed that a coverage area can be served by multiple mm-wave base stations, which provide “overlapping coverage”. Such a situation is shown in Figure 4-15. To achieve redundant coverage, multiple mm-wave BSs are placed within the low-band 5G coverage area. These BSs form a “serving cluster”, so that the UE is within reach of each mm-wave BS of the cluster. A serving cluster (see Section 4.4), therefore, is defined based on the location information of the UE and the BS, which can be derived by measurements taken by the UEs on mm-wave and / or low band frequencies. A dynamic reconfiguration is envisaged to handle mobility or different load situations at the involved base stations.




mmMAGIC Public 45

Figure 4-15 Multi-base-station coverage on mm-waves

The proposed solution is characterized by the following detailed functionalities:

• multiple mm-wave cells (mm-wave BSs) are simultaneously covering an area (mm-wave BS cluster);

• high gain BF is applied to serve the UEs; • in case of a link being suddenly blocked, a fast switching to another mm-wave BS of

this cluster is performed in order to maintain QoE; • in case of UE movement a dynamic cluster reconfiguration takes place, to ensure

always a certain number of mm-wave BS are covering the current location of the UE. The role of the low frequency band is to make the operation of multi-BS coverage easier and more reliable. It is characterized by the following detail functionalities:

• support the setup of mm-wave BS cluster based on UE information; • assistance of mobility handling and mobility detection; • support of handover to another mm-wave BS to provide seamless fall-back to low band

transmission if the mm-wave link fails. Of course this is possible only if the type of service allows this.

The practical realization of such multi-BS coverage has impact on several network layers.

On the PHY layer the multi-BS coverage causes interference, if the BSs are operating individually on the same resources. This can be mitigated by using high gain beam steering with small half-power beamwidth (HPBW) antenna pattern to reduce the probability that a UE is hit by an interfering mm-wave BS. In addition, also interference coordination among mm-wave BS clusters is a powerful means to reduce unwanted interference.

On higher layers the fast switching of a connection to another mm-wave BS requires fast adaptation of the backhaul connection for a huge amount of data, in combination with the fast

Low band eNB

or

low band 5G-NB

mm-wave NB 3

mm-wave NB 2

mm-wave NB 1

mm-wave UE




mmMAGIC Public 46

adaptation of the scheduler of the new mm-wave BS. Therefore, the network architecture must comprise suitable enabling functionalities and network elements supporting these requirements.

The considered scenario is an urban micro / urban macro like outdoor scenario with multiple mm-wave base stations within coverage of a low band cell. Performance evaluation and comparison of implementation options can be based on PHY layer SINR distribution. Ray tracing coverage analysis and/or stochastic system level simulation will be applied.

The KPIs to be considered are related to • Coverage area

• Number of covering BS

• Throughput • Mobility, HO delay and signaling reduction

4.3.4 The single/multi-connectivity optimization sc hemes for standalone and non-standalone RAN

The efficient optimization techniques in Self-Organizing Networks are expected to provide high Quality-of-Service (QoS) while reducing the resource usage. These requirements are particularly difficult to achieve in mm-wave range because of propagation phenomena. The QoS is described by Key Performance Indicators (KPI). The optimization schemes and desired KPIs are discussed in this chapter.

Two proposed schemes are Single Link Optimization (SLO) and Multi Link Optimization (MLO). The proposed methods are applicable to both control and data planes. The first approach is expected to be used for each link in multi-connectivity mode or one link in single-connectivity. The benefit of approach is significantly noticeable in multi-connectivity mode because of the number of links that are optimized. The latter is aimed at improving the reliability of connection in multi-connectivity mode. Hence less retransmissions occur. Here, the simultaneous transmission from a few APs is taken into account. Both optimizations are assumed to be used on the same resources to manage the complex multi-connectivity mode.

The main goal of SLO aims at increasing the single link performance. The network performance is defined by desired KPIs. Here, we particularly expect SLO to be the appealing approach for throughput and coverage enhancement. Thus, these KPIs are used in further consideration. The approach requires also enough network flexibility and an efficient optimization algorithm which drives the process. The flexibility is provided by two dimensional (2D) antenna arrays [SBF+15] which are key enablers for efficient beamsteering (the beam is steered by current phases in N×M elements). The two dimensional antenna arrays use Basic Beams (BBs) approach [SBF+15] that collects a couple of promising configurations to one antenna pattern. The aforesaid solution enables the efficient power adjustment in the cells, e.g., the non-uniformly distributed crowd in urban areas can be covered (use case 3).

The desired KPIs in SLO are taken into account as an argument of the cost function [BSF+13]. The cost function design is adjusted to the operator’s expectations and propagation conditions in the network. Plenty of optimization methods can be applied. However, the complexity of method has to be taken into account. Hence, direct search methods, e.g. Nelder-Mead simplex search method [NM65], are promising for this application. They can search directly through the cell by changing the BB direction in spherical coordinates [SBF+15]. The overall beam can contain a few BBs that are optimized sequentially or in parallel.

The MLO problem is aimed at improving reliability of multi-link connection. The goal is to find the optimal number of links to provide the low outage probability. The link selection is also taken into account. The multi-connectivity is provided by Maximal Ratio Combining (MRC) or Spatially Coupled Low-Density Parity-Check (SC-LDPC) codes. Both techniques require non-coherent transmission through links. The first approach requires transmissions at the same frequencies. The latter is expected to be used in connections at different frequencies. Any multi-connectivity scheme, which meets aforesaid requirements, can be applied e.g., CoMP, CA, DC, SFN.




mmMAGIC Public 47

The commonly known MRC technique is proposed as the straightforward technique for link combining [Sri10]. The usability of MRC in mm-wave range was already shown [WMH14]. Thus this technique is taken into account. The diversity combining approach was also proposed for mm-wave in [RCM96].

The second proposed technique for link combining is the usage of Low-Density Parity-Check (LDPC) codes. The LDPC improves significantly the reliability of the connection. The desired LDPC codes for this application are the group of SC-LDPC codes [HLA+14]. The multi-connectivity provides the variety of different independent channels that can be used for transmission. The independent channels entail the various fading coefficients in each link. Hence the connection with n links can be described as a block fading channel with n blocks [HLA+14]. The spatial coupling yields the code diversity that provides the desired error correction. Hence, data lost in one link might be recovered by data which is transmitted in another link. This feature can be enabled also by root-check LDPC codes [BFB+10].

In the standalone scenario the MLO yields the number of links for current network conditions. Then the SLO is used for each link in the network cluster. The cluster contains a few neighbouring APs. The SLO is used sequentially AP by AP [KSF15]. The information about KPIs is exchanged between APs in cluster. While considering 5G-NB as an AP, the X2 interface is used. When the optimization process is finished (the goal or the maximum number of evaluation is reached) the next AP starts optimizing itself. The algorithm makes the predefined number of rounds through APs in one cluster. This process yields the configuration that is expected as the optimal configuration. The next optimization process is started after certain time or is caused by another event in the network.

In the non-standalone (Multi-RAT) approach, the low-frequency network is expected to be the key enabler for providing the coverage in the network architecture. The commonly used in LTE-A linear arrays [3GPP TR 25.814] entail the wide beams that can cover the most of the network area. The problem with mm-wave is that it is difficult to find the beam, because the channel changes a lot. The LTE-A connection is enough reliable to provide the basic telecommunications services. However, it is still not possible to cover the whole network and regions with low coverage appear. Concurrently, there is a problem in providing desired network capacity in non-uniform dense urban areas. Both issues can be coped with Multi-RAT solution that is presented.

The lower frequency mainly targeted for providing coverage with reasonable throughput in uniform traffic demand distribution. However, the coverage is treated as the main goal. Thus the adequate weight in the cost function is taken into account. The aforementioned (but limited) SLO with desired cost function is expected to be used. The major goal is to find the desired configuration for a relative long period of operations.

The widely deployed LTE-A network [AGC10] can be used as one-part low frequency network for Multi-RAT system. The SLO process in low-frequency is expected to be provided by Master eNBs (MeNB) for a whole cell cluster simultaneously. The parameters are limited to downtilt because of usage of linear arrays without BBs. The eNBs transmit the average statistics to MeNB through X2 interface. Then the optimization is made offline. The new configuration is forwarded to MeNB. The cell clusters are overlapping. The optimization is made sequentially through the network. The optimization is made periodically, however, with long periods, e.g., week or month. The network adjusts to the changes in the environment as e.g., new buildings.

In the Multi-RAT scenario, the external single mm-wave link (besides the low-band one) is expected to improve the network capacity and support in providing high coverage. The SLO optimization can be done separately in each mm-wave eNBs. The statistics from neighbouring cells are sent through X2 interface.

There is also another challenge in Multi-RAT scenario. The throughput significantly differs between low-frequency and high-frequency connections. However, the structure of SC LDPC codes that contains different number of bits in both links can be applied. The other idea might be to use low-frequency network for control plane, a high-frequency network for user plane as in dual-connectivity approach.




mmMAGIC Public 48

4.3.5 Energy efficiency in single/multi-connectivit y optimization The multi-connectivity approach entails increased resource usage that affects the energy efficiency. The more links serve the connection the more energy is used. Thus it is necessary to take into account energy efficiency while considering the number of connections. On the other hand, the number of links affects the reliability of the connection. Therefore, this number shall be the trade-off between high reliability and low energy consumption.

Moreover, the energy efficiency in each link can be decreased separately. Each link is provided by a 2D antenna array. The 2D antenna arrays are expected to contain tens of elements in the square grid structure. This structure can be easily used as the matrix for various antenna shapes. The various shapes entail different antenna array patterns. Moreover, some shapes might be more desired for the current traffic distribution [SBS+16]. Thus some elements might be switched off, while the network performance is still kept. Concurrently, the power consumption is decreased. The overall throughput in the area and the power consumption affect energy efficiency. The cost function takes into account the current energy efficiency as KPI of the considered area. The optimization is constrained by the network performance requirements (e.g., coverage/throughput limits). The optimization algorithms switch off the desired antenna elements to increase the energy efficiency [SBS+16]. E.g., Q-learning algorithms can be used that increase their knowledge by switching off antennas. Some predefined shapes or random switching can be also applied. After all, the desired shape is achieved and the energy consumption is decreased.

4.3.6 Multi-layer multi-RAT management Multi-layer multi-RAT management is the most generic approach to implement inter-RAT processing covering different interfaces supported by the transmitter and the receiver. A cross-functional approach allows switching from one technology to another in accordance with an optimisation criterion and requested functions such as the Fast Session Transfer (FST) [IEEEad12], the advanced C/U plane splitting mechanisms [SUMP16]. A vertical abstraction layer, covering PHY/MAC and layer 2.5 and network logical functions, is then introduced Figure 4-16. These models are motivated by latency reduction and backward compatibilities with existing technologies and multi-connectivity process. The proposed generic model, which is an extension on the I-MAC concept [KBN12], considers several layers for link adaptation metric integration, so three layer architecture levels are proposed for the integration method of metrics in multi-RAT architecture depending on involved technologies on multi-RAT scenarios.

The general concept is illustrated on Figure 4-16 and will be designed upon defined mmMAGIC scenarios.




mmMAGIC Public 49

Figure 4-16 Multi-layer multi-RAT management archit ecture

Figure 4-16 illustrates the multi-layer multi-RAT concept where 3 layers are envisioned to perform air interface switching and MCS switching in a single air interface. This multi-layer multi-RAT architecture is also denoted multi-layer abstraction layer linked to NGMN 5G concept.

The abstraction layer -1 performs transmission mode switching exploiting MAC mechanisms upgraded with existing protocols integrating new link adaptation metrics using the same communication channel to forward the decision. Solutions will be provided regarding enhanced PHY/ MAC protocols developed in mmMAGIC and RRM processing.

The abstraction layer-2 considers a L2.5 layer managing several air interfaces when control cannot be shared between different interfaces. This solution is an extension of the I-MAC concept by integrating multiple criteria in the multi-RAT management as the power efficiency, the multi-layer availability to perform communications and relay node management in mesh networks.

The abstraction layer-3 exploits IP network protocols to switch from one interface to another one or to slice from one network to another one. C/U plane splitting application for WLAN-LTE aggregation utilizes the abstraction layer-3 in order to perform Wi-Fi offloading in small cells. A first solution has been proposed [SUMP16] in MiWEBA integrating link adaptation metrics in WLAN-LTE carrier aggregation schemes issued from the 3GPP. We will extend the concept to 5G-RAT management developed in mmMAGIC.

Metrics are evaluated at the PHY layer and forwarded to one of these abstraction layer levels, depending on concerned interfaces in the simulated multi-RAT scenario. When considering power efficient link adaptation processing, metrics designed in the Section 4.3.7 may be selected and integrated in those 3 scalable architectures.




mmMAGIC Public 50

4.3.7 Energy efficient multi-RAT link adaptation sy stem design Power Efficiency and Energy Efficiency multi-RAT processing is an alternative to spectrum efficiency link adaptation processing developed for 3GPP and IEEE.

5G requirements oriented on multi-RAT networks involve the definition of metrics with the ability to enable selecting transmission modes among different air interfaces optimizing power and energy. These metrics will be integrated in a novel multi-layer multi-RAT architecture performing a scalable air interface management following several optimization criteria.

Metric definition For power and energy trends, two metrics are proposed as an alternative to spectrum efficient CQI metrics usually adopted in link adaptation processing denoted Adaptive Modulation Coding (AMC) processing [ARI09][TSE14].

• one Power Efficiency metric, named Green Link Budget (GLB) metric, applicable to all technologies, is proposed to minimize transmit power, preserve QoS and extend coverage in a point-to-point link.

This metric is deduced from link budget assessments applied on different interfaces delivering a target throughput in connection with the transported service. Normalized values are computed to compare independent interfaces exhibiting different power sensitivity ranges.

Two sub-metrics are defined as illustrated on the Figure 4-17.

- the α-metric measures relative degradations at the PHY layer thanks to a multipath-channel margin (MCM)parameter and at the propagation level regarding path-loss figures with the path-loss margin (PLM) [SUM16].

- the β-metric adapts the transmit power in computing the difference between the required power to transmit data and the available received power.

Figure 4-17 The power efficiency metric (GLB metric)

• one Energy Efficiency metric, combining a Power Efficiency metric with a temporal occupation sub-metric γ evaluated upon a time window T to transmit data.

The γ metric formula is

� � 10�� #��#� ��




mmMAGIC Public 51

Figure 4-18 The temporal occupation metric used for energy efficient metric definition

Figure 4-18 illustrates, on a time window T, the method to calculate this metric by considering the different occupation time ∆t and the idle time for a transmission mode j, TM#j, selected by the GLB metric.

The selection criterion related to time occupation of each candidate transmission mode resulting from a previous power efficiency decision, depends on the time resource allocation technique.

An extension of these power and energy efficiency metrics to multiple connections will be investigated considering traffic models and user probability in a multi-user context. A second extension of the power efficiency metric definition will include multi-relay and mesh topologies in non-standalone scenarios.

Metric calculation These metrics are calculated in exploiting several available values included in fields of the signalling and data frames.

Different methods will be designed depending on access techniques and multi-RAT scenarios.

Metric evaluation KPI will be identified to evaluate and define gains in a multi-RAT network for 5G.

Integration in multi-RAT architectures Several multi-RAT architectures may be envisioned to implement multi-RAT link adaptation metrics following a cross layer approach (see: Section 4.3.6). Cross layer approach intends for latency reduction and backward compatibility with existing mechanisms when they may integrate new link adaptation metrics and criteria. We propose to integrate Power Efficiency and Energy Efficiency metrics in the multi-layer multi-RAT architecture as detailed in the Section 4.3.6. The selection of the abstraction layer depends on involved interfaces in the multi-RAT scenario.

4.4 mm-wave access point clustering For 5G mm-wave systems, the beam-based antenna patterns will result in dynamic variations in coverage, signal quality, and channel quality as minor UE movements and rotations will change the directionality of the beams. At the same time, signal blockage from obstacles can greatly reduce the beam coverage. This leads to frequent handovers between different beams in order to provide sufficient and adequate coverage and connectivity. One option to resolve this is to use access point clusters within which the mobility of the UE is transparent to the CN.




mmMAGIC Public 52

Thus, within the cluster the handover of the UE between different nodes or beams can be perform within the cluster without any CN signalling.

4.4.1 Cluster structure The cluster is defined as group of access points (APs) in the vicinity of the UE capable of serving the UE. This cluster will be specific to each UE which is configured and may be reconfigured by the network and as the UE moves, APs can be added or removed from the cluster. To coordinate the mobility within the cluster, one of the APs is designated as the cluster head (CH) which is connected to the CN through the S1* interface and is also connected to all other APs in the cluster. Depending on the topology of the network and the quality of the backhaul, the location and role of the CH may vary, which is explored in the following section.

Figure 4-19 below depicts the physical layout of a mm-wave AP cluster.

Figure 4-19 mm-wave cluster elements

Each AP serves a set of cells – in this example four cells are served from each AP. The APs communicate over the logical interface (e.g. X2. The physical elements such as APs and cells in the cluster can have various functions and can be grouped to create new entities. In the Table 4-1 there is a set of definitions related to roles and grouping of elements within the cluster. Additional information on cell clustering illustrated by examples can be found in Annex D.

C22

C32

AP 2AP 1

C13

C11

C12

C14 C21

C23

C24

AP 3AP4

C43

C41

C42

C44 C31

C33

C34




mmMAGIC Public 53

Table 4-1 General definitions for clustering logica l and functional architecture Term Definition

cluster set of cells The set of 5G mm-wave cells that the UE can detect is called cluster set of cells. Only one cell out of the cluster set can serve the UE at a given time instant (unless the UE uses multi-connectivity as defined in the previous section). Each UE has its own cluster set of cells.

cluster set of APs The APs serving the cells of the cluster set are called cluster set of APs.

serving cell The cell that is serving the UE is called the serving cell.

serving AP The AP that is serving the UE is called the serving AP.

standby cells The cells that are in the cluster set and are not serving the UEs are called standby cells.

cluster set manager (CSM)

The cluster set of cells are managed by a cluster set manager (CSM). CSM functionalities are handled by the RRC layer of the 5G mm-wave Cluster head.

Cluster head The AP in which the data and control planes of the UE are established will be the Cluster Head of the UE for a given time. Cluster head can be an AP serving a cell in the cluster set or an AP which is not serving any cell in cluster set.

secondary AP The secondary AP is the AP to which the data and control planes of the user are re-routed from the Cluster Head via the X5 interface. The secondary AP serves one or multiple cells in the cluster set.

4.4.2 Deployment variants Depending on the type of backhaul that is available and number of RATs involved in clustering (single- or multi-RAT), different deployment variants for the cluster management can be considered.

Ideal backhaul The network structure for ideal backhaul would be quite similar to CoMP. All the intelligence is located in a central node which is responsible for all control and user plane protocol handling, including how the beams are tracked at different APs. In this case, APs are like RRH, only handling the RF part. The central node decides which AP serves the UE, and which APs are in stand-by. Since beam-forming is executed at an AP for the analog beam-forming, the beam-forming weights should be transmitted from the central node to the AP e.g. over the standardized interface CPRI (Common Public Radio Interface). This method eases the coordination between multiple APs and avoids conflicts between different APs but stresses backhaul and central node. The network topology is shown in Figure 4-20.

Figure 4-20 Network topology for ideal backhaul




mmMAGIC Public 54

As a large amount of raw I/Q data is transmitted over fibre, one potential way to do this is to use Radio over Fibre technology where the analog signal is transmitted over fibre and at the same time the beam-forming weights are transmitted from the central node to the AP. The central node takes care of packet transmission from different APs to a UE when the serving beam of this UE needs be switched back and forth between different APs.

Non-ideal wired backhaul If the network is deployed with a non-ideal wired backhaul, e.g., using a bandwidth limited backhaul, it is still possible to utilize a central node which hosts the delay insensitive part of the protocol stack. Each access node has a protocol stack up to RLC* layer. It has intelligence to decide how to use its own resources and is responsible for its own beamforming functionality. The network topology for wired non-ideal backhaul is shown in Figure 4-21.

Figure 4-21 Network topology for non-ideal wired ba ckhaul

There are two ways to set up the clusters for the wired non-ideal backhaul: distributed mode or centralized mode. In distributed mode, the CH is located at one of the APs in the cluster. In centralized mode, the CH is located at the central node. For distributed mode, when the serving beam for a UE needs to be temporarily switched between different APs within the cluster, those APs, other than CH in the cluster receive packets for the UE from the AP serving as CH. Data forwarding at the other APs can be performed either at the RLC or at the MAC layer. If data forwarding is at the RLC layer, a relay RLC feature supporting multi-hop needs to be supported at the CH and the other AP while the MAC layer at the other APs does not need to care about segmentation requirements. If data forwarding is at the MAC layer, the MAC layer needs to take care of segmentation in case the RLC PDU is too large to be transmitted. For centralized mode, APs in the cluster receive packets from the central node. The PDCP protocol at the central node needs to take care of reliable transmission from different APs to the UE during beam switching. As the delays between the APs can be significant when using non-ideal backhaul, the centralized mode may not be sufficiently fast to respond to the varying propagation conditions, whereas the distributed mode executes the beam steering command at each AP which minimizes the delays.

Wireless self-backhaul For wireless self-backhaul, the CH location depends on the topology of the cluster. Besides the coordination of beam switching, the cluster head handles the majority of data to be sent to and to be received from the UE. For wireless self-backhaul, in order for the cluster head to coordinate the inter-AP beam switch sufficiently fast, it is assumed that there is only one hop between the cluster head and the APs in the cluster. In Figure 4-22, AP1, AP2 and AP3 can be in one cluster (cluster 1) and AP3, AP4 and AP5 can be in another cluster (cluster 2). However, AP2 and AP4 cannot be in the same cluster since there is more than one hop between AP2 and AP4.




mmMAGIC Public 55

Figure 4-22 Clusters in wireless self-backhaul

The network topology for the wireless self-backhaul is shown in Figure 4-23. The network controller (NC) and the local gateway (L-GW) are the physical entities responsible for the CP and UP respectively for the self-backhauling cluster.

Figure 4-23 Network topology for wireless self-back haul

When the serving beam for a UE needs to be temporarily switched between different APs within the cluster, other target APs will begin to obtain packets from the CH. The packets already at the source AP may be forwarded to the target AP either through an RLC relay solution, or a MAC layer based solution. If the RLC relay solution is used, the CH RLC needs to be enhanced so that it won’t delete data from its buffer until it receives the RLC ACK from the UE. In this way, during the beam switching procedure, even if some packets are forwarded from CH to other APs when the target AP temporarily serves UE, these packets are still kept in the CH buffer. Then, if UE needs to be served by the old AP again, it is not necessary to forward packets back and forth between source and the target AP. For the MAC layer based method, the RLC at the CH does not need to be changed but the source and target AP MAC layers need to be enhanced with a segmentation feature and packet sequence number. The RLC relay solution requires a larger buffer at the CH, whereas the MAC layer solution requires additional processing at each AP, which would increase the delays.

Single-RAT The standalone, single-RAT scenario requires that APs will have full UP protocol stack implemented. For tight integration of access points logical interface between APs is needed in order to enable re-routing PDUs at RLC level. Cluster architecture for standalone mm-wave cells in single-RAT scenario is shown in Figure 4-24.




mmMAGIC Public 56

Figure 4-24 Cluster architecture for standalone mm- wave cells in single-RAT scenario.

Multi-RAT In the multi-RAT scenario shown in Figure 4-25, there is a central node which provides a split on the PDCP* level. As an example one Wide Area (WA) node (with carrier frequency < 6GHz) and two mm-wave nodes are depicted. The access nodes are connected with central node via a fronthaul split – fronthaul interface is denoted as Fs.

S-GW MME

5G-NB1 5G-NB2

UE

PHYMACRLC*

RRCPDCP*

PHYMACRLC*

RRCPDCP*

S1*CS1*U

X2*

Uu*PHYMACRLC*

RRCPDCP*

Control plane

User plane




mmMAGIC Public 57

Figure 4-25 Cluster architecture for the multi-RAT scenario

It is worth noting that in such multi-RAT scenario it is possible: (1) to re-route PDCP* PDUs to RLC* from the Central Node to the 5G-AP over fronthaul split. In such case additional delay might be introduced when compared to option (2) and routing via PDCP* located in the central node requires additional overhead. Another possibility is to re-route RLC PDUs from AP1 to AP2 over dedicated logical interface (denoted here as X2* but might be also a new logical interface). This architecture has much in common with the solution described under “Non-ideal wired backhaul” above with few differences. Here there are no assumptions regarding physical connection between mm-wave nodes that’s why we exclude possibility of re-rerouting on MAC level. Re-routing on MAC level requires tight synchronization level on TTI level, instead we see rerouting on RLC or PDCP level since these protocols are much less delay sensitive than MAC.

4.4.3 Mobility in cell clusters Beam switching For the beam switching, the UE measures the beam quality based on a training signal (TRN) and reports it to the AP. During the training period, both the Tx and Rx are trained for the uplink period and downlink period. Based on the measurement report, if the AP determines that it is an inter-AP beam switch, the report will be forwarded to the CH. After the decision by the CH, the AP informs the UE to switch the beam. The UE switches to the target beam and the network transmits/receives the data via the target beam.

As each AP supports flexible TDD and schedules resources of its own, the scheduling decision of APs within a cluster at one specific time instant can be different due to different instantaneous traffic demands. For example, at one specific TTI or time instant, the CH may want another AP in the cluster to send a DL test beam for a UE served by the CH, however the other AP in the cluster may want to schedule UL for its own UE.

Central Node

S-GW MME

5G-AP1 (mmW) 5G-AP2 (mmW)

UE

PHY-mmW

MAC-mmW

RLC*

S1*CS1*U

X2*5G-AP (WA)

PHY-WA

MAC-WA

RLC*

RLC*

RRC

PDCP*

PHY-mmW

MAC-mmW

PHY-WA

MAC-WA

UP

PDCP*

CPRRC

PDCP*

Fs

Uu*

Control plane

User plane

PHY-mmW

MAC-mmW

RLC*




mmMAGIC Public 58

To solve this conflict, one solution is to have some commonly agreed fixed DL and UL timeslots within the cluster. These commonly agreed fixed DL and UL time slots are used by all APs in the cluster to send a DL test beam or a receive UL test beam. Both the primary serving AP (P-SAP) and the assisting serving APs (A-SAP) decides how to use its other time slots. Figure 4-26 shows how this solution works.

Figure 4-26 Common time slots for beam tracking pur pose

• The coordination among APs within a cluster can be either distributed or centralized. In distributed coordination, the AP itself decides which UE to track according to the request from the CH. The information from CH to AP can include Beam and UE info

• Information to help AP calculate priority for each UE

The AP itself decides which test beam to send or receive for a specific UE.

With centralized coordination, each AP reports the UEs served by it, which UEs want the neighbour AP to track them, and its load information to the central node. The central node informs the AP in the coming fixed DL/UL timeslot which neighbour UE the AP should track. The AP then decides which test beam to send or receive for a specific UE.

Intra-AP beam switch

For the intra-AP beam switch, the AP can make the decision based on the measurement report. The AP informs the UE in the original beam to switch to the target beam. Optionally, the AP can also inform the CH that the beam is switched. The UE switches to the target beam and the data can be transmitted in the target beam.

Inter-AP beam switch

If the AP determines that it is an inter-AP beam switch, the report will be forwarded to CH from the current serving AP. The CH will request the target AP for beam switching. If positive feedback is received from the target AP, the CH will inform the current serving AP, which informs the UE in the original beam to switch beam. After that, the UE switches to the target beam and the target AP transmits the data in the target beam.

Fast recovery from beam-forming failure

When there is a failure in the serving beam due to any reason, it is difficult to transmit the beam switch command in the serving beam, and the UE and the network should switch to the backup




mmMAGIC Public 59

beam blindly based on prior agreement. In order for the blind beam switch to work, both UE and cluster head should know which one is the first backup beam. There are two possible solutions to identify the first backup beam.

• Solution 1 - UE control: Based on the last measurement report, the best beam except the serving beam will be regarded as the first backup beam. There is a possibility that there is no resource on the selected backup beam since the network is not involved in the selection.

• Solution 2 - Network control: The network informs the UE of the first backup beam during initial access and optionally during any transmissions whenever the first backup beam should be changed. There is more overhead with this technique due to the additional information during normal transmission.

When there is a failure in the current serving beam, both the network and UE will switch to the identified first backup beam. In the network, if the first backup beam and the current serving beam belong to the same AP, the AP itself can coordinate the switch. If the first backup beam and the current serving beam belong to different APs, the CH will be involved in the blind beam switch.

4.4.4 Cluster management During UE mobility, the cluster structure will be changed, which means cluster management will be an important part in the context of mobility management. Cluster member change includes cluster member addition and removal. When the cluster head should be changed from one node to another node, it is called cluster member relocation. For cluster management, two modes are introduced, one is network controlled mode, and the other one is UE controlled mode. The network controlled mode is the traditional mode, and UE controlled mode is introduced to reduce latency.

Network-controlled mode For the cluster update, the UE’s can measure

• the common reference signal if available, such as PSS/SSS, in case the target node is out of the serving cluster. In the absence of broadcasted common reference signals, the UE is configured by the network to monitor dedicated reference signals

• all the detectable APs, or it can measure only the list of APs that it receives from the CN/CH.

The measurement report will be sent to the cluster head first, and the report will include e.g., AP ID, Beam ID, and signal quality.

• The quality metric could be path loss, reference signal receive power (RSRP) or reference signal receive quality (RSRQ), Eb/No, etc.

• The measurement criteria can be periodical or event triggered.

• The UE can report the N APs which have the strongest signals, or the APs whose signal is larger than a threshold. In the UE-centric concept, UE doesn’t know which is the serving AP and which APs are in the cluster, so the UE will report the measurement report based on the information that it can know.

Based on the measurement report sent by the UE, the cluster head can check which cluster member can be added / removed, or if the cluster head should be re-located from one node to another. If CH doesn’t know the information (address, etc.) of some APs, it will send the information to the NC for assistance. In some cases where the CH cannot reach the new APs




mmMAGIC Public 60

or new CH, the CH cannot handle the cluster management, and the NC will coordinate the cluster update. UE will not be involved in the update procedure, so that it is transparent to UE.

Intra-cluster management without CH relocation

When the CH obtains the measurement report for cluster update from the UE, if it is identified that it is only for cluster member adding, the CH can handle it by itself. In some cases the CH doesn’t know the information of the AP, and it can request NC for help.

When adding a cluster member, the NC will send the information (address, etc.) of the AP back to the CH (and the AP), and CH can add the AP to the cluster with the assistance information, which happens when the network is newly deployed and the CH doesn’t know the details of the neighbouring APs.

When the CH obtains the measurement report for cluster update and it is identified that it is only for cluster member removing, the CH can remove the cluster member directly. Optionally, the CH may inform the NC of the action. During the removing procedure, the acknowledgement from the removed AP is also optional. If no remove acknowledgement is received, a timer can be used in the AP and the timer will be reset when the AP will receive any command from CH. When there is time out, the AP will be regarded as removed.

Intra-cluster management with CH relocation

When the CH obtains the measurement report for cluster update from the UE and it is decided by the CH that it is a cluster head relocation, but the target location of the cluster head is still in the range of the current cluster (for example another cluster member), the cluster head relocation can be performed among the original cluster head and target cluster head. After it is updated, the status will also be informed to the NC and L-GW, and later the NC and L-GW will contact the target CH.

The procedure may be performed without a measurement report from UE. In a network with wireless self-backhaul, the AP whose beams are frequently used may also be selected as the new cluster head if it is capable of being a cluster head (e.g., with respect to processing capacity, buffer size, backhaul capacity, etc.).

Inter-cluster management

In some cases, the serving CH cannot handle the cluster management, since based on the measurement report, the proper cluster head might be out-of-range of the current CH, so the NC will be needed to coordinate the cluster update.

The NC will check the availability of the new cluster member and cluster head. With acknowledgement from the new cluster member and cluster head, the NC informs cluster head update to the new cluster member, the new cluster head, the original cluster member and the original cluster head. After the updating, the NC will also inform this to L-GW.

For wired backhaul, the APs can reach each other so the cluster management is mainly Intra-cluster management. This case mainly applies for wireless self-backhaul.

UE-controlled mode A NW controlled inter-cluster management following traditional handover spirit may bring along switching latency. To reduce this latency, a UE-controlled manner is introduced in this section.

Intra-cluster management

For intra-cluster management, it still follows the same procedure as in network-controlled mode, i.e., the CH in the serving cluster controls the switching behaviour based on measurement report from the UE.




mmMAGIC Public 61

Inter-cluster management

Compared with network-controlled mode, the inter-cluster management is the main differentiating point. The core part of this alternative is 1) CP preparation before the switching, and 2) UE initialized activation during the switching.

NW pre-preparation includes the following aspects:

• Pre-download L3 UE context to the selected AP(s).

• Relevant AP(s) wake up to be prepared for data transmission and reception, and transmit reference signal for necessary measurements.

• Prepare (potential) candidate cluster(s) for the UE.

UE initialized activation may include the following steps:

• Target beam measurement configuration: the NW pre-configures the measurement which triggers the switching.

• Target AP activation: the UE activates the AP via a Layer-2 signalling from the UE. The DL transmission can be resumed after the AP activation if there is already data pre-buffered in the AP. The UL transmission can be done via the target AP directly.

• Target cluster head activation: it is the target AP that directly communicates with the UE after the switching which activates the cluster head, via a Layer-2 signalling from the AP. The DL transmission can be resumed after the cluster head activation if there is already data pre-buffered in the cluster head.

Procedures for cell clusters

Random Access Procedure

For a Random Access an UE that is UL synchronized to a serving cell is not automatically UL synchronized to other neighbouring cells. In real deployments, cluster set may comprise cells served by near and far APs requiring different timing advance values that need to be obtained by the RACH procedure. The timing advance values are updated by each cell individually. In order to initiate RACH procedure, the UE sends the RACH preamble using a synchronized beam ID to address target AP.

Addition of cells served by secondary APs to the cluster set

The procedure of extending the cluster set by cells served by secondary AP is based on information exchange between UE, Cluster Head and Secondary AP. The message flow for such case is presented in Figure 4-27.




mmMAGIC Public 62

Figure 4-27 Addition of cells served by secondary A Ps to the cluster set

Accessing the cells served by secondary APs

• PHY/MAC/RLC configurations are transferred to the UE via higher layer RRC signalling

• UE needs to be aware of any PHY/MAC/RLC configurations of cells served by secondary APs

Most of the RRC functions are handled by Cluster head, e.g., measurements report, RRC configuration/reconfiguration, UE context transfer. The RRC master is responsible for configuration of secondary APs.

4.5 Initial access, mobility management and handove rs The initial access to the mm-wave RAT is a critical element and needs to be optimized for both standalone and non-standalone deployments. Also efficient mobility management in the mm-wave RAT is needed to guarantee a seamless service experience for users that are moving. It should be designed to support seamless mobility with minimal use of resources. As the mm-wave RAT operates at higher frequencies, the mobility solution has to support mobility between different beams either in a loss-less or seamless fashion depending on the use case. As the mm-wave RAT supports multi-connectivity, both between different mm-wave nodes as well as inter-RAT multi-connectivity, e.g., with LTE-A or low frequency 5G RATs, the mobility features should support coordination features between the nodes even when the backhaul between them has limited capacity or introduces some latency.

4.5.1 Low frequency RAT assisted initial access The initial access is typically performed by the UE after it is turned on and the objective of this procedure is to establish a RRC connection with the selected mm-wave AP responsible for a small cell. The performance of the applied initial access scheme directly impacts the user experience. One of the performance-critical challenges is to achieve beam alignment within a short time interval during the initial access phase, by exploiting the limited a-priori information on the preferred transmission direction at both ends of the link. In a non-standalone deployment, i.e., a heterogeneous network, where mm-wave small cells are located within the coverage area of a macro cell operating at low frequency, low frequency RAT assisted initial access is a

X2*-AP: Addition Request (UL GTP Tunnel Endpoint)

X2*-AP:Addition Request (DL GTP Tunnel Endpoint)

RRC (CSM) processes measurement report and decides which cells to add to cluster set

UE Cluster Head Secondary AP

RRC Connection Request + Measurement report

Different tunnels for each UE bearer

RRC Connection Setup• Identity of the established SRB• PHY/MAC/RCS configuration of the connected cell

RRC Connection Setup Complete




mmMAGIC Public 63

practical approach, that can be more efficient than the standalone approach. More concretely, from a UE power consumption and latency standpoint, the system efficiency can be considerably improved in a range of scenarios, by exploiting the assistance from a low frequency RAT to the largest possible extent.

The initial access process is essentially composed of three tasks. These tasks are the following:

• Downlink timing/frequency synchronization

• System information acquisition, and

• Uplink timing synchronization (if uplink data transmission in the mm-wave small cell is required).

In what follows, the relevant aspects on the possible low frequency RAT assistance to the three preceding tasks are described.

Downlink synchronization Downlink synchronization is the first task to be performed by the UE. To enable the cell detection, the mm-wave AP is assumed to transmit some synchronization signals (SSs) at particular time-frequency resources with a certain periodicity. Similar to LTE, two synchronization signals, namely primary synchronization signal (PSS) and secondary synchronization signal (SSS), can be employed to acquire symbol/slot/sub-frame timing, in order for the UE to obtain the cell ID. With the aim of achieving a fast mm-wave small cell detection, the low frequency RAT can transmit a signal to the UE, containing information about the frequency and cell IDs of the mm-wave small cells within its coverage area. With this signalling, the UE does not need to perform an exhaustive search over the whole small cell ID space, but it only tries to detect the signalled cell IDs. As a consequence, the UE power consumption for downlink synchronization is significantly reduced. It is envisioned that a mm-wave AP may support different levels of SS coverage enhancement, and each level of coverage enhancement may correspond to a particular SS design. To aid the UE detection of the SS with different levels of coverage enhancement, the low frequency RAT can also signal the supported coverage enhancements to the UE so that the UE can determine the exact SS pattern transmitted throughout the mm-wave small cell.

System information transmission As mentioned above, the second task of the initial access procedure is to acquire the system information which provides to the UE all the essential information used for accessing the network. The coverage of the system information determines the coverage of the cell. Some of the system information components are changing fast on the basis of one or several mm-wave RAT frames, but other system information parts may vary relatively slow. Specifically, the system frame number changes for each mm-wave RAT frame, however, other system information such as system bandwidth, random access resources, paging resources and scheduling of other system information components are typically semi-static. For this reason, it can be energy efficient to convey some of the slowly varying system information by exploiting the existing low frequency RAT. On the other hand, the quickly changing system information components, such as the system frame number, need to be transmitted by the mm-wave RAT. To guarantee sufficient coverage, efficient schemes of transmitting the system information parts by the mm-wave RAT need to be studied more systematically.

Uplink synchronization It is important that efficient uplink data transmission in the mm-wave RAT is supported as well, especially for “UL data traffic dominant” use cases. UL synchronization needs to be achieved prior to any UL packet transmission to ensure that all the co-scheduled UEs’ UL signals arrive at the eNB around the same time within the CP duration. In LTE, the RACH procedure is designed to accomplish this task. Specifically, based on the received UE RACH preamble signal, the eNB can determine the timing advance value for the UE. The radio resources for the preamble transmission are typically signalled in the system information and, as mentioned




mmMAGIC Public 64

above, such system information can be signalled by the low frequency RAT. This can be viewed as a basic assistance to the UL synchronization. To ensure a certain UL preamble coverage, if several preamble formats are supported by the system, the low frequency RAT can signal a particular preamble format to the UE in order to realize the network assisted preamble format selection. In case of contention free RACH, the low frequency RAT can signal the exact preamble sequence to be used by the UE. During the RACH procedure, upon the reception of the preamble signal, the eNB can send a RACH response signal to the UE. If the same frame structure is used for both low and high frequency RATs and both RATs are synchronous on the level of sub-frame or TTI boundary, the RACH response signal can be transmitted by the low frequency RAT as well. In addition to the above mentioned options for UL synchronization assistance, the low frequency RAT may also offer other assistance to the possible beam alignment operations during the initial UL synchronization procedure.

Beam-training In addition to the aforementioned exchange of slowly changing system level information and synchronization, the low frequency band can be used to help with beam-training. Given suitable signal processing mechanisms, the position and orientation (or AoA and AoD information of the signal) of the UE relative to a low-frequency eNB can be determined (see e.g., [KW13]). If low-frequency eNB and high-frequency eNB are co-located, or their position and orientation relative to one another are known, this allows to derive coarse-grained angle information for beam-training of the mm-wave RF frontend, allowing to significantly speed up the initial access procedure. The accuracy of this angle information depends on a range of factors, specifically antenna geometry, beamforming algorithms used, staleness of the angle information, radio environment (and in particular frequency specific properties of the radio environment), UE mobility, etc. Depending on these factors, low frequency assisted beam-training may or may not be useful in a given scenario.

4.5.2 Energy efficient initial access In LTE, a significant amount of the network energy consumption is caused by the broadcasted system information, periodically transmitted on the common channels. This system information, e.g., the Cell-specific Reference Signal (CRS), primary and secondary synchronization signal (PSS & SSS) is used to enable the UEs to access the system and enable handovers between different cells. For the mm-wave RAT, the connection is assumed to heavily rely on beamforming resulting in a more complicated and cumbersome transmission for the common broadcasted signals. Thus, the system information should be primarily transmitted as dedicated signals only to the targeted UEs in the proper directions. Additionally, in a densely deployed scenario, the coverage area of multiple APs may overlap and may have similar or identical system information. In that case it may be sufficient that only some APs transmit the system information, e.g., a high power Macro BS transmits the system information while the low power pico/femto BSs only transmit UP data.

4.5.3 Fast handover/scheduling in standalone mm-wav e RAN In this section we consider a standalone mm-wave RAN, that is, a cellular network that only uses communications beyond carrier frequencies of 6 GHz. This is a significant challenge since the network cannot fall back to legacy technologies such as LTE-A in case that a UE cannot communicate using mm-wave due to, e.g., blockage. Hence, timely handovers and accurate scheduling are critical to ensure the reliable operation of the network. While legacy cellular networks provide mechanisms to handle both handover and scheduling, the variability of the mm-wave channel is much larger than for communications below 6 GHz. As a result, handling such issues using existing management protocols is prohibitive in terms of overhead and highly inefficient as well. The problem is that handovers are very frequent, resulting in an extremely large number of control messages. Hence, taking handover decisions locally is fundamental. To




mmMAGIC Public 65

this end, standalone mm-wave RANs should form node clusters with local controllers that handle handovers and take scheduling decisions (see also the cluster management mechanisms introduced in Section 4.4). Such clusters may include both wired and wireless base stations, that is, base stations which use mm-wave not only to serve UEs but also to relay traffic to the core network. The aforementioned controller must also take into account such wireless base stations, and the resulting self-backhauling. For instance, if a wireless backhaul link suffers blockage due to a moving obstacle, it must seamlessly find an alternative way to deliver data to the core network.

The local controller must be aware of which UE is in range of which access point. In particular, it must know whether a UE is just in range of an access point, or whether it actually is using multi-connectivity features to be able to switch easily from its current access point to a new one in case of, e.g., blockage. Even though the controller is local, providing such timely information incurs overhead. Hence, this leads to a significant number of trade-offs. First, the network must adjust the frequency and detail of control informat ion to the fluctuation rate of the node cluster. For instance, if the node cluster is deployed in a static environment it would be inefficient to provide the same amount of control information than if the cluster is located in a crowded area where pedestrians cause blockage frequently. Second, the cluster controller must decide on the benefits of switching a UE to a diffe rent access point that can provide a better link quality compared to the cost of rerouting traffic to that new access point. For instance, if the controller is aware of mobility information, and expects the UE to only be in reach of the new access point for a very short amount of time, it might not pay off. Finally, a third trade-off that the controller must take into account is the frequency of beam training compared to the expected mobility of the user. If a user is expected to remain at a certain location, it does not need to perform beam search as often as a user which is moving and thus must continuously evaluate which access point is most suitable to connect to next.

Multi-connectivity and relaying allow for multiple options for when and where to hand over and efficient mobility management solutions need to take these trade-offs into account (impact on self-backhauling, load balancing considerations, etc.). The mobility management also has a direct impact on the backhaul and may require traffic rerouting between cluster APs. The overhead associated with a handover is impacted by the beam training mechanism. Reducing this overhead, for example by aiding/preparing handover decisions through location information, is crucial for dynamic scenarios with potentially frequent high handovers. Directly related to this beam training in face of mobility are beam width adaptation strategies. The wider the beam, the less frequent beam adaptation is necessary, and hence the beam width can be optimized for a given user mobility (e.g., based on a past or predicted mobility pattern and UE speed).

4.5.4 Fast handover/scheduling between technologies In this section, we consider the case of a RAN which supports both mm-wave and one or more legacy technologies such as LTE. This case is less demanding than the one in the previous section since UEs can always fall back to more robust technologies at the price of worse performance in terms of throughput and latency. Still, a significant advantage of legacy networks operating below 6 GHz is that their performance is easier to predict. Since blockage and other physical layer effects do not play such a significant role in, e.g., LTE-A compared to mm-wave, it becomes feasible to build reliable coverage maps of legacy technologies . Such maps may be preloaded on each UE and updated at large intervals, or may be available at a central instance. In the former case, the UE can decide autonomously whether to request a handover to, e.g., LTE. In the latter case, such decisions are performed centrally. This incurs a higher cost in terms of control overhead, but ensures that the coverage map in use is updated frequently and allows the network to prepare handovers in advance. This results in a trade-off which strongly depends on the particular environment in which the network is deployed. For instance, in a dense and highly dynamic network, local decisions at the nodes may reduce control overhead significantly. In order to design the mechanisms that take these decisions, either




mmMAGIC Public 66

locally or centrally, it is crucial to identify heuristics that hint at when a handover to a legacy technology should be performed. Such heuristics can be found, e.g., by simulating a large set of scenarios and using the results to deduce in which cases a handover is beneficial. This off-line knowledge can be further extended by allowing the nodes and/or the network controllers to learn during network operation.

While the availability of legacy technologies in the network ensures robust performance by means of the aforementioned handover decisions, switching from a mm-wave link to, e.g., an LTE-A link significantly changes the capabilities of the connection. In particular, such a change implies a dramatic rate variation since mm-wave can provide rates in the order of gigabits per second, while LTE-A is limited to hundreds of megabits per second. Frequent handovers among both technologies might result in large and drastic rate fluctuations that might hinder the proper operation of the application using the network. To address this, the local and/or central entities that take the handover decision should provide cross-layer information to the application layer on the expected future throughput variations. For instance, a video streaming application may choose one out of a number of possible video quality settings to adjust to the available throughput. Frequent rate variations may induce the application to change the video quality very often, which becomes immediately evident to the user and significantly reduces the Quality of Experience (QoE), resulting in very rough handovers. However, if the entity deciding on handovers provides information to the application regarding how long a certain data rate will be available according to the expected user mobility, the application may decide to use short intervals of very high rate to buffer more video data instead of switching to a higher quality. This exploits the transient availability of mm-wave links, improves QoE, and results in a seamless experience for the user.

4.5.5 Active mode mobility In a beam-based solution with large antenna arrays provisioning many possible candidate beams, all beams cannot transmit reference and measurement signals in an always-on, static manner. Instead, the transmission is divided into ‘Link Beams’, which transmit most of the CP and UP data, and ‘Mobility Beams’ which transmits a ‘Mobility Reference Signal’ (MRS), The ‘Mobility Beams’ may have wider coverage than the ‘Link Beams and the connected AP can select a set of relevant ‘Mobility Beams’, which it then instructs the UE to measure on and report to the network. It is also possible for the UE to measure the MRSs blindly and report the measurement results. As the UE measures the MRSs, the network may reconfigure the beam characteristics, such as transmission point and direction which enables both intra- and inter-node handover. For the mobility to work efficiently, the involved APs need to maintain beam neighbour lists, exchange beam information, and coordinate MRS usage.

If the UE has an ongoing data transmission, the measurements could be triggered by link quality degradation. In the absence of a data transmission, the quality of the mobility links or control signals transmitted to the UE could be monitored.

The measurement results can then be transmitted either to the serving node, or to each node transmitting a MRS. However that requires a previously obtained uplink synchronization which may or may not be available. Alternatively, the UE may only report back to the serving node and the best neighbouring node which again would require an uplink synchronization. In general, the MRSs are only transmitted upon demand and the network decides which candidate beams, or neighbour beams, should be activated. In order to transmit the measurement results to other nodes than the serving node, it is necessary to apply a correct timing advance which may differ from the serving node. If the network is tightly synched with small ISD, it may suffice to reuse the old synchronization and the UE may deduce if it is sufficient. Thus the handover procedure will be slightly faster as the UE does not need to re-synch to the network.




mmMAGIC Public 67

4.5.6 Mobility on demand We envision wide range of mobility options for the 5G mm-wave systems ranging from no mobility (stationary meters, Customer Premises Equipment (CPE)) to high-speed trains running at 500 km/h. It is worth noting that some MNOs (Mobile Network Operators) observed that only minority of subscribers are actually mobile.

Mobility types can be differentiated also in another dimension by various levels of service continuity: seamless mobility, nomadic mobility, sporadic senders.

Figure 4-28 Principle of mobility on demand.

In the proposed solution of mobility on demand shown in Figure 4-28, the mobility of high-speed users will be handled in a manner similar to LTE-A – by the MME entity located in the core network. For nomadic users or static devices, mobility can be enabled only when need (e.g., when the users change location). In such case, mobility management functionality could be delegated from the core to the radio access part of the network or can be omitted entirely if it is known that the device anyway never moves (e.g. sensor attached to fixed object). One of the considered solutions is that the cloud RAN (see: Section 3.4.2) can contain a local mobility anchor dedicated for such a low- or no-mobility users.

It is expected that such an approach will bring several benefits to the MNOs. First of all, it will optimize traffic flows and network resources. It will also provide TCO optimization: not all devices need full mobility support. The resources for the core network will be reduced and traffic backhauling to the centralized cloud can be avoided.

4.6 MAC and RRM MAC and radio resource management (RRM) are key components of the RAT. The main role of RRM is to optimize the efficient utilization of radio resources, considering the benefits offered by the existing adaptation techniques, and to improve the end user performance according to the configured QoS parameters. As the network algorithms are not standardized, it offers immense flexibility with design, and an opportunity to tailor the algorithms to the specific




mmMAGIC Public 68

requirements of next generation telecommunication systems. Some of the existing algorithms, which can be easily adopted with revised features, are packet scheduling, admission control, power and interference control algorithms. In addition, since the LTE-A based current systems have an adjustable design topology, there is immense scope to optimize packet scheduling, as the scheduling can usually be realized in frequency and time domain. When considering the use case scenarios and deployment aspects of mm-wave systems, various RRM functions and features will have to be reviewed and improved to address new challenges. For example: when examining the signalling support for uplink adaptation and packet scheduling, parameters such as Sounding Reference Signal (SRS) bandwidth, duration; and SRS period and time offset will have to be considered. In addition, other entities like the configuration of buffer status reports (BSR) and power headroom reporting will have to be considered. Since mm-wave systems are prone to frequency disruptions and interference, better techniques for interference management, and concurrently power setting management will have to be introduced. Yet another fundamental aspect worth addressing is the efficient monitoring technique to retain the UE in micro-sleep active state to reduce the power consumption, whilst providing high QoS and connectivity. Specifically for mm-wave, the option of self-backhauling brings about additional challenges in terms of resource allocation in time, frequency and space between access and self-backhaul.

4.6.1 Coordination mechanisms to minimize inter-cel l interferences in the presence of beamforming

In ultra-dense standalone deployments, the presence of significant beamforming gains can lead to bursty and unpredictable inter-cell interference. Particularly when users have limited beamforming capabilities at the receive side, inter-cell interference can be severe in scenarios comprising a high density of access nodes per unit area. This is aggravated by the fact that practical beamforming can exploit opportunistic reflections to reach users in NLOS conditions. Such reflections can lead to unpredictable interference towards other users unless basic coordination of the beamforming vectors is envisioned (e.g. with coordinated beamforming), or some basic RRM technique is applied. Standalone deployments lack a suitable anchor point for inter-node coordination and control, which could minimize inter-cell interference through smart allocation of resources. In this case, distributed multi-node coordination is deemed essential.

One simple condition for the appearance of such interference is that the desired user and some other user located in a neighbour cell are aligned with respect to the neighbour interfering base station (Figure 4-29). Beams intended for UE B will reach UE A, perhaps even with stronger level than the serving beam, and likely following an intermittent traffic pattern hence creating strong interference. This condition can appear in ultra-dense LOS scenarios where an interfering 5G-NB is in line of sight conditions with respect to both UE A and UE B.

A more general condition for interference can however arise by virtue of multipath. The presence of obstacles together with beamforming can lead to strong multipath components thus making inter-cell interference much more likely to appear (Figure 4-30). Some coordination among cells at beam level may be effective to prevent this.




mmMAGIC Public 69

Figure 4-29 Simple condition for the appearance of inter-cell interferences with

strong beamforming, in the absence of reflectors

Figure 4-30 General condition for the appearance of inter-cell interferences with strong

beamforming, in the presence of reflectors

A convenient tool to support a broad range of inter-node coordination strategies can be a “beam labelling” technique. All transmitted beams can be conveniently labelled in the form of a beam indicator, which could be signalled to the users by means of a “Beam Indicator Channel”:

• Beam indicators can comprise any labels, such as e.g. an integer number in a predefined grid of beams, the corresponding angles in a spherical coordinate system, or the intended UE to be served

UE A

UE B

Condition for interference: UE A, UE B and interfering

NB are aligned

Serving beam Interfering beam

SERVING 5G NB

INTERFERING 5G NB

CELL A

CELL B

UE A UE B

Serving beamInterfering beam

CELL A

CELL BReflected beam

SERVING 5G NB

INTERFERING 5G NB




mmMAGIC Public 70

• The Beam Indicator Channel would contain this information so that any user from the surrounding cells can easily acquire it

• Beam indicators should be cell-dependent, or linked with a suitable cell identifier (cell ID) so that users can acquire both the interfering beam and the originating cell ID

• If a beam transmitted towards a given user comprises more than one sub-beam, it would be desirable to label them separately so that any interfered UE can discriminate between the constituent sub-beams

In the presence of interference, the UE will detect at least two beam indicators in the same time-frequency resources: one for the serving beam and another for the interfering beam (Error! Reference source not found. ). Hence the UE should be able to acquire both by means of orthogonal sequences, cover codes, or any other suitable multiplexing technique, with the objective of protecting the information and conveying also the corresponding cell ID. It is not desirable that the UE acquires the interfering cell ID through standard mechanisms from cell selection and reselection (e.g. from a broadcast channel), because it may be difficult to relate an interfering beam with any of the neighbour cells’ ID that are detectable by the UE.

Figure 4-31 Acquisition of beam indicators by an in terfered UE for the proposed inter-cell beam

coordination mechanism

Beam indicators can be reported back to the serving cells by means of a special interference control message. This message conveys pairs of (interfering cell ID, interfering beam indicator) as detected by users, and will be reported periodically or upon certain conditions such as a request from the BS or the appearance or disappearance of an interfering beam.

The 5G-NB will collect multiple interference control messages from the users to populate a table of interference relationships, in such a way that the 5G-NB can acquire an accurate picture of the interference relationships with beams from other surrounding cells. As a result, cells can agree on any suitable coordination strategy to minimize interferences, spanning from advanced coordinated beamforming (when detailed channel state information can be exchanged among the cells at the right timing), to simpler RRM mechanisms based on coordinated partitioning of the resources.

UE SEES DIFFERENT BEAM INDICATORS IN THE SAME

TIME/FREQUENCY

SERVING BEAMINTERFERING BEAM

Serving BeamIndicator

Interfering BeamIndicator

Desired signal Interference

UE




mmMAGIC Public 71

Mobility can impact the proposed mechanism as a result of beam tracking effects. Ideally, beams should follow the users’ trajectories, and for this reason any strong interference at one instant might disappear shortly after as a result of beam steering. For this reason the proposed coordination technique is more likely to work properly in slow mobility conditions.

The key element for such coordination is the ability to acquire beam labels from other cells. Beam labels should be preferably based on target UEs and not on any angles or coordinates, in order to keep the labels unchanged under mobility. If a beam comprises multiple sub-beams, the constituent sub-beams should also be separately labelled on the basis of a common beam label (e.g. with different “sub-beam labels”). In this way the interfering 5G-NB could switch off only the problematic sub-beam upon interference, and not the whole beam. Any further coordination of resources at sub-beam level would be hard to justify, as it would involve complex signalling to the users; hence simple muting of sub-beams could suffice in this case to tackle interference issues. More detailed information that complements description in this subsection can be found in Annex C.

4.6.2 Early triggering of MAC-level retransmissions in fully or partially centralized deployments

The presence or absence of MAC-level retransmissions (i.e., HARQ) essentially depends on the transmission time interval (TTI) and the residual block error rate that the system is designed to operate with. Since data rate is expected to be very high, the processing delay of advanced HARQ may cause longer delays than simple retransmission and soft combining [MMMAG15-IR41-2]. Hence an important question to answer is whether ARQ/HARQ is needed at all, given the short channel occupancy times. This question can only be answered on a case by case basis, since there may be use cases where certain combinations of KPIs (like stringent reliability and availability) demand particularly robust links against channel impairments, which can be achieved with the use of retransmissions and the correspondingly low residual error rates. In other cases, retransmissions might be dispensable. Given the variability of KPIs and use cases we cannot discard the presence of HARQ retransmissions, at least in a first analysis.

HARQ relies on successful decoding of received packets to deliver ACK/NACK indications to the sender. This requires full FEC decoding of the packet. FEC processing delays can represent a significant part of the HARQ round trip time (HARQ RTT) at high data rates, and this in turn can compromise deployments with centralized FEC decoding at the baseband unit (Figure 4-32). Channel decoding of large packets can be very time consuming, and meeting the HARQ RTT requirements may be challenging especially in centralized deployments where part of the delay budget is consumed by the transport network.

In these conditions it would be desirable to decouple HARQ retransmissions from FEC decoding, and to trigger retransmissions without having to perform full FEC decoding of the packets. Current SoTA techniques provide methods to predict the block error rate (BLER) from the frequency profile of the signal to noise and interference ratio (SINR), as in Link to System (L2S) techniques [ORG10]. However, this quantity cannot provide any clue of whether a given packet is in error or not, and more research is required to fulfil this objective.




mmMAGIC Public 72

Figure 4-32 Decoupling of retransmissions from FEC decoding for the proposed early triggering

of MAC-level retransmissions in centralized deploym ents

Early triggering of retransmissions would require additional processing located as close to the access points as possible (white boxes in Figure 4-32). Detection of packet errors would rely on soft outputs available at the receiver after detection and equalization, prior to performing full FEC decoding of the packets. This would enable reduced and flexible HARQ round trip times, which can be of great interest even if the overall delay would remain unchanged because of the unavoidable FEC decoding. Moreover, the size of the transmission buffer (containing packets pending confirmation) could be reduced in correspondence with the shorter HARQ RTT.

Given the statistical nature of packet error detection, it will be essential for the system to provide a measure of the reliability of packet error decisions. No parity bits can be checked for the presence of errors, hence missed detection and false alarms events will appear to a greater or lesser extent depending on the channel conditions. For this reason, the system may disregard packet error decisions characterized by very low reliability values, letting the higher layers decide on which type of action to perform in this case.

4.6.3 Dynamic resource sharing for directional beam forming using Listen-Before-Talk

When employing multi-operator massive MIMO to ensure 50+ Mbps everywhere, one possible way to coordinate the coexistence is to use Listen-Before-Talk (LBT). LBT is the most flexible tool to support horizontal sharing for the following reasons: a) distributed structure without needing information exchanges between different networks or nodes; b) it may realize the coexistence support with different operators or systems simultaneously.

The key idea of LBT is that the source node (SN) listens to check the channel status before it actually transmits to the destination node (DN). In other words, the default mode of LBT for SN is ‘not to send’ and data is sent only when it is confirmed that the channel is available by listening.




mmMAGIC Public 73

Here ‘available’ means that the planned transmission will neither interfere nor be interfered by current ongoing transmissions. The assumption behind this is that the sensed power at the SN side represents the interference power at the DN side. However, when the sensed power at SN side is much smaller than interference power at DN side, the hidden node problem may occur, i.e., the channel is considered available but is actually occupied. In contrast, the exposed node problem may occur when sensed power is much larger than interference power, i.e., channel is detected busy but is actually not occupied. In current Wi-Fi or LAA systems for LTE, these problems already exist but they are not so severe and can be tuned by setting a feasible detection threshold. The probability of such problems occurring when using LBT is acceptable according to evaluations and practical applications in current Wi-Fi or LAA systems for LTE. For LBT, we should also consider for how long a time it is necessary to sense before each transmission. For this purpose, a back-off counter is introduced for LBT. The counter is generated randomly when the SN wants to transmit data and decreases if the channel is sensed idle. When it expires, the SN regards the channel as idle and could start to transmit data in the channel.

For mm-wave systems with large antenna arrays, high gain beamforming is available for data transmission. This will exacerbate the hidden and exposed node problems. Due to high gain beamforming, the sensing phase will be done with a directional beamforming pointing towards the direction the node wants to transmit. In this case, different oriented directions may result in different receiving powers.

A simple example is illustrated in Figure 4-33a. In left side, AP1 is transmitting data to UE1 and AP2 is listening. Since it is not in Tx coverage of AP1, AP2 considers the channel is available and thus starts to transmit data to UE2. But actually UE1 is interfered by AP2’s transmission due to it is in AP2’s Tx coverage. The key reason behind this is that sensed power at AP2 is much smaller than the interference power at UE1 side due to direction difference. By contrary, exposed node problem is illustrated in Figure 4-33b.

Figure 4-33 Problem illustration of directional Lis ten-Before-Talk: a) Hidden node problem, b)

Exposed node problem

Listen after talk (LAT) mechanism is introduced to solve the abovementioned hidden- and exposed- node problem in massive antennas case. The key reason to have such severe problems for LBT is the large difference between sensed power at the SN side (e.g. AP2 in Figure 4-33) and interference power at the DN side (e.g. UE1 in Figure 4-33) in the high gain beamforming case. Thus LAT considers involving the receiver to sense the channel directly. Another motivation for LAT is low interference situation, i.e. less collision for naive direct transmission. For this reason, LAT adopts opposite logic compared to LBT as follows: the default mode for transmitter is ‘to send’ and data is not sent only when it is confirmed that channel is occupied by interfering transmissions. The key idea is that the SN transmits anyway when data packets arrive and then solve collision detected by DN according to coordination signalling.




mmMAGIC Public 74

Simple evaluations are planned to validate the above analysis and concept. To better understand coexistence performance, both static evaluation and dynamic evaluation are considered in this section. Static evaluation is mainly to identify how severe the hidden node and exposed node problem are when massive MIMO is applied to listen before talk scheme in different settings. Furthermore, dynamic evaluation is established to compare system-level performance for different coexistence mechanisms discussed above. A modified Manhattan grid scenario is used as evaluation environment as shown in Figure 4-34. This is inspired by the fact that shared spectrum is usually complementary to licensed operation in high capacity demand case, e.g. crowded shopping centre. Two networks will be deployed in this area with 4ANs each. APs will be mounted in the wall and UEs are distributed randomly in the outdoor streets. One deployment example is given in right side of Figure 4-34, i.e. blue and red networks. In the evaluations, the AP antenna is assumed to be a rectangular array with M x N dual-polarized elements, where M is the number of columns and N is the number of rows. A 5x20 antenna array corresponds to a physical size of 7 cm x 24 cm with the used element spacing (0.7λ and 0.6 λ in the horizontal and vertical dimensions, respectively). In addition, it is assumed that the UE has isotropic antennas with -8 dBi antenna gain. UE-specific beamforming is simulated in the evaluation. A grid-of-beams (GoB) beam-forming concept has been assumed. It is assumed that a single layer is transmitted/received per UE and polarization. Only single-user MIMO is considered. The beam grid is created by applying DFT vectors over the antenna elements. The beam-forming is separable in azimuth and elevation so that separate DFT vectors are applied over the antenna array columns and rows. In each antenna dimension (horizontal and vertical) the DFT is oversampled by a factor two, i.e., there are twice as many beams as antenna elements in each dimension. For a 5x20 array, this amounts to 400 beams in the grid. To simplify the evaluation, mobility is not supported since it has not large impact on the coexistence performance. FTP traffic is modelled with Poisson arrival for each UE in system-level dynamic evaluations.

Figure 4-34 Deployment scenario for modified Manhat tan grid scenario

4.6.4 Multi-antenna techniques to support media-on- demand use cases

As the mm-wave RAT operates at a higher frequency compared to legacy RATs, the propagation losses will be increased. However, the reduced area per antenna element allows for an increased number of antenna elements on the same area enabling increased antenna gain through beam forming. Additionally, this will also allow for enhanced multi-user MIMO, or spatial multiplexing capabilities. The MU-MIMO principle is illustrated in Figure 4-35. Thanks to the spatial separation, enabled by the narrow beams (indicated in grey), a base station can schedule multiple users at the same time and frequency resource. The cost for this is a shared base station power, and intra-cell interference between multiplexed users.

Beamforming and MU-MIMO as such are not new concepts. The extent to which they are used, e.g. in terms of number of antennas forming the beams and the number of multiplexed users,

-200 -100 0 100

-250

-200

-150

-100

-50

0

50

100

150




mmMAGIC Public 75

will however reach new levels for 5G. For 5G around 256 antennas are often discussed, which is significantly more than for current systems.

The performance of the massive MIMO will be evaluated in the context of supporting media-on-demand services. Such services, like Netflix, are already very popular using fixed access, and are of interest to offer also to mobile and/or fixed-wireless users.

While these services are not very demanding in terms of data rates, around 10-20 Mbps per stream, the continuity of the streams results in very high traffic demands per user, and hence also very high traffic densities. They thus form a relevant test case for capacity enhancing features.

Figure 4-35 Benefits of using MU-MIMO: a base stati on can schedule multiple users at the same

time and frequency resource

4.6.5 Coordinated beam frequency scheduling The major performance limitation factor of mm-wave communications is the increased signal degradation due to the severe, distance-based path-loss phenomenon experienced in these frequencies. To mitigate the performance-related consequences of that unavoidable characteristic, extremely narrow beams need to be formed by a mm-wave AP, with the aim of expanding the achievable coverage range. Nonetheless, in this case, a trade-off between applying a narrow (pencil) beam, that results in an increased coverage range, on one hand, and increased training time, in order to establish a connection with a terminal (via a narrow beam), on the other hand, exists. Such a trade-off has to be efficiently dealt with, since 5G devices are envisioned to have extreme requirements, with respect to latency as well as to spectral efficiency, as compared to today’s systems. Hence, with the aim of effectively utilizing the available resources, multiple users should be simultaneously served.

One way to accomplish that is by means of coordination, considering the existence of multiple, clustered mm-wave APs. More specifically, under such a system setup, efficient multi-user rate scheduling methods need to be designed. Depending on the problem formulation, as well as on the number of system variables that are taken into consideration, it is possible that the designed scheme is overly complex, leading towards an excessive multi-AP coordination overhead. Hence, in an attempt to obtain a low-cost and low-complexity solution, we first choose to design a scheduling scheme by focusing on a single mm-wave cell in a standalone mode. We then generalize the proposed design by investigating the performance of a multi-cell system where the coordination is assisted by a low frequency macro-cell. In what follows, we start with a description of the setup of each mm-wave AP.

Multi-user scheduling in the existence of a single AP (standalone mode) We assume that a mm-wave AP is equipped with �B analog beamformers covering non-overlapping sectors of the cell (for example 3 beamformers, each covering a 120 degree region). Each beamformer can generate �P narrow beams of different directions, so, in total the AP can




mmMAGIC Public 76

potentially generate � �B beams of different directions, although only �B can be concurrently generated from the AP. Each beam direction can be labelled with an index p, so that each direction is uniquely identified by it. In addition, we assume that each UE reports to the AP the channel state information, together with the standard information about target data rate and scheduling priority factor. Focusing on the channel state information feedback, each UE can be enabled to report to the mm-wave AP a set of M preferred serving beams. For example the �th UE can report the vector !" � ($",, … , $",'(�), the elements of which are ordered according to its preference. For each beam, the �th UE can report the CQI of each sub-band in the system bandwidth, �. �. , +",, � -.",,,, … , .",,,/(�0, 0 ≤ 2 ≤ � − 1; 0 ≤ � ≤ 5 − 1,where 5 refers to the number of sub-bands in the system bandwidth. The reported CQIs from the �th UE can be then expressed in a compact way by the matrix 6" � -+",; … ; +",'(�0 ∈ 8'×/, where each row vector is composed of the sub-band CQIs corresponding to the reported beam index defined in !".

The resource scheduler determines at the MAC layer the resource allocation to each scheduled UE in the current TTI (i.e., resources in the time and frequency domain), and, on top of that, the mm-wave AP needs to appropriately select the transmitted beams for the scheduled UE. As a result, the available radio resources can be described by a three-dimensional resource grid in time, frequency and space (i.e., pencil beams). The beam-frequency rate allocation matrix :" for the �th UE can be expressed as

:" � ; �",, ⋯ �",,/(�⋮ ⋱ ⋮�",'(�, ⋯ �",'(�,/(�? ∈ 8'×/, (1)

where �",,,@ stands for the data rate allocated to the �th UE, when illuminated by the beam indexed with $",, in the � th frequency subband, and each element is bounded by the corresponding CQI. The equality �",,,@ � 0 means that no data for the �th UE is allocated at the associated beam direction and frequency sub-band, for the scheduled TTI, consequently, it is envisioned that :" is a sparse matrix. Given the matrix :", the total rate allocated to each UE can be obtained by the expression that follows:

�" � ∑ ∑ �",,,@/(�@B'(�,B , subject to �" ≤ �T,", (2)

where �C," is the target data rate for the �th UE. In order to ensure that fair resources allocation is carried out, a scheduling priority factor, D", can be associated to each UE. Considering N UEs in the cell, the optimal beam-frequency scheduler can be formulated as a constrained convex optimization problem which does not have a close-form solution (see [HFF+16] for a more detailed formulation). However, an exhaustive search method over the feasible solution space can provide an optimal solution. This turns into an overall complexity in the order of magnitude (! �PB5)F (where G is the number of feasible beam sets).

Since the above mentioned complexity is considerable for real applications, an efficient, reduced complexity, beam-frequency rate allocation procedure has to be designed. The algorithm described below achieves similar performance as the ones achieved by applying the exhaustive resource allocation scheme, by keeping a low complexity. The basic principle of the proposed algorithm is to sequentially find the optimal beam direction belonging to the unscheduled beamformers in order to achieve a maximum scheduling metric. After an optimal beam direction is scheduled, the corresponding analog beamformer is set to be scheduled, and all the reported beam directions thereof are removed from the subsequent beam search space. Such beam search procedure is performed until either the target scheduling metric is achieved or all the beamformers are scheduled.

The proposed, iterative scheduling algorithm can be summarized in the following steps:

• Step 0 (initialization): The beam-frequency scheduler sets all the beamformers to be unscheduled.




mmMAGIC Public 77

• Step 1 (iteration start): For each beam direction, the scheduler determines the rate allocation of each sub-band to a specific UE, with the aim of maximizing the contribution to the target scheduling metric. The outputs of this procedure are: i) the optimal UE-beam-frequency allocation; ii) the resulting rate-beam-frequency allocation; iii) the obtained scheduling metric; and iv) the residual target data rate of each UE.

• Step 2: Based on the outputs of Step 1, the beam direction associated to the maximum scheduling metric is selected and the frequency resources are allocated according to i) the UE-beam-frequency allocation and ii) the rate-beam-frequency allocation.

• Step 3: The beamformer associated to the selected beam direction is set to be the scheduled beamformer. All the reported narrow beams related to it are then removed from the set of unscheduled beam directions, thus, leading to a small search space for the next iteration.

• Step 4: The target scheduling metric is updated accordingly by removing the contribution of the achieved scheduling metric.

• Step 5 (end of iteration – stopping criteria): If the updated target scheduling metric is zero, or, in case that all beamformers have been scheduled, the beam-frequency scheduler halts the iteration process. If this is not the case yet, steps 1-4 are repeated till one of the two stopping criteria are satisfied.

Coordinated multi-cell, multi-user scheduling (non- standalone case) Based on the above described low complexity scheduling algorithm, which is applicable for a single cell system, we can tackle the problem of scheduling/resource allocation for a non-standalone, multi-cell, multi-user system scenario, where a low-frequency base station can efficiently perform the coordination task. The advantage of the proposed system architecture is two-fold:

• coordinated scheduling decisions among the APs will lead to a substantial coverage improvement, especially for cell-edge users;

• scheduling conflicts can be effectively resolved with the aid of the low-frequency base station, so that the harmful interference from a UE co-scheduled by two (or more) APs within the same time interval is avoided.

In what follows, we present two different coordinated scheduling solutions. According to the first one, initially the scheduling algorithm is independently (locally) executed by each of the mm-wave APs and then the macro-cell base station resolves the appearing collisions, thus leading to interference removal. According to the second solution, all needed information inputs are provided by the mm-wave APs to the macro-base station, and then the optimization algorithm is run at the latter, in a centralized manner. In the following, the two solutions: decentralized and centralized are sketched.

Decentralized scheduling decisions with centralized refinement

We assume that a number of neighbouring mm-wave APs are clustered and recognized as a coordinated cluster by the macro-cell base station (see Section 4.4). Each mm-wave AP independently runs the optimization algorithm (described in the previous subsection) and, as a result, defines which UEs it will serve, which beams to use, and the resulting quality of service. At the end of the rate allocation procedure and for each beamformer, each mm-wave AP knows

!∗ � -$�∗… . $IJ∗ 0 (i.e., the preferred beams selected) and for each beam, the connected UEs as well as, for each UE the allocated resource frequency. At this point, each mm-wave AP in the cluster, instead of immediately beginning to serve the UEs, forwards this information to the macro-cell via a separate high capacity/low delay backhaul link. Hence, the macro-cell knows which UEs will be served by which mm-wave AP of the cluster. Since the mm-wave APs take the decision independently, it is possible that the same UE has been scheduled for access by 2 different APs during the searching stage. However, since the macro-cell is aware of this




mmMAGIC Public 78

information, it can decide which of the “conflicting” APs should serve the UE, thus leading to interference avoidance prior to any transmission. The proposed algorithm is basically a hierarchal solution, where, first a distributed scheduling decisions are taken from the APs, and then, at a second stage, the low-frequency macro-cell can serve as a central node in order to resolve the appeared conflicts. The decentralized scheduling algorithm is explained in Figure 4-36.

UE1

UE2AP1 AP2

AP3

UE4

Macro eNB

Sche

du

ling d

ecisio

n

UE3

Figure 4-36 Decentralized scheduling algorithm

Centralized scheduling decisions

We assume that each UE n, instead of reporting to each mm-wave AP the CSI tailored to each beam that can be potentially formed for transmission, reports directly the useful information (i.e.,

a set of M predefined serving beams, !" � -$",, … , $",'(�0 along with the corresponding CQI values) to the macro-call base station. Such reporting can take place by introducing an additional, AP-specific label. For instance, regarding AP α, the reporting vector can be !KL �-$",, … , $",'(�0M. As a consequence, the optimization algorithm for resource allocation can be executed in a centralized manner by the macro-cell base station. Then, having converged to a solution, the macro-cell base station informs the APs belonging to the cluster, in terms of the scheduling policy to be followed. The centralized scheduling algorithm is explained in Figure 4-37.




mmMAGIC Public 79

UE3AP1 AP2

Macro eNB

Sch

ed

. de

cision

(stag

e 2

)UE1

UE2

Figure 4-37 Centralized scheduling algorithm




mmMAGIC Public 80

4.7 Self-backhauling 4.7.1 Introduction Self-backhauling refers to a set of solutions where coverage/capacity extension is applied to a network infrastructure by means of 5G-NBs, which connect to other 5G-NB that have dedicated backhaul link, by utilizing the similar radio access technology as the one used by the UEs to access the network. Basic concept of self-backhauling is shown in Figure 4-38.

Figure 4-38 Concept of self-backhauling Self-backhauling provides cost effective means to combat infrastructure constraints especially in a dense network deployment where access to fibre is limited due to the high density of access points. Self-backhauling can also play a critical role during early 5G deployments by providing means for incremental deployment, where initially the density of 5G-NBs with dedicated backhaul access point is lower but over time, as the traffic needs grow and fixed infrastructure becomes available self-backhauling is gradually replaced. Self-backhauled 5G-NBs are also expected to provide capacity extension to an existing deployment by means of multi-connectivity towards multiple donor cells. Typically, self-backhauling is seen as means for coverage extension since Self-Backhauled (SB-NBs) provide better connectivity to cell-edge users compared to direct link from the donor NB. However, in an interference-limited scenario such as a UDN deployment, Self-Backhauling can also be used for capacity extension by employing multi-connectivity towards more than one access points with dedicated backhaul links. In order to support multi-connectivity for UEs connected to sBH node as well as sBH node themselves, the increasing design complexity of protocol stack and potential gains dictate single-hop deployments only. Therefore, in order to support multi-hop functionality, it is imperative to focus on two discrete sets of solutions – one set optimized for capacity and the second set for extended coverage beyond one hop. Number of hops is an important dimensioning issue and affects many technical aspects of a sBH network. Increasing number of hops on one hand provides greater deployment flexibility, but on the other hand adds to the latency. Therefore, the number of hops presents a trade-off between end-to-end latency and reachability.

4.7.2 Design targets for self-backhauling Although the design targets can be classified into two categories, some common targets can be listed as:

• Both sets of solutions are access radio-interface agnostic • The UE protocol stack should be independent of backhauling solutions • Both solutions can support out-band backhauling and multiple radio interfaces for

backhaul and access links • Mobility support for sBH node and UE connected to it.

5G-NB with dedicated backhaul

Self-Backhauled 5G-NB

Core Network




mmMAGIC Public 81

Design targets for capacity focused solutions It is evident that with each hop, the capacity of the access network drops. However, by using multi-connectivity, the loss in capacity can be compensated at the cost of architectural complexity. Following are the design targets for capacity focused self-backhauling solutions:

• Network deployments restricted to single hop • Support for Multi-Connectivity at both backhaul and access links • Full Layer 3 functionality at sBH node • Full HARQ and scheduling cycle at each hop • sBH node must have full capability of 5G-NB

Design targets for coverage focused solutions Multi-hop deployments can play a significant role in reducing the entry costs during deployments. As cell size decreases in high frequency bands particularly in millimeter wave spectrum, the availability of wired access points is a critical issue that can be addressed by using coverage-focused solutions. One the other hand, a key challenge with multiple hops is that each network hop adds to the latency while reducing the overall capacity. Therefore, in order to design a multi-hop system without comprising the end-to-end latency techniques, such as fast scheduling cycles and rapid rerouting are assumed. Design targets for coverage enhancement deployments can be summarized as follows:

• Network deployments supporting multiple hops • Enabling low latency backhaul communication via fast scheduling • PHY/MAC level functionality at each hop with no independent HARQ cycles at individual

hops • Rapid rerouting to combat radio link blockages • Simplified RAN protocol stack for SB-NBs

4.7.3 Realizing self-backhaul cases One, amongst the diverse requirements of wireless self-backhauled node is to provide dynamic functionality: the ability to automatically attach itself to the surrounding donor access/base stations in a plug-and-play fashion. For this, the first step is to realize different self-backhaul cases, i.e., envision the different backhaul scenarios that can possibility arise as shown in Figure 4-39. Based on this, the following diagrams illustrate the various self-backhaul wireless scenarios that will be investigated in this project.




mmMAGIC Public 82

UE1 UE2

UE3BH1

D1 D2

UE 1 UE 2

D1 D2

UE1 UE2

UE3BH1

UE1 UE2

BH1

D1

L 1 L 2

L 3

UE1 UE2

D1

BH1

L 2

L 1

L 3

L 4

L 5

UE1

BH1

D1

BH1

UE1 UE2AP1

D1 D2

UE3

Figure 4-39 Different cases in self-backhauling

Brief description of each of the cases: Case-1: Backhaul Handover

• This condition illustrates the backhaul handover from one donor access to another or neighbouring access point

• For example: It can be observed in this case, that UE2 is served through the sBH access point BH1 for certain time duration, and then the control shifts or is handed over to the neighbouring access ‘D2’

• In this case, the donor access node remains stationary, but the sBH access point is dynamic

Case-2: Multi-connectivity for sBH • In this case, the sBH point has the ability to connect to various donor access at the

same time

Case-3: Outband backhauling • In this case, the backhaul link and the access links are operating at different frequency

bands

• This condition of backhauling avoids interference or overlap, as the communication links are separated in terms of operating frequency bands

• There can be various link combinations considering different frequency band operations




mmMAGIC Public 83

Table 4-2 Access/backhaul link combinations for out band backhauling Access Link Backhaul Link In/outband

Link 1 Link 3 Outband


Case 4: Flexible multi-backhauling

• In this case, there is flexibility with respect to frequency bands used for access and back links

Table 4-3 Access/backhaul link combinations for fle xible multi-backhauling

Access Link Backhaul Link In/outband

Link 1 Link 4 Inband



Link 2 Link 4 Outbound



Case 5: UE multi-connectivity

• In the previous cases, the sBH nodes had the capacity to connect to multiple users, while in this case the UE has the ability for multi-connectivity in the same frequency bands

Case 6: All-in-one • This is combined scenario of all the previously described cases

• This is integrated case comprising a combination of inband and outband backhauling, with other options of multi-connectivity, both in terms of the sBH access points and from the end user perspective

4.7.4 Dynamic multi-hop self-backhauling Communications in mm-wave bands will bring new challenges along opportunities. The challenges lie in the inherent directionality required in those bands to enable wireless communication as this may lead to outage-prone links and spotty coverage due blockages from street furniture and relative movement w.r.t. surrounding environment. There are two fundamental ways to address these issues:

• From PHY-level perspective, developing advanced channel estimation and beamforming algorithms can enable exploiting non-LoS paths/ sub-paths (of channel) that are reflected from surrounding environment.

• From MAC and Network-level perspective (which is the scope of this section), tighter integration and coordination is possible among adjacent mm-wave APs to form dynamic clusters of beam-cells to circumvent obstacles in line-of-sight paths. This strategy needs to be supported by efficient backhauling solutions between the adjacent nodes (mm-wave APs) per cluster. In many practical cases, due to the prohibitive cost of wired backhauling (e.g. Fibre), wireless multi-hop/ mesh backhauling can be a promising solutions, relying on similar in-band (self-backhauling) or even out-of-band settings.

• The multi-hop (self-) backhauling case can be also an interesting solution for moving hotspots (e.g. cars, buses…) to provide dynamic paths towards the core network via intermediate static mm-wave APs in the vicinity.




mmMAGIC Public 84

Figure 4-40 illustrates a schematic diagram of envisioned multi-hop backhauling scheme.

Figure 4-40 Illustration of envisioned multi-hop se lf-backhauling case As shown, within a cluster (or a target hotspot) a UE can be covered via fast intra-cluster scheduling between neighbouring mm-wave APs where the backhaul data routing towards Point of Presence (PoP) as the gateway towards core network will be via the same mm-wave communication air-interface with possible support from low frequency (LF) bands. Moving hotspots can also be supported similarly as depicted.

Multi-hop backhauling faces several challenges from QoS support, meeting per slice requirements to fault detection and congestion management. On the other hand, practical limitations stemming from mm-wave radio frequency and narrow beam antenna design, in conjunction with future use case requirements call for adaptive link scheduling algorithms across different backhaul links.

These require intelligent radio resource management design incl. dynamic backhaul resource allocation and packet routing to optimize the network resilience, efficiency and power consumption. Several flavours of routing and link scheduling algorithms can be considered. Some rely on distributed network intelligence with implicit / explicit signalling among involved links/nodes whereas others rely on centralised or semi-centralised deployments with unique controlling entities to set the routes or scheduling sets.

In this solution component, we explore different possible options on dynamic routing and link scheduling for (multi-hop) self-backhauling of mm-wave-based Heterogeneous networks. In particular, we consider the impact of several emerging features (e.g. Multi-connectivity) and other RAN design implications on network performance.

Multi-hop routing in mm-wave bands Assuming a mesh topology for mm-wave backhauling as outlined in Figure 4-40, multiple paths are possible to forward the packets between core network and a target serving mm-wave APs per time interval. Ideally path(s) with minimal delay and packet loss ratio (due to congestion or outage) should be selected. This depends on the channel states and queue states from each mm-wave AP (sBH) towards the neighbouring APs as well as the number of hops along the path towards final destination.




mmMAGIC Public 85

The way to address routing problem in different mm-wave APs depends on functional split of radio resource management between different network nodes and across different layers in the protocol stack.

Conventionally, the paths between any pairs of nodes can be pre-computed based on the above latency and packet loss ratio KPIs in a controller per cluster. The controller can be defined as logical functions as part of a node role with direct access to PoP of the cluster. Such nodes can be considered as the coordinator per cluster, harmonizing the RRM incl. routing aspects. Assuming multiple PoPs per cluster (hotspot), this role can be cyclically rotated between the candidate nodes. In case of inter-cluster handover, neighbouring clusters’ controllers need to coordinate the backhaul data re-routing of the packets. This can be facilitated via mm-wave APs that are participant in both clusters or alternatively can be orchestrated via low frequency Macro eNBs, covering the clusters.

In case of congestion or link failure due to outage, a hierarchical chain of events can be triggered, starting from sub-path alteration per node till full path re-computation (in the controller) if the issue lingers.

Alternatively, assuming multi-queue buffering of traffic (based on the destination of each follow or aggregated set of flows per slice), routing and congestion / outage control can be effectively absorbed into link scheduling procedure as will be tailored in next sub-section. In this form of functional split, each mm-wave node will individually decide on which flow (or aggregated flows) to forward packet out of, taking into account link scheduling decision and the buffer state of itself w.r.t. adjacent nodes. Effectively, in this manner, packets are forwarded from nodes with longer queues towards nodes with shorter queues per flow of traffic and routing is split into multiple individual packet forwarding decisions without reliance on a local or central controller.

Link scheduling in mm-wave bands Considering the interference footprint per link between adjacent mm-wave APs (when active), and also mm-wave RF constraints (on the number of simultaneous active beams per mm-wave AP), it may not be feasible (nor optimal) to have certain clusters of links activated together. This calls for link scheduling algorithms to coordinate the active links per transmission time interval.

As outlined earlier, the link scheduling as above is closely coupled with routing algorithm and the corresponding functional split.

Assuming a centralised routing, the link scheduling algorithm can activate the set of links that minimize the end-to-end latency and packet delivery ratio per path (or per set of paths) per transmission interval. This again can be achieved via leveraging the cluster controller entity. On the other hand, to save on complexity and signalling overhead, cyclic patterns of feasible scheduling sets can be defined and run in mm-wave APs, requiring less centralization per cluster.

Assuming individualized packet forwarding, the link scheduling need to activate the set of links with maximal weighted sum-rate per cluster. The weighting factor is in line with the maximal differential queue size of a node w.r.t. neighbouring nodes (as the outcome of packet forwarding decision in previous stage). Again link scheduling need to rely on a cluster controller entity to aggregate all link state / queue state information. Similarly, cyclic link scheduling patterns can be exploited here to save on complexity and resulting overhead.

Individual vs. Cluster-wide / Network-wide procedur es Assuming a cluster-wide routing / scheduling,

• Each backhaul node should exchange the link state and buffer state in regular interval (to be set by the cluster controller) with the cluster controller. The state information will also include the access link state w.r.t. fast intra-cluster scheduling plan.

• In return, the cluster controller will set the link or route schedule per interval.

• Each backhaul node will follow the schedule upon reception.




mmMAGIC Public 86

Assuming individualized packet forwarding,

• Each backhaul node will communicate with adjacent nodes to identify their corresponding queue states per time interval.

• Each backhaul node will locally calculate the differential queue sizes w.r.t. neighbouring nodes and identifies the maximal value per time interval and shares this value along its link state information to the cluster controller.

• In return, the cluster controller will set the link schedule per interval.

• However, each backhaul node individually decides and forwards the packet in the direction of maximal differential queue sizes.

4.7.5 SDN-based self-backhauling In urban environments where small cells are expected to be deployed densely so to enhance capacity, using self-backhauling in mm-wave frequencies can be a challenging task due to the variable backhaul channel conditions (LoS/NLoS) and availability. Therefore, having multiple short-distanced hops that can be adapted based on the channel conditions and the traffic load is essential to meet the tight 5G requirements. However, having multiple hops can increase latency in levels which are prohibited for ultra-low latency services.

To this end, one of the major challenges that need to be addressed is the scheduling of the traffic in backhaul and access links by taking into accounts the backhaul channel conditions and the traffic demand. In this context, approaches based on SDN principles will be investigated in order to efficiently perform scheduling of backhaul and access resources taking into account services with different KPIs.

In a typical SDN-based self-backhauling network, one logical controller is supposed to monitor topology changes, node-to-node radio channel status and all the traffic needs in a real time fashion. Moreover, dynamic decision will be made by the controller in terms of how much radio resource to be allocated for backhaul at each node. The network also enable multi-routes connection, allowing coordination and cooperation to be performed through management provided by the controller in order to achieve network-level optimization.

The architecture of backhaul networking is one potential technical aspects of SDN-based self-backhauling. Backhaul networking for dense deployed small cells could be characterized by the following aspects:

• Should be a ringed-tree topology (Figure 4-41)

• A node has more than one candidate backhaul link

• Backhaul links vary in capacity, latency and cost

• Vertical links would have higher priorities than horizontal links in route selection




mmMAGIC Public 87

Figure 4-41 An example ringed-tree backhaul networking

For both wireless backhauls and fibre backhauls, two types of logical links exist, namely one for mobile data and the other for control signalling (SDN-related). A single controller provides management to a bounded cluster, while interconnections can be expected among controllers to enable the so called boundless coordination (see Figure 4-42). Here, a controller is not necessarily a physical device. It could be just a functional entity in gateways or in certain base stations.

Figure 4-42 Backhaul networking with high-level net work elements




mmMAGIC Public 88

For a tremendously broad working spectrum band that stretches from 1GHz to 100GHz, it seems reasonable that downlink and uplink can be operated at different frequency bands for self-backhauling purpose, which envisions FDD mode as a potential candidate. For an objective spectrum, it could be working on either one of the following modes (see Figure 4-43), depending on the high-level spectrum usage policy and the actual configuration.

• Legacy paradigm: some spectrums only support this paradigm for simplicity

• Backhaul-only paradigm: suitable for point-to-point fashion with multiple sub-channels

• Hybrid paradigm: semi-static or improvised backhaul sub-channels coexist with DL/UL channels

Figure 4-43 FDD operation mode of self-backhauling

4.7.6 Resource allocation for backhaul and access l inks that involves spatial multiplexing

In the context of radio resource management, multiplexing of time and frequency resources between backhaul and access links attracts the most attraction, where the two links are operating on the same frequency band in a dynamic TDD system. In this kind of scenario, one relevant issue is figuring out an efficient resource allocation mechanisms to split radio resources between backhaul and access links, making sure that there are enough backhaul capacities for all traffic from access links in order to maximize the resource utilization of the network. The other relevant issue is as both backhaul and access links operate on the same spectrum, then one of the fundamental challenges to be resolved is the optimum distribution of non-conflicting resources between the two links. In addition to the time resource management between backhaul and access links under in-band relaying in a dynamic TDD system, multiplexing of spatial resources that exploits directional transmission with extensive beamforming has been envisioned to be a promising candidate to overcome the unfavourable path loss in high frequency bands. Therefore, we consider spatial multiplexing as additional key enabler to further improve the system performance. To this end, the performance of serial TDMA/FDMA can be further improved by incorporating the space dimension where more than one flow can be scheduled at the same time (see: Figure 4-44). This means that there will be more time resource allocated to each flow, and consequently the throughput of each flow increases.




mmMAGIC Public 89

Figure 4-44 Heterogeneous cellular networks exploit s spatial multiplexing

Spatial multiplexing brings salient network capacity gain when it comes to radio resource management. Here, by fully exploiting spectral reuse in scheduling scheme, more time resource can be allocated to the data flows, which enormously enhance the network capacity. An example of exploiting spatial capacity is concurrent transmission by allowing nodes to transmit concurrently in communication links without causing harmful interference. In such spatial time-division multiple-access (STDMA) system, a time slot can be allocated to multiple communication links to improve the spatial reuse, thus significantly increase the system throughput.

4.7.7 Resource allocation for access and self-backh aul in dynamic half-duplex TDD system

Multiplexing of time and frequency resources between backhaul and access links in common frequency band in a dynamic TDD system is discussed in this section. Since both backhaul and access links operate on the same spectrum; one of the fundamental challenges to resolve is the optimum distribution of non-conflicting resources between the two links (Figure 4-45)

Figure 4-45 Resource allocation in frequency and ti me between self-backhaul and access part

Capacity centered single hop solutions For single hop solutions, TTI level multiplexing between backhaul and access link has been assumed for PHY/MAC control plane. SB-NB can take two roles: it is seen as a UE from donor NB perspective and as a NB from UE’s perspective. In UE mode, SB-NB shares control and data plane with other UEs directly connected to donor NB. The data plane can be scheduled independently for both backhaul and access links as long as half-duplex constraint is maintained and scheduling collisions are avoided. When SB-NB acts as a UE towards the donor cell, it is




mmMAGIC Public 90

only able to receive and transmit control information from the donor in a given TTI, while unable to deliver or receive any control information from its own UEs. Similarly when it acts as an AP towards its own UE, it is not able to send or receive any control data from the donor AP. It is important to introduce control signalling that informs the UEs connected to the SB-NB about the periodic disruptions in the control part compared to the UEs that are directly connected to a normal NB. This pattern is assumed to be fixed over a long time scale and can be changed via RRC level control signalling. The pattern can be signalled to the UE or SB-NB upon cell selection, reselection or handover as shown in Figure 4-46 below.

Figure 4-46 Resource allocation for self- backhaul and access links in single-hop dynamic TDD systems

In order to allow maximum scheduling flexibility at the data plane, modulo based control channel multiplexing brings about additional challenges especially in a dynamic TDD system. For example, for SB-NB to act as an independent AP with its own scheduler, it requires advanced knowledge of scheduling decisions at backhaul link in order to schedule its own UEs without conflicts in time and frequency domain or direction (UL or DL). Secondly, the pattern also limits the scheduling possibilities due to reduced control channel allocation.

Coverage centred multi hop solutions An access point with integrated backhaul will be a small box which is easy to install on lamp posts, walls or small masts with its main cost deriving from RF components. The overall radio access of backhaul for multi-hop access points is designed with high capacity and mesh like terminations to multiple nodes in mind. Some of the key deployment challenges include working around obstacles and utilizing beam steering to maximize link gain while keep interference to a minimum. For access links it is envisioned to provide street level coverage in pedestrian zones. The capacity requirements demand high peak and edge user data rates. Multi-hop deployments incorporate single TTI signalling approach such that each TTI can be allocated to uplink, downlink or backhaul. The multi-hop connection between many self-BHs require fast scheduling and resource allocation between access and self-BH nodes. The solutions should reduce overall E2E latency over multiple hops.

4.7.8 Dynamic Interleaving codes for self-backhauli ng and RRM Frequency and time resource allocation is a key element in self-backhauling and advanced OFDM processing [Hoy11]. We propose an interleaving based method to allocate resource (typically, resource blocks in OFDM slots. This method named Dynamic Interleaving coding defines time variant interleaving patterns to distribute in the time and frequency domains sub-carriers and OFDM slots in successive OFDM symbols [SUM11]. Interleaving processing with a control of interleaving patterns and associated interleaving spreading values allows a diversity maximization during OFDM transmissions seeking resource allocation in time and frequency domains. The diversity may be optimized to limit multi-user interference Interleaving may improve transmission and limit interference in defining a scalable size of RB allocated to each user conditioned by interleaving patterns. It will improve resource allocation and limit multi-user interference in RB allocation.

TTI: n: n+k TTI: n+k+1:(n+k+1)+m Donor 5G

NB SB-NB

DL UL

Control

channels UL or DL data channels

Control

channels UL or DL data channels UE

TTI: n: n+k TTI: n+k+1:(n+k+1)+m SB-NB

DL UL DL or UL DL or UL




mmMAGIC Public 91

We also envision time-variant resource mapping in OFDM symbols, using a dynamic interleaving process, as a virtual multi-band processing which make increases the spectrum efficiency of the system without additional RF channels. Propagation channel diversity introduced by dynamic interleaving process is assimilated to a multi-band process. An illustration of the concept is done in Figure 4-47 where dynamic sub-carrier interleaving is described by 2 different interleaving patterns L0(k) and L1(k). Interleaved sub-carriers are then distributed in Nsc,0 RBs with a size NSDC,0 allowing an interleaving spreading maximization for the interleaving pattern L0(k).

We propose to optimize and extend the method exposed in [SUM11] to air interfaces studied in WP3 and advanced 5G self-backhauling mechanisms.

Figure 4-47 Dynamic Interleaving code processing fo r self-backhauling processing and virtual multi-band process




mmMAGIC Public 93

5 Summary and highlights This deliverable has presented the recent findings on the architecture and integration work done in mmMAGIC. The concepts, developed here are twofold: intended to provide 5G system that employs mm-waves operating at 6–100 GHz frequency range, and secondly related to how to integrate it with the rest of 5G ecosystem mainly focusing on LTE-A and 5G systems operating below 6 GHz. Some key aspects of this report are highlighted below, presented in the order of its occurrence in their respective sections.

Use cases, deployments and scenarios We have analysed the use cases, deployments, and requirements in order to design the functional blocks, architectural elements and enablers to meet the technical requirements, and fulfil the KPIs of the use cases. We considered the architectural impacts of deployment in different use cases within the diverse test scenarios.

We identified principles for the architecture design oriented on tight integration of multi-RAT 5G ecosystem. The principles are as follows: design to support both standalone and non-standalone mm-wave system deployments; support network slicing; distinction between synchronous and asynchronous functions; device capabilities signalled from the CN;; efficient design of control signalling to support system access and mobility.

We have provided our preliminary considerations on protocol stack design indicating directions for potential modifications/extensions. Further logical architectures were presented – baseline based on SAE and followed by distributed and centralized variants, which are supporting network virtualization (CN and/or RAN in the cloud).

The main part of this report deals with initial concepts for architecture and integration, comprising eight family of technical solutions—forming a building block for the integrated architecture. These solutions are summarised in the subsequent paragraphs.

Integration for 5G networks The integration of mm-wave system with the rest of 5G ecosystem was analysed. We indicated that the main scope of our architectural work lies in the RAN part of the network. However, we also explored the division between RAN and CN parts of the network. We assumed that the split between the core network and the RAN would be similar to that of current LTE. Nonetheless, in further work, we will be investigating possibilities of delegating some CN responsibilities to the RAN part e.g. related to mobility.

We discussed the multi-RAT integration between LTE and UTRAN, implemented via inter-RAT hard handovers, but found the technique not sufficient to the integration between the evolution of LTE-A and mm-wave 5G RAT since it has several drawbacks. It is the motivation of this project to study new means for inter-RAT integration for 5G systems. The major drawback of inter-RAT hard handovers is rather the long delay and service interruption, for instance during varying channel conditions. The hard handover delay depends on various parameters, for instance: cell search and synchronization time, alongside the extensive RRC signalling required. The evolution of Dual Connectivity available for LTE-A might be used for integration of LTE with other RATs.

We inferred that tight multi-RAT integration on lowest possible level e.g. in MAC or PDCP layers was a reasonable way to implement in practice the architecture development from LTE-A to 5G networks.

Similar to NGMN, we identified three main areas, which need focus to fulfil 5G network requirements, like:




mmMAGIC Public 94

(1) Providing network capabilities for new services (2) Managing complex ecosystem of different radio technologies in UDN deployments incl.

backhaul provision (3) Keeping the flexibility and adaptively for any emerging services in the future.

In this deliverable, the above areas for development were identified with preliminary architecture solutions proposed for integration. In addition, we discussed providing network capabilities for new services by multiple solutions like multi-connectivity, various techniques from RRM domain, control signalling, connectivity optimization etc.

We approached managing complex ecosystem of different radio technologies in UDN deployments including backhaul provision via solutions for self-backhauling, RRM, Multi-RAT Multi-layer management; mm-wave cell clustering and management, resource sharing; fast handover/scheduling and coordinated beam-frequency scheduling.

Finally yet importantly, since the practical implementation of all use cases cannot be predicted, it was essential to keep the flexibility and configurability for any emerging services in the future by formulating integration related expectations towards network slicing, and proposed general model for multi-RAT multi-layer management.

The evolution of architecture from LTE-A to 5G requires solutions, which must address challenges in all the three aforementioned directions. The solutions include architectural designs enabling tight integration of multiple RATs.

Solutions (technology components) Network Slicing Even though Network Slicing is the concept mostly related to core network, we included preliminary considerations on Network Slicing impact on RAN design and defined some requirements. RAN should be:

1) ready to support different optimizations of the resource utilization based on slice information (see 2) ).

2) able to differentiate traffic between different slices providing slice-ID. (In RAN, it needs to ensure that the traffic in one slice does not degrade the performance of other slices)

3) designed to support efficient management of different slices and enable efficient introduction of new slices or add services to the existing slices, while maintaining the performance of the incumbent services

4) support incremental improvements of the common infrastructure

Review and redesign of the protocol stack We also discussed the protocol stack assumptions for the mm-wave integrated system. While reviewing the LTE-A RRC states, we conjectured that it is very likely for 5G mm-wave system to have traffic pattern with infrequent small bursts. In order to reduce cost (in terms of control signalling) of transitions between RRC_IDLE and RRC_CONNECTED, the novel RRC_CONNECTED_INACTIVE state is proposed as the primary sleep state.

Multi-connectivity and multi-RAT We also reviewed different types of multi-connectivity supporting both intra-frequency and inter-frequency solutions. More focus was put towards studying Dual Connectivity, as it is defined in LTE Rel-12 and its extension (enhanced dual connectivity, eDC) for 5G. The eDC for 5G is a




mmMAGIC Public 95

generalization of LTE-A DC to support the data split and duplication to more than two sites and the potential diversity for RRC signalling. In addition, the data split and duplication switching of UP and/or CP was also proposed as a candidate solution.

For the user plane multi connectivity options, we considered two Dual Connectivity arrangements - 1a and 3c. We analysed the potential split of service flows for these two cases and indicated their possible combinations for usage in 5G networks. For the control plane, we proposed to study single RRC signalling as well as extensions in form of RRC diversity and master/secondary RRC approaches.

We studied support of mm-wave by low band system and in this segment we identified signalling that goes over mm-wave system (both for initial access and data transmission) and low band system.

In metro-like deployment, where the low band coverage areas can be served by multiple mm-wave base stations that provide a “overlapping coverage, the role of low frequency band is to make the operation of multi-BS coverage easier and more reliable. It is characterized by the functionalities: support the setup of mm-wave BS cluster based on UE information, assistance of mobility handling and mobility detection, support of handover to other mm-wave BS to provide seamless fall-back to low band transmission if mm-wave link fails.

In this document, the single/multi-connectivity optimization schemes for standalone and non-standalone RAN were investigated, and two schemes of Single-Link Optimization and Multi-Link Optimization were proposed. The first approach can be used both for single and multi-connectivity mode. It can be predicted that the benefit of this approach will be significantly noticeable in multi-connectivity mode as the number of links are optimized. The latter optimization is aimed at improving the reliability of connection in multi-connectivity mode. Hence, less retransmissions occur.

We proposed an analysed the algorithms for the energy efficiency maximization based on the concept of switching off the desired antenna elements to increase the energy efficiency without giving up the network performance.

For the multi-layer multi-RAT management, we proposed generic model, which is an extension of the I-MAC concept, and considers several layers for link adaptation metric integration. So three-layer architecture was proposed for the integration of metrics in multi-RAT architecture depending upon the technologies involved in multi-RAT scenarios.

In order to increase network energy efficiency, we proposed multi-RAT link adaptation based on Power Efficiency and multi-RAT Energy Efficiency processing as an alternative to spectrum efficiency link adaptation processing developed for 3GPP and Wi-Fi.

mm-wave access point clustering For 5G mm-wave systems, the beam-based antenna patterns will result in dynamic variations in coverage, signal quality and channel quality as minor UE moves, and corresponding change in the rotation will change the directionality of the beams. At the same time, signal blockage from obstacles can greatly reduce the beam coverage. This leads to frequent handovers between different beams in order to provide sufficient and adequate coverage and connectivity. One option to resolve this is to use access point clusters within which the mobility of the UE is transparent to the CN. Thus, within the cluster, the handover of the UE between different nodes or beams can be performed without any CN signaling. We proposed several solutions depending on quality of available backhaul and type of deployment, which can be single or multi-RAT. We have presented solutions for mobility within and between mm-wave cell clusters. To cover all relevant aspects of the mm-wave cells clustering, we presented initial solutions for managing the cell clusters.




mmMAGIC Public 96

Initial access, mobility management and handovers When thinking of mm-wave systems it is natural to ask the question if low frequency RATs can cooperate with mm-wave and improve effectiveness of control procedures. In that context low-frequency-assisted initial access was studied in terms of Downlink timing/frequency synchronization, System information acquisition, Uplink timing synchronization and beam training.

We proposed energy efficient initial access exploiting the fact, that in a densely deployed scenario, the coverage area of multiple APs may overlap and may have similar or identical system information. In the proposed scheme, the system information should be primarily transmitted as dedicated signals only to the targeted UEs in the proper directions.

We provided considerations on fast handover/scheduling in standalone mm-wave RAN. In that, part we discussed selected functions of the local (mobility) controller, which should adjust the frequency, and detail of control information to the mobility type. Additionally, the cluster controller must decide on the benefits of switching a UE to a different access point.

We studied fast handover/scheduling between technologies and proposed two solutions. First, based on UE downloading LTE-A coverage maps that will be deployed whilst making a decision whether to handover to LTE-A; and second, the consequences of dramatic data rate fluctuations while handing over between mm-wave and LTE-A system. To achieve that, the local and/or central entities that take the handover decision should provide cross-layer information to the application layer on the expected future throughput variations.

We have presented initial concept related to active mode mobility where AP selects a set of relevant ‘Mobility Beams’ on which it transmits a ‘Mobility Reference Signal’ (MRS), which it then instructs the UE to measure on and report to the network.

In the proposed solution of mobility on demand, the mobility of high-speed users will be handled in a manner similar to LTE— by the MME entity located in the core network. For nomadic users or static devices, mobility can be enabled only when needed (e.g., when the user changes location).

MAC and RRM While MAC and radio resource management (RRM) are key components of the RAT, we discuss this aspect and draw the following conclusions.

The coordination mechanisms to minimize inter-cell interferences in the presence of beamforming are necessary. A convenient tool to support a broad range of inter-node coordination strategies can be a “beam labelling” technique. All transmitted beams can be conveniently labelled in the form of a beam indicator, which could be signalled to the users by means of a “Beam Indicator Channel”:

The main principle of early triggering of MAC-level retransmissions in fully or partially centralized deployments is to decouple HARQ retransmissions from FEC decoding, and to trigger retransmissions without having to perform full FEC decoding of the packets.

Dynamic resource sharing for massive MIMO is also important and the approach Listen-Before-Talk (LBT) can be applied. The key idea of LBT is that the source node listens to check the channel status before it actually transmits to the destination node. For mm-wave systems with large antenna arrays, high gain beamforming is available for data transmission. This will exacerbate the hidden and exposed node problems. Due to high gain beamforming, the sensing phase will be done with a directional beamforming pointing towards the direction the node wants to transmit. In this case, different oriented directions may result in different receiving powers. We must consider the time duration it must last to sense before the next transmission. For this purpose, a back-off counter is introduced for LBT




mmMAGIC Public 97

We have proposed scheduling solution that is jointly looking into beam and frequency scheduling dimensions in order to coordinate the network nodes. The studies were performed in two directions of centralized and not centralized decisions.

Self-backhauling This deliverable also shows that self-backhauling is an important topic for discussion. We conclude our analysis by the following statements.

While defining design targets for self-backhauling solutions we distinguish coverage-oriented and capacity-oriented self-backhauling solutions. However, the subset of those targets is common for both cases. These common targets are: both sets of solutions are access radio-interface agnostic, the UE protocol stack should be independent of backhauling solutions, both solutions can support out-band backhauling and multiple radio interfaces for backhaul and access links, mobility support for sBH node and UE connected to it. In addition, we identified six different cases specifically useful for self-backhaul investigations e.g. backhaul handover, UE multi-connectivity, sBH multi-connectivity etc.

In the presented considerations on dynamic multi-hop self-backhauling, both for Multi-hop routing and link scheduling, we are assumed a mesh topology for mm-wave backhauling, with the path selection and link scheduling tightly related to one another. In the proposed solution multiple paths were possible to forward the packets between core network and the target serving mm-wave APs per time interval. Ideally, path(s) with minimal delay and packet loss ratio (due to congestion or outage) should be selected. The way to address routing problem in different mm-wave APs depends on functional split of radio resource management between different network nodes and across different layers in the protocol stack. In case of congestion or link failure due to outage, a hierarchical chain of events can be triggered, starting from sub-path alteration per node till full path re-computation (in the controller) if the issue lingers.

While studying self-backhauling solutions, we looked also into a typical SDN-based self-backhauling network, where one logical controller is supposed to monitor topology changes, node-to-node radio channel status and all the traffic needs in a real time fashion. Moreover, dynamic decision will be made by the controller in terms of how much radio resource to be allocated for backhaul at each node. Backhaul networking for dense deployed small cells could be characterized by the following aspects: as a ringed-tree topology; a node has more than one candidate backhaul link; backhaul links vary in capacity, latency and cost; vertical links would have higher priorities than horizontal links in route selection.

Investigation of resource allocation for access and self-backhaul in dynamic half-duplex TDD system was performed in two directions: for capacity and coverage extension. The capacity centred solutions are single-hop since each additional hop is reducing capacity of e2e path. Multi-hop deployments (extending coverage) incorporate single TTI signalling approach such that each TTI can be allocated to uplink, downlink or backhaul.

Multi-hop deployments incorporate single TTI signalling approach such that each TTI can be allocated to uplink, downlink or backhaul. The multi-hop connection between many self-BHs requires fast scheduling and resource allocation between access and self-BH nodes.

As a part of resource management studies for self-backhauling, we propose an interleaving based method to allocate resource (typically, resource blocks in OFDM slots. This method named Dynamic Interleaving coding defines time variant interleaving patterns to distribute in the time and frequency domains sub-carriers and OFDM slots in successive OFDM symbols

All the aforementioned concepts are intended to provide 5G system architecture and to integrate it with current wireless systems to meet future user demands.




mmMAGIC Public 98

6 References

[3GPP R4-092042] 3GPP R4-092042 “Simulation assumptions and parameters for FDD HeNB RF requirements”, 8 May 2009

[3GPP TR 22.891] 3GPP TR 22.891 Technical Specification Group Radio Access Network, “Study on New Services and Markets Technology Enablers”, 3rd Generation Partnership Project, Tech. Rep. TR 22.891, 2015

[3GPP TR 23.799] 3GPP TR 23.799 Technical Specification Group Radio Access Network, “Study on New Services and Markets Technology Enablers”, 3rd Generation Partnership Project, Tech. Rep. TR 23.799, 2015

[3GPP TR 25.814] 3GPP TR 25.814 Technical Specification Group Radio Access Network, “Physical layer aspects for evolved universal terrestrial radio access (UTRA),” 3rd Generation Partnership Project, Tech. Rep. TR 25.814, 2006

[3GPP TR 36.842] 3GPP TR 36.842 Study on Small Cell Enhancements for E-UTRA and E-UTRAN – Higher layer aspects, 2014

[3GPP TR 36.931] 3GPP TR 36.931 version 9.0.0 Release 9, “LTE Evolved Universal Terrestrial Radio Access (E-UTRA) Radio Frequency (RF) Requirements for LTE Pico Node B,” 2011

[3GPP TS 23.401] 3GPP TS 23.401General Packet Radio Service (GPRS) enhancements for Evolved Universal Terrestrial Radio Access Network (E-UTRAN) access (Release 8), 2007

[3GPP TS 36.300] 3GPP TS 36.300 V13.2.0 E-UTRA, E-UTRAN, Overall Description; Stage 2, 2015

[4GA14] 4G Americas’, “Recommendations on 5G Requirements and Solutions”, 2014 (available online: http://www.4gamericas.org/files/2714/1471/2645/4G_Americas_Recommendations_on_5G_Requirements_and_Solutions_10_14_2014-FINALx.pdf)

[AGC10] I.F. Akzildiz, D.M. Gutierrez-Estevez, E. Chavarria Reyes, “The evolution to 4G cellular systems: LTE-Advanced”, Physical Communication 3 (2010) 217-244

[ARI09] C. A. Ariyaratne, “Link Adaptation Improvements for Long Term Evolution (LTE)”, Master thesis of Blekinge Institute of Technology, 2009

[BFB+10] J.J. Boutros, A. G. I Fabregas, E. Biglieri and G. Zemor, “Low-Density Parity-Check Codes for Nonergodic Block-Fading Channels”, IEEE IEEE Transactions on Information Theory, vol. 56, no. 9, September 2010

[BSF+13] S. Berger, M. Soszka, A. Fehske, P. Zanier, I. Viering, and G. Fettweis, “Joint Throughput and Coverage Optimization Under Sparse System Knowledge in LTE-A Networks,” in IEEE International Conference on ICT Convergence (ICTC), 2013

[BWR14] K. Bakowski, K. Wesolowski, M. Rodziewicz, “Simulation Tools for the Evaluation of Radio Interface Technologies for IMT-Advanced and Beyond,” 2014 (available online: https://www.metis2020.com/wp-content/uploads/publications/CRC_Press_2014_Bakowski_etal_Simulat




mmMAGIC Public 99

ion_Tools_for_the_Evaluation_of_Radio_Interface_Technologies_for-IMT-A_and_Beyond.pdf)

[E14] Ericsson, “The Real-Time Cloud White Paper,” February 2014 (available online http://www.ericsson.com/res/docs/whitepapers/wp-sdn-and-cloud.pdf)

[E15] Ericsson, “5G Systems White Paper,” January 2015 (available online http://www.ericsson.com/res/docs/whitepapers/what-is-a-5g-system.pdf)

[EUCNC15] M. Nekovee, P. von Wrycza, M. Fresia, M. Peter, J. Gora, J. Luo, M. Hunukumbure,“Millimetre-Wave Based Mobile Radio Access Network for Fifth Generation Integrated Communications (mmMAGIC)”, EUCNC 2015 :

[HFF+16] M. Honglei, M. Faerber, M. Fresia, V. Frascolla, “Joint Beam-Frequency Multiuser Scheduling for Millimeter-wave Downlink Multiplexing”, Vehicular on technology Conference, May 2016, (accepted)

[HLA+14] N. ul Hassan, M. Lentmaier, I. Adriyanova, G.P. Fettweis, “Improving Code Diversity on Block-Fading Channels by Spatial Coupling”, 2014 IEEE International Symposium on Information Theory (ISIT)

[Hoy11] C. Hoymann, ‘LTE-Advanced:Self-backhauling for cost reduction’, 2011, http://www.3g4g.co.uk/LteA/LteA_Pres_0811_Ericsson

[IEEEad12] IEEE 802.11 WG, “IEEE 802.11ad, Amendment 3: Enhancements for Very High Throughput in the 60 GHz Band,” Dec. 2012.

[ITUR Rec] ITU-R Rec. V.431-7, “Nomenclature of the Frequency and Wavelength Bands Used in Telecommunications,” 2000

[KBN12] R. Kraemer, M. Brzozowski, S.Nowak, “Reliable Architecture for Heterogeneous home networks: the OMEGA I-MAC Approach”, Elec. Energ. Vol. 25, No 1, April 2012

[KSF15] H. Klessig, M. Soszka and G. Fettweis, „Multi-Cell Flow-Level Performance of Traffic-Adaptive Beamforming under Realistic Spatial Traffic Conditions” in Proceedings of the Twelfth International Symposium on Wireless Communication Systems (ISWCS'15), Brussels, Belgium, 25.8. - 28.8.2015

[KW13] A. Kangas, T. Wigren, “Angle of Arrival Localization in LTE Using MIMO Pre-Coder Index Feedback”, IEEE Communications Letters, Vol. 17, No. 8, July 2013

[MET13-D61] ICT-317669 METIS, Deliverable 6.1. “Simulation guidelines”, Oct. 2013

[MMMAG15-D11] mmMAGIC D1.1 “Use case characterization, KPIs and preferred suitable frequency ranges for future 5G systems between 6 GHz and 100 GHz”, November 2015

[MMMAG15-IR41-2] mmMAGIC IR4.1 version 2 “Requirements and general design principles for mm-wave radio interface,” September 2015.

[NGMN15] NGMN Alliance, ‘NGMN White Paper,’ Feb. 2015 (available online https://www.ngmn.org/uploads/media/NGMN_5G_White_Paper_V1_0.pdf)

[NM65] J. A. Nelder and R. Mead, “A simplex method for function minimization,” The Computer Journal, vol. 7, no. 4, pp. 30–38, 1965

[NOK15] Nokia, “5G - a System of Systems for a programmable multi-service architecture White Paper”, October 2015 (available online:




mmMAGIC Public 100

http://info.networks.nokia.com/5gSystemsofSystemsWhitepaper-LP.html)

[ORG10] J. Olmos, S. Ruiz, M. García-Lozano and D. Martín-Sacristán, “Link Abstraction Models based on Mutual Information for LTE Downlink”, COST 2100 TD(10)11052, 2-4 June, 2010, Aalborg (Denmark).

[RCM96] Y. Roy, J-Y Chouinard, S.A. Mahmoud, “Selection Diversity Combining with Multiple Antennas for MM-Wave Indoor Wireless Channels”, IEEE Journal On Selected Areas in Communications, Vol. 14, No. 4, May 1996

[SBF+15] M. Soszka, S. Berger, A.Fehske, M. Simsek, B. Butkiewicz, “Coverage and Capacity Optimization in Cellular Radio Networks with Advanced Antennas”, ITG/IEEE Workshop on Smart Antennas (WSA'15), Ilmenau, 3.3. - 5.3.2015

[SBS+16] M. Soszka, S. Berger, M. Simsek, G. Fettweis, “Energy Efficiency Optimization for 2D Antenna in Self-Organizing Wireless Networks”, EEE Wireless Communications and Networking Conference, 3-6 April 2016 // Doha, Qatar // #IEEEWCNC (accepted)

[SMJ+15] I. Da Silva, G. Mildh, J. Rune et al., “Tight Integration of New 5G Air Interface and LTE to Fulfill 5G Requirements”, IEEE VTC Spring 2015, Glasgow, May 2015

[SMS+16] I. L. d. Silva, G. Mildh, M. Säily, and S. Hailu, “A novel state model for 5G radio access networks,” IEEE International conference on Communications (ICC), May 2016, Kuala Lumpur (accepted)

[Sri10] N. Srivastava, “Diversity Schemes For Wireless Communication – A Short Review”, Journal of Theoretical and Applied Information Technology, 31st May 2010. Vol.15. No.2

[SUM11] I. Siaud, A.M. Ulmer-Moll, 'Interleaving based Resource Allocation Algorithms for Multi Gigabit Wireless OFDM Systems', IWCLD 2011 workshop, Rennes-France

[SUM16] I. Siaud, A.M. Ulmer-Moll, “Green Oriented Multi-Techno Link Adaptation metrics for 5G Heterogeneous Networks”, EURASIP Journal on Wireless Communications and Networking Special Issue on Evolution of Radio Access Network Technologies towards 5G, 2016.

[SUMP16] I. Siaud, A.M. Ulmer-Moll, H. Peng, S. Nanba, K. Moriaki, „C/U-plane splitting architectures and Inter-RAT management for Radio Reconfigurable Systems”, ETSI workshop on Future Radio Technologies focusing on Air Interfaces, Sophia-Antipolis, January 2016

[TSE14] V. Tran Sang, and.M.A. Eltawil, “Link adaptation for wireless systems”, Wireless Commun. Mobile Computing journal, 2014

[WIN1D7.2] WINNER I Deliverable D7.2, “System Assessment Criteria,” June 2004

[WIN2D6.13.11] WINNER II Deliverable D6.13.11, “Final CG "metropolitan area" description for integration into overall System Concept and assessment of key technologies,” Oct. 2007

[WMH14] A. Wijayanti, H. Mahmud, G. Hendrantoro, “Cell-Site Diversity Gain using Various Combining Technique in Dual-Link Millimeter-Wave Communication System Under Impact of Rain Attenuation”, ICICI, Bandung, 2007




mmMAGIC Public 101




mmMAGIC Public 103

Annex




mmMAGIC Public 105




mmMAGIC Public 106

7 Annex A: Partners Input The following table contains the detailed inputs for the envisaged deployments per use case.

Table 7-1 Details on deployments addressed by the p artners Use Case Test

scenario, Type of operation

Deployment details: Cellular, Relay, multi-hop Cell size Antenna configuration BS / UE distribution Mobility Traffic others

Focus of investigation

1 Media on demand

O-I Stand-alone, Low band support

Cellular 200m ISD, regular grid Large array of antenna elements at base station Uniform UE distribution 3 km/h FTP traffic

Verify support for high area capacity

2 Cloud services

O, O-I, access

Low band support

Cellular, dense deployment, cell size up to 200 m, BF at BS and UE, random UE location, moderate mobility support, full buffer traffic,

Extension to higher rates

access O, O/I (tentative), backhaul

Standalone (lo, mid, hi and their combinations) Low band support

Cellular - Ultra Dense deployment/small cells (ISD 100m, 75m, 50m), macro deployment (LTE with ISD 250m), frequency bands (2, 5.6, 10, 28, 39, 73 GHz), beamforming at BS and UE, random UE location, full buffer and finite buffer traffic types, no mobility, multi-connectivity, mm-wave backhaul analysis at 73GHz (basic coverage and performance evaluation)

Capacity and throughput requirements

3 Dense urban society

O / access standalone Cellular, ultra-dense, average ISD few 10 m, random UE location, uniform distribution , no BF at UE, strong BF at BS, low or no mobility

Inter-node coordination with high interference

O / back-haul and access

standalone Cellular, dense small cell, tens to hundreds of meters, random UE location, uniform distribution, BF at BS and UE, configurable tx power, no mobility, full buffer traffic

O/ O-I/ access

Low band support

Cellular, dense deployment, ISD up to 100 m, BF at BS and UE, random UE location, moderate mobility support, full buffer traffic,

Extension capability of baseline use case 6

O / access Standalone and low-band support

Cellular, small cells, Multi-link

4 Smart office

I/ access Standalone and low-band support

Cellular (possibly aided by 802.11ad), ultra-dense deployment, small cells, BF at BS and UE, limited mobility, relaying, data center, transport protocols

Throughput maximization, cell-edge throughput, delay minimization

5 Immersive early 5G

O, back-haul

Low band support

- Dense deployment, Urban street level, (ISD <100 m), target frequency (initially 28 GHz), beamforming at backhaul node, different types of traffic incl. HTTP

Impact of different link scheduling




mmMAGIC Public 107

experience

and routing algorithms on QoE in terms of network latency

6 50+ Mbps every-where

I/O-I/O, access

standalone Cellular, centralized baseband processing, distributed antennas, fronthaul links, random UE location, uniform distribution

Early triggering of retrains-missions

O / O-I, access

Low band support

Cellular, dense deployment, cell size up to 200 m, BF at BS and UE, random UE location, moderate mobility support, full buffer traffic,

Baseline capabilities

O / O-I, access

Low band support

Cellular, cell size 166m, random UE location, uniform distribution, FTP/MBB traffic, co-located LTE (low frequency) and 5G (high frequency) including LTE-5G tight integration. Non co-located LTE and 5G, 5G on small cells, LTE on macro cells (low freq).

Compare standalone to Low band support

O / I, access and back-haul

Standalone and low-band support

Cellular, dense deployment, cell size up to 200 m, BF at BS and UE, random UE location, mobility support, small cells, relaying

Interplay of multi-connectivity and mobility management

access O, O/I (tentative)

Standalone (lo, mid, hi and their combinations) Low band support

Cellular - Ultra Dense deployment/small cells (ISD 100m, 75m, 50m), macro deployment (LTE with ISD 250m), frequency bands (2, 5.6, 10, 28, 39, 73 GHz), beamforming at BS and UE, random UE location, full buffer and finite buffer traffic types, no mobility, multi-connectivity

Cell-edge throughput requirements,

7 Moving hot spots

O, back-haul

Low band support

Dense deployment, Urban street level, (ISD <100 m), target frequency (initially 28 GHz), beamforming at BS, moving vehicle with high speed, full buffer

Initial analysis and evaluation on the impacts of beam tracking accuracy and signalling overhead, Dynamic self-backhauling to provide high data rate.

8 Tactile internet

O, access Standalone and low-band support

small cells, Multi-link




mmMAGIC Public 108

8 Annex B: Test scenarios The different outdoor test scenarios are shown in Figure 8-1 - Figure 8-3.

Figure 8-1 Manhattan grid test scenario

Figure 8-2 Madrid grid test scenario

Figure 8-3 Asian city grid test scenario

Figure 8-4 and Figure 8-5shows the indoor test scenarios.




mmMAGIC Public 109

Figure 8-4 Virtual reality office test scenario (le ft) and WINNER indoor office test scenarios

(right)

Figure 8-5: Shopping mall test scenario

Mixed outdoor-indoor test scenario is depicted in Figure 8-6 below.

Figure 8-6 Dual-stripe model as used in 3GPP. It co nsist of two multi-floor and multi-room

buildings located in close vicinity.

10 m

10 m

10 m

10 m

10 m




mmMAGIC Public 110

9 Annex C: Coordination mechanisms to minimize inter-cell interferences in the presence of beamforming

The inter-cell coordination scheme proposed in subsection 4.6.1 relies on beam indicators conveniently labelling the transmitted beams and any constituent sub-beams. Beam indicators, as acquired by devices, can be reported back to their corresponding serving cells by means of a special control message hereinafter denoted as “Automatic Interference Relation Report (AIRR)” (Figure 9-1). This message conveys pairs of (interfering cell ID, interfering beam indicator) as detected by users, and will be reported periodically or upon certain conditions such as a request from the 5G NB or the appearance or disappearance of an interfering beam (Figure 9-2).

The 5G NB will collect multiple AIRR messages from the users to populate a table of interference relationships, denoted as “Automatic Interference Relation Table” (AIRT) (Figure 9-3)The entries BIij in such table will contain the beam indication as reported by user i related to cell j, in such a way that the 5G NB acquires an accurate picture of the interference relationships with beams from other surrounding cells.

Figure 9-1 Possible structure of the Automatic Inte rference Relation Report (AIRR) for the

proposed inter-cell beam coordination mechanism

INTERFERING CELL IDENTITY

INTERFERING BEAM INDICATOR



…



Cell 1

Cell 2

Cell M

…




mmMAGIC Public 111

Figure 9-2 Periodic/aperiodic reporting of AIR repo rts upon request from the 5G NB, for the

proposed inter-cell beam coordination mechanism

Figure 9-3 Automatic Interference Relation Table (A IRT) showing the beam indicators BIij as

reported back by user i related to cell j, for the proposed inter-cell beam coordination mechanism

With this information the serving cell can exchange the AIRT with the neighbour cells involved, so as to inform of any strong interference being caused by specific beams. As a result, some cells can agree on a suitable coordination strategy in any of time, frequency or beam domains. Advanced coordinated beamforming techniques may require costly exchange of channel state

5G NBUE

5G NB REQUESTS FOR AIR REPORTS

UEs SEND PERIODIC/APERIODIC AIR

REPORTSAIR REPORT

5G NB adds/removes entriesin the AIRT table according to

AIR reports

UEs scan interferences, construct AIR reports and send them in a periodic oraperiodic way through a

control message

Interfering beams

Cell Identity

Beam Indicator

AUTOMATIC INTERFERENCE RELATION TABLE (AIRT)

User #1

User #2

User #M

Cell #1 Cell #2 Cell #N

11BI 12BI 13BI NBI1

21BI 22BI 23BI

Cell #3

NBI2

1MBI 2MBI 3MBI MNBI

… … … …

…

…

…

BIJ: BEAM INDICATOR FROM CELL J INTERFERING USER I




mmMAGIC Public 112

information among the nodes. Other simpler methods can involve smart resource management techniques, like time-based or frequency-based scheduling on the different beams (Figure 9-4) after agreeing on a common pattern to be followed. Preference over one method or another may depend on the backhaul capacity and latency constraints, and specifically with the ability to exchange large amounts of information with low latency. If it is not the case simpler RRM methods can be more interesting.

Figure 9-4 Illustration of a simple time-domain coo rdination between cells A and B each coordinating different beams, for the proposed inte r-cell beam coordination mechanism

It is apparent that the AIRT table should be quickly populated and exchanged to avoid outdating effects, particularly when users are moving fast or beams are too sharp.

time

Cell A beam’s transmission

Cell B beam’s transmission

ON

OFF ON

OFF ON

OFF

ON

OFF

OFF

ON ON

OFF

1 subframe

Transmissionpower




mmMAGIC Public 113

10 Annex D: Cell cluster examples

Example 1: The Cluster Head is an AP serving a cell in the cluster set as shown in Figure 10-1. In the given example, UE1 detects C12, C23, C34 and C41. The cell C12 has the strongest link. UE1 selects and connects to cell C12. Using the information from network manager, the data and control planes of UE1 are connected to AP1. The network manager is a separate network entity that knows the network topology and is able to decide which AP should be the cluster head for a given cluster of cells.

Figure 10-1 Cluster of cells example #1: The Cluste r head is an AP serving a cell in the cluster

set. UE1 selects and connects to cell C12 (stronges t cell). In case the link to C12 is blocked, the user data and control planes are re-routed to AP2 t o serve the UE1 via cell C23

In case the link to C12 is blocked, the user data and control planes are re-routed to AP2 to serve the UE1 via cell C23

For UE 1:

• Members of cluster set: Cells C12, C23, C34, C41; • Serving cell: C23; • Standby cells: C12, C34, C41; • Cluster Head: AP 1; • Secondary APs: AP 2, 3, 4.

For UE 2

• Members of cluster set: Cells C22, C31; • Serving cell: C22; • Standby cell: C31; • Cluster Head: AP 2; • Secondary APs: AP 3.

Cluster set of cells for UE 1, UE 2

Data/Control planes

AP 2 X5

AP 1

C13

C11

C12

C14 C21

C22 C23

C24

AP 3 AP4

C43

C41

C42

C44 C31

C32 C33

C34

UE 1 UE 2




mmMAGIC Public 114

Example 2: The Cluster Head is an AP which is not serving any cell in the cluster set This example is a possible evolution of a situation described in Example 1. Compared to Example 1, the UE1 moves and can now detect only C23 and C34, as shown in Figure 10-2.

Figure 10-2 Cluster of cells example #2: The Cluste r Head is an AP which is not serving any cell

in the cluster set

In this new situation shown in Figure 10-2 for UE 1, the roles of network entities will be as follows:

• Serving cell: C23

• Standby cell: C34

• Cluster Head: AP 1

• Secondary APs: AP 2, 3

Cluster set of cells for the UE

Data/Control planes

AP 2 X5

AP 1

C13

C11

C12

C14 C21

C22 C23

C24

AP 3 AP4

C43

C41

C42

C44 C31

C32 C33

C34

UE1

d3.1 initial concepts on 5g architecture and …...document: h2020-ict-671650-mmmagic/d3.1 date:...

Documents