Tech-invite3GPPspaceIETFspace
21222324252627282931323334353637384‑5x

Content for  TS 23.501  Word version:  18.5.0

Top   Top   Up   Prev   Next
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…   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…

 

5.43  Support for 5G Satellite Backhaul |R18|p. 508

5.43.1  Generalp. 508

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

5.43.2  Edge Computing via UPF deployed on satellitep. 508

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

5.43.3  Local switch for UE-to-UE communications via UPF deployed on GEO satellitep. 509

5.43.3.1  Generalp. 509

The UE to UE traffic may be locally routed by UPF(s) deployed on satellite (i.e. through local switch) to the target UE without traversing back to the satellite gateway on the ground.
Local switching via UPF(s) deployed on satellite in this clause only applies on GEO satellite backhaul case and considers only DNNs and slices for 5G VN.
N19 tunnel may be established between two UPFs deployed on different satellites for traffic between UEs. Also, N6 may be used for carrying traffic between UPFs deployed on different satellites.
Only a single SMF is supported for local switching and N19 forwarding, i.e. both UEs are served by the same SMF.
Clause 5.43.3.2 describes the case of PSA UPF deployed on satellite, clause 5.43.3.3 describes the case of UL CL/BP and local PSA deployed on satellite (PSA UPF is on the ground). Selection of PSA UPF or UL CL/BP/local PSA on satellite is described in clause 6.3.3 and determination of DNAI to select the UPF deployed on the corresponding GEO satellite reuses the mechanism described in clause 5.43.2.
A combination of DNN/S-NSSAI is assigned by the operator for the communications between UEs where backhaul with UPF is deployed on GEO satellite, the URSP is described in TS 23.503 and its configuration to enable the selection PSA UPF on the GEO satellite reuses the mechanism described in clause 5.43.2.
Up

5.43.3.2  Local switch with PSA UPF deployed on satellitep. 510

If SMF selects the UPF deployed on satellite as PSA of UE's PDU Session, the SMF configures the UE's N4 session to forward/detect packet to/from the internal interface as specified for the configuration for the 5GVN group member's N4 Session in clause 5.8.2.13.1 (Support for unicast traffic forwarding of a 5G VN).
SMF may reuse the mechanism described in clause 5.8.2.13.1 to configure group-level N4 session rules for each N19 tunnel.
For establishing N19 tunnel between the PSA UPFs onboard the satellite, the PSA UPFs are controlled by the same SMF.
  • To process packets between UE and servers residing in DN, SMF configures rules to route traffic via N6 as described in clause 5.8.2.13.1.
The group-level N4 session is per DNN and S-NSSAI. The SMF can create, update or delete the group-level N4 Session, i.e. add or delete N4 rules, allocate or release the N19 tunnel resources based on operator deployment, e.g. based on GEO satellite's planned obsolescence or new GEO satellite setup.
N6 may be used for carrying traffic between PSA UPFs deployed on different satellites. If N6 is used, SMF configures corresponding N4 rules for processing traffic to/from N6.
Up

5.43.3.3  Local switching with UL CL/BP and local PSA UPF deployed on satellitep. 510

If the UEs using GEO satellite backhaul are served by the same SMF and the GEO satellite(s) serving the UEs has UPF deployed, the SMF may determine to activate local switching and N19 forwarding for the UEs, based on:
  1. AF request including of UE identifiers which require communication between UEs as described in clause 5.29.2; and/or
  2. Destination IP address(es) reported by on-ground PSA UPF as current reporting mechanism in clause 5.8.5.7. To enable the destination IP address(es) reporting, SMF configures the on-ground PSA UPF to detect UL packets with destination IP addresses which belong to the current UPF address pool.
If the SMF determines that the UEs (i.e. corresponding to AF request in bullet 1) and/or the Destination IP address(es) reported in bullet 2)) are under the same GEO satellite (or multiple connectable GEO satellites) based on GEO Satellite ID(s) reported by AMF and the UEs are allowed to access the DNAIs corresponding to the GEO satellite IDs, for each UE communicating with target UE(s) in the communication group, the SMF may select and insert the UPF deployed on GEO satellite according to the DNAI as UL CL/BP and L-PSA, and configures UL CL/BP with the following rule:
  • Route the data traffic received from the UE and destined to IP address(es) of the target UE(s) to the L-PSA.
  • Route other data traffic received from the UE to the PSA UPF of the UE's PDU Session.
