Section: 7.11 F1-C transfer over E-UTRA
Content: In EN-DC, the F1-AP message encapsulated in SCTP/IP or F1-C related (SCTP/)IP packet can be transferred between IAB-donor and IAB-node via E-UTRA, if configured by IAB-donor, as specified in TS 38.331[ NR; Radio Resource Control (RRC); Protocol specification ]  [4]. When both E-UTRA and NR are configured to transfer the F1-AP message encapsulated in SCTP/IP or F1-C related (SCTP/)IP packet, it is up to the IAB implementation when to select the E-UTRA. SRB2 is used for transporting the F1-AP message encapsulated in SCTP/IP or F1-C related (SCTP/)IP packet between IAB-MT and MN [10], and the F1-AP message encapsulated in SCTP/IP or F1-C related (SCTP/)IP packet is transferred as a container via X2-AP between MN and SN, see TS 36.423[ Evolved Universal Terrestrial Radio Access Network (E-UTRAN); X2 Application Protocol (X2AP) ]  [9]. 7.12 F1-C transfer in NR-DC In NR-DC, the F1-AP message encapsulated in SCTP/IP or F1-C related (SCTP/)IP packet can be transferred via BAP sublayer or via SRB between the IAB-node and F1-terminating IAB-donor (as specified in TS 38.401[ NG-RAN; Architecture description ]  [7]), as specified in TS 38.331[ NR; Radio Resource Control (RRC); Protocol specification ]  [4]. When both MCG and SCG are configured to transfer the F1-AP message encapsulated in SCTP/IP or F1-C related (SCTP/)IP packet, it is up to the IAB-node implementation for path selection. Two scenarios are supported, as shown in Figure 7.12-1. Figure 7.12-1: F1-C transfer in NR-DC; a) Scenario 1; b) Scenario 2 Scenario 1: IAB-node exchanges F1-AP message encapsulated in SCTP/IP or F1-C related (SCTP/)IP packet with the SN (F1-terminating IAB-donor as specified in TS 38.401[ NG-RAN; Architecture description ]  [7]) using NR access link via MN (non-F1-terminating IAB-donor), and exchanges F1-U traffic using backhaul link(s) with SN. SRB2 is used for transporting the F1-AP message encapsulated in SCTP/IP or F1-C related (SCTP/)IP packet between IAB-MT and MN (see TS 38.331[ NR; Radio Resource Control (RRC); Protocol specification ]  [4]), and the F1-AP message encapsulated in SCTP/IP or F1-C related (SCTP/)IP packet is transferred in a container via XnAP between MN and SN, see TS 38.423[ NG-RAN; Xn Application Protocol (XnAP) ]  [5]. Scenario 2: IAB-node exchanges F1-AP message encapsulated in SCTP/IP or F1-C related (SCTP/)IP packet with the MN (F1-terminating IAB-donor) using NR access link via SN (non-F1-terminating IAB-donor), and exchanges F1-U traffic using backhaul link(s) with MN. Split SRB2 is used for transporting the F1-AP message encapsulated in SCTP/IP or F1-C related (SCTP/)IP packet between IAB-MT and SN (see TS 38.331[ NR; Radio Resource Control (RRC); Protocol specification ]  [4]), and the F1-AP message encapsulated in SCTP/IP or F1-C related (SCTP/)IP packet is transferred in a container via XnAP between SN and MN, see TS 38.423[ NG-RAN; Xn Application Protocol (XnAP) ]  [5]. The F1-AP message encapsulated in SCTP/IP or the F1-C related (SCTP/)IP packet can be transferred either over BAP sublayer or over SRB, but the two mechanisms cannot be supported simultaneously on the same parent link. The F1-AP message encapsulated in SCTP/IP or the F1-C related (SCTP/)IP packet is transferred over BAP sublayer, if the BH RLC channel used for transferring the F1-C traffic is configured on the cell group indicated for F1-C traffic transfer according to TS 38.331[ NR; Radio Resource Control (RRC); Protocol specification ]  [4]. 7.13 Activation and Deactivation of SCG To enable reasonable UE battery consumption while having fast usage of SCG when (NG)EN-DC or NR-DC is configured, an activation/deactivation mechanism of SCG is supported. While the SCG is deactivated, there is no transmission via SCG RLC bearers. Only the NR SCG can be deactivated, and all SCG SCell(s) are in deactivated state while the SCG is deactivated. Upon SCG deactivation and while the SCG is deactivated, the network ensures that there is no uplink control PDU transmission to the deactivated SCG (e.g. the network releases statusReportRequired from PDCP entities of SCG bearers if configured, the network does not perform QoS flow remapping from a DRB associated to the deactivated SCG to another DRB). The network ensures the SCG is activated while PDCP duplication is activated for SCG RLC entities associated with a PDCP entity. NOTE: Upon SCG (de)activation, it is up to the network to ensure there is no pending SDUs or PDUs in SCG RLC entity (e.g. instructs the UE to perform PDCP data recovery and RLC re-establishment/release, if needed). While the SCG is deactivated, the UE will not transmit PUSCH, SRS and CSI report on SCG, and the UE is not required to monitor PDCCH or receive DL-SCH on SCG. If configured by the network, the UE performs radio link monitoring on the SCG and beam failure detection on the SCG while SCG is deactivated. In case of SCG activation without performing random access, the network can indicate TCI states to UE for PDCCH/PDSCH reception on PSCell, if not provided, the UE uses the previously activated TCI states. The MN can configure the SCG as activated or deactivated upon e.g. PSCell addition, PSCell change, RRC Resume or handover. In case the SCG is configured as deactivated, the UE does not perform random access towards the PSCell. The network can trigger SCG RRC reconfiguration (e.g. PSCell change, configuration update) when deactivating the SCG and while the SCG is in deactivated state. SCG activation can be requested by the MN, by the SN and by the UE. SCG deactivation can be requested by the MN and by the SN. For UL data arrival on SCG bearer(s) while the SCG is deactivated, the UE indicates to the MN that it has UL data to transmit over SCG bearer. During handover procedure, the target MN can indicate the SCG state in the RRC reconfiguration message sent to the UE by the source MN. Network can configure whether the UE is allowed to indicate a preference for SCG deactivation to the MN.