3 Policy Services

This chapter explains the Policy services.

Note:

The performance and capacity of the Policy system may vary based on the Call model, Feature/Interface configuration, underlying CNE and hardware environment, including but not limited to the complexity of deployed policies, policy table size , object expression and custom json usage in Policy design.

3.1 Audit Service

Policy signaling services like SM service, AM service, UE service, Binding Management service etc are stateless, thereby making the centralized DB tier to store the session states. The policy micorservices session processing and DB tier transactions happen over network. The transactions that fail due to varied reasons get stored in the database as stale records. These stale records grows indefinitely over a period of time. The Audit Service is responsible for auditing the database to monitor for stale records, and either notify or clean up these stale records. The service that needs to use the Audit service to audit its tables, must register with the Audit service.

Figure 3-1 Audit Service Registration


The Audit Service Single Pod design

Audit service is mainly responsible for:
  • allows core services to dynamically register or de-register the tables for auditing process
  • core services can change other attributes at run time by using the Audit service restful interface
  • notifying the context owners about the expired records in the registered table for auditing
  • provide flow control of notifications towards the context owners
  • perform forceful deletion of stale records, in case no corrective action is taken by context owners
  • publish total count of records in the registered table for auditing

Audit service is not only responsible for stale session cleanup but has increased scope in other signaling features as well e.g., notifying core service for binding retry attempts.

Audit service with single pod deployment makes it neither scalable nor highly available. Audit service supports multiple pods, by using Audit Schedule. Audit Schedule helps to effectively manage and plan the audit service on the registered services.

Figure 3-2 Multiple Pod Audit Service


Multiple Pod Audit Service

Exception tables for the following services are maintained in an NDB Cluster to capture conflicting data.
  • Binding Service
  • SM Service
  • AM Service
  • UE Policy Service
  • PCRF Core
  • PDS
  • Usage Monitoring

These exception tables are used to detect occurrences of conflict between sites and records/keys in tables for which conflict happens.

Records in exception tables can grow rapidly due to frequent collision that can happen. Audit service is used to cleanup these exception tables in scheduled manner. The Audit service configuration for cleaning up these exception tables are predefined using Helm parameters at the time of installation with a default 24hr frequency for auditing.

To enable auditing on the exception tables, add exceptionTableAuditEnabled parameter to custom-values.yaml file while upgrading to latest version and set the value of this parameter to true. After the upgrade procedure is complete, enable or disable the audit for the above mentioned services using CNC Console. For more details on enabling the audit, see Enabling/Disabling Services Configurations section in Oracle Communications Cloud Native Core, Converged Policy Installation, Upgrade, and Fault Recovery Guide.

For information on how to configure Policy Audit Service, see Audit Service

3.2 Access and Mobility Service

Policy implements Access and Mobility (AM) management service related policies over the N15 interface towards Access and Mobility Management Function (AMF).

The following figure describes the communication between PCF and AMF over the N15 interface:

Figure 3-3 Communication between PCF and AMF over N15

PCF AMF interface

AMF can perform the following functions:

  • Enforcing control of policy decisions related to Radio Access Technology (RAT) or Frequency Selection Priority.
  • Enforcing Service Area Restrictions. It is executed in User Equipement (UE).
  • Enabling location tracking for a UE to get periodic updates on the current location of a subscriber.

Policy supports the following 3GPP defined services for AM Management:

Table 3-1 Access and Mobility Services

