Layer 2 FEC in 5G Broadcast / Multicast Networks5g-xcast.eu/wp-content/uploads/2018/09/Nomor... · lower layers. On the other hand, the ma-jor functions of the MAC protocol in LTE

Layer 2 FEC in 5G Broadcast /Multicast NetworksAugust 29, 2018Fasil Tesema, Volker PauliNOMOR Research GmbH, Munich, Germany

Summary

Evolution of broadcast / multicast verti-cals is pushing for a rapid growth of thewireless communication sectors to sup-port the technical requirements. While3GPP’s discussion on broadcast / mul-ticast for 5G-NR is at an early stage,the collaborative project 5G-XCast, underH2020 Phase II, is working towards provid-ing a comprehensive solution for a futuregeneration of broadcast / multicast em-bedded efficiently into 5G communicationnetworks. This white paper presents acase study for the use of a 2nd layer of for-ward error correction (FEC) utilizing ran-dom linear network codes and feedback toimplement highly efficient, reliable packetdelivery for mixed-mode broadcast / mul-ticast applications. The benefits over thestate of the art schemes are illustrated bymeans of system-level simulations.

I Introduction

Rapid evolution of broadcast / multicastvertical sectors such as Multimedia andentertainment, automotive, public warn-ing systems and internet of things, callsfor the development of the broadcast /multicast communication technology tosatisfy the requirements of these verticals.

5G-XCast is a H2020 Phase II project fo-cused on broadcast and multicast com-munication enablers for the fifth gener-ation (5G) of wireless systems, and itis working towards providing a compre-hensive solution to support the require-ments of the aforementioned vertical sec-tors. Among other things, the goals ofthe project include design of a highly flex-ible and efficient radio resource manage-ment for embedding broadcast / multi-cast into 3GPP’s NR system, that is sofar limited to unicast, i.e., the so-called“mixed mode” in contrast to pure “ter-restrial broadcast” supporting also receiveonly mode (ROM) devices. Nomor’s focusin this project is on RAN protocols and ra-

Nomor Research GmbH / [email protected] / www.nomor.de / T +49 89 9789 8000 1/26

dio resource management, which are be-ing implemented in Nomor’s system-levelsimulator for 5G mobile communicationnetworks.

Diligent design and implementation of Ra-dio Access Technology (RAT) protocolsand the relevant radio resource manage-ment are very crucial to fulfill the re-quirements of new emerging technologies.After detailed survey performed by the5G-XCast RAN working group, the ma-jor RAN protocol limitations of 3GPP’sRel 14 specification regarding broadcast/ multicast have been highlighted in [1].Among other things, the limitations onthe radio resource management, latencyand service scheduling have been identi-fied. In regard to radio resource man-agement, the current cellular broadcast /multicast systems provide limited supportfor feedback and higher layer RAN-levelerror correction schemes, leading to chal-lenges in terms of providing the requiredspectral efficiency and packet loss rates.

For 5G-NR, 3GPP has specified a 1st layerof FEC in the physical layer: Low DensityParity Check (LDPC) code for data chan-nels and polar codes for control channel[2]. These layer-1 error protection mecha-nisms can be readily applied also in Broad-

cast/Multicast case. However, they arenot sufficient for robustness at a largertime scale. But a 2nd layer of error protec-tion is required to ensure adequate QoE.Hence, for LTE 3GPP has specified appli-cation layer FEC (AL-FEC) [3] as a 2ndlayer of error protection based on Raptorcodes. In designing broadcast / multicastfor 5G, we now have the opportunity to re-consider the placement and design of this2nd layer FEC mechanism.

Furthermore, 3GPP has considered appli-cation of HARQ feedback in the 1st layerof FEC [4]. However, it was found to notbe very efficient as the number of usersgrows, the reason for this lying mainly inthe fact that here different UEs in generalask for retransmissions of different pack-ets due to mutually independent channelstate variations.

We consider the use of a 2nd layer ofForward Error Correction (FEC) schemein RAN as potential remedy to the iden-tified challenges with respect to spectralefficiency and packet loss rates.

This white paper presents a detailedoverview of the functions of RAN proto-cols in 5G-NR and a proposal to efficientlyembed a 2nd layer of FEC within 5G-NRwith consideration of the limitations of


putting the function at various layers inthe protocol stack including an efficientfeedback and dynamic redundancy adap-tation strategy. Moreover, elaboratedsimulation results are presented showingthe performance evaluation of the pro-posed scheme as compared to systematicRaptor codes used for LTE broadcast /multicast [3].

The white paper is structured as follows.Section II presents state of the art RANprotocols. Section III presents a pro-posal for 2nd layer of FEC for Point-To-Multipoint (PTM) transmissions. Then,Section IV demonstrates protocol func-tion implementation for 2nd layer of FEC.Section V shows details simulation results.Finally, Section VI presents concluding re-marks.

II LTE RAN Protocols forPTM

II.A RAN Protocols in LTE-A PTM

The most relevant RRM-related protocollayers in LTE PTM [5], particularly foruser plane data, are Radio Link Control(RLC), Medium Access Control (MAC)and Physical (PHY) layer, as depicted in

eNB

PHY

UE

PHY

MAC

RLC

MAC

RLC

Figure 1: LTE RAN protocols for PTM datatransmission [5].

Figure 1. Herein, the Packet Data Con-vergence Protocol (PDCP) is not used,i.e., operates in transparent mode. Themajor roles of the RLC layer are segmenta-tion and/or concatenation of RLC ServiceData Units (RLC SDUs) to fit into theavailable transport blocks provided by thelower layers. On the other hand, the ma-jor functions of the MAC protocol in LTEPTM are radio resource scheduling andmultiplexing of data to lower layer trans-port blocks.

Figure 2 shows an example of user planedata flow in LTE PTM. First of all, theMultimedia Broadcast Multicast Service(MBMS) packets from higher layers areinput to RLC layer as RLC SDUs. Based


