Content for TS 23.501 Word version: 19.4.0

1… 3… 4.2.3 4.2.4 4.2.5… 4.2.8… 4.2.8.2.2 4.2.8.2.3… 4.2.8.4… 4.2.9… 4.2.15… 4.3… 4.3.3 4.3.4 4.3.5 4.4… 4.4.6… 4.4.8… 5… 5.3… 5.3.3… 5.4… 5.5… 5.6… 5.6.7… 5.7… 5.7.2… 5.7.3… 5.7.4 5.7.5… 5.8… 5.8.2.11… 5.9… 5.10… 5.11… 5.15… 5.15.11… 5.16… 5.17… 5.18… 5.19… 5.21… 5.22… 5.27… 5.28… 5.29… 5.30… 5.31… 5.32… 5.32.6… 5.33… 5.34… 5.35… 5.38… 5.43… 5.49… 6… 6.3… 6.3.8… 7… 7.2… 8… 8.2.4 8.2.5… 8.3… A… D… E… F G… G.3 G.4… H… J K… M… N… O… P… S… T…

5.49 Support for Mobile gNB with Wireless Access Backhauling (MWAB) 5.49.1 General 5.49.2 Configuration of the MWAB 5.49.2.1 Configuration of the MWAB-UE 5.49.2.2 Configuration of the MWAB-gNB 5.49.3 Authorization aspects 5.49.4 Support of Additional ULI 5.49.5 Mobility support of MWAB 5.49.5.1 UE mobility when a MWAB-gNB cell is involved 5.49.5.2 UE mobility when the UE is moving together with a MWAB cell 5.49.5.3 Impact of MWAB mobility 5.49.6 Control of UE access to MWAB 5.49.7 Location Service Support of UEs served by MWAB 5.49.8 Support of regulatory service via MWAB 5.50 Support for NR Femto 5.50.1 Overview 5.50.2 5GS architecture to support NR Femto 5.50.3 CAG Information Provisioning 5.51 Support of Energy Efficiency and Energy Saving 5.52 QoS differentiation of traffic for Non-3GPP Device Identifier
...

5.49 Support for Mobile gNB with Wireless Access Backhauling (MWAB) |R19| p. 554

5.49.1 General p. 554

5.49.1.1 Principles and functional entities p. 554

Mobile gNB with Wireless Access Backhauling (MWAB) provides an NR access link to UEs in proximity and connects to the 5GC serving the UE through an IP connectivity provided by a Backhaul PDU session(s), as illustrated in Figure 5.49.1.1-1. The MWAB consists of a gNB component (MWAB-gNB) and a UE component (MWAB-UE). The MWAB-gNB is based on the gNB functionality specified in TS 38.300 and TS 38.401. The MWAB may be mounted on a moving vehicle and may serve UEs inside or outside the vehicle.

The MWAB-UE establishes the IP connectivity for the backhaul links for the MWAB-gNB, via NR Uu, using the existing registration procedure and PDU session establishment procedure. The backhaul links are between the MWAB-gNB and entities of the network (e.g. AMF, UPF, other gNBs and OAM server) that a MWAB-gNB cell serves. The IP connectivity provided by the MWAB-UE may be either via the same PLMN/SNPN that the MWAB-gNB serves or a different PLMN/SNPN, depending on the MWAB-UE PLMN selection mechanism as specified in TS 23.122. Different possible deployment scenarios are presented in Annex S.

MWAB operation supports both PLMN and SNPN cases. When the MWAB-gNB is serving a PLMN, the UEs served by MWAB may be non-roaming or roaming in the MWAB Broadcasted PLMN. In case the MWAB-gNB is serving a SNPN, the subscribed SNPN of the UEs may be different from the MWAB Announced SNPN. The UEs served by the MWAB are not aware of the network serving the MWAB-UE.

Reproduction of 3GPP TS 23.501, Fig. 5.49.1.1-1: MWAB architecture for 5GS

Figure 5.49.1.1-1: MWAB architecture for 5GS

MWAB-UE has a single NR Uu hop to the BH NG-RAN, using either TN or NTN access technology. The NR Uu access link between the MWAB-gNB and the served UE(s) does not use NTN access technology. 5G MOCN can be supported by the MWAB-gNB.

The details of the MWAB configuration/provisioning process are described in clause 5.49.2.

In order to operate as MWAB, the MWAB-gNB component and MWAB-UE component are authorized and controlled separately. The detailed procedures for the authorization of MWAB are described in clause 5.49.3.

When UE(s) are served by MWAB, the MWAB-gNB provides Additional User Location Information to the 5GC as described in clause 5.49.4.

Service continuity for the UE(s) served by the MWAB-gNB is supported when the MWAB moves. The UE(s) move or do not move together with the MWAB. The detailed procedures for the support of mobility are described in clause 5.49.5.

The MWAB shall be able to serve UE(s) without any MWAB-specific enhancements. For some operations, the MWAB may be configured to provide access only to certain UEs. Existing access control mechanisms, e.g. CAG control, can be used to manage the UE(s)'s access to the MWAB-gNB. The details of the access control for the UEs served by MWAB are described in clause 5.49.6.

