In EN-DC, the E-UTRAN QoS framework defined in TS 36.300 applies:

• An S1-U bearer is established between the EPC and the SN for SN terminated bearers;
• An X2-U bearer is established between the MN and the SN for split bearers, MN terminated SCG bearers and SN terminated MCG bearers;
• MN terminated and SN terminated bearers may have either MCG or SCG radio resources or both, MCG and SCG radio resources, established;

In MR-DC with 5GC:

• The NG-RAN QoS framework defined in TS 38.300 applies;
• QoS flows belonging to the same PDU session may be mapped to different bearer types (see clause 4.2.2) and as a result there may be two different SDAP entities for the same PDU session: one at the MN and another one at the SN, in which case the MN decides which QoS flows are assigned to the SDAP entity in the SN. If the SN decides that its SDAP entity cannot host a given QoS flow any longer, the SN informs the MN and the MN cannot reject the request. If the MN decides that its SDAP entity can host a given QoS flow which has already been relocated to SN, the MN informs the SN;
• The MN or SN node that hosts the SDAP entity for a given QoS flow decides how to map the QoS flow to DRBs;
• If the SDAP entity for a given QoS flow is hosted by the MN and the MN decides that SCG resources are to be configured it provides to the SN
  • DRB QoS flow level QoS parameters, which the SN may reject, and
  • QoS flow to DRB mapping information and the respective per QoS flow information;
• If the SDAP entity for a given QoS flow is hosted by the SN and the SN configures MCG resources, based on offered MCG resource information from the MN, the SN provides to the MN
  • DRB QoS flow level QoS parameters, which the MN may reject, and
  • QoS flow to DRB mapping information and the respective per QoS flow information.
• If the SDAP entity for a given QoS flow is hosted by the SN, the MN provides sufficient QoS related information to enable the SN to configure appropriate SCG resources and to request the configuration of appropriate MCG resources. The MN may offer MCG resources to the SN and may indicate for GBR QoS flows the amount offered to the SN on a per QoS flow level. Otherwise, the SN can only use SCG resources for the concerned QoS flow. The SN may request the MN to release QoS flows from the SDAP entity hosted by the SN that the MN cannot reject. The MN may also offer MCG resources per PDU Session for all DRBs to which non-GBR QoS flows contained in the PDU Session are mapped.
• MN decides the DL PDU session AMBR and UL PDU session AMBR limits to be assigned to the SN, and indicates these to the SN:
  • The PDCP entity at the SN applies the received DL PDU session AMBR limi t to the set of all bearers for which the SN hosts PDCP for the UE;
  • The MAC entity at the SN applies the received UL PDU session AMBR limit to the scheduled uplink radio traffic at the SN for the UE.
• The MN can decide to reallocate one or more QoS flows from the MN to the SN. In such case, the SN decides which DRBs the offloaded QoS flows are mapped to. It is possible to avoid/ minimise loss and ensure in-order delivery when reallocating all QoS flows mapped to a given DRB in the MN by keeping the QoS flows mapped to the same DRB in the SN. To achieve this, the SN should behave similar to what is specified for the target NG-RAN node upon handover, see clause 9.2.3.2.2 of TS 38.300. The corresponding behaviour applies when QoS flows are re-allocated from the SN to the MN.
• The MN decides the DL UE Slice MBR and UL UE Slice MBR limits to be assigned to the SN, and indicates these to the SN:
  • The PDCP entity at the SN applies the received DL UE Slice MBR limit to the set of all bearers for which the SN hosts PDCP for the concerned Slice, as defined in TS 23.501;
  • The MAC entity at the SN applies the received UL UE Slice MBR limit to the scheduled uplink radio traffic at the SN for the concerned Slice, as defined in TS 23.501.

In all MR-DC cases:

• The MN decides the DL UE AMBR and UL UE AMBR limits to be assigned to the SN, and indicates these to the SN:
  • The PDCP entity at the SN applies the received DL UE AMBR limit to the set of all bearers for which the SN hosts PDCP for the UE;
  • The MAC entity at the SN applies the received UL UE AMBR limit to the scheduled uplink radio traffic at the SN for the UE.

To support PDU sessions mapped to different bearer types, MR-DC with 5GC provides the possibility for the MN to request the 5GC:

• For some PDU sessions of a UE: Direct the User Plane traffic of the whole PDU session either to the MN or to the SN. In that case, there is a single NG-U tunnel termination at the NG-RAN for such PDU session.
  • The MN may request to change this assignment during the life time of the PDU session.
• For some other PDU sessions of a UE: Direct the User Plane traffic of a subset of the QoS flows of the PDU session to the SN (respectively MN) while the rest of the QoS flows of the PDU session is directed to the MN (respectively SN). In that case, there are two NG-U tunnel terminations at the NG-RAN for such PDU session.
  • The MN may request to change this assignment during the life time of the PDU session.

To support notification control indication for GBR QoS flows along the QoS framework specified in 38.300 [3] for MR-DC with 5GC, SN and MN may mutually indicate whenever QoS requirements for GBR QoS flows cannot be fulfilled anymore or can be fulfilled again. When indicating that GBR QoS flows cannot be fulfilled anymore, SN or MN may additionally indicate the reference to the QoS Parameter Set which it can currently fulfil.

In EN-DC, for each radio bearer the MN decides the location of the PDCP entity and in which cell group(s) radio resources are to be configured. Once an SN terminated split bearer is established, e.g. by means of the Secondary Node Addition procedure or MN initiated Secondary Node Modification procedure, the SN may remove SCG resources for the respective E-RAB, as long as the QoS for the respective E-RAB is guaranteed. In case an SN terminated bearer is released or reconfigured to an MN terminated bearer, only the MN generates the corresponding configuration and the SN does not generate the release configuration. In MR-DC with 5GC, the following principles apply:

• The MN decides per PDU session the location of the SDAP entity, i.e. whether it shall be hosted by the MN or the SN or by both (split PDU session);
• If the MN decides to host an SDAP entity it may decide some of the related QoS flows to be realized as MCG bearer, some as SCG bearer, and others to be realized as split bearer;
• If the MN decides that an SDAP entity shall be hosted in the SN, some of the related QoS flows may be realized as SCG bearer, some as MCG bearer, while others may be realized as split bearer. In this case, the SN decides how to realise the QoS flow, but if the MN does not offer MCG resources, the SN can only realize the QoS flow as SCG bearer. The SN may remove or add SCG resources for the respective QoS flows, as long as the QoS for the respective QoS flow is guaranteed
• If the MN decides that an SDAP entity shall be hosted in the SN, coordination of DRB IDs between the MN and the SN is needed to ensure unique allocation of DRBs for a UE. The SN is responsible to assign the DRB IDs for the DRBs it terminates, based on the DRB IDs indicated by the MN.
• For each PDU session, including split PDU sessions, at most one default DRB may be configured (see [3]). The MN decides whether the SN is allowed to setup the default DRB or not;
• In case an SN terminated bearer is released or reconfigured to an MN terminated bearer, the MN generates the corresponding configuration and the SN does not generate the release configuration. The only exceptional case where SN generates the release configuration is for the DRB release due to QoS flow to DRB remapping within SN.

In MR-DC, all the possible bearer type change options are supported:

• MCG bearer to/from split bearer;
• MCG bearer to/from SCG bearer;
• SCG bearer to/from split bearer.

Bearer termination point change is supported for all bearer types, and can be performed with or without bearer type change:

• MN terminated bearer to/from SN terminated bearer.

For MR-DC:

• when the security key is changed for a bearer due to a termination point change, the associated PDCP and RLC entities are re-established, while MAC behavior might depend on the solution selected by the network, e.g. MAC reset, change of LCID, etc. (see Annex A);
• for MCG bearer, split bearer and SCG bearer, during MN security key change the MCG/SCG PDCP and RLC are re-established and MCG/SCG MAC is reset;
• if a bearer type change happens together with MN security key change then for MCG bearer, split bearer and SCG bearer, the MCG/SCG PDCP and RLC are re-established and MCG/SCG MAC is reset;
• if a bearer type change happens through SN change procedure, then SN terminated PDCP and SCG RLC are re-established and SCG MAC is reset. MCG RLC/MAC behavior depends on the solution selected by the network, see Annex A;
• one step (direct) bearer type change between MN terminated bearer types without using the handover procedure is supported;
• one step (direct) bearer type change between SN terminated bearer types without using the handover or SN change procedure is supported;
• one step (direct) bearer type change from/to MN terminated bearer to/from SN terminated bearer without using the handover procedure is supported;
• PDCP SN length change for an AM DRB or RLC mode change for DRB is performed using a release and add of the DRBs (in a single message) or full configuration;
• One step (direct) bearer type change with PDCP version change (only applicable for EN-DC) is supported.

For MR-DC with 5GC:

• in a bearer termination point change of a DRB from a source NG-RAN node to a target NG-RAN node, for each DRB for which the source NG-RAN node provides QoS flow to DRB mapping information to the target NG-RAN node, the source NG-RAN node also offers the indicated DRB ID for usage at the target NG-RAN node. The target NG-RAN node informs the source NG-RAN node if it accepts the DRB offloading and takes the DRB ID into use.

Upon EN-DC specific activities, user data forwarding may be performed for E-RABs for which the bearer type change from/to MN terminated bearer to/from SN terminated bearer is performed. The behaviour of the node from which data is forwarded is the same as specified for the "source eNB" for handover, the behaviour of the node to which data is forwarded is the same as specified for the "target eNB" for handover. For MR-DC with 5GC, user data forwarding may be performed between NG-RAN nodes whenever the logical node hosting the PDCP entity changes. The behaviour of the node from which data is forwarded is the same as specified for the "source NG-RAN node" for handover, the behaviour of the node to which data is forwarded is the same as specified for the "target NG-RAN node" for handover. For SN change involving full configuration, the source SN behaviour is the same as the description as specified in intra-system data forwarding in TS 36.300 for the source eNB or TS 38.300 for the source NG-RAN node, respectively. In case that a DRB DL forwarding tunnel was established, the target SN may identify the PDCP SDUs for which delivery was attempted by the source SN, by the presence of the PDCP SN in the forwarded GTP-U packet and may discard them. For mobility scenarios which involve more than two RAN nodes, either direct or indirect data forwarding may be applied. Two transport layer addresses of different versions may be provided to enable that the source RAN node can select either IPv4 or IPv6. Direct data forwarding from source SN to target NG-RAN node and from source NG-RAN node to target SN for mobility scenario is supported. Direct data forwarding from source SN to target SN for SN change scenario is also supported. In case of NR-DC to NR-DC handover, direct data forwarding from source SN to target MN, from source SN to target SN and from source MN to target SN is supported. Direct data forwarding for inter-system handover is specified in TS 38.300. If a gNB and an en-gNB are involved in direct data forwarding and realised within the same network entity, inter-system handover to and from EN-DC allows direct data forwarding being performed in a node-internal way, in which case the source RAN node provides a UE context reference to the target side as described in clause 10.16. If the gNB and en-gNB are not realised within the same network entity, direct data forwarding for inter-system handover to and from en-gNB/gNB could be supported if there is direct connectivity between the two nodes. For MR-DC with 5GC, offloading of QoS flows within one PDU session may be performed between NG-RAN nodes. The handling of End Marker packets in case of NG-RAN initiated PDU session split is described in clause 10.14.3 and 10.14.4.