Content for  TS 23.501  Word version:  19.1.0

Satellite may be used as part of the backhaul between (R)AN and 5GC. The 5G System supports to report of usage of satellite backhaul as described in clause 5.43.2. For some deployments, UPF may be deployed on the satellite. In these cases, edge computing or local switch via UPF deployed on the satellite may be performed as described in clauses 5.43.2 and 5.43.3. Deployments with satellite backhaul and edge computing with UPF on the ground is supported as described in clause 5.13, i.e. without satellite backhaul specific requirements.

This clause only applies to the case where Edge Computing is deployed with UPF and Edge Computing services on-board the satellite. The UPF deployed on satellite can act as UL CL/BP/local PSA UPF or act as PSA UPF. To select the UPF deployed on satellite as PSA, the following enhancements apply:

• If the UE is accessing gNB with satellite backhaul, and AMF is aware of the satellite backhaul category, the AMF sends the satellite backhaul category to the PCF. If GEO satellite backhaul category is indicated, the PCF may take it into account to generate or update the URSP rule as defined in clause 6.1.2.2 of TS 23.503 to including an appropriate Route Selection Descriptor for services deployed on GEO satellite, which further enable PDU Session Establishment with PSA UPF on the satellite.

Based on GEO satellite ID provided by the AMF, the SMF performs PSA UPF selection or UL CL/BP/local PSA selection and insertion during the PDU Session Establishment procedure as described in clause 4.3.2 of TS 23.502 or PDU Session Modification procedure as described in clause 4.3.3 of TS 23.502 to select the UPF deployed on the GEO satellite if available, which includes:

• Based on configuration, the AMF may determine the GEO Satellite ID serving the UE and send it to the SMF. If GEO satellite ID changes, e.g. due to UE handover to an gNB using different GEO satellite as part of backhaul, the AMF may update the latest GEO Satellite ID to the SMF.
• The SMF determines DNAI based on local configuration, DNN or S-NSSAI or both and the GEO Satellite ID received from AMF.
• If the UE is allowed to access the service(s) according to the EAS Deployment Information as described in clause 6.2.3.4 of TS 23.548, the SMF selects the PSA UPF or UL CL/BP/local PSA based on the DNAI corresponding to the GEO Satellite ID and other factors as described in clause 6.2.3.2 of TS 23.548.

If the AMF is aware that a satellite backhaul is used towards 5G AN, the AMF may report this to SMF as part of the PDU Session establishment procedure as described in clause 4.3.2 of TS 23.502. If AMF is aware that satellite backhaul category changes (e.g. at handover), the AMF reports the current Satellite backhaul category to SMF. The SMF reports it to the PCF when the "Satellite backhaul category change" PCRT was armed as specified in TS 23.503, or notifies it to other NFs if requested as described in clause 5.2.8.3 of TS 23.502. When the backhaul network changes from a type of satellite to terrestrial network, the AMF reports that non-satellite backhaul network is used with the Satellite backhaul category. Satellite backhaul category refers to the type of the satellite (i.e. GEO, MEO, LEO or OTHERSAT, DYNAMIC_GEO, DYNAMIC_MEO, DYNAMIC_LEO, and DYNAMIC_OTHERSAT) used in the backhaul as specified in clause 5.4.3.39 of TS 29.571. The dynamic satellite backhaul category (i.e. DYNAMIC_GEO, DYNAMIC_MEO, DYNAMIC_LEO, and DYNAMIC_OTHERSAT) refers that i.e. capabilities (latency and/or bandwidth) of the satellite backhaul change over time due to e.g. use of varying inter-satellite links as part of backhaul. Only a single backhaul category can be indicated.

If dynamic satellite backhaul is used, QoS monitoring may be used to measure packet delay as specified in clause 5.45.2. If the Satellite backhaul category received from SMF indicates dynamic satellite backhaul is used, the PCF may, based on PCF local policy or configuration, request QoS monitoring for the packet delay between UE and PSA UPF as specified in clause 5.45.2. The AF may trigger QoS monitoring by requesting QoS monitoring report from the PCF e.g. when the AF has received a dynamic satellite backhaul category.

