6 Layer 2

38.3003GPPNRNR and NG-RAN Overall descriptionRelease 17Stage 2TS

Tools: ARFCN - Frequency Conversion for 5G NR/LTE/UMTS/GSM

6.1 Overview

The layer 2 of NR is split into the following sublayers: Medium Access Control (MAC), Radio Link Control (RLC), Packet Data Convergence Protocol (PDCP) and Service Data Adaptation Protocol (SDAP). The two figures below depict the Layer 2 architecture for downlink and uplink, where:

– The physical layer offers to the MAC sublayer transport channels;

– The MAC sublayer offers to the RLC sublayer logical channels;

– The RLC sublayer offers to the PDCP sublayer RLC channels;

– The PDCP sublayer offers to the SDAP sublayer radio bearers;

– The SDAP sublayer offers to 5GC QoS flows;

– Comp. refers to header compression or uplink data compression;

– Segm. refers to segmentation;

– Control channels (BCCH, PCCH are not depicted for clarity).

NOTE: The gNB may not be able to guarantee that a L2 buffer overflow will never occur. If such overflow occurs, the UE may discard packets in the L2 buffer.

Figure 6.1-1: Downlink Layer 2 Structure

Figure 6.1-2: Uplink Layer 2 Structure

Radio bearers are categorized into two groups: data radio bearers (DRB) for user plane data and signalling radio bearers (SRB) for control plane data.

For IAB, the Layer 2 of NR includes: MAC, RLC, Backhaul Adaptation Protocol (BAP), PDCP and optionally SDAP.

– The BAP sublayer supports routing across the IAB topology and traffic mapping to BH RLC channels for enforcement of traffic prioritization and QoS.

Figures 6.1-3 below depicts the Layer-2 architecture for downlink on the IAB-donor. Figure 6.1-4 and 6.1-5 depict the Layer-2 architecture for downlink and uplink on the IAB-node, where the BAP sublayer offers routing functionality and mapping to BH RLC channels.

Figure 6.1-3: DL L2-structure for user plane at IAB-donor

Figure 6.1-4: DL L2-structure at IAB-node

Figure 6.1-5: UL L2-structure at IAB-node

6.2 MAC Sublayer

6.2.1 Services and Functions

The main services and functions of the MAC sublayer include:

– Mapping between logical channels and transport channels;

– Multiplexing/demultiplexing of MAC SDUs belonging to one or different logical channels into/from transport blocks (TB) delivered to/from the physical layer on transport channels;

– Scheduling information reporting;

– Error correction through HARQ (one HARQ entity per cell in case of CA);

– Priority handling between UEs by means of dynamic scheduling;

– Priority handling between logical channels of one UE by means of logical channel prioritisation;

– Priority handling between overlapping resources of one UE;

– Padding.

A single MAC entity can support multiple numerologies, transmission timings and cells. Mapping restrictions in logical channel prioritisation control which numerology(ies), cell(s), and transmission timing(s) a logical channel can use (see clause 16.1.2).

6.2.2 Logical Channels

Different kinds of data transfer services as offered by MAC. Each logical channel type is defined by what type of information is transferred. Logical channels are classified into two groups: Control Channels and Traffic Channels. Control channels are used for the transfer of control plane information only:

– Broadcast Control Channel (BCCH): a downlink channel for broadcasting system control information.

– Paging Control Channel (PCCH): a downlink channel that carries paging messages.

– Common Control Channel (CCCH): channel for transmitting control information between UEs and network. This channel is used for UEs having no RRC connection with the network.

– Dedicated Control Channel (DCCH): a point-to-point bi-directional channel that transmits dedicated control information between a UE and the network. Used by UEs having an RRC connection.

Traffic channels are used for the transfer of user plane information only:

– Dedicated Traffic Channel (DTCH): point-to-point channel, dedicated to one UE, for the transfer of user information. A DTCH can exist in both uplink and downlink.

6.2.3 Mapping to Transport Channels