The SMF configures the Local PSA with local forwarding rules to forward the data traffic to the target UEs directly. If the selected L-PSAs are different for the UEs in the communication group, N19 tunnel is established between the L-PSAs. For establishing N19 tunnel between the UPFs onboard the satellite, the UPFs are controlled by the same SMF. If UEs are members of the same 5G VN group, the SMF may configure the local data forwarding rules on L-PSA(s) using 5GVN user plane handing mechanism in clause 5.8.2.13.1 (Support for unicast traffic forwarding of a 5G VN).
N6 may be used for carrying traffic between L-PSA UPFs deployed on different satellites. If N6 is used, SMF configures corresponding N4 rules for processing traffic to/from N6.
Up

5.43.4  Reporting of satellite backhaul to SMFp. 510

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 and indicates the satellite backhaul category change to SMF.
Satellite backhaul category refers to the type of the satellite (i.e. GEO, MEO, LEO or OTHERSAT, DYNAMIC_GEO, DYNAMIC _MEO, DYNAMIC _LEO, DYNAMIC _OTHERSAT) used in the backhaul as specified in clause 5.4.3.39 of TS 29.571. Only a single backhaul category can be indicated.
If dynamic satellite backhaul is used by the NG-RAN, 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, the AMF notifies the SMF of the corresponding dynamic satellite backhaul category to serve the PDU Session and the SMF can notify it to other NFs as described in clause 5.2.8.3 of TS 23.502.
Up

5.43.5  QoS monitoring when dynamic Satellite Backhaul is usedp. 511

If dynamic satellite backhaul is used, QoS monitoring can 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 can also trigger QoS monitoring by requesting QoS monitoring report from the PCF e.g. when the AF has received dynamic satellite backhaul indication.
Up

5.44  Support of Personal IoT network service |R18|p. 511

5.44.1  Generalp. 511

