The access and mobility policy control encompasses the management of service area restrictions, the management of the RFSP functionalities and UE-AMBR, and the management of the SMF selection. This clause defines the management of service area restrictions and RFSP Index for a UE registered over 3GPP access. The management of service area restrictions for a 5G-RG or a FN-CRG using W-5GAN are specified in TS 23.316
The management of service area restrictions enables the PCF of the serving PLMN (e.g. V-PCF in roaming case) to modify the service area restrictions used by AMF as described in TS 23.501, clause 5.3.4
A UE's subscription may contain service area restrictions, which may be further modified by PCF based on operator defined policies at any time, either by expanding a list of allowed TAIs or by reducing a non-allowed TAIs or by increasing the maximum number of allowed TAIs. Operator defined policies in the PCF may depend on input data such as UE location, time of day, information provided by other NFs, etc.
The AMF may report the subscribed service area restrictions received from UDM during Registration procedure or when the AMF changed, the conditions for reporting are that local policies in the AMF indicate that Access and Mobility Control is enable. The AMF reports the subscribed service area restrictions to the PCF also when the policy control request trigger for service area restrictions change, as described in clause 22.214.171.124
, is met. The AMF receives the modified service area restrictions from the PCF. The AMF stores them then use it to determine mobility restriction for a UE. The PCF may indicate the AMF that there is an unlimited service area.
The service area restrictions consist of a list of allowed TAI(s) or a list of non-allowed TAI(s) and optionally the maximum number of allowed TAIs.
The enforcement of the service area restrictions is performed by the UE, when the UE is in CM-IDLE state or in CM-CONNECTED state when in RRC Inactive, and in the RAN/AMF when the UE is in CM-CONNECTED state.
The management of the RFSP Index enables the PCF to modify the RFSP Index used by the AMF to perform radio resource management functionality as described in TS 23.501, clause 5.3.4
. PCF modifies the RFSP Index based on operator policies that take into consideration e.g. accumulated usage, load level information per network slice instance etc. The subscribed RFSP Index may be further adjusted by the PCF based on operator policies at any time.
For radio resource management, the AMF may report the subscribed RFSP Index received from UDM during the Registration procedure or when the AMF changed. The conditions for reporting are that local policies in the AMF indicate that Access and Mobility Control is enable. The AMF reports the subscribed RFSP Index to the PCF when the subscription to RFSP Index change to the PCF is met. The AMF receives the modified RFSP Index from the PCF.
The enforcement of the RFSP Index is performed in the RAN.
Upon change of AMF, the source AMF informs the PCF that the UE context was removed in the AMF in the case of inter-PLMN mobility.
The management of UE-AMBR enables the PCF to provide the UE-AMBR information to AMF based on serving network policy. The AMF may report the subscribed UE-AMBR received from UDM. The conditions for reporting are that the PCF provided Policy Control Request Triggers to the AMF to report subscriber UE-AMBR change. The AMF receives the modified UE-AMBR from the PCF. The AMF provides a UE-AMBR value of the serving network to RAN as specified in TS 23.501, clause 126.96.36.199
The management of the SMF selection enables the PCF to instruct the AMF to contact the PCF during the PDU Session Establishment procedure to perform a DNN replacement, as specified in TS 23.501, clause 5.6.1
. To indicate the conditions to check whether to contact the PCF at PDU Session establishment (as specified in clause 188.8.131.52
), the PCF provides the Policy Control Request Triggers SMF selection management and, if necessary Change of the Allowed NSSAI, together with SMF selection management related policy control information (see clause 6.5
) during UE Registration procedure and at establishment of the AM Policy Association.
The PCF may update SMF selection management information based on PCF local decision or upon being informed about a new Allowed NSSAI. The AMF applies the updated SMF selection management information to new PDU Sessions only, i.e. already established PDU Sessions are not affected.
The 5GC shall be able to provide policy information from the PCF to the UE. Such policy information includes:
Access Network Discovery & Selection Policy (ANDSP): It is used by the UE for selecting non-3GPP accesses and for selection of the N3IWF in the PLMN. The structure and the content of this policy are specified in clause 6.6.1.
UE Route Selection Policy (URSP): This policy is used by the UE to determine if a detected application can be associated to an established PDU Session, can be offloaded to non-3GPP access outside a PDU Session, or can trigger the establishment of a new PDU Session. The structure and the content of this policy are specified in clause 6.6.2. A URSP rule includes one Traffic descriptor that specifies the matching criteria and one or more of the following components:
SSC Mode Selection Policy (SSCMSP): This is used by the UE to associate the matching application with SSC modes.
Network Slice Selection Policy (NSSP): This is used by the UE to associate the matching application with S-NSSAI.
DNN Selection Policy: This is used by the UE to associate the matching application with DNN.
PDU Session Type Policy: This is used by the UE to associate the matching application with a PDU Session Type.
Non-Seamless Offload Policy: This is used by the UE to determine that the matching application should be non-seamlessly offloaded to non-3GPP access (i.e. outside of a PDU Session).
Access Type preference: If the UE needs to establish a PDU Session for the matching application, this indicates the preferred Access Type (3GPP or non-3GPP).
The ANDSP and URSP may be pre-configured in the UE or may be provisioned to UE from PCF. The pre-configured policy shall be applied by the UE only when it has not received the same type of policy from PCF.
The PCF selects the ANDSP and URSP applicable for each UE based on local configuration, and operator policies taking into consideration the information defined in clause 184.108.40.206
In the case of a roaming UE, the V-PCF may retrieve ANDSP and URSP from the H-PCF over N24/Npcf. When the UE is roaming and the UE has valid rules from both HPLMN and VPLMN the UE gives priority to the valid ANDSP rules from the VPLMN.
The ANDSP and URSP shall be provided from the PCF to the AMF via N15/Namf interface and then from AMF to the UE via the N1 interface as described in TS 23.502, clause 220.127.116.11
. The AMF shall not change the ANDSP and the URSP provided by PCF.
The PCF is responsible for delivery of UE policy. If the PCF is notified about UE Policy delivery failure (e.g. because of UE unreachable), the PCF may provide a new trigger "Connectivity state changes" in Policy Control Request Trigger of UE Policy Association to AMF as defined in TS 23.502, clause 18.104.22.168
. After reception of the Notify message indicating that the UE enters the CM-Connected state, the PCF may retry to deliver the UE Policy.
For backward compatibility the PCF may subscribe the "Connectivity state changes (IDLE or CONNECTED)" event in Rel-15 AMF as defined in TS 23.502, clause 22.214.171.124
If due to UE Local Configurations, a UE application requests a network connection using Non-Seamless Offload, the UE shall use Non-Seamless Offload for this application without evaluating the URSP rules. Otherwise, the UE shall select the PDU Session or Non-Seamless Offload in the following order:
If the UE has an URSP rule (except the URSP rule with the "match all" Traffic descriptor) that matches the application as defined in clause 126.96.36.199, the UE shall perform the association of the application to the corresponding PDU Session or to Non-Seamless Offload according to this rule; Otherwise,
If no URSP rule is applicable for the application (except the URSP rule with the "match all" Traffic descriptor), the UE shall perform the association of the application to a PDU Session according to the applicable UE Local Configurations, if any. If the UE attempts to establish a new PDU session according to the UE Local Configurations and this PDU Session Establishment request is rejected by the network, then the UE shall perform the association of the application to a PDU Session or to Non-Seamless Offload according to the URSP rule with the "match all" Traffic descriptor; Otherwise,
It is assumed that the S-NSSAI(s) in the UE Local Configurations are operator-provided S-NSSAI(s). The provision of the S-NSSAI(s) is not specified.
The application layer is not allowed to set the S-NSSAI when the UE establishes a PDU Session based on the UE Local Configurations.
Any missing information in the UE Local Configurations needed to build the PDU Session Establishment request can be the appropriate corresponding component from the URSP rule with the "match all" Traffic descriptor.
If neither the UE Local Configurations nor the URSP rules are applicable for the application (except the URSP rule with the "match all" Traffic descriptor), the UE shall perform the association of the application to a PDU Session or to Non-Seamless Offload according to the URSP rule with the "match all" Traffic descriptor
For the existing PDU Session(s), the UE shall examine the URSP rules within the UE Policy in order to determine whether the existing PDU Session(s) (if any) are maintained or not. If not, then the UE may initiate a PDU Session release procedure for the PDU Session(s) that cannot be maintained.
If there are multiple IPv6 prefixes within the PDU Session, then the IPv6 multi-homed routing rules, described in clause 188.8.131.52.2 of TS 23.501
, on the UE shall be used to select which IPv6 prefix to route the traffic of the application.
For the case that an application cannot be associated to any PDU Session, the UE can inform the application that association of the application to PDU Session fails.
184.108.40.206.2 Distribution of the policies to UE Word-p. 29
The UE access selection and PDU Session related policy control enables the PCF to provide UE access selection and PDU Session related policy information to the UE, i.e. UE policies, that includes either Access network discovery & selection policy (ANDSP) or UE Route Selection Policy (URSP) or both using Npcf and Namf service operations.
The PCF may be triggered to provide the UE access selection and PDU Session related policy information during UE Policy Association Establishment and UE Policy Association Modification procedures as defined in clause 4.16.11
and clause 4.16.12 of TS 23.502
The PCF can install a PCC Rule and activate start and stop of application detection in the SMF. When the same PCF is selected for SM policy association control and UE policy association control, THE reporting of start and stop of an application can trigger the installation or update of a URSP rule in the UE to send the application traffic to the PDU session as defined in the URSP rule.
Operator defined policies in the PCF may depend on input data such as UE location, time of day, information provided by other NFs, etc as defined in clause 220.127.116.11
The PCF includes the UE access selection and PDU session related information delivered to the UE into a Policy Section identified by a Policy Section Identifier (PSI). The PCF may divide the UE access selection and PDU Session related policy information into different Policy Sections, each one identified by a PSI. Each Policy Section provides a list of self-contained UE access selection and PDU Session related policy information to the UE, via AMF. The PCF ensures that a Policy Section is under a predefined size limit, known by the PCF.
The size limit to allow the policy information to be delivered using NAS transport is specified in TS 29.507
. The size limit is configured in the PCF.
A list of self-contained UE access selection and PDU Session related policy information implies that:
when the PCF delivers URSP rules to the UE, the PCF provides the list of URSP rules in the order of precedence and without splitting a URSP rule across Policy Sections;
when the PCF delivers WLANSP rules, the list of WLANSP rules are provided in the order of priority and without splitting a WLANSP rule across Policy Sections;
when the PCF delivers the non-3GPP access network selection information, the whole list of non-3GPP access network selection information (as defined in clause 18.104.22.168) is provided in one Policy Section.
It is up to PCF decision how to divide the UE access selection and PDU Session related policy information into Policy Sections as long as the requirements for the predefined size limit and the self-contained content (described above) are fulfilled.
The Policy Section list can be different per user. One PSI and its corresponding content can be the same for one or more users.
The PCF may, for example, assign the URSP as one whole Policy Section, or it may subdivide the information in the URSP into multiple Policy Sections by assigning one or several URSP rules to each Policy Section.
The PLMN ID is provided to the UE together with UE access selection or PDU Session related policy information and it is used to indicate which PLMN a Policy Section list belongs to.
The AMF forwards the UE access selection and PDU Session related policy information transparently to the UE. If the (H-)PCF decides to split the UE policies to be sent to the UE, the PCF provides multiple Policy Sections separately to the AMF and then AMF uses UE configuration Update procedure for transparent UE policies delivery procedure to deliver the policies to the UE, this is defined in TS 23.502, clause 22.214.171.124
and clause 4.16
The AMF does not need to understand the content of the UE policy, rather send them to the UE for storage.
The UE shall update the stored UE access selection and PDU Session selection policies with the one provided by the PCF as follows (details are specified in TS 24.501
If the UE has no Policy Sections with the same PSI, the UE stores the Policy Section;
If the UE has an existing Policy Section with the same PSI, the UE replaces the stored Policy Section with the received information;
The UE removes the stored Policy Section if the received information contains only the PSI.
The UE keeps the received UE policies stored even when registering in another PLMN. The number of UE policies to be kept stored in the UE for PLMNs other than the HPLMN is up to UE implementation. If necessary, e.g. the number of UE policies stored in UE for PLMNs exceeds the maximum value, the UE may remove earlier stored UE policy in UE.
The ANDSP for VPLMN, if provided within the UE policy in the UE Configuration Update procedure described in TS 23.502, clause 126.96.36.199
, applies to the equivalent PLMN(s) indicated in the last received list of equivalent PLMNs in Registration Accept.
At Initial Registration or the Registration to 5GS when the UE moves from EPS to 5GS:
The UE provides the list of stored PSIs which identify the Policy Sections associated to the home PLMN and the visited PLMN (if the UE is roaming) that are currently stored in the UE. If USIM is changed, the UE does not provide any PSI. If no policies are stored in the UE for the home PLMN, the UE does not provide any PSI associated to the home PLMN. If the UE is roaming and has policies for the home PLMN but no associated policies for the visited PLMN the UE includes only the list of PSIs associated to the home PLMN.
UE may indicate its ANDSP support to the PCF. If it is received, the PCF shall take it into account for the determination on whether to provide the ANDSP to the UE. The PCF does not provide ANDSP rules to the UE if the UE does not indicate support for ANDSP.
The UE may also provide the OSId.
The UE may trigger an Initial registration with the list of stored PSIs to request a synchronization for example if the UE powers up without USIM being changed.
During Initial Registration, the (H-)PCF retrieves the list of PSIs and its content stored in the (H-)UDR for this SUPI while the V-PCF (in the roaming scenario) retrieves the list of PSIs and its content stored in the V-UDR for the PLMN ID of this UE (alternatively, the V-PCF can have this information configured locally).
The PSI list and content stored/configured for a PLMN ID can be structured according to e.g. location areas (e.g. TAs, PRAs). The V-PCF can then provide PSIs and its content only if they correspond to the current UE location.
In the roaming scenario, the V-PCF shall also forward any UE provided PSIs that are associated to the home PLMN to the H-PCF.
When the PCF (i.e. the (H-)PCF as well as the V-PCF) receives a list of PSIs associated to the PLMN of the PCF from the UE, the PCF compares the list of PSIs provided by the UE and the list of PSIs retrieved from the UDR. In addition, the PCF checks whether the list of PSIs provided by the UE or its content needs to be updated according to operator policies, e.g. change of Location and/or time. If the two lists of PSIs are different or an update is necessary according to operator policies (which includes the case that the UE did not provide a list of PSIs associated to the PLMN of the PCF), the PCF provides the changes in the list of PSIs or the corresponding content to the AMF which forwards them to the UE.
The (H-)PCF maintains the latest list of PSIs delivered to each UE as part of the information related to the Policy Association until the UE policy association termination request is received from the AMF. Then the (H-)PCF stores the latest list of PSIs and its contents in the (H-)UDR using the Nudr_DM_Update
including DataSet "Policy Data" and Data Subset "Policy Set Entry".
The (H-)PCF may use the PEI provided by the AMF and/or the OSId provided by the UE, to determine the operating system of the UE.
If the PEI, the OSId or the indication of UE support for ANDSP is available to the PCF, the PCF stores them in the UDR using Nudr_DM_Create
including DataSet "Policy Data" and Data Subset "UE context policy control data" when such information is received from the UE in the UE Policy Container.
If the (H-)PCF is not able to determine the operating system of the UE, and if the (H-)PCF requires to deliver URSP rules that contain Application ID as Traffic Descriptors, then the Traffic Descriptors of such URSP rules include multiple instances of Application IDs each associated to supported UE operating systems by the network operator implementation.
If the (H-)PCF determines the operating system of the UE and if the (H-)PCF requires to deliver URSP rules that contain Application ID as Traffic Descriptors, then the Traffic Descriptors of such URSP rules include the Application ID associated with the operating system determined by the PCF.
If the PCF does not take into account the received PEI and/or OSId then the PCF can send URSP rules containing application traffic descriptors associated to multiple operating systems.
188.8.131.52.1 PFD management
The Management of Packet Flow Descriptions enables the UPF to perform accurate application detection when PFD(s) are provided by an ASP and then to apply enforcement actions as instructed in the PCC Rule.
The operator is able to configure pre-defined PCC Rules in the SMF or dynamic PCC Rules in the PCF that include at least an application identifier for service data flow detection, charging control information, i.e. charging key and optionally the Sponsor identifier or the ASP identifier or both. Depending on the service level agreements between the operator and the Application Server Provider, it may be possible for the ASP to provide individual PFDs or the full set of PFDs for each application identifier maintained by the ASP to the SMF via the PFD Management service in the NEF (PFDF). The PFDs become part of the application detection filters in the SMF/UPF and therefore are used as part of the logic to detect traffic generated by an application. The ASP may remove or modify some or all of the PFDs which have been provided previously for one or more application identifiers. The SMF may report the application stop to the PCF for a application instance identifier as defined in clause 184.108.40.206.4 of TS 23.501
if the removed/modified PFD in SMF/UPF results in that the stop of the application instance is not being able to be detected.
PFD management is optionally supported in the NEF and the SMF.
The ASP manages (provision, update, delete) the PFDs through the NEF (PFDF). The PFD(s) are transferred to the SMF through the NEF (PFDF). The PFDF is a logical functionality in the NEF which receives PFD(s) from the ASP through the NEF, stores the PFD(s) in the UDR and provides the PFD(s) to the SMF(s) either on the request from ASP PFD management through NEF (PFDF) (push mode) or on the request from SMF (pull mode). The PFDF functionality is a service provided by the NEF.
The ASP may provide/update/remove PFDs with an allowed delay to the NEF (PFDF). Upon reception of the request from the ASP, the NEF (PFDF) shall check if the ASP is authorized to provide/update/remove those PFD(s) and request the allowed delay. The NEF (PFDF) may be configured with a minimum allowed delay based on SLA to authorize the allowed delay provided by the ASP. When ASP and requested allowed delay are successfully authorized, the NEF (PFDF) shall translate each external Application Identifier to the corresponding Application Identifier known in the core network. The NEF (PFDF) stores the PDF(s) into the UDR.
The Allowed Delay is an optional parameter. If the Allowed Delay is included, it indicates that the requested PFD(s) should be deployed within the time interval indicated by the Allowed Delay.
The PFDs may be retrieved by SMF from NEF (PFDF) in "pull" mode or may be provisioned from NEF (PFDF) to the SMF in "push" mode.
When the "push" mode is used, the NEF (PFDF) retrieves from the UDR the PFDs for each application identifier and distributes them to those SMFs that enable access to those applications. The NEF (PFDF) may be configured with the list of SMFs where PFD(s) should be distributed. There are three methods to provision PFD(s) from the NEF (PFDF) to the SMF:
Push of whole PFD(s) that can be accessed by the NEF (PFDF) according to operator configuration in NEF (PFDF) (e.g., provision per day according to operator configuration);
Selective push of an ASP change in the PFD set (i.e. ASP changes the PFD set while operator configuration defines when to push);
Selective push of an ASP change in the PFD set according to ASP request (i.e. ASP indicates to push changes in a PFD set within the time interval indicated by the Allowed Delay).
When the "pull" mode is used, at the time a PCC Rule with an application identifier for which PFDs are not available is activated or provisioned, the SMF requests all PFDs for that application identifier from the NEF (PFDF), and NEF (PFDF) retrieves them from the UDR. The PFD(s) retrieved for an application identifier from the NEF (PFDF) are cached in the SMF, and the SMF maintains a caching timer associated to the PFD(s) to control how long the PFD(s) are valid. When the caching timer expires:
If there are still active PCC rules that refer to the corresponding application identifier, the SMF reloads the PFD(s) from the NEF (PFDF) and provides it to the UPF over N4;
If there's no active PCC rule that refers to the corresponding application identifier or the SMF removes the last PCC rule that refers to the corresponding application identifier, the SMF removes the PFD(s) identified by the application identifier and informs the UPF to remove the PFD(s) identified by the application identifier over N4.
It is assumed that all SMF(s) and PFD (s) in an operator network are configured with the same default caching time value to be applied for all application identifiers.
When the "pull" mode is used, the NEF (PFDF) may provide to the SMF a caching time value per application identifier. The SMF receives the caching time value together with the PFD(s) from the NEF (PFDF) over N29 and applies this value for the application identifier instead of the configured default caching time value. If no caching time value is received from NEF (PFDF), the SMF uses the configured default caching time value.
The configuration of a caching time value per application identifier in NEF (PFDF) is based on the SLA between the operator and the ASP.
When only "pull" mode is supported in one PLMN, if the Allowed Delay is shorter than the caching time value stored for this application identifier, or shorter than the default caching time if no application-specific caching time is stored, the NEF (PFDF) may still store the PFD(s) to the UDR. The NEF (PFDF) shall provide an indication that the PFD(s) were stored and the caching time value to the ASP when informing that the Allowed Delay could not be met.
When either "pull" mode or "push" mode is used, if there's any update of the PFD(s) received and there are still active application detection rules in the UPF for the Application ID, the SMF shall provision the updated PFD set corresponding to the Application ID to the UPF.
SMF should assure not to overload N4 signalling while managing PFD(s) to the UPF, e.g. forwarding the PFD(s) to the right UPF where the PFD(s) is enforced.
When the UPF receives the updated PFD(s) from either the same or different SMF for the same application identifier, the latest received PFD(s) shall overwrite any existing PFD(s) stored in the UPF.
If the PFDs are managed by local O&M procedures, PFD retrieval is not used; otherwise, the PFDs retrieved from NEF (PFDF) overrides any PFDs pre-configured in the SMF. The SMF shall manage the pre-configured PFDs and PFDs provided by the NEF (PFDF) at the UPF as defined in clause 220.127.116.11.4 of TS 23.501
. The SMF may differentiate the need for PFD retrieval based on operator configuration in the SMF.
The AF requests including an application identifier may trigger the activation or provisioning of a PCC Rule in the SMF by the PCF based on operator policies.
18.104.22.168.2 Packet Flow Description Word-p. 33
PFD (Packet Flow Description) is a set of information enabling the detection of application traffic.
Each PFD may be identified by a PFD id. A PFD id is unique in the scope of a particular application identifier. Conditions for when PFD ID is included in the PFD is described in TS 29.551
. There may be different PFD types associated to an application identifier.
A PFD include the following information:
PFD id; and
one or more of the following:
3-tuple(s) including protocol, server side IP address and port number;
the significant parts of the URL to be matched, e.g. host name;
a Domain name matching criteria and information about applicable protocol(s).
Based on the agreement between AF and mobile operator, the PFD can be designed to convey proprietary extension for proprietary application traffic detection mechanisms.
How the PFD(s) are used in service flow detection is specified in clause 22.214.171.124
The AF may contact the PCF via the NEF (and Npcf_BDTPolicyControl_Create
service operation) to request a time window and related conditions for future background data transfer.
The NEF may contact any PCF in the operator network.
The AF request shall contain an ASP identifier, the volume of data to be transferred per UE, the expected amount of UEs, the desired time window, the External Group Identifier and optionally, Network Area Information, request for notification. The AF provides as Network Area Information either a geographical area (e.g. a civic address or shapes), or an area of interest that includes a list of TAs or list of NG-RAN nodes and/or a list of cell identifiers. When the AF provides a geographical area, then the NEF maps it based on local configuration into of a short list of TAs and/or NG-RAN nodes and/or cells identifiers that is provided to the PCF. The NEF may map the ASP id based on local configuration into the DNN, S-NSSAI that is provided to the PCF. The request for notification is an indication that BDT warning notification should be sent to the AF. The BDT warning notification indicates to the ASP that the BDT policy needs to be re-negotiated.
A 3rd party application server is typically not able to provide any specific network area information and if so, the AF request is for the whole operator network.
The PCF shall first retrieve all existing background transfer policies stored for any ASP from the UDR. The PCF may retrieve analytics on "Network Performance" from NWDAF in the area where the UEs of this ASP are expected to be located at a certain time period. The "Network Performance" Analytics includes the tuple-(expected load in the area of interest, expected number of UEs of this ASP in the Area of Interest) following the procedure and services described in TS 23.288
. Afterwards, the PCF shall determine, based on the information provided by the AF, the analytics on "Network Performance" if available and other available information (e.g. network policy and existing background transfer policies) one or more background transfer policies. The PCF may be configured to map the ASP identifier into a target DNN and slicing information (i.e. S-NSSAI), that is used if the NEF did not provide the DNN, S-NSAAI to the PCF.
A background transfer policy consists of a recommended time window for the background data transfer, a reference to a charging rate for this time window, network area information and optionally a maximum aggregated bitrate (indicating that the charging according to the referenced charging rate is only applicable for the aggregated traffic of all involved UEs that stays below this value). Finally, the PCF shall provide the candidate list of background transfer policies or the selected background transfer policy to the AF via NEF together with the Background Data Transfer Reference ID. If the AF received more than one background transfer policy, the AF shall select one of them and inform the PCF about the selected background transfer policy.
The maximum aggregated bitrate (optionally provided in a background transfer policy) is not enforced in the network. The operator may apply offline CDRs processing (e.g. combining the accounted volume of the involved UEs for the time window) to determine whether the maximum aggregated bitrate for the set of UEs was exceeded by the ASP and charge the excess traffic differently.
It is assumed that the 3rd party application server is configured to understand the reference to a charging rate based on the agreement with the operator.
The selected background transfer policy is finally stored by the PCF in the UDR as part of the Policy Data Set. The background transfer policy contains the Background Data Transfer Reference ID, the volume of data to be transferred per UE, the expected amount of UEs, the one or more instances of the tuple (ASP id, DNN, S-NSSAI) and if the AF subscribed to notifications on changes of the negotiated BDT policy. The same or a different PCF can retrieve this background transfer policy and corresponding related information from the UDR and take them into account for future decisions about background transfer policies for background data related to the same or other ASPs.
When the AF wants to apply the Background Data Transfer Policy to an existing session, then the AF will, at the time the background data transfer is about to start, provide, for each UE, the Background Data Transfer Reference ID together with the AF session information to the PCF (via the N5 interface). The PCF retrieves the corresponding background transfer policy from Policy Data Set in the UDR and derives the PCC rules for the background data transfer according to this transfer policy.
When the AF wants to apply the Background Data Transfer Policy to a future session, then the AF provides, to the NEF, the Background Data Transfer Reference ID together with the External Identifier (i.e. GPSI) or External Group Identifier of the UE(s) that are to be subject to the policy. The NEF translates the External Group Identifier into the Internal Group Identifier or the External Identifier into a SUPI. The NEF stores the Background Data Transfer Reference ID, in the UDR as Application Data Set and Background Data transfer data Subset for an Internal Group Identifier or a SUPI and the ASP id requesting to apply the Background Data transfer Policy to a future session for the UE(s). A PCF that serves the UE(s) (i.e. the PCF that serves the UE for AM Policies) may retrieve the Background Data Transfer Reference ID by retrieving the UE's Application Data from the UDR or by subscribing to notifications of changes to the UEs' Application Data in the UDR. Furthermore, the PCF retrieves the specific Background Data Transfer Policy based on the received Background Data Transfer Reference ID stored as Policy Data Set from the UDR.
When the PCF determines to send the Background Data Transfer Policy information to the UE as part of a URSP rule, the PCF will store the policy in the UDR as part of the UE's Policy Set Entry and will use the associated S-NSSAI and DNN associated with the ASP id stored in the Application Data to store the Background Data Transfer Reference ID in the UE's PDU Session policy control subscription information (see clause 126.96.36.199
). The PCF uses local policies to decide if and when the Background Data Transfer Policy information is going to be sent to the UE as Validation Criteria in the RSD part of the URSP rule (see clause 188.8.131.52
). The UE uses Validation Criteria to determine whether or not a PDU Session should be established. The Time Window and Location Criteria are not required to be checked again during the lifetime of the PDU Session.
The PCF may, based on operator configuration, trigger the UE Configuration Update procedure when the policy is selected, or the PCF may wait until receiving a notification from the AMF that the UE has entered the Tracking Area or Presence Area where the policy applies, and/or the PCF may wait until the time window when the policy applies is approaching. The UE's support of the Validation Criteria in a URSP rule is optional.
If a non-supporting UE receives Validation Criteria, it ignores the URSP rule.
When the PDU Session is established, the PCF that serves the PDU session will use the Background Data Transfer Reference ID in the UE's PDU Session policy control subscription information (see clause 184.108.40.206
) to retrieve the corresponding background data transfer policy (i.e. Time Window and/or Location Criteria) from the UDR and derives the PCC rules for the background data transfer according to this transfer policy.
The AF will typically contact the PCF for the individual UEs to request sponsored connectivity for the background data transfer.
A transfer policy is only valid until the end of its time window. The removal of outdated transfer policies from the UDR is up to implementation.
The PCF may reject corresponding SM Policy Association, as described in clause 4.16.4 of TS 23.502
, if Validation condition is not satisfied. And based on this feedback, SMF will reject the PDU session setup.
After successful PDU session setup, PCF may trigger PDU session release when Validation condition is not satisfied.
When the PCF knows, from the NWDAF as described in TS 23.288
, that the network performance in the area of interest goes below the criteria set by the operator, the PCF retrieves all the background transfer policies from the UDR, check the BDT policies that are not applicable due to the degradation of the network performance and calculates a list of new candidate BDT policies for the ASP to select. The PCF notifies the ASP on both the BDT policies that is not valid any longer and the candidate BDT policies via NEF if requested by the ASP.
The PCF removes the BDT policy stored in the UDR for the corresponding background data transfer reference ID.
When the AF receives the notification, the AF may select one of the background transfer policies included in the candidate list, and then inform the PCF about the selected background transfer policy. The PCF stores the newly selected background transfer policy into the UDR for the corresponding Background Transfer Reference ID. As a consequence, the PCF identifies the UEs for which the background transfer policy was already applied and updates URSP rules with the new Validation Criteria as described in clause 220.127.116.11 of TS 23.502
A PCF can subscribe to notifications on changes in background transfer policy in UDR. Upon reception of such notification the PCF has also to identify the UEs for which the background transfer policy was already applied and update URSP rules with the new Validation Criteria as described in clause 18.104.22.168 of TS 23.502
The Policy Control Request Triggers relevant for AMF and 3GPP access type are listed in table 22.214.171.124-1 and define the conditions when the AMF shall interact again with PCF after the AM Policy Association Establishment or UE Policy Association Establishment.
The PCF provides Policy Control Request Triggers to the AMF indicating a specific UE (i.e. SUPI or PEI) in the Policy Association establishment and modification procedures defined in the TS 23.502
. The Policy Control Request Triggers are transferred from the old AMF to the new AMF when the AMF changes.
The PCR triggers are not applicable any longer at termination of the AM Policy Association or termination of UE Policy Association.
In the following description of the Policy Control Request Triggers relevant for AMF and 3GPP access type, the term trigger is used instead of Policy Control Request Trigger where appropriate.
If the Location change trigger are armed, the AMF shall activate the relevant procedure which reports any changes in location as explained in TS 23.501, clause 5.6.11
by subscribing with the Npcf_AMPolicyAssociation
service or Npcf_UEPolicyAssociation
service. The reporting is requested to the level indicated by the trigger (i.e. Tracking Area). The AMF reports that the Location change trigger was met and the Tracking Area identifier.
If the Change of UE presence in Presence Reporting Area trigger is armed, i.e. the PCF subscribed to reporting change of UE presence in a Presence Reporting Area, including a list of PRA ids. In addition, for "UE-dedicated Presence Reporting Area" a short list of TAs and/or NG-RAN nodes and/or cells identifiers is included. Then, the AMF shall activate the relevant procedure which reports any Change of UE presence in Area of Interest as explained in TS 23.501, clause 5.6.11
. The reporting is requested for the specific condition when target UE moved into a specified PRA. The AMF reports the PRA Identifier(s) and indication(s) whether the UE is inside or outside the Presence Reporting Area(s) to the PCF.
The Service Area restriction change trigger and the RFSP index change trigger shall trigger the AMF to interact with the PCF for all changes in the Service Area restriction or RFSP index data received in AMF from UDM. The reporting includes that the trigger is met and the subscribed Service Area restriction or the subscribed RFSP index provided to AMF by UDM, as described in clause 126.96.36.199
The Change of the Allowed NSSAI trigger shall trigger the AMF to interact with the PCF if the Allowed NSSAI has been changed. The reporting includes that the trigger is met and the new Allowed NSSAI. The PCF may update RFSP index and/or SMF selection management related policy control information (described in clause 6.5
) in the AMF based on the Allowed NSSAI.
The UE-AMBR change trigger shall trigger the AMF to interact with the PCF for all changes in the subscribed UE-AMBR data received in AMF from UDM. The reporting includes that the trigger is met and the subscribed UE-AMBR provided to AMF by UDM, as described in clause 188.8.131.52
If the PLMN change trigger is armed, the AMF shall report it to the PCF to trigger the update of V2X service authorization parameters to the UE as defined in clause 6.2.2 of TS 23.287
. The reporting includes the event with the serving PLMN ID.
If the SMF selection management trigger is set, then the AMF shall contact the PCF when the AMF detects that the UE requested an unsupported DNN and the PCF indicated DNN replacement of unsupported DNNs in the Access and mobility management related policy control information (see clause 6.5
). The PCF shall select a DNN and provide the selected DNN to the AMF.
If the SMF selection management trigger is set, then the AMF shall contact the PCF when the UE requested a DNN within the list of DNN candidates for replacement for the S-NSSAI indicated in the Access and mobility management related policy control information (see clause 6.5
). The PCF shall select the DNN and provide the selected DNN to the AMF.
If the Connectivity state changes trigger is set, then the AMF shall notify the PCF when the UE connectivity state is changed e.g. from IDLE to CONNECTED. The AMF then reset the trigger.