In Downlink, the following connections between logical channels and transport channels exist:

– BCCH can be mapped to BCH;

– BCCH can be mapped to DL-SCH;

– PCCH can be mapped to PCH;

– CCCH can be mapped to DL-SCH;

– DCCH can be mapped to DL-SCH;

– DTCH can be mapped to DL-SCH.

In Uplink, the following connections between logical channels and transport channels exist:

– CCCH can be mapped to UL-SCH;

– DCCH can be mapped to UL- SCH;

– DTCH can be mapped to UL-SCH.

6.2.4 HARQ

The HARQ functionality ensures delivery between peer entities at Layer 1. A single HARQ process supports one TB when the physical layer is not configured for downlink/uplink spatial multiplexing, and when the physical layer is configured for downlink/uplink spatial multiplexing, a single HARQ process supports one or multiple TBs.

6.3 RLC Sublayer

6.3.1 Transmission Modes

The RLC sublayer supports three transmission modes:

– Transparent Mode (TM);

– Unacknowledged Mode (UM);

– Acknowledged Mode (AM).

The RLC configuration is per logical channel with no dependency on numerologies and/or transmission durations, and ARQ can operate on any of the numerologies and/or transmission durations the logical channel is configured with.

For SRB0, paging and broadcast system information, TM mode is used. For other SRBs AM mode used. For DRBs, either UM or AM mode are used.

6.3.2 Services and Functions

The main services and functions of the RLC sublayer depend on the transmission mode and include:

– Transfer of upper layer PDUs;

– Sequence numbering independent of the one in PDCP (UM and AM);

– Error Correction through ARQ (AM only);

– Segmentation (AM and UM) and re-segmentation (AM only) of RLC SDUs;

– Reassembly of SDU (AM and UM);

– Duplicate Detection (AM only);

– RLC SDU discard (AM and UM);

– RLC re-establishment;

– Protocol error detection (AM only).

6.3.3 ARQ

The ARQ within the RLC sublayer has the following characteristics:

– ARQ retransmits RLC SDUs or RLC SDU segments based on RLC status reports;

– Polling for RLC status report is used when needed by RLC;

– RLC receiver can also trigger RLC status report after detecting a missing RLC SDU or RLC SDU segment.

6.4 PDCP Sublayer

6.4.1 Services and Functions

The main services and functions of the PDCP sublayer include:

– Transfer of data (user plane or control plane);

– Maintenance of PDCP SNs;

– Header compression and decompression using the ROHC protocol;

– Header compression and decompression using EHC protocol;

– Compression and decompression of uplink PDCP SDUs: DEFLATE based UDC only;

– Ciphering and deciphering;

– Integrity protection and integrity verification;

– Timer based SDU discard;

– For split bearers, routing;

– Duplication;

– Reordering and in-order delivery;

– Out-of-order delivery;

– Duplicate discarding.

Since PDCP does not allow COUNT to wrap around in DL and UL, it is up to the network to prevent it from happening (e.g. by using a release and add of the corresponding radio bearer or a full configuration).

6.5 SDAP Sublayer

The main services and functions of SDAP include:

– Mapping between a QoS flow and a data radio bearer;

– Marking QoS flow ID (QFI) in both DL and UL packets.

A single protocol entity of SDAP is configured for each individual PDU session.

6.6 L2 Data Flow

An example of the Layer 2 Data Flow is depicted on Figure 6.6-1, where a transport block is generated by MAC by concatenating two RLC PDUs from RB_x and one RLC PDU from RB_y. The two RLC PDUs from RB_x each corresponds to one IP packet (n and n+1) while the RLC PDU from RB_y is a segment of an IP packet (m).

NOTE: H depicts the headers and subheaders.

Figure 6.6-1: Data Flow Example

6.7 Carrier Aggregation

In case of CA, the multi-carrier nature of the physical layer is only exposed to the MAC layer for which one HARQ entity is required per serving cell as depicted on Figures 6.7-1 and 6.7-2 below:

– In both uplink and downlink, there is one independent hybrid-ARQ entity per serving cell and one transport block is generated per assignment/grant per serving cell in the absence of spatial multiplexing. Each transport block and its potential HARQ retransmissions are mapped to a single serving cell.

Figure 6.7-1: Layer 2 Structure for DL with CA configured

Figure 6.7-2: Layer 2 Structure for UL with CA configured

6.8 Dual Connectivity

When the UE is configured with SCG, the UE is configured with two MAC entities: one MAC entity for the MCG and one MAC entity for the SCG. Further details of DC operation can be found in TS 37.340 [21].

6.9 Supplementary Uplink

In case of Supplementary Uplink (SUL, see TS 38.101-1 [18]), the UE is configured with 2 ULs for one DL of the same cell, and uplink transmissions on those two ULs are controlled by the network to avoid overlapping PUSCH/PUCCH transmissions in time. Overlapping transmissions on PUSCH are avoided through scheduling while overlapping transmissions on PUCCH are avoided through configuration (PUCCH can only be configured for only one of the 2 ULs of the cell). In addition, initial access is supported in each of the uplink (see clause 9.2.6). An example of SUL is given in Annex B.

6.10 Bandwidth Adaptation

With Bandwidth Adaptation (BA), the receive and transmit bandwidth of a UE need not be as large as the bandwidth of the cell and can be adjusted: the width can be ordered to change (e.g. to shrink during period of low activity to save power); the location can move in the frequency domain (e.g. to increase scheduling flexibility); and the subcarrier spacing can be ordered to change (e.g. to allow different services). A subset of the total cell bandwidth of a cell is referred to as a Bandwidth Part (BWP) and BA is achieved by configuring the UE with BWP(s) and telling the UE which of the configured BWPs is currently the active one.

Figure 6.10-1 below describes a scenario where 3 different BWPs are configured:

– BWP₁ with a width of 40 MHz and subcarrier spacing of 15 kHz;

– BWP₂ with a width of 10 MHz and subcarrier spacing of 15 kHz;

– BWP₃ with a width of 20 MHz and subcarrier spacing of 60 kHz.

Figure 6.10-1: BA Example

6.11 Backhaul Adaptation Protocol Sublayer

6.11.1 Services and Functions

The main service and functions of the BAP sublayer include:

– Transfer of data;

– Routing of packets to next hop;

– Determination of BAP destination and BAP path for packets from upper layers;

– Determination of egress BH RLC channels for packets routed to next hop;

– Differentiating traffic to be delivered to upper layers from traffic to be delivered to egress link;

– Flow control feedback and polling signalling;

– BH RLF detection indication, BH RLF recovery indication, and BH RLF indication;

– BAP header rewriting.

6.11.2 Traffic Mapping from Upper Layers to Layer-2

In upstream direction, the IAB-donor-CU configures the IAB-node with mappings between upstream F1 and non-F1 traffic originated at the IAB-node, and the appropriate BAP routing ID, next-hop BAP address and BH RLC channel. A specific mapping is configured:

– for each F1-U GTP-U tunnel;

– for non-UE associated F1AP messages;

– for UE-associated F1AP messages;

– for non-F1 traffic.

Multiple mappings can contain the same BH RLC channel and/or next-hop BAP address and/or BAP routing ID. In case the IAB-MT is NR-dual-connected (SA mode only), the mapping may include two separate BH RLC channels, where the two BH RLC channels are established toward different parent nodes.

In case the IAB-node is configured with multiple IP addresses for F1-C on the NR leg, multiple mappings can be configured for non-UE-associated F1AP messages or UE-associated F1AP messages. The appropriate mapping is selected based on the IAB-node’s implementation.

These traffic mapping configurations are performed via F1AP. For a boundary IAB-node, the traffic mapping configuration includes information that allows the boundary IAB-node to determine the IAB topology the mapping applies to.