Personal IoT Network (PIN) provides local connectivity between PINEs, i.e. UEs and/or non-3GPP devices. PINEs communicate using PIN direct communication, PIN indirect communication and the PIN-DN communication. The management of the PIN direct communication is out of the scope of this specification. For the PIN indirect communication and PIN-DN communication, the data traffic and PIN management traffic pass via a PEGC. With the support of the PEGC registered to 5G network, the PINEs have access to the 5G network services and may communicate with other PINEs within the PIN or with the DN via 5G network. A PEGC may support multiple PINs. For each PIN, a dedicated (DNN, S-NSSAI) combination shall be configured. PIN and PINEs are managed by specific PEMC with support of an AF, if AF (Application Server and PIN server as specified in TS 23.542) is deployed. A PIN includes at least one PEGC and at least one PEMC. The management of the PIN (i.e. the management of PIN creation, deletion and update) and PINE (including the management role distribution between PEMC and AF) is out of the scope of this specification. The PEGC is a UE with subscription data related to PIN within the 5GS (i.e. dedicated (DNN, S-NSSAI) combination(s) for PIN) and shall register to 5G network as UE in order to support PIN indirect communication and PIN-DN communication via dedicated PDU session. The UE acting as PEMC does not have subscription data related to PIN within the 5GS and behaves as normal UE if it is registered in 5GS. An AF for PIN may be deployed to support the PIN service. The AF for PIN may communicate with PINEs, including PEMC and PEGC, via application layer for management of the PIN which is transported as user plane data transparently to 5G network and the AF for PIN may communicate with the 5GC via NEF. The PEMC can manage a PIN via PIN direction communication or PIN indirect communication with the other PINEs of the PIN or via PIN-DN communication with an AF for PIN which enables the exchange of information with 5GC. The 5GC is enhanced to support the delivery of UE policy related to PIN service for PEGC (as specified in clause 5.44.2) and to support the PDU session management for PIN service (as specified in clause 5.44.3). See information in Annex P for the relation between PIN and 5GS. The PINE, PEMC and PEGC application layer functionalities are defined in TS 23.542 and are transparent in 5G network. The support of PIN by 5G-RG and FN-RG is not specified. Redundant PDU session for URLLC is not supported in conjunction with PIN.

For a PEGC registered in the 5G network, the 5G network supports the provisioning of URSP rules that include a PIN ID as Traffic Descriptor. URSP rules with a PIN ID in the Traffic Descriptor are sent to the PEGC based on the information provided from an AF for PIN as specified in TS 23.502 and TS 23.503 for policy delivery.

A PIN is managed at the PIN application layer. A unique PIN ID in a PLMN is designated to a PIN, e.g. by PIN server as specified in TS 23.542. In 5GS the PIN ID is only used in the traffic descriptor of URSP rules, for routing traffic of specific PIN towards a dedicated (DNN, S-NSSAI) combination as specified in clause 6.6.2 of TS 23.503. If a PIN contains more than one PEGCs, the list of PEGCs may be grouped together following the 5G VN group management principles as specified in clause 5.29.2. Then the PEGCs of a PIN can be identified by an External Group ID by an AF for PIN. The AF for PIN may use the External Group ID to manage the list of PEGCs that are part of a PIN and for providing URSP guidance (as specified in clause 5.44.2) and/or QoS requests applicable to all the PEGCs (as specified in clause 5.44.3).

QoS monitoring comprises of measurements of QoS monitoring parameters and reports of the measurement result for a QoS Flow and can be enabled based on 3rd party application requests and/or operator policies configured in the PCF. Event Reporting from PCF is specified in clause 6.1.3.18 of TS 23.503 and User Plane QoS Flow related QoS monitoring and reporting in clause 5.8.2.18. The AF may request measurements for one or more of the following QoS monitoring parameters, which may trigger QoS monitoring for service data flow(s):