MBMS SDUH

Concatenated SDUH

MAC SDU

MBMS SDUH MBMS SDUH

SDU SegmentH SDU SegmentH

H MAC SDU

...

...

...

MAC PDU – Transport Block

RLC

MAC

MBMS packet

Service 1

MBMS packet

Service 2

concatenation segmentation

Multiplexing

RLC SDURLC SDU RLC SDU

H

MBMS packet

Service 1

Figure 2: Packet flow for MBMS data [5].

on the available MAC transport block,the RLC layer concatenates or segmentsRLC SDUs. Moreover, the RLC layerappends header information to the RLCSDUs to generate RLC PDUs. The RLCheader contains information that supportsthe corresponding receiver RLC to assem-ble RLC SDUs from received RLC PDUs.After RLC PDUs are generated, the MAClayer multiplexes RLC PDUs which maycome from different sources, e.g. differentMBMS services, into the available MACtransport block.

II.B NR RAN Protocols for Unicast

This section briefly outlines the radio pro-tocols specified for NR with considerationof Point-to-Point (PTP) communication.Figure 3 describes the architecture of theradio protocol function pertinent to thecommunication between NR gNB and aUE. The specified radio protocols are Ser-vice Data Adaptation Protocol (SDAP),PDCP, RLC, MAC and PHY layers [6]. Amajor change is that the concatenation ofpackets no longer takes place in RLC layer,but has been moved to the MAC layer. Acompletely new element is the SDAP layerwhich is used for packet marking with QoSflow ID (QFI) and mapping of QFI to ra-


gNB

PHY

UE

PHY

MAC

RLC

MAC

PDCPPDCP

RLC

SDAPSDAP

Figure 3: NR radio protocols for unicast datatransmission [6].

dio bearers.

The main functions of SDAP, PDCP, RLCand MAC in accordance with 3GPP’s gen-eral description of NR [5] are listed be-low. Further details on the specificationfor layer 2 protocols (SDAP, PDCP, RLCand MAC) can be found in [7]-[10], re-spectively.

SDAP Layer

• Mapping between a QoS flow and adata radio bearer• Marking QoS flow ID (QFI) in both

DL and UL packets

PDCP Layer

• Header compression and decompres-

sion: ROHC only• Reordering and duplicate detection• PDCP PDU routing (in case of split

bearers)• Retransmission of PDCP SDUs• Ciphering, deciphering and integrity

protection• PDCP SDU discard• PDCP re-establishment and data re-

covery for RLC AM• Duplication of PDCP PDUs

RLC Layer

• Transparent Mode (TM) or Unac-knowledged Mode (UM) or Acknowl-edged Mode (AM)• Segmentation (AM and UM) and

re-segmentation (AM only) of RLCSDUs• Reassembly of SDU (AM and UM)• RLC SDU discard (AM and UM)• Error Correction through ARQ (AM

only)• Duplicate Detection (AM only)• Protocol error detection (AM only)

MAC Layer

• Mapping between logical channelsand transport channels• Multiplexing / demultiplexing of

MAC SDUs belonging to one or dif-


ferent logical channels into / fromtransport blocks (TB) delivered to /from the physical layer on transportchannels• Scheduling information reporting• Error correction through HARQ• Priority handling between logical

channels of one UE• Priority handling between UEs• Packet re-ordering with re-

transmissions with HARQ

Figure 4 elaborates on an example ofdownlink user plane data flow across 5G-NR radio protocols. First of all, higher-layer IP packets are marked with QFIand mapped to radio bearers. Then, thePDCP layer performs header compressionand security (ciphering and integrity pro-tection) and forwards PDCP PDUs to theRLC layer. After that, the RLC layerwraps RLC SDUs or segments thereof intoRLC PDUs based on the available MAClayer transport block size. Unlike cur-rent PTM systems which support only UMmode communication, the 5G-NR PTPcan operate in UM or AM mode wherere-transmissions of lost packets can beperformed via Automatic Repeat reQuest(ARQ) procedures. Following the RLCfunctions, the MAC layer multiplexes RLCPDUs which may come from the same

or different sources, e.g. different radiobearers, into the available MAC transportblock.

III 2nd Layer of FEC in RANfor PTM

In line with LTE PTM described in Sec-tion II, the proposed FEC scheme for PTMis discussed focusing on RLC and MACfunctions. The SDAP is assumed to havea one-to-one mapping between QFI andradio bearer IDs 1, and PDCP protocolfunctions are assumed to operate in trans-parent mode.

III.A Motivation

In the current LTE PTM specificationHARQ feedback is not used. Proprietaryimplementation of dynamic link adapta-tion based on CQI feedback is possiblefor SC-PTM e.g. based on the worst UEin the cell. Based on these two restric-tions a rather large margin has to be ap-plied in selection of the modulation andcoding scheme (MCS) leading to inef-ficient use of the radio resources. In

1In principle, 5G SDAP supports mapping oneor multiple QFIs to one radio bearer


IP SDU

H SDAP SDU

PDCP SDUH

RLC SDUH

MAC SDU

IP SDU

H SDAP SDU

PDCP SDUH

IP SDU

SDAP SDU

PDCP SDUH

SDU SegmentH SDU SegmentH

MAC SDU

...

...

...

...


PDCP

RLC

SDAP

MAC

IP PDU nRadio

bearer 1

H

IP PDU n+1

Radio bearer 1

IP PDU mRadio

bearer 2

H

segmentation

RLC SDURLC SDU RLC SDU

H

H

H RLC SDU

H

HMAC SDUH MAC SDUH

Figure 4: User plane data flow across 5G-NR radio protocols.

