Tech-invite  3GPPspecsRELsGlossariesSIP
Info21222324252627282931323334353637384‑5x

full Contents for  TS 23.503  Word version:   16.4.1

Top   Up   Prev   Next
0…   4…   5…   6…   6.1.3…   6.1.3.6…   6.2…   6.2.2…   6.3…   6.4…   6.6…   A…

 

6  Functional descriptionWord-p. 24
6.1  Overall description
6.1.1  General
6.1.1.1  PCF Discovery and Selection
The procedures for PCF Discovery and Selection by the AMF and by the SMF are described in TS 23.501.
The procedure to ensure that an AF reaches the PCF selected for a PDU Session is described in clause 6.1.1.2.
6.1.1.2  Binding an AF request targeting an UE address to the relevant PCF
6.1.1.2.1  General
When multiple and separately addressable PCFs have been deployed, a network functionality is required in order to ensure that an AF needing to send policies about UE traffic identified by an UE address can reach over N5 the PCF holding the corresponding PDU Session information. This network functionality has the following characteristics:
  • It has information about the user identity, the DNN, the UE (IP or Ethernet) address(es), the S-NSSAI and the selected PCF address for a certain PDU Session.
    • For IP PDU Session type, it shall receive information when an IP address is allocated or released for a PDU Session.
    • For Ethernet PDU Sessions supporting binding of AF request based on MAC address, it shall receive information when a MAC address is detected as being used by the UE over the PDU Session; this detection takes place at the UPF under control of SMF; This is defined in TS 23.501, clause 5.8.2.
  • The functionality determines the PCF address and if available the associated PCF instance ID and PCF set ID, selected by the PCF discovery and selection function described in TS 23.501, according to the information provided by the AF or the NEF.
A private IPv4 address may be allocated to different PDU Sessions, e.g.:
  • The same UE IPv4 address is allocated to different PDU Sessions to the same DNN and different S-NSSAI;
  • The same UE IPv4 address is allocated to different PDU Sessions to the same S-NSSAI and different DNN.
In the case of private IPv4 address being used for the UE, the AF or the NEF may send DNN S-NSSAI, in addition, in Npcf_PolicyAuthorization_Create request and Nbsf_Management_Discovery request. The DNN and S-NSSAI can be used by the PCF for session binding, and they can be also used to help selecting the correct PCF.
Up
6.1.1.2.2  The Binding Support Function (BSF)Word-p. 25
The BSF has the following characteristics:
  • For a certain PDU session, the BSF stores internally information about the user identity, the DNN, the UE (IP or Ethernet) address(es), the S-NSSAI, the selected PCF address and if available the associated PCF instance ID and PCF set ID, and optionally the level of binding (see clause 6.3.1.0 of TS 23.501).
  • NOTE 1:
    Only NF instance or NF set Level of Binding indication are supported at the BSF.
  • The PCF registers, updates and removes the stored information in the BSF using the Nbsf management service operations defined in TS 23.502.
    • The PCF ensures that it is updated each time an IP address is allocated or de-allocated to the PDU Session or, for Ethernet PDU Sessions supporting binding of AF request based on MAC address, each time it has been detected that a MAC address is used or no more used by the UE in the PDU Session.
    • Based on operator's policies and configuration, the PCF determines whether the same PCF shall be selected for the SM Policy associations to the same UE ID, S-NSSAI and DNN combination in the non-roaming or home-routed scenario.
    NOTE 2:
    This applies to usage monitoring.
  • The selected PCF (if needed) downloads the user profile from the UDR as described in TS 23.502 4.16.4 step 2. If usage monitoring is enabled for the user, and based on operator's policies, the PCF checks if the BSF has already existing PCF serving the combination of SUPI, S-NSSAI, DNN.
    • If no such PCF is found the PCF shall register itself to the BSF as described above in this clause.
    • Else if an existing PCF is found for the above combination, the PCF shall return to the SMF the available information about the existing PCF and a redirection indication.
    NOTE 3:
    The assumption is that for DNN, S-NSSAI combinations where usage monitoring be applied, the same BSF instance or the same BSF SET is selected for all UE PDU Sessions to the same DNN, S-NNSAI.
  • For retrieval binding information, any NF, such as NEF or AF, that needs to discover the selected PCF address(es), and if available, the associated PCF instance ID, PCF set ID and level of binding (see clause 6.3.1.0 of TS 23.501) for the tuple (UE address, DNN, S-NSSAI, SUPI, GPSI) (or for a subset of this Tuple) uses the Nbsf management service discovery service operation defined in TS 23.502.
  • The NF may discover the BSF via NRF or based on local configuration. In the case of via NRF the BSF registers the NF profile in NRF. The Range(s) of UE IPv4 addresses, Range(s) of UE IPv6 prefixes supported by the BSF may be provided to NRF.
  • If the NF received a PCF set ID or a PCF instance ID with an indication of level of binding as result of the Nbsf manageent service discovery service operation, it should use that information as NF set level or NF instance level Binding Indication to route requests to the PCF as defined in clause 6.3.1.0 of TS 23.501 and according to the following provisions:
    • For the NF set level of binding, the NF will receive a PCF set ID but no PCF instance ID. If an NF is not able to reach the received PCF address(es) and applies direct discovery, it should query the NRF for PCF instances within the PCF set and select another instance.
    • For the NF instance level of binding, the NF will receive a PCF set ID and a PCF instance ID. If an NF is not able to reach the received PCF address(es) and applies direct discovery, it should query the NRF for PCF service instances within the PCF and select another instance.
    • The NF should provide a Routing Binding Indication based on the received PCF set ID and possible PCF instance ID in requests it sends to the PCF.
  • For an ongoing NF service session, the PCF may provide Binding indication to the NF (see clause 6.3.1.0 of TS 23.501). This Binding indication shall then be used instead of any PCF information received from the BSF.
  • If a new PCF instance is selected, the new PCF should invoke Nbsf_Management_Update service operation to update the binding information in BSF.
