Tech-invite3GPPspecsSIPRFCs
Overview21222324252627282931323334353637384‑5x

Content for  TS 38.300  Word version:  16.3.0

Top   Top   Up   Prev   Next
1…   4…   4.7…   5…   5.3…   5.4…   6…   6.2…   6.6…   7…   8…   9…   9.2.2…   9.2.3…   9.2.3.2   9.2.3.3…   9.2.4…   9.2.6…   9.3…   10…   11…   15…   15.5…   16…   16.3   16.4…   17…   A…   B…

 

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 RBx and one RLC PDU from RBy. The two RLC PDUs from RBx each corresponds to one IP packet (n and n+1) while the RLC PDU from RBy is a segment of an IP packet (m).
Reproduction of 3GPP TS 38.300, Figure 6.6-1: Data Flow Example
Up

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.
Reproduction of 3GPP TS 38.300, Figure 6.7-1: Layer 2 Structure for DL with CA configured
Up
Reproduction of 3GPP TS 38.300, Figure 6.7-2: Layer 2 Structure for UL with CA configured
Up

6.8  Dual ConnectivityWord‑p. 47
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.

6.9  Supplementary Uplink

In case of Supplementary Uplink (SUL, see TS 38.101-1), 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.
Up

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:
  • BWP1 with a width of 40 MHz and subcarrier spacing of 15 kHz;
  • BWP2 with a width of 10 MHz and subcarrier spacing of 15 kHz;
  • BWP3 with a width of 20 MHz and subcarrier spacing of 60 kHz.
Reproduction of 3GPP TS 38.300, Figure 6.10-1: BA Example
Up

6.11  Backhaul Adaptation Protocol Sublayer |R16|Word‑p. 48

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 signalling;
  • BH RLF indication.

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 IAB-DUs.
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. 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.
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.
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 towards different parent IAB-DUs.
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.
Up

6.11.3  Routing and BH-RLC-channel mapping on BAP sublayerWord‑p. 49
Reproduction of 3GPP TS 38.300, Figure 6.11.3-1: Routing and BH RLC channel selection on BAP sublayer
Up
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.
  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. This configuration contains the mapping between the BAP routing ID carried in the packet's BAP header and the next-hop node's BAP address.
BAP routing ID
Next-hop BAP address

Derived from BAP packet's BAP header
Egress 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 with its child-node's BAP address via F1AP and its parent-node's BAP address via RRC.
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 has RLF, the IAB-node may select another BH link based on routing entries with the same destination BAP address, i.e., by disregarding the BAP path ID. In this manner, a packet can be delivered via an alternative path in case the indicated path is not available.
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:
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 link
Derived from packet's ingress BH RLC channel
BH RLC channel on egress link to forward packet

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.
Up


Up   Top   ToC