fact, 3GPP performed a detailed studyin [4] on PTM with group-based uplinkfeedback for link adaptation and HARQ.Moreover, the HARQ feedback messagesare reported from each UE to the networkwhenever a packet is received. The num-ber of CQI and HARQ ACK/NACK mes-sages scale with the number of UEs, lead-ing to a high feedback load in scenarioswith high number of users where PTM istypically a suitable option. Even more im-portantly, the HARQ-based scheme of [4]becomes very inefficient as the number ofUEs grows as packet loss events at differ-

ent UEs are largely statistically indepen-dent such that different UEs will typicallyask for retransmissions of different pack-ets.

The work in [11] proposed exclusion of theHARQ ACK/NACK feedback and use ofonly CQI feedback to achieve an improvedperformance via enhanced outer loop linkadaptation techniques, but by construc-tion lacks the capability to deliver datawith high spectral efficiency with very highreliability, as there are no means to reli-ably fix packet losses e.g. due to chan-nel variations not predicted by the CQI


reports. Hence, an alternative error cor-rection scheme with minimal overhead offeedback messages that at the same timeprovides high reliability is desirable.

Accordingly, herein an alternative tech-nique that can provide the required per-formance via forward error correctionschemes is proposed. It is based onRandom Linear Network Coding (RLNC)which is selected due to its suitability forradio channels that induce packet losses[12], and the flexibility of decoding withor without packet re-ordering as long asthe required number of network codingPDUs is available at the receiver. Un-like block codes such as Raptor codes[3], RLNC offers the capability to performsuccessive en- / decoding and recoding[13].2 The entailed feature of recodingmakes RLNC interesting option to scale itto co-operative / D2D-assisted broadcast-ing, which is however beyond the scope ofthis paper.

2We note, however, that the 2nd layer FECscheme presented herein could almost just as wellbe implemented based on any other Fountaincoding scheme, including Raptor codes.

III.B Basics of RLNC

RLNC can be used to reliably transmitdata streams in an end–to–end mannerover a channel that induces packet losses.It incorporates 3 major functions: encod-ing, decoding and recoding.

III.B.1 Encoding

The encoding process consists of formingNetwork Coding (NC) PDUs pnc,n fromlinear combinations of NC Service DataUnits (SDUs) snc,m to be transmitted.The coefficients cn,m for these linear com-binations are selected randomly from a fi-nite field, e.g. of size 256. They are trans-mitted as side information along with thePDUs as the decoder needs them in itsdecoding process.3 This encoding processis illustrated in the following equation:

pnc,n =∑∀m

cn,msnc,m. (1)

When stacking multiple NC–PDUs asrows into a matrix, we obtain the followingdescription for a “generation” {snc,m|1 ≤

3Expediently, this transfer is done by sendingonly a seed to a certain random number generatorthat generates these coefficients, cf. e.g. [14].


m ≤ NG} of a finite size NG:

pnc,1

pnc,2...

︸︷︷︸4=P

=

c1,1 . . . c1,NG

c2,1. . .

...

︸︷︷︸

4=C

·

snc,1snc,2

...snc,NG

︸︷︷︸

4=S

(2)where with every PDU a row is added tothe matrix C.4

III.B.2 Decoding

Having discussed the encoding process,one can see that the decoding processcan basically be implemented by invertingthe matrix C, while this may of coursenot be the computationally most efficientapproach. It is then also easy to under-stand that this is possible only if the rankof C is equal to the number of encodedSDUs. Hence, a necessary (but not suffi-cient) condition for successful decoding isthat at least as many PDUs have been re-ceived as SDUs are encoded in the set ofPDUs. Based on the fact that the encod-

4Strictly speaking the organization of SDUsin disjoints sets a.k.a. generations is not required,however it is expedient for the purpose keepingtrack of the decoding progress.

ing coefficients cn,m are randomly drawn,the probability that the above-mentionedrank–criterion is also sufficient is close to1 if C is properly populated with non-zeroencoding coefficients. For a detailed anal-ysis see Figure 10. The main advantageof this concept is that it hardly mattersto the decoder, which of the PDUs it re-ceives and which ones get lost along theway, or which ones are received first in amulti–path scenario. As soon as it has re-ceived a sufficient number of PDUs, whichrarely has to be larger than the number ofencoded SDUs, it can decode the SDUs.As such, the scheme is very efficient interms of overhead for protection againstpacket loss. The difficulty is to determinean adequate number of PDUs that needto be transmitted over a lossy link.

III.B.3 Recoding

One of the main distinguishing features ofRLNC is the option to do recoding in enti-ties that have received some RLNC PDUs.This could be either one of several coop-erating UEs or a relay node that receivedPDUs on different routes in a multi–routesystem. However, co-operative commu-nication is not within the scope of thisdocument.


IV Protocol Function Imple-mentation for 2nd Layer ofFEC via RLNC

This section demonstrates the feasible op-tions of implementation of RLNC func-tions inside the radio protocol stack forPTM communication.

IV.A Feasible location for NC Sub-layer

The viable candidate locations to installNC sublayer function are demonstrated inFigure 5. With RLNC, one of the neces-sary requirements for decoding is that re-ceived RLNC PDUs have fixed size (whichis a design parameter). In other words,reception of variable length RLNC PDUsfrom the same generation sequence is notsuitable for decoding. As such, NC sub-layer location #1 is flexible enough to per-form RLNC en- / decoding under the con-straint of fixed RLNC PDU size. On theother hand, NC sublayer location 2 and3 are not feasible candidates as both op-tions don’t guarantee forwarding of fixedRLNC PDU sizes to their respective lowerlayers, as described in the following sub-sections. Figure 6 demonstrates the limi-tation of installing NC sublayer functions

RLC MAC PHY

NC

Sublayer

Location

1

NC

Sublayer

Location

2

NC

Sublayer

Location

3

Figure 5: The viable candidate locations toinstall NC sublayer function.

