Speed5g d5.2 Mac Approaches With FBMC Final

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.
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 CEA
simulations methodology
v0.9 2017-06-13 First review UNIS
v1.0 2017-06-14 Acted on first review on sec 2.1 Intel
and 2.2 and expanded sec 2.5
and Appendix
v1.1 2017-06-16 Revised the Appendix Intel
v1.2 2017-06-22 Modified sec 2.4, 3 (FBMC MAC CEA
results)
v1.3 2017-06-23 Modified sec 2.3 UNIS
v1.4 2017-06-25 Added Introduction, Conclusion, Intel
Executive summary and Abstract
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
© 2015 - 2018 SPEED-5G Consortium Parties Page 2 of 225

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
threshold = -62dBm) for various ISDs , FTP traffic model with 100% DL traffic and mean inter-arrival
time of 2 sec. ....................................................................................................................................... 165

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
FTP traffic model for 100%DL traffic with mean reading time 2sec ................................................... 132
FTP traffic model for 100%DL traffic with mean reading time 5sec ................................................... 132
full buffer 80%DL 20% UL traffic (DL part) .......................................................................................... 134
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
full buffer 80%DL 20% UL traffic (DL part) .......................................................................................... 137
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
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

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.
5GRRC-PHY ctrl.
5GRRC-HMAC ctrl.
5G_RRC
C_cRRM-5GRRC SAP
5GRRC-RLC ctrl.
5GRRC-PDCP ctrl
cRRM
C_5GRRC_5GPDCP SAP
5G-CELL C_5G-X2AP
5G_PDCP
5G-O&M C_5GOAM-cRRM 5GPDCP_5GRLC SAP
5G_RLC
C_SM-cRRM SAP
Spectrum
Manager
C_5GRLC_HMAC SAP
M_HMAC_cRRM SAP
5G_MAC sensing & Measurement

Config.
Sensing Higher_MAC
measurements Reports Results
management
Inter-RAT Coordination
M_cRRM_Config SAP
Configuration
Inter-Rat Coexistence coordination and management
UE Duty-cycle Adaptation MA Coordination Contention coordination
Configuration
Listen - before – Talk (LBT)
C_HMAC_LMAC SAP
CELL
Configuration Frame Format Inter-RAT scheduling coordination
Control Traffic
MAC Sensing Coordination Heterogeneous
Configuration Resource
Channel config Aggregation
Load Balancing
M_LMAC_HMAC SAP
M_PHY_HMAC SAP
D_5GRLC_LMAC SAP
Lower_MAC
Lower-MAC LTE-A Lower-MAC WiFi Lower-MAC 5G_AIV
Scheduling coordination Scheduling coordination

Scheduling coordination
KPI collection Carrier Configuration DRX KPI Collection Channel CP- KPI Collection Logical Channel Manager CP-DRX
Configuration DRX
Coexistance Scheduler Logical Channel Manager Coexistance Coexistance Scheduler Carrier Configuration
Scheduler Preamble Management
RACH
Carrier (1) Carrier (n) Carrier (1) Carrier (n)
UNLICENSED UNLICENSED LICENSED/UNLICENSED/ LICENSED/UNLICENSED/
Component-Carrier (1) Component-Carrier (n) LIGHTLY-LICENSED LIGHTLY-LICENSED
LICENSED LICENSED/UNLICENSED
Time/Freq. - domain Time/Freq. - domain
Time/Freq. - domain Time/Freq. - domain Time/Freq. – domain Time/Freq. – domain
ARQ QoS ARQ QoS
HARQ Ctrl. HARQ Ctrl. HARQ RACH HARQ RACH
QoS QoS QoS Frame QoS Frame
MA Ctrl. MA Ctrl.
TX/RX WIFI
TX/RX LTE-A TX/RX 5G_AIv
RLC-Adaptation
(De) Multiplex (De) Multiplex
(De) Multiplex
(Dis) Assembley (Dis) Assembley
(Dis) Assembley
D_LMAC_PHY SAP
C_LMAC_PHY SAP
Licensed Lightly-Licensed Unlicensed
Buffers Buffers Buffers PHY

Sensing Sensing Sensing
Layer
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 CW  min(CWmax , CWmin  2 N 1 ) , 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 N sel  N RB  N1 ,
where N1  10 and N RB 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 T1  2 sec and is assumed to be the same for both the UE side and the SC side.
Number of required radio

NRB
bearers
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 N RB
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 N sel to limit the number of handover attempts which cannot exceed N 2  15
per RB in a time window T2  3 sec . Furthermore, the number of successful handovers per RB cannot
exceed N 3  10 in a time window T3  3 sec .
It is worth highlighting here that the values of parameters N1 , T1 , N 2 , T2 , N 3 , T3 and the N RB

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
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
DCS-MAC Slot 23
Gap Period (GP) length [us]
for Double Slot 18.75
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 3 OFDM symbols 0-9 OFDM symbols 10-19 OFDM symbols
symbol
Reference Primary allocation Secondary allocation …

signal and block block
Chan. est.
Figure 16: C-Field structure for 2 MHz bandwidth
C-Field U-field
1 OFDM
3 OFDM symbols 0-9 OFDM symbols 10-19 OFDM symbols
symbol
… …
Secondary allocation Secondary allocation
block block
Reference Primary allocation Secondary allocation
…
signal block block
Secondary allocation Secondary allocation
block 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 Primary Header Message Payload CRC
Allocation Block
Message
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
Field type Field Description
Size
Message Type of message carried (e.g. System
3 bits
Type information, System Identity, Paging)
Bi-
directional Indicates if the given transmission is part of a
1 bit
RB bi-directional Radio Bearer
Indicator
ACK of C-field and U-field in symmetric radio
bearers only. When Bi-directional Indicator is
ACK 2 bits
set to 0, this field is used to indicate if data is
carried in the U-field
Number of additional symbols allocated for C-
Length 2 bits
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 Secondary- Message Secondary- … CRC
Control header-1 Payload- header-2
Allocation 1
Block
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

Number of secondary allocation
Length 2 bits
blocks used
Type of message (MIB, SIBs, Identity,
Type 4 bits
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
size
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
Carrier number on which primary transceiver is scanning in the
NextCarrier 5
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
size
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)
MaxInterferenceAllowe Maximum level of interference in a physical channel which
5
d permits its allocation
Maximum number of physical channels which can be allocated
MaxLoad 4
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