The LCS framework as defined in TS 23.273 is used for providing the location service to the UE(s) served by MWAB. When the AMF determines the UE is served by a MWAB cell based on e.g. the Additional ULI, the AMF selects the LMF that can support the MWAB handling and sends MWAB indication and Additional ULI (if available) to the LMF as defined in clause 8.3.2.2 of TS 23.273. Details on supporting the LCS over MWAB are described in clause 5.49.7.

Regulatory services (e.g. emergency services, priority services) can be supported by the MWAB and the details are provided in clause 5.49.8.

Details on MWAB-gNB's Xn connection are specified in TS 38.401.

The support of PWS functionality with MWAB is described in TS 23.041.

5.49.1.2 Backhaul PDU Session handling for MWAB p. 555

The use of multiple BH PDU Sessions for MWAB-gNB N2, N3, Xn interfaces and OAM access is based on configuration from OAM of the MWAB Broadcasted PLMN/SNPN.

The MWAB-gNB requests BH PDU Session(s) from the MWAB-UE by providing corresponding traffic descriptors specified in TS 23.503 and TS 24.526, via the implementation based internal communication between the MWAB-gNB and the MWAB-UE.

The MWAB-UE establishes, modifies BH PDU Sessions based on the received traffic descriptors from MWAB-gNB, configured URSP rules, and local configuration.

5.49.1.3 Support of QoS for UEs served by a MWAB p. 555

The MWAB-UE considers the traffic from the MWAB-gNB as application layer traffic and applies the related QoS handling as specified in clause 5.7 for BH PDU Session(s). The MWAB-UE may establish and modify the BH PDU Sessions based on necessary information provided by MWAB-gNB (e.g. according to the QoS requirements identified by the MWAB-gNB based on the QoS information of the PDU Session(s) in the UE contexts of the MWAB-gNB and/or based on OAM configuration) via implementation-based internal communication between MWAB-gNB and MWAB-UE.

Based on configuration and traffic mapping specified in TS 38.414 and clause 5.7.1.5, the MWAB-gNB (in the Uplink direction) and the UPFs (in the Downlink direction) in the MWAB Broadcasted PLMN/SNPN set proper marking information (DSCP) for the N3 GTP-U traffic for the UE(s) served by the MWAB-gNB. When Xn is supported for MWAB, based on TS 38.401, the MWAB-gNB and its neighbour NG-RAN node set proper DSCP for the Xn-U traffic based on OAM configurations, as defined in TS 38.424. The MWAB gNB additionally marks the DSCP value based on configuration for N2, Xn-C and OAM traffic it sources, i.e. not related to PDU Sessions(s) of the UE.

The MWAB-gNB provides the information to the MWAB-UE for the mapping of DSCP values used for N3 traffic and Xn traffic in the MWAB Broadcasted PLMN/SNPN to QoS flows to be used in the BH PLMN/SNPN (including the required Packet Filter Set for filtering of packets) and the corresponding QoS requirements (e.g. QoS Flow level parameters including e.g. 5QI). The MWAB-UE then initiates PDU session establishment or modification procedure to establish or update the BH PDU session(s) for N3 traffic and Xn traffic delivery based on the received information.

Based on the information provided by the MWAB-gNB and received during the PDU session establishment/modification, the MWAB-UE processes the UL N3 traffic and Xn traffic as described in clause 5.7.1.7. The BH UPF processes the DL N3 traffic and Xn traffic as described in clause 5.7.1.6.

The MWAB-UE may indicate to the MWAB-gNB the current BH PDU Session's QoS Flow level QoS parameters, e.g. for admission control of the QoS-Flows of the UEs served by the MWAB.

5.49.1.4 Support of network slicing for UEs served by a MWAB p. 556

A MWAB-gNB can be configured to associate S-NSSAI(s) in the MWAB-Broadcasted PLMN/SNPN to the traffic descriptor for selection of the BH PDU Sessions parameters e.g. use dedicated S-NSSAI in BH PLMN. If no such association exists for a specific S-NSSAIs of the MWAB Broadcasted PLMN/SNPN, the MWAB-gNB associates this S-NSSAI to default traffic descriptors for the selection of BH PDU Session(s) for the related N2 and/or N3 backhauling. The MWAB-gNB requests the BH PDU sessions as specified in clause 5.49.1.2.

When the MWAB-gNB obtains the S-NSSAI of a UE PDU Sessions from the UE PDU session context during PDU session establishment, it checks whether a configured association exists for the S-NSSAI of the PDU session of the UE and, if so, it uses the related BH PDU session for the UE's PDU Session.

If a new BH PDU Session needs to be established for supporting a UE's traffic for a S-NSSAI in the MWAB-Broadcasted PLMN/SNPN, after the completion of the PDU session establishment procedure, the MWAB-UE may trigger a PDU session resource modification procedure to shift the N3 traffic for the UE to the new BH PDU sessions.