The BSF may be deployed standalone or may be collocated with other network functions, such as PCF, UDR, NRF, SMF.
NOTE 4:
Collocation allows combined implementation.
Up
6.1.1.3  Policy decisions based on network analyticsWord-p. 26
Policy decisions based on network analytics allow PCF to perform policy decisions taking into account the analytics information provided by the NWDAF. The PCF subscribes/unsubscribes to Analytics information as defined in TS 23.288.
The following Analytics IDs are relevant for Policy decisions: "Load level information", "Service Experience", "Network Performance" and "Abnormal behaviour". The PCF may subscribe to notifications of network analytics related to "Load Level Information" using the Nnwdaf_AnalyticsSubscription_Subscribe service operation including the Analytics ID "Load level information", the Analytics Filter "S-NSSAI and NSI ID" and the Analytics Reporting Information set to a load level threshold value. The PCF is notified when the load level of the Network Slice Instance reaches the threshold, and then the PCF may verify if the RFSP index value needs to be modified for a SUPI for which an AM Policy Association is created; this is based on operator policies in the PCF, as defined in clause 6.1.2.1.
The PCF may subscribe to notifications of network analytics related to "Service Experience" using the Nnwdaf_AnalyticsSubscription_Subscribe service operation including the Analytics ID "Service Experience", the Target of Analytics Reporting "any UE" and the Analytics Filter including one or more "Application ID(s)". The PCF is notified on the Service Experience statistics or predictions including, for each Application Id, the list of SUPIs for which Service Experience is provided. In addition, both spatial and time validity may be provided as well as the confidence of the prediction. The PCF may check the 5QI values assigned to the Application, the number of UEs affected and may use this as input to calculate and update the authorized QoS for a service data flow template.
The NWDAF service to retrieve the service experience (i.e. the average observed Service MoS) is described in clause 6.4 of TS 23.288.
The PCF may subscribe to notifications of network analytics related to "Network Performance" using the Nnwdaf_AnalyticsSubscription_Subscribe service operation including the Analytics ID "Network Performance", the Target of Analytics Reporting "Internal Group Id" and the Analytics Filter including the Area of Interest. The PCF is notified on the Network Performance statistics or predictions including the Area of Interest and both the gNB status information and the predicted number of UEs in the Area of Interest. In addition, the confidence of the prediction may be provided. The PCF may use this information as input to calculate the background data transfer policies that are negotiated with the ASP, as defined in clause 6.1.2.4.
The NWDAF services to retrieve "Network Performance" as described in clause 6.6 of TS 23.288.
The PCF may subscribe to notifications of network analytics related to "Abnormal behaviour" using the Nnwdaf_AnalyticsSubscription_Subscribe service operation including the Analytics ID "Abnormal behaviour", the Target of Analytics Reporting "SUPI", "Internal Group Id" and the Analytics Filter including the list of Exceptions IDs and per each Expception Id a possible threshold. The list of Exception IDs is specified in TS 23.288. The PCF may use "Unexpected UE location" as input to determine the Service Area Restrictions defined in clause 6.1.2.1, "Suspicion of DDoS attack" to request the SMF to terminate the PDU session as defined in clause 6.1.3.6, "Wrong destination address" to perform gating of a service data flow as defined in clause 6.1.3.6 and "Unexpected long-live/large rate flows" to perform QoS related policies such as gating or policing as defined in clause 6.2.1.1.
The NWDAF services to retrieve UE related analytics are described in clause 6.7 of TS 23.288.
The PCF may also use the network analytics as input to its policy decision to apply operator defined actions for example for the UE context(s) or PDU session(s).
Up
6.1.2  Non-session management related policy control
6.1.2.1  Access and mobility related policy control
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 6.1.2.5, 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.
NOTE 1:
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.
NOTE 2:
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 5.7.2.6.
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 6.1.2.5), 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.
Up
6.1.2.2  UE access selection and PDU Session selection related policy (UE policy) controlWord-p. 27
6.1.2.2.1  General
The 5GC shall be able to provide policy information from the PCF to the UE. Such policy information includes:
  1. 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.
  2. 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:
    1. SSC Mode Selection Policy (SSCMSP): This is used by the UE to associate the matching application with SSC modes.
    2. Network Slice Selection Policy (NSSP): This is used by the UE to associate the matching application with S-NSSAI.
    3. DNN Selection Policy: This is used by the UE to associate the matching application with DNN.
    4. PDU Session Type Policy: This is used by the UE to associate the matching application with a PDU Session Type.
    5. 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).
    6. 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 6.2.1.2.
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 4.2.4.3. 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 4.16.12.2. After reception of the Notify message indicating that the UE enters the CM-Connected state, the PCF may retry to deliver the UE Policy.
NOTE 1:
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 5.2.2.3.
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 6.6.2.3, 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,
  • NOTE 2:
    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.
    NOTE 3:
    The application layer is not allowed to set the S-NSSAI when the UE establishes a PDU Session based on the UE Local Configurations.
    NOTE 4:
    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 5.8.2.2.2 of TS 23.501, on the UE shall be used to select which IPv6 prefix to route the traffic of the application.