Field
Field type size Field Description
Type 2 Type of Identity carried (enumerate: TMSI, IMSI)
User_Id 29 User identifier
Slot Id recommended for access (alternatively this field can be used as a
Slot_ID 4 system information identifier, if user id is set to a special value)
Carrier Id recommended for access (alternatively this field can be used as a
Carrier_ID 5
system information identifier, if user id is set to a special value)
Total
number of 40
bits
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
40
bits
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
Total number of From 10 to
bits 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
4 Number of Physical Channel command carried
command
Type of the first command (enumerate: Listen, Initiate, Active,
Type_1 3 Quality, Good, Poor)
SlotId_1 4 Slot identifier for the first command
CarrierId_1 5 Carrier identifier for the first command
Type of Radio bearer for the first command
RBType_1 1 (symmetric/asymmetric)
… … …
Type of the third command (enumerate: Listen, Initiate, Active,
Type_N 3 Quality, Good, Poor)
SlotId_N 4 Slot identifier for the third command
CarrierId_N 5 Carrier identifier for the third command
Type of Radio bearer for the third command
RBType_N 1 (symmetric/asymmetric)
bits 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
PhyChanSelGranuralit
y 4 Granularity of physical channel selection list (in dB)
MaxInterferenceAllow Maximum level of interference in a physical channel which
ed 5 permits its allocation
Maximum number of physical channels which can be
MaxLoad 4 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
Acknowledgement of U-Field for RB1 in the first half
RB-1 U-Field ACK 1
frame
… … …
RB-N U-Field Acknowledgement of U-Field for RB-N in the first
1
ACK half frame
Acknowledgement of U-Field for RB1 in the second
RB-1 U-Field ACK 1
half frame
… … …
RB-N U-Field Acknowledgement of U-Field for RB-N in the second
1
ACK half frame
bits 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
Number of active asymmetric
RB Number 4 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
CQI for RB1 in the second half
RB-1 CQI 4 frame
… … …
CQI for RB-N in the second half
RB-N CQI 4 frame
Total number of From 12 to N*8
bits +4
Table 22: Channel Quality Indication Type 1 message format
Channel Quality Indication Message Type 2

Number of RB information
RB Number 4 contained in the message
Identifier of asymmetric Radio
RB-1 ID 4 Bearer
RB-1 CQI1 4 CQI for RB1 in the first half frame
CQI for RB1 in the second half
RB-1 CQI2 4 frame
… … …
RB-N ID
RB-N CQI1 4 CQI for RB-N in the first half frame
CQI for RB-N in the second half
RB-N CQ2 4 frame
bits +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
Number of active asymmetric
RB Number 4 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
MCS for RB1 in the second half
RB-1 MCS 4 frame
… … …
MCS for RB-N in the second half
RB-N MCS 4 frame
bits +4
Table 24: MCS Indication Type 1 message format
Modulation and Coding Scheme Indication Message Type 2

Number of RB information
RB Number 4 contained in the message
Identifier of asymmetric Radio
RB-1 ID 4 Bearer
RB-1 MCS1 4 MCS for RB1 in the first half frame
MCS for RB1 in the second half
RB-1 MCS2 4 frame
… … …
RB-N ID
RB-N MCS1 4 MCS for RB-N in the first half frame
MCS for RB-N in the second half
RB-N MCS2 4 frame
bits +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.
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).
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.
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).
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.

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.

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.
CFP CAP
Freq.
Sub-channels
Scheduled downlink
Beacon
Scheduled A Idle
access uplink
C Period
access
K time
Channel occupancy time
Superframe duration
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.
Frame #(i-1) Frame #i Frame #i+1

No emission
time
CCA: CCA:
free busy
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

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 mp Td (µs) CWmin CWmax Allowed CW COT (ms)

option
1 3 16+ 15
63 {15,31,63} 8 ms
mp*9
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.
CCAn CCAn+1
Frame #n: N medium access slots
Freq.
Sub-channels
UE 3 UE 4
Beacon
UE1 U
Idle
UE 5
UE E
UE 1
1 UE 2 Period
2
UE3
UE3
Scheduled downlink Scheduled CAP SC