5.49.2 Configuration of the MWAB p. 556

5.49.2.1 Configuration of the MWAB-UE p. 556

The MWAB-UE manages the BH PDU Session(s) for the MWAB operation based on the configuration by the HPLMN or Subscribed SNPN of the MWAB-UE. The configuration of the MWAB-UE can be UE Local Configuration, or URSP rules as defined in TS 23.503, for the determination of the proper PDU session parameters, e.g. the DNN, S-NSSAI, the SSC Mode, etc. The URSP rules can be preconfigured or provisioned to the MWAB-UE by its HPLMN using UE Policy delivery as described in clause 4.2.4.3 of TS 23.502.

5.49.2.2 Configuration of the MWAB-gNB p. 556

The MWAB-gNB's configuration is managed by the OAM of the MWAB Broadcasted PLMN/SNPN and the address (or FQDN) of the OAM server per MWAB Broadcasted PLMN/SNPN may be configured at the MWAB-gNB. The OAM server of the MWAB Broadcasted PLMN/SNPN provides (re-)configuration parameters considering location of MWAB as specified in TS 38.401, e.g. for the purpose including the access stratum operation of the MWAB-gNB, the N2, N3 and Xn interface management, activating/deactivating the MWAB-gNB operation and to assist the MWAB-gNB providing traffic descriptor information (see clause 5.49.1.2) used by MWAB-UE for the BH PDU Session(s) management via URSP processing.

The MWAB-gNB shall be configured with the supported S-NSSAI(s) in the MWAB Broadcasted PLMN/SNPN.

5.49.3 Authorization aspects p. 557

5.49.3.1 General p. 557

There are two aspects related to the authorization of an MWAB. One aspect is the authorization of the MWAB-UE to establish a BH PDU Session. The other aspect is related to the authorization of the MWAB-gNB to operate as a gNB logically belonging to a MWAB Broadcasted PLMN/SNPN which the MWAB-gNB announces in the SIB.

5.49.3.2 MWAB-UE authorization p. 557

The MWAB-UE is authorized based on its subscription information which includes dedicated S-NSSAI(s) and DNN for MWAB operation. Such dedicated S-NSSAI(s) and DNN(s) shall be part of the subscription information for the MWAB-UE as specified in clause 5.2.3.3.1 of TS 23.502.

The authorization of the MWAB-UE to establish connectivity in a BH PLMN/SNPN is based on whether dedicated S-NSSAI(s) for MWAB operations are received as part of Allowed NSSAI in BH PLMN/SNPN following existing procedures as described in clause 5.15 and whether it can establish BH PDU session(s) in the BH PLMN/SNPN using the dedicated S-NSSAI(s) and DNN(s).

The MWAB-UE authorization supports time-based or location-based control.

For time-based control, existing time-based network slice subscription control can be reused (including the enhancements in clause 5.15.16).
For location-based control, existing mechanism, e.g. service area restriction, LADN based control (see e.g. clauses 5.6.5 and 5.6.5a) can be reused.

The MWAB-UE may be connected to the BH PLMN/SNPN for other services, if allowed by the subscription data, even if the S-NSSAIs and DNNs for Backhaul PDU sessions are no longer authorized.

5.49.3.3 MWAB-gNB authorization p. 557

The authorization of the MWAB-gNB is managed by the OAM system of the MWAB-Broadcasted PLMN/SNPN as specified in TS 38.401. The MWAB-gNB establishes a secure and trusted connection to the OAM server using the IP connectivity provided by the MWAB-UE via the Backhaul PDU Session(s) as specified in clause 5.49.1.

The OAM of the MWAB Broadcasted PLMN/SNPN determines when/where the MWAB-gNB can operate or when/where it needs to shut down. The OAM of the MWAB Broadcasted PLMN/SNPN may pre-configure the MWAB-gNB to turn on/shut down the operations of respective MWAB Broadcasted PLMN/SNPN part. When the MWAB-gNB is no longer authorized to operate by OAM of the MWAB Broadcasted PLMN/SNPN, the MWAB-gNB should handover the UE(s) of the MWAB Broadcasted PLMN/SNPN to other cells.

When the MWAB-gNB stops operating under OAM control, the MWAB-gNB may trigger the MWAB-UE to release the BH PDU sessions.

5.49.4 Support of Additional ULI p. 558

The TAC and cell ID broadcasted by the MWAB-gNB are configured and reconfigured e.g. upon MWAB mobility as specified in TS 38.401. The MWAB-gNB provides these in the User Location Information (ULI) to the AMF serving the UE's accessing MWAB-gNB.

When a UE is served by a cell of MWAB-gNB, the MWAB-gNB shall also provide the Additional User Location Information (Additional ULI) that reflects the location of the MWAB-UE to the AMF when it sends the User Location Information (ULI) over N2 messages. In the Additional ULI, the MWAB-gNB provides the TAI/NR CGI of the MWAB Broadcasted PLMN/SNPN with which the UE is registered as specified in TS 38.401.