During IAB-node integration, a default BH RLC channel and a default BAP routing ID may be configured via RRC, which can be used for non-F1-U traffic. These default configurations may be updated during topology adaptation scenarios as discussed in TS 38.401 [4].

In downstream direction, traffic mapping occurs internal to the IAB-donor. Transport for IAB-donors that use split-gNB architecture is handled in TS 38.401 [4].

6.11.3 Routing, BAP Header Rewriting and BH-RLC-channel Mapping on BAP sublayer

Figure 6.11.3-1: Routing and BH RLC channel selection on BAP sublayer

Routing on BAP sublayer uses the BAP routing ID, which is configured by the IAB-donor-CU. The BAP routing ID consists of BAP address and BAP path ID. The BAP address is used for the following purposes:

1. Determination if a packet has reached the destination node, i.e. IAB-node or IAB-donor-DU, on BAP sublayer. This is the case if the BAP address in the packet’s BAP header matches the BAP address configured via RRC on the IAB-node, or via F1AP on the IAB-donor-DU. For a dual-connected boundary IAB-node that is configured with two BAP addresses, the BAP address in the packet’s BAP header is matched with the BAP address configured by the CU of the IAB topology, where the packet has been received.

2. Determination of the next-hop node for packets that have not reached their destination. This applies to packets arriving from a prior hop on BAP sublayer or that have been received from IP layer.

For packets arriving from a prior hop or from upper layers, the determination of the next-hop node is based on a routing configuration provided by the IAB-donor-CU via F1AP signalling or a default configuration provided by the IAB-donor-CU via RRC signalling. This F1AP configuration contains the mapping between the BAP routing ID carried in the packet’s BAP header and the next-hop node’s BAP address.

Table 6.11.3-1: Routing configuration

BAP routing ID	Next-hop BAP address
Derived from BAP packet’s BAP header	Egress BH link to forward packet

The IAB-node resolves the next-hop BAP address to a physical backhaul link. For this purpose, the IAB-donor-CU provides the IAB-node/IAB-donor-DU with its child-node’s BAP address via F1AP, and it provides the IAB-node with its parent-node’s BAP address via RRC. For a boundary IAB-node, the routing configuration also indicates the IAB topology it applies to. The BH link to the next-hop node and the next-hop BAP address belong to the IAB topology of the CU that provided the RRC configuration of the BH link to that next-hop node.

The IAB-node can receive multiple routing configurations with the same destination BAP address but different BAP path IDs. These routing configurations may resolve to the same or different egress BH links.

In case the BH link resolved from the routing entry is considered unavailable for this packet, the IAB-node may perform local rerouting as defined in TS38.340 [31], i.e., select another BH link by considering only the packet’s BAP address or, in some cases, by header rewriting. In this manner, the packet can be delivered via an alternative path as defined in TS 38.340 [31].

A BH link may be considered unavailable in case the BH link has RLF. A parent link may be considered unavailable after a BH RLF detection indication has been received on this parent link and before a subsequent BH RLF recovery indication has been received on the same parent link. For DL traffic, a BH link may be considered unavailable for BAP PDUs carrying a certain BAP routing ID due to congestion derived from flow-control feedback information related to this BAP routing ID, as defined in TS 38.340 [31].

For a boundary IAB-node, the routing configuration may carry information on the IAB topology the configuration applies to.

The IAB-node may rewrite the BAP routing ID in the packet’s BAP header under the following circumstances:

– A packet is routed between two IAB topologies via a boundary IAB-node as defined in TS 38.401[31]. In this case, the BAP routing ID carried by the received BAP PDU is allocated by the IAB-donor-CU of the ingress IAB topology, while the BAP routing ID carried by the BAP PDU after header rewriting is allocated by the IAB-donor-CU of the egress IAB topology.