access uplink ACK
access
Channel occupancy time
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).

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
Frame Dest. Source Sequence Access Payload CRC
Control address address Control Control
MPDU
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 1 byte Number of MSDU considered in this ACK frame
frames
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 11+ 2N bytes (for a frame sent to N UEs),
IE 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 5 bytes See section 2.4.3.12
response IE
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 Indicates the UE to configure a specific
request IE measurement
11 Measurement configuration Confirms the measurement configuration
response IE 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 to switch the channel (0: Load Balancing, 1:
Reason 1 byte
channel reconfiguration)
Channel identifier (definition of channel IDs: out of scope
Channel ID 1 byte
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
Defines the QCI of the service request (as defined in Table
QCI target 1 byte
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

Defines the QCI of the service request (as defined in Table
QCI target 1 byte
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
Uncorrelated lognormal shadowing
Shadow fading model
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
BS: GTX = GRX = 5 dBi
UE/BS Antenna Gain
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.
0.9
CEA
0.8 UNIS
0.7
0.6
CDF
0.5
0.4
0.3
0.2
0.1
0
-110 -100 -90 -80 -70 -60 -50 -40
Coupling gain (Prx - Ptx) [dB]
Figure 80 - Distributions of coupling gain.

1 1
0.9 0.9
CEA CEA
UNIS UNIS
0.8 0.8
0.7 0.7
0.6 0.6
CDF
CDF
0.5 0.5
0.4 0.4
0.3 0.3
0.2 0.2
0.1 0.1
0 0
-10 -5 0 5 10 15 20 25 30 35 40 -30 -20 -10 0 10 20 30 40 50
Wideband SINR (geometry-100% DL) [dB] Uplink SINR (100%UL) [dB]
1
1
0.9
0.9 CEA
CEA
UNIS UNIS
0.8
0.8
0.7
0.7
0.6
0.6
CDF
CDF
0.5 0.5
0.4 0.4
0.3 0.3
0.2 0.2
0.1 0.1
0 0
-40 -30 -20 -10 0 10 20 30 40 50 -30 -20 -10 0 10 20 30 40
Downlink SINR (50%UL, 50%DL) [dB] Uplink SINR (50%UL, 50%DL) [dB]
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.

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.

Parameter Assumption
Simulation run time 100 seconds
Deployment
General EXTENDED UMi (Urban micro-cell scenario) [16]
Duplex method TDD
Downlink/Uplink transmission scheme 1×1 SISO
Network Layout Hexaganonal grid, 1 sector by side
Wrap-around / # rings yes /3 rings
Inter-site distance 30 m, 50 m, 100 m
Carrier frequency 5 GHz
Total system bandwidth 20MHz
UE distribution random distribution WITH a condition on the maximum number of UEs per BS
Baseline: 10 UEs per BS
UE density/drops
Optional: more than 10
Minimum distance (2D distance) Small cell-UE, UE-UE: 3m
User association Strongest RSSI ( pathloss + shadowing)

Downlink scheduler Round robin with full bandwidth allocation
Uplink scheduler Round robin with full bandwidth allocation
BS Tx power 24 dBm (ISD = 100m) - 12 dBm (ISD = 50m) - 9 dBm (ISD = 30m)
UE Tx power 20 dBm (ISD = 100m) - 8 dBm (ISD = 50m) - 5 dBm (ISD = 30m)
Antenna pattern 2D Omni-directional
Antenna height (BS) 10 m (ISD= 100, 50m) 6m (ISD=30m)
Antenna height (UE) 1,5 m
Antenna gain (BS) 5 dBi
Antenna gain (UE) 0 dBi
Channel model
Distance-dependant path loss EXTENDED ITU-R UMi based model with 3D distance between an eNB and a UE
Penetration Loss None

Correlated and non correlated lognormal shadowing with sigma = 3dB (LOS) / 4dB
Shadow fading model
(NLOS)
Baseline: no fast fading
Channel fading model Option: Uncorrelated TU channel model (NLOS) and direct path Rician factor K = 6
dB (LOS)
UE Mobility Not considered ( 0 Km/h)
UE Noise Figure 9 dB
BS Noise Figure 5 dB
Thermal noise spectral density - 174 dBm/Hz
Traffic model
Baseline: 100% DL
DL/UL traffic ratio
Optional: 80% DL +20% UL
Application layer packet size 1500 Bytes
Full buffer Saturated model

File size S = 0,5 Mbytes
FTP traffic
Reading Time D : Exponential distribution, Mean = 5 sec, 2sec , 1sec
MAC level max number of packet Full buffer: 0 (no retransmission)
retransmissions FTP: infinite
Interferer systems
Inter-cell interference modeling Explicit
Baseline: no-adjacent channel leakage
Options: adjacent channel modeling
inter-channel interference 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)
Frequency pattern
Option: reuse=3 (regular allocation of cell frequency on 3 frequencies)
LTE Link to system interface Mutual Information Effective SNIR Mapping (MIESM)
Target BLER 10%
Basic modulation - CQI 4-QAM, 16-QAM, 64-QAM [CQI = 1:15]
Table 68: Simulation parameters for MAC designs comparison

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 Exponential distribution, mean = {1;2;5} seconds
Time D
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 -33dBm (non-coexistence scenario) / variable
channel (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” Values
system parameters
Signal bandwidth 2 MHz
Number of frequency 10
channels
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
0.8 0.6 0.4 0.8 0.6 0.4 0.8 0.6 0.4
Allowed Load (ML)
Mean delay [ms] 24.98 27.94 29.76 21.28 21.97 22.79 15.24 15.13 15.24
Per-cell Spectral 0.432 0.376 0.329 0.566 0.507 0.460 1.012 0.933 0.818
Efficiency [bps/Hz]
Area Spectral
Efficiency 554.33 482.80 422.32 261.61 233.99 212.30 116.84 107.68 94.48
[bps/km2/Hz]
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

Maximum Allowed 0.80 0.60 0.40 0.80 0.60 0.40 0.80 0.60 0.40
Load (ML)
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 0.361 0.345 0.300 0.450 0.428 0.420 0.665 0.674 0.648
efficiency [bps/Hz]
Area Spectral
Efficiency 463.22 442.84 385.27 207.98 197.91 194.17 76.75 77.83 74.85
[bps/km2/Hz]
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
efficiency [bps/Hz]
Area Spectral
Efficiency 357.72 350.40 323.73 151.52 148.07 143.95 42.06 41.69 40.92
[bps/km2/Hz]
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.

80%DL 20% UL traffic (DL part)
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

Maximum Allowed 0.80 0.60 0.40 0.80 0.60 0.40 0.80 0.60 0.40
Load (ML)
DL traffic
Mean delay [ms] 21.96 24.37 27.27 19.10 19.51 20.43 12.95 13.17 13.51
efficiency [bps/Hz]
Area Spectral
Efficiency 505.94 441.76 370.16 232.57 214.45 191.76 111.12 99.85 85.01
[bps/km2/Hz]
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
efficiency [bps/Hz]
Area Spectral
Efficiency 27.59 27.96 27.30 15.20 15.51 16.56 11.17 10.88 9.61
[bps/km2/Hz]
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
Per-cell spectral efficiency 0.329 0.317 0.460 0.459 0.818 0.801
[bps/Hz]
Area Spectral Efficiency 422.32 407.25 212.30 211.84 94.48 92.49
[bps/km2/Hz]
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.

80%DL 20% UL traffic (DL part)
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

Maximum
Allowed Load 0.4 0.3 0.2 0.4 0.3 0.2 0.4 0.3 0.2
(ML)
Mean delay [ms] 39.27 42.31 59.88 29.50 43.82 73.70 25.95 31.28 60.18
Per-cell spectral
efficiency 0.248 0.217 0.150 0.339 0.214 0.126 0.505 0.365 0.221
[bps/Hz]
Area Spectral
Efficiency 318.05 277.80 192.04 156.44 98.92 58.17 58.33 42.13 25.50
[bps/km2/Hz]
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 0.399 0.299 0.200 0.400 0.299 0.199 0.401 0.300 0.201
occupancy DCS
Channel 0.021 0.029 0.068 0.089 0.163 0.234 0.189 0.257 0.319
occupancy WiFi
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 -33.00 -63.00 -73.00 -33.00 -63.00 -73.00 -33.00 -63.00 -73.00
Interference (MI)
Mean delay [ms] 56.35 57.20 22.68 63.31 63.32 42.17 41.92 40.66 28.56
Per-cell spectral
efficiency 0.150 0.149 0.181 0.126 0.127 0.159 0.221 0.223 0.271
[bps/Hz]

Area Spectral
Efficiency 192.04 191.04 232.39 58.17 58.73 73.60 25.50 25.79 31.30
[bps/km2/Hz]
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 0.200 0.200 0.175 0.199 0.201 0.193 0.201 0.198 0.195
occupancy DCS
Channel 0.068 0.073 0.090 0.234 0.234 0.242 0.319 0.321 0.332
occupancy WiFi
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

FBMC-MAC design FBE / LBE FBE / LBE
Inter-side-distance (ISD) {30, 50, 100 } m {30, 50, 100 } m
FBMC K = 4
CCA –ED threshold {-62, -72, -82 } dBm -62 dBm

Frequency reuse 1 and 3 1 and 3
No fast fading [Baseline] No fast fading [Baseline]
Channel Fading Model
Uncorrelated TU [-62 dBm] Uncorrelated TU[-62 dBm]
Table 80: Full Buffer - Non coexistence scenario cases
Full-buffer 100 % DL
FBMC-MAC design LBE
Wi-Fi DCF - CSMA/CA
FBMC K = 4
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
FBMC-MAC design LBE
FBMC K = 2
Inter-side-distance (ISD) {30, 50, 100 } m

CCA –ED threshold {-62 } dBm
Frequency reuse 1 and 3
Channel Fading Model Uncorrelated TU
FBMC-MAC design LBE
OFDM
CCA –ED threshold {-62 } dBm

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

FBMC-MAC design FBE / LBE
Mean file reading time D {2 , 5} sec
FBMC K = 4

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

FBMC-MAC design LBE
Wi-Fi (Full buffer) DCF - CSMA/CA
FBMC K = 4
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.
0
FBMC K = 4
FBMC K = 3
-20
FBMC K = 2
Power spectral density [dBc/Hz]
OFDM
-40
-60
-80
-100
-120
-140
-160
-15 -10 -5 0 5 10 15
Frequency [MHz]
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.

OFDM N = 2048 FBMC K = 2

0 0
-5 -5
-10

-10
-15
-15 BW = 20 MHz BW = 20 MHz
-20
-20
-25
-25 -37 dBc - 44 dBc
-30
Out-of-band Out-of-band
-30 emission mask emission mask
-35
-35 -40
-40 -45
-40 -30 -20 -10 0 10 20 30 40 -40 -30 -20 -10 0 10 20 30 40
Frequency [MHz] Frequency [MHz]
Figure 99: Out-of-band emission mask in case of OFDM and FBMC with K= 2
Max. power in 20 Max. power in 1 MHz Max. power in 1RB

PHY
MHz bandwidth bandwidth (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

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)

FBE LBE
1 1
0.9 0.9
0.8 ISD = 100 ED = - 62 dBm 0.8 ISD = 100 ED = - 62 dBm

ISD = 50 ED = - 62 dBm ISD = 50 ED = - 62 dBm
0.6 0.6 ISD = 50 ED = - 82 dBm
ISD = 50 ED = - 82 dBm
CDF
ISD = 30 ED = - 82 dBm
CDF
ISD = 30 ED = - 82 dBm
0.5 0.5
0.4 0.4
0.3 0.3
0.2 0.2
0.1 0.1
0 0
0 0.1 0.2 0.3 0.4 0 0.05 0.1 0.15 0.2 0.25
DL Normalized UE Throughput [bps/Hz] DL Normalized UE Throughput [bps/Hz]
Figure 100: CDFs of DL normalized UE throughput using different ED thresholds and ISDs for FBE and LBE, full
buffer 100%DL, No fading
FBE, Full buffer 100 % DL LBE, Full buffer 100 % DL

0.6 0.6
ISD = 100 m ISD = 100 m
0.55
Per-cell spectral efficiency [bps/Hz]
ISD = 50 m
ISD = 50 m 0.55 0.85 0.86

ISD = 30 m 0.41 ISD = 30 m
0.5 0.5 0.84
0.39
0.45 0.45
0.22
0.4 0.4
0.35 0.35
0.3 0.31 0.3 0.80 0.79

0.14 0.20
0.25 0.25 0.82
0.2 0.10 0.12 0.2 0.2 0.73 0.75

0.80
0.15 0.15
-82 -80 -78 -76 -74 -72 -70 -68 -66 -64 -62 -82 -80 -78 -76 -74 -72 -70 -68 -66 -64 -62
CCA - ED threshold [dBm] CCA - ED threshold [dBm]
Figure 101: Per-Cell spectral efficiency vs. ED thresholds and ISDs for FBE and LBE, full buffer 100%DL, No fading
[baseline].

FBE LBE
Reported performance
metrics ISD [m] / CCA-ED [dBm] ISD [m] / CCA-ED [dBm]
Full buffer 100% DL 30 50 100 30 50 100
No fading, FR = 1
-82 -62 -82 -62 -82 -62 -82 -62 -82 -62 -82 -62
Mean Delay [ms] 543.13 223.32 432.48 150.14 384.14 81.07 23.57 10.09 12.33 6.029 7.55 4.18
Per-cell spectral
0.171 0.193 0.247 0.29 0.41 0.5 0.188 0.162 0.273 0.235 0.48 0.52
efficiency [bps/Hz]
Area spectral efficiency
220.00 247.07 114.22 134.08 47.17 57.89 240.82 208.16 125.9 108.65 56.36 60.4
[bps/Km2/Hz]
Fairness_UE_Th 0.073 0.12 0.1 0.18 0.178 0.25 0.631 0.602 0.68 0.6 0.71 0.55
Fairness_SC_Th 0.087 0.173 0.135 0.27 0.215 0.38 0.72 0.79 0.79 0.819 0.84 0.83
Fairness_access 0.09 0.2 0.14 0.31 0.22 0.41 0.73 0.8 0.8 0.82 0.84 0.86
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).
FBE LBE
1 1
0.9 0.9
0.8 0.8
0.7 0.7
0.6 0.6
CDF
CDF
0.5 0.5
ISD = 100 Freq_reuse = 1
0.4 0.4 ISD = 100 Freq_reuse = 1
ISD = 50 Freq_reuse = 1 ISD = 50 Freq_reuse = 1
0.3 ISD = 30 Freq_reuse = 1 0.3 ISD = 30 Freq_reuse = 1
0.2 ISD = 50 Freq_reuse = 3 0.2 ISD = 50 Freq_reuse = 3
0.1 0.1
0 0
0 0.1 0.2 0.3 0.4 0 0.05 0.1 0.15 0.2 0.25 0.3

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
Reported performance FBE LBE

metrics ISD [m] / CCA-ED = -62 dBm / Freq_Reuse (F R) ISD [m] / CCA-ED = -62 dBm / Freq_Reuse (F R)
Full buffer 100% DL 30 50 100 30 50 100
No fading, FR = {1,3}
FR = 1 FR = 3 FR = 1 FR = 3 FR = 1 FR = 3 FR = 1 FR = 3 FR = 1 FR = 3 FR = 1 FR = 3
Mean Delay [ms] 223.32 97.68 150.14 68.78 81.07 34.45 10.09 5.36 6.029 4.35 4.18 2.26
Per-cell spectral
0.193 0.57 0.290 0.88 0.500 1.26 0.162 0.66 0.235 0.94 0.520 1.38
efficiency [bps/Hz]
247.07 242.82 134.08 136.03 57.89 48.677 208.16 280.47 108.65 144.91 60.40 53.27
[bps/Km2/Hz]
Fairness_UE_Th 0.12 0.28 0.18 0.42 0.25 0.52 0.602 0.72 0.6 0.69 0.55 0.72
Fairness_SC_Th 0.173 0.35 0.27 0.56 0.38 0.66 0.79 0.85 0.819 0.87 0.83 0.92
Fairness_access 0.2 0.39 0.31 0.61 0.41 0.69 0.8 0.85 0.82 0.91 0.86 0.95
Table 88: Performance of FBE and LBE using different ISDs, CCA-ED = -62 dBm, full buffer 100%DL, No fading,
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.
FBE LBE
1 1
0.9 0.9
0.8 0.8
0.7 0.7
0.6 0.6
CDF
CDF
0.5 0.5
0.4 ISD = 100 - Freq_reuse = 1 0.4

ISD = 50 - Freq_reuse = 1 ISD = 100 - Freq_reuse = 1
0.3 ISD = 30 - Freq_reuse = 1 0.3 ISD = 50 - Freq_reuse = 1
0.1 0.1
ISD = 30 - Freq_reuse = 3
0 0
0 0.05 0.1 0.15 0.2 0.25 0.3 0.35 0 0.05 0.1 0.15 0.2 0.25 0.3

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

metrics ISD [m] / CCA-ED = -62 dBm / Freq_Reuse (F R) ISD [m] / CCA-ED = -62 dBm / Freq_Reuse (F R)
Full buffer 100% DL 30 50 100 30 50 100
TU channel FR = {1,3}
FR = 1 FR = 3 FR = 1 FR = 3 FR = 1 FR = 3 FR = 1 FR = 3 FR = 1 FR = 3 FR = 1 FR = 3
Mean Delay [ms] 656.79 159.49 281.02 35.62 142.16 42.77 10.315 4.15 5.98 4.63 4.033 2.34
Per-cell spectral
0.225 0.654 0.306 0.961 0.504 1.289 0.198 0.652 0.265 0.974 0.486 1.385
efficiency [bps/Hz]
289.09 279.57 141.37 147.95 58.25 49.63 253.68 279.05 122.54 149.91 56.068 53.32
[bps/Km2/Hz]
Fairness_UE_Th 0.223 0.409 0.276 0.558 0.315 0.588 0.654 0.725 0.627 0.723 0.552 0.737
Fairness_SC_Th 0.26 0.471 0.355 0.668 0.437 0.705 0.808 0.852 0.832 0.882 0.836 0.912
Fairness_access 0.281 0.502 0.385 0.706 0.464 0.734 0.805 0.876 0.839 0.933 0.874 0.958
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.

LBE - Freq_reuse = 1 LBE - Freq_reuse = 3

1 1
30 m
0.9 0.9 30 m
50 m
0.8 0.8
50 m
0.7 100 m 0.7
100 m
0.6 0.6
CDF
CDF
0.5 0.5
0.4 0.4
0.3 0.3
0.2 FBMC K = 4 0.2 FBMC K = 4

FBMC K = 2 FBMC K = 2
0.1 OFDM 0.1 OFDM
0 0
0 0.05 0.1 0.15 0.2 0.25 0 0.05 0.1 0.15 0.2 0.25 0.3 0.35
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
LBE LBE
metrics ISD [m] / CCA-ED = -62 dBm / Freq_Reuse = 1 ISD [m] / CCA-ED = -62 dBm / Freq_Reuse = 3
Full buffer 100% DL 30 50 100 30 50 100
TU channel
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
Mean Delay [ms] 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
Per-cell spectral
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
efficiency [bps/Hz]
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
[bps/Km2/Hz]
Fairness_UE_Th 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
Fairness_SC_Th 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
Fairness_access 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
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

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.
FBE LBE
1 1
0.9 0.9
0.8 0.8
0.7 0.7
0.6 0.6
CDF
0.5 CDF 0.5
0.4 ISD = 100 - Freq_reuse = 1 0.4

0.1 0.1 ISD = 50 - Freq_reuse = 3
0 0
0 0.05 0.1 0.15 0.2 0.25 0.3 0 0.05 0.1 0.15 0.2 0.25 0.3
FBE LBE
1 1
0.9 0.9
0.8 0.8
0.7 0.7
0.6 0.6
CDF
CDF
0.5 0.5
0.4 0.4 ISD = 100 - Freq_reuse = 1

0.3 0.3
0.2 0.2
ISD = 30 - Freq_reuse = 3 0.1 ISD = 30 - Freq_reuse = 3
0.1
0
0 0 0.1 0.2 0.3 0.4 0.5
0 0.1 0.2 0.3 0.4 0.5 0.6
UL Normalized UE Throughput [bps/Hz]
UL Normalized UE Throughput [bps/Hz]
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

FBE LBE
Reported performance ISD [m] / CCA-ED = -62 dBm / Freq_Reuse (F ) ISD [m] / CCA-ED = -62 dBm / Freq_Reuse (F )
R R
metrics [Full buffer 80%
DL/20%UL No fading] 30 50 100 30 50 100
FR = 1 FR = 3 FR = 1 FR = 3 FR = 1 FR = 3 FR = 1 FR = 3 F R = 1 F R = 3 FR = 1 FR = 3
DL Mean Delay [ms] 496.35 224.04 208.15 81.81 152.22 23.15 12.151 4.91 6.784 3.338 4.737 2.601
DL Per-cell spectral
0.17 0.475 0.246 0.712 0.398 0.932 0.161 0.538 0.234 0.883 0.455 1.241
efficiency [bps/Hz]
DL Area spectral
217.88 203.14 113.45 109.58 45.91 35.88 206.15 229.93 108.01 136.02 52.52 47.76
efficiency [bps/Km2/Hz]
DL Fairness_UE_Th 0.182 0.333 0.237 0.48 0.297 0.549 0.703 0.758 0.703 0.781 0.65 0.823
DL Fairness_SC_Th 0.225 0.385 0.312 0.569 0.4 0.645 0.832 0.88 0.87 0.925 0.875 0.964
UL Mean Delay [ms] 728.28 384.00 293.23 171.10 304.97 88.12 29.09 14.02 17.66 10.89 14.20 10.29
UL Per-cell spectral
0.066 0.186 0.091 0.252 0.171 0.4 0.05 0.134 0.058 0.201 0.13 0.379
efficiency [bps/Hz]
UL Area spectral
85.13 79.39 42.15 38.83 19.71 15.385 63.58 57.36 26.86 30.91 15.03 14.59
efficiency [bps/Km2/Hz]
UL Fairness_UE_Th 0.199 0.34 0.248 0.48 0.29 0.513 0.645 0.696 0.56 0.683 0.54 0.678
UL Fairness_SC_Th 0.217 0.363 0.275 0.512 0.334 0.566 0.711 0.75 0.641 0.749 0.635 0.742
Fairness_access 0.25 0.43 0.35 0.62 0.422 0.67 0.842 0.907 0.88 0.968 0.918 0.989
Table 91: Performance of FBE and LBE using different ISDs, full buffer traffic 80%DL/20%UL, No fading,
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

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.
FBE LBE
1 1
0.9 0.9
0.8 0.8
0.7 0.7
0.6 0.6
CDF
0.5 CDF 0.5

0.1 0.1
0 0
0 0.5 1 1.5 2 0 0.2 0.4 0.6 0.8
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]
FBE, FTP D = 5 sec LBE, FTP D = 5 sec

2.4 1.4
ISD = 100 m ISD = 100 m
2.2 0.34
ISD = 50 m 1.2 0.87 ISD = 50 m

2 ISD = 30 m ISD = 30 m
0.43
1.8 0.44 1 0.84
1.6 0.88
0.8
1.4
0.6
1.2
0.20
1 0.23
0.4
0.35 0.81 0.83
0.8 0.14 0.81
0.15 0.2
0.6 0.28 0.79 0.78
0.8
0.4 0
-82 -80 -78 -76 -74 -72 -70 -68 -66 -64 -62 -82 -80 -78 -76 -74 -72 -70 -68 -66 -64 -62
CCA - ED threshold [dBm] CCA - ED threshold [dBm]
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.

FBE LBE
FTP 100% DL [D = 5s] 30 50 100 30 50 100
No fading
-82 -62 -82 -62 -82 -62 -82 -62 -82 -62 -82 -62
Mean Delay [ms] 1261 511 1175 308 193 141 18.3 8.4 9.86 4.86 6.16 3.23
Per-cell spectral
0.022 0.038 0.029 0.056 0.074 0.086 0.079 0.083 0.122 0.12 0.225 0.18
efficiency [bps/Hz]
27.99 49.26 13.5 25.65 8.5 9.898 101.21 107.12 56.41 55.52 25.92 20.78
[bps/Km2/Hz]
Fairness_UE_Th 0.076 0.097 0.115 0.122 0.271 0.216 0.352 0.265 0.329 0.267 0.448 0.295
Fairness_SC_Th 0.157 0.188 0.242 0.273 0.429 0.452 0.514 0.453 0.461 0.464 0.61 0.534
Fairness_access 0.143 0.281 0.207 0.358 0.34 0.439 0.794 0.776 0.806 0.837 0.866 0.879
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.
FBE LBE
1 1
0.9 0.9
ISD = 100 - D = 5 sec ISD = 100 - D = 5 sec
0.8 ISD = 50 - D = 5 sec 0.8 ISD = 50 - D = 5 sec
ISD = 30 - D = 5 sec ISD = 30 - D = 5 sec
0.7 ISD = 100 - D = 2 sec 0.7 ISD = 100 - D = 2 sec
ISD = 50 - D = 2 sec ISD = 50 - D = 2 sec
0.6 ISD = 30 - D = 2 sec 0.6 ISD = 30 - D = 2 sec
CDF
CDF
0.5 0.5
0.4 0.4
0.3 0.3
0.2 0.2
0.1 0.1
0 0
0 0.5 1 1.5 2 0 0.2 0.4 0.6 0.8
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


metrics ISD [m] /Reading time D [s] ISD [m] /Reading time D [s]
FTP 100% DL
[CCA-ED = -62 dBm] 30 50 100 30 50 100
No fading D=2s D=5s D=2s D=5s D=2s D=5s D=2s D=5s D=2s D=5s D=2s D=5s
Mean Delay [ms] 262 511 359.25 308 163.3 141 7.992 8.4 5.251 4.86 3.408 3.23
Per-cell spectral
0.062 0.038 0.097 0.056 0.171 0.086 0.091 0.083 0.13 0.12 0.23 0.18
efficiency [bps/Hz]
79.32 49.26 44.88 25.65 19.77 9.898 116.57 107.12 60.97 55.52 26.39 20.78
[bps/Km2/Hz]
Fairness_UE_Th 0.083 0.097 0.116 0.122 0.187 0.216 0.356 0.265 0.334 0.267 0.311 0.295
Fairness_SC_Th 0.156 0.188 0.244 0.273 0.358 0.452 0.592 0.453 0.621 0.464 0.622 0.534
Fairness_access 0.246 0.281 0.333 0.358 0.446 0.439 0.811 0.776 0.816 0.837 0.863 0.879
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.

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%).
LBE, Full buffer LBE, FTP D = 5 sec
1 1
0.9 0.9
0.8 0.8
0.7 0.7
0.6 0.6
CDF
CDF
0.5 0.5
ISD = 100 ED = - 62 dBm
ISD = 100 ED = - 62 dBm
0.4 ISD = 30 ED = - 62 dBm 0.4
ISD = 30 ED = - 62 dBm
ISD = 100 ED = - 82 dBm
0.3 0.3 ISD = 100 ED = - 82 dBm
ISD = 30 ED = - 82 dBm
ISD = 30 ED = - 82 dBm
ISD = 100 (WiFi) ED = - 62 dBm
0.2 0.2 ISD = 100 (WiFi) ED = - 62 dBm
0.1 ISD = 100 (WiFi) ED = - 82 dBm
0.1 ISD = 100 (WiFi) ED = - 82 dBm
0 0
0 0.05 0.1 0.15 0.2 0 0.05 0.1 0.15 0.2
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