NOTE 5:
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.
Up
6.1.2.2.2  Distribution of the policies to UEWord-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.
NOTE 1:
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 6.2.1.2.
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.
NOTE 2:
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 6.6.1.1) 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.
NOTE 3:
The Policy Section list can be different per user. One PSI and its corresponding content can be the same for one or more users.
NOTE 4:
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 4.2.4.3 and clause 4.16.
NOTE 5:
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 4.2.4.3, 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).
NOTE 6:
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.
NOTE 7:
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.
Up
6.1.2.3  Management of packet flow descriptionsWord-p. 31
6.1.2.3.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 5.8.2.8.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.
NOTE 1:
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.
NOTE 2:
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:
  1. 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);
  2. Selective push of an ASP change in the PFD set (i.e. ASP changes the PFD set while operator configuration defines when to push);
  3. 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.
NOTE 3:
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.
NOTE 4:
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.
NOTE 5:
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 5.8.2.8.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.
Up
6.1.2.3.2  Packet Flow DescriptionWord-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).
NOTE 1:
Based on the agreement between AF and mobile operator, the PFD can be designed to convey proprietary extension for proprietary application traffic detection mechanisms.
NOTE 2:
How the PFD(s) are used in service flow detection is specified in clause 6.2.2.2.
Up
6.1.2.4  Negotiation for future background data transfer
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.
NOTE 1:
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.
NOTE 2:
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.
NOTE 3:
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.
NOTE 4:
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 6.2.1.3). 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 6.6.2.1). 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.
NOTE 5:
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 6.2.1.3) 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.
NOTE 6:
The AF will typically contact the PCF for the individual UEs to request sponsored connectivity for the background data transfer.
NOTE 7:
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 4.16.12.2 of TS 23.502.
NOTE 8:
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 4.16.12.2 of TS 23.502.
Up
6.1.2.5  Policy Control Request Triggers relevant for AMFWord-p. 35
The Policy Control Request Triggers relevant for AMF and 3GPP access type are listed in table 6.1.2.5-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.
Policy Control Request Trigger
Description
Condition for reporting

Location change (tracking area)
The tracking area of the UE has changed.
PCF (AM Policy, UE Policy)
Change of UE presence in Presence Reporting Area
The UE is entering/leaving a Presence Reporting Area
PCF (AM Policy, UE Policy)
Service Area restriction change
The subscribed service area restriction information has changed.
PCF (AM Policy)
RFSP index change
The subscribed RFSP index has changed
PCF (AM Policy)
Change of the Allowed NSSAI
The Allowed NSSAI has changed
PCF (AM Policy)
UE-AMBR change
The subscribed UE-AMBR has changed
PCF (AM Policy)
PLMN change
The UE has moved to another operators' domain.
PCF (UE Policy)
SMF selection management
UE request for an unsupported DNN or UE request for a DNN within the list of DNN candidates for replacement per S-NSSAI
PCF (AM Policy)
Connectivity state changes
The connectivity state of UE is changed
PCF (UE Policy)

NOTE:
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 6.1.2.1.
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 6.1.2.1.
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.
Up

Up   Top   ToC