– An upstream packet is locally re-routed to a different IAB-donor-DU than indicated by the BAP address in the BAP header of the received packet. The rewritten BAP header carries the BAP address of the alternative IAB-donor-DU and the BAP path ID for a path to this alternative IAB-donor-DU. BAP header rewriting for upstream inter-IAB-donor-DU local rerouting is only applied if neither routing nor local re-routing without header rewriting resolve to an available egress BH link.

For packets that are routed between two IAB topologies via a boundary node, the BAP header rewriting configuration is provided via F1AP, and it includes the ingress BAP routing ID, the egress BAP routing ID, and it indicates the egress IAB topology:

Table 6.11.3-2a: BAP header rewriting configuration

Ingress BAP routing ID	Egress BAP routing ID	Egress topology indicator
BAP routing ID carried in the BAP header of the received BAP PDU	BAP routing ID carried in the BAP header of the transmitted BAP PDU	Indicates the egress IAB topology.

For upstream packets that are locally re-routed to a different IAB-donor-DU, the BAP header is rewritten with a BAP routing ID contained in the routing entry that was selected for re-routing.

Details of BAP header rewriting are defined in TS 38.340 [31].

When routing a packet from an ingress to an egress BH link, the IAB-node derives the egress BH RLC channel on the egress BH link through an F1AP-configured mapping from the BH RLC channel used on the ingress BH link. The BH RLC channel IDs used for ingress and egress BH RLC channels are generated by the IAB-donor-CU. Since the BH RLC channel ID only has link-local scope, the mapping configurations also include the BAP addresses of prior and next hop:

Table 6.11.3-2: BH RLC channel mapping configuration

Next-hop BAP address	Prior-hop BAP address	Ingress RLC channel ID	Egress RLC channel ID
Derived from routing configuration	Derived from packet’s ingress BH link	Derived from packet’s ingress BH RLC channel	BH RLC channel on egress BH link to forward packet

For a boundary IAB-node, the BH RLC channel mapping configuration may also include indicators for the IAB topology of the ingress and of the egress BH link.

The IAB-node resolves the BH RLC channel IDs from logical channel IDs based on the configuration by the IAB-donor-CU. The IAB-MT obtains the BH RLC channel ID in the RRC configuration of the corresponding logical channel. The IAB-DU obtains the BH RLC channel ID in the F1AP configuration of the BH RLC channel.

6.12 Multiple Transmit/Receive Point Operation

In Multiple Transmit/Receive Point (multi-TRP) operation, a serving cell can schedule the UE from two TRPs, providing better coverage, reliability and/or data rates for PDSCH, PDCCH, PUSCH, and PUCCH.

There are two different operation modes to schedule multi-TRP PDSCH transmissions: single-DCI and multi-DCI. For both modes, control of uplink and downlink operation can be done by physical layer and MAC layer, within the configuration provided by the RRC layer. In single-DCI mode, the UE is scheduled by the same DCI for both TRPs and in multi-DCI mode, the UE is scheduled by independent DCIs from each TRP.

There are two different operation modes for multi-TRP PDCCH: PDCCH repetition as in Clause 5.2.3 and SFN based PDCCH transmission. In both modes, the UE can receive two PDCCH transmissions, one from each TRP, carrying the same DCI. In PDCCH repetition mode, the UE can receive the two PDCCH transmissions carrying the same DCI from two linked search spaces each associated with a different CORESET. In SFN based PDCCH transmission mode, the UE can receive the two PDCCH transmissions carrying the same DCI from a single search space/CORESET using different TCI states.

For multi-TRP PUSCH repetition, according to indications in a single DCI or in a semi-static configured grant provided over RRC, the UE performs PUSCH transmission of the same contents toward two TRPs with corresponding beam directions associated with different spatial relations. For multi-TRP PUCCH repetition, the UE performs PUCCH transmission of the same contents toward two TRPs with corresponding beam directions associated with different spatial relations.

For inter-cell multi-TRP operation, for multi-DCI PDSCH transmission, one or more TCI states can be associated with SSB with a PCI different from the serving cell PCI. The activated TCI states can be associated with at most one PCI different from the serving cell PCI at a time.