LBE LBE + WiFi

Full buffer 100% DL 30 100 30 100
No fading. FR = 1
-82 -62 -82 -62 -82 -62 -82 -62
Mean Delay [ms] 23.57 10.09 7.55 4.18 30.077 19.864 13.468 18.046
Per-cell spectral
0.188 0.162 0.48 0.52 0.083 0.054 0.249 0.164
efficiency [bps/Hz]
240.82 208.16 56.36 60.4 106.515 69.214 28.7 18.984
[bps/Km2/Hz]
Fairness_UE_Th 0.631 0.602 0.71 0.55 0.597 0.514 0.654 0.283
Fairness_SC_Th 0.72 0.79 0.84 0.83 0.793 0.733 0.805 0.619
Fairness_access 0.73 0.8 0.84 0.86 0.809 0.717 0.803 0.685
Mean Channel LBE 10.9 23.4 28.61 51.96 7.83 14.18 16.74 33.58
occupancy % WiFi - - - - 5.86 12.2 12.18 32.72
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.
LBE + WiFi
metrics ISD [m], EDLBE / EDWiFi [dBm]
Full buffer 100% DL 30 100
No fading, FR = 1
[-82/-82] [-82/-62] [-62/-82] [-62/-62] [-82/-82] [-82/-62] [-62/-82] [-62/-62]
Mean Delay [ms] 30.077 1145.93 9.547 19.864 13.468 2483.78 4.27 18.046
Per-cell spectral
0.083 0.002 0.156 0.054 0.249 0.001 0.502 0.164
efficiency [bps/Hz]
106.515 2.075 199.752 69.214 28.7 0.098 57.985 18.984
[bps/Km2/Hz]
Fairness_UE_Th 0.597 0.017 0.624 0.514 0.654 0.016 0.534 0.283
Fairness_SC_Th 0.793 0.122 0.818 0.733 0.805 0.069 0.817 0.619
Fairness_access 0.809 0.325 0.833 0.717 0.803 0.094 0.859 0.685
Mean Channel LBE 7.83 0.84 22.65 14.18 16.74 0.056 51.9 33.58
occupancy % WiFi 5.86 20.7 0.37 12.2 12.18 47.65 0.14 32.72
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.