at the entry of MAC sublayer in the radioaccess. Herein, RLC PDUs will be inputsto the NC sublayer function. The gen-erated RLNC PDUs will have fixed sizeequal to the maximum of RLC PDUs plusNC header information, as shown by theblue boxes in the figure. However, theRLNC PDUs will in general not be ableto fit into the transport block provided bythe lower layers.

Figure 7 demonstrates the potential limi-tations if NC sublayer function is installedas one of the initial physical layer proce-dures.

As described in [2], 5G-NR physical layerhas a set of procedures that perform 1stlayer of FEC to provide bit-level robust-ness of transmitted data against lossychannel conditions. Herein, the majorprocedures of the specified error correc-tion scheme are segmentation of a trans-


NC SDU NC SDU

MBMS SDUH

MAC SDU

MBMS SDUH


RLC

MAC

MBMS packet #1 Service 1

RLC SDU RLC SDU

H




MBMS SDUH MBMS SDUH

RLC SDUH

• Potential NC sublayer

location;

• Not feasible location as

all NC PDUs have fixed

size with the largest RLC

PDU and they may not

fit to available TBs.

MBMS SDUH

MAC SDUH

H H NC SDUH

RLC SDUH RLC SDUH

MAC SDUH MAC SDUH

Figure 6: Potential limitations if NC sublayer function is installed in MAC layer.

MAC SDU ...


MAC

H

...PHY TB

K1 L

L

K1 L K1 L

MAC SDU


H

TB

K2 L

L

K2 L K2 L

• Potential NC sublayer

location;

• Not feasible location

as NC PDUs have

fixed size and code

block segments can

have variable size for

various TBs.

Figure 7: Potential limitations if NC sublayer function is installed in physical layer.


port block into equally sized code blocksof a given maximum size, Cyclic Redun-dancy Check (CRC) for decoding failuredetection in each code block, and use ofLow Density Parity Check (LDPC) codesfor error correction on data channels.

The potential location for a 2nd layer ofFEC in this case is after segmentationof the transport block into code blocks.Generally, the 2nd layer of FEC pack-ets should be distributed across differenttransport blocks to provide more robust-ness against fading processes. However,based on the characteristic of equally sizedRLNC PDUs across an entire generationthe generated RLNC PDUs would in gen-eral not fit into the allocated physicaltransmission resources, unless the amountof resources allocated to every transmis-sion is selected such that it can withoutsignificant padding carry an integer num-ber of complete RLNC PDUs.

IV.B Options of NC Sublayer

Assuming the feasible NC sublayer loca-tion #1, two major options of NC sublayerfunctions are investigated as follows.

Figure 8 shows the first feasible optionto perform RLNC functions inside the ra-

dio protocol at NC sublayer location #1.Herein, MBMS packets which in generalhave variable sizes are received at the NCsublayer as NC SDUs. Then, the RLNCencoder generates at least as many fixedsize RLNC PDUs as the number of inputNC SDUs. In this case, the size of anRLNC PDU is the maximum of sizes of theencoded NC SDUs, which directly con-stitutes a disadvantage of this approach.The major advantage of this option is thatit allows instantaneous encoding based onthe available NC SDUs.

Figure 9 describes the second feasible op-tion to perform RLNC functions inside theradio protocol at NC sublayer location #1.In this case, a fixed SDU size is configuredwith the same size as the fixed size RLNCPDU payload. As a result, MBMS packetsfrom the higher layers are segmented and/ or concatenated to fit into the fixed-sizeNC SDU, e.g. see packet #2, #3, and #4in the NC SDUs shown in Figure 9. Thenthe NC SDUs are encoded by the RLNCencoder to generate RLNC PDUs.

The main drawback of this option is thefact that NC SDU sizes are fixed andneeds to be filled with complete or seg-ments of incoming packets. If an NC SDUis only partially filled, it waits for incom-


MBMS SDUH

H

MBMS SDUH

SDU SegmentH

RLC

MAC

MBMS packet #1Service 1

SDU Segment


NC sublayer



MBMS SDUH MBMS SDUH

Variable packet sizes

Variable NC SDU size#1

RLC SDU RLC SDU RLC SDU

SDU Segment

segmentation

RLNC Encoder

Fixed

NC PDU

sizeH NC PDU Data H NC PDU Data H NC PDU Data

#2 #3 #4

RLC SDU

H NC PDU Data

More NC PDU

RLC SDU SDU SegmentH

MAC SDU


H MAC SDU


HMAC SDUH