If serving cell change report is required by AMF as specified in clause 4.10 of TS 23.502, the MWAB-gNB shall report Additional ULI (and ULI) for the UE even when only serving cell of the MWAB-UE changes.

The AMF may consider the 'Additional ULI' when it determines UE location and manages the UE location related functions (e.g. Mobility Restrictions).

Based on operator policy, the AMF may send the Additional ULI when the AMF provides user location information it has received over the N2 interface to a NF (e.g. the LMF as specified in clause 5.19.1 of TS 23.273).

The MWAB-gNB indicates the Additional ULI to AMF(s) it connects to by NG Setup and RAN Configuration Update procedures as specified in TS 38.401.

5.49.5 Mobility support of MWAB p. 558

5.49.5.1 UE mobility when a MWAB-gNB cell is involved p. 558

No MWAB-specific enhancements impacting the UE are defined to handle a UE mobility to and from a MWAB-gNB while the UE is in RRC_IDLE, RRC_INACTIVE or RRC_CONNECTED modes, irrespective of whether the MWAB is static or the MWAB is moving, i.e.:

For UEs in RRC_IDLE and RRC_INACTIVE state, procedure for cell (re) selection as specified in TS 38.304 and TS 23.122 for RRC_IDLE and RRC_INACTIVE is used irrespective of cells are belonging to a MWAB-gNB or a gNB.
For UEs in RRC_CONNECTED state, the MWAB-gNB or gNB triggers the handover procedures to the neighbouring cells as specified in TS 38.300 and TS 23.502 irrespective of whether the cells are belonging to a MWAB-gNB or a gNB.

5.49.5.2 UE mobility when the UE is moving together with a MWAB cell p. 559

For a UE served by an MWAB-gNB cell, the MWAB-gNB may trigger the handover procedures for UEs in RRC_CONNECTED mode as specified in TS 38.401. For UEs in RRC_IDLE and RRC_INACTIVE state, the existing NAS mobility procedures and Connection Resume procedure are used as specified in TS 23.502.

5.49.5.3 Impact of MWAB mobility p. 559

The mobility of MWAB includes the MWAB-UE and the MWAB-gNB aspect.

The mobility of the MWAB-UE reuses the exiting UE mobility procedures specified for normal UE, subject to constraints specified in TS 38.401..
During mobility, a MWAB-gNB can obtain or apply a new configuration as specified in TS 38.401 from the OAM server of MWAB Broadcasted PLMN/SNPN and, if any new AMF was provided as part of the new configuration, the MWAB-gNB (i.e. new logical gNB as specified in TS 38.401) sets up the N2 connection with the new AMF and it (i.e. old logical gNB as specified in TS 38.401) releases the N2 connection with any old AMF removed from the MWAB-gNB configuration.

NOTE:
It is expected the MWAB-gNB removes the old configuration after the MWAB-gNB has completed the handover of the UEs in RRC_CONNECTED state.
The MWAB-UE may request new or modify existing BH PDU Sessions for the corresponding N2, N3 and Xn interfaces, upon request from the MWAB-gNB as it moves in the network and the MWAB-gNB updates the TNL association as specified in clause 5.21.1 and TS 38.401 to use the new TNL information associated with the new BH PDU Session(s) as needed.
SSC mode 3 may be applied to the BH PDU Sessions to minimize traffic interruption when UPF re-allocation for these BH PDU Sessions is required during the MWAB mobility.
When it is required to change AMF for the UEs served by the MWAB-gNB upon mobility of a MWAB into a new region, the TAC(s) and Cell ID(s) the MWAB-gNB announces also change. The MWAB-gNB, for UEs in RRC_CONNECTED mode, behaves as specified in TS 38.401.
To prevent handover of a MWAB-UE towards a target MWAB-gNB, the target MWAB-gNB (i.e. during Xn handover or during N2 HO after target AMF slice control as described in step 4 in clause 4.9.1.3.2 of TS 23.502) fails the handover as specified in TS 38.401 because the dedicated slices for BH PDU sessions of the MWAB-UE are not supported by the target MWAB-gNB.

5.49.6 Control of UE access to MWAB p. 559

5.49.6.1 General p. 559

Control of UE access to MWAB is supported. If the MWAB-gNB is serving a PNI-NPN, the CAG mechanism described in clause 5.49.6.2 is used. If the MWAB-gNB is serving an SNPN, the SNPN control mechanism described in clause 5.49.6.3 is used.

The MWAB-gNB and the 5GC can reuse other existing mechanisms e.g. forbidden Tracking Area, UAC, to manage the UE's access to an MWAB-gNB cell.

5.49.6.2 Control of UE access to an MWAB serving PNI-NPN p. 559

According to operator's policy, access control may be applied to UE access to MWAB-gNB cell supporting a PNI-NPN.

If the MWAB-gNB is serving a PNI-NPN, the CAG mechanism defined in clause 5.30.3 can be used for managing UE's access to the MWAB-gNB cell, with the following additional considerations:

The MWAB-gNB is configured either during the communication with the OAM of MWAB-gNB or (pre-)configuration mechanism, with one or more CAG identifiers which are unique within the scope of this PLMN.
If the MWAB-gNB is (pre-)configured with the PLMN list supporting PNI-NPN, the corresponding CAG Identifiers per PLMN is also configured in the MWAB.
The MWAB-gNB performs UE access control based on the CAG identifier associated with the MWAB-gNB cell, as defined in clause 5.30.3.4. The MWAB-gNB takes the role of the NG-RAN.

NOTE:
In the case of UE not supporting CAG functionality, the MWAB-gNB and 5GC of MWAB Broadcasted PLMN can use other existing mechanisms e.g. forbidden Tracking Area, to manage UE's access to a MWAB-gNB cell.
Time validity information may be provided to the UE together with the CAG Identifier(s) of the MWAB-gNB(s) that the UE can access. If the evaluation of the time validity information of an entry in the Allowed CAG list changes, the updated Allowed CAG list will be provided to UE and MWAB-gNB by the AMF for enforcement, to make sure that UE not accessing the corresponding MWAB-gNB cell outside of the time duration.

Dedicated CAG ID(s) can be used for the control of UE access to a PNI-NPN via MWAB cells.

5.49.6.3 Control of UE access to an MWAB broadcasted SNPN p. 560

If the MWAB-gNB is serving an SNPN, as illustrated in Annex S, clause S.3, the existing SNPN control mechanism defined in clause 5.30.2.5 can be used to manage the UE's access to MWAB-gNB.

Dedicated SNPN ID(s) or GIN(s) can be used if differentiation is desired in control of UE access to the SNPN via MWAB-gNB or other fixed gNBs.

5.49.7 Location Service Support of UEs served by MWAB p. 560

Location Service involving MWAB is described in clause 5.19 of TS 23.273.

5.49.8 Support of regulatory service via MWAB p. 560

Based on the OAM configurations, an MWAB may support emergency services for UEs connected to the MWAB-gNB.

When the MWAB determines that a UE which connects to the MWAB-gNB initiates an emergency PDU Session, e.g. via AS layer signalling, or based on the ARP of the PDU Session context, the following handling applies:

If the HPLMN of MWAB-UE has configured it with specific S-NSSAI and DNN for BH PDU Session(s) to serve emergency PDU Session for UEs accessing this MWAB, the MWAB uses a BH PDU Session associated with this specific S-NSSAI and DNN. The MWAB-UE establishes such PDU session if it was not yet established.
- If a new BH PDU sessions using this specific S-NSSAI and DNN is established, the emergency PDU Session establishment procedure for the UE(s) served by the MWAB-gNB should not be interrupted by the establishment of the new BH PDU Session. To avoid interruption of the establishment of the emergency PDU Sessions of the UE(s) served by the MWAB-gNB, the MWAB-gNB should complete the emergency PDU Session establishment by using the existing BH PDU Sessions for N3 traffic and then trigger PDU Session resource modification procedure for the emergency PDU Sessions of the UE(s) to associate the emergency PDU Session N3 interface to the new BH PDU Session to serve emergency PDU Session for UEs accessing this MWAB.
If the HPLMN of MWAB-UE has not configured the MWAB-UE with specific S-NSSAI and DNN for BH PDU Session(s) to serve emergency PDU Session(s) for UEs accessing this MWAB, the MWAB reuses the existing BH PDU Session(s) for N2/N3 interface.
If there are UEs with emergency services, the MWAB-gNB will not stop operating (e.g. due to de-authorization) as MWAB until it handovers the UEs to other cells as described in clause 5.49.3.
Based on configuration for the specific S-NSSAI and DNN for BH PDU Session to serve emergency PDU Sessions, the BH PLMN/SNPN and the MWAB attempt to guarantee the resources of the BH PDU session(s) to serve emergency PDU Session in the BH PLMN/SNPN so that they are not released when MWAB is serving the emergency services.

5.50 Support for NR Femto |R19| p. 561

5.50.1 Overview p. 561

This clause provides an overview of 5GS functionalities and architecture to support NR Femto deployments.

For the support of NR Femto in 5GS, the architecture is described in clause 5.50.2.

For the UE access control to the NR Femto cell, the CAG concept defined in the clause 5.30.3 for PNI-NPN may be used. The Femto cell may broadcast one or multiple CAG Identifiers as specified in the clause 5.30.3 if CAG is used for access control.

The CAG owner or an authorized administrator may control/provision subscribers to allow accessing their NR Femto/CAG cells as described in clause 5.50.3.

An NR Femto Hosting Party plays the role of a CAG owner.

5.50.2 5GS architecture to support NR Femto p. 561

In 5GS, an NR Femto node connects to 5GC directly or via NR Femto Gateway (NR Femto GW) as specified in TS 38.300 (see Annex V).

The NR Femto GW serves as a concentrator for the N2 interface, as described in TS 38.300. The NR Femto GW appears to the AMF as a gNB. The NR Femto GW appears to the NR Femto node(s) as an AMF. The N2 and N3 interface between the NR Femto node(s) and the 5GC is the same, regardless whether the NR Femto node(s) is(are) connected to the 5GC via an NR Femto GW or not.