LBE + WiFi, Full buffer LBE + WiFi, Full buffer

0.6 55
ISD = 100 m ED = -62dBm
ISD = 100 m ED = -62dBm 50 ISD = 100 m ED = -82dBm
Mean channel occupancy (LBE) %

ISD = 100 m ED = -82dBm ISD = 30 m ED = -62dBm
0.5
ISD = 30 m ED = -62dBm 45 ISD = 30 m ED = -82dBm
ISD = 30 m ED = -82dBm
40
0.4
35
0.3 30
25
0.2
20
15
0.1
10
0 5
0 0.25 0.5 0.75 1 0 0.25 0.5 0.75 1
APs/SCs density ratio APs/SCs density ratio
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.

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
Per-cell Spectral Efficiency 0.329 0.460 0.818 0.162 0.235 0.520
[bps/Hz]
[bps/km2/Hz]
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
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
Per-cell Spectral 0.300 0.420 0.648 0.083 0.120 0.180
Efficiency [bps/Hz]
Area Spectral
Efficiency 385.27 194.17 74.85 107.12 55.52 20.78
[bps/km2/Hz]
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
62dBm) for various ISDs , FTP traffic model with 100% DL traffic and mean inter-arrival time of 2 sec.

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
[bps/Hz]
[bps/km2/Hz]
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
[bps/Hz]
[bps/km2/Hz]
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
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
Per-cell spectral 0.150 0.505 0.083 0.249
efficiency [bps/Hz]
Area Spectral
Efficiency 192.04 58.33 106.52 28.70
[bps/km2/Hz]
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 20.037 40.112 7.830 16.740
design [%]
Channel occupancy 6.837 18.917 5.860 12.180
WiFi
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
On
ACKs
Not considered (operation over 20.0 MHz
Channel bonding
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

[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

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 Type of traffic steering requested by
cRRM/5G-RRC.
2: Aggregation
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 Indicates which RAT type should be
considered for this configuration. This
2: 5G (FBMC)
aides in HMAC determining air interface
3: 5G (DCS) to offload the traffic to or aggregate radio
3: Wi-Fi resources on.
LCG U8 Logical Channel Group to be considered

for the steering.
BW U8 1: 5MHz Channel Bandwidths. [MHz]
2: 10MHz
3: 20MHz
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.
configuration.
LMACConfig #i{ List of LMAC Configurations
DCS: See A.3.1
FBMC: See A.2.11
RATType U8 1: LTE-A Indicates which RAT type should be
considered for this configuration. This
2: 5G (FBMC)
aids HMAC in tying the config to an air
3: 5G (DCS) interface to offload the traffic to or
3: Wi-Fi 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 Status of applying
5G-MAC
1: Successful
configuration.
A.1.4 MeasurementConfig.request
MeasurementConfig.request

Description:
Measurement configurations, indicating type of measurements to be performed by the HMAC.
configuration.
UEID U16 UE IDentity
MeasID U8 Measurement Identity
MeasurementObject #i{
RATType U8 1: LTE-A RAT Type
2: 5G (FBMC)
3: 5G (DCS)
3: Wi-Fi
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-
Status U8 0: Unsuccessful Status of applying the measurement
configuration.
1: Successful
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.
element
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
element
Status U8 0: Unsuccessful Indicates whether
Measurement.request was successfully
1: Successful
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.
element
CellID U8 Cell ID of the cell reporting the
measurement
MeasInfo { struct
data
}
A.1.9 ChannelIdentification.indicate
ChannelIdentification.indicate
Description:
This is used to report channels identified in the spectrum
element
CellID U8 Cell ID of the cell reporting the
channels
BandID U8 Band ID
ChannelID U8 Identified Channel
2: 5G (FBMC)
3: 5G (DCS)
3: Wi-Fi
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.
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
2: 5G (FBMC)
3: 5G (DCS)
3: Wi-Fi
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.
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


2: 5G (FBMC)
3: 5G (DCS)
3: Wi-Fi
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
2: 5G (FBMC)
3: 5G (DCS)
3: Wi-Fi
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.
2: 5G (FBMC)

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.
2: 5G (FBMC)
3: 5G (DCS)
3: Wi-Fi
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
Status U8 0: Unsuccessful Status of the configuration
1: Successful
PHY_ID U8 PHY Identity
Band U8 Band Information
active subcarriers)
PHYSpecParams { struct FBMC: See A.2.15
DCS: See A.3.13
}
Measurement.request
Description:
This is used to request for measurement data
element

TTR U8 Time to Report [ms].
Measurement.confirm
Description:
This is used to report of requested measurement data
element
Status U8 0: Unsuccessful Status of the measurement request
1: Successful
MeasInfo { struct
data
}
A.1.19 Measurement.indicate
Measurement.indicate
Description:
This is used to report of requested measurement data
element
MeasInfo { struct
data
}
Measurement.request
Sender: HMAC Receiver: PHY SAP: C_HMAC_PHY
Description:
This is used to request for measurement/sensing data
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
element
Status U8 0: Unsuccessful Status of the measurement request
1: Successful
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
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

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
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
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
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
element
UEID U8 Cell ID
CQI U8 Channel Quality Indicator Information
A.2.4 Association.confirm
Association.confirm
Description:
Confirmation to the Association Request
element
CellID U8 Cell ID
Status U8 0: Unsuccessful Status of the Association request
1: Successful
A.2.5 Association.indicate
Association.indicate
Description:
Indication of the Association
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
element
CellID U8 Cell ID
A.2.7 UEPaging.request
UEPaging.request
Description:
UE Paging Request
element
UEID U8 UE IDentifier
A.2.8 UEPaging.response
UEPaging.response
Description:
Response to UE Paging Request
element
Status U8 0: Unsuccessful Status of UE Paging Request
1: Successful
2. NoAnswer
UEID U8 UE IDentifier
A.2.9 SchedFrameTrigger.request
SchedFrameTrigger.request
Description:
Scheduling Frame Trigger request
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
element
Status U8 0: Unsuccessful Status of the Scheduling Frame Trigger
request
1: Successful
LMACConfiguration.request
Description:
2: 5G (FBMC)
3: 5G (DCS)
3: Wi-Fi
AirInterfaceConfig { struct
RATType U8 RAT Type
Action U8 0: OFF To switch off or on
1: 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)
active subcarriers)
}
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 Indicate where scheduler config is to
setup, modify or release the scheduling
1: Modify
2: Release
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.
2: 5G (FBMC)
3: 5G (DCS)
3: Wi-Fi
Status U8 0: Unsuccessful Status of the Air Interface
Configuration
1: Successful
RATType U8 RAT Type
1: ON
}
Status U8 0: Unsuccessful Status of the PHY Configuration
1: Successful