• UL packet delay, DL packet delay, round trip packet delay for a service data flow, see clause 5.45.2.
• Congestion, see clause 5.45.3.
• Data Rate, see clause 5.45.4.
• Packet Delay Variation, see clause 5.37.7.
• Round trip packet delay considering UL on a service data flow and DL of another service data flow, see clause 5.37.4.

The following AF requested QoS requirements may trigger QoS monitoring for service data flow(s):

• Round-trip latency requirement, see clause 5.37.6.

The PCF may generate the authorized QoS Monitoring policy for a service data flow based on the QoS Monitoring request received from the AF (as described in clause 6.1.3.21 of TS 23.503) or based on PCF local policy or configuration reasons, such as PCF awareness of dynamic satellite backhaul connection. The PCF includes the authorized QoS Monitoring policy in the PCC rule and provides it to the SMF. The QoS monitoring parameter(s) that can be measured by means of QoS monitoring are listed below. The QoS monitoring policy in PCC rule (described in clause 6.3.1 of TS 23.503) may include the following:

• UL packet delay, DL packet delay, round trip packet delay, see clause 5.45.2.
• Congestion, see clause 5.45.3.
• Data Rate, see clause 5.45.4.

The SMF configures the UPF to perform QoS monitoring for the QoS Flow and to report the monitoring results as described in clause 5.8.2.18 with parameters determined by the SMF based on the authorized QoS Monitoring policy received from the PCF or local configuration or both. The SMF may also configure NG RAN to measure the QoS monitoring parameters by sending QoS monitoring request based on the authorized QoS Monitoring policy received from the PCF and/or local configuration. The QoS monitoring request to the NG RAN for different parameters is as defined in clause 5.45.2 and 5.45.3. Based on configuration, the AMF knows that the QoS monitoring feature is supported by all NG RAN nodes in an area. The AMF shall, when configured, inform the SMF about the support of the QoS monitoring feature by sending the parameter NG RAN QoS monitoring capability during PDU Session establishment, PDU Session modification, Service request and UE mobility procedures. The SMF determines whether QoS monitoring is possible or not for the PDU Session based on whether the NG RAN QoS monitoring capability is received (or not) from the AMF and the QoS monitoring capability of the UPF. QoS monitoring is possible if the SMF has received the NG RAN QoS monitoring capability in the last message received from AMF (i.e. Nsmf_PDUSession_CreateSMContext or Nsmf_PDUSession_UpdateSMContext service operation) and the UPF also supports the QoS monitoring capability. Otherwise, QoS monitoring is not possible for the PDU Session. The SMF may need to notify the PCF when the support for QoS monitoring has changed as described in clause 6.1.3.5 of TS 23.503. The following clauses describe the QoS monitoring parameters which can be measured and any specific actions or constraints for their measurement.

QoS Monitoring for packet delay allows for the measurement of UL packet delay, DL packet delay or round trip packet delay between UE and PSA UPF. The details of the QoS Monitoring for packet delay are described in clause 5.33.3. The PCF may calculate Packet Delay Variation (clause 5.37.7) and the round trip packet delay when UL and DL are on different QoS flows (clause 5.37.4) based on packet delay monitoring results of QoS flows.

The NG-RAN may be required to provide the UL and/or DL QoS Flow congestion information to UPF (i.e. a percentage of congestion level for exposure). The UPF may be required to monitor and expose the UL and/or DL QoS Flow congestion information reported from the NG-RAN. QoS monitoring request for congestion information provided by the SMF to the NG-RAN is to trigger the NG-RAN to measure and report UL and/or DL QoS Flow congestion information to PSA UPF as defined in 5.37.3. For the reporting of the congestion information from PSA UPF, the periodical reporting is not applied and only the Reporting frequency 'event triggered' applies, see clause 5.8.2.18. The PSA UPF reports the received UL and/or DL QoS Flow congestion information to the target NF as instructed by the QoS Monitoring request (see clause 5.8.2.18) from the SMF. Only ECN marking for L4S in NG-RAN (as described in clause 5.37.3) or QoS monitoring of congestion information may be requested to NG-RAN for a QoS Flow. QoS Monitoring of congestion information for exposure and ECN marking for L4S (in NG-RAN or UPF) are mutually exclusive, therefore, measurements of Congestion information on a QoS Flow are not exposed in QoS Monitoring reports if SMF enables ECN marking for L4S (see clauses 5.37.3 and 5.37.4).