In a deployment with a locally deployed UPF close to the location of NR Femto node(s), the edge computing functionality specified in clause 5.13 can be applied.

5.50.3 CAG Information Provisioning p. 561

In 5G, a CAG owner or an authorized administrator can control/provision subscribers allowed to access CAG cells via the AF using CAG Information Provisioning as defined in clause 4.15.6.2 and 4.15.6.3h of TS 23.502.

In this Release of the specification, CAG Information Provisioning is only applied for non-roaming case.

5.51 Support of Energy Efficiency and Energy Saving |R19| p. 561

5.51.1 General p. 561

The 5GS supports some features aimed at Energy saving described in the following clauses.

5.51.2 Energy Consumption Information collection, calculation and exposure p. 561

5.51.2.1 General p. 561

The Energy Information Function (EIF) is defined to:

collect the UE related Energy Consumption information;
calculate the Energy Consumption information at UE, S-NSSAI, PDU Session and Service Data Flow (e.g. per UE per application) granularity; and
expose the Energy Consumption information to the authorized consumer NF(s) (AF/NEF).

Procedures for energy consumption information collection and exposure are defined in clause 4.29 of TS 23.502.

In this Release of the specification, collecting and calculating of UE related Energy Consumption information is supported only for the UP resources of the 3GPP access type serving the UE in the 5GS.

5.51.2.2 Energy Consumption information collection p. 562

5.51.2.2.1 General p. 562

The Energy Information Function (EIF) collects the UE related Energy Consumption information including Node-level energy consumption information, Node-level data volume from OAM and data volume of the required granularities (i.e. S-NSSAI, PDU Session and/or Service Data Flow) from UPF (via SMF). The EIF can expose the energy consumption at the requested granularity over a certain time window (i.e. the total energy consumed from a start time to an end time) or periodically (i.e. every reporting period of e.g. 10 minutes).

Node-level energy consumption is collected network-wide at a configurable starting time with interval T such that the Energy Consumption information reported to the EIF is time-aligned.

The reporting period for periodic reporting by the EIF to its consumers can only be a multiple of this time interval T and is time-aligned to the node-level energy consumption reporting occurring at every time interval T configured in the network.

5.51.2.2.2 Energy Consumption information collection from SMF p. 562

The serving SMFs are retrieved by the EIF from the UDM of the UE based on the provided input parameters including the UE ID and optional S-NSSAI or (S-NSSAI, DNN). Also, the EIF subscribes to the UDM to be notified with the applicable SMFs.

The EIF invokes Nsmf_EventExposure_Subscribe as defined in TS 23.502 with the required granularities (UE ID, DNN/S-NSSAI, application information (e.g. Application Identifier, or Packet Filters)) to retrieve the information from SMF, which is shown in Table 5.51.2.2.2-1. The SMF receives the data volume of the required granularities from the PSA UPF. The SMF derives the gNB ID(s) from the AMF provided ULI as described in clause 4.3.2. If the I-SMF is involved in the PDU session, the SMF of PDU session requests I-SMF to report the current I-UPF ID and ULI and subsequent change of these entities.

The SMF then sends the collected data volume, along with the serving gNB ID(s) and (I-)UPF ID(s) to EIF for energy consumption calculation. And the information collected from SMF by EIF, is shown in Table 5.51.2.2.2-2. Upon release of a PDU session, the SMF terminates subscriptions related to the PDU session. The SMF periodically notifies EIF with the information at the end of each time interval T until the EIF unsubscribes as defined in TS 23.503. The SMF shall collect data volume only for the PDU session carried over the 3GPP Access. When the PDU session is over Non-3GPP Access type the SMF reports UL/DL Data volume in the measurement period equal to 0 (zero) and the gNB ID is not provided.

When the SMF receives the Nsmf_EventExposure_Subscribe for a Service Data Flow from the EIF, the SMF generates a URR for the Data Volume counting with a Periodic measurement threshold set according to the Timer interval T and associates the subscription from EIF to the generated URR. The SMF is then associating the generated URR to an appropriate PDR. SMF logic ensures that the PDRs and their precedence values are configured appropriately in the UPF so that both, the URRs for Data Volume counting for EIF and the traffic handling instructions derived from the existing PCC rules can co-exist and the traffic of the Service Data Flow is treated in the same way as before. For example, the SMF may behave as follows:

If there is a PCC rule existing for that Service Data Flow, the SMF associates the generated URR with the PDR of that PCC rule.
If there is no PCC rule for the Service Data Flow, the SMF generates a PDR for the Service Data Flow and associates the generated URR with that PDR. All other instructions of the PDR related to the match-all PCC rule are copied (so that the traffic of the Service Data Flow is treated in the same way as before).
In all other cases, e.g. if the Service Data Flow is partially overlapping with an existing PCC rule (which can only occur when the subscription contains Packet Filters), the SMF may need to generate PDR(s), associate the generated URR with the(se) PDR(s) and copy all other instructions of the PDR related to the existing PCC rule so that both, the Data Volume counting for EIF and the traffic handling instructions derived from the existing PCC rule can be realized.