Personal IoT Network (PIN) provides local connectivity between PIN elements i.e. UEs and/or non-3GPP devices. PIN elements 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 management traffic pass via a UE acting as PIN element with Gateway Capability (PEGC). With the support of the PEGC registered to 5G network, the PIN Elements have access to the 5G network services and may communicate with other PIN Elements within the PIN or with the DN via 5GC. A PEGC may support multiple PINs. For each PIN, a dedicated DNN/S-NSSAI shall be configured.
PIN and PIN elements are managed by specific PIN element with Management Capability (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 network (i.e. the management of PIN network creation, deletion and update) and PIN Element (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. (DNN, S-NSSAI) combination(s) for PIN) and shall register to 5GS 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 PIN elements, including PEMC and PEGC, via application layer for management of the PIN which is transported as user plane data transparently to 5GS and with the 5GC via NEF.
The PEMC can manage the PIN via PIN direction communication or PIN indirect communication with the other elements of PIN or via PIN-DN communication with PIN AF which enables the exchange of information with 5GC.
The 5GC is enhanced to support the delivery of UE policy related to PIN service for UE acting as 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 5GS.
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.
Up

5.44.2  UE policy delivery for PINp. 512

For a PEGC registered in the 5GS, the 5GS 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 UE based on the information provided from an AF for PIN as specified in TS 23.502 and TS 23.503 for policy delivery.

5.44.3  Session management enhancement for PIN service supportp. 512

5.44.3.1  PDU Session Establishment for PINp. 512

When a PDU Session associated with a PIN is established by PEGC, an SMF is selected according to clause 4.3.2.2.3 of TS 23.502 based on S-NSSAI/DNN. The PEGC may use IP address allocation methods as specified in clause 5.8.2 (e.g. IPv6 Prefix Delegation feature).
One PEGC may serve more than one PIN. The PEGC may use a single or multiple PDU sessions to serve multiple PINs. One PDU Session may be shared by more than one PIN served by the PEGC, if differentiation or isolation for the traffics to/from different PINs via PEGC is not required in 5GS. Otherwise, different DNNs and S-NSSAIs shall be applied to distinguish the PINs by different PDU sessions of the PEGC.
One PIN can be served by only one PDU session in the PEGC. If there are multiple PDU sessions for a PIN from different PEGCs connecting to the same UPF, the same mechanism for local switching in the UPF as defined for 5G VN group communication, as described in clause 5.8.2.13, may be applied.
Up

5.44.3.2  Session management related policy controlp. 512

For PIN indirect communication and PIN-DN communication via PEGC and5GC with PDU session, the 5GC supports the session policy control. The policy control is based on session management procedures as specified in TS 23.502 and TS 23.503.
An AF may provide QoS parameters for PIN traffic to 5GC as specified in clauses 4.15.6.6, 4.15.6.6a, and 4.15.6.14 of TS 23.502.
An AF may influence traffic routing for PDU sessions for PIN-DN communication as specified in clause 5.6.7 and in clause 4.3.6 of TS 23.502.
Up

5.44.3.3  Non-3GPP QoS Assistance Informationp. 512

QoS experienced by PINEs connected behind a PEGC depends on the end-to-end path between a PINE and the application server, i.e. depends on the QoS differentiation in both the 3GPP network and the non-3GPP network attached to the PEGC. Non-3GPP QoS Assistance Information (N3QAI) enables the PEGC to perform QoS differentiation for the PINEs in the non-3GPP network behind the PEGC.
During PDU session establishment and PDU session modification, if the SMF provides the PEGC with QoS flow descriptions, the SMF may additionally signal N3QAI for each QoS flow to the PEGC based on the (DNN, S-NSSAI) combination of the PDU Session. Based on the N3QAI together with QoS rule information, the PEGC may reserve resources in the non-3GPP network. N3QAI consists of the following QoS information: QoS characteristics, GFBR/MFBR, Maximum Packet Loss Rate, Notification Control.
How to enforce QoS based on the N3QAI in the non-3GPP network is considered outside the scope of 3GPP.
Up

5.44.3.4  Non-3GPP delay budget between PINE and PEGCp. 512

For PIN indirect communication and PIN-DN communication via PEGC and 5GC, non-3GPP delay is the delay between the PEGC and the PINE. 5GC may need to be aware of the non-3GPP delay and compensate for this delay in 5GS. The compensation is achieved by adjusting the dynamic CN PDB for the 3GPP network by the non-3GPP delay (i.e. the network determined original PDB value is unchanged, but it needs to cover non-3GPP delay, besides the AN PDB and CN PDB).
If the PEGC supports providing of the non-3GPP delay budget for a specific QoS flow of the PIN traffic, the PEGC may provide a non-3GPP delay budget to SMF by using the UE requested PDU Session Modification procedure. Based on the (DNN, S-NSSAI) combination of the PDU Session, the SMF may, according to operator policy and implementation, consider the non-3GPP delay budget when signalling the dynamic CN PDB to NG-RAN. The dynamic CN PDB signalled to the NG-RAN ismay be calculated as the sum of the value of dynamic CN PDB for the related GBR QoS flow and the requested non-3GPP delay budge. If the dynamic CN PDB changes in the SMF (e.g., when an I-UPF is inserted by the SMF), based on the (DNN, S-NSSAI) combination of the PDU Session, the SMF may apply the non-3GPP delay budget again before signalling the dynamic CN PDB to NG-RAN. The non-3GPP delay budget does not impact the QoS flow binding in SMF.
It is assumed that the PEGC will limit the frequency of triggering the UE-initiated PDU Session Modification request to provide the non-3GPP delay budget to the network to avoid unnecessary signalling.
Up

5.44.4  Identifiers for PINp. 513

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 application layer 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 the 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).
Up

5.45  QoS Monitoring |R18|p. 513

5.45.1  Generalp. 513

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):
The following AF requested QoS requirements may trigger QoS monitoring for service data flow(s):
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:
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 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.
The following clauses describe the QoS monitoring parameters which can be measured and any specific actions or constraints for their measurement.
Up

5.45.2  Packet delay monitoringp. 514

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

5.45.3  Congestion information monitoringp. 514

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 shall send a report when the measurement result crosses the indicated Reporting threshold. Subsequent reports shall not be sent by the PSA UPF during the Minimum waiting time.
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 one of ECN marking for L4S (in the case of ECN marking for L4S in RAN as described in clause 5.37.3) or QoS monitoring of congestion information may be requested to NG-RAN for a QoS Flow. They are mutually exclusive, therefore, measurements of Congestion information on a QoS Flow are not provided in QoS Monitoring reports if SMF enables ECN marking for L4S in RAN (see clause 5.37.3).
Up

5.45.4  Data rate monitoringp. 515

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

5.45.5Void

5.46  Assistance to AI/ML Operations in the Application Layer |R18|p. 515

5.46.1  Generalp. 515

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

5.46.2  Member UE selection assistance functionality for application operationp. 516

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

5.47  Support for Network Controlled Repeater (NCR) |R18|p. 517


Up   Top   ToC