Service Operation Name Description Initiated By Resource URI HTTP Method
Npcf_AMPolicyControl_Create Creates an AM Policy Association and provides corresponding policies to the Network Function (NF) consumer AMF {apiRoot}/npcf-am-policy-control/v1/policies/ POST
Npcf_AMPolicyControl_Update Updates an AM Policy Association and provides corresponding policies to the NF consumer when the policy control request trigger is met or the AMF is relocated due to the UE mobility and the old PCF is selected AMF {apiRoot}/npcf-am-policy-control/v1/policies/{polAssoId}/update POST
Npcf_AMPolicyControl_UpdateNotify Provides updated policies to the NF consumer PCF {{Notification URI}/update

{Notification URI}/terminate

POST
Npcf_AMPolicyControl_Delete Provides means for the NF consumer to delete the AM Policy Association AMF {apiRoot}/npcf-am-policy-control/v1/policies/{polAssoId} DELETE
Npcf_AMPolicyControl_TerminateNotify Requests termination of policies to the NF consumer PCF {apiRoot}/npcf-am-policy-control/v1/policies/{supi}/updateNotify POST

For information on how to configure PCF Access and Mobility service, see PCF Access and Mobility.

3.3 Authorization Service

PCF implements policy authorization service that authorizes Application Function (AF) request over the N5 interface.

Policy Authorization service supports the creation of policies as requested by AF for Packet Data Unit (PDU) session. Policy authorization service is a critical function for IP Multimedia Subsystem (IMS) integration and dynamic Policy and Charging Control (PCC) rule creation.

Oracle Communications PCF supports the following 3GPP defined services for Policy Authorization:

Table 3-2 Policy Authorization Services

Service Operation Name Description Initiated By Resource URI HTTP Method
Npcf_PolicyAuthorization_Create Determines and installs the policy according to the service information provided by an authorized NF service consumer. AF, Network Exposure Function (NEF) {apiRoot}/npcf-policyauthorization/v1/app-sessions POST
Npcf_PolicyAuthorization_Update Determines and updates the policy according to the modified service information provided by an authorized NF service consumer. AF, NEF {apiRoot}/npcf-policyauthorization/v1/app-sessions/{appSessionId} PATCH
Npcf_PolicyAuthorization_Delete Provides means to delete the application session context of the NF service consumer. AF, NEF {apiRoot}/npcf-policyauthorization/v1/app-sessions/{appSessionId}/delete POST
Npcf_PolicyAuthorization_Notify Notifies NF service consumer of the subscribed events. PCF

{notifUri}/notify

{notifUri}/terminate

POST
Npcf_PolicyAuthorization_Subscribe Allows NF service consumers to subscribe to the notification of events. AF, NEF {apiRoot}/npcf-policyauthorization/v1/app-sessions/{appSessionId}/events-subscription PUT
Npcf_PolicyAuthorization_Unsubscribe Allows NF service consumers to unsubscribe to the notification of events. AF, NEF {apiRoot}/npcf-policyauthorization/v1/app-sessions/{appSessionId}/events-subscription DELETE

Policy authorization for PCF interaction with NEF

The Npcf_PolicyAuthorization on N5 interface acts as the main integration point between PCF and NEF. The Npcf_PolicyAuthorization ensures that the services and applications utilizing the 5G network, especially those accessed externally through the NEF, are governed by appropriate policies established by the PCF.

The Npcf_PolicyAuthorization service operation authorizes the request from the NF service consumer NEF, and optionally communicates with Npcf_SMPolicyControl service to determine and install the policy according to the information provided by the NF service consumer.

PCF complies with 3GPP 23.502 and 29.514 Rel 15.4. For details on the message format, procedures followed, and the other aspects of Npcf_PolicyAuthorization over N5 interface that PCF complies with, see the Compliance Matrix.

For configuring Policy Authorization service, see PCF Policy Authorization.

3.4 Binding Service

Binding service stores binding information related to 4G and 5G subscribers and help Diameter Gateway in forwarding Application Function (AF) requests. It also queries Oracle Communications Cloud Native Core, Network Repository Function (NRF) client for fetching Oracle Communications Cloud Native Core, Binding Support Function (BSF) information (One time Query and subscribe for notifications). For BSF, autonomous NRF discovery and static configuration is only supported, on-demand is not yet supported. Session Management service and PCRF- Core service send all the relevant information to Binding service asynchronously.

In Policy, Diameter Gateway should have a converged mode, where:
  • Diameter Gateway connects to PCRF-Core
  • Diameter Gateway also accepts a connection from Diameter Connector
In Converged mode of Diameter Gateway,
  • All Diameter Applications except Rx are routed to PCRF-Core.
  • For Rx messages, Diameter Gateway queries (asynchronously) Binding Service and based on the response, it forwards AF requests to either PCRF-Core or SM Service (via. Diameter Connector).

Configuration

In Helm Charts, you must configure diamgateway.envGatewayMode as converged in custom-values.yaml file, and the child helm files for Diameter-Gateway, Query-Service, and so on need to refer to this environment variable. This is mainly for performance considerations so that Diameter-Gateway and Query Service need not to query Binding service for the binding information. For more information on diamgateway.envGatewayMode, see Oracle Communications Cloud Native Core Policy Installation, Upgrade and Fault Recovery Guide.

Depending on the value of the following parameters, binding service or BSF is queried:
  • bindingEnable in custom-values.yaml file
  • Binding Operation in Oracle Communications Cloud Native Core, Cloud Native Configuration Console (CNC Console)
Behaviour is as follows:
  • When both the configuration variables are set to true, binding service is queried.
  • When the bindingEnable parameter is set to true and the Binding Operation is configured to false, BSF is queried.
  • When the bindingEnable parameter is set to false and the Binding Operation is configured to true, neither BSF nor binding service is queried.
  • When both the configuration variables are set to false, neither BSF nor binding service is queried.

Binding Service Truth table when receiving AAR-I

Following truth table is considered by Binding Service for finding the context owner of a session.

Priority: Priority indicates that attributes if specified in the message is considered as per the following priority from high to low. For example, IPv6 has higher priority indicates that if IPv6 is present, then only IPv6 binding is considered and corresponding context-owner information is returned otherwise next attribute priority is considered.
  • IPv6
  • IPv4 + APN/DNN+SNSSAI
  • IPv4
  • IMSI
  • MSISDN

Table 3-3 Binding Service Truth table when receiving AAR-I

S.No. Message IPv6 IPv4 APN/DNN+SNSSAI IP Domain ID GPSI/MSISDN SUPI/IMSI Binding Lookup Query
1 Gx-CCR I/SM Association P (Present in Gx CCR-I/N7 Sm create message) P P P P P IPv6
AAR - I P (Present in Rx AAR-I message) P P P    
2 Gx-CCRI/SM Association P P P P P P IPv4 + APN/(DNN+SNSSAI) + IP Domain ID
AAR - I   P P P    
3 Gx-CCRI/SM Association P P P P P P IPv4 (DNN and IP Domain ID won't be considered)
AAR - I   P     P P
4 Gx-CCRI/SM Association P P P   P P IPv4 + APN/(DNN+SNSSAI) + IP Domain IDIF No Records found (Would consider IP Domain ID as BLANK in Gx Session) => Not in the scope of PI-C (Need to enhance DB API for the same)
AAR - I   P P P    
Binding Service Truth table when receiving AAR-U

Table 3-4 Binding Service Truth table when receiving AAR-U

S.No. Message IPv6/IPv4 APN/DNN+SNSAAI Session ID Binding Lookup Query
1 AAR-U P P P Session-ID
2 AAR-U P P P IP Address + APN/DNN+SNSSAI (If Rx Session Id not Found in Binding DB)
3 AAR-U P   P IP Address (If Rx Session Id not Found in Binding DB)

Note:

  • IP-CAN-Session Not available message is displayed when there is no suitable binding found in the binding service.
  • UNABLE-TO-COMPLY message is displayed when request times out at Diameter Gateway.

Remote Cleanup of PDU Sessions when PDU Session Exceeds Limiting Number

In the event where the number of SM sessions per DNN exceeds the configured "Max sessions per DNN" value for a Binding service, Binding service triggers remote or local cleanup request towards SM service when the number of SM session per DNN exceeds the configured Max sessions per DNN value.

The deletion of stale binding session is controlled by a configurable binding flag. The binding flag "Max Session Cleanup Mode" can be set to either "Local" or "Remote" value.
  • If the flag is set to "Local" PCF does not send terminate notification to SMF and deletes the session locally.
  • If the flag is set to "Remote" PCF initiates terminate notification request toward SMF. PCF starts a timer to wait for SMF to send delete request to PCF based on Force Delete On Expiry of Wait Timer flag.
    • If delete request is received before timer expiry then deletes the session
    • If timer expires and delete request is not received PCF deletes the session

The timer value is configured in the PCF SM service Advanced setting page in CNC Console. Its default value is 30000 millisecond. This is considered only if "Remote" is selected in Binding service configuration.

On failure of PCF terminate notification request to SMF, PCF deletes the session based on the "Force delete on Error" flag.

3.5 Notifier Service

Policy Notifier service is an optional service that allows Policy to send notifications to the subscribers about their current data usage. This service is independent of deployment mode and can be enabled in all the supported deployment modes.

As part of subscriber quota management and based on the defined policies, the user is notified about their current usage at various levels. For example, when a user consumes 80% of the granted quota, a notification must be sent to notify the user about its usage. Similarly, when they reach or exceed the threshold, a notification must be sent informing the user about reduced quality of service or even suspension of service. With the Notifier service, Policy can send either HTTP notification or short messages (SMS) using SMPP to subscribers, based on the policies configured by operators, through an external notification server.

Note:

In the current release, Policy supports subscriber notification only using HTTP and SMPP protocols.

This feature is supported only for PCRF-Core call flows.

The following diagram shows how Notifier Service fetches configurations from Config service and on receiving notification request from PRE, sends out the notification to the subscriber via external notification server:

Figure 3-4 High Level Notifier Service Diagram

High Level Notifier Service Diagram

Call Flow

The following call flow diagram describes the notification call flow for SM service. As seen in the diagram, SM service sends a request to PRE that runs any given active policy and as a result triggers notification request to Notifier Service. Then, Notifier service sends a notification request towards the configured external server. On receiving success response, Notifier service sends the response to PRE, which in turn sends it to SM service.

Figure 3-5 Notifier Call Flow for SM Service

Notifier Call Flow for SM Service

Enable

By default, the Notifier service is disabled. Thus, the user cannot access the configurations from GUI.

To enable the service, set the following parameter to true at the time of installing or upgrading Policy:
notifierServiceEnable

For information on how to set the parameter value, see Oracle Communications Cloud Native Core Policy Installation, Upgrade and Fault Recovery Guide.

Configure

Once the service is enabled, you should be able to see Notifier service menu under the Service Configurations on CNC Console for Policy.

To allow flexibility, operators can configure an HTTP request message including the destination, content, and other attributes. The static content of the notification is retrieved from Policy variables and Policy table.

For information on how to configure Notifier service, see Configuring Notifier Service.

Logs

Policy publishes logs for all Hypertext Transfer Protocol (HTTP) messages sent via Policy action.

3.6 NWDAF Agent

Policy integrates with Network Data Analytics Function (NWDAF) service to get analytics information. NWDAF can provide various analytics data, which PCF can consume and use to make policy decisions. For more information analytics data, see Oracle Communications Networks Data Analytics Function User Guide.

Note:

Policy 22.4.0 includes phase one implementation of Policy integration with NWDAF for testing purposes.

It also queries Network Repository Function (NRF) client for fetching NWDAF information. For NWDAF, autonomous NRF discovery and static configuration is only supported, on-demand is not yet supported. For more information on autonomously discovered NF profiles for NWDAF, see Discovered NF Instances.

A 5G network contains a vast number of devices and sensors generating an enormous amount of data. The NWDAF Agent allows the Communications Service Providers (CSPs) to efficiently monitor, manage, automate, and optimize their network operations by the data collected and analytics generated across the network. It also helps the CSPs in achieving the operational efficiency and provides an enhanced service experience. Currently, NWDAF Agent supports slice load level analytics as part of the analytics data that is provided from NWDAF.

The following diagram describes the interaction with NWDAF Agent and Policy:

Figure 3-6 Interaction between Policy and NWDAF Agent

Interaction between CNC Policy and NWDAF Agent
PCF supports the following 3GPP defined services for NWDAF Agent:

Table 3-5 3GPP defined services for NWDAF Agent

Service Operation Name Description Initiated By Resource URI HTTP Method or Custom Operation
GET Get NWDAF Agent Service configuration AM {apiRoot}/oc-cnpolicy-configuration/v1/services/nwdafAgent GET
PUT Update NWDAF Agent Service configuration AM {apiRoot}/oc-cnpolicy-configuration/v1/services/nwdafAgent PUT
GET Export NWDAF Agent Service configuration AM {apiRoot}/oc-cnpolicy-configuration/v1/services/nwdafAgent/export GET
POST Import NWDAF Agent Service configuration AM {apiRoot}/oc-cnpolicy-configuration/v1/services/nwdafAgent/import POST

For information on parameters of the 3GPP defined services for NWDAF Agent , see Oracle Communications Cloud Native Core, Converged Policy REST API Specification Guide.

Enable

By default, the NWDAF Agent is disabled. Thus, the user cannot access the configurations from GUI.

To enable the service, set the following parameter to true at the time of installing or upgrading Policy:
nwdafAgentServiceEnable

For information on how to set the parameter value, see Oracle Communications Cloud Native Core Policy Installation, Upgrade and Fault Recovery Guide.

Configure

Once the service is enabled, you should be able to see NWDAF Agent service menu under the Service Configurations on CNC Console for Policy.

For information on how to configure NWDAF Agent, see Configuring NWDAF Agent.

After the configuration you can use blockly to see the analytics data. For more information, see "Public Category" section in Oracle Communications Cloud Native Core, Converged Policy Design Guide.

3.7 PCRF Core Service

The Policy solution supports the Gx reference point for provisioning and removal of PCC rules from the PCRF to the PCEF and the transmission of traffic plane events from PCEF to PCRF.

PCRF Core Service supports the following:
  • IP-CAN session Establishment, Modification, and Termination Support
  • Install, Modify, or Remove Predefined PCC rules
  • Install, Modify, or Remove Dynamic PCC rules
  • Gate function
  • Charging related information support
  • Integration with AF (over Rx)
  • Presence Area Reporting (PRA) Support
  • Time of the day procedures
  • Sponsored data connectivity support
  • NSA related enhancements for QoS (Quality of Service)
  • UE IPv4, IPv6, and IPv4v6 support

For information about configuring PCRF Core service, see Settings.

Configurations to route messages to OCS or UDR through Diameter Gateway

Note:

Configurations described in this section are required when PCRF Core uses UDR or OCS as a datasource.
When CNC Policy is deployed in cnPCRF or converged mode, PCRF Core service does not connect directly to OCS or UDR. Instead, PCRF Core establishes a connection with Diameter gateway - the front end for any Diameter traffic, and routing of messages destined for OCS/UDR has to go through the latter.
To allow PCRF Core to communicate with UDR and OCS through Diameter gateway, perform the following Diameter peer configurations:
  1. Configure the OCS as OCS peer by putting the following values on the Create Peer Node page:

    Table 3-6 Peer Node Configuration

    Field Name Description
    Name Name of the peer node.

    Example value: ocs
    Type Type of the peer node.

    Example value: ocs
    Reconnect Limit (sec) The reconnect limit. This value must be configured as the Diameter peer configuration.

    Example value: 10
    Initiate Connection Set to true to initiate the connection with peer node.
    Port OCS peer port detail.

    Example value: 8007
    Host The OCS host IP/FQDN.
    Realm The realm detail of the OCS peer.

    Example value: oracle.com
    Identity The identity detail of the OCS peer.

    Example value: ocs

    For more information, see Peer Nodes.

  2. Configure the DataSource by providing the following values on Create Data Source page:

    Table 3-7 Data Source Configuration

    Field Name Description
    Name Data source name.

    Example value: ocs
    Description Details about the data source.
    Type Data source type.

    Example value: Sy
    admin state Enable this switch.
    Realm The realm detail of the data source.
    Role Role of the data source.

    Example value: Primary
    Timer Profile Timer profile for the data source.
    Primary Server The primary data source server details.
    For Primary data source server, enter the following values:
    • Identity: Primary server identity.

      Example value: oc-diam-gateway

    • Addr: Load balancer IP of Diameter gateway.
    • Port: Port detail.

    For more information, see Data Sources.

  3. Configure the static routing table, using the configurations given in the following table:

    Table 3-8 Diameter Route Table Configuration

    Field Name Description
    Priority Set the priority value.

    Example value: 1
    Name Name of the route.

    Example value: ocsroute
    Type Route type

    Example value: Realm
    Realms The realm detail of the route.

    Example value: oracle.com
    Application ID Example value: Sy
    Server Identifier

    The value of this field is reference of Diameter peer configuration name.

    Example value: ocs

    For more information, see Routing Table.

3.8 Policy Data Source (PDS) Service

Policy Data Source (PDS) Service

Policy Data Source Service (PDS) is an intermediate layer which interfaces Core Services (SM/AM/UE/PCRF-Core) with the protocol specific connector layers (UDR/CHF/LDAP Connectors). PDS also holds the subscriber information in its database when a new session gets established for a given subscriber and cleans-up the information when the last session termination happens. PDS is also responsible for storing the Subscriber State Variables except session level in its database and provides these variable information across multiple core services which requests the information.

You could define the workflows for PDS and the workflow would define the flow of request processing. This workflow is internal to the PDS project and should consult with engineering team for any update.

The following figure depicts the PDS architecture:

PDS overview

For configuring PDS service, see PDS Settings.

Note:

Currently, PDS supports SUPI/GPSI as the search key. It does not support NAI as the search key.

UDR Connector- UDR Connector is a protocol specific layer which converts the request send by PDS to nUDR specific format and forwards to real UDR for subscription information. It also provides an ability to subscribe for profile change at UDR.

CHF Connector – CHF Connector is a protocol specific layer which converts the request send by PDS to nCHF specific format and forwards to actual CHF for fetching PolicyCounter Information. As per the standards, it automatically subscribes for profile change at CHF.

For configuring the UDR or CHF connector, see PCF User Connector.

3.9 Session Management Service

Oracle Communications Policy Control Function (PCF) implements policy control for session management for service data flows. PCF implements the N7 interface to trigger the Session Management (SM) policies towards Session Management Function (SMF). SMF controls the User Plane Function (UPF) . It translates policies received from PCF to a set of directives or information that can be understood by UPF and then forwards it to the UPF.

The following figure illustrates the communication between PCF and SMF over the N7 interface.

Figure 3-7 Communication between PCF and SMF over N7

SM with SMF

Session Management Service supports the following:

  • Enforcement control of policy decisions related to QoS, charging, gating, service flow detection, packet routing and forwarding, and traffic usage reporting.
  • Enforcement of QoS, charging, gating, service flow detection, packet routing and forwarding, and traffic accounting and reporting policy decisions can be distributed among the UPF, Radio Access Network (RAN), and User Equipment (UE) depending on the policy type.
  • Support for UE IPv4, IPv6, and IPv4v6

Oracle Communications PCF supports the following 3GPP defined services for Session Management:

Table 3-9 Session Management Services

Service Operation Name Description Initiated By Resource URI HTTP Method
Npcf_SMPolicyControl_Create Request to create an SM Policy Association with the PCF to receive the policy for a PDU session SMF {apiRoot}/npcf-smpolicycontrol/v1/sm-policies POST
Npcf_SMPolicyControl_Delete Request to delete the SM Policy Association and the associated resources SMF {apiRoot}/npcf-smpolicycontrol/v1/sm-policies/{smPolicyId}/delete POST
Npcf_SMPolicyControl_Update Request to update the SM Policy association with the PCF to receive the updated policy when Policy Control Request Trigger condition is met SMF {apiRoot}/npcf-smpolicycontrol/v1/sm-policies/{smPolicyId}/update POST
Npcf_SMPolicyControl_UpdateNotify Update and/or delete the PCC rule(s) PDU session related policy context at the SMF and Policy Control Request Trigger information PCF

{Notification URI}/update

{Notification URI}/terminate

POST

For configuring PCF Session Management service, see PCF Session Management.

3.10 UE Policy Service

Policy implements PCF UE Policy service to provision the UE policies, determined by PCF, to UE through AMF over the N15 interface.

The following figure describes the communication between PCF and AMF over the N15 interface:

Figure 3-8 PCF-AMF communication

PCF communicating to UE through AMF over N15 interface

PCF UE Policy service performs the following functions:

  • Transfering UE Route Selection Policies (URSP) rules to UE
  • Establishing the UE Policy Association requested by the NF service consumer
  • Deleting the UE Policy Association requested by the NF service consumer
  • Defining and delivering URSP message to UE via AMF using N1N2 message

Policy supports the following 3GPP defined service operations for the PCF UE Policy service:

Table 3-10 PCF UE Policy Services

Service Operation Name Description Initiated By Resource URI HTTP Method
Npcf_UEPolicyControl_Create Creates a UE Policy Association AMF {apiRoot}/npcf-ue-policy-control/v1/policies/ POST
Npcf_UEPolicyControl_Update Provides means for the NF consumer, that is, AMF to update an existing UE Policy association.

AMF invokes this procedure only if PCF has subscribed to  location change trigger.

 AMF {apiRoot}/npcf-ue-policy-control/v1/policies/{polAssoId} POST
Npcf_UEPolicyControl_UpdateNotify Notifies NF consumer about the update made to policy control request trigger(s) by PCF PCF {Notification URI} POST
Npcf_UEPolicyControl_Delete Provides means for the NF consumer to delete the UE Policy Association AMF {apiRoot}/npcf-ue-policy-control/v1/policies/{polAssoId} DELETE
N1N2MessageSubscribe Creates a subscription for N1 Message Transfer AMF {apiRoot}/namf-comm/<apiVersion>/ue-contexts/{ueContextId}/n1-n2-messages/subscriptions POST
N1N2MessageUnSubscribe Deletes an existing subscription for N1 Message Transfer AMF {apiRoot}/namf-comm/<apiVersion>/ue-contexts/{ueContextId}/n1-n2-messages/subscriptions/{subscriptionId} DELETE
N1N2MessageTransfer Transfers an N1 message (NAS message) to be delivered to the UE PCF {apiRoot}/namf-comm/<apiVersion>/ue-contexts/{ueContextId}/n1-n2-messages POST
N1N2MessageNotify Indicates status of an N1N2 Message Transfer AMF {apiRoot}/v1/ue-contexts/{ueContextId}/n1-n2-messages/notify POST
N1N2MessageFailureNotify Indicates that N1N2 message has failed to deliver to UE AMF {apiRoot}/v1/ue-contexts/{ueContextId}/n1-n2-messages/txfailure-notify POST
For information on how to configure PCF UE Policy, see PCF UE Policy Service.

3.10.1 UE Policy Enhancements

UE Service in PCF is responsible for handling the User Equipment (UE) related procedures as described in 3GPP TS 29.525. This primarily includes delivery of UE Route Selection Policy (URSP) rules to the UE. URSP rules can be locally configured at PCF. The current implementation of PCF only supports local configuration of URSP rules, however UDR may send the UPSI codes to indicate to PCF which rules to deliver. PCF delivers URSP rules to UE via AMF on the N15 interface. PCF consumes the Namf-comm service provided (produced) by AMF on the N15 Namf interface.

AMF Selection for Namf-comm Subscription

Policy discovers the producer AMFs from NRF either using GUAMI or using the AMF Set ID and the AMF Region ID.

You can set the AMF Discovery criteria using CNC console.
  1. Log in to CNC Console as an Administrator.
  2. Navigate to PCF UE Policy page under Policy.
  3. Under AMF section, set the value of AMF Discovery criteria to either GUAMI or SetID and RegionID.

    • By default, the value of AMF Discovery criteria parameter is set to GUAMI.

      With this default configuration, Policy sends GUAMI to NRF to receive the list of AMF profiles. From the list of AMF profiles received from NRF, Policy selects one of the AMFs as the producer AMF.

    • If the value of AMF Discovery criteria parameter is set to SetID and RegionID, Policy extracts the AMF SetID and AMF RegionID from GUAMI and uses these IDs to discover the producer AMF as explained below.

Note:

GUAMI is the default configuration for all existing deployments. With this default configuration, the upgrade support for existing customers will also be acheived and any new UEPolicyAssociation Request will not impact the existing behavior of AMF discovery based on GUAMI.

Figure 3-9 Selecting Producer AMF using AMF SetID and AMF Region ID


This call flow shows how Policy selects the producer AMF for the next subscription request using AMF SetID and AMF RegionID extracted from GUAMI.

  1. Policy receives UEPolicyAssociationRequest from Consumer AMF.

  2. If AMF Discovery criteria is set to SetID and RegionID, Policy parses the GUAMI to fetch the AMF SetID and AMF RegionID.

    Figure 3-10 Parsing GUAMI


    This diagram depicts how Policy parses the GUAMI to extract the AMF SetId and AMF RegionID

    Sample GUAMI:

    "guami": {
        "plmnId": {
            "mcc": "450",
            "mnc": "05"
        },
        "amfId": "010041"
    }

    In the above example, Policy extracts the following details from GUAMI:

    amfid = 010041

    AMF RegionID (first 8 bits): 01

    AMF SetID (next 10 bits): 001

  3. Policy includes the extracted AMF SetID and AMF RegionID in a query parameter (amf-set-id, amf-region-id) and queries the NrfClientConnector through NRF discovery URI /nnrf-disc/v1/nf-instances.
  4. Policy receives a list of AMF Profiles as a response from NRF.
  5. Policy selects the target AMF from the list of AMF Profiles by matching GUAMI received in UEPolicyAssociationRequest with the GUAMI(s) present in the list of AMFProfiles returned from NRF.
    1. If the above match results in a single AMF instance, Policy uses that AMF for the Subscription Request required for UE Policy Transfer.
    2. If there is no match, Policy applies the filter for Priority/Capacity Load to all the GUAMI's received in AMFProfile to identify the relevant AMF.
    3. If there are more than one AMF profiles, Policy applies the filter for Priority/Capacity Load to select the relevant AMF.
  6. Policy sends a N1N2MessageSubscribe to the selected producer AMF and receives a response.
  7. Policy responds the consumer AMF with a 201 message.

UE Policy Delivery Rules

The following rules are defined in 3GPP TS 29.525 with respect to UE Policy (URSP) delivery:
  • The PCF shall only send "MANAGE UE POLICY COMMAND" messages below a predefined size limit.
  • The PCF may deliver the UE policy to the UE in several "MANAGE UE POLICY COMMAND" messages.

The UE policy is divided into policy sections for fragmented delivery and subsequent partial updates of UE policies. Such policy sections may be predefined in the PCF, may be retrieved by the PCF from the UDR as specified in 3GPP TS 29.519, or maybe dynamically generated by the PCF, but shall comply with the rules below. If the predefined size limit is observed, the PCF may combine several policy sections into one "MANAGE UE POLICY COMMAND" message.

The following rules apply for policy sections:
  • The size must be below the predefined size limit.
  • The policy section must contain complete URSP rule(s), and no fractions of such rules.
  • The policy section may contain a small number of policies, for example, URSP rule(s), to ease a subsequent partial update of UE policies.
  • A single PLMN should provide the entire content of a policy section.
Each UE policy section is identified by a UE policy section identifier (UPSI). The UPSI is composed of two parts:
  1. The PLMN ID part containing the PLMN ID for the PLMN of the PCF which provides the UE policies.
  2. An UE policy section code (UPSC) containing a unique value within the PLMN selected by the PCF.

Fragmented URSP Delivery

The PCF may deliver the UE policy to the UE in several "MANAGE UE POLICY COMMAND" messages.

After sending a "MANAGE UE POLICY COMMAND" message, the PCF shall wait for a related confirmation in a "MANAGE UE POLICY COMPLETE" message or failure indication in a "MANAGE UE POLICY COMMAND REJECT" message. When no such message is received until the expiry of a supervision timer specified in Annexure D of 3GPP TS 24.501, or when a failure indication is received, the PCF should resend related instructions for the policy sections.

When UE Policy is installed with fragmentation, policy table do not support URSPs installation. Policy supports this feature implementation, by providing URSP data type and URSP List data type as column in the policy table. On the Policy Console, this column data types is added in the Create Policy Table page. Two Blocklys namely, URSP List data type and URSP data type is used by the create Policy table blocks.

For detailed information about configuring the policy blocks for UE Policy service type, see Oracle Communication Cloud Native Core, Converged Policy Design Guide.

Manage UE Policy Command Reject

In case of PCF receiving "MANAGE UE POLICY COMMAND REJECT", policy tries to re-transmit the N1N2Message for all the rejected UPSIs only. PCF will decode UE Policy Manage Command Reject and will resend the UPSIs as part of UE Policy Manage Command which were rejected by UE. This is done by setting the label On UE Policy Command Reject to Re-Transmit Rejected UPSIs value from the drop down list in the CNC Console.

Note:

AMF notifying REJECT messages to PCF-UE with encoded rejected UPSIs should adhere to specification specified under Annexure D of 3GPP TS 24.501.

PCF handles the following N1N2Message transfer failures:
  • On T 3501 Timer Expiry
  • On Transaction Failure Notification
  • On UE Policy Command Reject

Using CNC Console N1 Message Retransmission Settings group in PCF UE Policy page, the user can configure the UEPolicy maximum number of retransmissions and the actions to be taken to handle each failures separately.

For UE Policy configurations on CNC Console, see PCF UE Policy Service

Support of policy evaluation on AMF Notification on N1Notify and N1N2NotifyFailure

Currently, PCF does not evaluate Policies after N1 message notify or N1N2Transfer failure notification flow in PCF UE service. Thus PCF does not allow the user to take action dynamically and allows only static action such as retransmit, skip the fragment, or ignore.

This feature enables the PCF user to write policies using Policy blockly. PCF evaluates the policies and takes actions after receiving N1Message Notify messages with MANAGE UE POLICY COMPLETE or MANAGE UE POLICY COMMAND REJECT messages from AMF , when UPSI's are installed. PCF UE service decodes the N1 Notify message that it receives from AMF during the rejection of URSP's by UE.

The subscription and transfer process are managed by the retry mechanism. In the notification flow, when the UE service receives a notification from AMF (N1MessageNotification), PRE is included both in the event of success or failure, allowing for subsequent installation attempts.
  • In case of MANAGE UE POLICY COMPLETE message, PCF UE does not send the list of rejected UPSIs or URSPs since the transaction was completed successfully.
  • In case of MANAGE UE POLICY COMMAND REJECT message, PCF UE sends the list of rejected UPSIs and URSPs to the PRE so that policy evaluation can be done using this information.
  • In case of N1N2MessageTransferFailure message, PCF UE does not send the list of rejected UPSIs or URSPs as this is the a HTTP error with AMF and there is no information about rejected UPSIs or URSPS. PCF UE sends the cause of the failure to PRE.

Note:

The blockly Policy created by considering the course of action that needs to be taken in the event of an error, supersedes any configurations set in N1 Message Retransmission Settings of the PCF UE Policy page in CNC Console.

Figure 3-11 UE and PRE interaction


UE and PRE interaction

The policy writer can check if the message is "MANAGE UE POLICY COMPLETE" and then take actions like:
  • Write successfully the installed UPSI as a string value in VSA and update it to UDR.
  • Define remote state variables, set values to variables and write in VSA and update it to UDR.
The policy writer can check if the message is "MANAGE UE POLICY COMMAND REJECT" and then take actions like:
    • Write successfully the installed UPSI as a string value in VSA and update it to UDR.
    • Retransmit the failed UPSIs or new UPSIs, based on conditions like PLMN, SUPI, the failed UPSIs.
    • Skip the retransmit of UPSIs, based on conditions like PLMN, SUPI, the failed UPSIs.
    • Abort the transaction of transferring the UEPolicy in N1N2Message based on conditions like PLMN, SUPI, the failed UPSIs.
    • Define remote variables other than UPSI, set values to variables and write in VSA and update it to UDR.

Support of policy evaluation on T3501 Timer Expiry

Currently, PCF does not evaluate Policies after T 3501 timer expiry in PCF UE service. Thus PCF does not allow the user to take action dynamically and allows only static action present at CNC Console such as retransmit, skip the fragment, or abort. This feature enables the PCF user to write policies using Policy blockly on T3501 Timer Expiry. For more information, see "PCF UE Policy" section in Oracle Communications Cloud Native Core, Converged Policy Design Guide.

Deletion of URSP Rules

UE service allows deletion of URSP rule(s) in subsequent call flows that were previously sent over N1N2 NAS message delivery. The UPSI containers are updated and resent with the same UE Policy Section Code (UPSC) code and PLMN ID. An UPSI if being retransmitted because of URSP deletion will not further fragment the remaining URSPs within that UPSI as there is change in the size of the UPSI. The UPSI container honors the precedence of URSP rules while delivering in multiple fragments.

Note:

The operator can perform Install and Remove URSP rules in the same policy execution cycle.

Managing UE Policy Enhancements

This section explains the procedure to enable and configure the feature.

Enable

This forms Policy applications core feature functionality. You do not need to enable or disable this feature.

Configure Using CNC Console

Perform the feature configurations in CNC Console as described in PCF UE Policy Service section.

Configure Using REST API

Perform the feature configurations as described in "UE Policy" section in Oracle Communications Cloud Native Core, Converged Policy REST Specification Document

Configure Using Blockly

PCF UE services blockly's are described "UE Policy Blocks" section in Oracle Communications Cloud Native Core, Converged Policy Design Guide.

Observability

Metrics:

Policy provides UE Policy metrics as described in UE Service Metrics section.

Maintain

If you encounter alerts at system or application levels, see Alerts section for resolution steps.

In case the alerts still persist, perform the following:
  • Collect the logs: For more information on how to collect logs, see Oracle Communications Cloud Native Core, Converged Policy Troubleshooting Guide.
  • Raise a service request: See My Oracle Support for more information on how to raise a service request.

3.11 Usage Monitoring Service

Policy Usage Monitoring is an internal service that interacts with Policy PRE service to get usage monitoring related Policy decisions and sends notifications to the subscribers about their current data usage. This service is independent of deployment mode and can be enabled in all the supported deployment modes.

With the introduction of Usage Monitoring service, Policy can control usage monitoring support for a PDU Session. Usage is defined as either volume or time of user plane traffic.

Policy receives usage monitoring related information per APN and UE from the UDR, i.e. the overall amount of allowed resources (based either on traffic volume and/or traffic time) that are to be monitored for the sessions of a user, together with the corresponding remaining allowed usage related information. In addition, usage monitoring related information for Monitoring key(s) per APN and UE may also be received from the UDR, together with the corresponding remaining allowed usage related information. For the purpose of usage monitoring control Policy requests the Usage report trigger and provides the necessary usage threshold(s), either volume threshold, time threshold, or both volume threshold and time threshold, upon which the PGW reports to Policy. Policy may request a usage report from the PGW.

Once Policy receives a usage report from the PGW, it deducts the value of the usage report from the remaining allowed usage for that APN.

Enable

By default, the Usage Monitoring service is disabled.

To enable the service, set the following parameter to true at the time of installing or upgrading Policy:
usageMonEnable

For information on how to set the parameter value, see Oracle Communications Cloud Native Core, Converged Policy Installation, Upgrade, and Fault Recovery Guide.

Note:

To enable Usage Monitoring for PCRF, the deployment must have a 5G UDR as user data for Usage Monitoring is read from 5G UDR only.

Configure

Once the service is enabled, you can configure the Usage Monitoring service under the Service Configurations on CNC Console for Policy.

For information on how to configure Usage Monitoring service, see Configuring Usage Monitoring.