If the PCC rules are changed, the SMF shall again perform the above checks and actions.

When the SMF receives the Nsmf_EventExposure_Subscribe for the PDU Session from the EIF, the SMF associates the subscription from EIF to the PDU Session, generates a URR for the Data Volume counting (with a Periodic measurement threshold set according to the Timer interval T) and associates it with all PDRs of the PDU Session.

In both cases, the UPF will send the collected data volume information of this URR at the end of each Time interval to the SMF in a Usage Report (see clause 4.4.2.2 of TS 23.502). If there is a change in the user plane path (e.g. handover between gNBs or insertion/removal of I-UPF) during the Time interval, the SMF shall request the collected data volume information of this URR from the UPF. If this happens, the UPF will immediately send the collected data volume information to the SMF in a Usage Report (see clause 4.4.2.2 of TS 23.502) and the SMF shall then store this information together with the gNB ID and I-UPF ID that belong to the user plane path before the change happened.

Table 5.51.2.2.2-1: Information to SMF for user-plane energy consumption calculation

Information	Description
UE ID	SUPI.
S-NSSAI +DNN	Slice and DNN applicable to a PDU session.
IP 5-Tuple	IP-5-tuple.

Table 5.51.2.2.2-2: Information from SMF for user-plane energy consumption calculation

Information	Description
UE IP address	UE IP address.
UE ID	SUPI.
S-NSSAI	Network Slice applicable to a UE.
S-NSSAI +DNN	Slice and DNN applicable to a PDU session.
Packet Filters	Packet Filters as in clause 5.7.6 for IP or Ethernet traffic.
Application Identifier	Identification for the traffic of the service data flow.
List of Data Volume information	The data volume and the associated UPF(s) and gNB(s) serving the UE within the time interval.
> UL/DL Data Volume	The UL/DL Data Volume of a PDU Session identified by (UE-ID, S-NSSAI/DNN) or a Service Data flow (UE ID, S-NSSAI, DNN, Packet Filters/Application Identifier).
> (I-)UPF ID(s)	Identifier of any (I-)UPF(s) associated to a reported data volume used by a PDU Session identified by (UE-ID, S-NSSAI/DNN) or a Service Data flow (UE ID, S-NSSAI, DNN, Packet Filters/Application Identifier).
> gNB ID	Identifier of the gNB serving the UE.
Reference to Time Interval	Indicate the time interval of the collected information (e.g. time stamps).

5.51.2.2.3 Energy Consumption information collection from OAM p. 564

Table 5.51.2.2.3-1 provides the list of information received from OAM. EIF requests the energy consumption and data volume information per NF level from OAM by providing the serving gNB ID(s) and (I-)UPF ID(s) received from SMFs.

The node-level reporting interval from the OAM is the network-wide configurable starting time and interval T which is the same as data volume reporting interval from SMFs.

Table 5.51.2.2.3-1: Information from OAM for user-plane energy consumption calculation

Information	Description
gNB energy consumption	The Energy consumed by a gNB over the configured time interval T based on clause 6.7.3.4.2 of TS 28.554.
gNB data volume	The UL/DL data volume handled by a gNB over the configured time interval T based on clause 6.7.1.1 of TS 28.554.
UPF energy consumption	The Energy consumed by a UPF over the configure time interval T based on clause 6.7.3.1 of TS 28.554.
UPF data volume	Data volume consumed at a UPF.

When the serving gNB and/or the (I-)UPF(s) of the UE are changed, the serving gNB ID and (I-)UPF ID(s) will be updated to the EIF through SMF(s). And then, the EIF requests the energy consumption and data volume information from OAM for the updated serving gNB ID and (I-)UPF ID(s).

The EIF acts as the enforcement point for user consent for collection and processing of energy-related information depending on local regulations. For support of user consent (for collection and processing of energy-related information), the EIF communicates with the UDM as specified in Annex V of TS 33.501.

5.51.2.3 Energy Consumption information calculation p. 564

EIF calculates the Energy Consumption information of the required granularities (UE, S-NSSAI, PDU Session and/or Service Data Flow), based on input parameters from Table 5.51.2.2.2-2 and Table 5.51.2.2.3-1 and gets the results. Some example formulas to support the above calculation are described in Annex T.

5.51.2.4 Energy Consumption information exposure p. 564

AF/NEF subscribes the EIF for Energy consumption information of required granularities (UE, S-NSSAI, PDU session and/or Service Data Flow).

For UE level energy exposure, the consumer NF provides UE ID (SUPI/GPSI).
For S-NSSAI of the UE level exposure, the consumer NF provides UE ID (SUPI/GPSI), S-NSSAI.
For PDU session level exposure, the consumer NF provides UE ID (SUPI/GPSI), DNN/S-NSSAI.
For Service Data Flow level exposure (e.g. per UE per application), the consumer NF provides UE ID (SUPI/GPSI), DNN/S-NSSAI and application information, e.g. Application Identifier, or Flow description(s).