256, 512)
active subcarriers)
}
Status U8 0: Unsuccessful Status of Frame Configuration
1: Successful
}
Status U8 0: Unsuccessful Status of the Scheduler Configuration
1: Successful
1: Modify
2: Release
UEID U8 UE ID
algorithm and etc.)
}
Status U8 0: Unsuccessful Status of coexistence Configuration
1: Successful
preamble, pattern)

}
ChannelReselConfig { struct
Status U8 0: Unsuccessful Status of the Channel Reselection
Configuration
1: Successful
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.
2: 5G (FBMC)
3: 5G (DCS)
3: Wi-Fi
256, 512)
active subcarriers)
}


}
preamble, pattern)
}
}
Description:
This is the PHY Configuration.
Nfft U8 Number of points in FFT (256, 512)
}
Description:
This is used to confirm PHY Configuration.

256, 512)
}
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
preamble, pattern)
A.2.17 PHYPerformCCA.confirm
PHYPerformCCA.confirm
Description:
This is used to report of the status for Clear Channel Assessment procedure
Status U8 0: Unsuccessful Status of the CCA request
1: Successful
ChannelID U8 Channel IDentifier
BW U8 Bandwidth
preamble, pattern)

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 {
Status U8 0: Unsuccessful Status of the data transmission
1: Successful
mapped
}
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 {
mapped
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:
2: 5G (FBMC)
3: 5G (DCS)
3: Wi-Fi
RATType U8 RAT Type
1: ON
}
(enumeration: 2, 3, 4) (relevant only if
FMBC phy is used)
256, 512)
active subcarriers)
}
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
}
1: Modify
2: Release
UEID U8 UE ID
algorithm and etc.)
}
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
preamble, pattern)
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.
2: 5G (FBMC)
3: 5G (DCS)
3: Wi-Fi
Status U8 0: Unsuccessful Status of the Air interface configuration
1: Successful
RATType U8 RAT Type
1: ON
}
Status U8 0: Unsuccessful Status of the PHY configuration
1: Successful
TrxID U8 Transceiver ID
BandID U8 Band ID

