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.
If the UPF deployed on satellite is acting as PSA, the following enhancements apply:
If the UE is accessing gNB with satellite backhaul, and AMF is aware 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 126.96.36.199 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.
If the UPF deployed on satellite is acting as PSA or as UL CL/BP and local PSA, 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 based on GEO satellite ID provided by the AMF, 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 188.8.131.52 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 184.108.40.206 of TS 23.548.
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 220.127.116.11 describes the case of PSA UPF deployed on satellite, clause 18.104.22.168 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.
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 22.214.171.124.1 (Support for unicast traffic forwarding of a 5G VN).
SMF may reuse the mechanism described in clause 126.96.36.199.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 188.8.131.52.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.
For UPF deployed on satellite acting as UL CL/BP/local PSA case, the PSA UPF anchored by UE PDU sessions is on the ground, if the UEs are served by the same SMF, the SMF may determine to activate local switching and N19 forwarding for the UEs using the GEO satellite backhaul, based on:
AF request including of UE identifiers which require communication between UEs as described in clause 5.29.2;
Destination IP address(es) reported by on-ground PSA UPF as current reporting mechanism in clause 184.108.40.206. 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 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 220.127.116.11.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.
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. 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.
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.
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 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 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.
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.
When a PDU Session associated with a PIN is established by PEGC, an SMF is selected according to clause 18.104.22.168.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 22.214.171.124, may be applied.
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 126.96.36.199, 188.8.131.52a, and 184.108.40.206 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.
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.
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 budget and compensate for this delay in 5GS. The compensation is achieved by reducing the PDB for the 3GPP network by the non-3GPP delay.
If the PEGC supports requesting of the non-3GPP delay budget for a specific traffic flow, the PEGC may use the UE requested PDU Session Modification procedure to request a non-3GPP delay budget for a set of packet filters. Based on the (DNN, S-NSSAI) combination of the PDU Session, the SMF increases the dynamic CN PDB for the related GBR QoS flow by the requested non-3GPP delay budget according to operator policy and implementation and signals the updated dynamic CN PDB to NG-RAN. 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 applies 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.
A PIN is managed at the PIN application layer. In 5GS a PIN ID is unique in a PLMN and only used in the traffic descriptor of URSP rules, for routing traffic of specific PIN towards a dedicated (DNN, S-NSSAI) combination.
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).
QoS monitoring comprises of measurements of QoS 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.
The AF may request measurements for one or more of the following QoS parameters, which may trigger QoS monitoring for service data flow(s):
UL packet delay, DL packet delay, round trip packet delay, see clause 5.45.2.
Round trip packet delay when UL and DL are on different QoS flows, see clause 5.37.4.
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 220.127.116.11 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 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.
The SMF configures the UPF to perform QoS monitoring for the QoS Flow and to report the monitoring results as described in clause 18.104.22.168 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 parameters based on the authorized QoS Monitoring policy received from the PCF and/or local configuration.
The following clauses describe the QoS 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 NG-RAN may be required to provide the UL and/or DL QoS Flow congestion information (i.e. a percentage of congestion level for exposure). The UPF may be required to monitor the UL and/or DL QoS Flow congestion information reported from the NG-RAN.
QoS monitoring request to the NG-RAN and NG-RAN reporting for UL and/or DL QoS Flow congestion information to PSA UPF is as defined in 5.37.3. 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 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).
The QoS Monitoring for data rate allows the measurement of the UL and/or DL data rate per QoS flow at 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.
According to the QoS Monitoring request for UL and/or DL data rate from SMF, 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;
The AF may subscribe to NEF monitoring events as described in clause 22.214.171.124.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 e.g. Federated Learning, 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 filtering criteria. Alternatively, the AF may select the list of UEs for the AI/ML operation e.g. Federated Learning, 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 126.96.36.199 of TS 23.503 and in clause 4.16.15 of TS 23.502.
At the time or during the AI/ML operation. e.g., Federated Learning, 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 188.8.131.52 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 request a new recommended time window for the AI/ML operation using the Planned Data Transfer with QoS (PDTQ) requirements as described in clause 184.108.40.206 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 addresses, 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 220.127.116.11-1 of TS 23.502 and/or the Application-Specific Expected UE Behaviour parameter(s) captured in Table 18.104.22.168f-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 22.214.171.124 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 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) 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 126.96.36.199-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 collect the corresponding data for the list of UEs 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 in order to select member UE(s) used in application AI/ML operation. (See clause 188.8.131.52 of TS 23.502 for details of parameters).
AF in either trusted or untrusted domain can select the Member UEs for e.g. participating in federating learning operation, by collecting the corresponding data using network exposure information as described in clause 4.15.13 of TS 23.502, e.g. UE location reporting from the AMF, user plane information from the UPF and data analytics from NWDAF.