Figure 8: 1st feasible option for RLNC functions placement above RLC layer (location #1).

MBMS SDUH MBMS SDUH

MBMS packet #1Service 1


NC sublayer



MBMS SDUH MBMS SDUH

Variable packet sizes

Fixed NC SDU size#1 #2 #3 #3 #4

RLC SDU RLC SDU RLC SDU

RLNC Encoder

Fixed NC PDU sizeH NC PDU Data H NC PDU Data H NC PDU Data

H

MAC SDU

SDU SegmentH


RLC

MAC

SDU Segment

H

SDU Segment

MAC SDU


H

segmentation

RLC SDU SDU SegmentH

MAC SDUH

Figure 9: 2nd feasible option for RLNC functions placement above RLC layer (location #1).


ing packet before it is passed on to theencoder. In essence, it may incur delays inthe process. However, a minimum afford-able delay can be configured to stop wait-ing for incoming packet and use paddinginstead.

Due to its efficient radio resource utiliza-tion capability, we select option #2 (cf.Figure 9) as a way forward in the im-plementation of RLNC-based 2nd layer ofFEC in RAN for PTM communication.

IV.C Proposed Implementation

As described in Section III.B.2, the mainrequirement for a UE to decode RLNC en-coded data is to receive at least as manyRLNC PDUs as the number of encodedNC SDUs. However, some RLNC PDUscan be lost due to lossy wireless transmis-sion channel. Hence, a certain number ofextra RLNC PDUs will have to be sentto the UE to compensate for the loss ofpackets. Existing approaches like the AL-FEC standardized for LTE do this only ina pre-emptive manner, which may morethan needed in some situations and stillnot be sufficient in others. Hence the pro-posal of this work is to use feedback forthe UEs to signal how many more PDUs

would be required.

While [15] proposes the use of sliding win-dow to optimize the en- / decoding com-plexity in the application layer, we hereinstick to the use of a sequence of gener-ations of fixed size successive en- / de-coding in order to maintain en- / decoderhistory without incurring delays related toblock-wise encoding. If the UE is unableto decode all NC SDUs of a certain gen-eration after reception of a given numberof RLNC PDUs, it can use uplink feed-back to signal to the network the numberof RLNC PDUs required for that genera-tion. Then, the network transmits addi-tional RLNC PDUs from the notified gen-eration, doing so again over the multicast/ broadcast channel, which is a clear im-provement over the conventional packet-specific HARQ considered in [4]. UnlikeHARQ ACK / NACK feedback messagesthat are triggered with every receptionof a packet, the NC uplink feedback istriggered only if the UE is unable to de-code after reception of RLNC PDUs thatare outputs of a successive encoding ofSDUs from a certain generation sequence.For efficiency this checking and reportingcan be restricted to be performed onlywith a certain periodicity depending onthe latency requirements of the service,


e.g. 50ms.

In this process, the network can takeinto account already transmitted addi-tional PDUs if multiple RLNC feedbackmessages have been received from differ-ent UEs for the same generation, as ad-ditional PDUs requested by one UE areagain multicasted / broadcasted and mayhence also be received by other UEs. Oneaspect of such an implementation is thatthe network tracks the count of trans-mitted PDUs for the last N generation.Ideally, the network would track all previ-ous generation; however, it is expensive interms of memory requirements to main-tain the entire history, and may also notbe required depending on latency require-ments of the service. Hence, maintainingthe count of additionally sent PDUs forthe last N generations, which is a designparameter, is indispensable. Great caremust be taken with the computation ofhow many additional PDUs are required inorder to provide the truly required numberwithout on the other hand overloading thetransmit buffer with an exorbitant numberof additional PDUs.

V Performance Evaluation

V.A Simulation Settings

System-level simulations of communica-tion networks mimic geographically con-fined parts of a communication net-work consisting of multiple base stationsand numerous UEs, gateways, applicationservers etc., i.e., including layer-2/3 andpossibly higher layer protocol functional-ities. This allows for evaluation of as-pects such as resource management, in-terference between different concurrenttransmissions or higher-layer considera-tion, such as the impact of radio networkperformance on TCP connections or userexperience at the application level. Thismay take into account UE distributions ormobility according to synthetic models orin “real-world” scenarios.

Herein, we compare the newly proposedfeedback-based 2nd layer FEC schemeagainst two reference schemes:

No AL-FEC: Operation without anykind of AL-FEC and

AL-FEC: Operation with LTE-like AL-FEC, i.e., a systematic fountaincode. Deviating from the LTEspecification, we use a system-


Parameter Value

Carrier frequency 3.5 GHz

Total BS transmit power 51 dBm

Systembandwidth 100 MHz

Number of BS antennas 8

Inter-site distance 200 m

Number of UE antennas 8

UE mobility model 3kmph, randomlyuniform distr.

BS noise figure 5 dB

UE noise figure 9 dB

BS ant. element gain 14 dBi

BS ant. elev. 3dB-BW 10◦

BS ant. azim. 3dB-BW 65◦

BS ant. mech. downtilt 20◦

UE ant. element gain 0 dBi

PTP traffic model Full buffer

PTM traffic model 8Mbps,packet arrival rate 100Hz

Channel model 3GPP TR 38.901 [16]

Table 1: Main simulation parameters.

atic RLNC code with optimal—e.g.Gauss-Jordan elimination based—decoding. A comparison with ac-tual Raptor codes as standardized fordeployment in LTE is shown in Fig-ure 10 and discussed below.

Of the various test environments de-fined for IMT-2020 evaluations [17], ur-ban dense test environment is used forsample performance evaluation of the pro-posed 2nd layer of FEC in RAN andits comparison with AL-FEC and no AL-FEC. Table 1 summarizes the main simu-lation parameters, which are derived fromthe “Dense Urban” scenario. The 2ndlayer FEC mechanisms all operate in theGF(256) and with a generation size of 100symbols, i.e., over 1sec.

V.B Simulation Results

We start by comparing the LTE Rap-tor codes against the systematic RLNCcode with optimal decoding used in thispaper as feedback-less AL-FEC referencescheme. The comparison is done with re-spect to probability of failure as a func-tion of the reception overhead, i.e., thenumber of PDUs received in excess of thetheoretical absolute minimum required for


0 1 2 3 410

−5

10−4

10−3

10−2

10−1

100

Absolute overhead i [# packets]

pfa

il, i

Sys. RLNC, NG

=100

Sys. RLNC, NG

=256

Sys. RLNC, NG

=512

Sys. RLNC, NG

=1024

Sys. RLNC, NG

=2048

Raptor, NG

=256

Raptor, NG

=512

Raptor, NG

=1024

Raptor, NG

=2048

Figure 10: Comparison of systematic RLNCcode and Raptor code with 40% packet lossrate.

decoding a generation, cf. Figure 10. ForRaptor codes, we took the data from [18,Fig. 6]. Like in [18, Fig. 6], we assumea 40% packet loss rate in the simulation.While the optimally decoded systematicRLNC code clearly exhibits better perfor-mance in terms of decoding failure ratevs. reception overhead, a true Raptor codecould in principle be used just as well asbasis of our feedback-based 2nd layer FECscheme. The difference in terms of aver-age overall spectral efficiency as consid-ered below is very small: For the gener-ation size of 100 considered in this work,the average reception overheads for theRaptor code and optimally decoded sys-

tematic RLNC code computed via

− 1 +∞∑i=0

NG + 1

NG

(1− pfail,i) ·i−1∏j=0

pfail,j

(3)are . 2% and . 0.1%, respectively. Atthis pfail,i denotes the probability that thecode cannot completely decode a genera-tion with reception overhead i, as shownin Figure 10.

Figures 11, 12 and 13 show the cumula-tive distribution function (CDF) of appli-cation layer spectral efficiency, applicationlayer packet loss rate and RLC SDU lossrate, respectively, for AL-FEC with 10%redundancy at application layer and dif-ferent MCSs at layer-1 FEC as well as noAL-FEC for one sample MCS. Here, theCDFs of the spectral efficiency are simplestep functions due to the fixed modula-tion and coding parameters. With moreaggressive MCS settings, i.e., higher spec-tral efficiency of the layer-1 transmissionscheme, both the application layer packetloss rate and the RLC SDU loss rate in-crease. Comparing AL-FEC with no AL-FEC for the same MCS, one can observethat as expected there is no impact at theRLC layer in terms of the RLC SDU lossrate. However, at the application layer,


0 0.2 0.4 0.6 0.8 1 1.20

0.5

1

1.5

2

Application layer SE [b/s/Hz]

CD

F

No AL−FEC; QPSK, Rc = 0.5879AL−FEC; QPSK, Rc = 0.4385

AL−FEC; QPSK, Rc = 0.5879AL−FEC; 16QAM, Rc = 0.3691

Figure 11: CDF of application layer SE[b/s/Hz] for no AL-FEC and AL-FEC withvarious MCS settings.

10−3

10−2

10−1

100

0.8

0.88

0.96

Application layer packet loss rate

CD

F

No AL−FEC; QPSK, Rc = 0.5879

AL−FEC; QPSK, Rc = 0.4385


AL−FEC; 16QAM, Rc = 0.3691

Figure 12: CDF of application layer packetloss rate for no AL-FEC and AL-FEC. withvarious MCS settings.

10−3

10−2

10−1

100

0.8

0.88

0.96

RLC SDU loss rate

CD

F

No AL−FEC; QPSK, Rc = 0.5879



AL−FEC; 16QAM, Rc = 0.3691

Figure 13: CDF of RLC SDU loss rate forno AL-FEC and AL-FEC with various MCSsettings.

AL-FEC provides improved (lower) packetloss rate, as it is able to repair smallerpacket loss events.

Figures 14 and 15 show the CDF ofapplication layer spectral efficiencies andpacket loss rates, respectively, for no AL-FEC and AL-FEC with the same MCS set-ting of ‘QPSK, Rc = 0.59’ for various lev-els of redundancy of repair packet: 10%,20% and 30%. Herein, AL-FEC consider-ably improves the application layer packetloss rate at a cost of reduced spectral ef-ficiency. It can be observed, how higherlevels of redundancy are able to fix higherpacket loss rates in the lower layers.


Figures 16 and 17 show CDF comparisonof 2nd layer of FEC in RAN against AL-FEC and no AL-FEC in terms of applica-tion layer spectral efficiencies and packetloss rates, respectively, for a sample MCSsetting of ‘QPSK, Rc = 0.59’. The 2ndlayer of FEC in RAN utilizes periodicfeedback (50ms) for triggering transmis-sion of appropriate numbers of additionalRLNC PDUs to compensate for lost pack-ets. Consequently, the 2nd layer of FECin RAN exhibits further improved packetloss rate performance as compared to con-ventional AL-FEC. At the same time, thespectral efficiency for 2nd layer of FEC inRAN is higher than that of AL-FEC be-cause in the 2nd layer of FEC additionalRLNC PDUs are not sent preemptively butare generated and sent only based on re-quest. Accordingly, with the current con-figuration, in approximately 60% of alldrops no additional RLNC PDUs are re-quired for decoding and in less than 10%of all drops, the overall spectral efficiencyis lower than that of conventional AL-FEC, but with the benefit of having zero(at least < 10−3) packet loss rate.

Figures 18, 19 and 20 show the delay anal-ysis of 2nd layer of FEC in RAN as com-pared to AL-FEC. Figure 18 contains theinverse-CDF (I-CDF) of the difference be-

0 0.2 0.4 0.6 0.8 1 1.20

0.5

1

1.5

2


CD

F

No AL−FECAL−FEC; Redundancy 10%

AL−FEC; Redundancy 20%AL−FEC; Redundancy 30%

Figure 14: CDF of application layer SE[b/s/Hz] for no AL-FEC and AL-FEC withvarious redundancy levels and ‘QPSK, Rc =0.59’.

10−3

10−2

10−1

100

0.8

0.88

0.96


CD

F

No AL−FEC

AL−FEC; Redundancy 10%



Figure 15: CDF of application layer packetloss rate for no AL-FEC and AL-FEC withvarious levels of redundancy ‘QPSK, Rc =0.59’.


tween the reception time of an applicationlayer packet and its transmission time forAL-FEC with various MCS settings andfor 2nd layer of FEC with ‘QPSK, Rc =0.59’. For AL-FEC, the application layerdelay is higher for less conservative MCSsettings since the packet loss rate is higherand some application layer packet are re-covered after reception of repair packetsand others are delayed by the thus trig-gered reordering process. Note that forthe conventional AL-FEC, no delays be-yond 1.1s occur, as the reordering in thereceiver is implemented to assume that1.1s after the reception of the first PDUof a generation no more PDUs from thatgeneration will be received.5 The applica-tion layer delay distribution is considerablymore favorable for the 2nd layer of FEC ascompared to AL-FEC for the same MCSsetting of ‘QPSK, Rc = 0.59’ due to thefact that repair packets are re-transmittedon the fly based on the periodic opportu-nity for feedback.

Such application layer delay can be cru-cial in determining the quality of experi-ence in watching a video, where a play-out buffer is installed to avoid frequent

5Recall that each generation contains SDUsgenerated over an interval of 1sec.

0 0.2 0.4 0.6 0.8 1 1.20

0.5

1

1.5

2


CD

F

No AL−FECAL−FEC

RAN 2nd layer FECMean SE; RAN 2nd layer FEC

Figure 16: CDF of application layer SE[b/s/Hz] for no AL-FEC, AL-FEC and 2ndlevel of FEC in RAN with ‘QPSK, Rc = 0.59’.

10−3

10−2

10−1

100

0.8

0.88

0.96


CD

F

No AL−FEC

AL−FEC

RAN 2nd layer FEC

Figure 17: CDF of application layer packetloss rate for no AL-FEC, AL-FEC and 2ndlevel of FEC in RAN with ‘QPSK, Rc = 0.59’.


0 0.2 0.4 0.6 0.8 110

−8

10−6

10−4

10−2

100

Application layer delay [s]

I−C

DF



AL−FEC; 16QAM, Rc = 0.3691

RAN 2nd layer FEC

Figure 18: I-CDF of application layer packetdelay for AL-FEC with various MCS settingsand for 2nd layer of FEC with ‘QPSK, Rc =0.59’.

0 5 10 150.6

0.65

0.7

0.75

0.8

0.85

0.9

0.95

1

Packet stalling frequency [Hz]

CD

F



AL−FEC; 16QAM, Rc = 0.3691

RAN 2nd layer FEC

Figure 19: CDF of application layer packetstalling frequency for AL-FEC with variousMCS settings and for 2nd layer of FEC with‘QPSK, Rc = 0.59’.

stalling of playback while in normal opera-tion incurring some buffering delay. In or-der to achieve a high quality of experiencethe target is to minimize this buffering de-lay, while keeping the frequency of stallingevents and the total relative time of stalls,i.e., the aggregated stalling time normal-ized by the observation window length,low. Figures 19 and 20 show the CDFsof packet stalling frequency and relativepacket stalling period, respectively, as-suming a play-out buffer size / stallingthreshold of 1.1s, i.e., slightly larger thanwhat is covered by one generation of NCSDUs to allow the repair packets of thesystematic AL-FEC code sent at the endof the generation to repair also losses onall packets of the generation.

In this case, the 2nd layer of FEC providesa better performance in terms of packetstalling frequency and packet stalling pe-riod as compared to AL-FEC for the com-pared sample MCS setting of ‘QPSK, Rc= 0.59’. Furthermore, it can be observedthat it exhibits delay characteristics verysimilar to those of conventional AL-FECwith ‘QPSK, Rc = 0.44’, while the over-all spectral efficiency is about 30% highercompared to this reference scheme. Judg-ing from Figure 18 one can also observethat with the new scheme the play-out


0 0.2 0.4 0.6 0.8 10.6

0.65

0.7

0.75

0.8

0.85

0.9

0.95

1

Packet stalling period ratio

CD

F



AL−FEC; 16QAM, Rc = 0.3691

RAN 2nd layer FEC

Figure 20: CDF of application layer packetstalling period ratio for AL-FEC with variousMCS settings and for 2nd layer of FEC with‘QPSK, Rc = 0.59’.

buffer time could be reduced to 0.2s whilethe probability of stalling due to a latepacket would still be below 10−3, i.e., oncein every 10s, or once in every 100s with aplay-out buffer of 0.5s.

VI Conclusions

A highly flexible and efficient radio ac-cess technology is one of the requirementsto support future generation broadcast /multicast vertical sectors. One of the lim-itations of current radio systems is ineffi-ciencies in spectral efficiency and packet

loss rates due to shorter and longer timescale degradation of the signal. In 3GPPa first layer of FEC on the physical layeris specified mainly for robustness againstshorter time scale degradation of radiosignals, while for broadcast / multicastsystematic Raptor codes are applied to re-cover losses left after physical-layer FEC.This white paper proposed a feedback-based 2nd layer of FEC scheme for mixedmode broadcast / multicast to implementhighly efficient wireless broadcast / mul-ticast system that can provide robustnessfor longer time scale signal degradations,as well.

Elaborate system level analysis were per-formed to assess the performance of thisscheme in comparison to state of the artreference schemes, namely conventionalsystematic AL-FEC codes and operationwithout AL-FEC. Figure 21 summarizesthe major findings of this system-levelsimulation based study in terms of av-erage application layer spectral efficiency,average packet loss rate, average stallingfrequency and average stalling period ra-tio. The analysis was done with the lat-est channel models used for IMT-2020evaluation and within 3GPP, in particu-lar the “dense urban” scenario. It wasfound that by sacrificing some overall


No AL−FEC AL−FEC RAN 2nd layer FEC0

0.2

0.4

0.6

0.8

1

Avera

ge a

pplic

ation layer

SE

No AL−FEC AL−FEC RAN 2nd layer FEC0

0.5

1

1.5

2x 10

−3

Avera

ge a

pplic

ation layer

packet lo

ss r

ate

AL−FEC RAN 2nd layer FEC0

0.01

0.02

0.03

0.04

0.05

0.06

Avera

ge s

talli

ng fre

quency [H

z]

AL−FEC RAN 2nd layer FEC0

0.2

0.4

0.6

0.8

1

1.2

1.4x 10

−3

Avera

ge s

talli

ng p

eriod r

atio

Figure 21: Comparison among no AL-FEC, AL-FEC and 2nd layer of FEC in RAN.

spectral efficiency the AL-FEC providesan improvement in the packet loss rateby around 35%, as compared to no AL-FEC. On the other hand, the 2nd layerof FEC as proposed in this paper avoidspacket losses practically entirely, with lim-ited sacrifice on average overall spectralefficiency (around 3%), because trans-missions of additional repair packets aretriggered only with loss of packet, i.e.,no regular redundant repair packets areneeded. In regards to comparison of 2ndlayer of FEC in RAN and AL-FEC in termsof average stalling frequency and averagestalling period ratio for video streamingapplication, we observed that these can beavoided practially entirely, while the newscheme still operates at a higher averagespectral efficiency.

Acknowledgement: This work was sup-ported in part by the European Commis-

sion under the 5G-PPP project Broadcastand Multicast Communication Enablersfor the Fifth-Generation of Wireless Sys-tems 5G-XCast (H2020-ICT-2016-2 call,grant number 761498). The views ex-pressed in this contribution are those ofthe authors and do not necessarily repre-sent the project.

References

[1] D. Vargas and D. Mi (Eds). Perfor-mance of LTE Advanced Pro (Rel-14) eMBMS, deliverable D3.1, 5G-PPP 5G-Xcast project. November2017.

[2] 3GPP. NR; NR and NG-RAN Over-all Description; Stage 2 (Release 15).3GPP TS 38.212 v15.2.0, June 2018.


[3] 3GPP. Multimedia Broad-cast/Multicast Service (MBMS);Protocols and Codecs (Release 15).3GPP TS 26.346 v15.1.0, June2018.

[4] 3GPP. E-UTRA; Study on Single-Cell Point-to-Multipoint Transmis-sion for E-UTRA (Release 13). 3GPPTR 36.890, July 2015.

[5] 3GPP. Technical SpecificationGroup Radio Access Network;Evolved Universal Terrestrial RadioAccess (E–UTRA); E-UTRAN;Overall description; Stage 2(Rel. 14). 3GPP TS 36.300v14.6.0, April 2018.

[6] 3GPP. NR; Multiplexing and Chan-nel Coding (Release 15). 3GPP TS38.300 v15.2.0, June 2018.

[7] 3GPP. E-UTRA and NR; ServiceData Adaptation Protocol (SDAP)Specification (Release 15). 3GPP TS37.324 v15.0.0, June 2018.

[8] 3GPP. NR; Packet Data Conver-gence Protocol (PDCP) Specifica-tions (Release 15). 3GPP TS 38.323v15.2.0, June 2018.

[9] 3GPP. NR; Radio Link Control(RLC) Protocol Specifications (Re-

lease 15). 3GPP TS 38.322 v15.2.0,June 2018.

[10] 3GPP. NR; Medium Access Control(MAC) Protocol Specifications (Re-lease 15). 3GPP TS 38.321 v15.2.0,June 2018.

[11] A. Awada, D. Navratil, and M. Saily.Study on Single-Cell Point-to-Multipoint Transmission for PublicSafety Communications with eM-BMS LTE Networks. In IEEEWCNC, April 2016.

[12] T. Ho, M. Medard, R. Koetter,D.R. Karger, M. Effros, J. Shi, andB. Leong. A Random Linear NetworkCoding Approach to Multicast. IEEETransactions on Information Theory,Oct 2006.

[13] M. Toemoeskoezi, F. Fitzek, D. Lu-cani, M. Pederson, and P. Seel-ing. On the Delay Characteristicsfor Point-to-Point Links using Ran-dom Linear Network Coding with on-the-fly Coding Capabilities. In IEEEEuropean Wireless Conference, May2014.

[14] V. Roca and B. Teibi. Slding WindowRandom Linear Code (RLC) ForwardErasure Correction (FEC) Schemes


for FECFRAME. IETF Draft, March2018.

[15] V. Roca, T. Tran, B. Teibi, C. Bur-dinant, and C. Thienot. Less La-tency and better Protection withAL-FEC Sliding Window Codes: Arobust Multimedia CBR BroadcastCase Study. In IEEE WiMob, Oc-tober 2017.

[16] 3GPP. Technical SpecificationGroup Radio Access Network; Studyon Channel Model for Frequenciesfrom 0.5 to 100 GHz (Rel. 14). 3GPPTR 38.901 v14.1.1, July 2017.

[17] ITU. Guidelines for Evaluation of Ra-dio Interface Technologies for IMT-2020. ITU Document 5/57-E, Octo-ber 2017.

[18] T. Stockhammer, A. Shokrollahi,M. Watson, M. Luby, and T. Ga-siba. Application Layer Forward Er-ror Correction for Mobile MultimediaBroadcasting. Handbook of MobileBroadcasting: DVB-H, DMB, ISDB-T and Media FLO, pages 239–280,2008.

Note:This white paper is provided to you

by Nomor Research GmbH. Simi-lar documents can be obtained fromhttp://www.nomor.de. Please supportour work in the social media.

Consultancy Services: Please contactus in case you are interested in our servicesby sending an email to [email protected].

3GPP related Consultancy Services:

• Link and System Level Simulations• Research, Analyses and Concept De-

velopment• Demonstration and Prototyping• 3GPP Standardization Support• Technology Training• Patents Support

Technical Areas:

• Mobile Communication Networks• Mission Critical Communication• Vehicular Communication• Satellite and Broadcast• Multimedia Delivery and Content

Distribution• Internet of Things

Disclaimer:This paper is provided for informationalpurpose only. We do not accept any re-sponsibility for the content of this newslet-ter. Nomor Research GmbH has no obli-gation to update, modify or amend or to


http://www.nomor.de

mailto:[email protected]

otherwise notify the reader thereof in theevent that any matter stated herein, orany opinion, projection, forecast or esti-mate set forth herein, changes or subse-quently becomes inaccurate. Please notein our assessment(s) we only consideredthose facts known to us and therefore theresults of our assessment / assessmentsare subject to to change due to facts cur-rently not known to us. Furthermore,please note, with respect to our assess-ment(s) different opinions might be ex-pressed in the relevant literature and theremay be some other interpretations whichare scientifically valid.


Documents

Layer 2 FEC in 5G Broadcast / Multicast Networks5g-xcast.eu/wp-content/uploads/2018/09/Nomor... · lower layers. On the other hand, the ma-jor functions of the MAC protocol in LTE