The QoS Monitoring for data rate allows the measurement of the UL and/or DL data rate per QoS flow at the PSA UPF and it can be applied to a Non-GBR or GBR QoS flow. The data rate is measured over a monitoring averaging window with a standardized value. The SMF may configure the UPF to perform and report QoS monitoring for data rates as described in clause 5.8.2.18. According to the QoS Monitoring request for UL and/or DL data rate from the SMF, the UPF is required to initiate data rate measurement for a QoS Flow and to report the measured data rate as instructed.

This clause describes the list of 5GC enablers to support the following AI/ML operations in the Application layer over the 5G System:

• AI/ML operation splitting between AI/ML endpoints;
• AI/ML model/data distribution and sharing;
• Distributed/Federated Learning.

The AF may subscribe to NEF monitoring events as described in clause 4.15.3.2.3 of TS 23.502 in order to assist its application AI/ML operations. For example, the AF may subscribe to session inactivity time monitoring event in order to assist the AI/ML application server in scheduling available UE(s) to participate in the AI/ML operation (e.g. Federated Learning). In addition, the AF may subscribe to NEF to be notified on the traffic volume exchanged between the UE and the AI/ML application server in order to assist the AF with the transfer of AI/ML data. The AF that aims to provide an AI/ML operation may request assistance from the 5GC as described in clause 5.46.2. The AF initially provides a list of target member UE(s) and at least one filtering criterion, when subscribing to the NEF to be notified about a subset list of UE(s) (i.e. list of candidate UE(s)) that fulfil certain filtering criteria. Details of the procedures are described in clause 4.15.13 of TS 23.502. This subset list of UE(s) may become the member UE(s) used in the AI/ML operation depending on the AF's final decision, considering its internal logic. Alternatively, the AF may select the list of UEs for the AI/ML operation without NEF involvement as described in Annex I of TS 23.502: in this case, the AF determines a list of UEs without any assistance from the NEF and may use, for example, NWDAF analytics to assist with the AI/ML operation over 5G System. The AF may request the network to provide a recommended time window for the AI/ML operation using the Planned Data Transfer with QoS (PDTQ) requirements and procedures as described in clause 6.1.2.7 of TS 23.503 and in clause 4.16.15 of TS 23.502. At the time or during the AI/ML operation, the AF may request the serving NEF to provide QoS for a list of UEs. Each UE is identified by its UE IP address. The AF may subscribe to QoS Monitoring which may include also Consolidated Data Rate monitoring as described in clause 5.45 and in clause 4.15.6.13 of TS 23.502 for those AF requests for QoS that result in a successful resource allocation. The AF provides QoS parameters that are derived from the performance requirements listed in clause 7.10 of TS 22.261. As a result of the AF subscription to NEF to provide the subset list of UE(s) that fulfil certain filtering criteria, the AF may be notified about changes in the subset list of UE(s) and in such a case the AF may determine a updated list of UEs used in the AI/ML operation from the new subset list of UE(s) provided by NEF, and the AF may request a new recommended time window for the AI/ML operation using the Planned Data Transfer with QoS (PDTQ) requirements as described in clause 6.1.2.7 of TS 23.503 and in clause 4.16.15 of TS 23.502. The AF may request the NEF to provide QoS for the updated list of UEs, each identified by UE IP address, that results in QoS resources previously allocated to some UEs to be released, while QoS resources for other UEs to be allocated and QoS monitoring to be initiated. The AF may also subscribe to, or request Network Data Analytics as defined in TS 23.288, such as End-to-end data volume transfer time analytics, DN performance analytics, Network performance analytics, UE mobility analytics, WLAN performance analytics etc. in order to assist its AI/ML operations. The AF hosting an AI/ML based application may provision the Expected UE Behaviour parameters captured in Table 4.15.6.3-1 of TS 23.502 and/or the Application-Specific Expected UE Behaviour parameter(s) captured in Table 4.15.6.3f-1 of TS 23.502 to the 5GC. The parameters may be provisioned with corresponding confidence and/or accuracy levels, and a threshold may also be provided to the UDM by the NF (e.g. AMF or SMF) subscribing to such externally provisioned parameters as described in clause 4.15.6.2 of TS 23.502. In addition, the following principles apply when 5GS assists the AI/ML operation at the application layer:

• AF requesting 5GS assistance to AI/ML operations in the application layer shall be authorized by the 5GC using the existing mechanisms.
• Application AI/ML decisions and their internal operation logic reside at the AF and UE application client and is out of scope of 3GPP.
• Based on application logic, it is the application decision whether to request assistance from 5GC, e.g. for the purpose of selection of Member UEs that participate in certain AI/ML operation.
• In this Release, 5GS assistance to AI/ML operations in the application layer is conducted within a single slice.

5G System may support Member UE selection assistance functionality to assist the AF to select member UE(s) that can be used in application operations such as AI/ML based applications (e.g. Federated Learning) as specified in clause 5.46.1 according to the AF's inputs. The Member UE selection assistance functionality shall be hosted by NEF, and the features of the Member UE selection assistance functionality hosted by the NEF include (see clause 4.15.13 of TS 23.502 for details of Member UE selection procedures):

• Receiving a request from the AF that shall include a list of target member UE(s) (which may not necessarily be a part of the subsequent updated request), optionally (a) time window(s), and one or more filtering criteria as specified in Table 4.15.13.2-1 of TS 23.502 (e.g. UE current location, UE historical location, UE direction, UE separation distance, QoS requirements, DNN, preferred access/RAT type, Desired end-to-end data volume transfer time performance, or Service Experience).
• Referring to the filtering criteria provided by the AF and then interacting with 5GC NFs using existing services in order to have the corresponding data for all the UEs in the list of target member UE from relevant 5GC NFs (e.g. PCF, NWDAF, AMF, SMF) to derive the list(s) of candidate UE(s) (i.e. UE(s) among the list of target member UE(s) provided by the AF) which fulfil the filtering criteria.
• Providing the AF with the Member UE selection assistance information, including one or more lists of candidate UE(s), and optionally other additional information (e.g. one or more recommended time window(s) for performing the application operation, QoS of each target UE, UE(s) location, Access/RAT type, or Service Experience). NEF may also provide the number of UEs per each filtering criterion that do not fulfil the corresponding filtering criterion.

The Member UE selection assistance information provided by the NEF may be used by the AF to select member UE(s) used in application AI/ML operation. (See clause 5.2.6.32 of TS 23.502 for details of parameters). Without using the Member UE selection assistance functionality, AF in either trusted or untrusted domain can select the Member UE(s) for e.g. participating in federating learning operation, by collecting the corresponding data using network exposure information as described in clause 4.15 of TS 23.502, e.g. UE location reporting from the AMF, user plane information from the UPF and network data analytics from NWDAF.

The "subscription-based routing to a target core network" feature forwards traffic related with a UE to a target (partner) PLMN as specified in clauses 4.2.3 and 4.2.4. This subscription-based routing to a target core network feature may apply to all signalling and User Plane traffic related to a UE or only to the SM signalling and User Plane traffic related to the PDU sessions established by the UE to some DNN(s) and/or S-NSSAI(s) and/or related to a SUPI range and/or subscription data. The NF/NF Service discovery and selection mechanisms for serving the UE (all signalling and User Plane traffic) or a PDU session (corresponding SM signalling and User Plane traffic) in the target PLMN makes use of a corresponding Routing Indicator, or SUPI range, or S-NSSAI(s) and DNN(s) as defined in clauses 6.3.1 and 6.3.8 to discover and select a NF/NF Service in the target network.