d5.2: mac approaches with fbmc (final)...this framework supports aggregation and radio access...

Grant Agreement No.: 671705 Research and Innovation action Call Identifier: H2020-ICT-2014-2

quality of Service Provision and capacity Expansion through Extended-DSA for 5G

D5.2: MAC approaches with FBMC (final)

Version: v1.5

Deliverable type R (Report)

Dissemination level PU (Public)

Due date 30/06/2017

Achievement date 30/06/2017

Lead editor Bismark Okyere (IMC)

Authors Benoit Miscopein, Rida El Chall (CEA), Marcin Filo (UNIS), Bismark Okyere (IMC)

Reviewers Seiamak Vahid (UNIS), Valerio Frascolla (IMC)

Work package, Task WP5, T5.2

Keywords MAC Specification, MAC functions, LMAC, HMAC, FBMC MAC, DCS MAC, Primitives definitions, Simulations

Abstract

This document concludes on SPEED-5G’s eDSA MAC proposed in [1], with a protocol specification and the final simulation results, analysis and evaluation. The eDSA MAC specification includes detailed description of procedures and primitives identified in order to operate the two novel SPEED-5G MAC protocols: Dynamic Channel Selection (DCS) and Filter-Bank Multicarrier (FBMC)-based MAC protocols. Specifications also give a fully detailed description the MAC procedures, frame formats and information elements. Following a calibration phase, the document also provides the simulation results for comparison of the MAC designs, based on common simulations scenarios and assumptions, allowing derivation of MAC selection guidelines considering the context of operation.


© 2015 - 2018 SPEED-5G Consortium Parties of 225

Document revision history

Version Date Description of change List of contributor(s)

v0.1 2017-01-26 Initial version Intel

v0.2 2017-02-03 Added DCS design description UNIS

v0.3 2017-02-03 Added FBMC design description CEA

v0.4 2017-02-24 Updated chapters 1 and 2 Intel

v0.5 2017-04-20 Update sections 2.4 and 3 CEA

v0.6 2017-05-01 Re-aligned all the sections Intel

v0.7 2017-06-12 Updated DCS-MAC section 3 UNIS

v0.8 2017-06-12 Updated FBMC section and simulations methodology

CEA

v0.9 2017-06-13 First review UNIS

v1.0 2017-06-14 Acted on first review on sec 2.1 and 2.2 and expanded sec 2.5 and Appendix

Intel

v1.1 2017-06-16 Revised the Appendix Intel

v1.2 2017-06-22 Modified sec 2.4, 3 (FBMC MAC results)

CEA

v1.3 2017-06-23 Modified sec 2.3 UNIS

v1.4 2017-06-25 Added Introduction, Conclusion, Executive summary and Abstract

Intel

v1.5 2017-06-30 Final editing and submission EURES

Disclaimer

This report contains material which is the copyright of certain SPEED-5G Consortium Parties and may not be reproduced or copied without permission.

All SPEED-5G Consortium Parties have agreed to publication of this report, the content of which is licensed under a Creative Commons Attribution-Non Commercial-NoDerivs 3.0 Unported License1.

Neither the SPEED-5G Consortium Parties nor the European Commission warrant that the information contained in the Deliverable is capable of use, or that use of the information is free from risk, and accept no liability for loss or damage suffered by any person using the information.

Copyright notice

© 2015 - 2017 SPEED-5G Consortium Parties

1 http://creativecommons.org/licenses/by-nc-nd/3.0/deed.en_US



Executive Summary

This deliverable is the final report on SPEED-5G MAC specification and evaluation. It contains a detailed description of the SPEED-5G MAC proposal which is composed of a multi-RAT MAC framework able to perform extended Dynamic Spectrum Access (eDSA) and two MAC protocols which fit with the framework and are considered as possible 5G Air Interface candidates.

The eDSA MAC framework is composed of two sub-layers: Higher-MAC (HMAC) and Lower-MAC (LMAC). The LMAC is the work horse, and is composed of different RAT-specific MAC protocols with the potential of operating concurrently. HMAC coordinates the operation of the different instances of the RAT-specific MAC protocols at the LMAC. The main innovations of the eDSA MAC framework are:

- Seamless traffic (control and user data) steering and offload from one RAT to the other.

- Inter-RAT coordination at the MAC level, which differs from the LWA approach.

- Aggregation of heterogeneous radio resources for high-speed data transmission

This framework supports aggregation and Radio Access Network (RAN) split at the MAC layer. It is an approach that differs from the recently standardised LTE/Wi-Fi Aggregation (LWA) feature, where the aggregation and/or RAN split is at the PDCP layer. The framework is capable of supporting Legacy LTE-A, Wifi and novel 5G air interfaces within a single communication system. The description of the SPEED-5G MAC framework is accompanied by a set of essential eDSA procedures which are related to the so-called monitoring plane operation, the configuration of the MAC by RRM (Radio Resource Management) entity or the configuration and management of traffic steering decision to support carrier aggregation or traffic offload features.

Besides this framework, two novel 5G MAC protocols are also described: Dynamic Channel Selection (DCS) MAC and Filter-Bank Multi-carrier (FBMC) MAC. The DCS-MAC is a novel approach TDD-based MAC protocol designed to support high-capacity broadband wireless access in ultra-dense deployments. It has been designed as possible solution to replace LTE in licensed and lightly licensed spectrum bands. FBMC relies on a more common MAC approach but it assumes a novel FBMC physical layer. It has been specifically designed to operate in the 5 GHz band and to exploit the spectral confinement of the signal to facilitate the coexistence with other systems. This deliverable gives a full specification of these two MAC protocols, describing MAC procedures, the frame formats for data and control packets, and the list of the primitives with their corresponding information elements.

This document also presents the simulation results of the proposed MAC protocols. They have been obtained using system-level simulations (SLS) which have been calibrated to ensure a fair comparison of the results. The simulations have been done assuming dense outdoor networks relying on a regular hexagonal grid based on inter site distances of 30 to 100 meters. The simulations scenarios consider different traffic models (full buffer and bursty traffic) as well as coexistence with WiFi-like systems. Essentially, simulations show that the MAC protocols provide promising results when used in the conditions they have been designed for. First of all, the 2 MAC designs outperforms genuine WiFi systems as the results obtained when simulating IEEE802.11ac with the same parameters provide lower throughputs (3 to 4 times less area spectral efficiency compared to FBMC and DCS MAC); which demonstrates gains brought about by the SPEED-5G solutions. When comparing DCS and FBMC MAC designs, it appears that DCS MAC provides better results than FBMC MAC (factor of 2 on the area spectral efficiency in downlink full buffer). This is however expected since FBMC relies on a Listen-Before-Talk approach which de facto limits the channel occupancy. When coexistence with other systems is considered, FBMC MAC provides better results as the LBT feature induces a fair access with a system like WiFi; in the same situation DCS MAC clearly impacts the coexisting systems as it can lead to the blocking of a majority of coexisting “access points”. However, the results tend to show that appropriate parameters tuning on both MAC designs allows optimization of the performance in many different situations.



The provided comparisons clearly shows that DCS-MAC makes use of techniques which enable effective utilization of radio resources and it can be considered for an operation in licensed and lightly-licensed bands which do not mandate the use of the LBT procedure. Along the same line, FBMC MAC can be considered as an interesting solution for situations where the coexistence with other systems is mandated. The FBMC MAC provides advantages of fairness and of the spectral confinement of FBMC signal.



Table of Contents

Executive Summary ...................................................................................................................... 3

Table of Contents ......................................................................................................................... 5

List of Tables ................................................................................................................................ 9

List of Figures ............................................................................................................................. 13

Abbreviations ............................................................................................................................. 18

1 Introduction ................................................................................................................. 21

2 eDSA MAC Specification ............................................................................................... 23

2.1 Speed-5G MAC overview ....................................................................................................... 23

2.2 eDSA MAC-related Signalling Procedures .............................................................................. 25

2.2.1 Introduction ........................................................................................................................... 25

2.2.2 Measurements configuration and reporting procedures ...................................................... 25

2.2.3 MAC configuration procedures.............................................................................................. 28

2.2.4 Traffic steering triggered by RRM procedure ........................................................................ 29

2.2.5 Procedure for scheduling transmission on a specific Lower MAC ......................................... 32

2.3 Dynamic Channel Selection (DCS) MAC specifications .......................................................... 33

2.3.1 DCS-MAC Overview................................................................................................................ 33

2.3.2 Frame formats ....................................................................................................................... 38

2.3.3 MAC constants ....................................................................................................................... 48

2.3.4 DCS-MAC Procedures ............................................................................................................. 48

2.4 Filter-Bank Multicarrier (FBMC)-based MAC specification .................................................... 80

2.4.1 FBMC MAC design overview .................................................................................................. 80

2.4.2 Frame formats ....................................................................................................................... 86

2.4.3 Information elements ............................................................................................................ 92

2.4.4 MAC constants ....................................................................................................................... 98

2.4.5 FBMC MAC procedures .......................................................................................................... 98

2.5 eDSA MAC Primitives ........................................................................................................... 114

2.5.1 C_5GRRC_HMAC SAP ........................................................................................................... 115

2.5.2 M_cRRM_HMAC SAP ........................................................................................................... 115

2.5.3 C_HMAC_LMAC SAP ............................................................................................................ 115

2.5.4 C_HMAC_PHY SAP ............................................................................................................... 116

2.5.5 C_LMAC_PHY SAP ................................................................................................................ 116

2.5.6 M_HMAC_PHY SAP .............................................................................................................. 117

2.5.7 C_5GRLC_HMAC SAP ........................................................................................................... 117

2.5.8 D_5GRLC_HMAC SAP ........................................................................................................... 117

2.5.9 D_LMAC_PHY SAP ................................................................................................................ 117



3 eDSA MAC Simulations ............................................................................................... 119

3.1 Introduction ......................................................................................................................... 119

3.2 Methodology ....................................................................................................................... 119

3.2.1 System level simulators calibration ..................................................................................... 119

3.2.2 Performance metrics ........................................................................................................... 122

3.2.3 Common simulation parameters ......................................................................................... 122

3.2.4 Interference modelling ........................................................................................................ 125

3.2.5 Modelling coexistence with “WiFi” systems ........................................................................ 125

3.3 DCS-Based MAC Simulation ................................................................................................. 127

3.3.1 Simulation assumptions ....................................................................................................... 127

3.3.2 Scenario description ............................................................................................................ 128

3.3.3 Simulation Results ............................................................................................................... 130

3.4 FBMC-Based MAC Simulation .............................................................................................. 143

3.4.1 Simulation assumptions ....................................................................................................... 143

3.4.2 Simulation Results ............................................................................................................... 148

4 eDSA MAC Strategies .................................................................................................. 164

4.1 Introduction ......................................................................................................................... 164

4.2 eDSA MAC strategy comparison .......................................................................................... 164

4.2.1 Non-coexistence scenario .................................................................................................... 164

4.2.2 Coexistence scenario ........................................................................................................... 167

4.3 eDSA MAC versus legacy systems ........................................................................................ 168

4.4 Summary .............................................................................................................................. 170

5 Conclusion ................................................................................................................. 172

References ............................................................................................................................... 174

Appendix A Primitives Description ......................................................................................... 176

A.1.1 TrafficSteeringConfig.request .............................................................................................. 176

A.1.2 CellMACConfiguration.request ............................................................................................ 176

A.1.3 CellMACConfiguration.confirm ............................................................................................ 177

A.1.4 MeasurementConfig.request ............................................................................................... 177

A.1.5 MeasurementConfig.confirm .............................................................................................. 178

A.1.6 Measurement.request ......................................................................................................... 179

A.1.7 Measurement.confirm ......................................................................................................... 179

A.1.8 Measurement.indicate ........................................................................................................ 180

A.1.9 ChannelIdentification.indicate............................................................................................. 180

A.1.10 HLSignalingMessage.request ............................................................................................... 181

A.1.11 HLSignalingMessage.indicate .............................................................................................. 181

A.1.12 LMACConfiguration.request ................................................................................................ 182



A.1.13 LMACConfiguration.confirm ................................................................................................ 182

A.1.14 LMACConfiguration.indicate ................................................................................................ 183

A.1.15 PHYConfiguration.request ................................................................................................... 183

A.1.16 PHYConfiguration.confirm ................................................................................................... 184



A.1.19 Measurement.indicate ........................................................................................................ 185



A.1.22 RLCBufferStatus.request ...................................................................................................... 186

A.1.23 RLCData.indicate .................................................................................................................. 186

A.1.24 RLCData.response ................................................................................................................ 187

A.2 FBMC-Based MAC Messages ............................................................................................... 187

A.2.1 LMACStart.request............................................................................................................... 187

A.2.2 BeaconReception.indicate ................................................................................................... 187

A.2.3 Association.request ............................................................................................................. 188

A.2.4 Association.confirm ............................................................................................................. 188

A.2.5 Association.indicate ............................................................................................................. 188

A.2.6 De -association.indicate ....................................................................................................... 188

A.2.7 UEPaging.request ................................................................................................................. 189

A.2.8 UEPaging.response .............................................................................................................. 189

A.2.9 SchedFrameTrigger.request ................................................................................................ 189

A.2.10 SchedFrameTrigger.confirm ................................................................................................ 190






A.2.16 PHYPerformCCA.request ..................................................................................................... 196

A.2.17 PHYPerformCCA.confirm ..................................................................................................... 196

A.2.18 PHYFrameTransmit.request ................................................................................................. 197

A.2.19 PHYFrameTransmit.confirm ................................................................................................. 197

A.2.20 PHYFrameReceive.indicate .................................................................................................. 197

A.2.21 PerformSensing.request ...................................................................................................... 198

A.2.22 PerformSensing.confirm ...................................................................................................... 198

A.3 DCS-Based MAC Messages .................................................................................................. 199






A.3.4 RadioBearerEstablish.request ............................................................................................. 205

A.3.5 RadioBearerEstablish.confirm ............................................................................................. 205

A.3.6 RadioBearerEstablish.indicate ............................................................................................. 206

A.3.7 RadioBearerRelease.request ............................................................................................... 206

A.3.8 RadioBearerRelease.confirm ............................................................................................... 207

A.3.9 RadioBearerRelease.indicate ............................................................................................... 207

A.3.10 SchedTransmission.request ................................................................................................. 208

A.3.11 SchedTransmission.confirm ................................................................................................. 208



A.3.14 PHYFrameTransmit.request ................................................................................................. 209

A.3.15 PHYFrameTransmit.confirm ................................................................................................. 210

A.3.16 PHYFrameReceive.indicate .................................................................................................. 210

A.3.17 ChannelMeasurement.request ............................................................................................ 211

A.3.18 ChannelMeasurement.confirm............................................................................................ 212

Appendix B Link-to-system level mapping – Error Model ........................................................ 213

B.1 FBMC-MAC simulation error model .................................................................................... 213

B.2 DCS MAC simulation error model ........................................................................................ 214

Appendix C Generic eDSA Procedures Description .................................................................. 216

C.1 Network Attachment Procedures ........................................................................................ 216

C.2 Network Detachment Procedures ....................................................................................... 219

C.3 Tracking Area Update Procedures ....................................................................................... 220

C.4 RAB Management Procedures ............................................................................................. 222

C.5 PDCP and RLC Configuration Procedures ............................................................................ 225



List of Tables

Table 1: Mapping of number of required radio bearers to NRB ............................................................ 36

Table 2: OFDM numerology of DCS-MAC PHY for 2MHz channel......................................................... 37

Table 3: OFDM numerology of DCS-MAC PHY for 20MHz channel....................................................... 37

Table 4: Modulation and coding schemes of DCS-MAC PHY ................................................................ 38

Table 5: C-Field format of the primary allocation block ....................................................................... 39

Table 6: C-Field Header description for primary allocation block ......................................................... 39

Table 7: C-Field format for the secondary allocation block(s) .............................................................. 39

Table 8: C-Field Header description for secondary allocation block ..................................................... 40

Table 9: System Identity message format ............................................................................................. 40

Table 10: System Information message format .................................................................................... 41

Table 11: In-band coexistence message format.................................................................................... 41

Table 12: Blind slot information message format ................................................................................. 41

Table 13: System information status message format ......................................................................... 42

Table 14: Paging message format ......................................................................................................... 42

Table 15: Network information message format .................................................................................. 43

Table 16: System information status message format ......................................................................... 43

Table 17: Connection Control message format .................................................................................... 43

Table 18: Radio Bearer Attributes Control message format ................................................................. 44

Table 19: Physical channel commands format ...................................................................................... 44

Table 20: Out-of-band coexistence message format ............................................................................ 45

Table 21: Asymmetric Acknowledgement Information message format ............................................. 45

Table 22: Channel Quality Indication Type 1 message format ............................................................. 46

Table 23: Channel Quality Indication Type 2 message format ............................................................. 46

Table 24: MCS Indication Type 1 message format ................................................................................ 47

Table 25: MCS Indication Type 2 message format ................................................................................ 47

Table 26: Basic U-Field format .............................................................................................................. 48

Table 27: DCS-MAC constants ............................................................................................................... 48

Table 28: Superframe durations for load based access ........................................................................ 83

Table 29: Broadband FBMC parameters ............................................................................................... 83

Table 30: Modulation and coding schemes of FBMC MAC ................................................................... 84

Table 31: General Frame format ........................................................................................................... 86

Table 32: Generic frame control format ............................................................................................... 86

Table 33: Frame type field values ......................................................................................................... 86

Table 34: Sequence Control field format .............................................................................................. 87

Table 35: Access Control field format ................................................................................................... 87



Table 36: Beacon frame header settings............................................................................................... 88

Table 37: Information elements composing the beacon payload ........................................................ 88

Table 38: Control frame subtype field values ....................................................................................... 89

Table 39: Acknowledgment frame payload .......................................................................................... 89

Table 40: Command frame subtype values ........................................................................................... 90

Table 41: Payload of a de-association request frame ........................................................................... 90

Table 42: Payload of a service establishment request frame ............................................................... 90

Table 43: Payload of a service establishment response frame ............................................................. 91

Table 44: Payload of a measurement configuration request frame ..................................................... 91

Table 45: Payload of a measurement configuration response frame ................................................... 91

Table 46: Payload of a measurement report frame .............................................................................. 91

Table 47: Data frame subtype values .................................................................................................... 91

Table 48: Payload of an uplink data frame ........................................................................................... 92

Table 49: List of information elements ................................................................................................. 92

Table 50: Superframe IE ........................................................................................................................ 93

Table 51: Priority field values for resource allocation for ACK vs. control frame in CAP ...................... 93

Table 52: Associated devices IE ............................................................................................................. 93

Table 53: UE resource allocation IE. ...................................................................................................... 94

Table 54: Paging IE ................................................................................................................................ 94

Table 55: Channel switching scheduling IE ........................................................................................... 94

Table 56: Quiet period scheduling ........................................................................................................ 95

Table 57: Service establishment request IE .......................................................................................... 95

Table 58: QCI values .............................................................................................................................. 95

Table 59: Service establishment response IE ........................................................................................ 96

Table 60: Association response IE ......................................................................................................... 96

Table 61: De-association request IE ...................................................................................................... 96

Table 62: Measurement configuration request IE ................................................................................ 97

Table 63: Measurement configuration response IE .............................................................................. 97

Table 64: Measurement configuration response IE .............................................................................. 98

Table 65: FBMC MAC constants ............................................................................................................ 98

Table 66 - Parameters for calibration of system level simulators....................................................... 120

Table 67: LOS statistics for all links ..................................................................................................... 121

Table 68: Simulation parameters for MAC designs comparison ......................................................... 124

Table 69: FTP Traffic Model 2 .............................................................................................................. 125

Table 70: Wifi parameters for coexistence simulations ...................................................................... 126

Table 71: DCS-MAC specific simulation parameters ........................................................................... 128

Table 72: LBT-based “WiFi-like” system specific simulation parameters ........................................... 129



Table 73: Summary of DCS-MAC performance metrics for full buffer traffic model with 100% DL traffic ................................................................................................................................................... 131

Table 74: Summary of DCS-MAC performance metrics for FTP traffic model with 100% DL traffic .. 133

Table 75: DCS-MAC performance results using different ISDs, full buffer 80% DL and 20% UL ......... 135

Table 76: DCS-MAC performance results for various number of SC TRXs, using different ISDs and full buffer 100% DL traffic model .............................................................................................................. 136

Table 77: DCS-MAC performance results for various number of SC TRXs, using different ISDs and full buffer with 80% DL and 20% UL traffic ............................................................................................... 138

Table 78: DCS-MAC performance in coexistence scenario for various ML settings, assuming Full buffer model with 100% DL traffic in coexistence scenario........................................................................... 141

Table 79: DCS-MAC performance in coexistence scenario for various MI settings, assuming full buffer model with 100% DL traffic ................................................................................................................. 143

Table 80: Full Buffer - Non coexistence scenario cases ...................................................................... 144

Table 81: Full Buffer - Wi-Fi coexistence scenario cases ..................................................................... 144

Table 82: Full Buffer - FBMC K = 2 and OFDM simulations ................................................................. 144

Table 83: FTP trafic - Non coexistence scenario cases ........................................................................ 145

Table 84: FTP traffic - Wi-Fi coexistence scenario cases ..................................................................... 145

Table 85: out-of-band emission power with respect to occupied bandwidth .................................... 147

Table 86: FBMC PHY and MAC configuration parameters .................................................................. 147

Table 87: Performance of FBE and LBE using different ISDs and ED thresholds, Full-buffer 100%DL, No fading ................................................................................................................................................... 150

Table 88: Performance of FBE and LBE using different ISDs, CCA-ED = -62 dBm, full buffer 100%DL, No fading, Frequency reuse 1 and 3 ......................................................................................................... 151

Table 89: Performance of FBE and LBE using different ISDs, CCA-ED = -62 dBm, full buffer 100%DL, uncorrelated TU channel, Frequency reuse 1 and 3 ........................................................................... 152

Table 90: Performance of LBE with different ISDs and different PHYs (FBMC K = {4, 2}, OFDM), full buffer 100%DL, uncorrelated TU channel, Frequency reuse 1 and 3 ................................................. 153

Table 91: Performance of FBE and LBE using different ISDs, full buffer traffic 80%DL/20%UL, No fading, Frequency reuse 1 and 3 ......................................................................................................... 155

Table 92: Performance of FBE and LBE using different ISDs and ED thresholds, FTP traffic D = 5 s, No fading ................................................................................................................................................... 157

Table 93: Performance comparisons for FBE and LBE using different ISDs, CCA-ED = -62 dBm, FTP traffic D = 5, 2 sec, No fading .............................................................................................................. 158

Table 94: Performance of LBE FBMC-MAC in coexistence scenario, same density of WiFi APs, full buffer, No fading ................................................................................................................................. 160

Table 95: Performance of LBE FBMC-MAC in coexistence scenario, same density of WiFi APs using various ED thresholds, full buffer, No fading ...................................................................................... 160

Table 96: Performance comparison of DCS-MAC (assuming ML=0.4) and FBMC-MAC (assuming ED threshold = -62dBm) for various ISDs, full buffer traffic model with 100% DL traffic ........................ 165

Table 97: Performance comparison of DCS-MAC (assuming ML=0.4) and FBMC-MAC (assuming ED threshold = -62dBm) for various ISDs , FTP traffic model with 100% DL traffic and mean inter-arrival time of 2 sec. ....................................................................................................................................... 165



Table 98: Performance comparison of DCS-MAC (assuming ML=0.4) and FBMC-MAC (assuming ED threshold = -62dBm) for various ISDs, full buffer traffic model with 80% DL traffic and 20% UL traffic ............................................................................................................................................................. 166

Table 99: Performance comparison of DCS-MAC (assuming ML=0.2 for ISD=30m and ML=0.4 for ISD=100m) and FBMC-MAC (assuming ED threshold = -82dBm) for various ISDs, full buffer traffic model with 100% DL traffic ................................................................................................................. 168

Table 100: WiFi specific simulation parameters ................................................................................. 169

Table 101: Comparison of average area spectral efficiency (b/s/Hz/Km2) performance for different MAC designs ........................................................................................................................................ 170



List of Figures

Figure 1: Enhanced SPEED-5G eDSA MAC Framework Architecture and functional blocks ................. 24

Figure 2: Procedure for measurement configuration of HMAC by cRRM............................................. 26

Figure 3: Procedure for measurement collection by cRRM .................................................................. 26

Figure 4: Procedure for measurement configuration of LMAC by HMAC ............................................ 27

Figure 5: Procedure for measurement collection by HMAC ................................................................. 27

Figure 6: Generic procedure for MAC configuration by RRM entity ..................................................... 28

Figure 7: LMAC reconfiguration procedure .......................................................................................... 28

Figure 8: Generic procedure for traffic steering configuration, SC Side ............................................... 30

Figure 9: Generic procedure for traffic steering configuration at UE side, to switch AI#2 on .............. 31

Figure 10: Generic procedure of traffic aggregation for capacity boosting .......................................... 32

Figure 11: Generic procedure of traffic offload for interference mitigation ........................................ 32

Figure 12: Generic procedure for frame scheduling ............................................................................. 33

Figure 13: Frame and slot structure ...................................................................................................... 34

Figure 14: Multi-frame structure .......................................................................................................... 34

Figure 15: Multiple access and physical channel structure (Physical channel = time slot + frequency channel combination) ........................................................................................................................... 34

Figure 16: C-Field structure for 2 MHz bandwidth ................................................................................ 38

Figure 17: C-Field structure for bandwidth larger than 2MHz .............................................................. 38

Figure 18: Transmission over a dedicated radio bearer (TX side) ......................................................... 50

Figure 19: Transmission over a dedicated radio bearer (RX side)......................................................... 51

Figure 20: Transmission over a dedicated radio bearer (Over the air) ................................................. 51

Figure 21: Transmission over a common radio bearer (TX side) .......................................................... 52

Figure 22: Transmission over a common radio bearer (RX side) .......................................................... 52

Figure 23: Transmission over a common radio bearer (Over the air) ................................................... 53

Figure 24: Message sequence chart for execution of pilot radio bearer establishment in RRC idle state (UE side). ............................................................................................................................................... 54

Figure 25: Message sequence chart for pilot radio bearer establishment in RRC idle state (Small Cell side). ...................................................................................................................................................... 55

Figure 26: Message sequence chart for successful pilot radio bearer establishment (Over the air). .. 56

Figure 27: Message sequence chart for unsuccessful pilot radio bearer establishment (Over the air). ............................................................................................................................................................... 57

Figure 28: Message sequence chart for pilot radio bearer establishment in RRC Connected state (Initiating side). ..................................................................................................................................... 58

Figure 29: Message sequence chart for execution of bearer establishment in RRC Connected state (responding side). .................................................................................................................................. 59

Figure 30: Message sequence chart for non-pilot bearer establishment (Initiating Side). .................. 61

Figure 31: Message sequence chart for non-pilot bearer establishment (Responding Side). .............. 62



Figure 32: Message sequence chart for successful non-pilot asymmetric bearer establishment (Over the air). .................................................................................................................................................. 63

Figure 33: Message sequence chart for successful non-pilot symmetric bearer establishment (Over the air). .................................................................................................................................................. 63

Figure 34: Message sequence chart for unsuccessful non-pilot asymmetric bearer establishment (Over the air). ........................................................................................................................................ 64

Figure 35: Message sequence chart for unsuccessful non-pilot symmetric bearer establishment (Over the Air). .................................................................................................................................................. 65

Figure 36: Message sequence chart for execution of common bearer establishment (Small cell side)66

Figure 37: Message sequence chart for execution of common bearer establishment (UE side) ......... 67

Figure 38: Message sequence chart for intra-cluster radio bearer handover procedure (Initiator side). ............................................................................................................................................................... 68

Figure 39: Message sequence chart for intra-cluster radio bearer handover procedure (Responder side). ...................................................................................................................................................... 69

Figure 40: Message sequence chart for inter-cluster radio bearer handover procedure (UE side). .... 70

Figure 41: Message sequence chart for inter-cluster radio bearer handover procedure (Small Cell Side). ...................................................................................................................................................... 71

Figure 42: Message sequence chart for radio bearer release (Initiator Side). ..................................... 72

Figure 43: Message sequence chart for radio bearer release (Responder Side). ................................. 73

Figure 44: Message sequence chart for symmetric radio bearer release (Over-the-air). .................... 73

Figure 45: Message sequence chart for asymmetric radio bearer release (Over-the-air). .................. 73

Figure 46: Message sequence chart for Bearer release with RRC connection release (Initiator Side). 74

Figure 47: Message sequence chart for bi-directional bearer release (Responder Side). .................... 75

Figure 48: Message sequence chart for paging procedure (Small Cell side). ....................................... 76

Figure 49: Message sequence chart for paging procedure (UE side). .................................................. 76

Figure 50: Message sequence chart for system information indication procedure (Small Cell side). .. 77

Figure 51: Message sequence chart for system information indication procedure (UE side). ............. 77

Figure 52: Message sequence chart for Slot availability indication procedure. ................................... 78

Figure 53: Message sequence chart for slot length modification (over-the-air). ................................. 78

Figure 54: Message sequence chart for channel scanning/hoping sequence alteration (Small Cell side). ...................................................................................................................................................... 79

Figure 55: Message sequence chart for slot length modification (Responder side). ........................... 79

Figure 56: FBMC MAC frame structure ................................................................................................. 81

Figure 57: Frame based equipment (FBE) access mode ....................................................................... 81

Figure 58: Load based equipment (LBE) access mode (N=3) ................................................................ 83

Figure 59: Multiple access scheme in FBMC broadband MAC .............................................................. 85

Figure 60: FBMC air interface initiation procedure .............................................................................. 99

Figure 61: Channel selection procedure ............................................................................................. 100

Figure 62: Channel reconfiguration procedure on the small cell side ................................................ 101

Figure 63: Channel reconfiguration procedure on the UE side .......................................................... 101



Figure 64: FBMC procedure for beacon discovery (step #1 of Figure 122) ........................................ 102

Figure 65: FBMC procedure for device association request (step #2 of Figure 122) .......................... 102

Figure 66: FBMC procedure for device association response by small cell (step #3 of Figure 122) ... 103

Figure 67: FBMC procedure for device de-association ....................................................................... 103

Figure 68: Paging procedure ............................................................................................................... 104

Figure 69: UE-initiated service request (Random Access step) .......................................................... 105

Figure 70: UE-initiated service request (Service establishment step) ................................................ 106

Figure 71: Procedure of UE sending control data in CAP .................................................................... 107

Figure 72: Procedure of UE sending control data in CFP .................................................................... 108

Figure 73: Procedure for retrieving control data at UE side ............................................................... 108

Figure 74: Procedure of Small cell sending control data in beacon .................................................... 109

Figure 75: Procedure for retrieving control data at small cell side ..................................................... 109

Figure 76: Small cell data transmission procedure ............................................................................. 111

Figure 77: Uplink data transmission .................................................................................................... 112

Figure 78: Uplink packet reception and acknowledgment ................................................................. 113

Figure 79: Reconfiguration procedure ................................................................................................ 114

Figure 80 - Distributions of coupling gain. .......................................................................................... 120

Figure 81 - Distributions of downlink and uplink SINR for 100% DL traffic, 100% UL and (50 % UL, 50% DL). ...................................................................................................................................................... 121

Figure 82: 3-ring hexagonal grid model .............................................................................................. 123

Figure 83: Wrap-around in a 2-ring hexagonal grid, showing the impact on cell n°13 by one of the 7 instances of cell n°7. ............................................................................................................................ 123

Figure 84: Simplified DCF procedure for Wifi APs ............................................................................... 126

Figure 85: CDFs of normalized UE throughput (left) and UE delay (right) for different MALs, ISDs and full buffer 100%DL traffic .................................................................................................................... 131

Figure 86: CDFs of normalized UE throughput (left) and UE delay (right) for different MALs, ISDs and FTP traffic model for 100%DL traffic with mean reading time 2sec ................................................... 132

Figure 87: CDFs of normalized UE throughput (left) and UE delay (right) for different MALs, ISDs and FTP traffic model for 100%DL traffic with mean reading time 5sec ................................................... 132

Figure 88: CDFs of normalized UE throughput (left) and UE delay (right) for different MALs, ISDs and full buffer 80%DL 20% UL traffic (DL part) .......................................................................................... 134

Figure 89: CDFs of normalized UE throughput (left) and UE delay (right) for different MALs, ISDs and full buffer 80%DL 20% UL traffic (UL part) .......................................................................................... 134

Figure 90: CDFs of normalized UE throughput (left) and UE delay (right) for different number of TRXs, ISDs and full buffer 100%DL traffic ..................................................................................................... 136

Figure 91: CDFs of normalized UE throughput (left) and UE delay (right) for different MALs, ISDs and full buffer 80%DL 20% UL traffic (DL part) .......................................................................................... 137

Figure 92: CDFs of normalized UE throughput (left) and UE delay (right) for different MALs, ISDs and full buffer 80%DL 20% UL traffic (UL part) .......................................................................................... 137

Figure 93: Control overhead vs Maximum Allowed Load for different number of TRXs per UE (1TRX per UE – left, 2TRXs per UE – right) and number of UEs per SC for full buffer traffic model ............. 139



Figure 94: CDFs of normalized UE throughput (left) and UE delay (right) for different ML values, ISDs and full buffer 100%DL traffic in coexistence scenario ....................................................................... 140

Figure 95: CDFs of channel occupancy for LBT-based “Wifi-like” system for different MALs, ISDs and Full buffer 100%DL traffic.................................................................................................................... 140

Figure 96: CDFs of normalized UE throughput (left) and UE delay (right) for different levels of maximum allowed interference, ISDs and full buffer 100%DL traffic for coexistence scenario ......... 142

Figure 97: CDFs of channel occupancy for LBT-based “Wifi-like” system for different levels of maximum allowed interference, ISDs and full buffer 100%DL traffic ................................................. 142

Figure 98: Power spectral Density of OFDM, and FBMC with several values of 𝐾 ............................. 146

Figure 99: Out-of-band emission mask in case of OFDM and FBMC with K= 2 .................................. 147

Figure 100: CDFs of DL normalized UE throughput using different ED thresholds and ISDs for FBE and LBE, full buffer 100%DL, No fading ..................................................................................................... 149

Figure 101: Per-Cell spectral efficiency vs. ED thresholds and ISDs for FBE and LBE, full buffer 100%DL, No fading [baseline]. ........................................................................................................................... 149

Figure 102: CDFs of DL normalized UE throughput using different ISDs (FBE, LBE), CCA-ED = -62 dBm, full buffer 100%DL, No fading, Frequency reuse 1 and 3 .................................................................... 151

Figure 103: CDFs of DL normalized UE throughput different ISDs for FBE and LBE, CCA-ED = -62 dBm, full buffer 100%DL, uncorrelated TU channel, Frequency reuse 1 and 3 ........................................... 152

Figure 104: CDFs of DL normalized UE throughput using different ISDs and different PHYs (FBMC K = {4, 2}, OFDM) for LBE, CCA-ED = -62 dBm, full buffer 100% DL, uncorrelated TU channel, Frequency reuse 1 and 3 ....................................................................................................................................... 153

Figure 105: CDFs of normalized DL/UL UE throughput using different ISDs of FBE and LBE, CCA-ED = -62 dBm, full buffer 80 % DL/20% UL, No fading, Frequency reuse 1 and 3 ........................................ 154

Figure 106: CDFs of DL normalized UE throughput of LBE and FBE using different ED thresholds and ISDs, FTP traffic D = 5 sec, No fading [baseline] .................................................................................. 156

Figure 107: Per-cell spectral efficiency vs. ED thresholds and ISDs for FBE and LBE, FTP traffic D = 5 sec, No fading [baseline]. Legends on curve correspond to fairness channel access. ........................ 156

Figure 108: CDFs of DL normalized UE Throughput using different ISDs for FBE and LBE, CCA-ED = -62 dBm, FTP traffic D = 2 and 5 sec, No fading ........................................................................................ 157

Figure 109: Control overhead vs ISDs of using different traffic models ............................................. 158

Figure 110: CDFs of DL normalized UE Throughput using different ISDs and ED thresholds with LBE FBMC-MAC in coexistence scenario, same density of WiFi APs, full buffer and FTP traffic D = 5 sec, No fading ................................................................................................................................................... 159

Figure 111: Per-cell spectral efficiency and mean channel occupancy of LBE FBMAC-MAC vs. APs/SCs density ratio using several ED thresholds and ISDs on coexistence scenario (FBMC-MAC +Wifi), full buffer, No fading ................................................................................................................................. 161

Figure 112: Mean channel occupancy of both operators (A, B) using several ED thresholds and ISDs on coexistence scenario (FBMC-MAC with LBE + Wifi), full buffer, No fading ................................... 162

Figure 113: CDFs of normalized UE throughput for FBMC-MAC (assuming ED threshold of -62dBm) and DCS-MAC (assuming ML of 0.4) for different ISDs and full buffer traffic model with 100%DL traffic ............................................................................................................................................................. 164

Figure 114: CDFs of normalized UE throughput for FBMC-MAC (assuming ED threshold of -62dBm) and DCS-MAC (assuming ML of 0.4) for different ISDs and FTP traffic model with 100%DL traffic and mean inter-arrival time of 2 sec. ......................................................................................................... 165



Figure 115: CDFs of normalized UE throughput for FBMC-MAC (assuming ED threshold of -62dBm) and DCS-MAC (assuming ML of 0.4) for different ISDs and Full-buffer traffic model with 80%DL traffic and 20% UL traffic ............................................................................................................................... 166

Figure 116: CDFs of normalized UE throughput (left) and channel occupancy of the coexisting system (right) in coexistence scenario for FBMC-MAC (assuming ED threshold of -82dBm) and DCS-MAC (assuming ML=0.2 for ISD=30m and ML=0.4 for ISD=100m) for Full-buffer traffic model ................. 168

Figure 117: CDFs of normalized UE throughput for FBMC-MAC (assuming ED threshold of -62dBm), DCS-MAC (assuming ML of 0.4) and WiFi (IEEE 802.11ac) for different ISDs and Full-buffer traffic model with 100%DL traffic .................................................................................................................. 169

Figure 118 – FBMC-MAC BLER mapping procedure. ........................................................................... 213

Figure 119 - BLER vs. SNR curves in AWGN channel for FBMC (K=4) PHY in 20 MHz. ........................ 214

Figure 120: DCS MAC BLER mapping procedure. ................................................................................ 214

Figure 121: BLER vs. SNR curves in AWGN channel for the underlying PHY of DCS MAC .................. 215

Figure 122: Generic procedure for UE initial attachment and RRC connection establishment.......... 217

Figure 123: RRC connection establishment failure ............................................................................. 218

Figure 124: Network detachment procedure ..................................................................................... 220

Figure 125: Location update procedure .............................................................................................. 221

Figure 126: UE initiated E-RAB establishment procedure .................................................................. 223

Figure 127: Network initiated E-RAB establishment procedure 2 ...................................................... 224

Figure 128: E-RAB release procedure.................................................................................................. 225

Figure 129: RLC configuration initiated by RRC................................................................................... 225

Figure 130: PDCP configuration initiated by RRC ................................................................................ 225



Abbreviations

ACK Acknowledgement

AI Air interface

CAP Contention Access Period

CC Connection Control

CCA Clear Channel Assessment

CDF Cumulative Distribution Function

CI Coexistence Information

CFP Contention Free Period

COT Channel Occupancy Time

CQI Channel Quality Indicator

CRC Cyclic Redundancy Check

cRRM centralised Radio Resource Management

CSMA/CA Carrier-Sense Multiple Access/Collision Avoidance

CTRL Control

CTS Clear To Send

DCS Dynamic Channel Selection

eCCA Extended Clear Channel Assessment

ED Energy Detection

eDSA Extended Dynamic Spectrum Access

EMM EPS Mobility Management

EPS Evolved Packet System

FBE Frame-Based Equipment

FBMC Filter-Bank Multiple Carrier

FS-FBMC Frequency Spreading-FBMC

FTP File Transfer Protocol

HMAC Higher MAC

IMSI International Mobile Subscriber Identity

IP Internet Protocol

ISD Inter-site Distance

LAA Licensed-Assisted Access

LBE Load-Based Equipment

LBT Listen Before Talk

LMAC Lower MAC

LTE Long-Term Evolution



LWA LTE-WiFi Aggregation

MA Multiple Access

MAC Medium Access Control

MAS Medium Access Slots

MCS Modulation and Coding Scheme

MCS Message Sequence Chart

MME Mobility Management Entity

MPDU MAC Packet Data Unit

MSDU MAC Service Data Unit

NACK Negative ACK

NOMA Non-Orthogonal Multiple Access

OTA Over-the-Air

OFDM Orthogonal Frequency-Division Multiplexing

OFDMA Orthogonal frequency-division multiple Access

OQAM Offset Quadrature Amplitude Modulation

PAPR Peak-to-Average Power Ratio

PCC Physical Channel Control

PDCP Packet-Data Convergence Protocol

PSD Power Spectral Density

PHY Physical Layer

QoS Quality of Service

RACH Random Access Channel

RAN Radio Access Network

RAT Radio Access Technology

RBC Radio Bearer Control

RLC Radio Link Control

RRC Radio Resource Control

RTS Request To Send

SAP Service Access Point

SC Small Cell

SI System Information

TAU Tracking Area Update

TB Transport Block

TCP Transmission Control Protocol

TDD Time Division Duplexing

TDMA Time Division Multiple Access



TMSI Temporary Mobile Subscriber Identity

TTI Transmission Time Interval

TU Typical Urban

UE User Equipment

WSNet Wireless Sensor Network Simulator



1 Introduction

In deliverable D5.1 [1], a multi-Radio Access Technology (RAT) MAC framework capable of performing extended Dynamic Spectrum Access (eDSA) has been introduced and designed. The MAC layer proposed within the SPEED-5G eDSA protocol architecture, is designed to support aggregation and/or split point of the different RATs at the MAC layer, largely due to inter-RAT coordination gains as opposed to the recently standardized LTE-Wifi Aggregation (LWA). The SPEED-5G eDSA MAC framework is characterised by a split of the MAC layer into 2 sub-layers: the lower MAC (LMAC), which is composed of air interface-dependent functions such as scheduling and the communication with the PHY layer to transmit /receive data to/from the physical layer (PHY) and the higher MAC (HMAC) which is composed of coordination functions to manage coexistence, sensing and measurement collection and inter-RAT scheduling. In addition, the SPEED-5G eDSA MAC framework defines a monitoring plane which allows MAC to collect PHY and MAC KPIs and forward them to the RRM entity so that it can adapt the configuration of the whole protocol stack. The framework is also characterised by its ability to provide backward compatibility with existing RATs like LTE or Wifi, as well as being able to host future 5G air interface variants (5G-AIV) which are still to be defined in 3GPP. In lieu of that, two novel 5G MAC protocol candidates were designed and described in D5.1 [1]: Dynamic Channel Selection (DCS)-based MAC and Filter-Bank Multi-carrier (FBMC) –based MAC. These SPEED-5G MAC protocols, together with the eDSA MAC framework addresses the key objective of SPEED-5G, which is to provide built-in capability of aggregating resources among a variety of non-contiguous spectrum under various licence regimes as well as support for traffic offload. It also tackles some of the well-known challenges in legacy systems, which includes lack of dynamic control of radio resources (in licensed, unlicensed and lightly-licensed spectrum) that has led to unbalanced spectrum load and capacity bottleneck. The design presented in D5.1 was supported with some initial simulation results.

In this document, the eDSA MAC protocol specification is described. This specification contains detailed description of procedures related to the Inter-RAT coordination capability of HMAC, traffic steering, contextual PHY and MAC measurements management, etc. These procedures are described using Message Sequence Charts (MSCs), which detail the interaction of not only the functional elements within DCS-based and FBMC -based MAC protocols, but also how these protocols interact with 5G-RRC, 5G-RLC and most importantly the cRRM in SPEED-5G’s system architecture. They are the essential enablers of the eDSA concept developed in SPEED-5G.

The eDSA MAC framework designed in D5.1 is enhanced in this deliverable. For instance, the framework shown in D5.1 didn’t fully allow for inter-RAT coordination at HMAC level, as HMAC had no means of knowing of the buffer statuses or QoS of the active logical channels, directly from 5G-RLC. This has been remedied with a slight change in the interfaces in the eDSA protocol architecture. Chapter 2 describes these subtle enhancements. This chapter also lists generic procedures such as attach/detach, paging or radio bearer management; it also details a full specification of the DCS-based and FBMC-based MAC protocols, identifying the frame types and format, information elements (IEs) and MAC-specific procedures Furthermore, this chapter lists the primitives identified for all the procedures which are further detailed in Appendix C.

This deliverable also presents the evaluation of the two MAC designs. This essentially consists of analysis of simulation results obtained from simulating DCS and FBMC MAC designs. Common simulation methodology, assumptions and calibrations have been assumed in order to ensure system level simulation tools are able to produce comparable results. In essence, the MAC evaluation relies on the definition of common simulation parameters on which DCS and FBMC MAC designs are simulated, defining network layout, UE densities, traffic patterns and channel models. Among the objectives of the simulations, the evaluation of the impact of the FBMC PHY is at stake. This is done in particular for the FBMC-based MAC by exploring and modelling different flavours of FBMC PHY configurations in order to derive the best PHY configuration from the simulations. These have all been detailed in chapter 3.



This deliverable is therefore structured as follows. Chapter 2 describes SPEED-5G MAC specifications, starting with the MAC framework and describing the generic signalling procedures involving the MAC and higher layers in the protocol stack. Chapter 2 includes the full specification of DCS MAC (section 2.3) and FBMC MAC (section 2.4). Chapter 3 describes the simulation assumptions and calibration process; this chapter also details the evaluation results of the 2 MAC designs, using common simulation assumptions. Chapter 4 provides a comparative analysis of the simulation results via a benchmark of the proposed MAC designs with existing systems such as IEEE 802.11ac. Direct comparison of DCS and FBMC MAC is also done, in order to derive some MAC selection guidelines, considering the context of operation (network layout, traffic models, SC density or frequency band). Chapter 5 concludes the deliverable.



2 eDSA MAC Specification

2.1 Speed-5G MAC overview

The initial eDSA MAC framework has been presented in deliverable D5.1 [1]. The eDSA MAC supports aggregation and splitting of Radio Access Technologies (RATs) at the MAC layer. One key advantage of having aggregation and/or split point at the MAC layer is that, it leads to better gains with respect to radio resources utilization and RATs coordination, leveraging the capability of the MAC, to exercise control over the real-time medium access and utilization of the radio resources. The framework is capable of supporting Legacy LTE-A, Wifi and novel 5G air interfaces (AI), in a single communication system.

The eDSA MAC layer is composed of two sub-layers: Higher-MAC (HMAC) and Lower-MAC (LMAC). The LMAC is the fine-grained part of the eDSA MAC layer as it is composed of different RAT-specific MAC protocols, with potential to operate concurrently. LMAC is the part of MAC where very short term decisions are taken and executed and its main functionality pertains to the scheduling of resource and data transmission; as an example in LTE, LMAC’s time constraints are of the order of the TTI duration. In the other hand, HMAC coordinates the operation of the different instances of the RAT-specific MAC protocols at the LMAC level and takes decisions which can be one order of magnitude slower than LMAC. The interested reader can refer to [1] for the detailed design description of the functionalities of these sub-layers.

The main innovations of the eDSA MAC framework are:

- Seamless traffic (control and user data) steering from one RAT to the other.

- Inter-RAT coordination at the MAC level, which differs from the LWA approach.

- Aggregation of heterogeneous radio resources for high-speed data transmission.

To leverage the diversity of many instances of air interfaces at the LMAC, the HMAC has to monitor the traffic load and the interference level of these air interfaces at the LMAC. Such information then allows the HMAC to steer traffic seamlessly from one air interface to the other. For example, some Radio the Resource Control (RRC) over-the-air (OTA) messages could be steered from LTE-A to a 5G air interface, if the interference level experienced by the former is high. In addition, user traffic can be aggregated at the MAC layer, utilizing the available radio resources from the different air interfaces at the LMAC. This is referred to as the Inter-RAT Coordination.

In [1], Inter-RAT Coordination is limited by HMAC’s lack of information of the buffer statuses and QoS of the different logical channels from 5G-RLC layer, due to the fact that there was no SAP or interface between the HMAC and 5G-RLC. Indeed, the buffer statuses and QoS of the different active logical channels could also be retrieved from the LMAC, but at the cost of excessive internal signalling overhead between HMAC and LMAC. To overcome this, this current deliverable proposes to deprecate C_5GRLC_LMAC_SAP, and instead introduces a new interface between 5G-RLC and HMAC. This is shown in the updated eDSA MAC Framework in Figure 1.

The new SAP is C_5GRLC_HMAC_SAP and with this new SAP, HMAC can:

- determine the QoS of the user traffic and the buffer statuses of the corresponding active logical channels

- inform cRRM of the need for new bearers on the 5G RAT, with cRRM being the entity that handles the decision through Radio Bearer Control (RBC) Function, then

- instructs 5G-RRC to configure the necessary radio bearers, logical channels and transport channels,

- inform the UE of the new configuration, and

- once the UE acknowledges (having applied) the new configuration, HMAC finally steers traffic



on the newly configured bearers mapped to the LMAC 5G_AIV entity.

In addition, if a set of logical channels is to be suspended due to handover from one radio frequency to another or due to recovery from a Radio Link Failure (RLF), through this new interface C_5GRLC_HMAC_SAP, the HMAC can pre-empt the 5G-RLC to not discard the current buffered traffic and, once the handover or the recovery from RLF succeeds, HMAC then requests 5G-RLC to retransmit the buffer data traffic to LMAC.

In SPEED-5G two 5G MAC designs have been proposed [1]: Dynamic Channel Selection (DCS)-based and Filter-Bank Multicarrier (FBMC)-based MAC protocols, which fit in the LMAC in the eDSA MAC framework. Sections 2.3 and 2.4 will focus on their respective MAC procedures and how they interact with the rest of the layers in the protocol layer architecture.

cRR

M

5G_RLC

Higher_MAC

Lower_MAC

Inter-Rat Coexistence coordination and management

Duty-cycle Adaptation

Listen - before – Talk (LBT)

Channel config

Frame Format

Sensing

Configuration

UE Configuration

CELLConfiguration

MAC Configuration

sensing & measurements management

Measurement Reports

Lower-MAC 5G_AIV

Inter-RAT Coordination

Buffers

Unlicensed

Buffers

Licensed

PHYLayer

5G_PDCP

C_5GRRC_5GPDCP SAP

C_c

RR

M-5

GR

RC

SA

P

Lower-MAC LTE-A

KPI collection Carrier Configuration

Logical Channel ManagerCoexistance Scheduler

RACH

DRX

Component-Carrier (n) LICENSED/UNLICENSED

HARQ Ctrl.

QoS

Time/Freq. - domain

Component-Carrier (1) LICENSED

HARQ Ctrl.

QoS

Time/Freq. - domain

(De) Multiplex

(Dis) Assembley

TX/RX LTE-A

Scheduling coordination

KPI Collection

Carrier Configuration

Logical Channel Manager

Coexistance Scheduler

CP-DRX

Carrier (1) LICENSED/UNLICENSED/

LIGHTLY-LICENSED

HARQ RACH

QoS Frame

MA Ctrl.

Time/Freq. – domain


Carrier (n) LICENSED/UNLICENSED/

LIGHTLY-LICENSED

HARQ RACH

QoS Frame

MA Ctrl.

Time/Freq. – domain

Lower-MAC WiFi

KPI Collection Channel Configuration

Preamble ManagementCoexistance Scheduler

CP-DRX

Carrier (1) UNLICENSED

Carrier (n) UNLICENSED


ARQ QoS

Time/Freq. - domain

ARQ QoS

Time/Freq. - domain

5GRRC-PDCP ctrl

5GRRC-RLC ctrl.

5GRRC-HMAC ctrl.

D_LMAC_PHY SAP

(De) Multiplex

(Dis) Assembley

TX/RX 5G_AIv

M_LMAC_HMAC SAP

5G-O&M

M_PHY_HMAC SAP

5G_MAC

5G-CELL

5GRRC-PHY ctrl.

(De) Multiplex

(Dis) Assembley

TX/RX WIFI

RLC-Adaptation

C_5G-X2AP

C_5GOAM-cRRM

C_SM-cRRM SAP

C_H

MA

C_L

MA

C S

AP

D_5GRLC_LMAC SAP

Sensing ResultsConfig.

Buffers

Lightly-Licensed

C_LMAC_PHY SAP

Sensing SensingSensing

5G_RRC

5GPDCP_5GRLC SAP

Spectrum Manager

M_cRRM_Config SAP

M_H

MA

C_c

RR

M S

AP

Contention coordinationMA Coordination

C_5GRLC_HMAC SAP

Inter-RAT scheduling coordination

Heterogeneous Resource

AggregationLoad Balancing

Control Traffic Coordination

Figure 1: Enhanced SPEED-5G eDSA MAC Framework Architecture and functional blocks



2.2 eDSA MAC-related Signalling Procedures

2.2.1 Introduction

This section describes the new eDSA MAC signalling procedures used by both the DCS and FBMC-based MAC protocols. These are:

- Measurement configuration and reporting,

- MAC configuration by RRM,

- Traffic steering triggered by RRM,

- Scheduling transmission on a specific LMAC entity

The eDSA variants of legacy procedures such as call setup, attach, RAB establishment, etc. have also been developed and detailed in Appendix C. Despite adoption of similar (to those used in legacy LTE systems) naming convention for these procedures, these procedures have been developed to ensure backward compatibility e.g. to legacy LTE, if LTE LMAC is instantiated. In the cases where LMAC is composed of DCS and/or FBMC MAC designs, these procedures include new MAC-specific OTA message exchanges, as embedded sub-procedures. The procedures specific to DCS and FBMC MAC are further developed in sections 2.3.4 and 2.4.5 respectively.

2.2.2 Measurements configuration and reporting procedures

The procedures described in this sub-section relate to the management and reporting of measurements in the SPEED-5G system. As depicted in the next subsections, SPEED-5G proposes a new set of mechanisms for handling measurements. The new mechanisms aim at complementing the existing legacy RRC measurements used for handovers and are handled by the SPEED-5G so called monitoring plane, which complements the usual data and control planes.

2.2.2.1 RRM-triggered measurements

The following section describes procedures which are necessary for management and collection of measurement by the cRRM entity located in the operator’s infrastructure network. The first MSC presents the procedure for measurement configuration at the HMAC, whilst the second MSC describes procedures for the measurement collection. The first procedure, shown in Figure 2, aims at configuring the KPI collector located in the HMAC entity. The procedure configures what information should be collected by the KPI collector and defines how they have to be collected by the cRRM entity. It is worth noting that this procedure may trigger HMAC to initiate another measurement configuration procedure in order to collect data from lower layers, as requested by the cRRM. As shown in the second MSC (see Figure 3) two different options for measurement collection are possible. The first option (on-demand) sees cRRM explicitly requesting for a specific measurement information stored in the HMAC’s KPI collector. The second option (periodic/event-driven) assumes that HMAC is responsible for reporting the collected measurement information, to the cRRM. This can happen either periodically, or if a predefined condition is met (usually configured via measurement configuration procedure).



Figure 2: Procedure for measurement configuration of HMAC by cRRM

Figure 3: Procedure for measurement collection by cRRM

2.2.2.2 HMAC-triggered measurements

This subsection describes the necessary procedures for management and collection of measurement by the HMAC entity. The MSC in Figure 4 presents the procedure for the measurement configuration at the LMAC, whilst the second MSC describes procedures for the measurement collection. This procedure aims at configuring the KPI collector located in the LMAC entity and can be triggered as a result of cRRM measurement configuration procedure. Similar to the cRRM measurement configuration procedure described in the previous section, the HMAC measurement configuration procedure configures what information should be collected by the KPI collector located in LMAC and defines how they should be collected by the HMAC entity. As shown in the MSC of Figure 5, three different options for measurement collection are possible. In the first option, the HMAC explicitly requests for a specific measurement data collected by the KPI collector located in the LMAC. In the second option, the LMAC is responsible for reporting to HMAC the collected measurement data. This can happen either periodically, or if a certain condition is met (the condition is set during the



measurement configuration procedure). In the third option, the HMAC explicitly requests for a specific measurement to be conducted by the PHY. In contrast to the other options, direct access to PHY allows HMAC to initiate non-legacy measurements, leading to significantly higher flexibility. Additionally, it does not require measurements to be setup beforehand.

Figure 4: Procedure for measurement configuration of LMAC by HMAC

Figure 5: Procedure for measurement collection by HMAC



2.2.3 MAC configuration procedures

2.2.3.1 MAC configuration initiated by the cRRM entity

This procedure relates to the configuration of the MAC layer by the cRRM entity, which is responsible for configuring the MAC and PHY layers with a set of parameters in compliance with decisions taken at the cRRM level. The configuration primitives are received/sent by HMAC through the 5GRRC_HMAC CTRL interface (which also carries RRC configuration messages). These parameters may relate to channel selection and configuration, coexistence management in shared spectrum, RAT activation or selection, etc. Figure 6 shows this procedure, starting with configuration request sent by cRRM to HMAC layer; the latter may forward the LMAC and PHY-specific configuration towards LMAC and PHY layers. The procedure is completed by a message sent by HMAC to cRRM, notifying the success or failure of the operation.

Figure 6: Generic procedure for MAC configuration by RRM entity

2.2.3.2 Lower MAC configuration initiated by Higher MAC

This procedure shows how the HMAC reconfigures the LMAC, for instance upon request from cRRM (see previous section) or from RRC, may for instance trigger the configuration of a particular air interface (see next section). This is done through a request/confirm primitive exchange, as depicted in Figure 7. Optionally, this reconfiguration can trigger the PHY reconfiguration by the LMAC, using the same mechanism.

Figure 7: LMAC reconfiguration procedure

This procedure is generic as it can be applied to any of the MAC designs by means of specific information elements conveyed in these messages, as shown in section A.1.15.



2.2.4 Traffic steering triggered by RRM procedure

Traffic steering is another key aspect of the SPEED-5G eDSA context as it consists of both traffic offloading and aggregation using different LMAC entities to carry logical channels. With traffic offloading, user traffic and control messages can be re-routed from one air interface to the other, depending on the radio resources utilization (spectrum utilization), load and the interference level on the air interface from which traffic is being offloaded. In the case of the traffic aggregation, user traffic can be aggregated over radio resources from a multitude of spectrum or air interfaces. According to the work reported in D3.1 [2] and D3.2 [3], traffic steering decision can be taken by cRRM for the sake of either capacity boosting, having the secondary carrier acting as a supplemental carrier like the LTE’s Licensed-Assisted Access (LAA) or LWA, or for interference mitigation. In the latter case, this induces the release of resources on AI#1 to allocate resource on AI#2 to convey the considered logical channel. The whole procedure of traffic steering is captured in Figure 8 to Figure 11.

Typically, the cRRM decision indicates among others i) the logical channel that has to be steered, and ii) the selected AI#2 together with the secondary carrier configuration (band and/or channel bandwidth).

Figure 8 and Figure 9 describe the configuration phase of the traffic steering, for both the SC and the UE. On the SC side, the decision received from the cRRM entity can trigger different set of actions (alternatives), depending on the actual SC and device configuration related to the activation of AI#2 on both sides.

The first alternative is the possible non-activation of AI#2 at the UE side. This requires RRC reconfiguration process, sparked by a message of the SC’s HMAC to the RRC (Step n°3) indicating that the AI#2 has to be switched on at the UE side. The RRCReconfigurationRequest (step 4) is a RRC peer-to-peer message to the UE RRC entity; it is used to modify the bearer, indicating that AI#2 is among the air interfaces on which the logical channel can be conveyed. This request is sent to the UE via AI#1 which completes the RRC reconfiguration procedure via a RRCReconfigurationComplete message to the SC RRC, and triggers the device attachment on AI#2 (“MAC specific step 3 in Figure 8).

However, prior this RRC reconfiguration, having the SC AI#2 operating in a configuration which fits with the steering decision received from RRM is required. Here again, 2 options are possible: either AI#2 is not activated at the SC or it is activated but having a configuration which is not in accordance with the RRM guidelines (for instance the active channel bandwidth of AI#2 is too small). In the first case, the HMAC provokes the start of AI#2, which is a MAC-specific action, including a channel identification procedure. This is captured in Figure 8 by the box referred as to “MAC-specific step #1”. In the other case a MAC-specific channel reconfiguration is required on the AI#2, which is referred as to “MAC-specific step #2”. In both cases, the HMAC sends back to cRRM a notification, via the monitoring plane about the selected channel (ChannelIdentification.indicate message). When the UE is associated in AI#2, HMAC sends to RRC a notification of this status, as it is done in LWA case for LTE [6].

The second alternative happens when AI#2 is already active on the UE. In this case, the only possible remaining step is the channel reconfiguration and the RRC and cRRM notifications on the device association on AI#2 and the occupied channel for AI#2.



Figure 8: Generic procedure for traffic steering configuration, SC Side



Figure 9 shows the configuration steps at the UE side induced by the configurations from the SC. It mainly pertains to the RRC reconfiguration request sent by the SC (see Figure 8). This includes a set of MAC to RRM communication for RRC reconfiguration request and indication which triggers the emission of a message from the UE RRC to HMAC to activate of AI#2 (message 3a) and then initiates the initial attachment procedure on AI#2, which is a MAC specific procedure. Given that the SC has sent a RRC connection request to the UE after having perform the AI#2 activation and/or channel (re)selection, the SC can include in the UE RRC reconfiguration request the parameters of the AI#2 channel, so that the initial attachment procedure can be speeded up. In parallel, a notification of the completeness of RRC reconfiguration is sent back to the SC, using AI#1.

Figure 9: Generic procedure for traffic steering configuration at UE side, to switch AI#2 on

Figure 10 and Figure 11 show the complete offload procedures, including the configuration procedure reported earlier in this section, for the capacity boosting and interference management cases, respectively.

For capacity boosting, once the configuration is performed, the HMAC sends to the LMAC of AI#2 a scheduler configuration request message, containing the QoS requirements of the considered logical channel. Once this is done, the MAC specific data transmission procedure can start. For interference management case (Figure 11), the only difference is in the fact that prior to AI#2 scheduler configuration, the logical channel configuration is removed from the AI#1 configuration.



Figure 10: Generic procedure of traffic aggregation for capacity boosting

Figure 11: Generic procedure of traffic offload for interference mitigation

2.2.5 Procedure for scheduling transmission on a specific Lower MAC

This generic procedure deals with the scheduling of a data frames at the LMAC level, which is triggered by HMAC (see Figure 12). This procedure is a direct consequence of the SPEED-5G MAC framework which is based on the Inter-RAT scheduling feature at HMAC level (see section 2.1). This requires that buffers status are known at HMAC, thanks to reports sent by the RLC through the C_5GRLC_HMAC SAP.

The procedure starts with a message from HMAC to LMAC (SchedTransmission.request) indicating that a frame is to be scheduled and be transmitted OTA. The message includes generic and mandatory parameters like the ID if the UE to be scheduled in the frame, as well as the ID of the logical channel (or group of logical channels) and the related buffers status reports. Upon receiving this message, LMAC will i) proceed to the actual scheduling of resources among the considered UE, ii) retrieve SDUs from RLC with a transport block size defined by LMAC and iii) proceed to the transmission of the MAC frame to the PHY layer.

When the LMAC scheduling is completed, LMAC sends back the SchedTransmision.confirm message to notify HMAC whether the scheduling has been successfully performed or not.



Figure 12: Generic procedure for frame scheduling

This procedure can be applied either at the SC or the UE sides but in the case of FBMC MAC (see section 2.4), this message is used for DL scheduling only. Indeed UL scheduling is done locally in LMAC since UE BSRs are known at the lower level after being retrieved in OTA control frames.

2.3 Dynamic Channel Selection (DCS) MAC specifications

2.3.1 DCS-MAC Overview

This section provides a brief overview of DCS-MAC and its main characteristics and features. DCS-MAC is a novel MAC protocol which has been designed in SPEED-5G to support high-capacity broadband wireless access in ultra-dense deployments. In deployment scenarios where traditional/rigorous RF planning and proper site selection are bypassed or even ignored, excessive inter-cell interference can be expected. In order to address this, dynamic channel selection and multi-channel operation has been developed as core features in DCS MAC design, with the aim of preventing QoS degradation resulting from high levels of interference. The build-in support for multi-channel operation enables also contiguous and non-contiguous channel/carrier aggregation which increases peak throughput and system capacity, as well as allowing for more flexible resource allocation. More comprehensive description of DCS-MAC can be found in deliverable D5.1 [1].

2.3.1.1 Frame design and multiple access

As presented in [1], default frame length in the DCS-Based MAC is 10ms and frames are subdivided into multiple slots as shown in Figure 13. Although not explicitly depicted in the figure, the slot lengths can vary, thus affecting the number of slots per frame. The slot lengths (and as a result, the number of slots per frame) may change depending on the bandwidth of frequency channels, the licensing regime of the spectrum band, traffic type and channel load.

In DCS-MAC, each slot in a frame is subdivided into a control data field (C-Field) and a user data field (U-Field). In order to limit the overhead related to the control part, the C-Field length can be dynamically changed depending on the amount of information which needs to be transferred. Additionally, slot lengths can be changed, thus reducing the overhead per slot (e.g. depending on the interference conditions).



Figure 13: Frame and slot structure

Several frames constitute a multi-frame (see Figure 14). The multi-frame length is related to the amount of common control information which needs to be broadcast by SCs and is set to the default value of 16.

Figure 14: Multi-frame structure

The multiple access mode of the proposed MAC is based on a combination of multi-channel operation, Time Division Multiple Access (TDMA) and Time Division Duplexing (TDD) and is able to fully exploit the potential of additional spectrum resources from different bands. The combination of a frequency channel and a time slot in DCS-MAC is termed a physical channel and it represents the smallest granularity of resource which can be allocated for transmission.

Figure 15: Multiple access and physical channel structure (Physical channel = time slot + frequency channel combination)

As indicated in [1], the duplexing scheme used by the proposed MAC separates uplink transmissions from downlink transmissions in the time domain. The separation between uplink and downlink traffic is pre-defined and is equal to the half of the length of the frame. It needs to be highlighted however that the direction of transmission for all slots can be renegotiated during the connection setup (and also for ongoing connections), thus allowing full flexibility in resource allocation.

2.3.1.2 Multi-Channel Operation

The proposed MAC is designed to natively support multi-channel (and band) operation, and thus



aims at full exploitation of all potentially available spectrum resources [1]. In order to enable operation in multiple channels (and bands), each SC periodically scans all supported channels according to some predefined scanning/hopping sequence. The information about the scanning/hopping sequence used by a SC can be obtained (by a UE) during synchronization stage and allows the UE to track scanned resources and initiate transmission using the right physical channel (i.e. time slot and frequency channel combination). In order to enable an SC initiated transmission, the UEs adopt a similar procedure and scan physical channels using a delayed version of the hopping/scanning sequence adopted by their serving SC. Different scanning/hopping sequences can be adopted SC. The simplest one assumes that a transceiver scans one frequency channel per MAC frame. More sophisticated scanning/hopping sequences which can help minimize contention between users from neighboring cells can also be used. The build-in support for multi-channel operation also allows DCS-MAC to provide native support for channel/carrier aggregation. The aggregation of additional channels in DCS-MAC is achieved by adding a new transceiver on SC or UE sides. The flexibility of aggregation is only limited by potential inability of some transceivers to operate in all supported bands. It is worth highlighting here that by increasing the number of transceivers in a SC we are also reducing the physical channel access time and improving accuracy of the physical channel quality map used for physical channel selection.

2.3.1.3 Resource Access

As mentioned in [1], DCS-MAC does not differentiate between resources dedicated for RACH and other channels. This design choice allows DCS-MAC based systems to alleviate the problem of interference and non-optimal allocation of resources for RACH. One of the main advantages of such approach is that all resources pre-allocated for uplink transmission (see Figure 15) can be potentially used for access. The access to all physical channels pre-allocated for uplink transmission is facilitated by the build-in multi-channel operation of the DCS-MAC based on periodical scanning of all supported channels. In order to lower contention between UEs camping on different SCs, different scanning/hopping sequences can be adopted by neighboring cells.

In case of an access failure, a typical exponential random backoff procedure is used to resolve any potential collisions and prevent degradation of system performance. The backoff time is randomly

selected from a contention window with an interval ],0[ CW . The value of CW is calculated using the

following expression )2,min( 1

minmax

NCWCWCW , where N is the number of failed access

attempts. The value of CWmin and CWmax is set to 10 frames (i.e. 100ms) and 320 frames (i.e. 3200ms), respectively, as default values. It needs to be highlighted here that physical channels in DCS-MAC are selected based on their quality. This provides additional source of randomness which further reduces the probability of collisions (physical channel quality map is affected by UE location and thus it may significantly differ from one UE to another).

2.3.1.4 Dynamic Channel Selection

In order to cope with different challenges associated with dense (and ultra-dense) deployments, the proposed MAC uses a dynamic decentralized procedure to select physical resources for transmission. This procedure is called Dynamic Channel Selection (DCS) and builds on top of multi-channel operation and time-slotted access of the proposed MAC protocol. In general, the main aim of the DCS is to enable inter-cell and inter-system interference avoidance (by exploiting interference diversity). Additionally, the DCS MAC design allows the system to adapt itself continuously to changing traffic conditions by allocating resources on an “as-needed” basis. As a result, DCS as a key feature of the proposed MAC design enables efficient operation in dense (or ultra-dense) deployment across different bands. The channel selection process in DCS-MAC is based on the physical channel quality map which is maintained and updated by SCs and UEs, through periodical scanning of all supported channels. It needs to be highlighted that in order to prevent the use of out-



dated physical channel measurements, the quality of selected physical channel is re-measured one frame before the actual transmission. If the new measurement indicates that the quality of the physical channel has significantly degraded, a new physical channel is then selected.

In order to prevent the potential problem of system instability resulting from continuous dynamic (re-) selection of physical channels (and at the same time having to maintain efficient resource utilization), different mechanisms can be used. DCs-MAC uses a mechanism based on timers and counters which prevent SCs and UEs from (re-)selecting new physical channels too often. The mechanism is based on the principle that the number of physical channel selections cannot exceed a certain number in a given time window. The maximum number of physical channel selections in a

time window depends on the number of required radio bearers (RBs) and is equal to 1NNN RBsel ,

where 101 N and RBN is a non-linear mapping from the number of required radio bearers (see

Table 1). It needs to be underlined here that in case of SCs, the maximum number of physical channel selections in a window depends on the number of needed RBs for all served UEs. The time window

length is set to sec21 T and is assumed to be the same for both the UE side and the SC side.

Number of required radio bearers

NRB

1 1

2 to 3 2

4 to 7 3

7 to 15 4

15 to 25 5

Above 25 6

Table 1: Mapping of number of required radio bearers to NRB

Physical channel selection in DCS-MAC can be triggered either when a new RB needs to be established or when an existing RB needs to be handed over due to poor channel quality (intra-cell and inter-cell handovers are considered in DCS-MAC).

As excessive number of handovers may cause instability, we use additional time window based

mechanism on top of selN to limit the number of handover attempts which cannot exceed 152 N

per RB in a time window sec32 T . Furthermore, the number of successful handovers per RB cannot

exceed 103 N in a time window sec33 T .

It is worth highlighting here that the values of parameters 1N , 1T , 2N , 2T , 3N , 3T and the RBN

mapping are constants and have been fine-tuned for the scenario when DCS-MAC operates in a dedicated band. Possible mechanisms for dynamic adaptation of these parameters in order to provide better performance in a fast changing environment is left for future study.

2.3.1.5 Physical layer Considerations

The following section provides details related to physical layer numerology used with DCS-MAC. Note however that the proposed design can be used with any PHY which meets certain minimum criteria.

The following table provides the OFDM-based numerology for the PHY, adapted for use by (and in evaluations of) DCS-MAC. The parameters were derived based on [18], assuming that DCS-MAC is designed specifically for SC deployment where the cell radius does not exceed 100m. First OFDM symbol in a slot is assumed to be always used for synchronization and channel estimation. The following tables present parameters for 2MHz and 20MHz channel bandwidths (other bandwidths



ranging from 2MHz to 20MHz, with a granularity of 2MHz, are also supported).

OFDM parameters

Target BW [MHz] 2

Subcarrier spacing [kHz] 60

Number of active subcarriers 30

Cyclic Prefix (CP) length [us] 1.041

Per TRX BW (MHz) 1.8

Gap Period (GP) length [us] 9.375

Number of OFDM symbol per DCS-MAC Slot 23

Gap Period (GP) length [us] for Double Slot 18.75

Number of OFDM symbol per Double Slot 46

Table 2: OFDM numerology of DCS-MAC PHY for 2MHz channel

OFDM parameters

Target BW [MHz] 20

Subcarrier spacing [kHz] 60

Number of active subcarriers 300

Cyclic Prefix (CP) length [us] 1.041

Per TRX BW (MHz) 18

Gap Period (GP) length [us] 9.375

Number of OFDM symbol per DCS-MAC Slot 23

Gap Period (GP) length [us] for Double Slot 18.75

Number of OFDM symbol per Double Slot 46

Table 3: OFDM numerology of DCS-MAC PHY for 20MHz channel

The following table provides a list of possible modulation and coding schemes supported by the considered PHY. The list was derived based on the LTE specifications, using the same channel coding methodology (Efficiency is a product of bits/symbol by the Ratio, and the Ratio refers to the coding rate).

CQI Index MCS name Bit Per symbol Ratio (/1024) Efficiency

1 QPSK 2 0,07617188 0,15234375

2 QPSK 2 0,1171875 0,234375

3 QPSK 2 0,18847656 0,37695313

4 QPSK 2 0,30078125 0,6015625

5 QPSK 2 0,43847656 0,87695313

6 QPSK 2 0,58789063 1,17578125

7 16-QAM 4 0,36914063 1,4765625



8 16-QAM 4 0,47851563 1,9140625

9 16-QAM 4 0,6015625 2,40625

10 64-QAM 6 0,45507813 2,73046875

11 64-QAM 6 0,55371094 3,32226563

12 64-QAM 6 0,65039063 3,90234375

13 64-QAM 6 0,75390625 4,5234375

14 64-QAM 6 0,85253906 5,11523438

15 64-QAM 6 0,92578125 5,5546875

Table 4: Modulation and coding schemes of DCS-MAC PHY

2.3.2 Frame formats

As mentioned earlier, each slot in the DCS-MAC frame is subdivided into a control data field (C-Field) and a user data field (U-Field). This section describes the format of these fields in more detail.

2.3.2.1 Control Data Field description

The C-Field is subdivided into primary and secondary allocation blocks (see Figure 16 and Figure 17). There is always one primary allocation block whilst the number of secondary allocation blocks varies depending on the channel bandwidth and the length of the C-Field. Control information which is necessary for establishing synchronization with a network is always transmitted over the primary allocation block. This approach borrows from the LTE design and enables operation using various channel bandwidths.

C-Field U-field

1 OFDM symbol

3 OFDM symbols 0-9 OFDM symbols 10-19 OFDM symbols

Reference signal and Chan. est.

Primary allocation block

Secondary allocation block

…

Figure 16: C-Field structure for 2 MHz bandwidth

C-Field U-field

1 OFDM symbol

3 OFDM symbols 0-9 OFDM symbols 10-19 OFDM symbols

Reference signal

… …

…



Primary allocation block




… …

Figure 17: C-Field structure for bandwidth larger than 2MHz



In the following we describe format and contents of the message which can be carried in the primary C-Field allocation block. As presented in Table 5 below, the message carried in the primary C-Field allocation block consists of three fields: Header, Message Payload and CRC.

Bits 8 40 16

Primary Control Allocation Block

Message

Primary Header Message Payload CRC

Table 5: C-Field format of the primary allocation block

The C-Field Header for primary allocation block carries information describing the contents of the primary allocation block and includes information about the type of payload carried, type of Radio Bearer used for transmission, Ack information for transmission in the opposite direction (in case of bi-directional RB) and the length of the C-Field. In case of transmission over a non-bi-directional RB (e.g. common RB, or asymmetric RB), the ACK field indicates if data is carried in the U-field.

Field type Field Size

Field Description

Message Type

3 bits Type of message carried (e.g. System information, System Identity, Paging)

Bi-directional

RB Indicator

1 bit Indicates if the given transmission is part of a

bi-directional Radio Bearer

ACK 2 bits

ACK of C-field and U-field in symmetric radio bearers only. When Bi-directional Indicator is set to 0, this field is used to indicate if data is

carried in the U-field

Length 2 bits Number of additional symbols allocated for C-

Field (see Note 1)

Note 1: For 2Mhz Bandwidth number of symbols allocated varies from 3 to 9 (for larger bandwidths this changes to 1-3)

Table 6: C-Field Header description for primary allocation block

In contrast to the message carried in the primary allocation block, the payload carried in the secondary allocation block may have a variable size and can span multiple secondary allocation blocks. The Table 7 presents format of the message which can be carried in the secondary allocation block(s).

Bits 4 Variable 4 Variable 16

Secondary Control

Allocation Block

Secondary-header-1

Message Payload-

1

Secondary-header-2

… CRC

Table 7: C-Field format for the secondary allocation block(s)



The secondary allocation block is used only if more than one message needs to be transmitted using the C-Field. As most information is conveyed in the C-Field Primary-Header, the C-Field Secondary-Header carries only information about the message type which follows the header. To give it more flexibility, the type field consists of 4 bits.

Field type Size Field Description

Length 2 bits Number of secondary allocation

blocks used

Type 4 bits Type of message (MIB, SIBs, Identity, Paging, Connection Control, Others)

Table 8: C-Field Header description for secondary allocation block

In the following subsections we describe messages which can be carried in the C-Field. In general, the messages can be subdivided into fixed sized messages which can be transmitted over the primary C-Field allocation block and messages of variable size which always need to be transmitted in the secondary C-Field allocation block(s).

2.3.2.1.1 System Identity Message

The system identity message conveys MAC level system identifier and a bit which indicates whether the message originates from a SC or a UE. The identity consists of a Cell Identifier which is created based on PLMN id and Tracking area code and a Cluster Member Identifier which identifies a cluster member within a specific SC cluster. The message is always transmitted in primary C-Field allocation block. The message needs to be transmitted at least every 80ms and it is transmitted if there is no other message to be transmitted in the primary C-Field allocation block.

System Identity message

Field type Field Size Field Description

BS_Indicator 1 Indicates if the message is transmitted by a BS or by a UE

Cell_Id 31 Cell identifier

ClusterMember_Id 8 Cluster member identifier

Total number of bits 40

Table 9: System Identity message format

2.3.2.1.2 Basic System Information Message

This message conveys the most important system information required to access the system and enables frame synchronization. The message is sent every 80ms (which corresponds to half of multi-frame length) on all active downlink radio bearers. In order to prevent overwriting Basic System Information (BSI) of a UE associated with a specific SC by a BSI transmission from a neighboring SC, CRC of BSI message is scrambled by a combination of ClusterMember_Id and the last 8 bits of Cell_Id.

System Information message

Field type Field size

Field Description

SlotNumber 4 Slot number during which transmission took place

CarrierNumber 5 Carrier number on which transmission took place

Bandwidth 3 Bandwidth used in this band (enumerate)



FirstHalfFrame 1 Indicator if transmission takes place in the first half of the frame

SupportedCarriers 13 Map of carriers supported in this band

ScanningSequenceId 5 Scanning sequence Id

NextCarrier 5 Carrier number on which primary transceiver is scanning in the

next slot (Note 1)

TRXNumber 4 Number of Transceivers supported by BS


Note 1: CarrierNumber and SupportedCarriers fields indicate if carrier is part of this band

Table 10: System Information message format

2.3.2.1.3 Coexistence Information message

This message conveys the most important (in-band) coexistence related information. The message is sent every 80ms (which corresponds to half of multi-frame length) on all active downlink radio bearers in Frame 1. In order to prevent overwriting coexistence related information of a UE associated with a specific SC by transmission from a neighboring SC, CRC of Coexistence Information (CI) message is scrambled by a combination of ClusterMember_Id and the last 8 bits of Cell_Id. Similarly to the BSI message, CI message allows user to acquire Frame synchronization.

Coexistence Information message

Field type Field size

Field Description

Other Carriers 16 Map of additional carriers accessible in this band

MaxAllowedTxPower 5 Maximum transmit power (in dBm) per frequency channel

PhyChanSelGranurality 4 Granularity of physical channel selection list (in dB)

MaxInterferenceAllowed

5 Maximum level of interference in a physical channel which

permits its allocation

MaxLoad 4 Maximum number of physical channels which can be allocated

per band

BsTxPower 5 BS transmission power

OtherBands 1 Indicator that a given SC operates on other bands


Table 11: In-band coexistence message format

2.3.2.1.4 Slot Availability Information message

This message conveys information about the availability of different physical channels for access. The message is sent on all active downlink radio bearers. In order to prevent overwriting of slot availability status of a UE associated with a specific SC by transmission from a neighboring SC, the CRC of Slot Availability Information message is scrambled by a combination of ClusterMember_Id and the last 8 bits of Cell_Id.

Blind Slot Information message

Field type Field size Field Description

TrxMap 4 Indicates carried map of slots is for TRX 1-3, 4-6, 6-9, 10-12

BlindSlotIndication 36 Map of not accessible slots


Table 12: Blind slot information message format



2.3.2.1.5 System Information Status message

This message conveys information about the status of different system information. The message is sent on all active downlink radio bearers. In order to prevent overwriting this information by transmission from a neighboring SC, the CRC of this message is scrambled by a combination of ClusterMember_Id and the last 8 bits of Cell_Id. This message needs to be explicitly requested by a UE if not received in a predefined period of time (depending on the scenario the period may vary from minutes to hours). The message can be carried in primary or secondary allocation block of the C-Filed.

System Information Status message


SI_ID1 4 SI Identifier

SystemInfoValueTag1 5 Indicates if a change has occurred in the SI message







SIS number 4 Reserved for future use (if more SI are defined)


Table 13: System information status message format

2.3.2.1.6 Paging Information message

This message conveys information about the identity of the paged user. The message is sent on all active downlink radio bearers. In order to prevent processing of this information by UEs camping on neighboring SCs, the CRC of this message is scrambled by a combination of ClusterMember_Id and the last 8 bits of Cell_Id. In order to improve chances of a successful pilot RB setup, a SC can recommend a physical channel to a UE by sending a Slot_ID and Carrier_ID information on which a UE can initiate access procedure. Similar to LTE, paging Information message can be also used to inform users about changes in the system information. This is achieved by transmitting a paging message with User_Id set to a reserved value. In this case Slot_Id and Carrier_Id are used to carry information about SIB_Ids which indicates type of the updated system information.

Paging Information message


Type 2 Type of Identity carried (enumerate: TMSI, IMSI)

User_Id 29 User identifier

Slot_ID 4 Slot Id recommended for access (alternatively this field can be used as a

system information identifier, if user id is set to a special value)

Carrier_ID 5 Carrier Id recommended for access (alternatively this field can be used as a

system information identifier, if user id is set to a special value)

Total number of

bits 40

Table 14: Paging message format



2.3.2.1.7 Network Information message

This message conveys network information. As Cell_Id is conveyed in the System Identity message is constructed based on PLMN_Id and TrackingAreaCode which is sufficient to uniquely identify a network in a given area, the message is only transmitted if explicitly requested by a UE. Message can be carried in primary or secondary allocation blocks of the C-Filed. The CRC of this message is scrambled by a combination of ClusterMember_Id and the last 8 bits of Cell_Id

Network Information message


PLMN_Id 20 PLMN identity

TrackingAreaCode 16 Tracking Area Code

Other 4 For future use


Table 15: Network information message format

2.3.2.1.8 System Information Request message

This message conveys a UE request for transmission of specific system information. The message can be sent during a RB setup or for an already setup bi-directional pilot RB. The message is carried solely in the secondary allocation block of the C-Filed.

System Information Request message


SI_Id1 4 SI Identifier

SI_IdN 4 SI Identifier

Total number of bits From 4 to 4 + N*4

Table 16: System information status message format

2.3.2.1.9 Connection Control message

This message is used for transmission of user specific information. It consists of three fields: 1) short user identifier which is created based on the last 21 bits of User Id, 2) short cell identifier which is created based on the 15 bits of Cell Id carried in System Identity message, 3) CC-Type which indicates message type. Four message types are considered in: RB Access-Request, RB Handover-Request, RB Confirm, RB Release. In case of RB Access-Request for bi-directional pilot RB, the message is usually sent in a combination with other user specific messages which enable initiation of multi-RB connection setup. RB Confirm is used solely for setting up of bi-directional RBs. In case of asymmetric RBs, Physical Channel Control message with a Command “Active” is used instead of RB Confirm (see Section 2.3.2.1.11). The message can be sent in primary as well as secondary allocation block.

Connection Control Message


S_UE_Id 21 Short User identifier

S_Cell_Id 16 Short Cell identifier

CC-Type 3 Indicates type of Connection Control Message

Total number of bits

40

Table 17: Connection Control message format



2.3.2.1.10 Slot Length Modification message

This message is used for transmission of user specific information. The message is used to set slot lengths for particular RBs. The message is most commonly used during the RB setup procedure, but it can be also used at the later stage. The message can be carried solely in the secondary allocation block. In case the reception of this message is acknowledged and no response is received, the request for slot length modification is accepted and slot lengths for all requested RBs are modified accordingly.

Slot Length Modification message


RequestIndicator 1 Request/Response indicator

RB Number 4 Number of Radio Bearers

RB-1 ID 4 Identifier of Radio Bearer

RB-1 SlotLength 2 Length of slot for RB 1

… … …

RB-N ID 4 Identifier of Radio Bearer

RB-N SlotLength 2 Length of slot for RB N


From 10 to 5+N*6

Table 18: Radio Bearer Attributes Control message format

2.3.2.1.11 Physical Channel Control message

This message is used for transmission of user specific information. The Physical Channel Control (PCC) message can be used to change scanning pattern of a SC or a UE to enable faster channel access. The commands can be also used to change direction of slot transmission (which make it necessary to establish asymmetric RB) and request status of a given physical channel. In particular, the message is used during the pilot RB setup procedure to initiate fast establishment of multi RB connection with the number of RB corresponding to the number of commands carried. The message is also used to confirm successful establishment of asymmetric RBs by the receiving side. By using “Poor” and “Good” commands, physical channels can be recommended for an RB establishment.

Physical Channel Control message


Number of command

4 Number of Physical Channel command carried

Type_1 3 Type of the first command (enumerate: Listen, Initiate, Active,

Quality, Good, Poor)

SlotId_1 4 Slot identifier for the first command

CarrierId_1 5 Carrier identifier for the first command

RBType_1 1 Type of Radio bearer for the first command

(symmetric/asymmetric)

… … …

Type_N 3 Type of the third command (enumerate: Listen, Initiate, Active,

Quality, Good, Poor)

SlotId_N 4 Slot identifier for the third command

CarrierId_N 5 Carrier identifier for the third command

RBType_N 1 Type of Radio bearer for the third command

(symmetric/asymmetric)


From 17 to 4+N*13

Table 19: Physical channel commands format



2.3.2.1.12 Other-Band Coexistence Information message

In contrast to Coexistence Information message, this message does not need to be received before UE can access the network. In order to receive it, the UE needs to explicitly request for it. This message conveys information about other bands available for access. The existence of this message is advertised in the Coexistence Information message (see Section 2.3.2.1.3). If system operates using more bands, more than one message is transmitted as a response to UE request.

Other Band Coexistence Information Message


BandId 4 Band identifier

Number of Carriers 5 Number of carriers used in a given band

Bandwidth 3 Bandwidth of frequency channels in a given band

Carriers 0-32 Map of carriers accessible in this band

MaxAllowedTxPower 5 Maximum transmit power (in dBm) per frequency channel

PhyChanSelGranurality 4 Granularity of physical channel selection list (in dB)

MaxInterferenceAllowed 5

Maximum level of interference in a physical channel which permits its allocation

MaxLoad 4 Maximum number of physical channels which can be

allocated per band

BsTxPower 5 BS transmission power in a specific band

MoreBands 1 Indicates that system operates on additional bands

Total number of bits From 35 to 67

Table 20: Out-of-band coexistence message format

2.3.2.1.13 Asymmetric Acknowledgement Information message

This message conveys user specific information and is used to carry acknowledgement information for all active asymmetric radio bearers. The message can be transmitted in uplink (by UE) or downlink (by SC) and is always carried over a bi-directional pilot radio bearer. The message has variable length which depends on the number of active asymmetric radio bearers and is subdivided into two parts. The first part carries information relevant for the first half frame whilst the second part carries information for the second half frame. It is worth highlighting here that, in contract to bi-directional radio-bearers, no user specific control information is transmitted over a C-Field of asymmetric RBs. This means that C-Field of asymmetric RBs does not need to be acknowledged.

Asymmetric Acknowledgement Information message

Field type Field size Field description

RB Number 4 Number of Active asymmetric Radio Bearers

RB-1 U-Field ACK 1 Acknowledgement of U-Field for RB1 in the first half

frame

… … …

RB-N U-Field ACK

1 Acknowledgement of U-Field for RB-N in the first

half frame

RB-1 U-Field ACK 1 Acknowledgement of U-Field for RB1 in the second

half frame

… … …

RB-N U-Field ACK

1 Acknowledgement of U-Field for RB-N in the second

half frame


From 8 to N*4 + 4

Table 21: Asymmetric Acknowledgement Information message format



2.3.2.1.14 Channel Quality Indication message

This message conveys user specific information and is used to carry information about channel quality for active radio bearers (including pilot radio bearers). The message can be transmitted in uplink and is always carried over a pilot radio bearer. There are two types of Channel Quality Indication (CQI) message defined: type 1 and type 2. CQI message Type 1 has variable length which depends on the number of active asymmetric radio bearers and is subdivided into two parts. The first part carries information relevant for the first half frame whilst the second part carries information for the second half frame. In contrast to CQI message Type 1, the CQI message Type 2 does not need to carry information for all active bearers. Instead, it can carry information for just a subset of Radio Bearers (this is especially beneficial in case of slowly varying channels). Decision on whether to use Type 1 or Type 2 message depends on the size of the message (message with the smallest size is always selected). The message is transmitted if degradation of RB performance is detected. The transmission of the message can be repeated if C-Filed of a pilot bearer is not acknowledged by a SC.

Channel Quality Indication Message Type 1


RB Number 4 Number of active asymmetric

Radio Bearers

RB-1 CQI 4 CQI for RB1 in the first half frame

… … …

RB-N CQI 4 CQI for RB-N in the first half frame

RB-1 CQI 4 CQI for RB1 in the second half

frame

… … …

RB-N CQI 4 CQI for RB-N in the second half

frame


From 12 to N*8 + 4

Table 22: Channel Quality Indication Type 1 message format

Channel Quality Indication Message Type 2


RB Number 4 Number of RB information contained in the message

RB-1 ID 4 Identifier of asymmetric Radio

Bearer

RB-1 CQI1 4 CQI for RB1 in the first half frame

RB-1 CQI2 4 CQI for RB1 in the second half

frame

… … …

RB-N ID

RB-N CQI1 4 CQI for RB-N in the first half frame

RB-N CQ2 4 CQI for RB-N in the second half

frame


From 16 to N*12 + 4

Table 23: Channel Quality Indication Type 2 message format



2.3.2.1.15 Modulation and Coding Scheme Indication message

This message conveys information about modulation and coding scheme used for active radio bearers (including pilot radio bearers). The message is transmitted in downlink and is always carried over a pilot radio bearer. Similar to CQI message, there are two types of Modulation and Coding Scheme (MCS) Indication message defined: type 1 and type 2. MCS Indication message Type 1 has variable length which depends on the number of active asymmetric radio bearers and is subdivided into two parts. The first part carries information relevant for the first half frame whilst the second part carries information for the second half frame. In contrast to MCS Indication message Type 1, the MCS Indication message Type 2 does not need to carry information for all active bearers. Instead, it can carry information for just a subset of Radio Bearers (this is especially beneficial in case of slowly varying channels). Decision on whether to use Type 1 or Type 2 message depends on the size of the message (message with the smallest size is always selected). The message is transmitted as a response to CQI message received from a UE, or when MCS for uplink RB needs to be altered (e.g. due to channel degradation). The transmission of the message is repeated until C-Filed of a pilot bearer is acknowledged. Given that C-Field is acknowledged by a UE, the modification of MCS for the requested RBs is conducted in the next frame.

Modulation and Coding Scheme Indication Message Type 1


RB Number 4 Number of active asymmetric

Radio Bearers

RB-1 MCS 4 MCS for RB1 in the first half frame

… … …

RB-N MCS 4 MCS for RB-N in the first half frame

RB-1 MCS 4 MCS for RB1 in the second half

frame

… … …

RB-N MCS 4 MCS for RB-N in the second half

frame


From 12 to N*8 + 4

Table 24: MCS Indication Type 1 message format

Modulation and Coding Scheme Indication Message Type 2


RB Number 4 Number of RB information contained in the message

RB-1 ID 4 Identifier of asymmetric Radio

Bearer

RB-1 MCS1 4 MCS for RB1 in the first half frame

RB-1 MCS2 4 MCS for RB1 in the second half

frame

… … …

RB-N ID

RB-N MCS1 4 MCS for RB-N in the first half frame

RB-N MCS2 4 MCS for RB-N in the second half

frame


From 16 to N*12 + 4

Table 25: MCS Indication Type 2 message format



2.3.2.2 User Data Field description

In the following we describe format and contents of the U-Field. In general the U-field consists of a message and a CRC. In order to prevent processing of overheard messages transmitted by neighbouring SCs (or UEs associated with neighbouring SCs), CRC of U-fields is scrambled by the last 24bits of a User Id. Size of U-Field is variable and depends on the amount of resources allocated for C-Field.

Bits Variable 24

User Data Field User data payload CRC

Table 26: Basic U-Field format

2.3.3 MAC constants

The DCS-MAC constants are given in Table 27.

Parameter Value

FrameDuration 10 ms

MultiframeDuration 160 ms

BaseSlotDuration 416.7 us

BaseBandwidth 2 MHz

PrimaryAllocationBlockSize 3 OFDM slots

BaseNumberOfSlots 24

SystemInformationPeriod 80 ms

CoexistenceInformationPeriod 8 0ms

CWmin 10 DCS frames (100 ms)

CWmax 320 DCS frames (3200 ms)

N1 10

N2 15

N3 10

T1 2 sec

T2 3 sec

T3 2 sec

Table 27: DCS-MAC constants

2.3.4 DCS-MAC Procedures

The following section describes several basic procedures supported by the proposed MAC design. The DCS-MAC layer can perform the procedures listed below. Note that the concept of DCS MAC is innovative and it does not rely on a channel (like FBMC MAC, LTE and/or Wifi) which has to be identified or reconfigured since it allocates on a per case base a set of bearers to convey signaling and/or user date.

Data transmission

Paging

LMAC/PHY (re-)configuration



Pilot radio bearer establishment

Non-pilot radio bearer establishment

Common radio bearer establishment

Radio bearer release

Radio bearer handover

System information dissemination

Synchronization/locking

2.3.4.1 Data Transmission procedure

In the following we describe data transmission procedures. Two types of transmission are considered in DSC-MAC: 1) transmission over a dedicated radio bearer and 2) transmission over a common radio bearer. As shown later, dedicated radio bearers permit transmission of control and user traffic, whilst common radio bearers are used solely for transmission of common control traffic and paging. If necessary, LMAC control traffic and higher layer control traffic can be time-multiplexed.

2.3.4.1.1 Data Transmission over a dedicated radio bearer

The following MSCs present interaction between different entities on the transmission and receiving side for a dedicated radio bearer. It is important to note that in case of a dedicated radio bearer all the allocated radio resources need to be fully occupied to limit fluctuations of interference measurements conducted by other nodes in the network. This means that if the amount of resources which is required to send the signaling and RLC data is smaller than the amount of resources provided by radio bearers, then dummy data needs to be generated and sent over the unused resources. This dummy data is then discarded on the receiver side before the signaling and the RLC data is then processed.

It is worth highlighting here that there is a direct mapping between MAC-specific steps depicted in Figure 122 to Figure 128 in Section C.4 and figures provided below. For instance, Steps in the figures below correspond to Step#3 to Step#6 in Figure 122 and Step#1 to Step#3 in Figure 124.



Figure 18: Transmission over a dedicated radio bearer (TX side)



Figure 19: Transmission over a dedicated radio bearer (RX side)

Figure 20: Transmission over a dedicated radio bearer (Over the air)

2.3.4.1.2 Data Transmission over a common radio bearer

The following MSCs present interaction between different entities on the transmission and receiving sides in case of a common radio bearer. In contrast to a dedicated radio bearer, the transmitting side of a common radio bearer can be solely a SC. A common radio bearer is setup and used if there is no active UE in a SC to disseminate important common control information and paging.



Figure 21: Transmission over a common radio bearer (TX side)

Figure 22: Transmission over a common radio bearer (RX side)



Figure 23: Transmission over a common radio bearer (Over the air)

2.3.4.2 Pilot radio bearer establishment procedure

This procedure is used to establish a bi-directional radio bearer for conveying control traffic. At least one pilot bearer needs to be maintained for every active connection. The procedure includes channel selection which consists for three steps described below.

1. Select the physical channel with the best quality (e.g. minimum level of interference) which does not breach any of the channel access requirements and is accessible not sooner than in the next TDMA frame (information about the channel access requirements, such as maximum allowed interference level in different bands and channels, could be preconfigured or obtained from a higher layer entity).

2. Conduct measurements on the selected physical channel (in uplink slot and downlink slot) one TDMA frame before accessing the channel (this is necessary as the measurements which are used to make a decision could be outdated). If the measurement results indicate that the quality of the selected channel has degraded by a specific factor compared to the last conducted measurement, then select a new channel and repeat the procedure for the new channel.

3. Access the channel in the slot allocated for uplink transmission (in case of UE-initiated procedure) or downlink transmission (in case of small cell (SC)-initiated procedure).

Two Bearer Establishment procedures can be distinguished in DCS-MAC. The first procedure is conducted in case a UE is in the RRC_IDLE state, whilst the second procedure is conducted when a UE is in the RRC_CONNECTED state. The first procedure is triggered upon initial UE attachment or when it initiates a connection with a SC. The second procedure is used when a UE has an existing RRC connection with a SC and needs to re-establish a bearer after its release caused by UE inactivity. The procedure is triggered by arrival of new data at the UE or the SC side and does not require interaction with RRC entities.

2.3.4.2.1 Pilot radio bearer establishment procedure in the RRC_IDLE state

In the following we describe the Radio Bearer Establishment procedure for the case when a UE is in the RRC_IDLE state. The procedure is triggered as a response to an RRC connection request message by an RRC entity, located on the UE side. As indicated in Section C.4, this can happen in in case of 1) initial attachment to a network, 2) service request, or 3) tracking area update in the RRC_IDLE state.

Four Message sequence charts are provided in this section. The first and the second MSCs, depicted in Figure 24 and Figure 25, describes the interaction between different entities within a UE and SC, respectively. The last two MSCs, depicted in Figure 26 and Figure 27 provide information about messages being exchanged over the air for the case of successful and unsuccessful radio bearer establishment.

As can be seen from Figure 26, a successful establishment of a radio bearer requires successful



exchange of four messages. After first four messages are exchanged a radio bearer is considered as established which means that a single frame error does not result in an immediate release. This four-step mechanism is necessary to decrease the probability of selecting channels of a poor quality.

It is worth highlighting here that there is a direct mapping between MAC-specific steps depicted in Figure 122, Figure 125, Figure 126 and figures provided below. For instance, Steps 1 to 5 in Figure 24 (success part) with Steps 1 to 2 in Figure 25 (success part) and Step 1 in Figure 26 correspond to MAC-specific Step#1 in Figure 125 and Figure 126 and MAC-specific Step#2 in Figure 122.

Figure 24: Message sequence chart for execution of pilot radio bearer establishment in RRC idle state (UE side).



Figure 25: Message sequence chart for pilot radio bearer establishment in RRC idle state (Small Cell side).



Figure 26: Message sequence chart for successful pilot radio bearer establishment (Over the air).



Figure 27: Message sequence chart for unsuccessful pilot radio bearer establishment (Over the air).



2.3.4.2.2 Pilot radio bearer establishment procedure in the RRC_CONNECTED state

In the following we describe the Radio Bearer Establishment procedure for the case when a UE is in the RRC Connected state. In contrast to the procedure when UE is in the RRC Idle state, this procedure in the RRC_CONNECTED state can be initiated either by a UE or a SC. The procedure is initiated in a response to arrival of new data to an empty RLC buffer.

Two Message sequence charts are provided in this section and describe the interaction between different entities on the initiator side and the responder side. The MSCs describing the over-the-air transmission are discussed in the previous section (see Figure 26 and Figure 27).

Figure 28: Message sequence chart for pilot radio bearer establishment in RRC Connected state (Initiating side).



Figure 29: Message sequence chart for execution of bearer establishment in RRC Connected state (responding side).

2.3.4.3 Non-pilot radio bearer establishment procedure

This procedure is used to establish non-pilot bearers (which are used for u-plane/data transmission) and overwrite pre-allocation of slots for uplink and downlink transmission thus allowing establishment of asymmetric bearers/links between UEs and SC. In general, the procedure is used to 1) modify bandwidth of ongoing connections by establishing new radio bearers, 2) establish a multi-radio-bearer connection (e.g. during inter-cell handover), 3) reallocate resources for non-pilot radio bearers within the same cell (i.e. intra-cell i.e. slot handover).



In contrast to the pilot radio bearer establishment procedure, this procedure enables the initiating party to modify channel scanning/hopping sequence of the receiving party. This allows for significant reduction of the radio bearer establishment time. Similar to the pilot radio bearer establishment procedure for the case when a UE is in the RRC-connected state, the procedure is the same for the UE-initiated and the SC-initiated bearer establishment. The procedure involves channel selection which consists for four steps described below.

1. Select the physical channel with the best quality (e.g. minimum level of interference) which does not breach any of the access requirements and can be measured at least once before being accessed (information about the channel access requirements, such as maximum allowed interference level in different bands and channels, could be preconfigured or obtained from a higher layer entity).

2. Conduct measurements on the selected physical channel (in uplink slot and downlink slot) one TDMA frame before accessing the channel (this is necessary as the channel quality measurements which are used to make a decision could be outdated). If the measurement results indicate that the quality of selected channel significantly degraded compared to the last measurement, we select a new channel and repeat the procedure for a new channel.

3. Inform the receiving party about physical channels selected for transmission to temporarily modify its scanning/hopping sequence (information can be conveyed over already established pilot bearer, or a pilot bearer which is being established). This step is optional and is used only if modification of scanning/hopping sequence is necessary.

4. Access the selected channel using the slot allocated for uplink transmission (in case of a UE-initiated bi-directional bearer), downlink transmission (in case of a SC-initiated bi-directional bearer) or both slots (is case of an asymmetric bearer)

Six Message sequence charts are provided in this section with the first two describing the interaction between different entities on the initiating side and the responding side. The remaining MSCs describe the over-the-air transmission. Two types of bearers can be established using the non-pilot radio bearer establishment procedure: 1) symmetric radio bearer, and 2) asymmetric radio bearers. As can be seen the over-the-air part of the non-pilot bearer establishment procedure for symmetric bearer is the same as in case of the pilot radio bearer (please refer to Section 2.3.4.2 for more detail).



Figure 30: Message sequence chart for non-pilot bearer establishment (Initiating Side).



Figure 31: Message sequence chart for non-pilot bearer establishment (Responding Side).



Figure 32: Message sequence chart for successful non-pilot asymmetric bearer establishment (Over the air).

Figure 33: Message sequence chart for successful non-pilot symmetric bearer establishment (Over the air).



Figure 34: Message sequence chart for unsuccessful non-pilot asymmetric bearer establishment (Over the air).



Figure 35: Message sequence chart for unsuccessful non-pilot symmetric bearer establishment (Over the Air).



2.3.4.4 Common radio bearer establishment procedure

On the SC side the procedure is triggered after a SC is switched on or when a last dedicated bearer is released by the SC. In the first case, similar to other radio bearer establishment procedures, the procedure involves channel selection which consists of three steps.

1. Select the physical channel with the best quality (e.g. minimum level of interference) which does not breach any of the access requirements and can be measured at least once before being accessed (information about the channel access requirements, such as maximum allowed interference level in different bands and channels, could be preconfigured or obtained from a higher layer entity).

2. Conduct measurements on the selected physical channel (in uplink slot and downlink slot) one TDMA frame before accessing the channel (this is necessary as the channel quality measurements which are used to make a decision could be outdated). If the measurement results indicate that the quality of selected channel significantly degraded compared to the last measurement, we select a new channel and repeat the procedure for a new channel.

3. Access the selected channel using the slot allocated for downlink transmission

In the case when a common bearer is established as a result of a last dedicated bearer being released, channel selection is not necessary as a SC can allocate resources used by the last dedicated bearer (unless dedicated bearer was released due to a poor physical channel quality).

The following message sequence chart describes interactions between different entities within a SC which are necessary to establish a common bearer.

Figure 36: Message sequence chart for execution of common bearer establishment (Small cell side)

On the UE side, the procedure is triggered when a UE determines that a given SC can be camped on, and after a release of the last Dedicated Radio Bearer. The first case is part of the synchronization/locking procedure described in Section 2.3.4.10.



Figure 37: Message sequence chart for execution of common bearer establishment (UE side)

2.3.4.5 Radio Bearer handover procedure

This procedure for radio bearer handover is triggered whenever one of the established dedicated bearers is considered to be of a poor quality. In general, the bearer handover procedures can be subdivided into intra-cluster handover procedure and inter-cluster handover procedure. The intra-cell handovers (i.e. reallocations of resources within the same cell) are considered to be a part of the intra-cluster handovers. The main difference between intra-cluster and inter-cluster handover procedures is related to the involvement of higher layers. The party responsible for initiating the procedure in most situations is the UE. In some cases this can be done also by the SC. For instance, this happens in case of an intra-Cell handover for downlink asymmetric radio bearer. Additionally, it is also possible for a SC to request a handover by sending a control message to a UE. This message can however be ignored by a UE.

2.3.4.5.1 Intra-Cluster radio bearer handover

In the following we describe the Intra-Cluster bearer handover procedure. The procedure is triggered when one of established dedicated bearers is considered to be of a poor quality and prior measurements indicate that the strongest received signal power originates from a member of the same cluster.

Two Message sequence charts are provided in this section. The first MSC describes the interaction between different entities within a UE whilst the second MSC is focused on the SC side.

As can be seen from both figures, the handover procedure uses the Radio Bearer Establishment procedure (for pilot and non-pilot radio bearers) and Radio Bearer Release procedures. This indicates that the procedure is essentially no different from a radio bearer establishment in the RRC-Connected state.



Figure 38: Message sequence chart for intra-cluster radio bearer handover procedure (Initiator side).



Figure 39: Message sequence chart for intra-cluster radio bearer handover procedure (Responder side).

2.3.4.5.2 Inter-Cluster radio bearer handover

In the following we describe the Inter-Cluster bearer handover procedure. The procedure is triggered when one of established dedicated bearers is considered to be of a poor quality and prior measurements indicate that the strongest received signal power originates from a member of another cluster. In contrast to intra-cluster handovers, inter-cluster handovers require interaction between RRC entities and can be initiated only by UEs. The inter-cluster handover procedure is conducted solely for the pilot radio bearer (after exchange of all necessary RRC related messages with a new SC, the remaining radio bearers follow the intra-cluster handover procedure).



Two Message sequence charts are provided in this section. The first MSC describes the interaction between different entities within a UE whilst the second MSC is focused on the SC side.

Figure 40: Message sequence chart for inter-cluster radio bearer handover procedure (UE side).



Figure 41: Message sequence chart for inter-cluster radio bearer handover procedure (Small Cell Side).



2.3.4.6 Radio Bearer release procedure

This procedure is used to free physical channels allocated by the bearer establishment procedure. In general, the procedure is triggered to 1) release an ongoing connection, 2) release resources after successful handover, 3) modify the amount of resource allocated for a given connection, 4) convert a bidirectional bearer into an asymmetric bearer, 5) manage channel overload. In case of asymmetric radio bearers, the release message needs to be transmitted on both links by the transmitting side. The procedure for asymmetric radio bearers on the receiving side can be triggered over a pilot bearer.

Two Radio Bearer Release procedures can be distinguished in DCS-MAC. The first procedure is triggered as a result of UE inactivity and does not involve interaction with RRC entities. The second procedure is triggered in case of a long UE inactivity, complete connection release or an inter-cluster handover and involves interaction with RRC entities.

2.3.4.6.1 Radio Bearer release procedure without RRC connection release

The following MSCs present the Initiator and the Responder side of the first type of Release procedure. The procedure can be triggered either by a UE or by a SC. Two cases are considered in the figure below. In the first case radio bearers are released due to user inactivity. In the second case radio bearers are released as a result of radio resources being inefficiently utilized.

Figure 42: Message sequence chart for radio bearer release (Initiator Side).



Figure 43: Message sequence chart for radio bearer release (Responder Side).

Figure 44: Message sequence chart for symmetric radio bearer release (Over-the-air).

Figure 45: Message sequence chart for asymmetric radio bearer release (Over-the-air).

2.3.4.6.2 Radio Bearer release procedure with RRC connection release

The following MSCs present the exchanges at the Initiator and the Responder sides of the RB release procedure including RRC connection release. In contrast to the previous release procedure, this procedure can be triggered solely by a SC and involves transmission of an RRCConnectionRelease message. Two cases are considered for this procedure. In the first case radio bearers are assumed to be established before the procedure is initiated. This allows for the release procedure to be conducted in a similar fashion as the release procedure described in the previous section. In the second case no radio bearers are assumed to be established before the procedure is triggered. This means that a new pilot radio bearer needs to be requested by a SC to convey an RRCConnectionRelease message. The pilot radio bearer establishment procedure is initiated by a SC and an RRCConnectionRelease message is transmitted over a RadioBearerEstablishReq message. The pilot radio bearer establishment is then terminated by a UE in a response to an



RRCConnectionRelease message.

It is worth highlighting here that there is a direct mapping between MAC-specific step#1 depicted in Figure 128 in Section C.4 and the figures provided below.

Figure 46: Message sequence chart for Bearer release with RRC connection release (Initiator Side).



Figure 47: Message sequence chart for bi-directional bearer release (Responder Side).

2.3.4.7 Paging procedure

This procedure is initiated by the SC and is triggered whenever it needs to initiate a connection with a UE in the RRC_IDLE state. The procedure permits SCs to indicate which physical channels should be used by UEs during their pilot bearer establishment procedure. In case the paging procedure does not result in triggering of the procedure for pilot bearer establishment, the transmission of a paging message can be repeated until it expires. To allow for a full backward compatibility, the validity of a paging message cannot exceed to value of the timer located in MME which is responsible for handling paging failure.

Paging message is transmitted over common control channels. The common control channel in DCS-MAC is transmitted over all established dedicated radio bearers and common radio bearers. This is necessary to maintain high robustness against interference by allowing UEs in the RRC_IDLE state to dynamically select downlink bearers to camp on, based on their quality.

It is worth highlighting here that there is a direct mapping between MAC-specific step#1 depicted in Figure 127 in Section C.4 and the figures provided below.



Figure 48: Message sequence chart for paging procedure (Small Cell side).

Figure 49: Message sequence chart for paging procedure (UE side).

2.3.4.8 System information dissemination procedures

In the following we describe the procedures for dissemination of system information. As shown in the next subsections, system information may either originate from higher layers (e.g. HMAC or RRC) or generated by LMAC.

2.3.4.8.1 Higher layer common information dissemination procedure

The following procedure is used by a SC to disseminate higher layer common system information to all UEs which are currently camping on a given cell or maintain an active connection.

It is worth highlighting here that there is a direct mapping between MAC-specific step#1 depicted in



Figure 124 in Section C.4 and the figures provided below.

Figure 50: Message sequence chart for system information indication procedure (Small Cell side).

Figure 51: Message sequence chart for system information indication procedure (UE side).

2.3.4.8.2 LMAC common information dissemination procedure

This procedure is used by a SC to disseminate LMAC related common system information to all UEs which are currently camping on a given cell or maintain an active connection. In the following MSC we describe one example of LMAC common information dissemination.

One of the main pieces of common information from LMAC which need to be disseminated is slot availability (see Section 2.3.2.1.4). SCs and UEs which operate using DSC-MAC need to cease scanning during slots allocated to active radio bearers when there is insufficient number of transceivers. This leads to the “deafness problem” (also called the “missing/busy receiver problem”). In order to alleviate this problem, SCs broadcast information about slots which are unavailable for access. In general, the procedure is triggered whenever a slot becomes unavailable (or available) for access. However, in order to limit the overhead related with frequent slot status changes, the transmission of the updated information can be delayed to aggregate information about multiple slots. As UEs are expected to be accessed only by their serving base stations, which are fully aware their slot allocations, UEs are not required to initiate this procedure. The message sequence chart for the slot availability indication procedure is shown in the figure below.



Figure 52: Message sequence chart for Slot availability indication procedure.

2.3.4.9 Reconfiguration procedures

2.3.4.9.1 Slot length modification procedure

The procedure can be triggered by a SC or a UE for an already-established bi-directional or uni-directional radio bearer. The procedure enables adaptation of physical channel parameters to changing channel load and interference conditions. The procedure is triggered by HMAC entity but its execution is handled by LMAC. As indicated in the MSC below, the reconfiguration control message is transmitted over an established pilot bearer.

Figure 53: Message sequence chart for slot length modification (over-the-air).



2.3.4.9.2 Channel scanning/hopping sequence alteration procedure

This procedure can be triggered by a SC. The procedure enables adaptation of scanning/hopping sequence to changing channel load conditions.

Figure 54: Message sequence chart for channel scanning/hoping sequence alteration (Small Cell side).

Figure 55: Message sequence chart for slot length modification (Responder side).

2.3.4.10 Synchronization procedures

2.3.4.10.1 UE synchronization/locking procedure

This section briefly describes the terminal synchronization/locking procedure. The procedure is triggered after a UE is switched on. The main aim of the procedure is to allow UEs to establish slot and frame synchronization, find the closest SC and obtain all necessary information required to establish a connection with this cell. In general, the procedure consists of three phases. During the first phase a UE scans for any receivable transmission which carries System Identity message and which indicates that a given SC could be accessed by a UE. When such transmission is received, a UE



obtains also “slot synchronization” and moves to the second phase (it is worth noting that the System Identity message is transmitted not only by SCs, but also by UEs transmitting in uplink). During the second phase of synchronization/locking procedure a UE attempts to receive a System Information message which carries information about the channel bandwidth used in the given band and allows a UE to obtain frame synchronization. After receiving System Information message, a UE enters the third phase and builds a map of all SCs available on different physical channels while receiving information using the strongest detected downlink RB (this can be either a common RB or a dedicated RB). In case a SC with a stronger signal is found, the UE switches reception and starts monitoring the newly detected cell. When a UE obtains all other necessary information, the UE enters the “synchronized/locked state” and initiates Initial attachment procedure to inform network about its arrival (see Section C.1 for details).

2.3.4.10.2 Small cell synchronization/locking procedure

This section describes the SC synchronization/locking procedure. The procedure is initiated after a SC is switched on. The main aim of this procedure is to allow SC to establish slot and frame synchronization with other SCs in the neighbourhood and to select a scanning/hopping sequence which minimizes the contention between UEs camping on different cells. It is worth noting here that the proposed MAC can still operate without the slot and the frame synchronization. However, this would result in higher levels of interference.

The procedure is similar to the “UE synchronization/locking procedure” and consists of three phases. During the first phase a SC scans for any receivable transmission with System Identity message originated from other cells. When such transmission is received, a SC obtains “slot synchronization” and moves to the second phase. During the second phase of procedure the SC attempts to receive a System Information message which carries information about the channel bandwidth used in the given band and allows the SC to obtain frame synchronization. After receiving System Information message the SC enters the third phase and builds a map of other SCs available on different channels. Based on the observed scanning/hopping sequences (which are periodically transmitted over common control channels by neighbouring SCs), the cell selects its own scanning/hopping sequence. After selecting its own scanning/hopping sequence, the cell enters the “synchronized/locked state” and establishes a common radio bearer for dissemination of common control information (see Section 2.3.4.8.2).

2.4 Filter-Bank Multicarrier (FBMC)-based MAC specification

2.4.1 FBMC MAC design overview

As described in D5.1 [1], this MAC design relies on a master-slave operation mode, with the SC being the master of the UEs within radio range in a star-like topology. Data transmission is based on a combination of contention and scheduled access within a beacon-enabled MAC superframe where uplink and downlink data, control and command frames are sent within timeslots. The beacon, sent by the SC, provides the basic timing to synchronise UEs and carries most of the control information for device discovery, network organisation and resource reservations as well as scheduling information.

The superframe structure is depicted in Figure 56 and is an evolution of the ECMA 392 standard [9]. The beacon-enabled superframe is composed of time slots that could be allocated to uplink or downlink communications, depending on the load in the network by the higher MAC. The component parts of the superframe, already described in detail in [1], are the following

A scheduled access period, called Contention Free Period (CFP) with an uplink and a downlink part. The SC scheduler allocates resource blocks (RBs) in the CFP slots to UEs both in up and downlink, the allocation for the superframe being described in the beacon.



A contention access period (CAP) located at the end of the frame and composed of slots. And used to transmit control and command frames in uplink.

A SC ACK slot where uplink traffic, if any, is acknowledged

An Idle period at the end of the superframe.

Figure 56: FBMC MAC frame structure

2.4.1.1 Shared spectrum utilisation modes

The following sections describe how the SC can get a transmit opportunity for the superframe on a shared frequency band, using listen-before-talk (LBT). This comes along the exploitation of Frame-Based Equipment (FBE) or Load-Based Equipment (LBE) features, as outlined in the ETSI regulation specification ([5]), allowing for two access options. In D5.1, only the channel access corresponding to the FBE option has been described, which is well suited to non-crowded spectrum usage. The LBE option has been added as it provides a more flexible contention scheme which may lead to improved fairness of the access of neighbouring systems in dense deployment scenarios. Note that whatever is the access mode (FBE or LBE), the SC applies the LBT procedure only for triggering the emission of the superframe. If a superframe transmission opportunity is found by the SC, there is no further LBT operation for the CFP slots of the superframe, would they be for DL or UL traffic.

2.4.1.1.1 Frame based access

In this access mode, the superframe emission is triggered by a CCA (Clear Channel Assessment) procedure, which is done in a periodic manner. If the channel is seen as empty, the superframe is emitted; if the channel is deemed as busy, the SC refrains until the next CCA opportunity. The CCA period is called the “Fixed Frame length” and is the actual superframe duration shown in Figure 56. The ETSI regulation specifies that the channel occupancy time (COT) shall be between 1 and 10 ms and followed by an inactivity period of at least 5% of the COT. Finally, the CCA shall be done during a minimum duration of 20 µs. The FBE access mode for the SC operation is shown in Figure 57.

Figure 57: Frame based equipment (FBE) access mode

In dense deployment scenarios, this access mode may induce some unfairness. Indeed, in this case a given SC which gets a transmit opportunity will have a high probability to keep the channel and may block most of its neighbours. The latter may experience a busy channel when performing a CCA

Be

aco

n Scheduled

uplink

access

Scheduled downlink

access

CAP

Freq.S

ub

-chann

els

Idle

Period

Channel occupancy time

A

C

K

CFP

Superframe duration

time

Frame #(i-1) Frame #iNo emission

time

Frame #i+1

CCA:

free

CCA:

busy



which will make them defer their transmission until their next CCA opportunity, which may fall during the superframe emission of the first SC.

2.4.1.1.2 Load based access

In order to circumvent the aforementioned blocked nodes issue, the integration of a bigger and more flexible contention proportion in the access mode is desirable [12][13]. This follows the lead of 3GPP specifications which has retained the Load-Based Equipment (LBE) as the channel access for downlink and uplink transmissions in the 5GHz in the framework of LAA procedure [14]. The FBMC MAC design reuses part of these specifications, whilst acknowledging that the uplink access method in FBMC is quite different as it is triggered by the SC resource allocation (time slot). The load based access introduces the notion of extended CCA (eCCA): a successful initial CCA done over a duration Td triggers a random back-off procedure. A transmission opportunity is found if the channel is sensed (E-CCA) as free over N consecutive time periods of duration Ts = 9 µs. N is randomly selected in the interval [1, CW], where CW is the length of the contention window. If an E-CCA turns out to be negative (channel is busy), an initial CCA is performed maintaining the current value of N. This procedure is shown in Figure 58.



Figure 58: Load based equipment (LBE) access mode (N=3)

Different options in this access mode exist (referred as to access priority orders in 3GPP specifications). Each option governs the values of the initial CCA duration, the maximum size of the contention window and the duration of the superframe (COT), as shown in Table 28. It is worth noting that compared to 3GPP specifications, we have excluded two options since it would result in too short a COT duration, given the FBMC MAC superframe structure.

Access option

mp Td (µs) CWmin CWmax Allowed CW COT (ms)

1 3 16+ mp*9

15 63 {15,31,63} 8 ms

2 7 16+mp*9 15 1023 {15,31,63,127,255,511,1023} 8 ms

Table 28: Superframe durations for load based access

2.4.1.2 FBMC physical layer assumption

The baseline for the definition of the FBMC PHY is the physical layer of LTE which is based on CP-OFDM PHY. In terms of numerology, the LTE PHY relies on a 1024-FFT (resp. 2048-FFT), an inter-carrier spacing of 15 kHz and a 15.36 MHz (resp. 30.72 MHz) sampling frequency for the 10 MHz option (resp. 20 MHz). Similarly to LTE, the physical layer is made to support physical resource blocks of 180 kHz, which is the elementary band allocation. In the project, the FBMC physical layer is assumed to rely on a particular implementation of FBMC called Frequency Spreading-FBMC (FS-FBMC) [7]. Performance studies shows that the frequency sampling process of FS-FBMC for K=4 allows to reach the same level of performance of LTE PHY even when the number of sub-carriers is reduced by 4. As a result, for the 10 MHz band option, an “equivalent” FBMC PHY could operate with 256 sub-carriers with a 60 kHz inter carrier spacing. Note that the reduction of the number of subcarriers induces a reduction of the Peak-to-Average Power Ratio (PAPR) which allows to reduce constraints on the RF front end design. Table 29 shows FBMC parameters for broadband transmission for bandwidth of 10 and 20 MHz.

Parameters 10 MHz band 20 MHz band

𝑁 (FFT size) 256 512

𝑁𝑐 (active carriers) 165 330

∆𝑓 (intercarrier spacing) 60 kHz 60 kHz

B (bandwidth) 9.9 MHz 19.8 MHz

PRB (resource block) 180 kHz 180 kHz

𝐹s = 𝑁∆𝑓 (sampling freq) 15.36 MHz 30.72 MHz

Symbol time (K=4) 66 µs

Table 29: Broadband FBMC parameters

As explained in deliverable D5.1 ([1]), a key feature of FBMC is that two asynchronous transmissions on adjacent channels or bands do not result in significant interference if a guard band of at least an inter-carrier spacing is introduced. This translates into a better spectrum utilization than in LTE: using FBMC, a 10 (resp. 20) MHz band is occupied up to 9.9 (19.8) MHz whereas in LTE the same band is



occupied up to 9 (18) MHz. This isolation of 2 concurrent and adjacent streams with a one-carrier guard band will be further exploited for uplink resource allocation.

In addition to this, the FBMC MAC supports a set of possible modulation and coding schemes, to enable adaptive modulation. They have been derived from LTE specifications, using the same channel coding methodology and extending the list of supported modulations to 256-QAM. For this particular modulation, the values of the “ratio” parameter have been obtained by extrapolating the LTE values. The MCS values and parameters are given in Table 30.

CQI Index MCS name Bit Per symbol Ratio (/1024) Efficiency

1 QPSK 2 0,07617188 0,15234375

2 QPSK 2 0,1171875 0,234375

3 QPSK 2 0,18847656 0,37695313

4 QPSK 2 0,30078125 0,6015625

5 QPSK 2 0,43847656 0,87695313

6 QPSK 2 0,58789063 1,17578125

7 16-QAM 4 0,36914063 1,4765625

8 16-QAM 4 0,47851563 1,9140625

9 16-QAM 4 0,6015625 2,40625

10 64-QAM 6 0,45507813 2,73046875

11 64-QAM 6 0,55371094 3,32226563

12 64-QAM 6 0,65039063 3,90234375

13 64-QAM 6 0,75390625 4,5234375

14 64-QAM 6 0,85253906 5,11523438

15 64-QAM 6 0,92578125 5,5546875

16 256-QAM 8 0,72949219 5,8359375

17 256-QAM 8 0,78125 6,25

18 256-QAM 8 0,83105469 6,6484375

19 256-QAM 8 0,87792969 7,0234375

20 256-QAM 8 0,92382813 7,390625

21 256-QAM 8 0,96679688 7,734375

Table 30: Modulation and coding schemes of FBMC MAC

2.4.1.3 Multiple Access

Multiple access is based on an OFDMA-like approach for both uplink and downlink channels, using the same concept of resource block in LTE systems but applied to FBMC modulation. In FBMC-MA, a resource block is an allocation of 3 active subcarriers, spanning on 180 kHz, during a medium access slot. The scheduler is responsible of allocating uplink and downlink resource blocks to active logical channels, assuming the same kind of scheduler as those used in LTE. Interestingly, FBMC tolerates asynchronous transmission in adjacent channels if a guard band of one inter carrier spacing is introduced. This means that uplink resource allocation at SC scheduler can be done in a



straightforward manner. Figure 59 depicts this multiple access scheme on the frame structure, for the scheduled access parts.

Figure 59: Multiple access scheme in FBMC broadband MAC

In this beacon-enabled frame structure, the beacon is initially used for cell identification and network synchronization and carries control information about the scheduled uplink and downlink access as well as the contention-based access as described in next section. In the scheduled downlink access, the SC sends the requested information data to the users based on user priority, QoS requirements and the availability of resources. The scheduled uplink access is used by users that had previously demanded an UP grant access to send uplink data. If an active UE has a both scheduled uplink and uplink resources, control information (CQI, ACK) may be multiplexed with data in the scheduled part and not sent in the CAP as previously stated.

As far as contention access period is concerned, this period is used to initiate network access (association/de-association) and send ACK/NACK and CQI updates. In CAP, UEs perform a random access procedure based on multi-channel access, using an elementary channel of 18 active sub-carriers (6 resource blocks), meaning channel bandwidth of 1 MHz. Thus, 8 elementary channels and 16 elementary channels are assumed available for system bandwidths of 10 MHz and 20 MHz, respectively. Since contention-based access is subject to collisions, the time spent to get access to the medium may be long. The SC may in this case set the priority of traffic to be sent in the CAP as described in the following sections. At the end of the CAP, the SC schedules one slot (2 MAS) to send ACK/NACK for the scheduled uplink data.

2.4.1.4 Adaptive modulation support

The FBMC MAC supports the adaptation of modulation and coding scheme (MCS), based on the MCS list shown in Table 30. For doing so, SCs determine the suitable MCS which can be used to communicate with devices in both uplink and downlink. The determination of the appropriate MCS for downlink is done by exploiting CQI reports sent by devices (e.g. in ACK frames), the CQI report being calculated by the UE on the last received beacon. For uplink, the MCS is determined by the SCs by using the last frames sent by devices. In both cases, devices are notified of the on-going MCS by appropriate information elements in the beacon.

In order to maximise the probability of a proper demodulation by all the nodes, the beacon frame is transmitted using the most robust MCS. Given the PHY parameters given in section 2.4.1.2, the maximum length of the payload for a beacon transmitted on a 1ms time slot is 1376 (respectively 2760) bits for a 10 MHz band (resp. 20 MHz).

CCAn

Frame #n: N medium access slots

Be

aco

n

Scheduled

uplink

access

Scheduled downlink

accessCAP

Freq.

Sub

-chann

els

Idle

Period

Channel occupancy time

CCAn+1

SC

ACK

UE 3

UE

2

UE 4

UE

5

UE3

UE

1UE 1

UE1

UE3

U

E

2



2.4.2 Frame formats

This section describes the format of the different MAC frames which are sent over the air either in uplink or downlink within a MAC superframe. These frames could be either data, control or command frames.

2.4.2.1 Generic frame format

The general frame format is given in Table 31, a MPDU (MAC Packet Data Unit) frame being composed of a MAC header, the frame payload (MSDU, MAC Service Data Unit) and a cyclic redundancy check (CRC) field. The remainder of this section describes the main fields elements of the MAC header (the other being marked as reserved), knowing that the frame format and information elements discussed in this MAC design are deeply rooted in ECMA 392 standard [9].

Bits 16 16 16 16 16 Variable 16

MPDU

Frame Control

Dest. address

Source address

Sequence Control

Access Control

Payload CRC

MAC header

Table 31: General Frame format

2.4.2.1.1 Frame control field

The “Frame Control” filed allows mainly to identify the frame type, which can be a beacon, a data frame, a control or a command frame. The format of this field is given in Table 32.

Syntax Size (bits) Notes

Reserved 4

ACK Policy 1 ACK – No ACK policy

Frame type 3 Defines the frame type (beacon, data, command, control)

Frame Subtype 4 Provide additional information on type (e.g. distinguish commands frames)

Retry 3 For data packets, set to 1 if packet is retried

Reserved 3

Table 32: Generic frame control format

The value of the frame type item designates the nature of the frame, as shown in Table 33.

Value Frame Type Described in section

0 Beacon Ref. section 2.4.2.2

1 Control frame Ref. section 2.4.2.3

2 Command Frame Ref. section 2.4.2.4

3 Data frame Ref. Section 2.4.2.5

4-7 Reserved

Table 33: Frame type field values



2.4.2.1.2 Address fields

The address fields indicate respectively the address of the destination and the source nodes. The source addresses is always set to the originating device whereas the destination node address can identify unicast (destination node address) or broadcast operation. In the former case, the destination address is set to the address of the destination node; in the latter case, the destination address is set to 0xFFFF.

2.4.2.1.3 Sequence control field

The “Sequence Control” field is composed of the items compiled in Table 34.


Fragment Number 3 Indicate the fragment number within a MSDU. Is set to 0 if no fragmentation is applied

Sequence Number 11

More fragment 1 Is set to 0 if no fragmentation is applied or if the last fragment is begin transmitted; 1 otherwise

Reserved 1

Table 34: Sequence Control field format

The “Sequence Number” field allows for different frame control processes, depending on the frame type. For beacon frames, it allows to identify the superframe. For command frames or data frames, this number can be used for instance to avoid duplication, to re-order frames at the reception side or to identify a command when providing the response to the command. The sequence numbers are obtained via a modulo-2048 counter and a device manages several dedicated counters, for instance to identify data frames with the same destination node, command frames, etc.

2.4.2.1.4 Access Control field

The “Access Control” field is described in Table 35.


Duration 14 Estimated channel occupancy (packet duration)

More Frames 1 Flag to indicate if data frames will be sent using the same access method to the same destination node

Access Method 1 Flag to indicate whether the frame is sent in CAP (0) or CFP (1)

Table 35: Access Control field format

2.4.2.1.5 Cyclic Redundancy check field

As shown in Table 31, a CRC field is appended at the end of the frame. The 16 bits of CRC are calculated on the whole frame (MAC header and MSDU parts), using the ITU-CCITT generator

polynomial of degree 16 defined by the following g equation: 𝐺(𝑥) = 𝑥16 + 𝑥12 + 𝑥5 + 1.

2.4.2.2 Beacon frames

In this MAC design, beacon frames are sent by SCs and they provide i) the means of time synchronisation for the nodes in order to enable the TDD operation, ii) system information broadcast where nodes can retrieve parameters required for initial attachment (or cell reselection) or related to superframe structure, iii) uplink and downlink resource allocations and iv) common or dedicated



command information elements. Typically, the beacon is transmitted on the first slot of the superframe; it can be extended on the next slot. Table 36 shows the settings of the header of a beacon frame.

Field Value Notes

Reserved field (4 bits) 0 All bits set to zero

ACK Policy 0 Beacons are not ACKed

Frame type 0 Beacon frame

Frame Subtype Reserved No subtype for beacons

Retry Reserved No retry for beacons

Reserved field - -

Dest @ 0xFFFF Broadcast address

Source @ Small cell ID

Sequence Control Superframe number Increment of the 11-bit counter for modulo-2048 superframe number

Duration 0 -

More Frames 0 or 1 1: beacon is extended to the next slot

Access Method Reserved -

Table 36: Beacon frame header settings

The payload of the beacon is composed of a set of information elements which carry common and dedicated control information for UEs. Depending on the nature of the control information which needs to be transmitted in a given superframe, the content of the beacon payload may vary and an extended beacon duration may be required (indicated in the beacon frame header). The payload is composed of the IEs pertaining to the items appearing in Table 37. The related information elements are defined in section 2.4.3.

Information elements Status

Superframe description IE Mandatory

List of associated UEs IE Mandatory

Uplink and downlink resource allocation IE Mandatory

UE paging data IE Optional

Channel switching scheduling IE Optional

Quiet Period scheduling IE Optional

Association request response IE Optional

Table 37: Information elements composing the beacon payload

2.4.2.3 Control frames

Referring to the MAC header described in Table 32, the frame type field of a control frame is set to 1 and the subtype is set to a value corresponding to the control nature, as shown in Table 38.



Subtype value Type

0 ACK/NACK

1 Keep alive

2 Random access

3 Paging frame

4-255 Reserved

Table 38: Control frame subtype field values

2.4.2.3.1 Acknowledgement (ACK/NACK) frame

The payload of the ACK frame is shown in Table 39. It can group acknowledgment on a sequence of N MSDU, N being specified by the field “Number of frames”; for each frame, the “sequence control” field and the acknowledgment bit being given. The last field of the frame is the minimum value of the CQI obtained on the resource blocks of the whole channel and estimated during the last beacon reception.

Item Size Description

Number of frames

1 byte Number of MSDU considered in this ACK frame

For (i=0; i<N, i++){ 2 bytes

Sequence control 2 bytes Sequence control of the frame covered by this (N)ACK frame

ACK 1 bit 1: acknowledgment ; 0: non acknowledgment

}

CQI 1 byte Mean CQI computed on the resource blocks of the last beacon

Table 39: Acknowledgment frame payload

2.4.2.3.2 Keep-Alive frame

As described in section 2.4.5.4, a device gets from the SC the notification of a periodic emission of a “keep alive” frames during the initial attachment procedure. When in idle mode, the nodes needs to send this periodic frame aiming at letting the SC both manage the de-association of departed UEs and get periodic CQI updates from associated UEs. The payload of this control frame is only composed of the mean CQI computed on the resource blocks of the last beacon.

2.4.2.3.3 Random Access Frame

As described in section 2.4.5.6, a service establishment procedure starts with a random access procedure. It consists in the emission by the requesting UE of a “random access” control frame during the CAP part of the MAC superframe in a sub-channel part of the frequency resource dedicated to control (as opposed to the frequency resource dedicated to ACK frames). In the same way as for a ”keep alive” frame, the payload of this control frame is composed of the mean CQI computed on the resource blocks of the last beacon.

2.4.2.3.4 Paging frame

As described in section 2.4.5.6, a service establishment procedure initiated by the SC contains a paging procedure. This paging can be done either in the beacon (cf. section 2.4.2.2) or in a separate command frame sent in a dedicated downlink slot if it turns out that the beacon payload has reached



its maximum length with the mandatory information elements. The payload of the paging frame is composed of the paging IE as defined in section 2.4.3.4.

2.4.2.4 Command frames

Command frames can be uplink or downlink frames. When transmitted by the SC, a command frame is sent in the downlink part of the CFP of the superframe, possibly piggybacked with a data frame, if any. On the UE side, command frames are transmitted in the CAP of the MAC superframe, unless the beacon indicates that it has a reservation of a dedicated resource in the uplink part of the CFP. As shown in Table 33, the frame type field has to be set to “2” and depending on the command nature, the subtype field shall be set according to Table 40.

Subtype value Type

0 Association request

1 De-association request

2 Service Establishment request

3 Service Establishment request response

4 Measurement configuration request

5 Measurement configuration request response

6 Measurement report

7-255 Reserved

Table 40: Command frame subtype values

2.4.2.4.1 Association request

As shown in 2.4.5.4, an association request is sent by a UE which wants to get associated to a SC. This control frame is sent in the CAP exclusively. The payload of this frame is composed of the 6-byte MAC address of the device (48-bit Extended Unique Identifier) and the mean CQI computed on the resource blocks of the last beacon.

2.4.2.4.2 De-association request

Following the procedure shown in section 2.4.5.4, this frame can be sent by a device to initiate a de-association with a SC. The payload of the de-association request frame is given in Table 61.


De-association IE 3 bytes See section 2.4.3.10

Table 41: Payload of a de-association request frame

2.4.2.4.3 Service establishment request

This frame is sent by a device or a SC according to the procedure described in section 2.4.5.6. It can be sent either by a UE after a random access procedure or by the SC, both in the CFP of the frame. The payload of this frame is given in Table 42.


Service establishment request IE 3 bytes See section 2.4.3.7

Table 42: Payload of a service establishment request frame



2.4.2.4.4 Service establishment response

This frame is sent by a device or a SC according to the procedure described in section 2.4.5.6, after the reception of a service establishment request. It can be sent either by a UE after a random access procedure or by the SC, both in the CFP of the frame. The payload of this frame is given in Table 43.


Service establishment response IE 7 bytes See section 2.4.3.8

Table 43: Payload of a service establishment response frame

2.4.2.4.5 Measurement configuration request

This frame is used by a SC to configure a measurement to a UE or a group of UEs, for measurement items pertaining to sensing, knowing that MAC-related measurements are dealt with internal procedures and messages like shown in section 2.2.2. The payload of this frame is given in Table 44.


Measurement configuration request IE

11+ 2N bytes (for a frame sent to N UEs), see section 2.4.3.8

Table 44: Payload of a measurement configuration request frame

2.4.2.4.6 Measurement configuration response

This frame is used by a device to acknowledge a measurement configuration request sent by a SC. The payload of this frame is given in Table 45.


Measurement configuration response IE

5 bytes See section 2.4.3.12

Table 45: Payload of a measurement configuration response frame

2.4.2.4.7 Measurement report

This frame is sent by a device to report a measurement, following a prior configuration sent by the SC. The payload of this frame is shown in Table 46.


Measurement report IE 4 bytes See section 2.4.3.13

Table 46: Payload of a measurement report frame

2.4.2.5 Data frames

Data frames can be uplink or downlink frames. As far as the data frame header is concerned, the frame type field has to be set to “3” (see Table 33); depending on the directionality of the data frame, the subtype field shall be set according to Table 47.

Subtype value Type

0 Downlink frame

1 Uplink frame

2-255 Reserved

Table 47: Data frame subtype values



The payload of a downlink frame is given in Table 31. Provided this MAC design implements a centralised scheduling process, the uplink buffer state report shall be piggybacked in the payload of uplink frames like shown in Table 48. The buffer state report format is the same as the one used in LTE, which can be found in [15].


Frame payload Variable See Table 31

BSR 3 bytes Buffer state report

Table 48: Payload of an uplink data frame

2.4.3 Information elements

IE ID Information element Description

0 Superframe IE Describes the superframe structure

1 Associated devices IE Indicates the IDs of the devices which are associated

2 UE resource allocation IE Indicates the resource allocation for active UEs

3 Paging IE Indicates that a device is paged by the small cell

4 Channel Switching scheduling IE Indicates that a switch of the communication channel is scheduled

5 Quiet Period scheduling IE Indicates that a quiet period is scheduled

6 Service establishment request IE Describes the request of a service establishment

7 Service establishment response IE Indicates the acceptance or denial of a service establishment request.

8 Association request response IE Allows a small cell to confirm or deny the association request sent by a UE

9 De-association request IE Allows a device to request a de-association to the small cell

10 Measurement configuration request IE

Indicates the UE to configure a specific measurement

11 Measurement configuration response IE

Confirms the measurement configuration requested by the small cell

12 Measurement report IE Allows a UE to send a measurement report

Table 49: List of information elements

2.4.3.1 Superframe IE

The Superframe IE is used in beacons to describe the superframe length, the composing periods and their respective length. The Superframe IE is specified in Table 50.


IE ID 1 byte Set to the IE ID as defined in Table 49



Base Duration 1 byte Slot duration (value x 10µs)

COT 1 byte Superframe active periods length (in slots)

CFP 1 byte Duration of the CFP period (in slots)

CAP 1 byte Duration of the CAP period (in slots)

DL Slots 1 byte Number of downlink slots in CFP

Inactive Period 1 byte Duration of the inactive period of the frame (value x 100µs)

CAP Priority 1 byte Defines the CAP resource allocation to ACK vs. control frames (see Table 51)

CAP Sub-channel 1 byte Sub-channel bandwidth for access in CAP (in 180-kHz-wide resource blocks)

Table 50: Superframe IE

The CAP priority fields indicates how the CAP resources are subdivided and allocated respectively for ACK packets and for other control frames. The allocation is given in Table 51, knowing that the control frame part occupies the lowest part of the spectrum band.

Value Description

0 50-50% for ACK vs. control frames

1 25-75% for ACK vs. control frames

2 75-25 % for ACK vs. control frames

Table 51: Priority field values for resource allocation for ACK vs. control frame in CAP

2.4.3.2 Associated devices IE

This IE is used in beacons to indicate the identity of the associated devices. The IE format is specified in Table 52.



Length 1 byte Length of the IE (=3+2xN bytes)

N 1 byte Number of associated devices

For (i=0;i<N, i++) {

Dest @ 2 bytes Addresses of the associated devices

}

Table 52: Associated devices IE

2.4.3.3 UE resource allocation IE

The UE allocation IE is used in beacon to advertise the active UEs that some slots are allocated to them. The IE is specified in Table 53.





Length 1 byte Length of the IE (=3+6xN bytes)

N 1 byte Number of allocations

For (i=0;i<N, i++) {

Dest @ 2 bytes Addresses of the associated devices

Slot number 1 byte Slot number

MCS 1 byte Modulation and coding scheme number

Starting RB 1 byte Index of the starting resource block (RB), given the index of lowest RB in the channel is set to 0

Bandwidth 1 byte Number of RBs allocated to the user

}

Table 53: UE resource allocation IE.

2.4.3.4 Paging IE

This UE is used in beacon to notify a device that a service has to be established. The IE is specified in Table 54.



Length 1 byte Length of the IE (= 2+2xN bytes)

For (i=0;i<N, i++) { N paged UEs

Dest @ 2 bytes Addresses of the paged UEs

}

Table 54: Paging IE

2.4.3.5 Channel Switching scheduling IE

This IE is used by the beacon to notify the associated UEs about the next change of the communication channel. The notification can be triggered by a RRM notification to migrate to another channel for load balancing purpose for instance or to modify the existing channel and change the bandwidth. The IE is specified in Table 55.



Reason 1 byte Reason to switch the channel (0: Load Balancing, 1: channel reconfiguration)

Channel ID 1 byte Channel identifier (definition of channel IDs: out of scope of the document)

Bandwidth 1 byte Channel bandwidth (in MHz)

Countdown 1 byte Time before channel switching (Value x 10ms)

Table 55: Channel switching scheduling IE



2.4.3.6 Quiet Period scheduling IE

This IE is used by the SC in the beacon to schedule a period of time when it will stay quiet and no transmission will be done. This can be triggered by RRM algorithms which decide to balance the load by means of muting a group of neighbouring SCs. The IE is specified in Table 56.



Countdown 1 byte Time before channel switching (Value x 10ms)

Quiet Duration 1 byte Quiet period duration (Value x 10ms)

Table 56: Quiet period scheduling

2.4.3.7 Service establishment request IE

This IE is used by a device to request the establishment of a service once the random access is performed. It defines the level of QoS (QoS Class Indicator, QCI) the device expects, knowing that the shared nature of the channel compromises any guarantee in QoS support. The IE is specified in Table 57.



Source@ 2 bytes Address of the source node

Dest @ 2 bytes Address of the destination node

QCI target 1 byte Defines the QCI of the service request (as defined in Table 58)

TTL 1 byte Defines the time to live of the request (in 10s of ms)

Table 57: Service establishment request IE

The field “QCI target” contains the description of the expected QoS. The values are shown in Table 58; they have been chosen following the Wifi Access Classes.

Value Description

0 Background: no constraint (packet having the lowest priority)

1 Best effort: moderate constraint on throughput

2 Video: high constraint in throughput and latency

3 Voice: very high constraint in latency

Table 58: QCI values

2.4.3.8 Service establishment response IE

This IE is used by a node to notify the corresponding party about the acceptance or denial of a service establishment request. The IE is specified in Table 59.






Dest @ 2 bytes Address of the destination node

QCI target 1 byte Defines the QCI of the service request (as defined in Table 58)

Status 1 bit 0: request accepted ; 1: request denied

Table 59: Service establishment response IE

2.4.3.9 Association response IE

This IE is used by a SC to notify a device of the acceptance or denial of an association request sent by the device. The IE is specified in Table 60.



Dest 6-byte MAC @ 6 bytes 48-EUI of the destination node

Dest@ 2 bytes Short destination node address (set to 0xFFFF if failure)

Status 1 byte 0: Success

1: Fail-undetermined

2: Fail-No Enough Resource

3-255: reserved

Table 60: Association response IE

2.4.3.10 De-association request IE

This IE is used by a device to request its de-association to the SC. It may be triggered because i) it becomes short in battery (trigger of a clean de-association procedure before switching off), ii) the device is in interference-limited conditions or iii) the device is about to proceed to a cell reselection with a neighbouring cell. The IE is specified in Table 61.




Status 1 byte 0: Battery issues

1: Interference limitation

2: Leaving the cell

3-255: reserved

Table 61: De-association request IE

2.4.3.11 Measurement configuration request IE

This IE is used by the SC to trigger the configuration of measurements to be performed by a device or a group of devices. The IE is specified in Table 62, knowing that the measurement configuration relates to sensing measurements, done using an energy detection.



Measurement ID 2 bytes Identification of the measurement



Measurement type 1 byte 0: RSSI

1: SINR

2-255: Reserved

Band ID 1 byte Identification of the band ID

Channel ID 1 byte Identification of the channel ID

Duration 2 bytes Duration of the measurement in µs

Type 1 byte 0: Periodic

1: Threshold-based

2: On demand

3-255: Reserved

Type parameter 1 byte Value of the period expressed in number of superframe or

Value of the threshold or

Countdown for on-demand measurement

Filtering process 1 byte 0: No averaging

2-255: Value of the averaging window.

For (i=0;i<N, i++) {

Dest @ 2 bytes Addresses of the UEs. If only one address is set to 0xFFFF: request is sent to all the UEs.

}

Table 62: Measurement configuration request IE

2.4.3.12 Measurement configuration response IE

This IE is used by a device to notify the SC that a measurement configuration request has been accepted or rejected. The IE is specified in Table 63.




Measurement type 1 byte 0: RSSI

1: SINR

2-255: Reserved

Status 1 byte 0: Confirmed

1: Rejected – Not specified

2: Rejected – band not supported

3: Resource limitation (for averaging)

Table 63: Measurement configuration response IE

2.4.3.13 Measurement report IE

This IE is used by a device to notify the SC that a measurement configuration request has been accepted or rejected. The IE is specified in Table 64.






Value 1 byte Measured value

Table 64: Measurement configuration response IE

2.4.4 MAC constants

The FBMC MAC layer constants are given in Table 65.

Parameter Description Value

SuperframeDuration Maximum superfraùe duration 10 ms

MASDuration Medium Access Slot Duration 500 μs

MinCAPSlot Minimum number of slots in CAP 1

MaxCFPUL Maximum number of slots in UL CFP 4

MaxCFPDL Maximum number of slots in DL CFP 8

CSMASlotTime Contention access slot duration (for CSMA) 9 µs

CWmin Minimum size of contention window for LBE 15

CWmax Maximum size of contention window for LBE 1023

MaxLBECCASlots Maximum e-CCA priority (mp) 7

LBEDurationTf Tf duration in LBE (equivalent to SIFS) 16 µs

minFBECCATime Minimum LBT duration in FBE 20 µs

minFBEIdlePeriodRate Minimum FBE idle period proportion 0.05

MaxLostBeacons Maximum number of lost beacons 3

MacMaxFrameRetries Maximum number of frame retries 3

Broadcast_Identifer Identifier for broadcast packet (address field) 0xFFFF

MaxAssociatedDevices Maximum number of associated devices 32

MaxActiveUsers Maximum number of active devices 16

Table 65: FBMC MAC constants

2.4.5 FBMC MAC procedures

This section deals with specific procedures of FBMC MAC design as a complement of the generic signalling procedures between MAC and higher layers shown in Appendix C. Generally speaking, the procedures in this section describe messages exchanged between HMAC and LMAC (and PHY) in order to enable the operation of FBMC MAC. These procedures are:

Data transmission

Channel (re-)configuration)

Paging

Traffic steering and offload.

FBMC air interface initiation



Device association and de-association

Service request (network and device triggered)

LMAC/PHY (re-)configuration

2.4.5.1 FBMC air interface initiation procedure

This procedure is invoked to initialize the FBMC air interface, either in a single RAT or in a multi RAT mode. The start of the FBMC air interface relies on the selection of a channel (see section 2.4.5.2), the configuration of the MAC layer (see section 2.2.3) and the emission of beacons by the SC. Shown in Figure 60, this procedure is triggered by RRC, which sends to the HMAC the command of starting the air interface, for instance at RRC (re)configuration stage. Once this procedure is completed, the SC waits for association requests sent by devices (see section 2.4.5.4); prior to this stage, a communication channel has to be selected according to the channel selection procedure (see section2.4.5.2) and the LMAC shall be configured in accordance. It is worth noting that the request of RRC may include guidelines both on channel selection (giving for instance a list of preferred channels) and LMAC configuration (for instance giving a default MAC superframe configuration).

Figure 60: FBMC air interface initiation procedure

2.4.5.2 Channel configuration procedure

As stated previously, this procedure corresponds to the identification of a communication channel for the FBMC air interface. The channel identification is performed when the FBMC air interface is started and it may be done using a set of parameters like band identification, bandwidth, preferred channels or forbidden channels. These parameters are known by the HMAC either because they are default parameters or because they have been sent by the RRM in previous messages (like traffic steering configuration, for instance).

The channel identification, shown in Figure 61, is done by performing a spectrum sensing on the identified band, respectively focusing and avoiding the preferred and forbidden channels if such lists are provided by the RRM entity. The sensing results are sent by the PHY back to HMAC where the sensed received power(s) are compared with the sensing threshold to assess whether one or several channels can be used. In the case no channel is available, HMAC reports back to RRM an indication of the channel identification failure. Optionally RRM can ask for the received power in the different channels sensed by the PHY, using a request/response primitive on the monitoring plane (M_cRRM_HMAC SAP). If at least one channel is deemed as available, HMAC picks one of them, which will be the channel of the secondary carrier; this is reported as such by an indication from HMAC to RRM (arrow n°4 in Figure 61).



Figure 61: Channel selection procedure

2.4.5.3 Channel reconfiguration procedure

This procedure is required when the operating channel has to be changed. The trigger for this procedure can be of different kinds. It can be requested by a RRM entity for interference management on a group of cells achieved by balancing the load over a set of available channels. It can also be triggered by a HMAC decision if it appears that the coexistence with other systems operating on the same channel leads to a poor performance (latency or throughput) level. This procedure implies two steps, which are in one hand a channel (re)selection process and in the other hand the notification to the attached devices that the channel is about to change; these steps are captured in Figure 62 and Figure 63. The notification of the devices served by the SC is done in the same way as in [9], using information element included in the beacon that indicates i) the new operating channel and ii) a countdown before the channel switch happens.



Figure 62: Channel reconfiguration procedure on the small cell side

Figure 63: Channel reconfiguration procedure on the UE side



2.4.5.4 Device association and de-association procedures

This subsection relates to the generic procedures described in section C.1 and details the different steps which appear as MAC specific in Figure 122 and Figure 124.

Device association

The first step of this procedure (Step #1 in Figure 122) happens when the FBMC air interface is switched on at the UE side and the latter starts scanning the spectrum, seeking for a beacon sent by a neighbouring SC. When the synchronisation on a beacon is achieved, LMAC indicates to HMAC that a beacon is received.

Figure 64: FBMC procedure for beacon discovery (step #1 of Figure 122)

After the step #1 depicted in Figure 64, HMAC sends to RRC an indication of this beacon reception, providing RRC with the System information it would have retrieved in the beacon frame (SC ID, operator’s name) and let RRC proceed to the RRC connexion request, as shown in Figure 122. This triggers the step #2 which corresponds to the FBMC MAC association procedure depicted in Figure 65. HMAC sends an association request to LMAC which triggers the emission of an association command in the CAP of the FBMC MAC frame.

Figure 65: FBMC procedure for device association request (step #2 of Figure 122)

Upon reception of this command frame, the SC HMAC is notified by the FBMC LMAC that an association is requested by a device. HMAC sends an indication of this request to RRC and RRC starts a RRC connexion setup (see Figure 122), which triggers step #3, depicted in Figure 66. In this step, SC appends the device ID in the list of devices contained in the “Associated Devices IE” in the beacon; when synchronising on this beacon, the device can complete association with LMAC sending to HMAC an association confirmation. Note that in the information element of the association setup sent by the SC and included in the beacon, a periodic measurement report is indicated, to act as a “keep alive” signalling or a Tracking Area Update like in LTE procedures [11]. The completion of this step triggers the RRC connexion completion between the HMAC and RRC of the UE, which appears in



Figure 122

Figure 66: FBMC procedure for device association response by small cell (step #3 of Figure 122)

Device de-association procedure

This procedure relates to the MAC specific steps of the generic detachment procedure described in section C.1. As stated previously, the generic procedure can be initiated either by the device or the SC, depending on the triggering event. This procedure is performed by an indication of HMAC towards RRC at the originator side, after specific MAC steps. The FBMC specific triggering procedures are shown in Figure 67 in the case of the detachment is initiated by the SC or the device.

Figure 67: FBMC procedure for device de-association

2.4.5.5 Paging procedure

Figure 68 shows the MAC specific steps of the paging procedure. The paging control data is transmitted by the SC and the timer is started by the SC LMAC. If the cell doesn’t get any response from the UE before the timer expires, the paging is considered a failure. If the UE properly receives the paging control data, it sends back a control frame in the CAP after an interaction with RRC in order to order to ask for a RRC connection setup. Note that if 3 consecutive failures are experienced by the cell, the device will be de-associated.



Figure 68: Paging procedure

2.4.5.6 Service establishment request procedure

Figure 69 and Figure 70 show how a UE can initiate a service establishment with a SC. This procedure assumes that the device is associated with the SC and is in RRC_IDLE mode. The complete procedure involves an interaction between RRC entities to establish a dedicated radio bearer (see section C.4.1) but the following concentrates only on MAC specific steps, which are indicated as such in Figure 126.

Figure 69 presents the first steps of the procedure in which the UE performs random access in order to ask for a RRC connection and the response of the SC to set it up. The UE initiates the procedure by sending a random access control frame, following the procedure of sending control data in the CAP of the superframe (see section 2.4.5.7.1) and it starts a timer. If the UE doesn’t get any response from the SC before the timer expires, the random access procedure is deemed as failed at the UE side. If the random access frame is received at the SC side (using the control data retrieval procedure



in section 2.4.5.7.2), the HMAC interacts with RRC which can either accept or reject the RRC connection request.

Figure 69: UE-initiated service request (Random Access step)

In the case where the SC accepts the RRC connection request, the device can initiate the service request by means of a control frame sent either in the CAP or in the CFP, depending on the choice made at the SC side (and indicated in the beacon). In the same way as for the random access, this request is processed at the SC side, involving and interaction with higher layers entities and RRC to set up the dedicated bearer if the service request is accepted. In the case the request is denied, the notification is sent to the UE as an information element in the beacon. In the case where the request is accepted, the SC sends the acceptance notification and the RLC and MAC configurations. In Figure



70, the procedure is completed by the UE MAC configuration, reported as such to the SC thanks to control data transmission, which triggers the cell MAC configuration in return. At this stage, the bearer is established and the device is in RRC connected mode.

Figure 70: UE-initiated service request (Service establishment step)



As detailed in Appendix C.4 the service establishment request can be initiated by the SC. In this case, the procedure is almost the same as its UE-initiated counterpart except it starts with a paging procedure triggered by RRC.

2.4.5.7 Signalling data transmission procedure

2.4.5.7.1 Control signalling management at UE side

The first procedure relates to how a device can send signalling data to the SC given that the basic mode relies on using the contention access period of the MAC frame. This is shown in Figure 71 where an interaction with RRC layer triggers the transmission of a signalling message towards LMAC for the emission of a control frame in the CAP. This control frame can be for instance a RRC connection request, an association or a response to a paging. When a beacon is received at the PHY layer, the LMAC locates the boundary of the CAP and performs the contention access algorithm (CSMA/CA). When the transmit opportunity is found, the LMAC sends the frame to the PHY which sends it over the air.

Figure 71: Procedure of UE sending control data in CAP

Alternatively, the SC can ask the device to send the control frame in the contention free period. This can be the case when the CAP resource do not suffice given the number of connected devices for instance. In this case, the only difference with the previous procedure is in the fact that the UE reads in the beacon if it has allocated resource and performs the transmission accordingly. This is captured in Figure 72.



Figure 72: Procedure of UE sending control data in CFP

The second procedure depicts how a device can retrieve control data sent by the SC. This is shown in Figure 73 where LMAC extracts from beacon the information elements of the control frame and forwards them to HMAC. Note that the control frame can be transmitted in a dedicated resource downlink allocation; in this case, the control frame will be reported to HMAC after being processed at the LMAC level.

Figure 73: Procedure for retrieving control data at UE side

2.4.5.7.2 Control signalling management at Small cell side

This section is the counterpart of the previous section as it deals with how a SC manages the emission and reception of control data. The main characteristic of this MAC design is in the use of the beacon to carry most of the downlink control traffic. It carries for instance paging notifications, RRC connection setup and reconfiguration, as well as resource allocation or radio link control for uplink traffic. This is shown in Figure 74.



Figure 74: Procedure of Small cell sending control data in beacon

Figure 74 shows the transmission of control data in the beacon and depicts in particular the LBT operation prior to any superframe emission. For the sake of readability, this figure assumes that there is no dedicated traffic being sent in the downlink contention free period leading to the emission of the beacon only. If there is on-going downlink traffic, Figure 74 would be combined with the section below which deals with the management of user data.

As far as control data reception is concerned, there is no specific procedure provided that this corresponds to a regular packet reception; the only specific part relies in the fact that LMAC extract the control nature of the packet by decoding the information elements and forwards the content to HMAC for further processing, as shown in Figure 75.

Figure 75: Procedure for retrieving control data at small cell side



2.4.5.8 Data transmission procedure

The following procedure describes how the SC manages the frame emission in unlicensed spectrum together with resource allocation for the active UEs. A buffer status update from RLC to HMAC is shown at the beginning of the procedure, even though it does not condition the execution of this procedure. It has been represented for the sake of consistency, given the procedure described in this section involves access to logical channel buffers at RLC level.

The frame emission process is triggered by a HMAC message (SchedFrameTrigger.request) which provides the buffers status of the active logical channels to LMAC. When receiving this message, a CCA procedure is invoked by the LMAC to comply with the ETSI regulation. The CCA is requested to PHY which in return provides the level of energy sensed in the channel. The procedure shown in Figure 76 implements the frame-based access, as reported previously in D5.1 deliverable, for which a negative CCA postpones the frame emission until the next CCA opportunity. Once the channel has been deemed idle, a frame can be sent by the SC, implying the scheduling of resources for active UEs, as a function of their MCS and the scheduling policy. At LMAC level, the scheduler computes the transport block sizes for each logical channel, maps them on the frame downlink slots and fetches them from RLC using a request/response primitive. This allocation is also reported in the beacon, transmitted in the first slot of the frame. On a per downlink slot basis, the data frame is passed to the PHY for its emission over the air.



Figure 76: Small cell data transmission procedure



As far as uplink traffic is concerned, the FBMC MAC design relies on a centralised approach where the SC allocates resource to UEs and notifies them about the time frequency resource allocation. The uplink transmission procedure is shown in Figure 77, which is triggered by the reception of a beacon containing an information element indicating that resources are allocated to the UE. Upon reception of the beacon, the LMAC computes the transport block size according to the amount of allocated resources and the MCS given by the SC. The LMAC gets from RLC both the data and the buffer status thanks to a bi-directional message exchange and provides PHY layer with this information to send this packet in the indicated time and frequency resource. Note that a CQI update has to be piggybacked in this message, which is computed on the beacon reception.

Figure 77: Uplink data transmission

The counterpart of the data transmission procedure is the packet acknowledgment, which is shown in Figure 78 from the UE perspective. The procedure starts with the reception of a data frame at the PHY layer, which is forwarded to the LMAC after decoding, using the PHYFrameReceived.indicate message. If the data packet is received with no error, the packet is forwarded to the RLC on the data plane and an ACK packet is prepared in order to be sent in the acknowledgment slot at the end of the superframe. In parallel, the CQI update is forwarded to the HMAC to be stored in the KPI and Sensing management entity. In the case of the reception of a NACK, the procedure is the same except the interaction with RLC layer.



Figure 78: Uplink packet reception and acknowledgment

2.4.5.9 Reconfiguration procedures

In FBMC-MAC, the LMAC reconfiguration is handled by HMAC using the generic primitive LMACconfiguration.request (described in section A.1.12) indicating FMBC-MAC specific parameters. Depending on the case, (whether reconfiguration affects all UEs or a specific UE) the reconfiguration information can be sent using common IE in the beacon or using a dedicated IE in a scheduled DL transmission, as shown in Figure 79. Reconfiguration of common parameters which have to be applied by all UE can be for instance the frame configuration using the Superframe IE (cf. section 2.4.3.1); it can also be the channel reconfiguration (cf. section 2.4.5.3) or the scheduling of a quiet period using the corresponding IE (cf. section 2.4.3.6). Examples of reconfiguration affecting a given UE can be an updated measurement configuration request the corresponding IE in a control frame appended to a dedicated data frame (if any) in a dedicated DL scheduled packet.



Figure 79: Reconfiguration procedure

2.4.5.10 Carrier aggregation procedure using a FBMC secondary carrier

According to the generic procedure described in section 2.2.4, the aggregation procedure is performed whenever the RRM entity decides to steer some traffic of a logical channel on a secondary FBMC carrier, assuming an active primary carrier is active.

According to Figure 9, the steering decision received at HMAC from RRM entity may spark the activation of the FBMC air interface at the SC side. This is performed following the procedure described in section 2.4.5.1, which includes the channel selection procedure (see section 2.4.5.2). Among the elements contained in the steering request of RRM, a number of parameters are used by the channel selection procedures: band identification and a list of preferred and forbidden channels. They may speed up the channel selection procedure by restricting the amount of scanned channels. Once the channel is selected, the RRC reconfiguration procedure appearing in 2.2.4 allows informing a UE to switch on the FBMC air interface. As it has been already noted, the RRC reconfiguration request sent to the UE includes the FBMC channel, in order to facilitate the beacon detection and the attachment procedure. In the case the SC had an active FBMC air interface prior to the offload request but on a channel which doesn’t fit with the RRM recommendations (in terms of bandwidth, for instance), so a channel reconfiguration procedure is invoked, as described in section 2.4.5.3. A RRC reconfiguration request can still be sent to the UE, whenever the latter needs to initiate its FBMC air interface, like in the previous case. At the UE side, if the procedure has involved RRC reconfiguration to switch on the FBMC air interface, an association procedure is performed, like shown in section 2.4.5.4.

Finally, the data transmission on the FBMC air interface can occur following the procedure described in section 2.4.5.8.

2.5 eDSA MAC Primitives

The following tables depict lists of primitives implemented for the eDSA MAC design. Each table shows the SAP on which those primitives can be exchanged and who the sender and receiver entities are. The details column of each table indicates a reference to the section, where the details of the primitives have been described.



2.5.1 C_5GRRC_HMAC SAP

Primitives Sender->Receiver Details

TrafficSteeringConfig.request 5G-RRC -> HMAC See A.1.1

CellMACConfiguration.request 5G-RRC -> HMAC See A.1.2

CellMACConfiguration.confirm HMAC -> 5G-RRC See A.1.3

MeasurementConfig.request 5G-RRC -> HMAC See A.1.4

MeasurementConfig.confirm HMAC -> 5G-RRC See A.1.5

2.5.2 M_cRRM_HMAC SAP


ChannelIdentification.indicate HMAC -> cRRM See A.1.9

Measurement.request cRRM -> HMAC See A.1.6

Measurement.confirm HMAC -> cRRM See A.1.7

Measurement.indicate HMAC -> cRRM See A.1.8

2.5.3 C_HMAC_LMAC SAP

2.5.3.1 Generic MAC Primitives


HLSignalingMessage.request HMAC -> LMAC See A.1.10

HLSignalingMessage.indicate LMAC -> HMAC See A.1.11

LMACConfiguration.request HMAC-> LMAC See A.1.12

LMACConfiguration.confirm LMAC-> HMAC See A.1.13

LMACConfiguration.indicate LMAC-> HMAC See A.1.14

Measurement.request HMAC -> LMAC See A.1.17

Measurement.confirm LMAC-> HMAC See A.1.18

Measurement.indicate LMAC-> HMAC See A.1.19

2.5.3.2 Specific FBMC-Based MAC Primitives


LMACStart.request HMAC -> LMAC See A.2.1

BeaconReception.indicate LMAC -> HMAC See A.2.2



Association.request HMAC-> LMAC See A.2.3

Association.confirm LMAC-> HMAC See A.2.4

Association.indication LMAC-> HMAC See A.2.5

De-association.indication LMAC-> HMAC See A.2.7

UEPaging.request HMAC -> LMAC See A.2.7

UEPaging.response LMAC-> HMAC See A.2.8

SchedFrameTrigger.request HMAC -> LMAC See A.2.9

SchedFrameTrigger.confirm LMAC-> HMAC See A.2.10

2.5.3.3 Specific DCS-Based MAC Primitives


RadioBearerEstablish.request HMAC -> LMAC See A.3.4

RadioBearerEstablish.confirm LMAC -> HMAC See A.3.5

RadioBearerEstablish.indicate LMAC -> HMAC See A.3.6

RadioBearerRelease.request HMAC-> LMAC See A.3.7

RadioBearerRelease.confirm LMAC-> HMAC See A.3.8

RadioBearerRelease.indicate LMAC-> HMAC See A.3.9

SchedTransmission.request HMAC -> LMAC See A.3.10

SchedTransmission.confirm LMAC-> HMAC See A.3.11

2.5.4 C_HMAC_PHY SAP


Measurement.request HMAC -> PHY See A.1.20

Measurement.confirm PHY -> HMAC See A.1.21

2.5.5 C_LMAC_PHY SAP

2.5.5.1 Generic MAC Primitives

Messages Sender->Receiver Details

PHYConfiguration.request LMAC -> PHY See A.1.15

PHYConfiguration.confirm PHY -> LMAC See A.1.16





PHYPerformCCA.request LMAC -> PHY See A.2.16

PHYPerformCCA.confirm PHY -> LMAC See A.2.17



ChannelMeasurement.request HMAC -> LMAC See A.3.17

ChannelMeasurement.confirm LMAC-> HMAC See A.3.18

2.5.6 M_HMAC_PHY SAP



PerformSensing.request HMAC -> PHY See A.2.21

PerformSensing.confirm PHY-> HMAC See A.2.22

2.5.7 C_5GRLC_HMAC SAP


RLCBufferStatus.request 5G-RLC -> HMAC See A.1.22

2.5.8 D_5GRLC_HMAC SAP


RLCData.indicate LMAC -> 5G-RLC See A.1.23

RLCData.response 5G-RLC -> LMAC See A.1.24

2.5.9 D_LMAC_PHY SAP



PHYFrameTransmit.request LMAC -> PHY See A.2.18

PHYFrameTransmit.confirm PHY -> LMAC See A.2.19

PHYFrameReceive.indicate PHY -> LMAC See A.2.20





PHYFrameTransmit.request LMAC -> PHY See A.3.14

PHYFrameTransmit.confirm PHY -> LMAC See A.3.15

PHYFrameReceive.indicate PHY -> LMAC See A.3.16



3 eDSA MAC Simulations

3.1 Introduction

This section presents the system-level simulation scenarios, parameters, and evaluation metrics for assessing the performance of the proposed MAC designs. More specifically, the performance results of DCS-MAC design for ultra-dense networks and FBMC-MAC design for broadband traffic operating in 5G unlicensed bands are investigated. The final objective of this work is to provide a set of guidelines to select one or the other MAC design depending on the context of operation, whether it pertains to network density, traffic pattern or possible coexistence with other systems when operating unlicensed spectrum. In addition, this chapter contains a PHY/MAC analysis to determine the suitable parameters of the FBMC physical layer, also depending on the simulation parameters.

3.2 Methodology

This section provides an overview of how the system level simulations have been set-up. They have been essentially performed following a 3-step approach:

- Step 1: System level simulator calibration: this step is necessary to verify that the simulators are aligned and provide comparable results.

- Step 2: Definition of a common set of performance metrics.

- Step 3: Definition of common simulation assumptions: both MAC designs implement a reference set of parameters, called baseline, which is used to compare the 2 proposed MAC designs in similar conditions. The 2 MAC designs are be simulated on optional parameters which prolong the baseline with more sophisticated models.

3.2.1 System level simulators calibration

In order to get comparable results coming from the two MAC designs which are evaluated on different software platforms, an important step is to proceed with the calibration of simulation platforms. This calibration consists in checking whether channel models and device association are applied in a similar way on both simulators, by comparing fundamental metrics on a given network layout and traffic distribution. The main simulation parameters considered in the calibration are listed in Table 66.

Parameters Values

Deployment types Outdoor deployment – UMi [3GPP TR.814]

Duplex method TDD

Downlink/Uplink transmission scheme 1 × 1 SISO

Network layout Hexagonal grid, 1 sector by side

Inter-site distance (ISD) 100 m

Wrap-around / # rings Yes, radio-distance based WA / 2rings

Carrier frequency 5 GHz

System bandwidth per carrier Unlicensed (20 MHz)

Path loss model ITU-R UMi based model

Shadow fading model Uncorrelated lognormal shadowing sigma = 3dB (LOS) / 4dB (NLOS)

Fast-fading model Not considered



Minimum (2D) distance 3 m (UE-UE, UE-BS)

Inter-cell interference modelling Explicit

UE distribution Uniform distribution

UE Mobility Not considered (0 Km/h)

UE/BS Tx power 20 / 24 dBm

UE/BS Antenna pattern 2D Omni-directional

UE/BS Antenna height 1.5m / 10 m

UE/BS Antenna Gain BS: GTX = GRX = 5 dBi UE: GTX = GRX = 0 dBi

UE/BS Noise Figure 9 dB / 5 dB

Thermal noise spectral density -174 dBm/Hz

DL/UL traffic ratio 100% DL, 100% UL, 50%DL +50%UL

DL/UL Scheduler Round Robin

User association Strongest RSSI

Table 66 - Parameters for calibration of system level simulators

In the first step, coupling gain and downlink wideband SINR distributions have been evaluated and compared. The coupling gain is defined as the average signal gain between a UE and its serving cell. It includes distance attenuation, shadowing and antenna gains. The downlink wideband SINR is the ratio of the average power received from the serving cell and the average interference power received from other cells plus noise.

In a second step, uplink SINR distributions in the case of a scenario where 100% of the traffic is uplink and uplink and downlink SINR distributions in the case of a “50% downlink and 50% uplink” scenario have also been evaluated and compared. In case of the uplink scenario, one user per cell is assumed to transmit at a time. The uplink SINR is the ratio of the average power received from the UE and the average interference power received from other UEs in other cells plus noise. In case of 50% UL and 50% DL scenario, one user per cell is assumed to transmit or receive at a time with a probability of 0.5. In this case, cross link interference have to be considered. The uplink SINR includes SC-to-SC interference, and downlink SINR includes UE-to-UE interference.

Figure 80 - Distributions of coupling gain.

-110 -100 -90 -80 -70 -60 -50 -400

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1

CD

F

Coupling gain (Prx - Ptx) [dB]

CEA

UNIS



Figure 81 - Distributions of downlink and uplink SINR for 100% DL traffic, 100% UL and (50 % UL, 50% DL).

Figure 80 and Figure 81 show the cumulative density functions (CDFs) of the coupling gain and

downlink and uplink wideband SINRs for different traffic scenario, respectively. The comparison of

the results obtained with the 2 simulators shows that they are perfectly aligned. More distributions

and statistics have been compared to prove the calibration of the simulators. In particular, statistics

on how the different links are distributed along Line-of-Sight (LOS) and non LOS (NLOS) propagation

conditions have been compared to prove that the LOS/NLOS generation is indeed similar on both

simulation platforms. Table 67 summarizes the obtained results on this aspect for “small-cell to small

cell” (SC-SC), “UE to small cells” (UE-SC) and “UE to UE” (UE-UE) links.

Links CEA UNIS

SC-SC 33.7 % 33.3 %

UE-SC 36 % 35.7 %

UE- UE 23.8 % 23.8 %

Total LOS 32.5 % 32.2 %

Table 67: LOS statistics for all links

The presented results of different simulators are aligned and prove that the simulators have been well calibrated and are able to produce comparable results.

-10 -5 0 5 10 15 20 25 30 35 400

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1

Wideband SINR (geometry-100% DL) [dB]

CD

F

CEA

UNIS

-30 -20 -10 0 10 20 30 40 500

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1

Uplink SINR (100%UL) [dB]

CD

F

CEA

UNIS

-40 -30 -20 -10 0 10 20 30 40 500

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1

Downlink SINR (50%UL, 50%DL) [dB]

CD

F

CEA

UNIS

-30 -20 -10 0 10 20 30 400

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1

Uplink SINR (50%UL, 50%DL) [dB]

CD

F

CEA

UNIS



3.2.2 Performance metrics

The following set of performance metrics has been considered to evaluate the system performance.

- Per-UE throughput

- Per-cell throughput

- Area network throughput

- Transmission delay

- Fairness

- Control traffic overhead

Per-UE throughput is a very common metric, considered to evaluate how much data rate can be served to UEs. The per-UE throughput at 5, 50, 95 percentile of throughput CDF curve has been considered to measure cell edge, average and cell-center throughput performance, respectively. For full buffer situation, the per-UE throughput is defined as the ratio of the number of bytes successfully received over the given simulation time, whereas in case of bursty traffic, the per-UE throughput is obtained by averaging the throughput obtained on the different bursts (not considering the inter burst duration). The per-cell throughput is also considered to evaluate the total capacity of the small cell; it is obtained by averaging for all the SCs the correctly received data with respect to the simulation duration. An iinteresting metric for regular layout like the hexagonal grid is the Area network throughput, which is obtained with the sum of the per-cell throughput values and divided by the area of the network. In order to compare 2 MAC designs assuming different PHY capabilities for each of them, these 3 throughput metrics can be normalized by the signal bandwidth, in order to derive throughput-per-Hz metrics.

Another important metric for the evaluation of the performance of the MAC layer is the transmission delay, which is the averaged time required to successfully deliver a packet once it is at the head of the MAC queue. This delay therefore includes the time required to retransmit the packet according to HARQ process, if necessary. This transmission delay is a relevant KPI when dealing with full buffer conditions. When a bursty traffic is considered, the queuing delay which corresponds to the delay between the creation of the packet in the application buffer and the moment it enters the MAC queue, is another important metric. However, in the simulations run in Speep-5G system level simulators, the management of higher layer buffers is not sufficiently realistic to monitor the queuing delay.

Fairness metric is used to determine whether users or applications are receiving a fair share of system resources. Scheduling of resources is considered fair if it does not exhibit preference to any single node when multiple nodes are trying to access resources. In order to measure fairness we propose to use Jain’s fairness Index. The fairness of channel occupancy, user throughput and cell throughput will be investigated.

Control (frames) overhead is used to quantify the control overheads associated with MAC designs, defined as the ratio between the resource used for control and the resources used for data. This metric is representative of the efficiency of a protocol as an ideal protocol would have the control overhead tending towards a minimal value.

3.2.3 Common simulation parameters

This section details the common simulation parameters considered for the evaluation of DCS MAC and FBMC MAC designs. They are listed in Table 68, where the baseline mention indicates that the related parameters which will be used to compare the 2 designs on the same configuration. In the same idea, the option mentioned covers cases on which MAC designs can be further evaluated on more realistic situation but with no comparison perspective.



3.2.3.1 Deployment assumptions

From a deployment standpoint, the simulations rely on an outdoor hexagonal grid which is composed of 3 rings like shown in Figure 82.

Figure 82: 3-ring hexagonal grid model

Although a 3-ring model only represents a finite area, it can be tuned to mimic a very large network by considering the wrap-around of the network [19]. Wrap-around helps in mitigating the issue of imbalanced interference conditions among the cells in the different rings of the network as outer rings would experience less interference than the inner ring. Therefore, it provides a very efficient way to dramatically reduce the simulation durations of a large scale network, reducing it to one of its subset. Wrap around is obtained by replicating the hexagonal pattern and by placing 6 virtual copies of it around the original network, replicated cells having the exact same configuration than the original one), like shown in Figure 83 for a 2-ring model.

Figure 83: Wrap-around in a 2-ring hexagonal grid, showing the impact on cell n°13 by one of the 7 instances of cell n°7.



Table 68: Simulation parameters for MAC designs comparison

Assumption

100 seconds

EXTENDED UMi (Urban micro-cell scenario) [16]

TDD

1×1 SISO

Hexaganonal grid, 1 sector by side

yes /3 rings

30 m, 50 m, 100 m

5 GHz

20MHz

random distribution WITH a condition on the maximum number of UEs per BS

Baseline: 10 UEs per BS

Optional: more than 10

Small cell-UE, UE-UE: 3m

Strongest RSSI ( pathloss + shadowing)

Round robin with full bandwidth allocation

Round robin with full bandwidth allocation

24 dBm (ISD = 100m) - 12 dBm (ISD = 50m) - 9 dBm (ISD = 30m)

20 dBm (ISD = 100m) - 8 dBm (ISD = 50m) - 5 dBm (ISD = 30m)

2D Omni-directional

10 m (ISD= 100, 50m) 6m (ISD=30m)

1,5 m

5 dBi

0 dBi

EXTENDED ITU-R UMi based model with 3D distance between an eNB and a UE

None

Correlated and non correlated lognormal shadowing with sigma = 3dB (LOS) / 4dB

(NLOS)

Baseline: no fast fading

Option: Uncorrelated TU channel model (NLOS) and direct path Rician factor K = 6

dB (LOS)

Not considered ( 0 Km/h)

9 dB

5 dB

- 174 dBm/Hz

Baseline: 100% DL

Optional: 80% DL +20% UL

1500 Bytes

Saturated model

File size S = 0,5 Mbytes

Reading Time D : Exponential distribution, Mean = 5 sec, 2sec , 1sec

Full buffer: 0 (no retransmission)

FTP: infinite

Explicit

Baseline: no-adjacent channel leakage

Options: adjacent channel modeling

i) FBMC K=4, no leakage

i)FBMC K = 2, adjacent channel leakage = -44 dB/20MHz

ii)OFDM-LTE, adjacent channel leakage = -37 dB/20MHz

Baseline: reuse=1 (all cells on the same frequency)

Option: reuse=3 (regular allocation of cell frequency on 3 frequencies)

Mutual Information Effective SNIR Mapping (MIESM)

10%

4-QAM, 16-QAM, 64-QAM [CQI = 1:15]

Inter-cell interference modeling

inter-channel interference modeling

LTE Link to system interface

Target BLER

Basic modulation - CQI

Frequency pattern

Interferer systems

BS Noise Figure

Thermal noise spectral density

Traffic model

DL/UL traffic ratio

Application layer packet size

Full buffer

FTP traffic

MAC level max number of packet

retransmissions

UE Noise Figure

Antenna height (BS)

Antenna height (UE)

Antenna gain (BS)

Antenna gain (UE)

Channel model

Distance-dependant path loss

Penetration Loss

Shadow fading model

Channel fading model

UE Mobility

Antenna pattern

Carrier frequency

Total system bandwidth

UE distribution

UE density/drops

User association

Minimum distance (2D distance)

Downlink scheduler

Uplink scheduler

BS Tx power

UE Tx power

Inter-site distance

Parameter

Simulation run time

Deployment

General

Duplex method

Downlink/Uplink transmission scheme

Network Layout

Wrap-around / # rings



From a channel model standpoint, the simulations use an extension of the Urban Micro (UMi) model from the ITU-R [16], to which a spatial correlation of the LOS/NLOS correlation and the shadowing correlation have been added in order to better capture the nature of dense networks. Indeed, given that ISD can be as small as 30 meters; this correlation is meant to bring a more realistic network behaviour since 2 nodes close one to the other should have a link with the SC with an identical LOS/NLOS probability. The same applies to the shadowing distribution. The correlation model applied to LOS/NLOS distribution is explained [21].

3.2.3.2 Traffic type models

From a traffic pattern model perspective, a 100% downlink traffic is used as the baseline for comparison, knowing that a mix of 20 % uplink and 80% downlink traffic can be considered as well for further MAC design evaluation. In this latter case, assumption is made that 20% of the nodes (resp. 80%) in a cell are having only uplink traffic (resp. downlink) and not 20% (80%) of the nodes of the network.

In both cases, two traffic types are considered: saturated traffic where nodes always have a packet in the transmission queue (as known as “full buffer” model) and bursty traffic. For the latter case, we use a FTP model 2 derived from [16] with parameters as shown in Table 69.

Parameters Statistical characterizations

File Size S 0.5 Mbytes

File inter-arrival Time D

Exponential distribution, mean = {1;2;5} seconds

Table 69: FTP Traffic Model 2

Compared to the saturated model, FTP traffic type allows evaluating the performance of the MAC designs under variable traffic density and time-varying interference conditions. The file inter-arrival time (also referred to as reading time) D is the time interval between end of download of previous file and the user request for the next file.

3.2.4 Interference modelling

Given that the simulation assumptions address small ISD values, the explicit modelling of inter-cell interference is important as it makes is possible to finely capture the impact of neighbouring cells on the performance degradation as a function of ISD.

The interference modelling considers 2 cases which are either a deployment with a frequency reuse factor of 1 or a reuse factor of 3. In the first case, all cells use the same frequency channel which means the signal-to-interference is computed as the ratio between the received power of the packet of interest and the sum of the powers of all simultaneous emissions in the neighbouring cells. In the other case, 3 adjacent channel frequencies are used with a regular pattern leading to a frequency allocation so that no contiguous cells share the same channel. Adjacent channel interference can be modelled using the approach depicted in section 3.4.1.3 where out-of-band emissions masks are applied to take into consideration the impact of emissions in adjacent channels on the SINR computation. Specific masks for the considered underlying PHYs (e.g. FBMC or OFDM) are defined which allows some PHY/MAC analysis.

3.2.5 Modelling coexistence with “WiFi” systems

Since an important feature of the 2 MAC designs is the ability to operate in shared spectrum, coexistence with other systems within the same channel or in an adjacent channel is considered. In this perspective, we consider the deployment of a LBT-based system implements a simplified Wifi



DCF-MAC protocol as depicted in Figure 84. The system simulations only focus on the emission part of “Wifi-like” system, in order to derive the fairness of the channel access of both SPEED-5G and “Wifi-like” systems. In the remainder of this document this system will be simply denoted as “Wifi”.

Figure 84: Simplified DCF procedure for Wifi APs

We consider the deployment of Wifi access points (APs) assuming system parameters shown in Table 70.

Wifi parameters Values

Path-loss model Same as for SPEED-5G cells

AP antenna gain 5 dB / 0 dB

AP noise figure 5 dB / 9 dB

AP antenna height 10 m / 1,5m

AP TX power Same as for SPEED-5G SCs (wrt. ISD values)

AP dropping Baseline: randomly dropped with the same density as SPEED-5G cells Option: randomly dropped with half the density as SPEED-5G cells

STA dropping No STA dropped

Wifi traffic model Only APs transmit (full buffer) and simplified DCF MAC

MAC parameters DIFS=34 µs SIFS=16 µs Backoff slot duration = 9 µs Contention window length = 31

Table 70: Wifi parameters for coexistence simulations

As far as Wifi traffic model is concerned, the simulations implement only downlink traffic of APs assuming full buffer traffic, allowing for the capture of worst case scenario in terms of the impact of the Wifi system.



3.3 DCS-Based MAC Simulation

The main purpose of this simulation study is to investigate the impact of different scenarios and MAC related parameters on the performance of the DCS-MAC designed for broadband traffic. Two main scenarios are considered in this study: 1) non-coexistence and 2) coexistence. In the non-coexistence scenario we evaluate performance of DCS-MAC when it operates in a separate band, i.e., without any other system (no inter-system interference). In case of the coexistence scenario we focus on investigation of DCS-MAC performance when it needs to coexist with another system, both using a shared spectrum. We focus our attention in this scenario on an LBT based “WiFi-like” system and we investigate impact of both systems on each other. It needs to be highlighted here that our investigation focuses on a “WiFi-like” system rather than the actual WiFi system itself. As the basic principal of operation of the considered “WiFi-like” system and WiFi is similar, the study gives us a close approximation on how a real WiFi system would perform in such a scenario. The investigation of the coexistence with a real WiFi system and DCS-MAC is left for future study.

3.3.1 Simulation assumptions

DCS-MAC design has been implemented using a proprietary simulation tool developed in Matlab. The following section provides a list of assumptions considered in this study. The list complements the information provided in Section 3.2.

Propagation delay is assumed to be zero. This is a common assumption in simulators developed in Matlab and enables vectorization of calculations. Similar assumption is also used for instance in the well-established LTE system level simulator developed by the Technical University of Vienna2.

Small scale fading is not considered in this study. It is worth highlighting here that channel fluctuations caused by small scale fading decrease with the decrease in the average ISD, thus in case of ultra-dense networks, modelling of small scale fading loses its importance. This stems from a higher probability of nodes being in line-of-sight (more nodes have strong LOS signal component). Additionally, short distances make channels between nodes in the same cell, highly correlated. This is of course not the case for sparse macro cell deployment. These deployments however are not the focus of this study.

Wrap-around with 4 rings, instead of 3 rings is assumed to improve accuracy of simulation results.

Adjacent channel interference is not considered in this study. This means that there is no out-of-band emission assumed and when two nodes operate on adjacent channels their potential negative impact on each other is not taken into account.

The simulator includes an error model of U-filed part of the transmission according to the standard link-to-system mapping (LSM) techniques. The use of LSM provides a good trade-off between level of accuracy and the computational complexity. The LSM technique used in the simulation model is based on the MIESM approach described in Appendix B. The curves which map SNR to BLER were generated using LTE link level simulator [21] modified in order to consider OFDM numerology provided in Section 2.3.1.5. The curves used in the simulation tool are presented in Appendix B.2. It needs to be highlighted here that the simulator does not include the error model for C-Field part of the transmission. This means that all control messages are assumed to be transferred over an ideal error-free channel. As C-Field uses a robust modulation and coding scheme, this would only have a limited impact on the overall system performance. In order to model radio link failures, it is assumed that U-field needs to

2 https://www.nt.tuwien.ac.at/research/mobile-communications/vccs/vienna-lte-a-simulators/



experience continuous errors over a pilot RB for 100ms, whilst using the lowest MCS.

3.3.2 Scenario description

In the following section we provide description of scenarios considered for evaluation. As mentioned earlier, two main types of scenarios are considered for evaluation of DCS-MAC: non-coexistence and coexistence scenarios. In both cases we consider a hexagonal-grid based network deployment of DCS-MAC based system with inter-site distance of 30m, 50m and 100m. The following Table provides a list of common DCS-MAC related parameters used for both considered scenarios.

Parameter Value

Slot lengths 0.417ms (no variable slot lengths, only basic slot length considered)

Bandwidth of frequency channels 2MHz

Number of frequency channels 10 (20MHz of total operational bandwidth)

TRX number SC Variable

TRX number UE 2

Scanning/Hopping sequence 1 frequency channel is scanned per frame

Maximum allowed load (ML) per SC Variable

Maximum number of RBs per UE 18

Packet size 1500 bytes

C-Part length Fixed to 3 OFDM symbols (only primary allocation block is used)

Physical Channel Selection list granularity 5 dB

Maximum allowed level of interference in a channel

-33dBm (non-coexistence scenario) / variable (coexistence scenario)

Table 71: DCS-MAC specific simulation parameters

As indicated in the Table above, different number of SC transceivers will be considered. It is worth reminding here that the number of transceivers directly impacts the number of physical channels which can be simultaneously allocated by an SC. In case of 10 transceivers available on the SC side, the maximum number of physical channels which can be allocated is equal to 240. This number drops to 120 for 5 transceivers.

The above table indicates also that, different levels of maximum allowed load (ML) per SC are considered for evaluation. The ML per SC corresponds to the maximum number of physical channels which can be allocated by a SC. For instance, for a system operating using 10 frequency channels and 24 time slots, the ML equal to 0.8 corresponds to 192 physical channels (out of 240 available).

In the considered scenarios, all UEs are assumed to have two TRXs which allow each UE to maintain a maximum number of 24 active RBs. Note that each RB consists of two physical channels allocated in the first half frame and the second half frame. In order to enable more efficient reallocation of resources (i.e. intra-cell handovers) the maximum number of RBs per UE has been limited to 18. In case the maximum number of active RBs in reached by the SC, the SC decreases gradually the maximum number of active RBs per UE. In order to maintain a fair access to resources, SC aims at maintaining equal number of active RBs per UE.

The Physical Channel Selection list granularity parameter determines how fine is the Physical Channel Selection list which is used to order the physical channels periodically measured by each DCS-MAC



device. The maximum allowed level of interference (MI) parameter provides the upper bound for the Physical Channel Selection list. This means that the MI parameter provides a limit on the maximum level of interference which permits allocation of a physical channel by a DCS-MAC node.

3.3.2.1 Non-coexistence scenario

In the non-coexistence scenario we evaluate performance of DCS-MAC when it operates in a dedicated band. The main aim of this scenario is to provide means for assessing the impact of inter-cell interference on the system performance for various system parameter settings.

We analyze DCS-MAC performance in an outdoor deployment scenario for regular hexagonal layout. Simulations for this scenario are run using the full buffer traffic model (which is used to evaluate MAC protocols under constant traffic load and non-time-varying interference situations) and FTP-model with 2 and 5 seconds mean file inter-arrival times.

3.3.2.2 Coexistence scenario

The main objective in this scenario is to access the impact of LBT-based “WiFi-like” system on DCS-MAC performance and to determine the fairness of coexistence. In order to assess the impact of DCS-MAC based system on the LBT-based “WiFi-like” system we rely on the channel occupancy statistics which provides a simple measure of fairness.

We analyze DCS-MAC and LBT-based “WiFi-like” coexistence in an outdoor deployment scenario which operate in a shared band. Similar to the non-coexistence scenario, we consider regular hexagonal layout for DCS-MAC SCs. LBT-based “WiFi-like” APs are randomly dropped in the hexagonal area with the density per channel equal to the density of DCS-MAC SCs. It needs to be highlighted here that unlike real WiFi the considered LBT-based “WiFi-like” system operates on 2MHz frequency channels, instead of 20MHz channels. The considered LBT-based “WiFi-like” system undergoes standard WiFi DCF CSMA/CA (does not use RTS/CTS mode) procedure with exponential backoff mechanism. Transmission time for this system is considered to be static and equals 5ms (this corresponds to a TxOP of 5ms). The full-buffer traffic model is assumed for the LBT-based “WiFi-like” APs which is a worst case scenario. More detail on how the activity of the LBT-based “Wifi-like” system is modelled is provided in Section 3.2.5.

The following table provides a list of parameters of the LBT-based “WiFi” like system which complements the list of parameters provided in Table 70 in Section 3.2.5.

LBT-based “WiFi-like” system parameters

Values

Signal bandwidth 2 MHz

Number of frequency channels

10

AP TX power 14dBm (ISD=100m), 2dBm (ISD=50m), -1dBm (ISD=30m) (see Note 1)

AP dropping Randomly dropped with the same density per each channel as DCS-MAC cells (see Note1)

STA dropping No STA dropped

Traffic model Full buffer

CCA_ED threshold -72dBm (see Note3)

Note 1: This corresponds to 24dBm, 12dBm, 9dBm for 20MHz channel bandwidth Note 2: Each frequency channel is occupied by the number of APs which corresponds the number of DCS-MAC SCs. As DCS-MAC SCs can operate on all 10 frequency channels this means that the number of APs is 10 times higher than DCS-MAC SCs. Note3: This corresponds to a typical value of -62dBm for WiFi when operating in a 20MHz channel bandwidth

Table 72: LBT-based “WiFi-like” system specific simulation parameters



3.3.3 Simulation Results

In this section, we present performance evaluation results of the proposed DCS-MAC design following the assumptions defined in Sections 3.2and 3.3.1. We first present the results for non-coexistence scenario for full buffer and FTP traffic. We then provide the results for the coexistence scenario.

3.3.3.1 Non-coexistence scenario

We start our evaluation by investigating the impact of the maximum allowed load per cell on the system performance given SCs are equipped with 10 TRXs. Simulations are conducted for different ISDs with different levels of maximum allowed load (ML), ranging from 0.4 to 0.8. Next, we investigate the impact of different number of TRXs on the system performance. In both cases, the simulations assume both the full buffer traffic model (which is used to evaluate MAC protocols under constant traffic load and non-time-varying interference situations) and the FTP model, with various mean file interarrival times (see Section 3.2.3.2). Finally, we provide analysis of the control overhead.

3.3.3.1.1 Impact of maximum load on the system performance

In the following section we investigate the impact of the ML per cell, on the system performance. We start by evaluating the system performance for the full buffer traffic model with 100% DL traffic which is then followed by evaluation of FTP traffic model. Next, we investigate the system performance when uplink traffic is considered, assuming the full buffer traffic model.

Figure 85 (left) shows CDFs of normalized UE throughput for different ML values, given different ISDs. In general, the results show that the DL normalized UE throughput decreases with the decrease in ISD. This stems from the increase in the UE density which changes from 1,154 UEs per km2 (for ISD=100m) to 12,830 UEs per km2 (for ISD=30m). The increase in the UE density leads to a significant increases in the offered load per km2 which in turn leads to significantly higher level of interference which affects the channel quality, leading to a decrease in per-UE normalized throughput. The impact of ML on the DL normalized UE throughput is slightly different. By lowering the ML per SC setting, we decrease the offered load per km2 by lowering the number of physical channels which can be allocated for transmission. This limits the per-UE throughputs in general but improves performance of cell edge users. This can be especially seen for ISD=30m. When the ML is larger than 0.6, a small fraction of UEs experience outage (i.e. zero throughput) due to the high level of interference caused by allocation of large number of physical channels. When the maximum allowed load is limited to 0.6, all UEs are able to find suitable physical channels and maintain a stable connection. In Figure 85 (right) we present CDFs of UE delays for all UEs which are not in outage. The results presented in this figure show that the delay increases with the decrease in the ISD. This is to be expected as the higher level of interference affects the channel quality leading to the use of lower MCSs for transmission of user data. The results present Figure 85 (right) indicate also that there exist a minimum delay which can be achieved by a UE. This minimum delay is directly related with the DCS-MAC frame structure which allows a minimum delay of 5ms.



Figure 85: CDFs of normalized UE throughput (left) and UE delay (right) for different MALs, ISDs and full buffer 100%DL traffic

Key Performance Indicators (KPIs) for full buffer 100% DL are summarized in Table 73. It is worth highlighting here that the near perfect fairness of channel access is related to the resource allocation procedure on the SC side which gradually decreases the number of active RBs per UE when the maximum load is reached. As mentioned in Section 3.3.2, the SC always tries to maintain the same number of active RBs per UE. As can be seen based on the throughput fairness metric for UEs, this may not always be optimal due to different conditions experienced by UEs. Possible improvement of the throughput fairness which provides more accurate fairness metric could be achieved by considering a more sophisticated mechanism on the SC side which uses the basic principle of a proportional fair scheduler by taking into account the average throughput of UEs.

ISD [m] 30 50 100

Maximum Allowed Load (ML)

0.8 0.6 0.4 0.8 0.6 0.4 0.8 0.6 0.4

Mean delay [ms] 24.98 27.94 29.76 21.28 21.97 22.79 15.24 15.13 15.24

Per-cell Spectral Efficiency [bps/Hz]

0.432 0.376 0.329 0.566 0.507 0.460 1.012 0.933 0.818

Area Spectral Efficiency [bps/km2/Hz]

554.33 482.80 422.32 261.61 233.99 212.30 116.84 107.68 94.48

Fairness_UE_Th 0.635 0.707 0.761 0.683 0.734 0.779 0.669 0.741 0.827

Fairness_SC_Th 0.930 0.938 0.959 0.940 0.947 0.963 0.950 0.959 0.980

Fairness_access 0.931 0.983 0.989 0.989 0.994 0.993 0.992 0.995 0.993

Table 73: Summary of DCS-MAC performance metrics for full buffer traffic model with 100% DL traffic

In the following we focus on the system performance when FTP traffic model is used. In general, the results show similar trends as in case of the full buffer traffic presented earlier. The results indicate that the offered load per km2 has a decisive impact on the overall system performance. By increasing the offered load per km2, either by decreasing the ISD, or by increasing the ML level per cell, or by lowering the mean file interarrival time parameter of the FTP model, we increase the Area Spectral Efficiency and lower delay. This leads however to the degradation of fairness (see Table 74). The exception here is the SC throughput fairness metric, which remains at approx. constant level.



Figure 86: CDFs of normalized UE throughput (left) and UE delay (right) for different MALs, ISDs and FTP traffic model for 100%DL traffic with mean reading time 2sec

Figure 87: CDFs of normalized UE throughput (left) and UE delay (right) for different MALs, ISDs and FTP traffic model for 100%DL traffic with mean reading time 5sec

Key Performance Indicators (KPIs) for FTP traffic model with 100% DL traffic are summarized in Table 74. As already mentioned, the results are consistent with the observations made for the full buffer traffic model with 100% DL traffic. It is important to note that the performance for different ML values for ISD of 100m does not change. This is due to the significantly lower offered load of FTP traffic model compared to the full buffer traffic model described before.



ISD [m] 30 50 100


0.80 0.60 0.40 0.80 0.60 0.40 0.80 0.60 0.40

Mean inter-arrival time = 2sec

Mean delay [ms] 18.048 18.944 21.584 14.581 15.178 14.716 8.502 8.187 8.607

Per-cell spectral efficiency [bps/Hz]

0.361 0.345 0.300 0.450 0.428 0.420 0.665 0.674 0.648


463.22 442.84 385.27 207.98 197.91 194.17 76.75 77.83 74.85

Fairness_UE_Th 0.786 0.823 0.858 0.854 0.862 0.888 0.901 0.906 0.918

Fairness_SC_Th 0.963 0.960 0.960 0.977 0.970 0.975 0.988 0.988 0.991

Fairness_access 0.868 0.928 0.966 0.910 0.934 0.953 0.858 0.877 0.926

Mean inter-arrival time = 5sec

Mean delay [ms] 12.28 12.73 14.74 8.72 9.06 9.73 6.54 6.57 6.66


0.279 0.273 0.252 0.328 0.321 0.312 0.364 0.361 0.354


357.72 350.40 323.73 151.52 148.07 143.95 42.06 41.69 40.92

Fairness_UE_Th 0.820 0.822 0.832 0.826 0.825 0.831 0.810 0.813 0.813

Fairness_SC_Th 0.977 0.979 0.982 0.981 0.980 0.982 0.975 0.979 0.977

Fairness_access 0.821 0.837 0.876 0.833 0.837 0.854 0.895 0.898 0.905

Table 74: Summary of DCS-MAC performance metrics for FTP traffic model with 100% DL traffic

In the following we investigate the system performance when uplink traffic is also considered, assuming the full buffer traffic model. The main aim of this part of the study is to evaluate the performance of UEs transmitting in uplink. In general, we notice that UL performance is significantly lower than DL performance. This is related to a significantly higher level of interference in the uplink direction. As mentioned in Section 2.3.1, DCS-MAC allows for dynamic re-allocation of slots pre-allocated for uplink and downlink transmission. This means that severe uplink to downlink interference maybe a big problem.

In general, we notice that results for the DL traffic UEs are in-line with the previous results. This is however not the case with the results for the UL traffic. From the results for the uplink UEs we notice that ML per SC setting has a significantly higher impact on the performance of cell edge UEs. This is especially reflected in the significant drop in the mean delay (see Table 75) and the CDFs for normalized UL per UE throughput (see Figure 88). Another aspect worth highlighting is the opposite impact of ML value on the uplink delay compared to downlink.



Figure 88: CDFs of normalized UE throughput (left) and UE delay (right) for different MALs, ISDs and full buffer 80%DL 20% UL traffic (DL part)

Figure 89: CDFs of normalized UE throughput (left) and UE delay (right) for different MALs, ISDs and full buffer 80%DL 20% UL traffic (UL part)

Key Performance Indicators (KPIs) for full buffer 80% DL and 20% UL are summarized in Table 75. As already mentioned, the results for downlink traffic are consistent with the observations made for the full buffer traffic model with 100% DL traffic. This is not the case with the uplink traffic. One of the interesting aspects is the approximately constant uplink area spectral efficiency. This, along with the improvement of fairness and drop in the delay clearly indicates that by tuning the ML value we mainly trade-off performance of UEs with good channel conditions located in a close proximity to SC for the performance of the cell edge UEs.



ISD [m] 30 50 100


0.80 0.60 0.40 0.80 0.60 0.40 0.80 0.60 0.40

DL traffic

Mean delay [ms] 21.96 24.37 27.27 19.10 19.51 20.43 12.95 13.17 13.51


0.394 0.344 0.289 0.504 0.464 0.415 0.962 0.865 0.736


505.94 441.76 370.16 232.57 214.45 191.76 111.12 99.85 85.01

Fairness_UE_Th 0.662 0.726 0.760 0.696 0.752 0.795 0.718 0.784 0.863

Fairness_SC_Th 0.900 0.916 0.932 0.925 0.934 0.947 0.930 0.934 0.964

Fairness_access 0.966 0.987 0.997 0.993 0.996 0.997 0.994 0.995 0.998

UL traffic

Mean delay [ms] 345.39 179.17 113.67 147.63 83.29 67.59 84.86 60.69 40.44


0.022 0.022 0.021 0.034 0.034 0.036 0.097 0.094 0.083


27.59 27.96 27.30 15.20 15.51 16.56 11.17 10.88 9.61

Fairness_UE_Th 0.406 0.476 0.559 0.474 0.569 0.626 0.500 0.578 0.661

Fairness_SC_Th 0.447 0.476 0.517 0.481 0.528 0.545 0.494 0.528 0.582

Fairness_access 0.965 0.991 0.984 0.995 0.999 0.990 0.984 0.994 0.989

Table 75: DCS-MAC performance results using different ISDs, full buffer 80% DL and 20% UL

3.3.3.1.2 Impact of the number of TRXs on the system performance

In the following section we investigate the impact of the number of TRXs per SC on the system performance. Similar to the previous subsection, we start by evaluating the system performance for the full buffer traffic model with 100% DL traffic which is followed by evaluation of FTP traffic model, and then we investigate the impact of uplink traffic for the same models. All simulations are conducted assuming maximum allowed load of 0.4 which for 24 slot frame configuration and a system operating on 10 frequency channels corresponds to the maximum allocation of 96 physical channels. Two settings for number of TRXs per SC are considered.

The provided results in figures below clearly show that a higher number of TRXs on the SC side can improve performance. This is mainly related with the higher flexibility in physical channel allocation which is enabled by availability of additional transceivers on the SC side. It is worth reminding here that the number of physical channels which can be accessed or scanned in a given time period is directly related with the number of TRXs. In case of 5 TRXs the number of physical channels which can be simultaneously accessed is 5 and the total number of physical channels which can be allocated is 120, whilst in case of 10 TRXs these numbers rise to 10 and 240, respectively.



Figure 90: CDFs of normalized UE throughput (left) and UE delay (right) for different number of TRXs, ISDs and full buffer 100%DL traffic

Key Performance Indicators (KPIs) for full buffer 80% DL and 20% UL are summarized in Table 76. The results show improvements of performance for larger number of TRXs compared to smaller number of TRXs. As already mentioned this is related to the higher flexibility in physical channel allocation.

ISD [m] 30 50 100

SC TRX number 10 5 10 5 10 5

Mean delay [ms] 29.70 29.90 22.42 22.78 15.24 15.32


0.329 0.317 0.460 0.459 0.818 0.801


422.32 407.25 212.30 211.84 94.48 92.49

Fairness_UE_Th 0.761 0.782 0.779 0.786 0.827 0.825

Fairness_SC_Th 0.959 0.959 0.963 0.963 0.980 0.977

Fairness_access 0.989 0.993 0.993 0.993 0.993 0.993

Table 76: DCS-MAC performance results for various number of SC TRXs, using different ISDs and full buffer 100% DL traffic model

In the following we investigate the system performance for the same system parameters but assuming the existence of uplink traffic. Similar to the previous section, the main aim of this part of the study is to evaluate the impact of the system parameters on the performance of UEs transmitting in uplink. Unlike the ML analysis conducted in the previous section, we notice that changes in the performance for uplink traffic is consistent with that of downlink traffic. This means that providing additional TRXs we improve the performance for both, uplink and downlink UEs.



Figure 91: CDFs of normalized UE throughput (left) and UE delay (right) for different MALs, ISDs and full buffer 80%DL 20% UL traffic (DL part)

Figure 92: CDFs of normalized UE throughput (left) and UE delay (right) for different MALs, ISDs and full buffer 80%DL 20% UL traffic (UL part)

ISD [m] 30 50 100

SC TRX number 10 5 10 5 10 5

DL traffic

Mean delay [ms] 27.273 27.727 20.427 20.473 13.510 13.874

Per-cell spectral efficiency [bps/Hz] 0.289 0.282 0.415 0.409 0.736 0.716

Area Spectral Efficiency [bps/km2/Hz] 370.156 362.343 191.760 189.131 85.012 82.734

Fairness_UE_Th 0.760 0.770 0.795 0.795 0.863 0.857



Fairness_SC_Th 0.932 0.943 0.947 0.940 0.964 0.961

Fairness_access 0.997 0.998 0.997 0.997 0.998 0.998

UL traffic

Mean delay [ms] 113.67 124.95 67.59 70.95 40.44 47.16

Per-cell spectral efficiency [bps/Hz] 0.021 0.018 0.036 0.033 0.083 0.081

Area Spectral Efficiency [bps/km2/Hz] 27.30 23.58 16.56 15.32 9.61 9.35

Fairness_UE_Th 0.559 0.571 0.626 0.653 0.661 0.664

Fairness_SC_Th 0.517 0.541 0.545 0.580 0.582 0.569

Fairness_access 0.984 0.989 0.990 0.990 0.989 0.989

Table 77: DCS-MAC performance results for various number of SC TRXs, using different ISDs and full buffer with 80% DL and 20% UL traffic

3.3.3.1.3 Control overhead considerations

Control overhead is an important performance metric which is used in the evaluation process of the MAC protocol efficiency. In case of DCS-MAC we assess the control overhead as the ratio between the maximum amounts of resources used to transfer control information over the total amount of resources which can be allocated to a UE. There are two main source of control overhead in the DCS-MAC. The first source is related to the C-Field transmission. As mentioned in Section 2.3, C-Field needs to be always transmitted on all active RBs (in uplink as well as in downlink direction) to allow proper system operation. The overhead due to C-Field transmission may vary depending on the amount of control information which needs to be transmitted, with the minimum overhead per RB dependent on the minimum size of the C-Field (i.e. 3 OFDM symbols). Another source of overhead in DCS-MAC is related to a Pilot Radio Bearer used for exchange of UE specific control signaling. In case of DL-only UE traffic (or UL-only UE traffic) this means that a physical channel allocated for Pilot Radio Bearer in uplink direction may not be used efficiently. The impact of this overhead may significantly vary depending on the number of active Radio Bearers allocated per UE (the larger the number of active RBs, the lower the overhead).

In our evaluation of the control overhead for DCS-MAC we consider the worst case scenario. This means that we assume that all UEs in the network have active connections with their respective SCs and have data for transmission (i.e. full buffer traffic model). Additionally, we assume that the C-Field transmitted over Pilot Radio Bearers for all UEs is always transmitted using its largest size (which for a 2MHz frequency channel corresponds to 12 OFDM symbols). This means that the capacity of a Pilot Radio Bearer in the considered scenario is limited to 45% of its total capacity. Next, we assume that all UEs have either DL-only or UL-only traffic which means that one of the physical channels allocated for a Pilot Radio Bearer is not being allocated with user traffic. This in turn indicates that the total overhead of a Pilot Radio Bearer reaches 77% (it is worth highlighting here that this is for worst-case scenario, but for multi-bearer connections, this overhead drops significantly). In case of non-Pilot Radio Bearers we assume the overhead of 13.6% which corresponds to the C-Filed transmission overhead with the length of 3 OFDM symbols. It is worth reminding here that only common control information is sent over a C-Field of a non-Pilot RB. All UE specific signaling which requires additional space in a C-Filed is always transmitted over a Pilot RB.

In Figure 93 we provide calculations of DCS-MAC overhead for the considered worst case scenario described above. Assuming that all UEs are served, we observe that the overhead varies from 16.2% to 34.7%. Additionally, it can be seen that the overhead significantly changes for different levels of Maximum Allowed Load (ML). This is directly related with the number of UEs per cell. As mentioned in Section 3.3.2, ML corresponds to the maximum number of physical channels which can be allocated per SC. Given the static number of UEs per cell and the full buffer traffic model, ML value determines the total number of non-Pilot RBs which can be allocated per UE. The results show also that the control overhead also depends on the number of TRXs employed by UEs. This is related to



the fact that the number of TRXs on the UE side has a direct impact on the maximum number of non-Pilot RBs which can be maintained by a UE and affects the level of minimum overhead which is equal to 18.9% and 16.2% for 1TRX and 2TRX per UE, respectively. It is worth reminding here that the provided results show the worst case scenario. In a more realistic scenario (e.g. non-full buffer) the overhead levels would be significantly lower.

Figure 93: Control overhead vs Maximum Allowed Load for different number of TRXs per UE (1TRX per UE – left, 2TRXs per UE – right) and number of UEs per SC for full buffer traffic model

3.3.3.2 Coexistence scenario

Similar to the evaluation of the non-coexistence scenario, we start from investigating the impact of the maximum allowed load (ML) per cell on the DCS-MAC system performance (given SCs are equipped with 10 TRXs). Additionally, we also investigate the LBT-based “WiFi-like” channel occupancy which is used as a measure of impact of DCS-MAC on the performance of the LBT-based “WiFi-like” system. Simulations are conducted for different ISDs with different levels of ML, ranging from 0.2 to 0.4. Next, we investigate the impact of the maximum allowed level of interference (MI) which permits allocation of a physical channel by a DCS-MAC node. In both cases, the performance is evaluated using the full buffer traffic model (which is used to evaluate MAC protocols under constant traffic load and non-time-varying interference situations). It is worth reminding here that unlike WiFi, the LBT-based “WiFi-like” system considered in this study operates on channels with the same bandwidth as the DCS-MAC system (i.e. channel with 2MHz bandwidth).

3.3.3.2.1 Impact of maximum load on the system performance

In the following section we investigate the impact of the maximum allowed load per SC on the DCS system performance and the LBT-based “Wifi-like” channel occupancy. We focus our evaluation solely on the full buffer traffic model with 100% DL traffic which provide the worst case scenario. The MI in this scenario is set to -33dBm which indicates that channels with a measured level of interference above -38dBm are considered to be busy and cannot be allocated. Due to the limitations of the proposed model for the LBT-based “Wifi-like” system, investigation of the impact of uplink traffic on the system performance is left as for future study.

Below figures show the impact of deploying an LBT-based “WiFi-like” system on UE throughput and



delay assuming the full buffer traffic model. Due to the existence of additional interference caused the “WiFi-like” system, we observe a significant throughput degradation compared to non-coexistence scenario (see Table 73, ML=0.4 and Table 78). We can see in Figure 94 that by increasing the ML value per SC we can improve DCS-MAC performance. The increase in the ML level leads however leads to significant degradation of the “WiFi-like” system performance reflected by the CDF of channel occupancy of the considered “WiFi-like” system (see Figure 95).

Figure 94: CDFs of normalized UE throughput (left) and UE delay (right) for different ML values, ISDs and full buffer 100%DL traffic in coexistence scenario

Figure 95: CDFs of channel occupancy for LBT-based “Wifi-like” system for different MALs, ISDs and Full buffer 100%DL traffic

Key Performance Indicators (KPIs) for the considered scenario are summarized in Table 78. From the obtained results it can be clearly seen that ML has significant impact on both DCS-MAC and “WiFi-like” system performance. The setting of the ML parameter can be then used to trade-off performance between coexisting systems. This indicates that DCS-MAC could coexist with other LBT-based systems operating in unlicensed bands, without causing significant performance degradation.



ISD [m] 30 50 100


0.4 0.3 0.2 0.4 0.3 0.2 0.4 0.3 0.2

Mean delay [ms] 39.27 42.31 59.88 29.50 43.82 73.70 25.95 31.28 60.18


0.248 0.217 0.150 0.339 0.214 0.126 0.505 0.365 0.221


318.05 277.80 192.04 156.44 98.92 58.17 58.33 42.13 25.50

Fairness_UE_Th 0.721 0.760 0.729 0.748 0.743 0.710 0.721 0.678 0.658

Fairness_SC_Th 0.943 0.958 0.953 0.958 0.965 0.955 0.959 0.958 0.957

Fairness_access 0.989 0.973 0.955 0.991 0.970 0.944 0.973 0.919 0.909

Channel occupancy DCS

0.399 0.299 0.200 0.400 0.299 0.199 0.401 0.300 0.201

Channel occupancy WiFi

0.021 0.029 0.068 0.089 0.163 0.234 0.189 0.257 0.319

Table 78: DCS-MAC performance in coexistence scenario for various ML settings, assuming Full buffer model with 100% DL traffic in coexistence scenario

3.3.3.2.2 Impact of the maximum level of interference on the system performance

In the following section we investigate the impact of the maximum level of interference (MI) which permits allocation of a physical channel by the DCS-MAC system on the performance of DCS-MAC and channel occupancy of LBT-based “Wifi-like”. We focus our evaluation solely on the full buffer traffic model with 100% DL traffic which provide the worst case scenario. The ML in this evaluation is set to 0.2 and the value of MI varies from -33dBm to -73dBm.

Figures provided in this section show the impact of deploying an LBT-based “WiFi-like” system with the density per single frequency channel corresponding to the density of DCS-MAC SCs on UE throughput and delay assuming the full buffer traffic model for various levels of MI. In general the provided results indicate that by tuning the MI value we can trade-off DCS-MAC performance for the considered LBT-based “WiFi-like” system performance. We also observe that careful setting of MI is very important. Unlike ML parameter, incorrect setting of MI may lead to a significant level of UE outage on the DCS-MAC side. This is related with the fact that some UEs may be in a close proximity to multiple LBT-based nodes, making the level of interference in the physical channels always exceeding the MI threshold.



Figure 96: CDFs of normalized UE throughput (left) and UE delay (right) for different levels of maximum allowed interference, ISDs and full buffer 100%DL traffic for coexistence scenario

Figure 97: CDFs of channel occupancy for LBT-based “Wifi-like” system for different levels of maximum allowed interference, ISDs and full buffer 100%DL traffic

Key Performance Indicators (KPIs) for the considered scenario are summarized in table below. As mentioned above, the obtained results clearly indicates that MI has significant impact on both DCS-MAC and “WiFi-like” system performance.

ISD [m] 30 50 100

Maximum Allowed Level of Interference (MI)

-33.00 -63.00 -73.00 -33.00 -63.00 -73.00 -33.00 -63.00 -73.00

Mean delay [ms] 56.35 57.20 22.68 63.31 63.32 42.17 41.92 40.66 28.56


0.150 0.149 0.181 0.126 0.127 0.159 0.221 0.223 0.271




192.04 191.04 232.39 58.17 58.73 73.60 25.50 25.79 31.30

Fairness_UE_Th 0.729 0.713 0.256 0.719 0.717 0.482 0.658 0.644 0.470

Fairness_SC_Th 0.953 0.943 0.793 0.958 0.956 0.926 0.957 0.958 0.926

Fairness_access 0.955 0.955 0.384 0.951 0.950 0.679 0.909 0.892 0.661

Channel occupancy DCS

0.200 0.200 0.175 0.199 0.201 0.193 0.201 0.198 0.195


0.068 0.073 0.090 0.234 0.234 0.242 0.319 0.321 0.332

Table 79: DCS-MAC performance in coexistence scenario for various MI settings, assuming full buffer model with 100% DL traffic

3.3.3.3 Conclusions

We have presented in this section the performance evaluations of DCS-MAC for a range of different scenarios and MAC specific parameters. The objective of this section was to study the impact of these parameters on performance and to assess if DCS-MAC based system is capable of operating in dense and ultra-dense deployments using licensed, lightly-licensed bands (non-coexistence scenario) as well as unlicensed bands (coexistence scenario).

Based on the simulation results the following conclusions are drawn:

- DCS-MAC is capable of operating effectively in highly dense deployment scenarios. In order to prevent UE outage, the maximum allowed load (ML) per SC may need to be appropriately tuned.

- The results indicate that the offered load per km2 has a decisive impact on the overall system performance. By increasing the offered load per km2, we increase the Area Spectral Efficiency but decrease the per-UE metrics.

- DCS-MAC is capable of coexisting with LBT-based “WiFi-like” systems when operating in a shared band. Fair coexistence with an LBT-based “WiFi-like” system requires however appropriate tuning of DCS-MAC specific parameters.

- The performance of DCS-MAC based system and “WiFi-like” based system is highly dependent on the level of maximum allowed load (ML) and the level of the maximum allowed interference (MI). Both parameters can be used to provide a trade-off between performance of DCS-MAC and LBT-based “WiFi-like” system.

3.4 FBMC-Based MAC Simulation

3.4.1 Simulation assumptions

FBMC-MAC design has been implemented on system-level simulator called “WSNet3”. The system level simulator has been developed to accurately model the behaviours of both MAC and FBMC-PHY layers.

The two different variants of channel access mechanisms FBE and LBE have been simulated in order to investigate the impact of both mechanisms on the performance of the FBMC MAC design. The goal is to estimate in the case of broadband traffic operating in 5GHz band the amount of traffic that can

3 Wireless Sensor Network Simulator (http://wsnet.gforge.inria.fr/index.html)



be offloaded on shared spectrum with a fair coexistence with others systems. Non-coexistence and coexistence (WiFi) scenarios are considered in the simulations, which rely on parameters described in section 3.2.3.

3.4.1.1 Full-buffer traffic

Full buffer traffic type is used to evaluate MAC protocols under constant traffic load and non-time-varying interference situations. First, no fast fading model is considered in the simulation where several ISDs and CCA thresholds will be tested on both channel access mechanisms (LBE/FBE); this is the baseline which will be used later for comparison. Next, uncorrelated TU channel model is used to investigate the performances results in more realistic cases; also scenarios based on non-coexistence and coexistence with Wifi will be considered, as shown in Table 80 and Table 81. In order to show the benefits of using FBMC modulations, an overlapping factor K= 4 is considered as baseline, corresponding to a model with no adjacent channels leakages. FBMC with overlapping factor K= 2 and OFDM modulations is used to evaluate the impact of adjacent channel leakages on the performance, as given in Table 82.

Full-buffer 100 % DL 80% DL / 20% UL

FBM

C K

= 4

FBMC-MAC design FBE / LBE FBE / LBE

Inter-side-distance (ISD) {30, 50, 100 } m {30, 50, 100 } m

CCA –ED threshold {-62, -72, -82 } dBm -62 dBm

Frequency reuse 1 and 3 1 and 3

Channel Fading Model No fast fading [Baseline] No fast fading [Baseline]

Uncorrelated TU [-62 dBm] Uncorrelated TU[-62 dBm]

Table 80: Full Buffer - Non coexistence scenario cases

Full-buffer 100 % DL

FBM

C K

= 4

FBMC-MAC design LBE

Wi-Fi DCF - CSMA/CA

Inter-side-distance (ISD) {30, 100 } m

CCA –ED threshold {-62, -82 } dBm

Frequency reuse 1

Channel Fading Model No fast fading [Baseline]

Table 81: Full Buffer - Wi-Fi coexistence scenario cases

Full-buffer 100 % DL

FBM

C K

= 2

FBMC-MAC design LBE

Inter-side-distance (ISD) {30, 50, 100 } m

CCA –ED threshold {-62 } dBm

Frequency reuse 1 and 3

Channel Fading Model Uncorrelated TU

OFD

M

FBMC-MAC design LBE


CCA –ED threshold {-62 } dBm

Frequency reuse 1 and 3

Channel Fading Model Uncorrelated TU

Table 82: Full Buffer - FBMC K = 2 and OFDM simulations



3.4.1.2 FTP traffic model

Simulations are run for various mean reading time to study the impact of traffic load on the performance of the MAC design using both LBT procedures. Similarly to full buffer traffic, non-coexistence and coexistence scenarios are considered, as listed in Table 83 and Table 84, respectively.

FTP traffic model 2 100 % DL FB

MC

K =

4

FBMC-MAC design FBE / LBE

Mean file reading time D {2 , 5} sec


CCA –ED threshold {-62, -72, -82 } dBm

Frequency reuse 1


Uncorrelated TU [-62 dBm]

Table 83: FTP trafic - Non coexistence scenario cases

FTP traffic model 2 100 % DL

FBM

C K

= 4

FBMC-MAC design LBE

Wi-Fi (Full buffer) DCF - CSMA/CA

Mean file reading time D {2 , 5} sec

Inter-side-distance (ISD) {30, 100 } m

CCA –ED threshold {-62 ,-82 } dBm

Frequency reuse 1


Table 84: FTP traffic - Wi-Fi coexistence scenario cases

3.4.1.3 PHY assumptions

PHY-MAC considerations

It is worth reminding that filtered multicarrier modulations like FBMC have been considered in 5G systems to overcome the burden of tight time and frequency synchronisation required by OFDM through the use of well-designed prototype filters which can provide a very sharp frequency confinement of the signal.

The design of FBMC filters has an impact on stop-band attenuation (out of band leakages) and the residual inter-symbol interference. Offset Quadrature Amplitude Modulation (OQAM) combined with Nyquist constraints on the prototype filter is generally used to guarantee orthogonality between adjacent symbols and adjacent carriers while providing maximum spectral efficiency.

The prototype filter is characterized by its filter length 𝐿, which is a multiple of the size of the FFT 𝑁, so that 𝐿 = 𝐾𝑁, where 𝐾 is an integer number and referred as to the overlapping factor. The overlapping factor 𝐾 can be also defined as the ratio of the filter impulse response duration to the multicarrier symbol period 𝑇. In the frequency domain, it is the number of frequency coefficients which are introduced between the FFT filter coefficients [17].

This overlapping factor 𝐾 has an impact on determining the optimum spectrum utilization and the desired stop-band attenuation. Figure 98 shows the power spectral density for OFDM and FBMC for several values of 𝐾. As it can be seen in the figure, a larger value of 𝐾 (𝐾 = 4) is able to achieve better frequency localization and lower out-of-band emissions on adjacent channel. At the contrary, for 𝐾 = 2, the leakage level increases significantly, and is only 10dB lower than OFDM.



The overlapping factor K has also an impact on the FBMC symbol duration. Generally small overlapping factor gives lower pulse duration interesting in case of short burst transmissions or when reliability is required even in mobility situations. The duration of a FBMC burst is given by 𝑇FBMC =

(𝐾𝑁 + (2𝑁symb − 1)𝑁

2)𝑇𝑠, where 𝑁symb is the number of complex FBMC symbols, 𝑁is the FFT size

and 𝑇𝑠 = 1/𝐹𝑠 is the sampling time. For a fixed duration of 1ms slot ( 𝑇FBMC = 1𝑚𝑠), a larger overlapping factor 𝐾 results on lower number of FBMC symbols, and therefore on a lower achieved throughput. In what follows, we outline how the impact of 𝐾 on throughput and on out-of-band emissions has been modeled.

Figure 98: Power spectral Density of OFDM, and FBMC with several values of 𝐾

Modelling the impact of K on the throughput

In FBMC, overlapping factor impacts the number of FBMC symbols that can be transmitted in 1ms slot. K has then an impact on the data that can be transmitted from upper layer (MAC) to the physical layer for 1 TTI, referred to as Transport block (TB) size.

For a given overlapping factor 𝐾, the transport block size is determined for each modulation and coding scheme (MCS) and for the number of allocated RBs. We assume that 3 FBMC symbols are reserved for control data such as synchronisation and channel estimation. These TB sizes are then integrated as LUTs into the simulators and used according to FBMC modulation parameters and MCS.

Modelling the impact of 𝐾 on out-of-band emissions

In order to illustrate the impact of prototype filters in FBMC and the benefits of FBMC over OFDM systems, the interference between adjacent channels is modelled using power spectral density masks. Such interference is modelled by the out of band leakage introduced on adjacent channels, which is determined by the power spectral density (PSD) of OFDM and FBMC modulation with several overlapping factor. In case of overlapping factor K = 4, no out of band emission is assumed since the level of interference is lower than -90 dBc and –100 dBc, respectively.

In case of OFDM and FBMC with K = 2, a simple out of band emissions mask consisting of a floor power level relative to the maximum spectral power density of the transmitted signal is considered in adjacent channels as shown in Figure 99. The average of interference level on adjacent channel is assumed equal to -37 dBc and -44 dBc for 20MHz band in case of OFDM and FBMC K= 2, respectively. We note also that the level of out of band emission power depends on the bandwidth of the transmitted signal. The maximum powers in case of 20MHz, 1 MHz bandwidth as well as 1RB (180 KHz) are given in Table 85.

-15 -10 -5 0 5 10 15-160

-140

-120

-100

-80

-60

-40

-20

0

Frequency [MHz]

Po

we

r sp

ectr

al d

en

sity [d

Bc/H

z]

FBMC K = 4

FBMC K = 3

FBMC K = 2

OFDM



Figure 99: Out-of-band emission mask in case of OFDM and FBMC with K= 2

PHY Max. power in 20 MHz bandwidth

Max. power in 1 MHz bandwidth

Max. power in 1RB (180KHz)

OFDM -37 dBc / 20MHz -51.6 dBc / 1 MHz -59 dBc / 180 KHz

FBMC 𝐾 = 2 -44 dBc/ 20MHz -57 dBc/ 1 MHz -64.4 dBc/ 180 KHz

Table 85: out-of-band emission power with respect to occupied bandwidth

Simulation parameters

Table 86 collects the PHY-MAC parameters used for the simulations. The frame configuration and slot length have been kept fixed but the allocation of slots are adapted to the traffic pattern. When 100% DL traffic is concerned, all slots are DL slots meaning that all the 6 slots of the CFP are allocated to DL. When UL traffic is considered, 2 slots of the CFP are allocated to UL.

Parameter Value

System bandwidth 20 MHz

Total number of RBs 110

Scheduler Time-frequency fair share

MAC superframe length (ms) 10

MAC slot duration (ms) 1

Max number of DL slots in CFP 6

Max number of UL slots in CFP 2

Number of slots in CAP 3

#RB for sub-channels in CAP (contention UL traffic) 6

Application packets size (bytes) 1500

Waveform FBMC (K=2 and 4) ; CP-OFDM (LTE baseline)

Table 86: FBMC PHY and MAC configuration parameters

-40 -30 -20 -10 0 10 20 30 40-40

-35

-30

-25

-20

-15

-10

-5

0

Frequency [MHz]

Po

we

r sp

ect

ral d

en

sity

[dB

c/H

z]

OFDM N = 2048

Out-of-bandemission mask

BW = 20 MHz

-37 dBc

-40 -30 -20 -10 0 10 20 30 40-45

-40

-35

-30

-25

-20

-15

-10

-5

0

Frequency [MHz]

Po

we

r sp

ect

ral d

en

sity

[dB

c/H

z]

FBMC K = 2

BW = 20 MHz

- 44 dBc

Out-of-bandemission mask



3.4.2 Simulation Results

3.4.2.1 FBMC-Based MAC Simulation results

In this section, we present simulation results which have been run to evaluate the performance of the proposed FBMC-MAC design following the assumptions defined in previous section. We first present the performance of non-coexistence scenarios for the two traffic types (full buffer and FTP traffic) and cover the performance for coexistence scenarios in a second step.

3.4.2.1.1 Non-coexistence scenario with full buffer (100 % DL)

Impact of CCA-ED threshold and ISD

In the baseline scenario, different ISDs are considered to evaluate the performance of MAC design in different degrees of network densification with different ED thresholds ranging from -62 dBm to -82 dBm. Figure 100 shows CDFs of normalized UE throughput using both channel access mechanisms FBE and LBE in case of non-fading channel in a single unlicensed 20MHz channel. In Figure 101, the average cell spectral efficiency vs. ED thresholds and ISDs is depicted.

In case of FBE, the activity of most SCs is completely blocked in all cases, as shown by Jain‘s fairness index of channel access which appears on the curves4. It is computed over beacons transmission rate and it indicates how SCs equally share the channel: with ISD = 30 and ED = -82 dBm, a fairness channel access of 0.1 is achieved, meaning that only 10% of SC get a fair channel access while other cells (90%) are blocked. The reason is that FBE uses a fixed timing frame for determining transmit opportunities. Once a SC senses an idle channel, it gets an indefinite channel access and may probably block the activity of surrounding SCs. The users associated with the transmitting cells experience a good SINR and higher achieved throughput compared to LBE. Indeed, in case of LBE, SCs perform a random back-off procedure that allows more fair access to the channel (fairness of channel access 0.8), at the expense of a lower throughput.

For FBE, we observe that increasing ED threshold from -82 dBm to -62 dBm results on increasing the number of channel access opportunities of SCs and the average cell spectral efficiency, even if the percentage of blocked SCs is still high (roughly 60% for ISD = 100 ). In case of LBE, we observe that lowering ED threshold from -62 dBm to -82 dBm improves the performance in terms of throughput (UE throughput and cell throughput) for dense scenarios (ISD = 30 m and 50 m) due to the increases of interference and collision probabilities coming from the overall higher activity of cells. However, with ISD = 100 m, this increase of ED sensitivity improves the throughput of cell-edge UE (still because of interference level reduction) while degrading the throughput of cell-center UE (because more often SCs defer their transmissions).

Regarding ISD variations, we observe that reducing ISD results in performance degradation and the throughput loss is approximately proportional to ISD reduction. Key Performance Indicators (KPIs) for full buffer 100% DL in case of non-fading channel are summarized in Table 87 . We notice also that increasing ED thresholds results in reducing the mean transmission delay in all cases. A noticeable and negative side effect of the SC blocking phenomenon in FBE is the resulting mean delay values which are an order of magnitude higher than the ones obtained with LBE.

4 Legends on curve correspond to fairness channel access; for instance 0.1 means that 10 % of cells only get access to the

channel and send data (90% of cell are completely blocked)



Figure 100: CDFs of DL normalized UE throughput using different ED thresholds and ISDs for FBE and LBE, full buffer 100%DL, No fading

Figure 101: Per-Cell spectral efficiency vs. ED thresholds and ISDs for FBE and LBE, full buffer 100%DL, No fading [baseline].

0 0.1 0.2 0.3 0.40

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1FBE

CD

F

DL Normalized UE Throughput [bps/Hz]

ISD = 100 ED = - 62 dBm

ISD = 50 ED = - 62 dBm

ISD = 30 ED = - 62 dBm

ISD = 100 ED = - 82 dBm

ISD = 50 ED = - 82 dBm

ISD = 30 ED = - 82 dBm

0 0.05 0.1 0.15 0.2 0.250

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1LBE

CD

F


ISD = 100 ED = - 62 dBm

ISD = 50 ED = - 62 dBm

ISD = 30 ED = - 62 dBm

ISD = 100 ED = - 82 dBm

ISD = 50 ED = - 82 dBm

ISD = 30 ED = - 82 dBm

-82 -80 -78 -76 -74 -72 -70 -68 -66 -64 -620.15

0.2

0.25

0.3

0.35

0.4

0.45

0.5

0.55

0.6

CCA - ED threshold [dBm]

FBE, Full buffer 100 % DL

Pe

r-ce

ll sp

ectr

al e

ffic

ien

cy [b

ps/H

z]

ISD = 100 m

ISD = 50 m

ISD = 30 m

0.20.12

0.20

0.39

0.14

0.10

0.22

0.31

0.41

-82 -80 -78 -76 -74 -72 -70 -68 -66 -64 -620.15

0.2

0.25

0.3

0.35

0.4

0.45

0.5

0.55

0.6


LBE, Full buffer 100 % DL

Pe

r-ce

ll sp

ectr

al e

ffic

ien

cy [b

ps/H

z]

ISD = 100 m

ISD = 50 m

ISD = 30 m

0.84

0.85

0.73

0.80 0.79

0.75

0.86

0.82

0.80



Table 87: Performance of FBE and LBE using different ISDs and ED thresholds, Full-buffer 100%DL, No fading

Summary: LBE presents better performance in terms of channel access opportunities as it achieves a more fair coexistence with respect to others operating SCs than FBE. Increasing ED threshold results in more severe interference and may reduce user throughput performance especially in dense deployments. However, in case of FBE, increasing ED threshold it may increase channel access opportunity of SCs and consequently improve throughput performance. The mean transmission delay will be also reduced.

Impact of frequency reuse

In order to reduce the interference between adjacent SCs, we evaluate the performance of FBMC-MAC by considering a frequency reuse pattern of 3, in which adjacent SCs are assigned different 20MHz unlicensed channels.

Figure 102 shows the CDFs of normalized UE throughput using different ISDs, frequency reuse 1 and 3 and with an ED threshold = -62 dBm. As can be seen, using a frequency reuse of 3 partly resolves the phenomenon of blocked SCs as the contention is shared on more resource. Table 88 compares KPIs using frequency reuse of 1 and 3: the overall performance is improved with frequency reuse of 3. The increase of cell spectral efficiency is approximately 2.5 to 3 times higher compared to single channel (Frequency reuse = 1). The mean transmission delay is also significantly reduced as well as better UE- and SC-throughputs and channel access fairness are achieved as shown in Table 88. We note also that using a frequency reuse 3 increases the ISD between SCs operating on the same frequency band, which may reduce the area spectral efficiency as shown in Table 88 especially in case of small density of SCs (ISD = 100 m).

-82 -62 -82 -62 -82 -62 -82 -62 -82 -62 -82 -62

543.13 223.32 432.48 150.14 384.14 81.07 23.57 10.09 12.33 6.029 7.55 4.18

0.171 0.193 0.247 0.29 0.41 0.5 0.188 0.162 0.273 0.235 0.48 0.52

220.00 247.07 114.22 134.08 47.17 57.89 240.82 208.16 125.9 108.65 56.36 60.4

0.073 0.12 0.1 0.18 0.178 0.25 0.631 0.602 0.68 0.6 0.71 0.55

0.087 0.173 0.135 0.27 0.215 0.38 0.72 0.79 0.79 0.819 0.84 0.83

0.09 0.2 0.14 0.31 0.22 0.41 0.73 0.8 0.8 0.82 0.84 0.86

Area spectral efficiency

[bps/Km2/Hz]

LBE

ISD [m] / CCA-ED [dBm] ISD [m] / CCA-ED [dBm]

30 50 100 30 50 100

FBE

Mean Delay [ms]

Reported performance

metrics

Full buffer 100% DL

No fading, FR = 1

Fairness_UE_Th

Fairness_SC_Th

Fairness_access

Per-cell spectral

efficiency [bps/Hz]

0 0.1 0.2 0.3 0.40

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1FBE

CD

F


ISD = 100 Freq_reuse = 1






0 0.05 0.1 0.15 0.2 0.25 0.30

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1LBE

CD

F










Figure 102: CDFs of DL normalized UE throughput using different ISDs (FBE, LBE), CCA-ED = -62 dBm, full buffer 100%DL, No fading, Frequency reuse 1 and 3

Table 88: Performance of FBE and LBE using different ISDs, CCA-ED = -62 dBm, full buffer 100%DL, No fading, Frequency reuse 1 and 3

Summary: Using frequency-reuse principle can improve the performance of FBMC-MAC in terms of throughput and latency and can achieve better fair coexistence among cells due to the spreading of the contention on a wider resource set. For the same reason, the channel access opportunities in case of FBE will be also increased, resulting in mitigating the SC blocking. However, this step requires an additional cell planning in order to distribute the frequency between adjacent SCs.

Impact of fading channel

We consider an uncorrelated TU channel model in order to evaluate the performance in more realistic scenario reflecting the variations of the received signal power in multi-path environments. Figure 103 shows throughput performance under TU channel with frequency reuse 1 and 3 and additional performance results are captured in Table 89. Comparing with the results with no fading in Table 88, we can see that the performance of FBE is significantly improved. The raison is that fading channel may attenuate the signals that results on a channel power level which may fall below ED threshold, resulting in increasing the channel access opportunities of SCs. In case of LBE, no significant improvement is observed due to the use of random backoff procedure.

FR = 1 FR = 3 FR = 1 FR = 3 FR = 1 FR = 3 FR = 1 FR = 3 FR = 1 FR = 3 FR = 1 FR = 3

223.32 97.68 150.14 68.78 81.07 34.45 10.09 5.36 6.029 4.35 4.18 2.26

0.193 0.57 0.290 0.88 0.500 1.26 0.162 0.66 0.235 0.94 0.520 1.38

247.07 242.82 134.08 136.03 57.89 48.677 208.16 280.47 108.65 144.91 60.40 53.27

0.12 0.28 0.18 0.42 0.25 0.52 0.602 0.72 0.6 0.69 0.55 0.72

0.173 0.35 0.27 0.56 0.38 0.66 0.79 0.85 0.819 0.87 0.83 0.92

0.2 0.39 0.31 0.61 0.41 0.69 0.8 0.85 0.82 0.91 0.86 0.95

Per-cell spectral

efficiency [bps/Hz]Area spectral efficiency

[bps/Km2/Hz]

ISD [m] / CCA-ED = -62 dBm / Freq_Reuse (FR)ISD [m] / CCA-ED = -62 dBm / Freq_Reuse (FR)


metrics

Full buffer 100% DL

No fading, FR = {1,3}

Fairness_UE_Th

Fairness_SC_Th

Fairness_access

Mean Delay [ms]

LBE

30 50 100 30 50 100

FBE

0 0.05 0.1 0.15 0.2 0.25 0.3 0.350

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1FBE

CD

F


ISD = 100 - Freq_reuse = 1






0 0.05 0.1 0.15 0.2 0.25 0.30

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1LBE

CD

F










Figure 103: CDFs of DL normalized UE throughput different ISDs for FBE and LBE, CCA-ED = -62 dBm, full buffer 100%DL, uncorrelated TU channel, Frequency reuse 1 and 3

Table 89: Performance of FBE and LBE using different ISDs, CCA-ED = -62 dBm, full buffer 100%DL, uncorrelated TU channel, Frequency reuse 1 and 3

Summary: Channel conditions have an impact on FBMC-MAC performance. Fading channel can improve the performance of FBE since fading channel may attenuate the power of the signal and results in increasing the channel access opportunities.

Impact of FBMC overlapping factor (PHY/MAC analysis)

In order to study the impact of the PHY on the performance of FBMC-MAC design, FBMC modulation with an overlapping factor of 2 (K = 2) and OFDM-based modulation are considered with different ISDs in uncorrelated TU fading channel. This has been simulated for both a single channel and frequency reuse 3 conditions. As previously stated, the design of FBMC filter has an impact on out-of -band emissions level as well as on the achieved throughput. Figure 81 depicts the UE throughput performance using FBMC with K = 2 and ODFM using frequency reuse 1 and 3. In case of frequency-reuse 1, using FBMC K = 2 or OFDM reduce throughput performance in case of dense deployments (ISD =30 and 50 m). The reason lies on the uplink transmission in the CAP where control packets are sent for CQI reports. The access in this frame part is done using a CSMA-CA procedure on 1 MHz-wide sub-channels. Due to the higher level of out-of-band emission for FBMC K=2 and OFDM (-57dBc and -51.6 dBc respectively), UE may defer their CQI report emission because neighboring UE are transmitting in the adjacent sub-channel. However, in case of ISD = 100 m, the UE density decreases and this phenomenon is less likely and FBMC K= 2 presents therefore a small throughput enhancement compared to FBMC K = 4. This is due to larger TB sizes which is approximately 3.5% higher than TB sizes with K = 4. More interestingly, in case of frequency reuse 3, the use of FBMC K=2 or OFDM significantly reduces the throughput performance, due to larger interference levels in adjacent (20MHz) channels; this is especially sensitive for ISD = 30 and 50 m. Table 90 summarizes the overall performance results with FBMC K = 4, K = 2 and OFDM. We notice that there is no significant impact on mean transmission delay with FBMC K = 2 and OFDM compared to FBMC K = 4.


656.79 159.49 281.02 35.62 142.16 42.77 10.315 4.15 5.98 4.63 4.033 2.34

0.225 0.654 0.306 0.961 0.504 1.289 0.198 0.652 0.265 0.974 0.486 1.385

289.09 279.57 141.37 147.95 58.25 49.63 253.68 279.05 122.54 149.91 56.068 53.32

0.223 0.409 0.276 0.558 0.315 0.588 0.654 0.725 0.627 0.723 0.552 0.737

0.26 0.471 0.355 0.668 0.437 0.705 0.808 0.852 0.832 0.882 0.836 0.912

0.281 0.502 0.385 0.706 0.464 0.734 0.805 0.876 0.839 0.933 0.874 0.958

30 50 100

LBE

ISD [m] / CCA-ED = -62 dBm / Freq_Reuse (FR)

Fairness_UE_Th

Fairness_SC_Th

Fairness_access


metrics

Full buffer 100% DL

TU channel FR = {1,3}

Mean Delay [ms]

Per-cell spectral

efficiency [bps/Hz]


[bps/Km2/Hz]

50 10030

ISD [m] / CCA-ED = -62 dBm / Freq_Reuse (FR)

FBE



Figure 104: CDFs of DL normalized UE throughput using different ISDs and different PHYs (FBMC K = {4, 2}, OFDM) for LBE, CCA-ED = -62 dBm, full buffer 100% DL, uncorrelated TU channel, Frequency reuse 1 and 3

Table 90: Performance of LBE with different ISDs and different PHYs (FBMC K = {4, 2}, OFDM), full buffer 100%DL, uncorrelated TU channel, Frequency reuse 1 and 3

Summary: PHY considerations such as modulation type (FBMC, OFDM) and/or FBMC filter design may significantly affect the MAC performance mainly due different out-of-band leakage levels. Reducing the overlapping factor of FBMC filter may results in more adjacent channel leakages and may cause performance degradation of FBMC-MAC especially in case of dense deployment scenarios.

3.4.2.1.2 Non-coexistence scenario with full buffer (80% DL/20%UL)

In this section, we consider a mix of downlink and uplink full buffer traffic to study the performance of the (TDD) MAC design in DL/UL conditions. The split of traffic is assumed 80% for DL and 20% for UL. Only ED threshold of -62 dBm is considered under non fading and uncorrelated TU fading channel.

Figure 82 shows DL and UL normalized UE throughput performances for a non-fading channel. Similar to full buffer 100% DL performance, we also observe better performance of UL/DL throughput using frequency reuse 3 and an increase of channel access opportunities in case of FBE. Because the number of resource blocks scheduled for UL (2 slots) is smaller than for DL (4), the achieved DL throughput is higher than UL throughput. UL transmission experiences higher mean transmission delay compared to DL transmission. We notice also that UL throughput of cell-center UE is higher compared to DL throughput especially in case of ISD = 100 and frequency reuse 3 due to reduce number of UL UE compared to DL UE scheduled in a slot. Indeed, in this UL/DL scenario, we assume that 2 UEs are uplink users, while 8 UEs are downlink users. Consequently, the total bandwidth will

0 0.05 0.1 0.15 0.2 0.250

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1LBE - Freq_reuse = 1

CD

F


FBMC K = 4 FBMC K = 2 OFDM

100 m

50 m

30 m

0 0.05 0.1 0.15 0.2 0.25 0.3 0.350

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1LBE - Freq_reuse = 3

CD

F


100 m

50 m

30 m

FBMC K = 4 FBMC K = 2 OFDM

K = 4 K = 2 OFDM K = 4 K = 2 OFDM K = 4 K = 2 OFDM K = 4 K = 2 OFDM K = 4 K = 2 OFDM K = 4 K = 2 OFDM

10.31 8.97 8.51 5.98 5.54 5.85 4.03 3.96 3.83 4.15 3.75 3.82 4.63 3.06 2.91 2.34 22.02 2.16

0.20 0.17 0.17 0.27 0.25 0.23 0.49 0.51 0.48 0.65 0.58 0.55 0.97 0.88 0.84 1.39 1.47 1.32

253.68 222.22 211.62 122.54 113.00 108.06 56.07 58.37 54.95 279.05 248.91 235.98 149.91 134.99 129.04 53.33 56.54 50.96

0.65 0.64 0.68 0.63 0.63 0.65 0.55 0.55 0.57 0.73 0.66 0.71 0.72 0.63 0.68 0.74 0.72 0.76

0.81 0.81 0.84 0.83 0.84 0.83 0.84 0.83 0.84 0.85 0.85 0.86 0.88 0.88 0.89 0.91 0.93 0.94

0.81 0.81 0.83 0.84 0.84 0.83 0.87 0.87 0.88 0.88 0.89 0.87 0.93 0.94 0.93 0.96 0.96 0.96

100 30 50

Fairness_access

Fairness_SC_Th

100

Mean Delay [ms]

Per-cell spectral


[bps/Km2/Hz]

Fairness_UE_Th


metrics

Full buffer 100% DL

TU channel

LBE LBE

ISD [m] / CCA-ED = -62 dBm / Freq_Reuse = 1 ISD [m] / CCA-ED = -62 dBm / Freq_Reuse = 3

30 50



be shared by 8UEs in DL and 2 UEs in UL resulting in higher resources allocations for UL users and therefore higher throughput. Table 91 summarizes the performance metrics of DL/UL considered scenario. Comparing with the results of 100% DL (Table 88), we can see that the achieved DL throughput with full buffer 100%DL is higher. Indeed, in 100% DL scenario, 6 slots are allocated for DL, however in this case, the split of slots allocated for DL and UL is respectively 4 and 2 out of 6. Hence we notice that the achieved DL throughput is close to proportional to the number of scheduled slots, as expected. Scenario under uncorrelated TU fading channel has been also investigated; even if not included in this document; the results show an improvement of the throughput performance and a reduction of the SC blocking for FBE, as it has been observed for the 100%DL full-buffer scenario. This scenario also confirms the huge disparity between the mean delay values obtained with FBE and LBE, given that many of the SCs have to refrain their transmission in the former case.

Figure 105: CDFs of normalized DL/UL UE throughput using different ISDs of FBE and LBE, CCA-ED = -62 dBm, full buffer 80 % DL/20% UL, No fading, Frequency reuse 1 and 3

0 0.05 0.1 0.15 0.2 0.25 0.30

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1FBE

CD

F








0 0.05 0.1 0.15 0.2 0.25 0.30

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1LBE

CD

F








0 0.1 0.2 0.3 0.4 0.5 0.60

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1FBE

CD

F

UL Normalized UE Throughput [bps/Hz]







0 0.1 0.2 0.3 0.4 0.50

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1LBE

CD

F

UL Normalized UE Throughput [bps/Hz]









Table 91: Performance of FBE and LBE using different ISDs, full buffer traffic 80%DL/20%UL, No fading, Frequency reuse 1 and 3

Summary: In UL/DL full buffer scenario, the achieved DL throughput is higher than UL throughput. This is related to the number of slots scheduled for UL/DL. The achieved DL throughput is proportional to the number of scheduled slots. The number of slots is an important parameter that should be configured depending on the UL/DL traffic load.

3.4.2.1.3 Non-coexistence scenario with FTP Traffic (100 % DL)

In this section, we evaluate the performance of FBMC-MAC design with FTP traffic model considered as bursty traffic model. Compared to full buffer for which there was no retries, this model assumes an infinite number of retries. In the same way as previously, different ISDs and ED thresholds are considered. Two different mean reading time of FTP file (D = 5sec and D = 2 sec) are simulated in the evaluation to study the impact of various traffic loads on the performance.

Impact of CCA-ED threshold and ISD

The CDFs of normalized UE throughput obtained for FBE and LBE using different ISDs and EDs thresholds are shown in Figure 106, considering a mean reading time of 5 sec (D = 5). Per-cell spectral efficiency vs. ED thresholds is also depicted in Figure 107. From Figure 106 and Figure 107, we can see that lowering ED threshold below -62 dBm can improve the performance in terms of user throughput and cell spectral efficiency at the expense of an increase of mean transmission delay (see in Table 92). Similarly to full buffer situation, the number transmit opportunities in FBE increases with higher ED threshold. Generally speaking, lowering the ED threshold reduces the probability of collision and the level of interference, which improves the channel conditions. Consequently, higher MCS can be assigned to UE and reduced number of retransmissions is experienced, leading to an overall better throughput. In LBE, the contention window is updated if at least 80% of packets are not acknowledged. Otherwise, the CW is reset to its minimum value. For this particular access mode, lowering ED threshold results in reducing the number of retransmissions and CW updates. However, it may increase the probability of the SC to defer more often, resulting on an increase of the average transmission delay as shown in Table 92. Similarly to full buffer traffic, increasing ISD improves the MAC performance as the level of interference is lower when ISD is getting higher, irrespective to the ED threshold level.

We notice in Table 92, the larger per-cell throughput achieved in case of FBE. Indeed, FBE suffers


496.35 224.04 208.15 81.81 152.22 23.15 12.151 4.91 6.784 3.338 4.737 2.601

0.17 0.475 0.246 0.712 0.398 0.932 0.161 0.538 0.234 0.883 0.455 1.241

217.88 203.14 113.45 109.58 45.91 35.88 206.15 229.93 108.01 136.02 52.52 47.76

0.182 0.333 0.237 0.48 0.297 0.549 0.703 0.758 0.703 0.781 0.65 0.823

0.225 0.385 0.312 0.569 0.4 0.645 0.832 0.88 0.87 0.925 0.875 0.964

728.28 384.00 293.23 171.10 304.97 88.12 29.09 14.02 17.66 10.89 14.20 10.29

0.066 0.186 0.091 0.252 0.171 0.4 0.05 0.134 0.058 0.201 0.13 0.379

85.13 79.39 42.15 38.83 19.71 15.385 63.58 57.36 26.86 30.91 15.03 14.59

0.199 0.34 0.248 0.48 0.29 0.513 0.645 0.696 0.56 0.683 0.54 0.678

0.217 0.363 0.275 0.512 0.334 0.566 0.711 0.75 0.641 0.749 0.635 0.742

0.25 0.43 0.35 0.62 0.422 0.67 0.842 0.907 0.88 0.968 0.918 0.989

UL Fairness_SC_Th

Fairness_access

UL Per-cell spectral

efficiency [bps/Hz]UL Area spectral

efficiency [bps/Km2/Hz]

UL Fairness_UE_Th

DL Fairness_UE_Th

DL Fairness_SC_Th

UL Mean Delay [ms]

DL Mean Delay [ms]

DL Per-cell spectral

efficiency [bps/Hz]DL Area spectral

efficiency [bps/Km2/Hz]


metrics [Full buffer 80%

DL/20%UL No fading]

FBE LBE

30 50 100 30 50

ISD [m] / CCA-ED = -62 dBm / Freq_Reuse (FR) ISD [m] / CCA-ED = -62 dBm / Freq_Reuse (FR)

100



from SC blocking phenomenon as in full buffer; it means that a small number of SCs are actives and have a definite channel access, which results on low level of interference and good channel conditions. As opposite to full buffer where all users have data, in bursty traffic , the number of served users is variable depending on file reading time, e.g. it may happens that only one user is active at a time. The served user is therefore able to download FTP file in a very small time duration leading to a high achieved throughput up to 60Mbps. Even though users of blocked SCs suffer from zero throughputs, the average per-cell throughput is relatively high due to high data rate achieved by active SCs. In LBE, due to the use of random back-off procedure, SCs may defer more frequently when others SCs are actives. Consequently, this channel access delay of SCs affect the time required to transmit FTP file, resulting on low user throughput compared to FBE but with more fairness between users. Therefore, the throughput-related KPIs should be observed by considering the fairness indexes which are significantly lower in FBE compared to LBE.

Figure 106: CDFs of DL normalized UE throughput of LBE and FBE using different ED thresholds and ISDs, FTP traffic D = 5 sec, No fading [baseline]

Figure 107: Per-cell spectral efficiency vs. ED thresholds and ISDs for FBE and LBE, FTP traffic D = 5 sec, No fading [baseline]. Legends on curve correspond to fairness channel access.

0 0.5 1 1.5 20

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1FBE

CD

F


ISD = 100 ED = - 62 dBm

ISD = 50 ED = - 62 dBm

ISD = 30 ED = - 62 dBm

ISD = 100 ED = - 82 dBm

ISD = 50 ED = - 82 dBm

ISD = 30 ED = - 82 dBm

0 0.2 0.4 0.6 0.80

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1LBE

CD

F


ISD = 100 ED = - 62 dBm

ISD = 50 ED = - 62 dBm

ISD = 30 ED = - 62 dBm

ISD = 100 ED = - 82 dBm

ISD = 50 ED = - 82 dBm

ISD = 30 ED = - 82 dBm

-82 -80 -78 -76 -74 -72 -70 -68 -66 -64 -620.4

0.6

0.8

1

1.2

1.4

1.6

1.8

2

2.2

2.4


FBE, FTP D = 5 sec

Pe

r-ce

ll sp

ectr

al e

ffic

ien

cy [b

ps/H

z]

ISD = 100 m

ISD = 50 m

ISD = 30 m

0.43

0.34

0.20

0.23

0.15

0.14

0.28

0.44

0.35

-82 -80 -78 -76 -74 -72 -70 -68 -66 -64 -620

0.2

0.4

0.6

0.8

1

1.2

1.4


LBE, FTP D = 5 sec

Pe

r-ce

ll sp

ectr

al e

ffic

ien

cy [b

ps/H

z] ISD = 100 m

ISD = 50 m

ISD = 30 m

0.810.81

0.84

0.87

0.83

0.78

0.88

0.79 0.8



Table 92: Performance of FBE and LBE using different ISDs and ED thresholds, FTP traffic D = 5 s, No fading

Summary: In case of FTP traffic, lowering ED threshold below -62 dB results in less interference and collision and can improve the performance of FBMC-MAC. Bursty traffic model results on better overall performance compared to full buffer, as the traffic load is smaller.

Impact of mean reading time

In this section, we evaluate the performance using two mean reading times (D = 2 sec and D = 5 sec). UE throughput performance is depicted in Figure 108. We observe that reducing the mean reading file from 5 to 2 sec results in reducing the throughput performance as expected due to the increases of traffic load. Indeed, reducing mean reading time increases the number of active users at a time, which leads to an increase of channel occupancy by the SCs, resulting on throughput loss in case of FBE. For LBE, this increase of channel occupancy leads to more contention and increases the probability of SCs to defer more frequently resulting on lower achieved throughput.

Table 93 summarizes performance metrics with D = 2 sec and D = 5 sec. We can see from the table that, mean transmission delay is increased with high traffic load (D = 2s etc.), still because the increase of the number of served users and more defer of transmissions by SCs. We notice also that throughput performance is approximately inversely proportional to traffic load.

Figure 108: CDFs of DL normalized UE Throughput using different ISDs for FBE and LBE, CCA-ED = -62 dBm, FTP traffic D = 2 and 5 sec, No fading

-82 -62 -82 -62 -82 -62 -82 -62 -82 -62 -82 -62

1261 511 1175 308 193 141 18.3 8.4 9.86 4.86 6.16 3.23

0.022 0.038 0.029 0.056 0.074 0.086 0.079 0.083 0.122 0.12 0.225 0.18

27.99 49.26 13.5 25.65 8.5 9.898 101.21 107.12 56.41 55.52 25.92 20.78

0.076 0.097 0.115 0.122 0.271 0.216 0.352 0.265 0.329 0.267 0.448 0.295

0.157 0.188 0.242 0.273 0.429 0.452 0.514 0.453 0.461 0.464 0.61 0.534

0.143 0.281 0.207 0.358 0.34 0.439 0.794 0.776 0.806 0.837 0.866 0.879

Fairness_SC_Th

Fairness_access

Fairness_UE_Th

100

Mean Delay [ms]

Per-cell spectral


[bps/Km2/Hz]


metrics

FTP 100% DL [D = 5s]

No fading

FBE LBE

ISD [m] / CCA-ED [dBm] ISD [m] / CCA-ED [dBm]

30 50 100 30 50

0 0.5 1 1.5 20

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1FBE

CD

F


ISD = 100 - D = 5 sec

ISD = 50 - D = 5 sec

ISD = 30 - D = 5 sec

ISD = 100 - D = 2 sec

ISD = 50 - D = 2 sec

ISD = 30 - D = 2 sec

0 0.2 0.4 0.6 0.80

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1LBE

CD

F


ISD = 100 - D = 5 sec

ISD = 50 - D = 5 sec

ISD = 30 - D = 5 sec

ISD = 100 - D = 2 sec

ISD = 50 - D = 2 sec

ISD = 30 - D = 2 sec



Table 93: Performance comparisons for FBE and LBE using different ISDs, CCA-ED = -62 dBm, FTP traffic D = 5, 2 sec, No fading

Summary: In FTP traffic, reducing mean reading time results on increasing the number of arrived users at a time and traffic loads. Consequently the SCs may defer more frequently in case of LBE, resulting on low throughput performance.

3.4.2.1.4 Control (frames) overhead

Control overhead is another important metric to evaluate the efficiency of MAC protocol. For FBMC-MAC, we evaluate the control overhead as the ratio between total amount of control information over total amount of data information. Control information regroups beacon, ACK/NACK, CQI feedbacks and user requests. We consider LBE FBMC-MAC under non-fading channel and with different traffic models. Figure 109 illustrates the percentage of control overhead as a function of ISDs and traffic models. We observe that the control overhead is relatively independent of ISDs. The total overhead is small about 3 to 5 % in all considered cases which reveals the efficiency of the MAC protocol. We can also observe that FTP traffic results in larger overhead due to the ACK/NACK packets.

Figure 109: Control overhead vs ISDs of using different traffic models

3.4.2.1.5 Coexistence scenario with Wifi

In this section, we analyze FBMC-MAC and WiFi coexistence in an outdoor deployment scenario using a shared 20MHz channel. For the evaluation, we consider regular hexagonal layout for FBMC SCs and randomly dropped “WiFi”" APs in the hexagonal area with several densities of “WiFi” APs with respect to FBMC SCs. For FBMC-MAC, only LBE-based access mechanism with a channel occupancy time of 10 ms is simulated. In this simulations, we use a Wifi-like system implementing a simplified DCF CSMA/CA (does not use RTS/CTS mode) with exponential backoff mechanism and TxOP of 5 ms.

D = 2 s D = 5 s D = 2 s D = 5 s D = 2 s D = 5 s D = 2 s D = 5 s D = 2 s D = 5 s D = 2 s D = 5 s

262 511 359.25 308 163.3 141 7.992 8.4 5.251 4.86 3.408 3.23

0.062 0.038 0.097 0.056 0.171 0.086 0.091 0.083 0.13 0.12 0.23 0.18

79.32 49.26 44.88 25.65 19.77 9.898 116.57 107.12 60.97 55.52 26.39 20.78

0.083 0.097 0.116 0.122 0.187 0.216 0.356 0.265 0.334 0.267 0.311 0.295

0.156 0.188 0.244 0.273 0.358 0.452 0.592 0.453 0.621 0.464 0.622 0.534

0.246 0.281 0.333 0.358 0.446 0.439 0.811 0.776 0.816 0.837 0.863 0.879

100

Mean Delay [ms]

Per-cell spectral


[bps/Km2/Hz]


metrics

FTP 100% DL

[CCA-ED = -62 dBm]

No fading

FBE LBE

ISD [m] /Reading time D [s] ISD [m] /Reading time D [s]

30 50 100 30 50

Fairness_SC_Th

Fairness_access

Fairness_UE_Th



Even if the simulated system doesn’t comply with the WiFi standard, it will be denoted as WiFi since it captures the essence of WiFi from a channel access perspective. Full buffer and FTP traffic for FBMC SCs are considered in the evaluation with different ED thresholds (-62 dBm, -82 dBm). Meanwhile, Wifi APs are assumed to be in saturated mode as a worst case scenario. The objective is to study the impact of WiFi on FBMC-MAC performance and to evaluate the fairness of coexistence by comparing the mean channel occupancy time of the 2 systems.

Figure 110 shows the impact of having on WiFi AP per cell on the per-UE throughput in full buffer and FTP traffic. The curves represent the FBMC MAC per UE throughput with and without WIFI; the curves marked as “(WiFi)” correspond to the coexistence case. Due to the shared channel nature, we observe significant throughput degradation compared to non-coexistence scenario. This is particularly visible for FTP traffic because WiFi APs are in saturated mode which is a very “aggressive” traffic pattern in comparison. Table 94 compares KPIs with and without Wifi in case of full buffer traffic. We can see that lowering ED threshold to -82 dBm improves throughput performance. Indeed, using an ED threshold of -62 dBm for both systems may result on severe interference and collision and degrade significantly the throughput performance of FBMC-MAC.

Comparing with the results of FBMC-MAC system, the throughput degradation is about 50% and 70% with ED = -82 dBm and -62 dBm, respectively. This is due to the reduction of channel occupancy of SCs, e.g. in case of ISD = 100 m, the SCs occupy the channel during approximately 52% of time in non-coexistence scenario (-62 dBm), while this channel occupancy is reduced to 33.58% in coexistence scenario. We notice also that Wifi APs occupy the channel for a comparable amount (32.72%).

Figure 110: CDFs of DL normalized UE Throughput using different ISDs and ED thresholds with LBE FBMC-MAC in coexistence scenario, same density of WiFi APs, full buffer and FTP traffic D = 5 sec, No fading

0 0.05 0.1 0.15 0.20

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1LBE, Full buffer

CD

F


ISD = 100 ED = - 62 dBm

ISD = 30 ED = - 62 dBm

ISD = 100 ED = - 82 dBm

ISD = 30 ED = - 82 dBm

ISD = 100 (WiFi) ED = - 62 dBm




0 0.05 0.1 0.15 0.20

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1LBE, FTP D = 5 sec

CD

F


ISD = 100 ED = - 62 dBm

ISD = 30 ED = - 62 dBm

ISD = 100 ED = - 82 dBm

ISD = 30 ED = - 82 dBm







Table 94: Performance of LBE FBMC-MAC in coexistence scenario, same density of WiFi APs, full buffer, No fading

The effect of using asymmetrical ED threshold on the FBMC-MAC performance and on the coexistence with respect to WiFi has also been evaluated. Table 95 captures the impact of varying ED thresholds on FBMC-MAC performance and on channel occupancy of both systems. We can notice that using asymmetrical ED threshold improves the performance of one system at the expense of the other system. Using ED threshold of -82 dBm for LBE and -62 dBm for WiFi increases channel occupancy of Wifi, the channel occupancy of SCs being negligible. Inversely, using ED threshold of -62 dBm for LBE and -82 dBm for WiFi produce an opposite behavior. Using same energy detection threshold allows fair channel occupancy of both systems. Better FBMC-MAC performance is achieved by lowering ED threshold of both systems to -82 dBm.

Table 95: Performance of LBE FBMC-MAC in coexistence scenario, same density of WiFi APs using various ED thresholds, full buffer, No fading

Another important issue is to study the impact of APs density on the performance. We consider a half APs density compared to FBMC-MAC SCs density (an AP is dropped in one SC out of two). Figure 111 illustrates the impact of varying APs density on per-cell spectral efficiency and mean channel occupancy of FBMC-MAC. We note that zero density ratio corresponds to non-coexistence scenario (only FBMC-MAC SCs). From this Figure, we observe that increasing the APs density results on reducing throughput performance and the mean channel occupancy of FBMC-MAC, due to WiFi activity on shared channel.

-82 -62 -82 -62 -82 -62 -82 -62

23.57 10.09 7.55 4.18 30.077 19.864 13.468 18.046

0.188 0.162 0.48 0.52 0.083 0.054 0.249 0.164

240.82 208.16 56.36 60.4 106.515 69.214 28.7 18.984

0.631 0.602 0.71 0.55 0.597 0.514 0.654 0.283

0.72 0.79 0.84 0.83 0.793 0.733 0.805 0.619

0.73 0.8 0.84 0.86 0.809 0.717 0.803 0.685

LBE 10.9 23.4 28.61 51.96 7.83 14.18 16.74 33.58

WiFi - - - - 5.86 12.2 12.18 32.72

ISD [m] / CCA-ED [dBm]

Mean Channel

occupancy %

30

Fairness_access

LBE + WiFi

ISD [m] / CCA-ED [dBm]

30 100100

Mean Delay [ms]

Per-cell spectral


[bps/Km2/Hz]

Fairness_UE_Th

Fairness_SC_Th


metrics

Full buffer 100% DL

No fading. FR = 1

LBE

[-82/-82] [-82/-62] [-62/-82] [-62/-62] [-82/-82] [-82/-62] [-62/-82] [-62/-62]

30.077 1145.93 9.547 19.864 13.468 2483.78 4.27 18.046

0.083 0.002 0.156 0.054 0.249 0.001 0.502 0.164

106.515 2.075 199.752 69.214 28.7 0.098 57.985 18.984

0.597 0.017 0.624 0.514 0.654 0.016 0.534 0.283

0.793 0.122 0.818 0.733 0.805 0.069 0.817 0.619

0.809 0.325 0.833 0.717 0.803 0.094 0.859 0.685

LBE 7.83 0.84 22.65 14.18 16.74 0.056 51.9 33.58

WiFi 5.86 20.7 0.37 12.2 12.18 47.65 0.14 32.72


[bps/Km2/Hz]

Mean Delay [ms]


metrics

Full buffer 100% DL

No fading, FR = 110030

ISD [m], EDLBE / EDWiFi [dBm]

LBE + WiFi

Fairness_SC_Th

Fairness_access

Mean Channel

occupancy %

Fairness_UE_Th

Per-cell spectral

efficiency [bps/Hz]



Figure 111: Per-cell spectral efficiency and mean channel occupancy of LBE FBMAC-MAC vs. APs/SCs density ratio using several ED thresholds and ISDs on coexistence scenario (FBMC-MAC +Wifi), full buffer, No fading

It is also interesting to investigate the impact of FBMC-MAC on WiFi coexistence by replacing FBMC-MAC SCs by WiFi APs. Hence, we consider two operators, operator A and operator B, and we evaluate the mean channel occupancy at the transmitter side of both operators as a measure of the fairness on channel access. Operator A deploys a regular hexagonal grid layout, while operator B deploys a random layout with one SC per “operator A” small cell. We assume that operator B deploys WiFi system, and we consider 4 different steps depending on operator A deployment:

- Case 1: Operator A deploys WiFi system

- Case 2: Operator A deploys FBMC-MAC system

- Case 3: Operator A is inactive (no operator is deployed in the hexagonal grid)

- Case 4: Operator A deploys FBMC-MAC system using different ED threshold than operator B.

We note that in the first 3 cases, both operators use same ED threshold (-62 dBm or -82 dBm). In case 4, an asymmetrical ED threshold is considered. The objective of these cases is to study the effects of switching from WiFi system to FBMC MAC and the impact on the mean channel occupy using different ED threshold and ISDs, by omitting operator A. Figure 112 depicts the obtained the mean channel occupancy of both systems.

We observe that in WiFi+WiFi scenario, the mean channel occupancy is slightly higher for operator A especially for ISD = 100 m. By substituting WiFi by LBE, we can see that the impact of FBMC MAC using LBE on WiFi is not bigger than the one caused by regular WiFi network. We notice that the mean channel occupancy of LBE is higher than WiFi. The reason is that LBE has a CoT of 10ms, while WiFi has a TxOP of 5ms. When operator A is inactive, we observe an increase of channel occupancy of WiFi APs of operator B. We observe in all cases that lowering ED threshold results in reducing the channel occupancy due to the increase of the probability of SCs/APs to defer more frequently. We see also that using asymmetrical ED threshold, increases the mean channel occupancy of the system with the highest ED threshold, e.g. with ED threshold of -62 dBm for WiFi and -82 dBm for LBE (in case 4), the system behaves as operator A is being inactive and operator B deploys only WiFi (case 3). These results confirm that use equal threshold policy leads to an almost fair access of both operators.

0 0.25 0.5 0.75 10

0.1

0.2

0.3

0.4

0.5

0.6

APs/SCs density ratio

Pe

r-ce

ll sp

ectr

al e

ffic

ien

cy [b

ps/H

z]

LBE + WiFi, Full buffer

ISD = 100 m ED = -62dBm

ISD = 100 m ED = -82dBm

ISD = 30 m ED = -62dBm


0 0.25 0.5 0.75 15

10

15

20

25

30

35

40

45

50

55

APs/SCs density ratio

Me

an

ch

an

ne

l occu

pa

ncy (

LB

E)

%

LBE + WiFi, Full buffer

ISD = 100 m ED = -62dBm

ISD = 100 m ED = -82dBm





Figure 112: Mean channel occupancy of both operators (A, B) using several ED thresholds and ISDs on coexistence scenario (FBMC-MAC with LBE + Wifi), full buffer, No fading

Summary: In coexistence scenario, using asymmetrical ED threshold may improves the performance of one system at the expense of the other. Using similar ED threshold results on fair channel occupancy between both systems (FBMC-MAC and WiFi). Lowering ED threshold to -82 dBm improves the performance of FBMC-MAC and results on fair coexistence with WiFi. APs density in the network impacts the performance of FBMC-MAC as high WiFi APs density reduces performance of FBMC-MAC.

3.4.2.1.6 Conclusions

In this section, we have presented the performance evaluations of FBMC MAC for both FBE and LBE mechanisms through varying several parameters (ISDs, ED thresholds, frequency reuse), traffic models and channel conditions. The objective was to study the impact of varying these parameters on the performance in order to carefully adjust FBMC-MAC design parameters to ensure performance enhancement and fair coexistence among SCs and others systems (WiFi).

Based on the simulation results the following conclusions can be drawn:

- LBE presents better performance in terms of channel access opportunities and achieves better fairness among SCs than FBE. This is due to the contention process applied by the SCs which avoids the SC blocking phenomenon observed in FBE. However, for isolated small cells with no coexistence requirement, FBE can be a very interesting solution as it maximises the channel occupancy and therefore the cell throughput.

- Depending on traffic load and inter-site distance between cells, ED threshold should be carefully adjusted to allow for trade-off between performance and good coexistence properties. Interestingly, with LBE and in saturated mode, adopting a low threshold (20 dB below the regulation limit) allows to improve the spectral efficiency (+15%) while degrading the mean delay and marginally affecting the fairness for small ISDs. On the other hand, the



same low threshold has a negative impact for larger ISDs as it reduces the area spectral efficiency and increase the mean delay. In the case of FBE, raising the threshold value helps in resolving poor fairness while gaining in both area spectral efficiency and mean delay; the fairness value still being very small compared to FBE in the same conditions.

- Frequency reuse 3 improves the performance of FBMC-MAC and achieves better fairness among cells at the expense of additional planning requirements. For small ISD values and with LBE, the area spectral efficiency is increased by 35 % when using a frequency reuse of 3 in saturated mode, compared to a frequency reuse of 1.

- PHY layer considerations such as modulation type (FBMC, OFDM) and FBMC filter design may significantly affect the performance due to out of bands leakages of OFDM and non-well design filter. This is particularly true when using a frequency reuse 3 as FBMC outperforms the LTE waveform, providing a gain of almost 20% in terms of area spectral efficiency for small ISDs.

- Coexistence performance with WiFi depends also on traffic types, ED-thresholds and APs density. Reducing ED threshold of both systems to -82 dBm improves the performance of FBMC-MAC compared to ED threshold -62 dBm; both values allow a fair channel occupancy between the two systems provided they use the same ED threshold values.



4 eDSA MAC Strategies

4.1 Introduction

In the following section we focus on comparing the proposed MAC designs for broadband traffic. The main objective of this comparison is to provide a set of guidelines to help selecting appropriate design depending on the context of operation, considering network density, traffic pattern or possible coexistence with other systems when operating unlicensed spectrum. Next, we compare the proposed MAC designs against WiFi in the context of dense and ultra-dense deployments. This comparison is aimed at indicating if the provided designs could compete with the WiFi in the context of dense outdoor deployments.

4.2 eDSA MAC strategy comparison

In the following section we focus on the comparison of the proposed MAC designs. It is worth to remind here that both MAC designs were evaluated on different simulation platforms. In order to obtain comparable results we defined then a common set of simulation parameters and conducted proper calibration (see Section 3.2.1for more detail). Additionally, we defined a common set of performance metrics which enable a direct comparison of both designs (see Section3.2.2).

Similar to Section 3.3 and Section 3.4 we differentiate between two main comparison scenarios: 1) non-coexistence scenario and 2) coexistence scenario. In the non-coexistence scenario we compare both designs when they operate using a dedicated band, i.e., without any other system interfering with their operation. In case of the coexistence scenario we focus on a comparison when both MAC designs need to coexist with another system using a shared spectrum. It is worth to remind here that the coexisting system in this scenario is an LBT based “WiFi-like” system (see Section 3.2.5 for more detail on how the activity of the LBT-based “Wifi-like” system is modelled).

4.2.1 Non-coexistence scenario

We start this section by comparing the system performance for the full buffer traffic model with 100% DL traffic which is then followed by comparison of performance using the FTP and full buffer traffic models, both with 80% of downlink and 20% of uplink traffic.

Figure 113: CDFs of normalized UE throughput for FBMC-MAC (assuming ED threshold of -62dBm) and DCS-MAC (assuming ML of 0.4) for different ISDs and full buffer traffic model with 100%DL traffic



MAC design DCS-MAC FBMC-MAC

ISD [m] 30 50 100 30 50 100

Mean delay [ms] 29.76 22.79 15.24 10.09 6.029 4.18


0.329 0.460 0.818 0.162 0.235 0.520


422.32 212.30 94.48 208.16 108.65 60.40

Fairness_UE_Th 0.761 0.779 0.827 0.602 0.600 0.550

Fairness_SC_Th 0.959 0.963 0.980 0.790 0.819 0.830

Fairness_access 0.989 0.993 0.993 0.800 0.820 0.860

Table 96: Performance comparison of DCS-MAC (assuming ML=0.4) and FBMC-MAC (assuming ED threshold = -62dBm) for various ISDs, full buffer traffic model with 100% DL traffic

Figure 114: CDFs of normalized UE throughput for FBMC-MAC (assuming ED threshold of -62dBm) and DCS-MAC (assuming ML of 0.4) for different ISDs and FTP traffic model with 100%DL traffic and mean inter-arrival

time of 2 sec.


ISD [m] 30 50 100 30 50 100

Mean delay [ms] 21.58 14.72 8.61 8.40 4.86 3.23


0.300 0.420 0.648 0.083 0.120 0.180


385.27 194.17 74.85 107.12 55.52 20.78

Fairness_UE_Th 0.858 0.888 0.918 0.265 0.267 0.295

Fairness_SC_Th 0.960 0.975 0.991 0.453 0.464 0.534

Fairness_access 0.966 0.953 0.926 0.776 0.837 0.879

Table 97: Performance comparison of DCS-MAC (assuming ML=0.4) and FBMC-MAC (assuming ED threshold = -62dBm) for various ISDs , FTP traffic model with 100% DL traffic and mean inter-arrival time of 2 sec.



Figure 115: CDFs of normalized UE throughput for FBMC-MAC (assuming ED threshold of -62dBm) and DCS-MAC (assuming ML of 0.4) for different ISDs and Full-buffer traffic model with 80%DL traffic and 20% UL traffic


ISD [m] 30 50 100 30 50 100

DL traffic

Mean delay [ms] 27.27 20.43 13.51 12.151 6.784 4.737


0.289 0.415 0.736 0.161 0.234 0.455


370.16 191.76 85.01 206.15 108.01 52.52

Fairness_UE_Th 0.760 0.795 0.863 0.703 0.703 0.65

Fairness_SC_Th 0.932 0.947 0.964 0.832 0.870 0.875

Fairness_access 0.997 0.997 0.998 0.842 0.880 0.918

UL traffic

Mean delay [ms] 113.67 67.59 40.44 29.09 17.66 14.2


0.021 0.036 0.083 0.05 0.058 0.13


27.30 16.56 9.61 63.58 26.86 15.03

Fairness_UE_Th 0.559 0.626 0.661 0.645 0.560 0.540

Fairness_SC_Th 0.517 0.545 0.582 0.711 0.641 0.635

Fairness_access 0.984 0.990 0.989 0.842 0.880 0.918

Table 98: Performance comparison of DCS-MAC (assuming ML=0.4) and FBMC-MAC (assuming ED threshold = -62dBm) for various ISDs, full buffer traffic model with 80% DL traffic and 20% UL traffic

The provided results clearly indicate that DCS-MAC outperforms FBMC-MAC in the considered scenario in case of downlink traffic. Interestingly, the results for the 80% Downlink and 20% Uplink traffic indicate that this is not the case with uplink traffic. The main reasons for the worse performance in downlink direction and better performance in uplink direction is related to the employment of the LBT procedure in the FBMC-MAC which prevents channel access when



interference level exceeds a certain value. This works as an advantage in case of uplink traffic which in case of DCS-MAC suffers from excessive interference caused by high-level of SC to SC interference. The possible way of handling the issue of excessive SC to SC interference in case of DCS-MAC would be to lower the limit of maximum level of interference (ML) which permits allocation of physical channels. Alternatively, directional antennas with radiation patterns which limit the impact of interference from neighbouring SCs could be installed.

It is also worth mentioning here that unlike DCS-MAC, the FBMC-MAC frame design does not put a limit on the minimal delay which can be achieved in the system. This can be seen as an advantage particularly in scenarios with low traffic load. In such scenarios FBMC-MAC can achieve lower delays allowing for better responsiveness for time-critical applications.

As mentioned, the main reason for the performance difference between DCS-MAC and FBMC-MAC is the fact that FBMC-MAC is based on the use of the LBT technique. LBT is necessary for the system to operate in the 5GHz UNII band [5]. DCS-MAC on the other hand was designed as a potential LTE replacement for deployment in ultra-dense scenarios. This means that DCS-MAC was aimed to operate in licensed or lightly-licensed bands in which the use of LBT is not mandated and thus allows for the use of techniques which enable more effective utilization of radio resources.

4.2.2 Coexistence scenario

We focus in this section on comparing the system performance for the full buffer traffic model with 100% DL traffic which is considered to be the worst case scenario.

In general, the obtained results confirm that FBMC-MAC was designed specifically for operating in the 5GHz unlicensed band in which it needs to coexist with other LBT-based systems. Even though both designs for the considered settings allow the other system to have the same mean channel occupancy (see Table 96), the FBMC-MAC ensures that all deployed APs of the coexisting system have a chance of gaining access to the system. This does not seem to be the case with DCS-MAC (see Figure 116) which seems to exploit the LBT nature of the coexisting system and thus prevents 50% of APs (in case of ISD=100m) or 70% of APs (in case of ISD=30m) from getting channel access. This fact is then reflected in the better performance of DCS-MAC (see Figure 116) which is obtained at the expense of the other system.

Although, due to regulatory reasons, DCS-MAC in its current form cannot be used in the 5GHz UNII, it could be potentially used in other technology neutral bands, where the use of LBT procedure is not mandated by regulatory bodies. In general, moving towards technology neutral spectrum bands is a global trend and in a near feature network operators could be allowed to deploy different systems in their own spectrum bands. This means that a network operator could decide to deploy LTE based network, DCS-MAC based network or an LBT-based “WiFi-like” based network using the same band. The simulations results suggest that DCS-MAC could successfully operate in such environment without significant performance degradation.



Figure 116: CDFs of normalized UE throughput (left) and channel occupancy of the coexisting system (right) in coexistence scenario for FBMC-MAC (assuming ED threshold of -82dBm) and DCS-MAC (assuming ML=0.2 for

ISD=30m and ML=0.4 for ISD=100m) for Full-buffer traffic model

MAC designs DCS-MAC FBMC-MAC

ISD [m] 30 100 30 100

Mean delay [ms] 59.88 25.95 30.08 13.47


0.150 0.505 0.083 0.249


192.04 58.33 106.52 28.70

Fairness_UE_Th 0.729 0.721 0.597 0.654

Fairness_SC_Th 0.953 0.959 0.793 0.805

Fairness_access 0.955 0.973 0.809 0.803

Channel occupancy of Speed5G Mac design [%]

20.037 40.112 7.830 16.740


6.837 18.917 5.860 12.180

Table 99: Performance comparison of DCS-MAC (assuming ML=0.2 for ISD=30m and ML=0.4 for ISD=100m) and FBMC-MAC (assuming ED threshold = -82dBm) for various ISDs, full buffer traffic model with 100% DL traffic

4.3 eDSA MAC versus legacy systems

In the following section we focus on the comparison of the proposed MAC designs with WiFi. In order to obtain comparable results we used a common set of simulation parameters defined in Section 3.2.3 and conducted proper calibration. The WiFi simulations were conducted using the newest version of the NS-3 simulator [23] with a number of modifications which include implementation of wrap-around and channel model. The simulations were run assuming the newest IEEE 802.11ac amendment with a proper preamble reception model as indicated in [22]. A full set of WiFi



simulations parameters can be found in Table 100 presented below. It is worth reminding here that both WiFi was evaluated without considering MIMO capabilities.

Parameter Value

IEEE 802.11 standard IEEE 802.11ac

Downlink/Uplink transmission scheme 1x1 SISO

STA/AP Rx sensitivity -82.0 dBm

STA/AP CCA Mode1 threshold -62.0 dBm

RTS/CTS Off

Physical layer aggregation (AMPDU) and Block ACKs

On

Channel bonding Not considered (operation over 20.0 MHz channel)

Modeling of preamble reception Considered

Rate adaptation algorithm Mistrel

Beacon period 100ms

Packet size 1500 bytes

MAC layer queue size 2000 packets

Table 100: WiFi specific simulation parameters

Figure 117: CDFs of normalized UE throughput for FBMC-MAC (assuming ED threshold of -62dBm), DCS-MAC (assuming ML of 0.4) and WiFi (IEEE 802.11ac) for different ISDs and Full-buffer traffic model with 100%DL

traffic



ISD [m] 30 50 100

Full buffer DL100%

WiFi (802.11ac) 111.33 44.21 19.49

FBMC-MAC 240.82 125.9 60.40

DCS-MAC 482.80 212.30 94.48

Full buffer DL80% UL20%

WiFi (802.11ac) 101.60 48.29 20.41

FBMC-MAC 207.237 107.506 54.935

DCS-MAC 397.46 208.32 94.62

Table 101: Comparison of average area spectral efficiency (b/s/Hz/Km2) performance for different MAC designs

The provided results clearly indicate that both designs Speed5G designs outperform WiFi in the considered scenario. The main reason for significantly higher performance of the considered designs compared to WiFi is that, in contrast to WiFi, they were specifically design to deal with problems related to dense and ultra-dense deployments. This is not the case with WiFi, which was originally designed as a system for home access. The need for backward compatibility with other existing WiFi devices prevented introduction of mechanisms allowing for better operation in such dense environments. Although, a new IEEE 802.11 Task Group has been recently formed which intend to address problems related with dense deployment, the proposed mechanisms for this purpose, such a BSS coloring, does not seem to provide much improvements [22]. Additionally, they do not seem to address the problem of significant user outage (see Figure 117). This means that the performance of WiFi will not be able to meet requirements of the user demand for traffic. The proposed designs seem to be a good alternative to WiFi.

4.4 Summary

In this section we focused on comparing the proposed MAC designs for broadband traffic. The main objective of this comparison was to provide a set of guidelines to help selecting appropriate design depending on the context of operation, considering network density, traffic pattern or possible coexistence with other systems when operating unlicensed spectrum.

In general it was determined that DCS-MAC provides better overall performance. The main reason for such performance difference is the fact that FBMC-MAC is based on the use of the LBT procedure which is necessary for the system to operate in the 5GHz band [5]. DCS-MAC on the other hand was designed for deployment in ultra-dense scenarios. This means that DCS-MAC was aimed to operate in licensed or lightly-licensed bands in which the use of LBT is not mandated and thus allows for the use of techniques which enable more effective utilization of radio resources. It is worth highlighting here that the LBT procedure, as defined by ETSI, is one of the building blocks of the SPEED-5G framework and could be potentially used by DCS-MAC. It is also worth mentioning here that unlike DCS-MAC, the FBMC-MAC frame design can result in reduced delays, especially in scenarios with low traffic load, where the FBMC-MAC system is able to deliver packets with a lower delay.

As indicated, FBMC-MAC was designed specifically for deployment in 5GHz UNII band, by strictly following the procedures mandated by the regulatory body. This is not the case with the DCS-MAC which without employing LBT-based access could not be used in the 5GHz band. In general, the obtained results for the coexistence scenario confirm that FBMC-MAC was designed specifically for operating in unlicensed bands. This does not seem to be the case with DCS-MAC (see Figure 116, right) which seems to exploit the LBT nature of the coexisting system and thus blocks significant number of coexisting system BSs from obtaining channel access. This fact is reflected in the better performance of DCS-MAC (see Figure 116, left and Table 99) which is obtained at the expense of the other system. In contrast, FBMC-MAC ensures that all deployed BSs of the coexisting system have a



chance of gaining access to the system.

Due to regulatory constraints, DCS-MAC in its current form cannot be used in the 5GHz UNII. However, it could be potentially used in other technology neutral bands. As previously indicated, this may be possible as moving towards technology neutral spectrum bands seems to be a global trend. This means that in a near feature network operators could be allowed to deploy different systems in their own spectrum bands. As the simulations results suggest that DCS-MAC could successfully operate in such environment (especially with an LBT-based system) without significant degradation of performance. This means that a DCS-MAC based system could be deployed in such bands. The investigation of the impact of DCS-MAC on LTE system when operating in such a shared band is left for future study. Potential scenarios which are also currently under considerations are the use of a DCS-MAC based system deployed in the uplink bands of LTE-FDD.

The provided results clearly indicate that both designs Speed5G designs outperform WiFi in the considered scenario. The main reason for significantly higher performance of the considered designs compared to WiFi is that, in contrast to WiFi, they were specifically design to deal with problems related to dense and ultra-dense deployments. In order to fully assess the benefits of using DCS-MAC, or FBMC-MAC over LTE, further investigations of features proposed in the newest release of the LTE standard is necessary. Similar, further investigation of coexistence between FBMC-MAC and WiFi system is necessary. Such investigation could follow the methodology of coexistence assessment between WiFi and LTE-LAA. This is however left as a future work.

The provided comparison clearly shows that both systems complement each other and can be used in parallel. DCS-MAC can be most effectively used in licensed and lightly-licensed bands which do not mandate the use of the LBT procedure, whilst FBMC-MAC can be used in the unlicensed bands such as 5GHz UNII band where peaceful coexistence is mandated by the regulatory bodies.



5 Conclusion

This deliverable presents the protocol specification, the final simulation results and the evaluation of the eDSA MAC design. The MAC specification is presented through procedures (in the form of message sequence charts (MSCs)), and supported with a comprehensive set of primitives, which all have been described. The procedures show, not only the internal behavior of the DCS and FBMC-based MAC protocols, but also the interaction of the different functional blocks in the eDSA MAC framework and with external entities such as 5G-RRC, 5G-RLC and cRRM.

A critical enhancement to the eDSA MAC framework described in this deliverable is the introduction of a new SAP between HMAC and RLC (C_5GRLC_HMAC_SAP). One of the key novelty of SPEED-5G MAC framework is to consider MAC as the RATs aggregation and/or split point as it may lead to better gains with respect to radio resources utilization, enables RAT coordination. Doing so would mean that HMAC could steer control traffic from LTE-A air interface to a 5G air interface, if the interference level at the former is too high to reliably transmit dedicated RRC OTA control messages. This new SAP is used to request for buffer statuses and QoS information of the different active logical channels and use this information to decide how to steer traffic (e.g. user traffic) over the different air interfaces, whilst applying the traffic steering policies from cRRM. In addition, this document gives a detailed description of the two MAC designs (DCS and FBMC MAC) which fit with the MAC framework as possible LMAC entities. The DCS MAC and FBMC MAC protocols specifications are detailed in this deliverable, providing the data, control and command frame formats, information elements and the procedures they have to support like association / de-association, paging, LMAC and PHY configuration, channel selection, traffic steering/offload. A list of primitives covering the generic eDSA procedures and the MAC-specific procedures is also given, the parameters of such primitives are detailed in Appendix A. The algorithms in these procedures and the identified primitives can be prototyped and the key features such as offloading and aggregation be demonstrated.

The other important part of the deliverable is the evaluation of these two MAC protocols. It essentially consisted of analyzing the simulation results obtained on System Level Simulators (SLS). The report starts by defining the evaluation methodology showing notably how the SLS tools can produce comparable results, thanks to a calibration phase. In essence, the MAC evaluation relies on the definition of common simulation parameters on which DCS and FBMC MAC designs are simulated, defining network layout, UE densities, traffic patterns and channel models. The goal of these simulations is on one hand to investigate how the proposed MAC designs perform under similar conditions along what is called the “baseline parameters”; and on the other hand we want to evaluate how the performance of each of protocol can be stressed or improved when using more sophisticated simulations parameters (referred as to “optional parameters”). The two MAC designs are also compared to existing technologies on the layout and parameters of the baseline; the reference technology is WiFi (IEEE 802.11 ax) and the goal is to assess how SPEED-5G MAC designs actually compare to the selected benchmark and figuring out what are the gains provided by the project solutions.

Intrinsically, the results show that FBMC MAC design is able to provide promising results as soon as the SCs adopt an access mode which includes a contention policy (LBE). This allows on one hand to ensure that all the SCs can gain access to the channel ensuring a good fairness, at the expense of a reduced per-UE throughput. Compared to the access mode with no contention (FBE), the fairness obtained in this mode results in better performance in terms of per-cell throughput and area spectral efficiency. Still for the LBE mode, the choice of the CCA threshold used by SCs for the LBT procedure remains important and allows for optimization of the network throughput as a lower thresholds induce reductions of the overall level of interference. The LBE on the hand, provides very interesting results in terms of coexistence with WiFi-like systems. The simulation results show that both such systems and FBMC MAC have fair access to the channel thanks to the LBE approach. As far as FBE is concerned, this rigid channel access for SCs doesn’t look suited to dense networks as it induces major SCs blocking phenomenon, which could be partially resolve by setting a high CCA threshold (at the



expense of a high interference level, though). FBE can be however seen as an interesting solution for isolated SCs operating in unlicensed bands with no coexisting systems (unlicensed or lightly licensed bands) as it maximizes the channel occupancy, providing high per-UE throughput values. Finally the simulations show that the FBMC waveform shows promising features for dense networks when a high frequency reuse patterns are used. Indeed the very low out-of-band leakage level of FBMC helps reduce the interference injected in adjacent channels. When the parameter of overlapping factor of the PHY are appropriately tuned, the FBMC MAC is expected to provides even better results assuming a CP-OFDM physical layer like in LTE-A. Essentially, FBMC MAC appears to be a very interesting solution to exploit unlicensed spectrum band in 5G since it exploits both the spectral confinement of the PHY and the fairness of the LBT feature of the MAC to facilitate the coexistence with other systems.

As far as DCS MAC is concerned, the simulation results show that this novel MAC design seems to be able to efficiently operate in highly dense network deployments. More notably, it exhibits better throughput performance than FBMC MAC under similar conditions. This solution, which has been designed to operate in licensed and lightly licensed bands, requires to appropriately tune key parameters like the maximum acceptable level of interference in order to minimize the number of UEs in outage. DCS MAC design also offers a high level of flexibility to adapt to various offered traffic intensities by adjusting the maximum amount of resource allocated in DCS MAC frames and the number of transceivers used at PHY level. Provided it doesn’t implement a LBT procedure, DCS MAC may have a negative impact on coexisting systems like WiFi by reducing their mean access time but this impact can be significantly reduced using the same tunable parameters. Essentially, DCS-MAC presents a very good solution for 5G systems operating in licensed or lightly licensed bands, in highly dense deployments.

Future steps include further investigation of the performance of these MAC designs, considering other traffic models and/or other network layout like indoor regular grids or hotspots in indoor and outdoor environments. In particular, deeper comparison with LTE-A solutions is also required to better capture the gains provided by the proposed solutions in both cases of aggregation and standalone operation. This MAC design specifications will be prototyped in order to demonstrate first the MAC framework based on the HMAC and LMAC split, highlighting how MAC can be configured by a RRM entity which can affect parameters related to channel access, frame structure, operating channel or measurement collection. The implementation of the MAC designs also aims at validating the features of DCS and FBMC MAC designs and bringing such HW implementation to the project so that they can be used in the demonstration work package. Finally an interesting area would the feasibility analysis of the integration of more recent 5G physical layers candidates like those investigated in other 5G-PPP projects like Fantastic-5G. It would allow to take advantage of cutting edge research in advanced multi-carrier modulations for both the MAC evaluation through simulation and MAC real time implementation.



References

[1] SPEED-5G project deliverable “D5.1: MAC approaches with FBMC and simulation results (first version)” June 2016

[2] SPEED-5G Public Deliverable, “D3.1: SPEED-5G Value chain analysis and system design”, ICT-671705, H2020-ICT-2014-2, Nov. 2016.

[3] SPEED-5G Public Deliverable, “D3.2: SPEED-5G enhanced functional and system architecture, scenarios and performance evaluation metrics”, ICT-671705, H2020-ICT-2014-2, June 2016.

[4] METIS-II, 5G RAN Architecture and Functional Design White Paper, https://metis-ii.5g-ppp.eu/wp-content/uploads/5G-PPP-METIS-II-5G-RANArchitecture-White-Paper.pdf.

[5] ETSI EN 301 893 V1.7.2, Broadband Radio Access Networks (BRAN); 5 GHz high performance RLAN; Harmonized EN covering the essential requirements of article 3.2 of the R&TTE Directive, July 2014.

[6] LTE; Evolved Universal Terrestrial Radio Access (E-UTRA) and Evolved Universal Terrestrial Radio Access Network (E-UTRAN); Overall description; Stage 2 (3GPP TS 36.300 version 13.3.0 Release 13)

[7] Vincent Berg et al., “A flexible radio transceiver for TVWS based on FBMC”, Microprocessors and Microsystems, Volume 38, Issue 8, Part A, November 2014, Pages 743-753.

[8] I. Da Silva et. al, “Tight integration of new 5G air interface and LTE to fulfil 5G requirements”, 2015.

[9] ECMA392 standard: “MAC and PHY for Operation in TV White Space”, June 2012.

[10] A. Benjebbour et.al. “Non-orthogonal Multiple Access (NOMA): Concept, Performance Evaluation and Experimental Trials”, 2015

[11] LTE; General Packet Radio Service (GPRS) enhancements for Evolved Universal Access Network (E-UTRAN) Access; (3GPP TS 23.401 version 13.5.0 Release 13)

[12] Coolpad, “Discussion on the Comparison of LBE and FBE for LBT,” 3GPP TSG RAN WG1 Meeting#79, R1-145132, San Francisco, pp. 1–5, Nov. 2014.

[13] Ericsson, “Further Details on LBT for LAA,” 3GPP TSG RAN WG1 Meeting #80, R1-150584, Athens, pp. 1–6, Feb. 2015

[14] 3GPP TS 36.213, Evolved Universal Terrestrial Radio Access (E-UTRA); Physical layer procedures. Version 14.2.0, March 2017.

[15] 3GPP TS 36.321, Evolved Universal Terrestrial Radio Access (E-UTRA); Medium Access Control (MAC) protocol specification. Version 14.2.1, April 2017.

[16] 3GPP TS 36.814, Evolved Universal Terrestrial Radio Access (E-UTRA); further advancements for E-UTRA physical layer aspects, version 9.2.0, March 2017.

[17] M. Bellanger, FBMC Physical Layer: a primer‖, PHYDYAS, Crowncom, pp. 1-31, 2010.

[18] Lähetkangas, Eeva, et al. "On the TDD subframe structure for beyond 4G radio access network." Future Network and Mobile Summit (FutureNetworkSummit), 2013. IEEE, 2013.

[19] M. Filo, R. Edgar, S. Vahid, R. Tafazolli, “Implications of wrap-around for TGax Scenario 3 and Scenario 4”, Contribution to IEEE 802.11ax; https://mentor.ieee.org/802.11/dcn/15/11-15-1049-01-00ax-implications-of-wrap-around-for-tgax-scenario-3-and-scenario-4.pptx, Sept. 2015.

[20] M. Filo, R. Edgar, S. Vahid, R. Tafazolli, “On TGax Scenario 4 channel model - follow-up”, Contribution to IEEE WG 802.11 TGax; https://mentor.ieee.org/802.11/dcn/15/11-15-1362-00-00ax-on-tgax-scenario-4-channel-model-8211-follow-up.pptx, Nov. 2015

https://metis-ii.5g-ppp.eu/wp-content/uploads/5G-PPP-METIS-II-5G-RANArchitecture-White-Paper.pdf

https://metis-ii.5g-ppp.eu/wp-content/uploads/5G-PPP-METIS-II-5G-RANArchitecture-White-Paper.pdf

https://mentor.ieee.org/802.11/dcn/15/11-15-1049-01-00ax-implications-of-wrap-around-for-tgax-scenario-3-and-scenario-4.pptx

https://mentor.ieee.org/802.11/dcn/15/11-15-1049-01-00ax-implications-of-wrap-around-for-tgax-scenario-3-and-scenario-4.pptx



[21] C. Mehlfhrer, M. Wrulich, J. C. Ikuno, D. Bosanska and M. Rupp, "Simulating the Long Term Evolution Physical Layer," in Proc. of the 17th European Signal Processing Conference (EUSIPCO 2009), Aug. 2009, Glasgow, Scotland.

[22] IEEE WG 802.11, Task Group AX, “TGax Simulation Scenarios”, https://mentor.ieee.org/802.11/dcn/14/11-14-0980-16-00ax-simulation-scenarios.docx

[23] NS-3 system level simulator, https://www.nsnam.org

[24] Takeshi Itagaki, Yuichi Morioka, Masahito Mori, “Performance Analysis of BSS Color and DSC”, Contribution to IEEE WG 802.11, Task Group AX, https://mentor.ieee.org/802.11/dcn/15/11-15-0045-00-00ax-performance-analysis-of-bss-color-and-dsc.pptx

https://www.nsnam.org/



Appendix A Primitives Description

A.1.1 TrafficSteeringConfig.request

TrafficSteeringConfig.request

Sender: 5G-RRC Receiver: HMAC SAP: C_5GRRC_HMAC

Description:

A message from cRRM/5G-RRC to HMAC to trigger traffic offloading and/or radio resources aggregation.

Information element type Value Description

ConfigType U8 1: Offload

2: Aggregation

Type of traffic steering requested by cRRM/5G-RRC.

CellID U8 The ID of the cell to handle the configuration.

UEID U16 ID of the user requiring trafficking offloading or resources aggregation.

RATType U8 1: LTE-A

2: 5G (FBMC)

3: 5G (DCS)

3: Wi-Fi

Indicates which RAT type should be considered for this configuration. This aides in HMAC determining air interface to offload the traffic to or aggregate radio resources on.

LCG U8 Logical Channel Group to be considered for the steering.

BW U8 1: 5MHz

2: 10MHz

3: 20MHz

Channel Bandwidths. [MHz]

BandID U8 Frequency bands of channels to steer traffic to.

PrefChannels U16 Preferred channels to steer to steer traffic to. [MHz]

ForbdChannels U16 Channels forbidden to steer to traffic to. [MHz]

SensingMode U8 Sensing Mode: ED or Preamble

SensingDur U8 Sensing Duration [ms]

DetThreshold U8 Detection Threshold [dBm]

TTL U8 Time-to-liv, indicating the validity of the steering command [ms]

A.1.2 CellMACConfiguration.request

CellMACConfiguration.request




Description:

Generic MAC configurations required to operate 5G-MAC. This configuration includes HMAC, different instances of LMAC and PHY configurations. HMAC will forward LMACConfig to respective LMAC, and LMAC will in turn forward LMACPHYSpecParams to corresponding PHY that it interfaces with.



LMACConfig #i{ List of LMAC Configurations

DCS: See A.3.1

FBMC: See A.2.11

RATType U8 1: LTE-A

2: 5G (FBMC)

3: 5G (DCS)

3: Wi-Fi

Indicates which RAT type should be considered for this configuration. This aids HMAC in tying the config to an air interface to offload the traffic to or aggregate radio resources on.

LMACID U8 Lower MAC ID required to apply the configuration

AirIntferfaceConfig { struct Air Interface configuration

}

LMACSpecParams { struct LMAC Specific Config Parameters

}

LMACPHYSpecParams { struct PHY Specific Config Parameters

}

}

A.1.3 CellMACConfiguration.confirm

CellMACConfiguration.confirm

Sender: HMAC Receiver: 5G-RRC SAP: C_5GRRC_HMAC

Description:

A confirmation of whether 5G-MAC configuration sent via CellMACConfiguration.request has been applied successfully or not.


Status U8 0: Unsuccessful

1: Successful

Status of applying 5G-MAC configuration.

A.1.4 MeasurementConfig.request

MeasurementConfig.request




Description:

Measurement configurations, indicating type of measurements to be performed by the HMAC.



UEID U16 UE IDentity

MeasID U8 Measurement Identity

MeasurementObject #i{

RATType U8 1: LTE-A

2: 5G (FBMC)

3: 5G (DCS)

3: Wi-Fi

RAT Type

LMACID U8 Lower MAC ID required to apply the configuration

BandID Frequency bands of channels to be considered for measurement

ChannelID Channel to be considered for measurement. [MHz]

LogChannelID Logical Channel ID (for traffic vol. measurements)

MeasInfoType U8 RSSI, SINR, BLER, Traffic Volume, Data rate, latency etc.

}

MeasurementReportConfig #i{

Type U8 Periodic/Event based/On-demand

TypeParam U8 Period/threshold

FilteringProcess U8 Averaging, window size, etc.

MeasurementGaps U8 Measurement gaps, relevant in using a single RF to do inter-frequency measurements. [ms]

}

A.1.5 MeasurementConfig.confirm

MeasurementConfig.confirm

Sender: HMAC Receiver: 5G-RRC SAP: C_5GRRC_HMAC

Description:

A confirmation to 5G-RRC/cRRM as to whether the measurement configuration has been successfully applied or not.

Information type Value Description



element

CellID U8 Cell ID that received the measurement configurations-




1: Successful

Status of applying the measurement configuration.

A.1.6 Measurement.request

Measurement.request

Sender: 5G-RRC/cRRM Receiver: HMAC SAP: M_cRRM_HMAC

Description:

This is used to request for a measurement based on already configured measurement Identity.

Information element

type Value Description

CellID U8 Cell ID that received the measurement configurations-



TTR U8 Time-to-Report indicates the time that HMAC should report of the measurement identified by the MeasID

A.1.7 Measurement.confirm

Measurement.confirm

Sender: HMAC Receiver: 5G-RRC/cRRM SAP: M_cRRM_HMAC

Description:

This is used to return measurement requested by cRRM based on Measurement ID

Information element



1: Successful

Indicates whether Measurement.request was successfully handled or not.

CellID U8 Cell ID that received the Measurement.request



MeasInfo {

struct



Value U8* A pointer to the actual measurement data

}

A.1.8 Measurement.indicate

Measurement.indicate


Description:

This is used to report measurement requested cRRM. The reporting could be periodic or event based.

Information element


CellID U8 Cell ID of the cell reporting the measurement



MeasInfo { struct


}

A.1.9 ChannelIdentification.indicate

ChannelIdentification.indicate


Description:

This is used to report channels identified in the spectrum

Information element


CellID U8 Cell ID of the cell reporting the channels

BandID U8 Band ID

ChannelID U8 Identified Channel

RATType U8 1: LTE-A

2: 5G (FBMC)

3: 5G (DCS)

3: Wi-Fi

RAT Type

SensingLevel U8 Level of received power during the selection procedure



A.1.10 HLSignalingMessage.request

HLSignalingMessage.request

Sender: HMAC Receiver: LMAC SAP: C_HMAC_LMAC

Description:

This is used to request for transmission of over-the-air (OTA) RRC messages.

Information element


CellID U8 ID of the cell to receive RRC message in UL or the ID of cell transmitting the RRC message

UEID U16 UE IDentity transmitting (UL) or to receive the RRC message (DL)

LCID U8 Logical Channel ID on which to transmit (UL) or receive the RRC message (DL)

TTL U8 Time-to-live: Longest retention time for the RRC message [ms].

MsgType U8 RRC message type

MsgPDU U8* A pointer to the message buffer

RATType U8 1: LTE-A

2: 5G (FBMC)

3: 5G (DCS)

3: Wi-Fi

RAT Type

LMACID U8 Lower MAC ID required to transmit the RRC message

A.1.11 HLSignalingMessage.indicate

HLSignalingMessage.indicate

Sender: LMAC Receiver: HMAC SAP: C_HMAC_LMAC

Description:

This is used to forward any received over-the-air (OTA) RRC message.

Information element


CellID U8 ID of the cell that transmitted the message (DL)

UEID U16 UE IDentity that transmitted the message (UL)

LCID U8 Logical Channel ID on which RRC message (DL) was received.

MsgType U8 RRC message type

MsgPDU U8* A pointer to the message buffer



RATType U8 1: LTE-A

2: 5G (FBMC)

3: 5G (DCS)

3: Wi-Fi

RAT Type

LMACID U8 Lower MAC ID that received the RRC message

A.1.12 LMACConfiguration.request

LMACConfiguration. request


Description:

This is used configure LMAC and PHY.


LMACID U8 Lower MAC ID

RATType U8 1: LTE-A

2: 5G (FBMC)

3: 5G (DCS)

3: Wi-Fi

RAT Type

AirInterfaceConfig { struct FBMC: See A.2.11

DCS: See A.3.1

}

LMACSpecConfig { struct FBMC: See A.2.11

DCS: See A.3.1

}

LMACPHYSpecConfig { struct FBMC: A.2.11

DCS: See A.3.1

}

A.1.13 LMACConfiguration.confirm

LMACConfiguration.confirm


Description:

This is used to confirm the LMAC and PHY Configuration.



RATType U8 1: LTE-A

2: 5G (FBMC)

RAT Type



3: 5G (DCS)

3: Wi-Fi

AirInterfaceConfig { FBMC: See A.2.12

DCS: See A.3.2

}

LMACSpecConfig{ struct FBMC: See A.2.12

DCS See A.3.2

}

LMACPHYSpecConfig { struct FBMC: See A.2.12

DCS: See A.3.2

}

A.1.14 LMACConfiguration.indicate

LMACConfiguration.indicate


Description:

This is used to indicate of the LMAC and PHY Configuration.



RATType U8 1: LTE-A

2: 5G (FBMC)

3: 5G (DCS)

3: Wi-Fi

RAT Type

LMACSpecParams { struct FBMC: See A.2.13

DCS: See A.3.3

}

LMACPHYSpecParams { struct FBMC: See A.2.13

DCS: See A.3.3

}

A.1.15 PHYConfiguration.request

PHYConfiguration.request

Sender: LMAC Receiver: PHY SAP: C_LMAC_PHY

Description:

This is used to configure PHY




PHY_ID U8 PHY Identity

Band U8 Band Information

ChannelID U8 Channel Identifier

MaxPow U8 Maximum transmist power [dBm]

BW U8 Channel bandwidth (in number of active subcarriers)

PHYSpecParams { struct FBMC: See A.2.14

DCS: See A.3.12

}

A.1.16 PHYConfiguration.confirm

PHYConfiguration.confirm

Sender: PHY Receiver: LMAC SAP: C_LMAC_PHY

Description:

This is used to confirm the configuration of the PHY



1: Successful

Status of the configuration

PHY_ID U8 PHY Identity

Band U8 Band Information




PHYSpecParams { struct FBMC: See A.2.15

DCS: See A.3.13

}


Measurement.request


Description:

This is used to request for measurement data

Information element






TTR U8 Time to Report [ms].


Measurement.confirm


Description:

This is used to report of requested measurement data

Information element



1: Successful

Status of the measurement request



MeasInfo { struct


}

A.1.19 Measurement.indicate

Measurement.indicate


Description:

This is used to report of requested measurement data

Information element




MeasInfo { struct


}


Measurement.request

Sender: HMAC Receiver: PHY SAP: C_HMAC_PHY

Description:

This is used to request for measurement/sensing data

Information element




PHY_ID U8 User ID

ChannelID U8 Channel Info

BandID U8 Band Info

SensingMode U8 Sensing Mode

SensingDur U8 Sensing Duration [ms]

BW U8 Channel BW

StartTime U8 Start Time [ms].


Measurement.confirm

Sender: PHY Receiver: HMAC SAP: C_HMAC_PHY

Description:

This is used to report of requested measurement/sensing data

Information element



1: Successful

Status of the measurement request

PHY_ID U16 User ID

SensingData U8* A pointer to the actual sensing data

A.1.22 RLCBufferStatus.request

RLCBufferStatus.request

Sender: RLC Receiver: HMAC SAP: C_5GRLC_HMAC

Description:

This is used to provide buffer status to HMAC and indicate the readiness to transmit them

Information element


LCG U8 Logical Channel Group

BufferSize U16 Amount of data ready to be transmitted

A.1.23 RLCData.indicate

RLCData.request

Sender: LMAC Receiver: RLC SAP: D_5GRLC_LMAC

Description:

This is used to indicate to RLC about received data

Information type Value Description



element


PDU U8* A pointer to the data received

A.1.24 RLCData.response

RLCData.response

Sender: RLC Receiver: LMAC SAP: D_5GRLC_LMAC

Description:

This is used to provide data LMAC

Information element



PDU U8* A pointer to data to be transmitted

A.2 FBMC-Based MAC Messages

A.2.1 LMACStart.request

LMACStart.request


Description:

To request LMAC to start

Information element


CellID U8 Cell ID

BandID U8 Band ID

BW U8 Channel Bandwidth

ListPrefChannels U8* A pointer to a list of preferred channels

ListForbdChannels U8* A pointer to a list of preferred channels

A.2.2 BeaconReception.indicate

BeaconReception.indicate


Description:

Indication of Received Beacon

Information element


CellID U8 Cell ID

BandID U8 Band ID



ChannelID U8 Frequency channel

BW U8 Channel Bandwidth

OperatorID U8 Operator’s ID

A.2.3 Association.request

Association.request


Description:

Association Request

Information element


UEID U8 Cell ID

CQI U8 Channel Quality Indicator Information

A.2.4 Association.confirm

Association.confirm


Description:

Confirmation to the Association Request

Information element


CellID U8 Cell ID


1: Successful

Status of the Association request

A.2.5 Association.indicate

Association.indicate


Description:

Indication of the Association

Information element


CellID U8 Cell ID

CQI U8 Channel Quality Indicator Information

A.2.6 De -association.indicate

De-association.indicate




Description:

Indication of the De-association

Information element


CellID U8 Cell ID

A.2.7 UEPaging.request

UEPaging.request


Description:

UE Paging Request

Information element


UEID U8 UE IDentifier

A.2.8 UEPaging.response

UEPaging.response


Description:

Response to UE Paging Request

Information element



1: Successful

2. NoAnswer

Status of UE Paging Request

UEID U8 UE IDentifier

A.2.9 SchedFrameTrigger.request

SchedFrameTrigger.request


Description:

Scheduling Frame Trigger request

Information element


SFN U8 SuperFrame Number

NumUEs U8 Number of UEs



UEConfig #i { struct

UEID U8 UE Identifier

LCG U8 Active Logical Channel Groups

BSR U8 Buffer status of Logica Channels in Logical Chanel Groups

}

A.2.10 SchedFrameTrigger.confirm

SchedFrameTrigger.request


Description:

Scheduling Frame Trigger confirmation

Information element




1: Successful

Status of the Scheduling Frame Trigger request


LMACConfiguration.request


Description:




RATType U8 1: LTE-A

2: 5G (FBMC)

3: 5G (DCS)

3: Wi-Fi

RAT Type

AirInterfaceConfig { struct

RATType U8 RAT Type


Action U8 0: OFF

1: ON

To switch off or on

}

LMACPHYSpecParams { struct





FBMCFilter U8 FBMC prototype filter order (enumeration: 2, 3, 4)

ICS U8 Intercarrier spacing [kHz]

Nfft U8 Number of points in FFT (enumeration 256, 512)


}

LMACSpecParams { struct

FrameConfig { struct

BaseDuration U8 Slot Duration [ms]

COTLength U8 SuperFrame Duration [in slots]

CAPLength U8 Duration of CAP [in slots]

DLSlots U8 Number of DL slots in the superframe

ULSlots U8 Number of UL slots in the superframe

InactiveLength U8 Length of the inactive period [ms]

}

SchedulerConfig { struct

Action U8 0: Setup

1: Modify

2: Release

Indicate where scheduler config is to setup, modify or release the scheduling

BW U8 Channel Bandwidth [MHz]

UEID U8 UE ID


SchedSpecParams U8* A pointer to the scheduling Specific Parameters (e.g. choice of scheduler algorithm and etc.)

}

CoexistenceConfig { struct

AccessMode U8 Tx Opportunity determination for the superframe (enumeration: FBE/LBE)

CCAThresh U8 CCA threshold value [dBm]

LBTDuration U8 Duration of listen before talk for superframe CCA [µs]

SensingMethod U8 Sensing method (enumeration: energy, preamble, pattern)

}



ChannelReselConfig { struct

Reason U8 Reason to switch the channel (enumeration: LB, BW)

ChannelID U8 Channel identifier

BW U8 Channel bandwith [MHz]

Countdown U8 Time before channel switching [ms]

}

}




Description:

This is used to confirm the LMAC and PHY Configuration.



RATType U8 1: LTE-A

2: 5G (FBMC)

3: 5G (DCS)

3: Wi-Fi

RAT Type



1: Successful

Status of the Air Interface Configuration

RATType U8 RAT Type


Action U8 0: OFF

1: ON

To switch off or on

}



1: Successful

Status of the PHY Configuration





Nfft U8 Number of points in FFT (enumeration



256, 512)


}




1: Successful

Status of Frame Configuration







}



1: Successful

Status of the Scheduler Configuration

Action U8 0: Setup

1: Modify

2: Release



UEID U8 UE ID



}



1: Successful

Status of coexistence Configuration







}

ChannelReselConfig { struct


1: Successful

Status of the Channel Reselection Configuration

Reason U8 Reason to switch the channel (enumeration: LB, BW)

ChannelID U8 Channel identifier

BW U8 Channel bandwith [MHz]

Countdown U8 Time before channel switching [ms]

}

}




Description:

This is used to indicate the current state the LMAC and PHY Configuration.



RATType U8 1: LTE-A

2: 5G (FBMC)

3: 5G (DCS)

3: Wi-Fi

RAT Type








}











}






}

}




Description:

This is the PHY Configuration.





Nfft U8 Number of points in FFT (256, 512)

}




Description:

This is used to confirm PHY Configuration.








}

A.2.16 PHYPerformCCA.request

PHYPerformCCA.request


Description:

This is used to request for Clear Channel Assessment procedure


ChannelID U8 Channel IDentifier

BW U8 Bandwidth




A.2.17 PHYPerformCCA.confirm

PHYPerformCCA.confirm


Description:

This is used to report of the status for Clear Channel Assessment procedure



1: Successful

Status of the CCA request

ChannelID U8 Channel IDentifier

BW U8 Bandwidth





A.2.18 PHYFrameTransmit.request

PHYFrameTransmit.request


Description:

This is transmit data payload



FrameContent {

DataPayload U8* A pointer to the MSDU

MCS U8 Modulation and coding scheme (enumerate: MCS identifiers)

RBs U8 Resource block where frame has to be mapped

}

A.2.19 PHYFrameTransmit.confirm

PHYFrameTransmit.confirm


Description:

This is to confirm the transmission of the data payload



FrameContent {


1: Successful

Status of the data transmission




}

A.2.20 PHYFrameReceive.indicate

PHYFrameReceive.indicate


Description:

This is to indicate the reception of data payload





Access U8 Superframe part (enumeration: CAP/CFP)

FrameContent {




RSSI U8 Received signal strength indicator [dB]

SNR U8 Signal-to-noise ratio [dB]

}

A.2.21 PerformSensing.request

PerformSensing.request

Sender: HMAC Receiver: PHY SAP: M_HMAC_PHY

Description:

This is used to request for sensing



BandID U8 Band ID


SensingDuration U8 Duration of sensing [µs]

SensingMode U8 Sensing method (enumeration: energy, cyclostationary)

A.2.22 PerformSensing.confirm

PerformSensing.confirm

Sender: PHY Receiver: HMAC SAP: M_HMAC_PHY

Description:

This is used to report the sensing data



BandID U8 Band ID


SensingDuration U8 Duration of sensing [µs]



SensingMode U8 Sensing method (enumeration: energy, cyclostationary)

MeasuredValue U8 Sensed value [dBm]

A.3 DCS-Based MAC Messages


LMACConfiguration.request


Description:




RATType U8 1: LTE-A

2: 5G (FBMC)

3: 5G (DCS)

3: Wi-Fi

RAT Type


RATType U8 RAT Type


Action U8 0: OFF

1: ON

To switch off or on

}



FBMCFilter U8 FBMC prototype filter order (enumeration: 2, 3, 4) (relevant only if FMBC phy is used)




}


BasicConfiguration { struct

BSRelated { Struct



CellID U8 Cell ID

ClusterID U8 Cluster Member ID

OperatorID U8 Operator ID

}

UERelated {


}

BaseSlotDuration U8 Base slot duration [ms]

NumSlots U8 Number of slots in a frame in BaseSlotDuration units

ScanningSequenceID U8 Scanning sequence identifier

}


Action U8 0: Setup

1: Modify

2: Release



UEID U8 UE ID



}


BandConfiguration #i {

BandID U8 Band ID

ChannelList U8* List of frequency channels which can be accessed in a given band

ForbdChannelList U8* List of forbidden frequency channels in a given band


PhyChanSelGranurality U8 Granularity of physical channel selection list [dB]

MaxInterferenceAllowed U8 Maximum level of interference in a physical channel which permits its allocation

MaxLoad U8 Maximum number of physical channels which can be allocated per band



MaxPow U8 Maximum transmit power (in dBm) per frequency channel

BW U8 Bandwidth of frequency channels in a given band

}

}

HandoverInfoConfig { struct

HandoverAlgoParam U8 Handover algorithm specific parameters

}

}




Description:

This is used to confirm configuration of LMAC and PHY.



RATType U8 1: LTE-A

2: 5G (FBMC)

3: 5G (DCS)

3: Wi-Fi

RAT Type



1: Successful

Status of the Air interface configuration

RATType U8 RAT Type


Action U8 0: OFF

1: ON

To switch off or on

}



1: Successful

Status of the PHY configuration

TrxID U8 Transceiver ID


BandID U8 Band ID



MaxPow U8 Maximum Transmit Power [dBm]

FBMCFilter U8 FBMC prototype filter order (enumeration: 2, 3, 4) (relevant only if FMBC phy is used)




}

}




1: Successful

Status of the Basic configuration

BSRelated { Struct

CellID U8 Cell ID

ClusterID U8 Cluster Member ID

OperatorID U8 Operator ID

}

UERelated {


}




}



1: Successful

Status of the Scheduler configuration

Action U8 0: Setup

1: Modify

2: Release



UEID U8 UE ID


SchedSpecParams U8* A pointer to the scheduling Specific



Parameters (e.g. choice of scheduler algorithm and etc.)

}



1: Successful

Status of the Coexistence configuration


BandID U8 Band ID



}

}



}

}




Description:

This is used to indicate current status of LMAC and PHY configuration.



RATType U8 1: LTE-A

2: 5G (FBMC)

3: 5G (DCS)

3: Wi-Fi

RAT Type


RATType U8 RAT Type


Action U8 0: OFF

1: ON

To switch off or on

}




FBMCFilter U8 FBMC prototype filter order (enumeration: 2, 3, 4) (relevant only if FBMC phy is used)



}






}



BandID U8 Band ID




PhyChanSelGranurality U8 Granurality of physical channel selection list [dB]

MaxInterferenceAllowed U8 Maximum level of interference in a physical channel which permits its allocation

MaxLoad U8 Maximum number of physical channels which can be allocated per band

MaxPow U8 Maximum transmist power (in dBm) per frequency channel

BW U8 Bandwidth of frequency channels in a given band

}

}



}



}

A.3.4 RadioBearerEstablish.request

RadioBearerEstablish.request


Description:

This is used to request for Radio Bearer Establishment.


PreambleType U8 Preamble type to distinguish BS from UE transmission

RBID U8 Radio Bearer ID


CellID U8 Cell ID

BandID U8 Band ID

PhyChannelID U8 Channel ID

HandoverIndicator U8 Indicates if a bearer is setup for handover purpose

SlotDuration U8 Slot duration in BaseSlotDuration units

ConnectionControlInfo {

PhyChannelCmd U8 Information about physical channels to be used by non-pilot radio bearers

BW U8 Number of Radio Bearers in UL and DL direction

}

A.3.5 RadioBearerEstablish.confirm

RadioBearerEstablish.confirm


Description:

This is used to confirm Radio Bearer Establishment request.



1: Successful





CellID U8 Cell ID



BandID U8 Band ID







}

A.3.6 RadioBearerEstablish.indicate

RadioBearerEstablish.indicate


Description:

This is used to indicate Radio Bearer Establishment.





CellID U8 Cell ID

BandID U8 Band ID







}

A.3.7 RadioBearerRelease.request

RadioBearerRelease.request




Description:

This is used to request for Radio Bearer Release.





CellID U8 Cell ID

BandID U8 Band ID


Reason U8 Reason for Radio Bearer release (e.g. RB Setup/Handover failed, Normal release, Poor Quality)

A.3.8 RadioBearerRelease.confirm

RadioBearerRelease.confirm


Description:

This is used to confirm Radio Bearer Release request



1: Successful





CellID U8 Cell ID

BandID U8 Band ID



A.3.9 RadioBearerRelease.indicate

RadioBearerRelease.confirm


Description:

This is used to indicate Radio Bearer Release







CellID U8 Cell ID

BandID U8 Band ID



A.3.10 SchedTransmission.request

SchedTransmission.request


Description:

Scheduling Transmission request

Information element


UEConfig #i { struct



BSR U8 Buffer status of Logica Channels in Logical Chanel Groups

}

A.3.11 SchedTransmission.confirm

SchedTransmission.confirm


Description:

Scheduling Transmission confirmation

Information element



1: Successful

Status of the Scheduling Transmission request






Description:

This is the PHY Configuration.





ICS U8 Inter-carrier spacing [kHz]


}




Description:

This is used to confirm PHY Configuration.




1: Successful

Status of the PHY Configuration


BandID U8 Band Identifier

MaxPow U8 Maximum transmit power [dBm]


ICS U8 Inter-carrier spacing [kHz]



}

A.3.14 PHYFrameTransmit.request

PHYFrameTransmit.request



Sender: PHY Receiver: LMAC SAP: D_LMAC_PHY

Description:

This is used to confirm the request for transmission of data.



PhyChannelID U8 Physical Channel ID


TxDuration U8 Duration of transmission in Base Slot Duration units

ControlContent { struct

Payload U8* A pointer to control MSDU


}

DataContent { struct

Payload U8* A pointer to user data MSDU


}

A.3.15 PHYFrameTransmit.confirm

PHYFrameTransmit.confirm


Description:

This is used to confirm the request for transmission of data.



1: Successful

Status of the Transmission request



BandID U8 Band ID


A.3.16 PHYFrameReceive.indicate

PHYFrameReceive.indicate




Description:

This is used to indicate the reception of data (control and/or user data).





TxDuration U8 Duration of transmission in Base Slot Duration units

ControlContent { struct

Payload U8* A pointer to control MSDU





}

DataContent { struct

Payload U8* A pointer to user data MSDU





}

A.3.17 ChannelMeasurement.request

ChannelMeasurement.request


Description:

This is used to request for channel measurement.




BandID U8 Band ID

MeasDuration U8 Duration of sensing in Base Slot



Duration units

MeasMode U8 Sensing method (enumeration: energy, preamble)

A.3.18 ChannelMeasurement.confirm

ChannelMeasurement.confirm


Description:

This is used to confirm the channel measurement request.




BandID U8 Band ID

MeasValue U8 Measured level of interference [dBm]

PreambleDetected U8 Indication if a valid DCS preamble was detected



Appendix B Link-to-system level mapping – Error Model

Link-to-system level mapping has been used in order to employ a PHY abstraction model considered in system level simulators so that the behaviour of multicarrier physical layers are accurately modelled in fast fading conditions, without resorting on link-level simulations. The objective is to get an effective average SINR out of the vector or SINR values on each sub-carrier (or resource block) and to efficiently map this SINR value into a (BLER) PER using lookup tables. The BLER mapping procedure relies on the well-known Mean Mutual information per coded bit (MMIB) effective SINR mapping (ESM) method.

B.1 FBMC-MAC simulation error model

Link level simulations have been conducted in AWGN channel using FBMC based modulations for each MCS to provide lookup tables of BLER vs. SNR curves in case of 20MHz channel bandwidth corresponding to 110 RBs as shown in Figure 119.

Since different RBs could be allocated to the user, it will be difficult to give the LUTs for all allocated RBs. A simplified method is therefore considered in this process, where a correction factor for the effective SINR is applied to accurately predict PER with variable number of RBs. We assume that minimum allocated RBs per user are 5 RBs (equivalent to 1MHz bandwidth). To get the correction factor (CF), we rely on the performance of turbo decoder using different TB sizes. If the Number of RBs is higher than 27 corresponding to 5MHz band, the degradation in terms of performance compared to 20MHz is marginal for all MCSs (CF = 0). Otherwise, the correction factor depends on the MCSs. For low MCS values (<5), CF in the range of [0.5-2] is added to the SINR to compensate the degradation of the performance. After that the obtained SINR effective is used to get the BLER. For further simplification, the correction factor step could be skipped since the degradation is not so high (< 2 dB).

Figure 118 – FBMC-MAC BLER mapping procedure.



Figure 119 - BLER vs. SNR curves in AWGN channel for FBMC (K=4) PHY in 20 MHz.

B.2 DCS MAC simulation error model

For DCS MAC we adopted the same approach as for FBMC-MAC, knowing that the procedure is simplified due to the fact that each UE gets the allocation of the full bandwidth of the channels (i.e. 2 MHz). There is therefore no need to make use of the correction factor introduced in the previous section. The BLER mapping procedure is shown in Figure 120 and the BLER vs. SNR curves for the different MCS considered in the underlying PHY are presented in Figure 121.

Figure 120: DCS MAC BLER mapping procedure.

-30 -20 -10 0 10 20 3010

-3

10-2

10-1

100

SNR [dB]

BL

ER

MCS 1

MCS 2

MCS 3

MCS 4

MCS 5

MCS 6

MCS 7

MCS 8

MCS 9

MCS 10

MCS 11

MCS 12

MCS 13

MCS 14

MCS 15

MCS 16

MCS 17

MCS 18

MCS 19

MCS 20

MCS 21

MMIBESM

Modulation

AWGN BLER vs. SNR LUT

MCS



Figure 121: BLER vs. SNR curves in AWGN channel for the underlying PHY of DCS MAC



Appendix C Generic eDSA Procedures Description

This appendix describes a set of procedures i.e. Network Attachment and Detachment, Tracking Area Update, Radio Access Bearer Management and PDCP and RLC Configuration. These procedures are not MAC-specific procedures, although necessary to trigger certain key procedures in the eDSA MAC, such as traffic steering, monitoring plane measurement collection at the MAC layer, and Inter-RAT coordination of the air interfaces at the LMAC by HMAC. For example, HMAC’s traffic steering of RRC OTA messages at LTE-A to FBMC-Based would require RRC Connection establishment, which in turn would have been triggered by an attach or TAU procedure. This is necessary to ensure backward compatibility to LTE, if for instance one of the air interfaces at the LMAC is of LTE-A. In essence, this facilitates easy deployment of eDSA systems in Network simulators or real systems.

C.1 Network Attachment Procedures

This procedure, shown in Figure 122, relates to the management of the initial attachment of UE and their connection to the SC. This procedure assumes that the cell selection has been completed and the UE is in not EMM-registered and RRC-connected states yet. When the procedure described in this section ends, the UE is considered as both EMM-registered and RRC-connected.

This procedure is initiated by the UE RRC layer, which retrieves the System Information broadcast by the SC in over-the-air (OTA) messages over the broadcast channel. Upon reception of this information, the UE RRC may initiate RRC connection establishment with the message, RRCConnectionRequest towards the SC’s RRC using MAC specific over the air control frames (step #2). Steps #3-4 are related to the actual peer-to-peer RRC communication initiated by the SC RRC to set up the RRC connection (via RRCConnectionSetup message), which will be used by the UE to send an Attach Request in an RRCConnectionSetupComplete message. At this stage, the UE is in RRC and ECM connected modes. The EMM registration is completed, thanks to step #5, in which the RRC Reconfiguration Request is sent by the SC RRC conveying the Attach Accept message. The procedure ends with step #6 which is a confirmation by the UE RRC that the attachment is complete via RRCReconfigurationComplete.



Figure 122: Generic procedure for UE initial attachment and RRC connection establishment



During the procedure depicted in Figure 122, the RRCConnectionRequest may end with a failure status. This is captured in Figure 123, with two possible options:

- Case 1: The SC may not receive the OTA message of the connection establishment request, in which case the HMAC reports back to the UE RRC that no response was received from the SC.

- Case 2: for some reasons, the UE connection request may not be accepted (overloaded SC, MME timer expires). In this case, the SC RRC sends back an RRCConnectionReject to the UE RRC, which terminates the procedure.

Note that this failure procedure can occur during the Tracking Area Update (see section C.3) or the Radio Bearer Establishment (see section C.4).

Figure 123: RRC connection establishment failure



C.2 Network Detachment Procedures

The generic procedure described in this section relates to the case in which a UE is being switched off. The procedure can be subdivided based on the UE state upon detection of such a triggering event. In case a UE is in RRC-Connected and EMM-Registered states when it is being switched off, an RRC layer triggers the procedure for an explicit detach from the network, depicted in Figure 124. To enable backward compatibility with LTE, the proposed procedure in terms of RRC messages being exchanged does not differ from the legacy LTE procedure. The main difference lays in the way RRC messages are being handled by MAC layer and exchanged between SC and UE. These parts are MAC-specific and will be discussed in more detail in the next section. In the case where the UE is in the RRC-Idle and EMM-Registered states, the implicit detach procedure is used (not depicted in Figure 124). In such a case, the decision is made by an MME entity located at the core network. This happens after UE fails to respond to paging or to update the MME about its current location using the periodical tracking area update procedure described in the next section. In contrast to UE initiated explicit detach procedure, no OTA signalling is used and MME simply moves the UE (context) from the EMM-Registered state to the EMM-Deregistered state. For completeness, in the next paragraph we describe the procedure depicted in Figure 124.

The procedure starts with the RRC layer sending NAS Detach request encapsulated in an RRC ULInformationTransfer message to the SC’s RRC entity. The Detach request is then forwarded to the MME entity (not shown in the figure). Assuming that UE is in the EMM-Registered state, the MME confirms NAS Detach Request with NAS Detach Accept which is forwarded back to the UE. The transmission of an RRC DLInformationTransfer message which carries a Detach Accept is followed by RRCConnectionRelease, which finalizes the procedure.



Figure 124: Network detachment procedure

C.3 Tracking Area Update Procedures

The generic procedure described in this subsection relates to the case when the UE is in the RRC-Idle and EMM-Registered states and needs to update the network about its location. The procedure can be either triggered periodically, or if the UE moves in a range of a SC associated with another Tracking Area. Similar to the previous subsection, to enable backward compatibility with LTE, the proposed procedure in terms of the RRC messages exchanged does not differ from the legacy LTE procedure. The main difference lays in the way RRC messages are handled by the MAC layer and exchanged between SC and the UE. These parts are MAC-specific and will be discussed in more detail in the next section. For completeness, in the next paragraph we describe the procedure depicted in Figure 124.

In the first part of the procedure an RRC connection is established. The procedure is triggered by the UE RRC by requesting HMAC entity in the eDSA MAC layer to send RRCConnectionRequest message. The first part of the procedure finishes with the reception of RRCConnectionSetup message by the UE. At this point, the RRC connection between the UE and the SC is established. The second part of the procedure starts with the UE sending the RRCConnectionSetupComplete message. This message confirms the successful establishment of the RRC connection and carries Tracking Area Update (TAU) Request NAS message which is then forwarded by the SC to the MME (not shown in the diagram).



Assuming that UE is in the EMM-Registered state, MME confirms TAU Request with TAU Accept which is forwarded back to the UE. Transmission of an RRC DLInformationTransfer message, which carries TAU Accept message from MME is followed by RRCConnectionRelease, which finalizes the procedure.

Figure 125: Location update procedure



C.4 RAB Management Procedures

C.4.1 UE-initiated RAB establishment procedure

The generic procedure described in this subsection relates to the case when the UE is in the RRC-Idle and EMM-Registered states and establishes a radio access bearer enabling exchange of user data between a network and a UE. To provide backward compatibility with LTE, the proposed procedure in terms of the RRC messages exchanged does not differ from the legacy LTE procedure. The main difference lays in the way RRC messages are handled by the eDSA MAC layer and exchanged between SC and UE. These parts are MAC-specific and will be discussed in more detail in the next section. For completeness, in the next paragraph we describe the procedure depicted in Figure 126.

In the first part of the procedure an RRC connection is established. The procedure is triggered by the UE RRC entity by requesting HMAC to send RRCConnectionRequest message. The first part of the procedure finishes with the reception of RRCConnectionSetup message by the UE. At this point, the RRC connection between UE and SC is established. The second part of the procedure starts with RRCConnectionSetupComplete message sent by the UE. This message confirms successful establishment of the RRC connection and carries NAS Service Request message, which is then forwarded by the SC to the MME (not shown in the diagram). Assuming that UE is in the EMM-Registered state, MME triggers the SC to allocate a Data Radio Bearer for a given UE by initiating RRC reconfiguration procedure. Before RRC reconfiguration is triggered, different security related legacy procedures may need to be performed. The procedure finishes after SC receives the RRCReconfigurationComplete message.

Step #1 in Figure 126 corresponds to the LTE random access procedure and transmission of RRCConnectionRequest message OTA. Step #2 - #5 correspond to procedures necessary for transmission of the RRCConnectioSetup message, RRCConnectionSetupComplete, RRCReconfiguration and RRCReconfigurationComplete messages OTA. This procedure may end with a failure, if the SC is not able to receive or process the RAB establishment requested by the UE. In this case, the RRC connection failure procedure shown in Figure 123 is invoked to terminate the RAB establishment procedure.



Figure 126: UE initiated E-RAB establishment procedure



C.4.2 Network-initiated RAB establishment procedure

The generic procedure described in this subsection relates to the case when network has new data to be transmitted to a UE in the RRC-Idle and EMM-Registered states. Using this procedure, the network can trigger the UE to initiate a connection establishment. Similar to the previous subsection, to enable backward compatibility with LTE, the proposed procedure in terms of the RRC messages exchanged does not differ from the legacy LTE procedure. The main differences lie in the way RRC messages are handled by MAC layer and exchanged between SC and UE. These parts are MAC-specific and will be discussed in more detail in the next section. For completeness, in the next paragraph we describe the procedure depicted in Figure 127.

The procedure starts with the reception of paging message transmitted by the MME located in a core network (not shown in the MSC). As a response, the RRC entity in the SC creates an RRC Paging message with appropriate contents and forwards it to the HMAC entity for transmission. On a successful reception of the RRC Paging message, the RRC entity at the UE triggers the RRC Connection Establishment procedure described in the previous subsection. The procedure finishes with a successful establishment of RRC connection. In the case where the paged UE does not respond to the RRC Paging message, the MME which initiated the process considers the UE to be out of coverage and moves it to EMM-Deregistered state using an implicit detach.

Step #1 in Figure 127 corresponds to transmission of an RRC Paging OTA message.

Figure 127: Network initiated E-RAB establishment procedure 2

C.4.3 E-RAB release procedure

This generic procedure, depicted in Figure 128, relates to the case where the UE is in RRC-Connected state and exchanges data with the network. This procedure is initiated when the HMAC entity on the SC side detects that the UE is inactive. As a result, RRC entity at the SC side 1) triggers the core network entities to release the allocated resources, 2) releases Logical Channels dedicated for the connection, 3) informs the UE about the connection release by sending the RRCConnectionRelease message, and 4) moves to the RRC-Idle state. On the reception of the RRCConnectionRelease message, UE releases the Logical Channels and moves to the RRC-Idle state. Depending on the underlying MAC, RRCConnectionRelease message can be conveyed in different ways. As in the previous subsection, to enable backward compatibility with LTE, the proposed procedure in terms of the RRC messages exchanged does not differ from the legacy LTE procedure.



Figure 128: E-RAB release procedure

C.5 PDCP and RLC Configuration Procedures

This section deals with the configuration of PDCP and RLC layers. This configuration is triggered by RRC and is conveyed via a simple request/confirm message sequence, as shown in Figure 129 and Figure 130. These procedures are the same as the legacy LTE. However, these legacy LTE procedures would have to be enhanced to properly interface with the eDSA MAC and protocol. They are therefore out of scope of this work, but are shown here for the sake of completeness. The RLC configuration covers the logical channel configuration, providing RLC with the logical channel identifier, QoS requirement and ACK policy for instance. The PDCP configuration involves radio bearer to logical mapping, integrity and ciphering configurations.

Figure 129: RLC configuration initiated by RRC

Figure 130: PDCP configuration initiated by RRC

d5.2: mac approaches with fbmc (final)...this framework supports aggregation and radio access...

Documents