MaxPow U8 Maximum Transmit Power [dBm]

FMBC phy is used)
256, 512)
active subcarriers)
}
}
Status U8 0: Unsuccessful Status of the Basic configuration
1: Successful
BSRelated { Struct
CellID U8 Cell ID
ClusterID U8 Cluster Member ID
OperatorID U8 Operator ID
}
UERelated {
}
}
Status U8 0: Unsuccessful Status of the Scheduler configuration
1: Successful
1: Modify
2: Release
UEID U8 UE ID


algorithm and etc.)
}
Status U8 0: Unsuccessful Status of the Coexistence configuration
1: Successful
BandID U8 Band ID
a given band
}
}
parameters
}
}
Description:
This is used to indicate current status of LMAC and PHY configuration.
2: 5G (FBMC)
3: 5G (DCS)
3: Wi-Fi
RATType U8 RAT Type
1: ON
}

FBMC phy is used)
256, 512)
}
}
BandID U8 Band ID
a given band
preamble, pattern)
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
}
}
parameters
}

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
UE transmission
CellID U8 Cell ID

BandID U8 Band ID
handover purpose
direction
}
A.3.6 RadioBearerEstablish.indicate
RadioBearerEstablish.indicate
Description:
This is used to indicate Radio Bearer Establishment.
UE transmission
CellID U8 Cell ID
BandID U8 Band ID
handover purpose
direction
}
A.3.7 RadioBearerRelease.request
RadioBearerRelease.request