The consumer NF may also subscribe the above information exposure with providing reporting period, or time window. AF/NEF may also subscribe the Energy consumption information exposure of required granularity and may provide reporting threshold for the required granularity and the reporting time period.

5.51.3 Void

5.51.4 BDT based on network energy related information p. 565

5GS supports BDT (background data transfer) policy selection and re-negotiation process by taking energy indicator from AF into consideration as specified in clause 6.1.2.4 of TS 23.503. The PCF may make BDT policy decisions based on operator's policy. The PCF may also trigger the re-negotiation of BDT policy with the AF.

5.51.5 Subscription information aspects p. 565

The Subscription data for a UE may include an Energy Saving Indicator that the UE is subject to network energy saving operation. The values of the Energy Saving Indicator point to energy saving behaviour configured in the NG-RAN and/or AM-PCFs of the network. The possible energy saving behaviours for a network and the mapping of the Energy Saving Indicator values to the respective behaviour are operator-defined and outside the scope of this specification. The AMF receives the Energy Saving indicator in the UE Subscription data. The AMF forwards the Energy Saving indicator to the NG-RAN and to the PCF.

5.51.6 Policy control aspects p. 565

During AM policy association establishment or modification procedures, if the Energy Saving Indicator is included in the UE subscription data, the AMF sends to the PCF the Energy Saving Indicator as described in clause 5.51.5. Based on the Energy Saving Indicator it receives from the AMF for a UE, the PCF may make AM policy decisions for the UE based on the operator policy as described in clause 6.1.2.1.1 of TS 23.503.

5.52 QoS differentiation of traffic for Non-3GPP Device Identifier |R19| p. 565

5.52.1 General p. 565

This clause specifies the scenario of a non-3GPP device connecting through the UE. In this scenario QoS differentiation of traffic is applied to the traffic that originates from or is directed to the non-3GPP device. The non-3GPP device does not use NAS and is not authenticated by 5GC.

The support of identification of traffic for non-3GPP devices connecting behind a 5G-RG is specified in TS 23.316.

The Non-3GPP Device Identifier is unique within the scope of the UE's SUPI.

In this Release of the specification, QoS differentiation for non-3GPP device connecting behind a UE is not supported in LBO roaming scenario.

5.52.2 Traffic identification p. 566

The UE may bind a Non-3GPP Device Identifier to a non-3GPP device, for the traffic of the non-3GPP device that requires differentiated QoS. This binding enables the 5G System to distinguish between the traffic generated by different non-3GPP devices connected through the same UE.

Non-3GPP Device Identifier Information is stored in the UDR and includes a Non-3GPP Device Identifier and QoS information. The content of the Non-3GPP Device Identifier Information is further described in clause 4.15.6.15 of TS 23.502.

5.52.3 Session management enhancement p. 566

For the traffic of non-3GPP devices requiring differentiated QoS, the Non-3GPP Device Connection Information may be signalled by the UE as defined in TS 24.501. When a non-3GPP device is connected to the UE, the UE may include the Non-3GPP Device Connection Information in PDU Session Modification Request to SMF. The Non-3GPP Device Connection Information may include information of more than one non-3GPP device. The SMF forwards the Non-3GPP Device Connection Information to the PCF for policy control.

For an Ethernet PDU Session, the Non-3GPP Device Connection Information includes the following information for each non-3GPP device:

Non-3GPP Device Identifier;
MAC address of the non-3GPP device used in PDU Session;
Optionally, VLAN tag ID that is associated with the non-3GPP device used in PDU Session.
If theVLAN tag ID is present in the Non-3GPP Device Connection Information and if the received VLAN Tag ID from UE is not within the allowed VLAN tags for the UE (described in clause 5.6.10.2) SMF rejects the PDU Session Modification Request.

For an IPv4 or IPv4v6 PDU Session, the Non-3GPP Device Connection Information includes the following information for each non-3GPP device:

Non-3GPP Device Identifier;
IPv4 Address associated with the non-3GPP device used in PDU Session;
Optionally, port range(s) associated with the non-3GPP device used in PDU Session.

For an IPv6 or IPv4v6 PDU Session, the Non-3GPP Device Connection Information includes the following information for each non-3GPP device:

Non-3GPP Device Identifier;
IPv6 Address/prefix(sub) associated with the non-3GPP device used in PDU Session;
Optionally, port range(s) associated with the non-3GPP device used in PDU Session.

If the PCF indicates to the SMF by rejecting the SM Policy Association Modification that any of the corresponding Non-3GPP Device Identifier(s) in the Non-3GPP Device Connection Information is not available in the UDR for the UE as specified in clause 6.1.3.31 of TS 23.503, the SMF rejects the PDU Session Modification with a cause code to notify the UE that the Non-3GPP Device Identifier(s) is not available for the UE.

5.52.4 QoS differentiation p. 567

QoS differentiation and policy control is defined in clause 6.1.3.31 of TS 23.503.