Description:
This is used to request for Radio Bearer Release.
UE transmission
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
UE transmission
CellID U8 Cell ID
BandID U8 Band ID
A.3.9 RadioBearerRelease.indicate
RadioBearerRelease.confirm
Description:
This is used to indicate Radio Bearer Release


UE transmission
CellID U8 Cell ID
BandID U8 Band ID
A.3.10 SchedTransmission.request
SchedTransmission.request
Description:
Scheduling Transmission request
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
element
Status U8 0: Unsuccessful Status of the Scheduling Transmission
request
1: Successful


Description:
This is the PHY Configuration.
FBMC phy is used)
ICS U8 Inter-carrier spacing [kHz]
256, 512)
}
Description:
This is used to confirm PHY Configuration.
Status U8 0: Unsuccessful Status of the PHY Configuration
1: Successful
BandID U8 Band Identifier
MaxPow U8 Maximum transmit power [dBm]
FBMC phy is used)
ICS U8 Inter-carrier spacing [kHz]
256, 512)
active subcarriers)
}
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
UE transmission
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.
Status U8 0: Unsuccessful Status of the Transmission request
1: Successful
BandID U8 Band ID
UE transmission
A.3.16 PHYFrameReceive.indicate
PHYFrameReceive.indicate

Description:
This is used to indicate the reception of data (control and/or user data).
UE transmission
TxDuration U8 Duration of transmission in Base Slot
Duration units
ControlContent { struct
Payload U8* A pointer to control MSDU
mapped
}
DataContent { struct
Payload U8* A pointer to user data MSDU
mapped
}
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.

0
10
MCS 1
MCS 2
MCS 3
MCS 4
MCS 5
MCS 6
-1 MCS 7
10
MCS 8
MCS 9
MCS 10
BLER
MCS 11
MCS 12
MCS 13
-2 MCS 14
10 MCS 15
MCS 16
MCS 17
MCS 18
MCS 19
MCS 20
MCS 21
-3
10
-30 -20 -10 0 10 20 30
SNR [dB]
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.
Modulation MCS
MMIB AWGN
ESM BLER vs.
SNR LUT
Figure 120: DCS MAC BLER mapping procedure.

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

Speed5g d5.2 Mac Approaches With FBMC Final

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Speed5g d5.2 Mac Approaches With FBMC Final

Загружено:

Авторское право:

Доступные форматы

Grant Agreement No.

quality of Service Provision and capacity Expansion through

D5.2: MAC approaches with FBMC (final)

Deliverable type R (Report)

Document revision history

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

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

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

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

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

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

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

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

A.3.2 LMACConfiguration.confirm ................................................................................................ 201

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

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

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

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

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

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

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

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

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

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

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

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

LWA LTE-WiFi Aggregation

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

TMSI Temporary Mobile Subscriber Identity

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

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

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

2 eDSA MAC Specification

2.1 Speed-5G MAC overview

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

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

5G-O&M C_5GOAM-cRRM 5GPDCP_5GRLC SAP

5G_MAC sensing & Measurement

Lower-MAC LTE-A Lower-MAC WiFi Lower-MAC 5G_AIV

Scheduling coordination Scheduling coordination

QoS QoS QoS Frame QoS Frame

Licensed Lightly-Licensed Unlicensed

Buffers Buffers Buffers PHY

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

2.2 eDSA MAC-related Signalling Procedures

2.2.2 Measurements configuration and reporting procedures

2.2.2.1 RRM-triggered measurements

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

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

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

Figure 4: Procedure for measurement configuration of LMAC by HMAC

Figure 5: Procedure for measurement collection by HMAC

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

2.2.3 MAC configuration procedures

2.2.3.1 MAC configuration initiated by the cRRM entity

Figure 6: Generic procedure for MAC configuration by RRM entity

2.2.3.2 Lower MAC configuration initiated by Higher MAC

Figure 7: LMAC reconfiguration procedure

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

2.2.4 Traffic steering triggered by RRM procedure

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