4 Policy Features

These section explains Oracle Communications Cloud Native Core, Converged Policy features.

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.

4.1 Optimizing PolicyDS Database Query With Configurable UE IDs

When PDS receives a request from any of the microservices, it queries the PolicyDS database to retrieve the details.

PolicyDS database includes:

• PDSProfile: Contains PDS Profile information that includes subscriber ID related information such as SUPI and GPSI.
• PDSSubscriber: Contains subscriber information.

Policy supports configuring the query on PolicyDS database based on single UE ID, multi UE IDs or based on a specific preference using the subscriber IDs.

Type of search to query and view details from PolicyDS database

Depending on the selected type of search, single UE ID, multi UE IDs, or preferential query, PDS queries data from PDSProfile and PDSSubscriber.

If the selected type of search is single UE ID, PDS queries all the details from PDSSubscriber.

If the selected type of search is multi UE IDs, or preferential query, PDS queries the details from PDSProfile.

The details of current and historical type of search configurations on various site is managed in pdssettings table.

PDS refers to pdssettings table to identify the siteID's and the configuration in each site.

Single UE ID Based Query

PDS query on PolicyDS database using Single UE ID approach allows to query PDSSubscriber using a primary key combination.

The primary key can be SUPI, GPSI or a combination of SUPI and GPSI. There must be at least a single SUPI or a GPSI for a given subscriber.

Note:

There cannot be multiple SUPIs for one GPSI or multiple GPSIs associated with one SUPI.

The primary key combination for Single UE ID based search can be modified. That is, primary key can be changed from SUPI to GPSI or from GPSI to SUPI.

On selecting the required primary key combination, the requests to PDS is expected to mandatorily contain that ID. Otherwise, the request is rejected with 400 HTTP error code. For example, when the primary key combination is SUPI, the request to PDS must contain a valid SUPI value. Otherwise, the request is rejected with 400 HTTP error code. For more information on primary key combination, see PDS UE ID Configuration.

Note:

This validation is not applicable in case of PDS notification call flows.

Multi UE ID Based Query

Multi UE ID based query is the default type of querying PolicyDS database when the type of search is not selected.

Multi UE ID indicates that there can be multiple SUPIs for one GPSI or multiple GPSIs associated with one SUPI.

Note:

Multi UE ID based search query uses OR criteria and the search time taken is higher.

Preferential Query

Preferential query allows to specify a key preference for PDS search query used to look up for a pdsprofile record.

Preferential query allows to specify a list of PDS search indexes that can be selected in any order of preference. The search order can be:

• SUPI: pdsprofile is queried based on the given SUPI value.
• GPSI: pdsprofile is queried based on the given GPSI value.
• SUPI, GPSI: pdsprofile is queried first based on the given SUPI value and then based on the given GPSI value.
• GPSI, SUPI: pdsprofile is queried first based on the given GPSI value and then based on the given SUPI value.

Note:

For notification and audit query the preference order is not considered.

Migration of database records

Policy allows to switch from one type of search to the other type.

For example, the type of search can be switched from Multi UE ID based search or Preferential search to Single UE ID based search.

When the type of search is switched, the database records in PDSProfile and PDSSubscriber tables are updated accordingly in a lazy manner. For example, if search type is switched from Multi UE ID based search or Preferential search to Single UE ID based search, the records in PDSSubscriber are updated with the information present in PDSProfile table, provided there is unique SPI/GPSI combination associated to that profile.

CNC Console for Policy displays if the migration of records is in progress. If so, how many records are still to be migrated (that is, total number of non-migrated records). For more information, see PDS UE ID Configuration.

Important:

When the type of query is switched from one type of search to another type, the dashboards that are used to identify unique subscriber count will be affected.

Note:

Whenever PDS queries PolicyDS database, it stores the results in cache. If a PolicyDS database query is triggered within the cached period, PDS displays the results stored in the cache. PDS does not query the database every time the query is triggered.

Important:

While switching from one type of search to the other, (for example, while switching from Multi UE ID based search or Preferential search to Single UE ID based search or vice versa) make sure that the migration of records is complete.

Note:

In case of multi-site deployment, Policy supports displaying the migration status at each of the sites.

To disable the migration status for one of the sites, all the sites should be in migration enabled state with the updated configuration. Otherwise, the migration status cannot be disabled.

Migration should be disabled in all the sites almost simultaneously to avoid stale subscriptions being left in PDS.

Migration from Single UE ID to Single UE ID with different primary key combinations should be done in all sites almost simultaneously to avoid stale subscription being left in PDS.

Sample data migration scenario

Note:

The switching of the search types and the migration of PDS data is supported only in case of CREATE and audit requests.

Whenever PDS receives a request from any of the PCF microservices such as SM service, AM service, or UE Policy service, PDS queries its PolicyDS database to retrieve the existing data based on the configured query type such as Multi UE ID or Single UE ID based search. In case, there is any change in the query type, PDS uses the latest query type to search for the data.

Here is a sample scenario when PDS receives a CREATE request for a subscriber for which PDS updates the pdsprofile details using a single UE ID query using SUPI.

PDS receives a CREATE request with SUPI= supi1 and GPSI=gpsi1 for the site Site1, and the query type is changed from Multi UE ID based search to Single UE ID based search using SUPI as the primary key. PDS queries the pdsprofile database for the given profileID having the given SUPI.

If there is no matching record found for the pdsprofileId with the given SUPI, PDS updates the SUPI, GPSI, and other profile details for the profileID in pdsprofile database.

PDS then queries the subscriber details in pdssubscriber database using the pdsprofileID. If there is a matching record found with the pdsprofileID, PDS updates the SUPI, GPSI, and other details of the profile corresponding to the subscriber (pdsuserID).

If there is no matching record found for the given pdsprofileID, PDS adds the new profile details for the subscriber based on pdsuserID.

It is mandatory to manually enable audit to support the migration.

When Audit service is performed on pdssubscriber database, it identifies the subscriber details (pdsuserIDs) that are deleted in pdssubscriber database. The corresponding profileIDs are then removed from the pdsprofile database.

Similarly, when Audit service is performed on pdsprofile database, it identifies the profileIDs that are deleted in pdsprofile database. The subscriber details in pdssubscriber database is then updated to remove the non existent pdsprofileID.

Managing Optimization of PolicyDS Database Query With Configurable UE IDs

This section describes how to enable and configure the feature using CNC Console and REST API.

Configure

Multi UE ID based search is the default type, if the type of search is not explicitly configured. The type of searching PolicyDS database can be configured either using CNC Console or using REST API.

Configure using CNC Console

To configure the UE ID based configuration using CNC Console, perform the configurations on PDS UE ID Configuration page under Service Configurations.

For more information, see PDS UE ID Configuration.

Configure using REST API

To configure the UE ID based configuration using REST API, configure the parameters for PDS UE ID Configuration Settings API.

For more information see, PDS UE ID Configuration Settings section in Oracle Communications Cloud Native Core, Converged Policy REST Specification Guide.

Observability

Metrics

occnp_db_processing_latency_seconds_count metric is used to monitor the UE ID based query on PolicyDS database.

For more information, see Policy DS Metrics.

The ENABLE_PDS_DB_HISTOGRAM_METRICS advanced settings key for PDS must be enabled to use occnp_db_processing_latency_seconds_count metric.

For more information on ENABLE_PDS_DB_HISTOGRAM_METRICS key, see PDS Settings.

Installation and Upgrade Impact

Upgrade impact:

• During installation/upgrade, UE ID configuration selected is validated before updating the pdssettings table.
• In case of duplicate configuration, a warn log is printed without any update to pdssettings database.
• Partition-based approach can be enabled only through the fresh installation
• In case of other invalid configuration (Site1 with Partition enabled and Site2 with Partition disabled and vice versa), a warn log is printed and the configuration updated in pdssettings database is the same as previous sites.

Logging

The following logs from PDS info are used to verify the type of search:

{"instant":{"epochSecond":1744551776,"nanoOfSecond":106606704},"thread":"boundedElastic-6","level":"DEBUG","loggerName":"ocpm.uds.policyds.util.PdsUserIdGeneratorUtil","message":"PdsUserId generated for SINGLE_UE_ID_PREFERENTIAL_SEARCH with primaryKeyCombination : SUPI
      is :imsi-450081000000001##0##fe7d992b-0541-4c7d-ab84-c6d70b1b0123","endOfBatch":false,"loggerFqcn":"org.apache.logging.slf4j.Log4jLogger","threadId":102,"threadPriority":5,"messageTimestamp":"2025-04-13T13:42:56.106+0000","ocLogId":"1744551775993_152_policy-occnp-ingress-gateway-f88679cd9-6j79l"}

The PDS logs display the type of search and also how the primary key is generated.

{"instant":{"epochSecond":1744551776,"nanoOfSecond":307685362},"thread":"boundedElastic-10","level":"DEBUG","loggerName":"ocpm.uds.policyds.db.helper.PdsSubscriberV2Helper","message":"Updating mode: 16768 in pdssubcriber for user id:
      imsi-450081000000001##1##fe7d992b-0541-4c7d-ab84-c6d70b1b0123","endOfBatch":true,"loggerFqcn":"org.apache.logging.slf4j.Log4jLogger","threadId":140,"threadPriority":5,"messageTimestamp":"2025-04-13T13:42:56.307+0000","ocLogId":"1744551775993_152_policy-occnp-ingress-gateway-f88679cd9-6j79l"}

Checkpoints

• Migration of records is not required when the type of search is switched between Multi UE ID search and Preferential search, as both these type of searches query pdsprofile and pdssubscriber tables.
• While switching to Single UE ID search, siteId can have a maximum of 80 characters when both SUPI and GPSI are used.
• The prerequisite for switching to Single UE ID search is that there should be multiple UE ID configurations. That is, one SUPI cannot have multiple GPSIs or one GPSI cannot have multiple SUPIs.
• All the sites should be upgraded to new release before modifying the PDS Settings configurations.
• In case of multi-site deployment, in order to disable the migration at one site, all the sites should be in migration enabled state with the updated configuration. Otherwise, migration at the specified site cannot be disabled.

  The following are the key points to remember while disabling the migration in any of the sites in a multi-site deployment:

  • Migration can be disabled at any of the sites, only if all the sites are using the same type of query. Migration can not be disabled at any one site if any of the sites are using a different query type.

    For example, in a three site deployment, if Single SUPI query is used in Site1 and Site3, while Multi UE ID query is used in Site2, migration can not be disabled in Site1 or Site3.

  • Query type can be changed at a site only if all the sites are using the same query type.

    For example, if Site1 and Site3 are using Single SUPI query and Site2 is using Multi UE ID query, type of query at Site1 or Site3 cannot be changed from Single SUPI query to Sinlge SUPI/GPSI until the type of query at Site2 is also changed to Single SUPI. When all the three sites are using Single SUPI query, query type can be changed to Single SUPI/GPSI or any other query type.

  • Migration from one query type to another is not allowed at one site when one of the other sites is using a different query type.

    For example, if Site1 is migrated from Single SUPI to Single SUPI/GPSI while Site2 and Site3 are still using Single SUPI, Site2 or Site3 cannot be migrated from Single SUPI to Mult UE ID type.

    Since Site1 is already migrated to Single SUPI/GPSI, Site2 and Site3 must also be migrated to Single SUPI/GPSI completely before attempting to migrate Site2 or Site3 to Multi UE ID type.

  • Migration at one site cannot be disabled, if the query type at that site is migrated to a different one while the other sites are yet to be migrated.

    For example, if Site1 is migrated from Single SUPI/GPSI to Multi UE ID while Site2 and Site3 are yet to be migrated from Single SUPI/GPSI to Multi UE ID, migration cannot be disabled at Site1.

    Migration at Site1 can not be disabled only after Site2 and Site3 are also migrated from Single SUPI/GPSI to Multi UE ID type.

• When a new site is added, by default the query type at that site will be in Multi UE ID mode. Suppose, the other sites are using a different query type, the new site should also be migrated to that query type.

  For example, while Site1 and Site2 are using Single SUPI query type, if a new site Site3 is added, the default query type at Site3 is Multi UE ID, which must be migrated to Single SUPI type as in Site1 and Site2.

• Migration should be disabled in all the sites almost simultaneously to avoid stale subscriptions being left in PDS.
• Migration from one Single UE ID search to another Single UE ID search with different primary key combination should be done in the all the sites almost simultaneously to avoid stale subscription being left in PDS.
• The value of SiteID field on PDS UE ID Configuration page in CNC Console should match with the actual siteIDs.
• When migration is disabled, any non migrated records can not be gracefully deleted if pdsprofile is deleted.
• A record can be deleted, if the configured primary key combination (UE ID) is not present in the record.
• Records in Pdsprofile are deleted once the migration is turned off in the subsequent audit notification for the pdsprofile table.
• Audit notification on Pdsprofile can not handle migration of the corresponding subscribers. Only the audit notification on pdssubscriber can handle the migration.
• Partition-based approach can be enabled only through the fresh installation.
• Configuration at all the sites must be the same. That is, if site1 is installed with a Multi UE ID configuration, then Site 2 should also be installed with a Multi UE ID configuration. Any other configuration apart from this will not be considered.
• If the configured primary key combination is not passed in the create request, the request is rejected with a 400 BAD request.
• If the UE ID passed in the UDR or CHF notification is the same as the primary key combination configured, the lookup can happen with the primary key combination only.
• The following are the key points to remember while migrating records from different combination of the query types:

  • Migration from Multi UE ID to Preferential search:

    If a migration from Multi UE ID based query to Preferential based query is attempted, if the preference order and the requested subscriber IDs are the same, there can be an improvement in the turn around of the search result.

    Migration of records depends on the preference order. Migration is applicable only if the query uses specific subscription based on preference order.

    For example, if the preference order is SUPI, S1:SUPI1-GPSI1 and S2:SUPI2-GPSI1 is treated as different subscribers. While S1:SUPI1-GPSI1 and S2:SUPI1-GPSI2 are for the same subscriber.

  • Migration from Preferential search to Multi UE ID search:

    If an attempt is made to migrate the type of query from Preferential based query to Multi UE ID based query, migration of records are not applicable if the records are migrated from pdsprofile database with query using a preference order to new query on pdsprofile database using SUPI or GPSI.

    Any combination of SUPI and GPSI if shared between subscribers are considered as one subscriber.

  • Migration from Single primary key search to Multi UE ID search:

    While migrating from Single primary key to Multi UE ID based query, if the migration is enabled, records are migrated from one single primary key based query on pdssubscriber to a new query on pdssubscriber.

    In single primary key, the primary key uniquely identifies the subscriber. For example, SUPI.

    Suppose, S1:SUPI1-GPSI1 and S2:SUPI2-GPSI1 is treated as different subscribers. While S1:SUPI1-GPSI1 and S2:SUPI1-GPSI2 are same subscribers.

    If the migration is not enabled, there is no migration of records.

    Any combination of SUPI and GPSI, if shared between subscribers is considered as one subscriber.

  • Migration from Single primary key search to Preferential search:

    In case of a migration from Single primary key based query to Preferential query, if the migration is enabled, migration of records depends on the preference order. Records are migrated from single primary key based search on pdssubscriber database to another primary key based search on pdssubscriber database.

    If the preference order is SUPI, the query must include at least one valid SUPI value.

    If the preference order is GPSI, the query must include at least one valid GPSI value.

    If the preference order is SUPI, GPSI, records are searched first based on the given SUPI value and then based on the given GPSI value. The query must include at least a valid SUPI or a valid GPSI value.

    If the preference order is GPSI, SUPI, records are searched first based on the given GPSI value and then based on the given SUPI value. The query must include at least a valid GPSI or a valid SUPI value.

    In single primary key, the primary key uniquely identifies the subscriber. For example, single SUPI.

    For example, S1:SUPI1-GPSI1 and S2:SUPI2-GPSI1 is treated as different subscribers. While S1:SUPI1-GPSI1 and S2:SUPI1-GPSI2 are same subscribers.

    If the migration is disabled, there is no migration of records.

    For example, if the preference order is SUPI, S1:SUPI1-GPSI1 and S2:SUPI2-GPSI1 is treated as different subscribers. While S1:SUPI1-GPSI1 and S2:SUPI1-GPSI2 are same subscribers.

  • Migration from Multi UE ID search to Single primary key search:

    While switching from Multi UE ID based query to Single primary key serach like Single SUPI or Single GPSI or a combination of SUPI and GPSI as primary key, if the migration is enabled, records are migrated from SUPI or GPSI based query on pdsprofile database to a new query using SUPI or GPSI on pdsprofile database.

    Any combination of SUPI and GPSI, if shared between subscribers is considered as one subscriber.

    If the migration is not enabled, there is no migration of records.

    SUPI or GPSI, or every combination of SUPI and GPSI is treated as a separate subscriber.

    For example if the migration is to a Single SUPI query, S1:SUPI1-GPSI1 and S2:SUPI2-GPSI1 are treated as different subscribers. While S1:SUPI1-GPSI1 and S2:SUPI1-GPSI2 are same subscribers.

    If the migration is to a combination of SUPI and GPSI as primary key, S1:SUPI1-GPSI1 and S2:SUPI2-GPSI1 is treated as different subscribers. While S1:SUPI1-GPSI1 and S2:SUPI1-GPSI2 are also different subscribers.

  • Migration from Preferential search to Single primary key search:

    While switching from Preferential search to Single primary key search such as Single SUPI or Single GPSI, or a combination of SUPI and GPSI as primary key, if the migration is enabled, records are migrated from SUPI or a GPSI or a combination of SUPI, GPSI based query on pdsprofile database to a new query using SUPI or GPSI on pdsprofile database.

    Any combination of SUPI and GPSI if shared between subscribers is considered as one subscriber.

    If the migration is not enabled, there is no migration of records.

    SUPI or GPSI, or every combination of SUPI and GPSI is treated as a separate subscriber.

    For example if the migration is to a Single SUPI query, S1:SUPI1-GPSI1 and S2:SUPI2-GPSI1 are treated as different subscribers. While S1:SUPI1-GPSI1 and S2:SUPI1-GPSI2 are same subscribers.

    If the migration is to a combination of SUPI and GPSI as primary key, S1:SUPI1-GPSI1 and S2:SUPI2-GPSI1 is treated as different subscribers. While S1:SUPI1-GPSI1 and S2:SUPI1-GPSI2 are also different subscribers.

  • Migration from one Single primary key search to another Single primary key search:

    During migration from one Single primary key search to another Single primary key search such as from Sinlge SUPI or a Single GPSI based search to a combination of Single SUPI and GPSI based search, if migration is enabled, records are migrated from a query using one primary key on pdssubscriber database to a query based on another primary key on pdssubscriber database.

    SUPI uniquely identifies the subscriber.

    SUPI or GPSI, or every combination of SUPI and GPSI is treated as a separate subscriber.

    For example if the migration is to a Single SUPI query, S1:SUPI1-GPSI1 and S2:SUPI2-GPSI1 are treated as different subscribers. While S1:SUPI1-GPSI1 and S2:SUPI1-GPSI2 are same subscribers.

    If the migration is to a combination of SUPI and GPSI as primary key, S1:SUPI1-GPSI1 and S2:SUPI2-GPSI1 is treated as different subscribers. While S1:SUPI1-GPSI1 and S2:SUPI1-GPSI2 are also different subscribers.

4.2 Support for Monitoring Migration Status of Database Records

Policy supports assessing the status of DB records in Policy for various microservices.

Note:

Currently, Policy supports assessing the status of only the PolicyDS database records.

Migration status for following type of search can be viewed:

• Multi UE ID: Allows to use multiple search criteria based on a primary key combination using AND (Preferential) and OR (default).
• Single UE ID: Allows to use a specific criteria based on a primary key combination to query the database.
• Partition based: Allows to use search criteria based on a composite key formed with a combination of keys. All the keys can be present in a single table or in different data tables.

  Partition based search is applicable only in case of fresh installation.

  enablePdsPartitionBasedSchema Helm parameter must be configured to enable Partition based schema for PDS.

  When PdsPartitionBasedSchema parameter is enabled, the primary key combination for partition based search must be configured using primaryKeyCombination Helm parameter.

  For more details on enablePdsPartitionBasedSchema and enablePdsPartitionBasedSchema Helm parameters, see Enabling/Disabling Services Configurations section in Oracle Communications Cloud Native Core, Converged Policy Installation, Upgrade, and Fault Recovery Guide.

For more details on the different type of search supported by Policy, see Optimizing PolicyDS Database Query With Configurable UE IDs.

The primary keys used for the query can be SUPI, GPSI, or a combination of SUPI and GPSI.

In case of Single UE ID search types, the primary key includes source type and siteIDs along with the selected SUPI or GPSI or a combination of SUPI and GPSI.

In case of partition based search type, a composite key is formed with subscriber IDs (SUPI, GPSI, or a combination of SUPI and GPSI), source type, and siteIDs stored in separate columns or data tables.

The following table depicts the possible primary key combination for each search type.

Table 4-1 Possible primary key combination for each search type

Search Type	Primary Key Combination
Multi UE ID	UUID
Single UE ID	SUPI##GPSI##source_type##siteid
Single UE ID	SUPI##source_type##siteid
Single UE ID	GPSI##source_type##siteid
Partition based Single-UE Id	SUPI##GPSI
Partition based Single-UE Id	SUPI
Partition based Single-UE Id	GPSI

Policy allows to switch the type of search. For example, it is possible to switch the type of search from Multi UE ID to Single UE ID type.

When the type of search is switched from one type to the other, tables within the database are updated to be in sync.

For example, when the type of search is switched from Multi UE ID to Single UE ID type, records are migrated from the tables used by Multi UE ID type to the tables used by Single UE ID type.

While the data migration is in progress, the database can be queried to get the count of database records that are pending to be migrated.

For example, while switching from Multi UE ID based query to Single UE ID based query, the database can be queried to get the count of records pertaining to the microservice or a subscriber that are yet to be migrated from one type of search to the other.

In case of multisite deployment, the query results such as count of records can be queried for specific sites.

The database migration status can be queried or viewed through CNC Console. For more information, see Custom Query.

Managing Custom Query

Configure

The Custom Query page under Status and Query in CNC Console can be used to query the database migration status.

For more information, see Custom Query.

4.3 Support for Signaling and DB Access Processing Latency Histogram Metrics

In order to provide sufficient insight into the microservices performance for incoming requests, Policy includes histogram metrics for the microservices.

These Histogram metrics enable Policy to observe data distribution by measuring the latency of multiple HTTP and database requests sent and received by the microservices.

Histogram Metrics for Binding Service

Enable

Histogram metrics for Binding service can be enabled either using Helm configuration or using CNC Console.

To enable histogram metrics for Binding service using CNC console, configure the ENABLE_BINDING_HTTP_HISTOGRAM_METRICS advanced settings key on Binding Service Configuration page under Service Configurations in CNC Console.

For more information about the advance settings keys, see Binding Service.

To enable histogram metrics for Binding service using Helm configuration, configure the value of SIGNALING_DB_HISTOGRAM_METRIC_ENABLED parameter to true.

For more information on Helm configuration, see Binding Service Configurations section in Oracle Communications Cloud Native Core, Installation, Upgrade, and Fault Recovery Guide.

Metrics

The following metrics are used to monitor the database processing latency in Binding service call flows, HTTP incoming and outgoing connections:

• occnp_db_processing_latency_seconds
• occnp_http_in_conn_processing_latency_seconds
• occnp_http_out_conn_processing_latency_seconds

For more information, see Binding Service Metrics.

Histogram Metrics for PDS Service

The following metrics are used to monitor the database processing latency in PDS service call flows, HTTP incoming and outgoing connections:

• occnp_db_processing_latency_seconds
• occnp_http_in_conn_processing_latency_seconds
• occnp_http_out_conn_processing_latency_seconds

For more information, see Policy DS Metrics.

Histogram Metrics for PCRF Core Service

The following metrics are used to monitor the latency in PCRF Core service call flows, Diameter Gateway response time for the incoming requests, HTTP incoming and outgoing connections, and DB request processing:

• occnp_diam_response_local_processing_latency_seconds
• occnp_http_in_conn_processing_latency_seconds
• occnp_http_out_conn_processing_latency_seconds
• occnp_db_processing_latency_ms

For more information, see PCRF Core Metrics.

4.4 Support for NR vs EUTRA KPIs for N7 Interface

The 5G deployment can be broadly categorized into Non-Standalone (NSA) and Standalone (SA) architectures. The NSA deployments combines a 5G Radio Access Network (RAN) operating alongside a legacy 4G LTE core network. The SA deployments feature a 5G RAN and a cloud native 5G core. The 5G network operators may deploy their networks using both the NSA and SA deployment strategies.

The following diagram illustrates the NSA and SA subscriber flow:

Figure 4-1 NSA and SA Flow

The NSA subscribers follows:

Long Term Evolution (LTE) network → Mobile Management Entity (MME)→ Serving Gateway (SGW) → Session Management Function (SMF) → Policy Control Function (PCF) with Radio Access Technology (RAT) value set to EUTRA. The Evolved Universal Terrestrial Radio Access (EUTRA) is the air interface technology used in 4G LTE networks.

The SA subscribers follows:

Session Management Function (SMF) → PDN Gateway → Control Plane(PGW-C) → Policy Control Function (PCF) with RAT value set to NR. New Radio (NR) is the air interface technology used in 5G networks.

Currently, the KPIs in PCF application do not differentiate between NSA and SA call flow. This feature provides KPI for N7 interface to differentiate between the NR and EUTRA radio access technology in the SM Service. The SM service will provide KPI to visualize in Grafana dashboard, and allows to measure the SMPolicyCreate, SMPolicyUpdate and SMPolicyDelete transactions per second (TPS) along with RAT type (NR or EUTRA).

Note:

The error responses from Ingress Gateway microservice does not support the newly added dimensions.

The following existing metrics in SM service are modified to capture the radio access type (ratType) and access type (accessType) dimensions.

• ocpm_ingress_request_total
• ocpm_ingress_response_total
• http_in_conn_request_total
• http_in_conn_response_total

The following new metrics are added for SM update and delete requests.

• http_in_conn_ext_request_total
• http_in_conn_ext_response_total

The following new dimensions are added to above metrics to support NR vs EUTRA rat type over N7 interface:

Table 4-2 SM Dimensions

Dimension Name	Values	Description
accessType access_type	3GPP_ACCESS NON_3GPP_ACCESS	Supported access types.
policyControlRequestTrigger	AC_TY_CH AN_CH_COR AN_INFO APP_STA APP_STO CM_SES_FAIL DEF_QOS_CH NO_CREDIT NUM_OF_PACKET_FILTER PLM_CH PRA_CH PS_DA_OFF QOS_NOTIF RAT_TY_CH RE_TIMEOUT REF_QOS_IND_CH RES_MO_RE RES_RELEASE SAREA_CH SCELL_CH SCNN_CH SE_AMBR_CH SUCC_RES_ALLO UE_IP_CH UE_MAC_CH UE_STATUS_RESUME UE_TZ_CH US_RE	Policy Control Request Trigger can have single value or comma separated list of values ordered alphabetically. The metrics using this dimension is not pegged if this field is not populated with either of the following mandatory values: AC_TY_CH, PRA_CH, RAT_TY_CH. They can come individually, together, or along other values. When a list of values is received, at least one of the previous values must be present; otherwise, the metric is not pegged. If the received number of values for this dimension is greater than 5, the mandatory values are prioritized first among the received values. The remaining values are ordered alphabetically and combine them with the previously retrieved mandatory ones until we run out of remaining values, or we will reach the maximum number of values allowed (5), whichever occurs first. If more values do exist after this process, they are ignored. For example: Table 4-3 policyControlRequestTrigger Dimension Scenario Incoming Values Output Dimension Peg Values AN_CH_COR,RES_MO_RE,QOS_NOTIF "" The values are not pegged, since the mandatory values are not found. PRA_CH "PRA_CH" The value is pegged, since one of the mandatory values exist. RAT_TY_CH,PRA_CH "PRA_CH,RAT_TY_CH" The value is pegged, since one of the mandatory value exist. RAT_TY_CH,AC_TY_CH,QOS_NOTIF "AC_TY_CH,RAT_TY_CH,QOS_NOTIF" The value is pegged, since one of the mandatory value exist. APP_STA,PRA_CH,RES_MO_RE,AC_TY_CH,QOS_NOTIF,UE_IP_CH,RAT_TY_CH "AC_TY_CH,APP_STA,PRA_CH,QOS_NOTIF,RAT_TY_CH" The value is pegged, since the mandatory values exist, and the remaining values were ignored. For delete request this dimension can be empty; otherwise the rules in Table policyControlRequestTrigger Dimension Scenario is applied. For requests where value is not validated, sanitization is done, and invalid values are removed and ignored.
rat_type ratType	EUTRA EUTRA_U GERA LTE_M_GEO LTE_M_LEO LTE_M_MEO LTE_M_OTHERSAT LTE-M NB_IOT_GEO NB_IOT_LEO NB_IOT_MEO NB_IOT_OTHERSAT NBIOT NR NR_GEO NR_LEO NR_MEO NR_OTHER_SAT NR_REDCAP NR_U TRUSTED_N3GA TRUSTED_WLAN UTRA VIRTUAL WB_E_UTRAN_GEO WB_E_UTRAN_LEO WB_E_UTRAN_MEO WB_E_UTRAN_OTHERSAT WIRELINE WIRELINE_BBF WIRELINE_CABLE WLAN	Supported Radio Access Type (RAT).
sourceAccessType	Single value	The previous access type before the update. The value can be empty if cannot be retrieved from a session. Dimension: accessType
sourceRatType	Single value	The previous radio access type before the update. The value can be empty if cannot be retrieved from a session. Dimension: ratType

A sample metric:

occnp_http_in_conn_ext_request_total{accessType="NON_3GPP_ACCESS",application="pcf_smservice",operationType="update",policyControlRequestTrigger="AC_TY_CH,NO_CREDIT,RAT_TY_CH,PRA_CH,UE_IP_CH",ratType="NR",sourceAccessType="3GPP_ACCESS",sourceRatType="EUTRA"} 1.0

For more detailed information about the metrics, see SM Service Metrics section.

For more information about the dimensions accessType, ratType, and policyControlRequestTrigger details, see CNC Policy Metrics section.

4.5 Support of Traffic Detection on SMF-N7 and TDF using Sd Interface

Important:

Custom support for traffic detection on SMF-N7 and TDF using the Sd interface is an experimental feature. It is subject to change and is not supported for production use (lab use only).

The PCF is responsible for defining and managing policies. It can be used for parental control by defining and enforcing policies related to network traffic and access based on user profiles. PCF monitors network traffic to detect and manage access to specific content or services based on pre-defined rules. Application Detection and Control (ADC) rules are used to enforce these policies, such as restricting access to certain websites or applications for specific users.

The CnPolicy provides ADC rules to the Traffic Detection Function (TDF) by using the Sd interface. The Sd interface enables to communicate with the TDF. CnPolicy uses a TDF to detect and identify specific types of network. This allows it to understand which application or service is generating the traffic. Based on the detected traffic type, the CnPolicy applies predefined policies or rules to manage the traffic flow. In solicited reporting, CnPolicy instructs TDF to report traffic events, including application starting or stopping based on the appropriate ADC rules.

The support for Sd interface already exists between PCRF Core and Diameter Gateway, for a PCRF deployment. For more details about it, see Support for Sd Interface in PCRF section.

By implementing this feature in CnPolicy on SMF-N7 interface, it enables CnPolicy to determine the traffic detection on Sd interface for both the PCF and Converged Policy (PCF + PCRF) modes of deployment. The following diagram illustrates the architecture involved for PCF to support for Sd interface. This feature introduces Sd interface support between Diameter Connector and Diameter Gateway on SMF-N7 interface.

Figure 4-2 Sd interface in PCF

CnPolicy performs the following functionality to SMF-N7 to determine the traffic detection on Sd interface for both PCF and Converged Policy modes of Deployment:

• TDF session establishment between CnPolicy and TDF when the session request is initiated by PCF only. For changes made to this procedure, refer to Sd Session Establishment from PCF to TDF callflow.
• Update of TDF session, refer to Sd Session Modification from PCF to TDF when PLMN Change and Sd Session Modification from PCF to TDF when Update Notification from OCS-Sy SNR call flows.
• TDF session termination requests is initiated by PCF, refer to Sd Session Termination Initiated by CnPolicy callflow.
• TDF session termination requests is initiated by TDF, refer to Sd Session Termination Initiated by TDF callflow.
• Provisioning of ADC rules from CnPolicy for traffic detection and enforcement at the TDF.
• Reporting of the start and the stop of a detected applications and transfer of service data flow descriptions for the detected applications, if available, from the TDF to the CnPolicy.

Call Flows

This section describes the different SM service call flows that are modified to support TDF session in CnPolicy.

Sd Session Establishment from PCF to TDF

CnPolicy establishes a Sd session, based on a policy condition/action during SM-Create request received over N7 interface. The condition to establish a Sd session is based on data Packet Data Unit (PDU) session establishment on N7 create. CnPolicy supports asynchronous mode of communication between SMF-N7 and Sd interface.

Note:

CnPolicy supports one Sd session per PDU session from SMF-N7. In case of multiple PDU sessions, the new Sd session is established to the same TDF for which the IPCAN session already exists.

The following procedure describes how CnPolicy initiates an Sd session from PCF-SM towards the TDF by sending a ADC Rule, using a TDF-Session-Request (TSR) message to the TDF and getting a successful TDF-Session-Answer (TSA) message to PCF-SM:

Figure 4-3 Sd Session Establishment (PCF→ TDF)

1. SMF sends a SM-Create request to PCF-SM.
2. If the OCS is enabled, then Spending Limit Request (SLR) is sent by the Diameter Connector to OCS.
3. A Spending Limit Answer (SLA) is sent by OCS to Diameter Connector.
4. PCF-SM on receiving the Policy counter in SLA, initiates a policy evaluation request to PRE.
5. PCF-SM checks for any Sd session creation requirement in the PRE response.
6. If the Sd session needs to be created, a Tdf session id is created and added to the smPolicy association.
7. The smPolicy association along with Tdf session id is stored in the database.
8. PCF-SM responds with HTTP 201 SM Create to SMF.
9. PCF-SM creates a Sd TDF-Session-Request (TSR) JSON text with Application Detection and Control (ADC) rules, and then initiates a tdf-creation request with the TSR JSON text toward Diameter Connector.
10. The Diameter Connector converts the TSR JSON to diameter based protocol, and sends a TSR request toward Traffic Detection Function (TDF).
11. The TDF responds with TDF-Session-Answer (TSA) to Diameter Gateway, and Diameter Connector converts this TSA to JSON text.
12. Diameter Connector responds to PCF-SM with HTTP 200 OK, and TSA JSON text. At PCF-SM the text is stored in the TDFSession table in the database.
13. If Tdf session creation fails then the TDF session id is removed from the smPolicy association during the database lazy purge.

Sd Session Modification from PCF to TDF

Sd Session Modification from PCF to TDF when PLMN Change

The following procedure describes how CnPolicy on receiving PLMN change from SMF, triggers an SM update request. This request may result in policy re-evaluation with changes to ADC rules. Reauthorizing these ADC rule at TDF and storing the updated TDF session into database.

Figure 4-4 Sd Session Modification from PCF to TDF when PLMN Change

1. The SMF initiates a SM update request toward PCF on change in the Public Land Mobile Network (PLMN).
2. The PCF-SM service in PCF on receiving the SLA response from OCS, initiates a policy evaluation towards PDS.
3. After receiving the response from PDS, PCF-SM checks if there is any ADC rule changes and if the Sd session exists.
   • If the condition is true, then PCF-SM sends a TDF update request towards a TDF through Diameter Connector.
   • Diameter Connector sends a Sd RAR request towards Diameter Gateway.
   • Diameter Gateway forwards this Sd RAR request to the TDF. The ADC rules are reauthorized at TDF.
   • TDF responds with Sd RAA towards Diameter Gateway.
   • Diameter Gateway forwards this to Diameter Connector.
   • Diameter Connector converts the Sd RAA response object to JSON format, and sends this to PCF-SM.
   • PCF-SM stores the updated Tdfsession into the database.

Sd Session Modification on Update Notification from OCS-Sy SNR:

The following procedure describes how CnPolicy on receiving Spending Notification Request (SNR) from OCS, can trigger a Sd session modification if Sd session exists. CnPolicy initiates a Sd rule modification resulting in reauthorized ADC rules at TDF and storing the updated TDF session into the database.

Note:

If the TDF session is not already existing, then this procedure will not create a new TDF session.

Figure 4-5 Sd Session Modification on Update Notification from OCS-Sy SNR

1. On OCS initiating a SNR request toward PCF, the PCF-SM initiates a policy evaluation request toward PDS.
2. In case of policy changes from PDS, PCF-SM triggers the SM update notify request toward SMF. PCF-SM also checks if there is any ADC rule changes and if the Sd session exists.
   • If the condition is true, then PCF-SM sends a TDF update request towards a TDF through Diameter Connector.
   • Diameter Connector sends a Sd RAR request towards Diameter Gateway.
   • Diameter Gateway forwards this Sd RAR request to the TDF. The ADC rules are reauthorized at TDF.
   • TDF responds with Sd RAA towards Diameter Gateway.
   • Diameter Gateway forwards this to Diameter Connector.
   • Diameter Connector converts the Sd RAA response object to JSON format, and sends this to PCF-SM.
   • PCF-SM stores the updated Tdfsession into the database.

Sd Session Termination Initiated by CnPolicy

The following procedure describes how CnPolicy on receiving SM delete from SMF, triggers an Sd session termination by sending the Sd RAR having Session-Release-Cause attribute set to IP_CAN_SESSION_TERMINATION towards TDF. CnPolicy sends delete response to SMF over N7 interface. It also supports receiving and processing of Sd CCR-T response have CC-Request-Type attribute set to TERMINATION_REQUEST.

Figure 4-6 Sd Session Termination (PCF → TDF)

1. SMF sends a SM-Delete request to PCF-SM.
2. PCF-SM checks if SM session has Sd session to terminate, if exists then it sends a TDF terminate request to Diameter Connector.
3. Diameter Connector converts the json to diameter protocol and sends Sd RAR towards Diameter Gateway.
4. Diameter Gateway on receiving the Sd RAA successful response, it is forwarded to Diameter Connector.
   • Diameter Connector responds with TDF terminate to PCF-SM, and PCF-SM also responds with terminate success to SMF.
   • TDF sends a Sd: CCR-T request to Diameter Gateway. Diameter Gateway based on the session id the request will be routed to either PCRF Core or Diameter Connector service.
   • If Diameter Connector receives an Sd: CCR-T request from Diameter Gateway, it converts the diameter protocol request to JSON, and sends it to PCF-SM.
   • PCF-SM deletes the associated Tdfsession in the database and send a request to Diameter Connector.
   • Diameter Connector converts JSON data to diameter protocol, and sends a Sd: CCA-T request to Diameter Gateway.
   • Diameter Gateway forwards the Sd: CCA-T to TDF.
5. Diameter Gateway on receiving the Sd RAA failure response, the Sd session is deleted and PCF does not wait for CCR-T from TDF.

Sd Session Termination Initiated by TDF

The following procedure describes how CnPolicy on receiving Sd session termination initiated by TDF by sending an Sd: CCR-T, shall clean up Sd session information and does not send any Update Notify request to SMF.

Figure 4-7 Sd Session Termination (TDF → PCF)

1. TDF initiates a Sd: CCR-T request toward Diameter Gateway.
2. Diameter Gateway sends this request to Diameter Connector.
3. Diameter Connector based on the session id, the request will be re-routed.

Diameter Gateway Routing Decision for CCR-U or CCR-T from TDF

The Diameter Gateway on receiving the CCR-U or CCR-T request from TDF has to decide if the request has to be routed to PCRF Core or Diameter Connector. It uses the <optional value> of diameter session-id AVP, which is used to identify a specific session. An encoded <optional value> is appended with session-id and added to the Diameter Gateway header to differentiate between PCRF Core and PCF so that it can re-route the requests accordingly.

The diagram illustrates the flowchart for the Diameter Gateway making the routing decision based on <option value>.

Figure 4-8 Flowchart for Diameter Gateway Routing Decision

Diameter Gateway service uses RFC-6733 recommendation for the Session-id AVP format <DiameterIdentity>;<high 32 bits>;<low 32 bits>[;<optional value>].

Where,

• <high 32 bits> and <low 32 bits> are decimal representations of the high and low 32 bits of a monotonically increasing 64-bit value. The 64-bit value is rendered in two part to simplify formatting by 32-bit processors. At startup, the high 32 bits of the 64-bit value may be initialized to the time in NTP format RFC5905, and the low 32 bits may be initialized to zero. This will for practical purposes eliminate the possibility of overlapping Session-Ids after a reboot, assuming the reboot process takes longer than a second. Alternatively, an implementation may keep track of the increasing value in non-volatile memory.
• <optional value> is implementation specific.

A sample session-id AVP format:

sd1.oacle.com;5dd8b4b775-fvwlg;1728285868;efac51ae-3d26-4632-9d3b-7ee3a5bbd207_101NTAyU00=

Where,

Table 4-4 Session-id AVP Format

Diameter Identity	High 32 bits	Low 32 bits	<option value>
sd1.oacle.com	5dd8b4b775-fvwlg	1728285868	efac51ae-3d26-4632-9d3b-7ee3a5bbd207_101NTAyU00=

Table 4-5 <option value> Format

AssociationID	Encoding_version_number	Number of Elements	Encoded_Key_Value_Pair
This is a random UUID generated number. Example: efac51ae-3d26-4632-9d3b-7ee3a5bbd207	This determines the encryption or decryption algorithm used for the particular ID to get the key-value pair information. Example: 1	This determines how many key-value pairs exists in the encoded format in encoded_key_value_pair Example: 01	This contains the key-value pair in a specific format used to decode the data. The NTAyU00=, decoded value is 502SM.

Table 4-6 Decoded_Key_Value_Pair as TagID-Length-Value (TLV) format

AssociationIdTLV	length_of_AssociationIdTLV	Value
This is the enum for tag IDs. Example: In decoded 502SM text, '5' represents the session or context owner.	This represents the length of the value string. Example: In decoded 502SM text, '02' represents the value length.	This holds the value. Example: In decoded 502SM text, 'SM' represents the value. Note: Currently only SM value is supported.

Diameter Gateway Force Routing for Sd Interface

In Policy converged mode deployment, both the HTTP and Diameter requests are handled by CnPolicy. In this mode of deployment if the Diameter Gateway is unable to identify the right session for the Sd CCR-T or CCR-U requests then the CnPolicy uses force routing mechanism. By default, this mechanism is disabled. It can be enabled by adding the following advanced setting keys to Diameter Gateway service configurations in CNC Console.

Following are the Diameter Gateway advanced settings keys and their default values for configuring force routing for Sd interface:

Table 4-7 Parameters for Advanced Settings

Key	Value
DIAMETER.gateway.sd.session.owner.failure.forcerouting.enabled	This is used to enable force routing to PCRF Core and/or Diameter Connector for Sd interface. Allowed values are true or false. Default Value: false
DIAMETER.gateway.sd.session.owner.failure.forcerouting.service.list	This is used to set the force routing to PCRF Core and/or Diameter Connector. The possible list of values: PCRF_CORE DIAMETER_CONNECTOR
DIAMETER.gateway.sd.session.owner.failure.forcerouting.retry.timeout	This is used to enable force routing retry on the next service if the current selected service is throwing timeout error. Allowed values are true or false. Default Value: true
DIAMETER.gateway.sd.session.owner.failure.forcerouting.retry.diameter.unknown.session.id	This is used to enable force routing retry on the next service if the current selected service is throwing DIAMETER_UNKNOWN_SESSION_ID. Allowed values are true or false. Default Value: true
DIAMETER.gateway.sd.session.owner.failure.forcerouting.retry.error.code.list	Provide the list of diameter error code for which users want to retry force routing. If the diameter error code coming from the current selected service is present in this list then force routing is retried on the next service. Allowed value is a string, and default is empty string. Example: 3004, 5012 Default Value: ""

Note:

If the TDF sends a empty or null, or encodes SESSION_OWNER as UNKNOWN in session-id then the Diameter Gateway cannot find the session owner.

For more information about the advanced settings in Diameter Gateway service, see Settings section.

Changes in Congestion Control feature

SM Service Congestion Control

When SM service is in congestion state then based on request priority and discard priority messages are either accepted or rejected. The request priority is decided based on the priority order: oc-message-priority header → 3gpp-sbi-message-priority header → advanced settings priority → default priority.

Following advanced keys are used to configure the message priorities for TDF messages at SM service:

Table 4-8 SM Advanced Settings

Key	Value
SM.TDF.SESSION.DELETE.PRIORITY	16
SM.TDF.SESSION.UPDATE.PRIORITY	18

For more details about the Congestion Control support in SM Service, refer to SM Service Pod Congestion Control.

Diameter Connector Congestion Control

When Diameter Connector service is in congestion state then based on request priority and discard priority messages are either accepted or rejected. The request priority is decided based on the priority order: oc-message-priority header/OC-Message-Priority AVP → advanced settings priority → default priority.

Following advanced keys are used to configure the message priorities for TDF and Sd messages at Diameter Connector service:

Table 4-9 Diameter Connector Advanced keys

Key	Value
SM.TDF.CREATE.SESSION.REQUEST.PRIORITY	24
SM.TDF.TERMINATE.REQUEST.PRIORITY	16
SM.TDF.UPDATE.REQUEST.PRIORITY	18
SD.CCR.TERMINATE.REQUEST.PRIORITY	16
SD.CCR.UPDATE.REQUEST.PRIORITY	18

For more details about the Congestion Control support in Diameter Connector, refer to Diameter Connector Pod Congestion Control.

Diameter Gateway Congestion Control

For more details about the Congestion Control support in Diameter Gateway, refer to Diameter Pod Congestion Control.

Changes in Audit Service for TDF Stale Session Cleanup in Database

Audit service supports auditing the TDF Session table periodically and remove the stale sessions. Based on the session'sLastAccessTime information the Audit service determines if the session is stale or not. If it is a stale session then it sends notification to SM service for cleaning the stale session.

For more details about editing the audit information related to TDF Session in CNC Console, refer to PCF Session Management page.

CNC Console Configurations

The N7-Sd feature in PCF is not enabled by default. This can be enabled by adding the TDF.TDF_ENALBLED advanced setting key in CNC Console.

In SM service, the data stored in the SmAssociation table in the database can be compressed. This can also be applied to TdfSession table too. To enable the data compression in SM service, enable the System.Data Compression Scheme field in PCF Session Management service.

For more information to enable this feature and also the data compression in SM service, see PCF Session Management page in CNC Console.

The traffic profile containing the ADC rules can be created using the Traffic Profile page in the CNC Console. The ADC rules can also be configures using the Rest APIs. For more information, see "PCF Traffic Profile ADC Rule", "PCF Predefined ADC Rule", and "PCF Predefined ADC Rule Base" sections in Oracle Communications Cloud Native Core, Converged Policy REST Specification Guide.

HTTP and Diameter Result Codes Mapping

In CnPolicy converged deployment, both the HTTP and Diameter requests are handled by the application. The errors in Diameter Connector are handled by the result code AVP in Diameter messages, which are mapped to appropriate HTTP response code.

Diameter Gateway maps Diameter error codes to HTTP status codes. This table provides the mapping of Diameter result code to HTTP response code when the Diameter Connector sends response to SM service.

Table 4-10 Diameter Result Codes from TDF toward SM service

Diameter Result Code	HTTP Response Code	Diameter Connector Response Body
DIAMETER_SUCCESS	200	No response body
DIAMETER_MISSING_AVP / DIAMETER_UNABLE_TO_COMPLY / DIAMETER_UNABLE_TO_DELIVER / DIAMETER_TOO_BUSY / DIAMETER_LOOP_DETECTED/ DIAMETER_APPLICATION_UNSUPPORTED	500	{ "type": null, "title": "INTERNAL_SERVER_ERROR", "status": 500, "detail": "Error Occurred", "instance": null, "cause": "<Mapping of Diameter Result Code with Cause is provided in below table>", "invalidParams": null }
DIAMETER_UNKNOWN_SESSION_ID	404	{ "type": null, "title": "NOT_FOUND", "status": 404, "detail": "Session Does not Exist", "instance": null, "cause": "A request is received with unknown session ID.", "invalidParams": null }

This table describes the Diameter Connector various error 'cause' that it can send in its response body to SM service.

Table 4-11 Error Cause Diameter Connector to SM service

Diameter Error Name	Diameter Result Code	Response Body 'Cause' from Diameter Connector to SM
DIAMETER_UNABLE_TO_COMPLY	5012	An internal failure occurred.
DIAMETER_UNKNOWN_SESSION_ID	5002	A request is received with unknown session ID.
DIAMETER_UNABLE_TO_DELIVER	3002	Request did not delivered to the destination.
DIAMETER_TOO_BUSY	3004	An upstream peer is either in congestion or too busy to handle a request.
DIAMETER_MISSING_AVP	5005	The request did not contain an AVP that is required by the Command Code definition.
DIAMETER_COMMAND_UNSUPPORTED	3001	The Request contained a Command-Code that the receiver did not recognize or support.
DIAMETER_LOOP_DETECTED	3005	An agent detected a loop while trying to get the message to the intended recipient.
DIAMETER_UNSUPPORTED_VERSION	5011	A request was received, whose version number is unsupported.
DIAMETER_AVP_OCCURS_TOO_MANY_TIMES	5009	A message was received that included an AVP that appeared more often than permitted in the message definition.
DIAMETER_AVP_UNSUPPORTED	5001	The peer received a message that contained an AVP that is not recognized or supported and was marked with the Mandatory bit.
DIAMETER_INVALID_AVP_VALUE	5004	The request contained an AVP with an invalid value in its data portion.
DIAMETER_INVALID_AVP_LENGTH	5014	The request contained an AVP with an invalid length.
DIAMETER_INVALID_HDR_BITS	3008	A request was received whose bits in the Diameter header were either set to an invalid combination, or to a value that is inconsistent with the command code definition.
DIAMETER_INVALID_AVP_BITS	3009	A request was received that included an AVP whose flag bits are set to an unrecognized value, or that is inconsistent with the AVP definition.

When Diameter Connector times out while processing a request, then it will send and 503 Service Unavailable response.

{
    "type": null,
    "title": "SERVICE_UNAVAILABLE",
    "status": 503,
    "detail": "Service Unavailable",
    "instance": null,
    "cause": "Request processing timeout.",
    "invalidParams": null
}

Delay response by TDF: Diameter-gateway will send DIAMETER_UNABLE_TO_DELIVER to diameter-connector and diameter-connector will send 500 Internal Server Error to SM with response body.

{
    "type": null,
    "title": "INTERNAL_SERVER_ERROR",
    "status": 500,
    "detail": "Error Occurred",
    "instance": null,
    "cause": "Request did not delivered to the destination.",
    "invalidParams": null
}

Destination-Realm (Host-Realm) is null/empty in Sd TSR/RAR request from SM towards TDF: Diameter-gateway will response back with DIAMAETER_MISSING_AVP to diameter-connector. Diameter-connector will send 500 Internal Server Error to SM with response body.

{
    "type": null,
    "title": "INTERNAL_SERVER_ERROR",
    "status": 500,
    "detail": "Error Occurred",
    "instance": null,
    "cause": "The request did not contain an AVP that is required by the Command Code definition.",
    "invalidParams": null
}

Destination-Identity (Host-Identity) is null/empty in Sd TSR/RAR request from SM towards TDF: Diameter-gateway will response back with DIAMETER_UNABLE_TO_DELIVER to diameter-connector. Diameter-connector will send 500 Internal Server Error to SM with response body.

{
    "type": null,
    "title": "INTERNAL_SERVER_ERROR",
    "status": 500,
    "detail": "Error Occurred",
    "instance": null,
    "cause": "Request did not delivered to the destination.",
    "invalidParams": null
}

Sd CCR-T/CCR-U response from SM towards TDF

HTTP status codes are used to indicate the success or failure of an HTTP request, and can be mapped to Diameter errors. This table provides the mapping of HTTP response code to Diameter result code when SM service sends response to Diameter Connector.

Table 4-12 HTTP Result Codes from SM service toward TDF

HTTP Response Code	Diameter Result Code
204/200	DIAMETER_SUCCESS
500	DIAMETER_UNABLE_TO_COMPLY
503	DIAMETER_UNABLE_TO_COMPLY
400	DIAMETER_UNABLE_TO_COMPLY
404	DIAMETER_UNKNWON_SESSION_ID

Support for TDS Session in Session Viewer

The session viewer supports SM TDS session in Session Viewer page of CNC Console.

TDF Session Viewer Call Flows

This section describes the different call flows for TDF session in Session view.

Figure 4-9 Fetch TDF Session

Delete TDF Session

Figure 4-10 LOCAL DELETE TDF SESSION

REMOTE DELETE TDF SESSION

Figure 4-11 REMOTE DELETE TDF SESSION

LOCAL DELETE SM SESSION

Figure 4-12 LOCAL DELETE SM SESSION

REMOTE DELETE SM SESSION

Figure 4-13 REMOTE DELETE SM SESSION

Manage Sd Interface Support for PCF

Enable

This feature is not enabled by default.

Configure Using CNC Console

Enable this feature by adding the TDF.TDF_ENALBLED advanced settings key to PCF Session Management page in CNC Console.

To configure auditing of TDF stale sessions, see PCF Session Management page in CNC Console.

To view the SM TDF Session details, see Session Viewer page in CNC Console.

Policy Blockly

The following blockly's are added to the PCF SM category.

• FQDN from notificationUri
• Remove ADC Type Rules
• Install ADC Rules
• Remove ADC Rules
• Establish traffic detection session with peer node name
• Establish traffic detection session with peer node set name
• Install ADCRules For TimePeriod

For more details about this blockly, see "PCF-SM Category" section in Oracle Communications Cloud Native Core, Policy Design Guide.

Observability

Metrics

Following SM Service Metrics are used to provide information about this feature:

• occnp_http_out_conn_request_total
• occnp_http_out_conn_response_total
• ocpm_egress_request_total
• ocpm_egress_response_total
• occnp_pcf_smservice_overall_processing_time_seconds_count
• occnp_pcf_smservice_overall_processing_time_seconds_sum
• occnp_pcf_smservice_overall_processing_time_seconds_max
• ocpm_egress_request_timeout_total
• session_oam_request_total
• session_oam_response_total
• occnp_http_sm_request_total
• occnp_http_sm_response_total
• audit_notifications_sent
• audit_update_notify_session_not_found
• audit_update_notify_session_found
• audit_update_notify_response_error
• audit_update_timestamp_cnt
• audit_delete_records_count
• audit_delete_records_max_ttl_count
• ocpm_late_arrival_rejection_total
• occnp_late_processing_rejection_total

Following Diameter Gateway Metrics are used to provide information about this feature:

• occnp_diam_service_overall_processing_time_seconds
• occnp_diam_service_overall_processing_time_seconds_bucket
• occnp_diam_service_overall_processing_time_seconds_sum
• occnp_diam_service_overall_processing_time_seconds_max
• occnp_diam_request_network_total
• occnp_diam_response_network_total
• occnp_diam_response_latency_seconds
• occnp_diam_response_latency_seconds_bucket
• occnp_diam_response_latency_seconds_sum
• occnp_diam_response_latency_seconds_count
• occnp_diam_response_latency_seconds_max

Following Diameter Connector Service Metrics are used to provide information about this feature:

• occnp_diam_connector_overall_processing_time_seconds_max
• occnp_diam_connector_overall_processing_time_seconds_count
• occnp_diam_connector_overall_processing_time_seconds_sum
• occnp_stale_diam_request_cleanup_total
• occnp_stale_http_request_cleanup_total

Alerts

The TDF_CONNECTION_DOWN alert is generated when there is a disconnection with configured TDF peer node.

4.6 Handling Collision Between AAR and STR Messages During Update Notify Timeout

Whenever PCF receives a Authorization Authentication Request (AAR-I/AAR-U) from Proxy- Call Session Control Function (P-CSCF), PCF asynchronously responds to P-CSCF with a Authorization Authentication Answer (AAA) and also sends an UpdateNotify message to SMF to install the pccRules.

If PCF does not receive any response from SMF and the wait time expires, it applies the session retry logic if configured. If PCF does not receive any response from SMF after all the retries and during this time if PCF also receives a Session Termination Request (STR) from P-CSCF, PCF sends a UpdateNotify message to SMF to remove the pccRules. Thereby, a collision or race condition arises as PCF first sends an UpdateNotifymessage to SMF to install the pccRule and before receiving any response from SMF, PCF also sends an UpdateNotify message to SMF to remove the pccRule.

PCF handles concurrency or collision between AAR-I or AAR-U triggered due to UpdateNotify to install pccRule and STR messages triggered due to UpdateNotify to remove the pccRule.

PCF sends UpdateNotify request for pccRule removal to SMF for STR after Timeouts and there is no response received for UpdateNotify request sent due to AAR-I/AAR-U.

PCF interacts with P-CSCF to enforce Quality of Service (QoS) parameters. PCF allocates the necessary network resources to ensure VoLTE calls have the lowest possible latency, ensuring call quality.

PCF receives AAR from P-CSCF through BSF to create the dedicated QoS flow for VoLTE session. AAR includes QoS information associated with the bearer. The request includes IP Multimedia Subsystem (IMS) Voice bearer and optionally Video or Real-time text (RTT) bearer.

PCF processes the AAR-I request and sends a UpdateNotify for pccRule install to SMF. If PCF does not receive any response from SMF, it retries the request as per session retry configuration.

While PCF is awaiting response for UpdateNotify for pccRule install from SMF, if it receives a STR to terminate the session:

• If the wait time to receive response from SMF expires and as per the session retry configuration, if the number of retries is also exhausted, pccRules are deleted from SmPolicyAssociation during timeout error handling.
• PCF sends the UpdateNotify to SMF due to STR to remove the pccRule depending on whether the pccRules are present in SmPolicyAssociation database or not.

Design and Architecture

PCF handles the race condition between multiple UpdateNotify messages triggered due to AAR-I or AAR-U and STR requests using pendingConfirmationAction advanced settings key.

To handle the race condition, Bulwark service must be enabled and configured to wait for processing the STR request until AAR-I or AAR-U request is complete. Also, the following advanced settings keys for SM service must be configured:

• SYSTEM.RX.UPDATE_NOTIFY.RULES.PENDING_CONFIRMATION.ENABLED
• SYSTEM.RX.UPDATE_NOTIFY.RULES.PENDING_CONFIRMATION.PROCESS_ON_UPDATE
• SYSTEM.RX.UPDATE_NOTIFY.RULES.PENDING_CONFIRMATION.RESPONSE_CODES
• SYSTEM.RX.UPDATE_NOTIFY.RULES.PENDING_CONFIRMATION.EXCEPTIONS

For more information on these advanced settings keys for SM service, see PCF Session Management.

When PCF reveices AAR, PCF sends UpdateNotify to SMF to install the rules. The message to SMF also includes pendingConfirmationAction key.

The pendingConfirmationAction key indicates if the pccRule is installed in SmPolicyAssociation database or not during the timeout error.

If pccRules are installed as part of AAR-I or AAR-U and are saved in SmPolicyAssociation database, the pendingConfirmationAction key is updated accordingly.

The value of pendingConfirmationAction key can be:

• 0 (None)
• 1 (install)
• 2 (remove)

If PCF receives a successful response from SMF for the UpdateNotify message sent due to AAR-I or AAR-U, PCF removes the pendingConfirmationAction from SmPolicyAssociation database.

Otherwise, if PCF receives STR request before receiving any response from SMF, the pccRules are removed from SmPolicyAssociation database and pendingConfirmationAction key is updated accordingly.

PCF sends pendingConfirmationAction key in ASR to P-CSCF depending on Supress_ASR key. When Supress_ASR key is enabled, PCF does not send pendingConfirmationAction to P-CSCF.

Call Flow

Figure 4-14 Handling Collision Between AAR and STR Messages During UpdateNotify Timeout

1. PCF receives requests from P-CSCF to enforce Quality of Service (QoS) parameters. The PCF allocates the necessary network resources to ensure Voice over Long-Term Evolution (VoLTE) calls have the lowest possible latency and high call quality.

   P-CSCF sends AAR command to PCF through BSF to create the dedicated bearer for Voice over New Radio (VoNR) session. AAR includes QoS information associated with the bearer. The request includes IP Multimedia Subsystem (IMS) Voice bearer and optionally Video/Round-trip time (RTT) bearer.

2. BSF sends the request to PCF.

3. PCF responds to P-CSCF with AAA through BSF.

4. BSF forwards the AAA from PCF to P-CSCF through Diameter Gateway.

5. PCF sends an UpdateNotify request to SMF triggered due to AAR-I.

6. After sending the UpdateNotify request for AAR-I to SMF, PCF waits for configured timeout period.

7. If there is no response for UpdateNotify from SMF triggered due to AAR-I, PCF applies the session retry for SMUpdate notification.

8. If there is no response from SMF beyond the configured time period and all the retries are over for UpdateNotify request sent to SMF due to AAR-I, PCF sends an UpdateNotify request to SMF for STR for pccRule removal.

Flow scenarios

Figure 4-15 Handling Collision Between AAR and STR Messages During Update Notify-Success Scenario

In this case, PCF receives an AAR-I message from AF/P-CSCF.

PCF sends the UpdateNotify (pccRule install) message to SMF. SMF responds with a 204 Success message.

PCF saves the pccRules in the SMPolicyAssociation database.

When PCF receives an STR message to terminate the session, it sends an STR request to SMF for pccRule removal.

SMF responds with an UpdateNotify success message and PCF removes the pccRules from SMPolicyAssociation database.

Figure 4-16 Handling Collision Between AAR and STR Messages During UpdateNotify-Timeout Scenario

After PCF sends an UpdateNotify for pccRule install to SMF, if there is no response from SMF due to Timeout at SMF, PCF applies the session retry.

PCF handles the timeout scenario at SMF based on the following pending confirmation advanced settings keys configured for SM service in CNC Console. Accordingly, PCF saves the pccRules in the database if SYSTEM.RX.UPDATE_NOTIFY.RULES.PENDING_CONFIRMATION.ENABLED advanced settings key is set to true.

• SYSTEM.RX.UPDATE_NOTIFY.RULES.PENDING_CONFIRMATION.ENABLED
• SYSTEM.RX.UPDATE_NOTIFY.RULES.PENDING_CONFIRMATION.PROCESS_ON_UPDATE
• SYSTEM.RX.UPDATE_NOTIFY.RULES.PENDING_CONFIRMATION.RESPONSE_CODES
• SYSTEM.RX.UPDATE_NOTIFY.RULES.PENDING_CONFIRMATION.EXCEPTIONS

Figure 4-17 Handling Collision Between AAR and STR Messages During UpdateNotify-Partial Success Scenario

In case of partial success in pccRule installation by SMF, PCF handles the situation as pending-Success-pendingFailure (200 partial success response).

• The pccRules sent in UpdateNotify are saved in SMPolicyAssociation database with pendingConfirmation key if handleUpdateNotifyForRxCollision key is enabled.
• If PCF receives AAR-U, smUpdateNotify is sent with pccRules to create them if sendPendingConfirmationRulesToInstallOnUpdate key is enabled. If PCF receives a successful response from SMF, the pendingConfirmation key is removed for pccRules.
• If PCF receives AAR-U, smUpdateNotify is sent with pccRules to create them if sendPendingConfirmationRulesToInstallOnUpdate key is enabled. If PCF receives a successful response from SMF, the pendingConfirmation key is removed for pccRules.
• STR is sent with pccRules information to be removed if sendPendingConfirmationToDeleteOnSTR key is enabled.
• If PCR receives STR, it sends SmfUpdateNotify cleaning up pccRules.
• If PCF receives AAR-U, it sends the pccRules again to confirm if they are installed.

Figure 4-18 Handling Collision Between AAR and STR Messages During UpdateNotify-408 or 504 Errors from SMF

• If SMF responds with Timeout error, 408/504 REQUEST_TIMEOUT error code and if SYSTEM.RX.UPDATE_NOTIFY.RULES.PENDING_CONFIRMATION.RESPONSE_CODES key is enabled, and pccRules are saved in SMPolicyAssociation database.
• PCF sends a Abort Session Request (ASR) with SuppressASR key disabled to AF/P-CSCF.
• AF/P-CSCF responds with Abort Session Answer (ASA).
• PCF receives a STR from AF/P-CSCF. PCF does not send any UpdateNotify message to SMF as the pccRules were not installed.
• PCF responds to AF- PCSCF with STA.

Figure 4-19 Handling Collision Between AAR and STR Messages During UpdateNotify-408 or 504 Errors from SMF When Error Codes are Configured

• If SMF responds with Timeout error, 408/504 REQUEST_TIMEOUT error.
• PCF treats the UpdateNotify message as Success. The pccRules are saved in SMPolicyAssociation database. The value of pendingConfirmationAction key is set to REMOVE.
• PCF sends a Abort Session Request (ASR) with SuppressASR disabled to AF/P-CSCF.
• AF/P-CSCF responds with Abort Session Answer (ASA).
• PCF receives a STR from AF/P-CSCF. PCF asynchronously responds with STA to AF/P-CSCF.
• PCF sends the UpdateNotify message to SMF for pccRule removal. SMF removes the pccRules and responds with a success message to PCF.

Figure 4-20 Handling Collision Between AAR-I, AAR-U, and STR Messages During UpdateNotify-Timeout Scenario with SupressASR Enabled

1. PCF receives an AAR-I from AF/P-CSCF and sends an UpdateNotify to SMF to install the pccRule.
2. If PCF does not receive the response from SMF, PCF retries to send the UpdateNotify message.
3. PCF treats the response to UpdateNotify as success. PCF saves the pccRules in SMPolicyAssociation database with the value of pendingConfirmationAction key set to INSTALL.
4. While awaiting the resonse for the UpdateNotify due to AAR-I from SMF, if PCF receives an AAR-U from AF/P-CSCF, PCF sends an UpdateNotify due to AAR-U to SMF.
5. PCF saves the pccRules in SMPolicyAssociation database with the value of pendingConfirmationAction key set to REINSTALL.
6. If SMF responds with a 204 SUCCESS message, PCF saves the pccRules in SMPolicyAssociation database and removes the PendingConfirmation key.
7. When PCF receives an STR message from AF/P-CSCF, PCF sends an UpdateNotify message to SMF to remove the pccRules.
8. If SMF responds to UpdateNotify with a 204 Success message, PCF removes the pccRules from SMPolicyAssociation database.

Managing Collision Between AAR and STR Messages During Update Notify Timeout

Enable

This feature can be enabled by configuring SYSTEM.RX.UPDATE_NOTIFY.RULES.PENDING_CONFIRMATION.ENABLED Advanced Settings Key under PCF Session Management page for Service Configurations in CNC Console. For more information, see PCF Session Management.

Configure

This feature can be configured using the following Advanced Settings Keys under PCF Session Management page for Service Configurations in CNC Console.

• SYSTEM.RX.UPDATE_NOTIFY.RULES.PENDING_CONFIRMATION.ENABLED
• SYSTEM.RX.UPDATE_NOTIFY.RULES.PENDING_CONFIRMATION.PROCESS_ON_UPDATE
• SYSTEM.RX.UPDATE_NOTIFY.RULES.PENDING_CONFIRMATION.RESPONSE_CODES
• SYSTEM.RX.UPDATE_NOTIFY.RULES.PENDING_CONFIRMATION.EXCEPTIONS

For more information, see PCF Session Management.

Observability

Metrics

This feature uses the following metrics:

• ocpm_handle_update_notify_timeout_as_pending_confirmation_total
• ocpm_handle_update_notify_error_response_as_pending_confirmation_total
• ocpm_process_pending_confirmation_rules_on_pa_update_total
• ocpm_process_pending_configuration_rules_on_pa_delete_total
• ocpm_rx_update_notify_request_total

For more information, see SM Service Metrics.

Alerts

This feature uses the following alerts:

• RX_PENDING_CONFIRMATION_UPDATE_NOTIFY_ERROR_RESPONSE_ABOVE_CRITICAL_THRESHOLD
• RX_PENDING_CONFIRMATION_UPDATE_NOTIFY_ERROR_RESPONSE_ABOVE_MAJOR_THRESHOLD
• RX_PENDING_CONFIRMATION_UPDATE_NOTIFY_ERROR_RESPONSE_ABOVE_MINOR_THRESHOLD
• RX_PENDING_CONFIRMATION_UPDATE_NOTIFY_TIMEOUT_ABOVE_CRITICAL_THRESHOLD
• RX_PENDING_CONFIRMATION_UPDATE_NOTIFY_TIMEOUT_ABOVE_MAJOR_THRESHOLD
• RX_PENDING_CONFIRMATION_UPDATE_NOTIFY_TIMEOUT_ABOVE_MINOR_THRESHOLD

For more information, see Common Alerts.

Logging

Policy logs collisions that occure when pccRule Removal is sent to SMF during UpdateNotify after timeouts occur for UpdateNotify for AAR messages.

Examples:

AAR-I/AAR-U update notify:

{
   "instant":{
      "epochSecond":1737588500,
      "nanoOfSecond":256798000
   },
   "thread":"boundedElastic-7",
   "level":"INFO",
   "loggerName":"ocpm.pcf.service.sm.serviceconnector.SmfConnector",
   "message":"Ready to send Update Notification to SMF: {\n  \"smPolicyDecision\" : {\n    \"pccRules\" : {\n      \"0_3\" : {\n        \"flowInfos\" : [ {\n          \"flowDescription\" : \"permit in 17 from 10.10.10.10 to 10.17.18.19 8001\",\n          \"flowDirection\" : \"UPLINK\"\n        }, {\n          \"flowDescription\" : \"permit out 17 from 10.17.18.19 to 10.10.10.10 8001\",\n          \"flowDirection\" : \"DOWNLINK\"\n        } ],\n        \"pccRuleId\" : \"0_3\",\n        \"precedence\" : 401,\n        \"refQosData\" : [ \"qosdata_2\" ],\n        \"refTcData\" : [ \"tcdata_1\" ]\n      },\n      \"0_2\" : {\n        \"flowInfos\" : [ {\n          \"flowDescription\" : \"permit in 17 from 10.10.10.10 to 10.17.18.19 8000\",\n          \"flowDirection\" : \"UPLINK\"\n        }, {\n          \"flowDescription\" : \"permit out 17 from 10.17.18.19 to 10.10.10.10 8000\",\n          \"flowDirection\" : \"DOWNLINK\"\n        } ],\n        \"pccRuleId\" : \"0_2\",\n        \"precedence\" : 400,\n        \"refQosData\" : [ \"qosdata_1\" ],\n        \"refTcData\" : [ \"tcdata_0\" ]\n      }\n    },\n    \"qosDecs\" : {\n      \"qosdata_1\" : {\n        \"5qi\" : 1,\n        \"qosId\" : \"qosdata_1\",\n        \"maxbrUl\" : \"12.0 Kbps\",\n        \"maxbrDl\" : \"12.0 Kbps\",\n        \"gbrUl\" : \"12.0 Kbps\",\n        \"gbrDl\" : \"12.0 Kbps\",\n        \"arp\" : {\n          \"priorityLevel\" : 15,\n          \"preemptCap\" : \"NOT_PREEMPT\",\n          \"preemptVuln\" : \"PREEMPTABLE\"\n        }\n      },\n      \"qosdata_2\" : {\n        \"5qi\" : 1,\n        \"qosId\" : \"qosdata_2\",\n        \"maxbrUl\" : \"600.0 bps\",\n        \"maxbrDl\" : \"600.0 bps\",\n        \"gbrUl\" : \"600.0 bps\",\n        \"gbrDl\" : \"600.0 bps\",\n        \"arp\" : {\n          \"priorityLevel\" : 15,\n          \"preemptCap\" : \"NOT_PREEMPT\",\n          \"preemptVuln\" : \"PREEMPTABLE\"\n        }\n      }\n    },\n    \"traffContDecs\" : {\n      \"tcdata_0\" : {\n        \"tcId\" : \"tcdata_0\",\n        \"flowStatus\" : \"ENABLED\"\n      },\n      \"tcdata_1\" : {\n        \"tcId\" : \"tcdata_1\",\n        \"flowStatus\" : \"ENABLED\"\n      }\n    },\n    \"policyCtrlReqTriggers\" : [ \"PLMN_CH\", \"UE_IP_CH\", \"DEF_QOS_CH\", \"AC_TY_CH\", \"SUCC_RES_ALLO\" ],\n    \"lastReqRuleData\" : [ {\n      \"refPccRuleIds\" : [ \"0_2\", \"0_3\" ],\n      \"reqData\" : [ \"SUCC_RES_ALLO\" ]\n    } ]\n  },\n  \"resourceUri\" : \"https://pcf_smservice.pcf:5805/npcf-smpolicycontrol/v1/sm-policies/1eb1b1bc-9e51-4ac0-ae38-13f21af05318_0_U1VQSTppbXNpLTQ1MDA4MTAwMDAwODAwMTs=\"\n}",
   "endOfBatch":false,
   "loggerFqcn":"org.apache.logging.slf4j.Log4jLogger",
   "threadId":293,
   "threadPriority":5,
   "messageTimestamp":"2025-01-22T17:28:20.256-0600",
   "ocLogId":"${ctx:ocLogId}"
}"TimeOut Exception	
Time Out"{
   "instant":{
      "epochSecond":1737588500,
      "nanoOfSecond":257747000
   },
   "thread":"boundedElastic-7",
   "level":"DEBUG",
   "loggerName":"ocpm.pcf.service.sm.domain.component.user.UserManager",
   "message":"process user service request",
   "endOfBatch":false,
   "loggerFqcn":"org.apache.logging.slf4j.Log4jLogger",
   "threadId":293,
   "threadPriority":5,
   "messageTimestamp":"2025-01-22T17:28:20.257-0600",
   "ocLogId":"${ctx:ocLogId}"
}{
   "instant":{
      "epochSecond":1737588500,
      "nanoOfSecond":257766000
   },
   "thread":"boundedElastic-7",
   "level":"DEBUG",
   "loggerName":"ocpm.pcf.service.sm.domain.component.user.UserManager",
   "message":"Processing Async policyCounterActions.",
   "endOfBatch":false,
   "loggerFqcn":"org.apache.logging.slf4j.Log4jLogger",
   "threadId":293,
   "threadPriority":5,
   "messageTimestamp":"2025-01-22T17:28:20.257-0600",
   "ocLogId":"${ctx:ocLogId}"
}{
   "instant":{
      "epochSecond":1737588503,
      "nanoOfSecond":261970000
   },
   "thread":"boundedElastic-7",
   "level":"WARN",
   "loggerName":"ocpm.pcf.util.StackTraceUtil",
   "message":"Failed to call SMF",
   "endOfBatch":false,
   "loggerFqcn":"org.apache.logging.slf4j.Log4jLogger",
   "threadId":293,
   "threadPriority":5,
   "messageTimestamp":"2025-01-22T17:28:23.261-0600",
   "triggerClass":"ocpm.pcf.service.sm.serviceconnector.SmfConnector",
   "errorName":"java.util.concurrent.TimeoutException",
   "errorMessage":"Did not observe any item or terminal signal within 3000ms in 'source(MonoDeferContextual)' (and no fallback has been configured)",
   "errorStack":"[reactor.core.publisher.FluxTimeout$TimeoutMainSubscriber.handleTimeout(FluxTimeout.java:295), reactor.core.publisher.FluxTimeout$TimeoutMainSubscriber.doTimeout(FluxTimeout.java:280), reactor.core.publisher.FluxTimeout$TimeoutTimeoutSubscriber.onNext(FluxTimeout.java:419), reactor.core.publisher.FluxOnErrorReturn$ReturnSubscriber.onNext(FluxOnErrorReturn.java:162), reactor.core.publisher.MonoDelay$MonoDelayRunnable.propagateDelay(MonoDelay.java:271), reactor.core.publisher.MonoDelay$MonoDelayRunnable.run(MonoDelay.java:286), reactor.core.scheduler.SchedulerTask.call(SchedulerTask.java:68), reactor.core.scheduler.SchedulerTask.call(SchedulerTask.java:28), io.micrometer.core.instrument.composite.CompositeTimer.recordCallable(CompositeTimer.java:129), io.micrometer.core.instrument.Timer.lambda$wrap$1(Timer.java:206), java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264), java.base/java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:304), java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136), java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635), java.base/java.lang.Thread.run(Thread.java:840)]"
}"Handling time out for Rx Collision	
Handle as Success"{
   "instant":{
      "epochSecond":1746472387,
      "nanoOfSecond":965052000
   },
   "thread":"boundedElastic-2",
   "level":"INFO",
   "loggerName":"ocpm.pcf.service.sm.domain.component.rule.PendingConfirmationRuleHelper",
   "message":"PccRules in Update Notify failure will be set as pendingConfirmation",
   "endOfBatch":false,
   "loggerFqcn":"org.apache.logging.slf4j.Log4jLogger",
   "threadId":95,
   "threadPriority":5,
   "messageTimestamp":"2025-05-05T13:13:07.965-0600",
   "ocLogId":"${ctx:ocLogId}"
}{
   "instant":{
      "epochSecond":1746472387,
      "nanoOfSecond":965553000
   },
   "thread":"boundedElastic-2",
   "level":"DEBUG",
   "loggerName":"ocpm.pcf.service.sm.domain.component.rule.PendingConfirmationRuleHelper",
   "message":"PccRule 0_3 set as pendingConfirmation",
   "endOfBatch":false,
   "loggerFqcn":"org.apache.logging.slf4j.Log4jLogger",
   "threadId":95,
   "threadPriority":5,
   "messageTimestamp":"2025-05-05T13:13:07.965-0600",
   "ocLogId":"${ctx:ocLogId}"
}{
   "instant":{
      "epochSecond":1746472387,
      "nanoOfSecond":965600000
   },
   "thread":"boundedElastic-2",
   "level":"DEBUG",
   "loggerName":"ocpm.pcf.service.sm.domain.component.rule.PendingConfirmationRuleHelper",
   "message":"PccRule 0_2 set as pendingConfirmation",
   "endOfBatch":false,
   "loggerFqcn":"org.apache.logging.slf4j.Log4jLogger",
   "threadId":95,
   "threadPriority":5,
   "messageTimestamp":"2025-05-05T13:13:07.965-0600",
   "ocLogId":"${ctx:ocLogId}"
}"Metric Pegged	
Metric"{
   "instant":{
      "epochSecond":1746472387,
      "nanoOfSecond":959692000
   },
   "thread":"boundedElastic-2",
   "level":"DEBUG",
   "loggerName":"ocpm.pcf.service.sm.domain.component.metrics.SmMetrics",
   "message":"Pegging Handle Update Notify timeout as Pending Confirmation metric, Operation Type: update_notify, Cause: Update Notify Time Out handled as PendingConfirmation",
   "endOfBatch":false,
   "loggerFqcn":"org.apache.logging.slf4j.Log4jLogger",
   "threadId":95,
   "threadPriority":5,
   "messageTimestamp":"2025-05-05T13:13:07.959-0600",
   "ocLogId":"${ctx:ocLogId}"
}"STR Update Notify (Rule Remove)	
STR Update Notify"{
   "instant":{
      "epochSecond":1746472392,
      "nanoOfSecond":580363000
   },
   "thread":"boundedElastic-2",
   "level":"DEBUG",
   "loggerName":"ocpm.pcf.service.sm.domain.component.metrics.SmMetrics",
   "message":"Pegging Sent pending confirmation rules to remove metric, Operation Type: update_notify",
   "endOfBatch":false,
   "loggerFqcn":"org.apache.logging.slf4j.Log4jLogger",
   "threadId":95,
   "threadPriority":5,
   "messageTimestamp":"2025-05-05T13:13:12.580-0600",
   "ocLogId":"${ctx:ocLogId}"
}{
   "instant":{
      "epochSecond":1746472392,
      "nanoOfSecond":580524000
   },
   "thread":"boundedElastic-2",
   "level":"INFO",
   "loggerName":"ocpm.pcf.service.sm.serviceconnector.SmfConnector",
   "message":"Ready to send Update Notification to SMF: {\n  \"smPolicyDecision\" : {\n    \"pccRules\" : {\n      \"0_2\" : null,\n      \"0_3\" : null\n    },\n    \"qosDecs\" : {\n      \"qosdata_1\" : null,\n      \"qosdata_2\" : null\n    },\n    \"traffContDecs\" : {\n      \"tcdata_0\" : null,\n      \"tcdata_1\" : null\n    }\n  },\n  \"resourceUri\" : \"https://pcf_smservice.pcf:5805/npcf-smpolicycontrol/v1/sm-policies/00ec301a-77eb-4536-aea1-394a6f33ea00_0_U1VQSTppbXNpLTQ1MDA4MTAwMDAwODAwMTs=\"\n}",
   "endOfBatch":false,
   "loggerFqcn":"org.apache.logging.slf4j.Log4jLogger",
   "threadId":95,
   "threadPriority":5,
   "messageTimestamp":"2025-05-05T13:13:12.580-0600",
   "ocLogId":"${ctx:ocLogId}"
}"ASR	
ASR"{
   "instant":{
      "epochSecond":1746472387,
      "nanoOfSecond":978063000
   },
   "thread":"boundedElastic-2",
   "level":"INFO",
   "loggerName":"ocpm.pcf.service.pa.serviceconnector.AfConnector",
   "message":"Sent Termination Notification to AF: http://localhost:1080/smservicenotify/terminate, \n class TerminationInfo {\n    termCause: ALL_SDF_DEACTIVATION\n    resUri: https://pcf_smservice.pcf:5805/npcf-policyauthorization/v1/app-sessions/6f3f0561-3365-4516-886b-831833b6ac74\n}",
   "endOfBatch":false,
   "loggerFqcn":"org.apache.logging.slf4j.Log4jLogger",
   "threadId":95,
   "threadPriority":5,
   "messageTimestamp":"2025-05-05T13:13:07.978-0600",
   "ocLogId":"${ctx:ocLogId}"
}{
   "instant":{
      "epochSecond":1746472387,
      "nanoOfSecond":978165000
   },
   "thread":"boundedElastic-2",
   "level":"DEBUG",
   "loggerName":"ocpm.pcf.service.sm.domain.component.pcrt.PolicyTriggerManager",
   "message":"Details for appSession are: AppSessionImpl{appSessionContext=class AppSessionContext {\n    ascReqData: class AppSessionContextReqData {\n        afAppId: urn:urn-7:3gpp-service.ims.icsi.mmtel\n        afRoutReq: Optional.empty\n        aspId: null\n        bdtRefId: null\n        dnn: null\n        evSubsc: Optional[class EventsSubscReqData {\n            events: [class AfEventSubscription {\n                event: FAILED_RESOURCES_ALLOCATION\n                notifMethod: EVENT_DETECTION\n            }]\n            notifUri: http://localhost:1080/smservicenotify/\n            usgThres: null\n            reqAnis: null\n        }]\n        medComponents: null\n        ipDomain: null\n        mpsId: null\n        notifUri: http://localhost:1080/smservicenotify/\n        sliceInfo: null\n        sponId: null\n        sponStatus: null\n        supi: null\n        suppFeat: 10\n        ueIpv4: 192.168.10.10\n        ueIpv6: null\n        ueMac: null\n        serviceUrn: null\n        servInfStatus: null\n        liIndicatorEncrypted: null\n        authorizationLifetime: null\n    }\n    ascRespData: class AppSessionContextRespData {\n        servAuthInfo: null\n        suppFeat: 10\n    }\n    evsNotif: null\n}, smPolicyAssociationId='00ec301a-77eb-4536-aea1-394a6f33ea00_0_U1VQSTppbXNpLTQ1MDA4MTAwMDAwODAwMTs=', emergencyServiceUrn=false, flowMetadatas={1.1=ocpm.pcf.service.pa.domain.model.FlowMetadata@442b970, 1.2=ocpm.pcf.service.pa.domain.model.FlowMetadata@3baab8ae}, AssociationImpl{associationId='6f3f0561-3365-4516-886b-831833b6ac74', supportedFeatures='10', supportedFeatureBits={4}, variables=null, routingContexts=null, sbiBinding={}, prodNfInstId=null, nfInstanceId=fe7d992b-0541-4c7d-ab84-c6d70b1b0123, sbiCorrelationInfoHeader=null}}",
   "endOfBatch":false,
   "loggerFqcn":"org.apache.logging.slf4j.Log4jLogger",
   "threadId":95,
   "threadPriority":5,
   "messageTimestamp":"2025-05-05T13:13:07.978-0600",
   "ocLogId":"${ctx:ocLogId}"
}"Policy Decision  after AAR-I	
SmPolicy Association After AAR-I Collapse source""sessRules":{
   "0_1":{
      "authSessAmbr":{
         "uplink":"500.0 Kbps",
         "downlink":"1.0 Mbps"
      },
      "authDefQos":{
         "5qi":5,
         "arp":{
            "priorityLevel":1,
            "preemptCap":"NOT_PREEMPT",
            "preemptVuln":"NOT_PREEMPTABLE"
         },
         "priorityLevel":2
      },
      "sessRuleId":"0_1"
   }
},
"pccRules":{
   "0_0":{
      "flowInfos":[
         {
            "flowDescription":"permit in ip from any to any",
            "flowDirection":"UPLINK"
         },
         {
            "flowDescription":"permit out ip from any to any",
            "flowDirection":"DOWNLINK"
         }
      ],
      "pccRuleId":"0_0",
      "precedence":3000,
      "refQosData":[
         "qosdata_0"
      ],
      "pendingConfirmationAction":0
   },
   "0_2":{
      "flowInfos":[
         {
            "flowDescription":"permit in 17 from 10.10.10.10 to 10.17.18.19 8000",
            "flowDirection":"UPLINK"
         },
         {
            "flowDescription":"permit out 17 from 10.17.18.19 to 10.10.10.10 8000",
            "flowDirection":"DOWNLINK"
         }
      ],
      "pccRuleId":"0_2",
      "precedence":400,
      "refQosData":[
         "qosdata_1"
      ],
      "refTcData":[
         "tcdata_0"
      ],
      "pendingConfirmationAction":2
   },
   "0_3":{
      "flowInfos":[
         {
            "flowDescription":"permit in 17 from 10.10.10.10 to 10.17.18.19 8001",
            "flowDirection":"UPLINK"
         },
         {
            "flowDescription":"permit out 17 from 10.17.18.19 to 10.10.10.10 8001",
            "flowDirection":"DOWNLINK"
         }
      ],
      "pccRuleId":"0_3",
      "precedence":401,
      "refQosData":[
         "qosdata_2"
      ],
      "refTcData":[
         "tcdata_1"
      ],
      "pendingConfirmationAction":2
   }
},
"qosDecs":{
   "qosdata_0":{
      "5qi":5,
      "qosId":"qosdata_0",
      "arp":{
         "priorityLevel":1,
         "preemptCap":"NOT_PREEMPT",
         "preemptVuln":"NOT_PREEMPTABLE"
      },
      "priorityLevel":2
   },
   "qosdata_1":{
      "5qi":1,
      "qosId":"qosdata_1",
      "maxbrUl":"12.0 Kbps",
      "maxbrDl":"12.0 Kbps",
      "gbrUl":"12.0 Kbps",
      "gbrDl":"12.0 Kbps",
      "arp":{
         "priorityLevel":15,
         "preemptCap":"NOT_PREEMPT",
         "preemptVuln":"PREEMPTABLE"
      }
   },
   "qosdata_2":{
      "5qi":1,
      "qosId":"qosdata_2",
      "maxbrUl":"600.0 bps",
      "maxbrDl":"600.0 bps",
      "gbrUl":"600.0 bps",
      "gbrDl":"600.0 bps",
      "arp":{
         "priorityLevel":15,
         "preemptCap":"NOT_PREEMPT",
         "preemptVuln":"PREEMPTABLE"
      }
   }
},
"chgDecs":{
   
},
"traffContDecs":{
   "tcdata_0":{
      "tcId":"tcdata_0",
      "flowStatus":"ENABLED"
   },
   "tcdata_1":{
      "tcId":"tcdata_1",
      "flowStatus":"ENABLED"
   }
},
"conds":{
   
},
"policyCtrlReqTriggers":[
   "PLMN_CH",
   "UE_IP_CH",
   "DEF_QOS_CH",
   "AC_TY_CH"
]
}

Timeout exception:

{
   "instant":{
      "epochSecond":1737588500,
      "nanoOfSecond":257747000
   },
   "thread":"boundedElastic-7",
   "level":"DEBUG",
   "loggerName":"ocpm.pcf.service.sm.domain.component.user.UserManager",
   "message":"process user service request",
   "endOfBatch":false,
   "loggerFqcn":"org.apache.logging.slf4j.Log4jLogger",
   "threadId":293,
   "threadPriority":5,
   "messageTimestamp":"2025-01-22T17:28:20.257-0600",
   "ocLogId":"${ctx:ocLogId}"
}{
   "instant":{
      "epochSecond":1737588500,
      "nanoOfSecond":257766000
   },
   "thread":"boundedElastic-7",
   "level":"DEBUG",
   "loggerName":"ocpm.pcf.service.sm.domain.component.user.UserManager",
   "message":"Processing Async policyCounterActions.",
   "endOfBatch":false,
   "loggerFqcn":"org.apache.logging.slf4j.Log4jLogger",
   "threadId":293,
   "threadPriority":5,
   "messageTimestamp":"2025-01-22T17:28:20.257-0600",
   "ocLogId":"${ctx:ocLogId}"
}{
   "instant":{
      "epochSecond":1737588503,
      "nanoOfSecond":261970000
   },
   "thread":"boundedElastic-7",
   "level":"WARN",
   "loggerName":"ocpm.pcf.util.StackTraceUtil",
   "message":"Failed to call SMF",
   "endOfBatch":false,
   "loggerFqcn":"org.apache.logging.slf4j.Log4jLogger",
   "threadId":293,
   "threadPriority":5,
   "messageTimestamp":"2025-01-22T17:28:23.261-0600",
   "triggerClass":"ocpm.pcf.service.sm.serviceconnector.SmfConnector",
   "errorName":"java.util.concurrent.TimeoutException",
   "errorMessage":"Did not observe any item or terminal signal within 3000ms in 'source(MonoDeferContextual)' (and no fallback has been configured)",
   "errorStack":"[reactor.core.publisher.FluxTimeout$TimeoutMainSubscriber.handleTimeout(FluxTimeout.java:295), reactor.core.publisher.FluxTimeout$TimeoutMainSubscriber.doTimeout(FluxTimeout.java:280), reactor.core.publisher.FluxTimeout$TimeoutTimeoutSubscriber.onNext(FluxTimeout.java:419), reactor.core.publisher.FluxOnErrorReturn$ReturnSubscriber.onNext(FluxOnErrorReturn.java:162), reactor.core.publisher.MonoDelay$MonoDelayRunnable.propagateDelay(MonoDelay.java:271), reactor.core.publisher.MonoDelay$MonoDelayRunnable.run(MonoDelay.java:286), reactor.core.scheduler.SchedulerTask.call(SchedulerTask.java:68), reactor.core.scheduler.SchedulerTask.call(SchedulerTask.java:28), io.micrometer.core.instrument.composite.CompositeTimer.recordCallable(CompositeTimer.java:129), io.micrometer.core.instrument.Timer.lambda$wrap$1(Timer.java:206), java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264), java.base/java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:304), java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136), java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635), java.base/java.lang.Thread.run(Thread.java:840)]"
}

Handling timeout for Rx collision:

{
   "instant":{
      "epochSecond":1746472387,
      "nanoOfSecond":965052000
   },
   "thread":"boundedElastic-2",
   "level":"INFO",
   "loggerName":"ocpm.pcf.service.sm.domain.component.rule.PendingConfirmationRuleHelper",
   "message":"PccRules in Update Notify failure will be set as pendingConfirmation",
   "endOfBatch":false,
   "loggerFqcn":"org.apache.logging.slf4j.Log4jLogger",
   "threadId":95,
   "threadPriority":5,
   "messageTimestamp":"2025-05-05T13:13:07.965-0600",
   "ocLogId":"${ctx:ocLogId}"
}{
   "instant":{
      "epochSecond":1746472387,
      "nanoOfSecond":965553000
   },
   "thread":"boundedElastic-2",
   "level":"DEBUG",
   "loggerName":"ocpm.pcf.service.sm.domain.component.rule.PendingConfirmationRuleHelper",
   "message":"PccRule 0_3 set as pendingConfirmation",
   "endOfBatch":false,
   "loggerFqcn":"org.apache.logging.slf4j.Log4jLogger",
   "threadId":95,
   "threadPriority":5,
   "messageTimestamp":"2025-05-05T13:13:07.965-0600",
   "ocLogId":"${ctx:ocLogId}"
}{
   "instant":{
      "epochSecond":1746472387,
      "nanoOfSecond":965600000
   },
   "thread":"boundedElastic-2",
   "level":"DEBUG",
   "loggerName":"ocpm.pcf.service.sm.domain.component.rule.PendingConfirmationRuleHelper",
   "message":"PccRule 0_2 set as pendingConfirmation",
   "endOfBatch":false,
   "loggerFqcn":"org.apache.logging.slf4j.Log4jLogger",
   "threadId":95,
   "threadPriority":5,
   "messageTimestamp":"2025-05-05T13:13:07.965-0600",
   "ocLogId":"${ctx:ocLogId}"
}

{"instant":{"epochSecond":1738790542,"nanoOfSecond":924361000},"thread":"boundedElastic-4","level":"DEBUG","loggerName":"ocpm.pcf.service.sm.serviceconnector.SmfConnector","message":"PccRules [0_2, 0_3] added to be removed by STR as TimeOut happened","endOfBatch":false,"loggerFqcn":"org.apache.logging.slf4j.Log4jLogger","threadId":106,"threadPriority":5,"messageTimestamp":"2025-02-05T15:22:22.924-0600","ocLogId":"${ctx:ocLogId}"}

Metric pegged:

{
   "instant":{
      "epochSecond":1746472387,
      "nanoOfSecond":959692000
   },
   "thread":"boundedElastic-2",
   "level":"DEBUG",
   "loggerName":"ocpm.pcf.service.sm.domain.component.metrics.SmMetrics",
   "message":"Pegging Handle Update Notify timeout as Pending Confirmation metric, Operation Type: update_notify, Cause: Update Notify Time Out handled as PendingConfirmation",
   "endOfBatch":false,
   "loggerFqcn":"org.apache.logging.slf4j.Log4jLogger",
   "threadId":95,
   "threadPriority":5,
   "messageTimestamp":"2025-05-05T13:13:07.959-0600",
   "ocLogId":"${ctx:ocLogId}"
}

STR update notify:

{
   "instant":{
      "epochSecond":1746472392,
      "nanoOfSecond":580363000
   },
   "thread":"boundedElastic-2",
   "level":"DEBUG",
   "loggerName":"ocpm.pcf.service.sm.domain.component.metrics.SmMetrics",
   "message":"Pegging Sent pending confirmation rules to remove metric, Operation Type: update_notify",
   "endOfBatch":false,
   "loggerFqcn":"org.apache.logging.slf4j.Log4jLogger",
   "threadId":95,
   "threadPriority":5,
   "messageTimestamp":"2025-05-05T13:13:12.580-0600",
   "ocLogId":"${ctx:ocLogId}"
}{
   "instant":{
      "epochSecond":1746472392,
      "nanoOfSecond":580524000
   },
   "thread":"boundedElastic-2",
   "level":"INFO",
   "loggerName":"ocpm.pcf.service.sm.serviceconnector.SmfConnector",
   "message":"Ready to send Update Notification to SMF: {\n  \"smPolicyDecision\" : {\n    \"pccRules\" : {\n      \"0_2\" : null,\n      \"0_3\" : null\n    },\n    \"qosDecs\" : {\n      \"qosdata_1\" : null,\n      \"qosdata_2\" : null\n    },\n    \"traffContDecs\" : {\n      \"tcdata_0\" : null,\n      \"tcdata_1\" : null\n    }\n  },\n  \"resourceUri\" : \"https://pcf_smservice.pcf:5805/npcf-smpolicycontrol/v1/sm-policies/00ec301a-77eb-4536-aea1-394a6f33ea00_0_U1VQSTppbXNpLTQ1MDA4MTAwMDAwODAwMTs=\"\n}",
   "endOfBatch":false,
   "loggerFqcn":"org.apache.logging.slf4j.Log4jLogger",
   "threadId":95,
   "threadPriority":5,
   "messageTimestamp":"2025-05-05T13:13:12.580-0600",
   "ocLogId":"${ctx:ocLogId}"
}

ASR

{
   "instant":{
      "epochSecond":1746472387,
      "nanoOfSecond":978063000
   },
   "thread":"boundedElastic-2",
   "level":"INFO",
   "loggerName":"ocpm.pcf.service.pa.serviceconnector.AfConnector",
   "message":"Sent Termination Notification to AF: http://localhost:1080/smservicenotify/terminate, \n class TerminationInfo {\n    termCause: ALL_SDF_DEACTIVATION\n    resUri: https://pcf_smservice.pcf:5805/npcf-policyauthorization/v1/app-sessions/6f3f0561-3365-4516-886b-831833b6ac74\n}",
   "endOfBatch":false,
   "loggerFqcn":"org.apache.logging.slf4j.Log4jLogger",
   "threadId":95,
   "threadPriority":5,
   "messageTimestamp":"2025-05-05T13:13:07.978-0600",
   "ocLogId":"${ctx:ocLogId}"
}{
   "instant":{
      "epochSecond":1746472387,
      "nanoOfSecond":978165000
   },
   "thread":"boundedElastic-2",
   "level":"DEBUG",
   "loggerName":"ocpm.pcf.service.sm.domain.component.pcrt.PolicyTriggerManager",
   "message":"Details for appSession are: AppSessionImpl{appSessionContext=class AppSessionContext {\n    ascReqData: class AppSessionContextReqData {\n        afAppId: urn:urn-7:3gpp-service.ims.icsi.mmtel\n        afRoutReq: Optional.empty\n        aspId: null\n        bdtRefId: null\n        dnn: null\n        evSubsc: Optional[class EventsSubscReqData {\n            events: [class AfEventSubscription {\n                event: FAILED_RESOURCES_ALLOCATION\n                notifMethod: EVENT_DETECTION\n            }]\n            notifUri: http://localhost:1080/smservicenotify/\n            usgThres: null\n            reqAnis: null\n        }]\n        medComponents: null\n        ipDomain: null\n        mpsId: null\n        notifUri: http://localhost:1080/smservicenotify/\n        sliceInfo: null\n        sponId: null\n        sponStatus: null\n        supi: null\n        suppFeat: 10\n        ueIpv4: 192.168.10.10\n        ueIpv6: null\n        ueMac: null\n        serviceUrn: null\n        servInfStatus: null\n        liIndicatorEncrypted: null\n        authorizationLifetime: null\n    }\n    ascRespData: class AppSessionContextRespData {\n        servAuthInfo: null\n        suppFeat: 10\n    }\n    evsNotif: null\n}, smPolicyAssociationId='00ec301a-77eb-4536-aea1-394a6f33ea00_0_U1VQSTppbXNpLTQ1MDA4MTAwMDAwODAwMTs=', emergencyServiceUrn=false, flowMetadatas={1.1=ocpm.pcf.service.pa.domain.model.FlowMetadata@442b970, 1.2=ocpm.pcf.service.pa.domain.model.FlowMetadata@3baab8ae}, AssociationImpl{associationId='6f3f0561-3365-4516-886b-831833b6ac74', supportedFeatures='10', supportedFeatureBits={4}, variables=null, routingContexts=null, sbiBinding={}, prodNfInstId=null, nfInstanceId=fe7d992b-0541-4c7d-ab84-c6d70b1b0123, sbiCorrelationInfoHeader=null}}",
   "endOfBatch":false,
   "loggerFqcn":"org.apache.logging.slf4j.Log4jLogger",
   "threadId":95,
   "threadPriority":5,
   "messageTimestamp":"2025-05-05T13:13:07.978-0600",
   "ocLogId":"${ctx:ocLogId}"
}

SMPolicyAssociation after AAR-I:

"sessRules": {
    "0_1": {
      "authSessAmbr": {
        "uplink": "500.0 Kbps",
        "downlink": "1.0 Mbps"
      },
      "authDefQos": {
        "5qi": 5,
        "arp": {
          "priorityLevel": 1,
          "preemptCap": "NOT_PREEMPT",
          "preemptVuln": "NOT_PREEMPTABLE"
        },
        "priorityLevel": 2
      },
      "sessRuleId": "0_1"
    }
  },
  "pccRules": {
    "0_0": {
      "flowInfos": [
        {
          "flowDescription": "permit in ip from any to any",
          "flowDirection": "UPLINK"
        },
        {
          "flowDescription": "permit out ip from any to any",
          "flowDirection": "DOWNLINK"
        }
      ],
      "pccRuleId": "0_0",
      "precedence": 3000,
      "refQosData": [
        "qosdata_0"
      ],
      "pendingConfirmationAction": 0
    },
    "0_2": {
      "flowInfos": [
        {
          "flowDescription": "permit in 17 from 10.10.10.10 to 10.17.18.19 8000",
          "flowDirection": "UPLINK"
        },
        {
          "flowDescription": "permit out 17 from 10.17.18.19 to 10.10.10.10 8000",
          "flowDirection": "DOWNLINK"
        }
      ],
      "pccRuleId": "0_2",
      "precedence": 400,
      "refQosData": [
        "qosdata_1"
      ],
      "refTcData": [
        "tcdata_0"
      ],
      "pendingConfirmationAction": 2
    },
    "0_3": {
      "flowInfos": [
        {
          "flowDescription": "permit in 17 from 10.10.10.10 to 10.17.18.19 8001",
          "flowDirection": "UPLINK"
        },
        {
          "flowDescription": "permit out 17 from 10.17.18.19 to 10.10.10.10 8001",
          "flowDirection": "DOWNLINK"
        }
      ],
      "pccRuleId": "0_3",
      "precedence": 401,
      "refQosData": [
        "qosdata_2"
      ],
      "refTcData": [
        "tcdata_1"
      ],
      "pendingConfirmationAction": 2
    }
  },
  "qosDecs": {
    "qosdata_0": {
      "5qi": 5,
      "qosId": "qosdata_0",
      "arp": {
        "priorityLevel": 1,
        "preemptCap": "NOT_PREEMPT",
        "preemptVuln": "NOT_PREEMPTABLE"
      },
      "priorityLevel": 2
    },
    "qosdata_1": {
      "5qi": 1,
      "qosId": "qosdata_1",
      "maxbrUl": "12.0 Kbps",
      "maxbrDl": "12.0 Kbps",
      "gbrUl": "12.0 Kbps",
      "gbrDl": "12.0 Kbps",
      "arp": {
        "priorityLevel": 15,
        "preemptCap": "NOT_PREEMPT",
        "preemptVuln": "PREEMPTABLE"
      }
    },
    "qosdata_2": {
      "5qi": 1,
      "qosId": "qosdata_2",
      "maxbrUl": "600.0 bps",
      "maxbrDl": "600.0 bps",
      "gbrUl": "600.0 bps",
      "gbrDl": "600.0 bps",
      "arp": {
        "priorityLevel": 15,
        "preemptCap": "NOT_PREEMPT",
        "preemptVuln": "PREEMPTABLE"
      }
    }
  },
  "chgDecs": {
  },
  "traffContDecs": {
    "tcdata_0": {
      "tcId": "tcdata_0",
      "flowStatus": "ENABLED"
    },
    "tcdata_1": {
      "tcId": "tcdata_1",
      "flowStatus": "ENABLED"
    }
  },
  "conds": {
  },
  "policyCtrlReqTriggers": [
    "PLMN_CH",
    "UE_IP_CH",
    "DEF_QOS_CH",
    "AC_TY_CH"
  ]
}

SmPolicy Association after STR

{
  "httpRequest" : {
    "method" : "POST",
    "path" : "/smf/notify/update",
    "body" : {
      "smPolicyDecision" : {
        "pccRules" : {
          "0_2" : null
        },
        "qosDecs" : {
          "qosdata_1" : null
        },
        "traffContDecs" : {
          "tcdata_0" : null
        }
      }
    }
  },
  "httpResponse" : {
    "statusCode" : 204
  },
  "id" : "smfRequest",
  "priority" : 1,
  "timeToLive" : {
    "unlimited" : true
  },
  "times" : {
    "unlimited" : true
  }
} ]
13:13:12.522 [main] INFO  c.intuit.karate.core.FeatureRuntime - classpath:ocpm/contract/test/core/contract.feature - call by tag at line 3563: name=deleteAppSession
13:13:12.525 [main] DEBUG com.intuit.karate - request:
1 > POST http://localhost:8080/npcf-policyauthorization/v1/app-sessions/6f3f0561-3365-4516-886b-831833b6ac74/delete
1 > Content-Type: application/json; charset=UTF-8
1 > Content-Length: 102
1 > Host: localhost:8080
1 > Connection: Keep-Alive
1 > User-Agent: Apache-HttpClient/4.5.13 (Java/17.0.12)
1 > Accept-Encoding: gzip,deflate
{"events":null,"notifUri":"http:\/\/localhost:1080\/smservicenotify\/","usgThres":null,"reqAnis":null}
 
13:13:12.580 [main] DEBUG com.intuit.karate - response time in milliseconds: 54
1 < 204
1 < Date: Mon, 05 May 2025 19:13:12 GMT
 
13:13:12.581 [main] INFO  contract.test.util.common.JavaUtil - Delay: 3sec
13:13:15.612 [main] INFO  contract.test.util.common.HttpUtils - VerifyMetric occnp_http_out_conn_response_total with params operationType="update_notify",responseCode="204": 1.0 - 0.0 == 1.0
13:13:15.613 [main] INFO  contract.test.util.common.HttpUtils - VerifyMetric ocpm_egress_request_total with params operation_type="update_notify": 2.0 - 1.0 == 1.0
13:13:15.613 [main] DEBUG c.intuit.karate.core.ScenarioEngine - over-writing existing variable 'SmSession' with new value: JSON.parse(util.db.readValue("select v from SmPolicyAssociation where k='" + smPolicyId + "'"))
13:13:15.632 [main] INFO  com.intuit.karate - [print] {
  "sessRules": {
    "0_1": {
      "authSessAmbr": {
        "uplink": "500.0 Kbps",
        "downlink": "1.0 Mbps"
      },
      "authDefQos": {
        "5qi": 5,
        "arp": {
          "priorityLevel": 1,
          "preemptCap": "NOT_PREEMPT",
          "preemptVuln": "NOT_PREEMPTABLE"
        },
        "priorityLevel": 2
      },
      "sessRuleId": "0_1"
    }
  },
  "pccRules": {
    "0_0": {
      "flowInfos": [
        {
          "flowDescription": "permit in ip from any to any",
          "flowDirection": "UPLINK"
        },
        {
          "flowDescription": "permit out ip from any to any",
          "flowDirection": "DOWNLINK"
        }
      ],
      "pccRuleId": "0_0",
      "precedence": 3000,
      "refQosData": [
        "qosdata_0"
      ],
      "pendingConfirmationAction": 0
    }
  },
  "qosDecs": {
    "qosdata_0": {
      "5qi": 5,
      "qosId": "qosdata_0",
      "arp": {
        "priorityLevel": 1,
        "preemptCap": "NOT_PREEMPT",
        "preemptVuln": "NOT_PREEMPTABLE"
      },
      "priorityLevel": 2
    }
  },
  "chgDecs": {
  },
  "traffContDecs": {
  },
  "conds": {
  },
  "policyCtrlReqTriggers": [
    "PLMN_CH",
    "UE_IP_CH",
    "DEF_QOS_CH",
    "AC_TY_CH"
  ]
}

SMPolicyAssociation after STR:

4.7 Supports Reattempt after Back-off during N1N2 Communication

The UE Policy Association procedure involves the AMF establishing a relationship with the PCF to deliver UE specific policies. PCF evaluates the relevant policies to determine the URSP rules that need to be sent to the UE. Before sending the URSP rules, PCF subscribes to the AMF by invoking N1N2Communication request. This step ensures that PCF can communicate with the appropriate AMF. To find the correct AMF, PCF uses the Nnrf_NFdiscovery service, which identifies the available AMF instances in the network. Following the successful AMF discovery and subscription, PCF sends the URSP rules to the UE through the N1N2MessageTransfer request. If any part of the procedure, such as the AMF discovery, subscription process or URSP transfer fails, then the overall URSP transfer will not be successful. This shows the importance of each of these procedures, as they are integral to successful N1N2Communication.

PCF supports multiple N1N2 Communication attempts that would help in successful delivery of URSP rules to UE. Since this procedure also has AMF Discovery, N1N2Subscription, and N1N2Transfer requests the reattempt is applied to them too.

The following flowchart illustrates the sequence of retry and reattempt mechanism as applied to a NF service operation.

Figure 4-21 Reattempt Flow Chart

On external trigger, a UE Policy management procedure is initiated and a procedure is attempted, and if that procedure fails retry mechanism kicks in. If the retry is applicable the failed procedure is retried. If this still fails and all the retries are exhausted, then reattempt is considered. So if the reattempt is applicable according to the reattempt profile, UE service will schedule a timer with audit service.

The PCF starts a back-off timer. The length of this timer exponentially increases based on the number of failed attempts. After the timer elapses, the PCF attempts to re-send the request. If successful, the process ends. If it fails again, the back-off timer is reset, and the retries continue until a maximum number of attempts is reached.

UE service uses reattempt mechanism on NFDiscover, N1N2MessageSubscribe, and N1N2MessageTransfer in UE policy management procedure. The following call flow illustrates the reattempt of UE policy management with back-off feature getting triggered during N1N2 message failures.

Figure 4-22 Reattempt and backoff Call flow

• PCF sends NFDiscover request to NRF.
• On success the procedure continues. On failure, PCF reattempts the UE policy management with back-off.
• PCF sends N1N2MessageSubscribe request to AMF.
• On success the procedure continues. On failure, PCF reattempts the UE policy management with back-off.
• PCF sends N1N2MessageTransfer request to AMF.
• On success the procedure continues. On failure, PCF reattempts the UE policy management with back-off.

Reattempts for NFDiscover, N1N2MessageSubscribe and N1N2MessageTransfer

Back-off is a rate limiting strategy that allows for dynamic rate limits, where the delay increases with each retry. When a request is rejected due to the rate limit, the back-off timer waits before attempting to retry the request.

The PCF uses a randomized backoff timer instead of a constant or linear one. This helps to resolve the "thundering herd" problem, which occurs when many clients attempt to reconnect at same time. The PCF throttles all reattempts after the configured threshold limit level, this typically involves rate limiting which sets a maximum number attempts allowed within a specific time frame. The configured threshold limit applies globally, restricting the total number of requests across PCF rather than just applying on individual services like UE or AM. Hence, in reattempt profile, the threshold limit level is confined to max 360K combined for all NF operations.

The Reattempt are configurable for AMF and NRF interfaces and is defined using existing Reattempt profile. The existing Reattempts Profile is enhanced to create reattempt profiles to AMF interface for N1N2 Subscribe, N1N2 Transfer, N1N2 Failure Notification operations. The reattempt profile can also be created to NRF interface for AMF Discovery operation. For each NF operations, user can configure maximum number of retry attempts and backoff timer for each retry. Retrying can also be enabled for internal failures, such as timeout exceptions or no response from the AMF, and just not for the service timeouts.

Note:

In reattempt profile threshold limit level is confined to max 360K combined for all NF operations.

The reattempt profile can be configured to retry for specific error codes and its causes.

The following fields are added or modified in Reattempts Profile in CNC Console that allows you to create new, and manage existing reattempt profiles for AMF and NRF interfaces and this get listed in the NF Communication Profiles page in CNC Console.

Table 4-13 Reattempts Profile

Field Name	Value
Interface Type	This field is modified to support AMF and NRF interface types.
Re-attempt Settings: Maximum Number of Attempts	This field is modified to configure maximum number of reattempts that are allowed for AMF or NRF service operation.
Re-attempt Settings: Back-off timer configurations	This field is added to provide specific configurations for back-off timer such as Index, Back-Off Timer (Seconds), and Max Random Number (Millisecond).
Re-attempt Settings: Threshold Limit Level	This field is modified to configure the threshold limit for timers that can be backed off for reattempt in case of either AMF or NRF operations. Note: The threshold limit level is confined to max 360K combined for all NF operations.
Re-attempt Error Code Settings: Enable Reattempt On Internal Failure	This field is added to determines whether to perform reattempt in occurrence of internal failures for either AMF or NRF operations.
Re-attempt Error Code Settings: Re-attempt for Following Error Codes	This field is added to configure the list of combination of HTTP Error Code and Error Cause for reattempt after back off.
Rate Limiting Settings: Rate Limit (per second)	This field is added to configure the rate limit threshold per second for NF service operation(s).

Note:

The Rate Limit (per second) field can be set to numerical value ranging from 0 - 700. But it is recommended to keep this value above or equal to 100 requests per second. The timer expiry notification rate should be more than the allowed timer creation time so as to prevent the creation of backlogs which will cause a delay in timer expiry notification reaching the UE service.

The NF Communication profile Re-attempt Settings section allows to enable the reattempts and select from the created reattempt profiles for specific NF operations. The following fields are added to support reattempts for AMF and NRF interfaces in NF Communication Profiles page in CNC Console.

Table 4-14 NF Communication Profiles

Field Name	Value
Re-attempt Settings	Provide Re-attempt Settings details:
Enable NF Service Operation Re-attempt	false
NF Service Operation Profiles	NAS operations: AMF Discovery N1N2 Message Subscribe N1N2 Message Transfer N1N2 Transfer Failure Notification

The created NF communication profile comprising of reattempt profile gets listed in the PCF UE Policy Service configurations page in CNC Console.

With rate limiting mechanism the UE slows down the rate of requests toward AMF after getting a server error. If PCF receives a "Retry-After IE" from AMF, its value is compared with the configured backoff timer, and which ever is the greater, it is used to set the timer.

Note:

The PCF does not consider "Retry-After" header from AMF or SCP or NRF.

Timer Service

The PCF Audit service is enhanced to provide Timer service providing a one-shot timer i.e. one time use. It manages the life cycle of a scheduled timer. The consuming service has to schedule a new timer once the timer is notifier or canceled. Timer service uses a pre-defined database table for managing the timers as defined by the audit service. The Timer service performs the database table polling using in-memory process of the pod for short timers

Timer service provides scheduling of Short timer and Long timer. Short timer are timers that expires within five minutes of their creation. The five minutes being default value and configurable. Any timer which is not a Short timer is a Long timer. The Short timers are scheduled at the creation timer, whereas the Long timer are scheduled during the scan time when they are close to expiring.

By default, the timer service is disabled. The timer service can be enabled or disabled at Timer Service page in CNC Console.

The below diagram provides an overview of the Timer service:

Figure 4-23 Timer Service Overview

Rate Limiting: The notification requests sent on timer expiry are rate limited. To perform rate limiting of timer notification, the rate limiting configuration is split across pods. For example, if there are 2 pods and rate limit is set to 1000 requests per second, then each pod performs rate limiting of 500 requests per second. This ensures that the rate limit state is shared across pods during runtime.

Note:

It is assumed that the consumer has load balanced the timer requests across Audit pods.

The Timer service uses the REPLICA_COUNT environment variable to determine the number of timer pods deployed. This value is mapped to the minReplicas key in the values.yaml file of the audit Helm chart. Although the audit service is deployed with a Kubernetes HorizontalPodAutoscaler (HPA), please note that dynamic scaling based on CPU load is not supported by the audit/timer services.

Note:

It is recommended not to scale the audit pods using the kubectl scale command to increase the number of pods, instead modify the minReplicas value in the values.yaml file and perform a Helm upgrade.

Rate Limiting the Timer Creation API: The Timer Creation API in the Audit service is rate limited using the token bucket algorithm. The default limit is 25 requests per pod to prevent traffic storms. For example, if there are 2 audit pods and requests are load balanced equally across the audit pods, the service can support 50 create timer requests.

Note:

Rate limiting is not guaranteed request rate; existing limitations from the token bucket algorithm still apply. Temporary spikes of 30-50% above 50 requests are acceptable, as the audit service can handle these bursts.

The timer occnp_timer_capacity metrics and capacity alerts are determined by the total number of timers created on the site and will not consider the fostered timers from pods of other sites as the logic for denying timer creation is based only on total timers created on the site, without regard for fostered timers.

The timer capacity alerts may deviate by 30 seconds, as the gauge metric is updated each time the timer scan run at default interval of 30 seconds.

Bulwark Concurrency

Bulwark needs to be enabled for the UE operations namely, UE create, update, UDR or CHF notification, T3501 Timer Expiry, N1Notify, and Timer Expiry Notification. The following table provides details about the newly added Bulwark configurations for Timer notifications.

Table 4-15 Newly added Advanced Settings for Bulwark Configurations for Timer

Key	Value	Description
CONCURRENCY.N15.REATTEMPT_TIMER_EXPIRY.LOCK_REQUEST_RETRY_COUNT	2	The number of retries when the lock acquisition fails from Bulwark due to lock request failing.
CONCURRENCY.N15.REATTEMPT_TIMER_EXPIRY.LOCK_REQUEST_RETRY_BACKOFF	1000	This is the duration for which UE service will wait once it receives ALREADY_LOCKED response from Bulwark.
CONCURRENCY.N15.REATTEMPT_TIMER_EXPIRY.LOCK_LEASE_DURATION	2000	The duration for which lock is kept once the acquisition is successful. After this duration, the lock gets released automatically.
CONCURRENCY.N15.REATTEMPT_TIMER_EXPIRY.LOCK_WAIT_DURATION	3000	The duration by which the UE service waits for the response to get a lock.
CONCURRENCY.N15.REATTEMPT_TIMER_EXPIRY.ENABLED	false	If Bulwark lock is enabled for processing Reattempt timer expiry Notification.

Table 4-16 AMF Discovery and Subscription

Key	Value	Description
AMF.OPTIMIZED.DISCOVERY.AND.SUBS.ENABLED	true	True: Discovery and subscription to AMF occur only when an N1MessageTransfer is required False: In-Advance AMF Discovery and Subscription are performed, N1Message Transfer may or may not be initiated, depending on the UE policy action

Support for GeoRedundency

A Policy Site is single deployment (NF instance) of Policy solution. Policy mated region refers to collection of two or more Policy Sites that share the same data. The Mated region is equivalent to an NF Set.

In a georedundant deployment, a mated region allows a service to be provided by any instance within the region, and providing access to the same context data. You can create mated region by configuring the Policy Mated Region page in under General Configurations in CNC Console.

An alternate site (NF Instance) from the Policy mated region can be configured for UE Policy Management Procedures. This common site takeover data shall be monitored and used by Audit to check for remote orphan and perform site takeover. The site take over configurations can be performed at Site Fallback page under General Configurations in CNC Console.

Call Flows

Reattempt NFDiscover Call Flow

The following figure illustrates the PCF UE Service call flow, handling the reattempts on a NFDiscover failure.

Figure 4-24 NFDiscover Call Flow

1. UE service initiates a NFDiscover request toward NRF Client.
2. On success from NRF Client, the UE Policy management procedure for N1N2MessageSubscribe continues with the next step.
3. On failure from NRF Client, PCF checks for reattempt applicability.
4. If the reattempt is applicable, then calculates the backoff based on the configured reattempt profile and schedules timer.
5. On Timer check passes for the capacity and other parameters, the timer information is stored in the database.
6. The database returns success 'OK'.
7. The scheduled timer success 'OK' is sent by Audit service to UE.
8. The reattempts details are stored in the database.
9. The database returns success 'OK'.
10. Alternate to Step 5. Failed check shall return failure to UE micro service which should abort the procedure.
11. Timer expiry shall notify the UE micro service after performing a rate limit check.
12. UE micro service performs a reattempt and returns OK.
13. Alternate to Step 4. Reattempt is not applicable and UE Policy Management Procedure shall be aborted.

N1N2MessageSubscribe Call Flow

The following figure illustrates the PCF UE Service call flow, handling the reattempts on a N1N2MessageSubscribe failure.

Figure 4-25 N1N2MessageSubscribe Call Flow

N1N2MessageTransfer Call Flow

The following figure illustrates the PCF UE Service call flow, handling the reattempts on a N1N2MessageTransfer failure.

Figure 4-26 N1N2MessageTransfer Call Flow

Manage Support for Backoff during N1N2Communication in UE

Feature Assumptions and Limitations

• For this feature to work as expected , we need to provision the respective Bulwark configuration for Timer service.
• Maximum capacity threshold for reattempt per site is 360K. Default is 180K.
• Maximum rate for the re-attempt is assumed to be 700 per second.
• Maximum rate of re-attempt timer scheduling is assumed to be 25 per second.
• During rate limiting, the NF Service Operation is not throttled. The UE Policy Management Procedure is to be executed later i.e. not aborted.
• Bulwark needs to be enabled for the feature as reattempt increases the chances of collisions for procedures related to the same UE.
• Reattempts are calculated per UE unless stated otherwise.
  • This means that same NF Service Producer can be retried as part of back-off for a different UE other than that for which the back-off timer is in progress.
• For ProblemDetails processing, final ProblemDetails returned is considered.
  • E.g. If both AMF1 and AMF2 returned ProblemDetails and AMF2 returned the last response, ProblemDetails from AMF2 shall be considered for back-off calculation.
• Rate limit is specific to reattempts and not to the initial requests for NFDiscover, N1N2MessageSubscribe, N1N2MessageTransfer service operations.
• Rate limits are global i.e. all the NFDiscover irrespective of the target NRF are considered, all N1N2MessageSubscribe irrespective of target AMF are considered.
• The retryAfter IE shall be used from last response received if multiple AMFs are tried and both return the retryAfter IE.
• Capacity threshold defining the number of NF Service Operation to be queued for reattempt with back off are assumed to be local to a site i.e. if capacity threshold is set to 200K in the reattempt profile, it means that 100K of pending NF Service Operation for this site. If the network has three sites, there can be 3 x 200 K pending NF Service Operation for the network.
• Whenever we receive the Retry-AfterIE from AMF, we compare its value with the backOffTimer and use the greater of the two to set the timer. However, the requirement for PCF to honor the Retry-AfterIE by delaying the Discovery/N1N2Subscribe/N1N2Transfer request to AMF with updated URSP Rules/UPSIs until the timer expires is currently out of scope and not implemented at this stage.

Enable

By default, this feature is disabled. User can enable it either using either CNC Console or REST API.

Configure Using CNC Console

To enable this feature, set Enable NF Service Operation Re-attempt flag to true in NF Communication Profiles page in CNC Console. Create reattempt profiles for either AMF or NRF operations, see Reattempts Profile page in CNC Console.

Configure Using REST API

To enable this feature, use Policy NF Communication Profiles APIs configured for reattemptSettings request body parameter.

For more information, see "NF Communication Profiles" and "Recreate Attempts" API sections in Oracle Communications Cloud Native Core, Converged Policy REST Specification Guide .

Observability

Metrics

The following changes are made to UE Service Metrics section:

• Following dimensions were added to occnp_http_out_conn_request_total and occnp_http_out_conn_request_total metrics:

  • isReattempt
  • isRetryAttempt
  • reattemptType

• The reattempt_timer_expiry_notification dimension is added to ue_n1_policy_consolidation metric.

• The isReattempt dimension is added to ue_n1_policy_sequencing metric.

• Following new metrics are added:
  • occnp_ue_timer_registration_total
  • occnp_ue_timer_create_success_total
  • occnp_ue_timer_create_failure_total
  • occnp_ue_timer_delete_success_total
  • occnp_ue_timer_delete_failure_total
  • occnp_ue_nf_discovery_reattempt_request_total
  • occnp_ue_nf_discovery_reattempt_response_total
  • ue_n1_policy_backed_off_collation_total

For more information about the dimensions, see CNC Policy Metrics section.

Following Audit Service Metrics are used to provide audit information for Timer service:

• occnp_timer_count_total
• occnp_timer_capacity
• occnp_timer_scan_total
• occnp_timer_registration_total
• occnp_timer_create_failure_total
• occnp_timer_notify_retry_total
• occnp_timer_state

Alerts

The following alerts are generated for this feature:

• AUDIT_TIMER_CAPACITY_FOR_UE_N1N2_TRANSFER_FAILURE_NOTIFICATION_ABOVE_CRITICAL_THRESHOLD
• AUDIT_TIMER_CAPACITY_FOR_UE_N1N2_TRANSFER_FAILURE_NOTIFICATION_ABOVE_MAJOR_THRESHOLD
• AUDIT_TIMER_CAPACITY_FOR_UE_N1N2_TRANSFER_FAILURE_NOTIFICATION_ABOVE_CRITICAL_THRESHOLD
• AUDIT_TIMER_CAPACITY_FOR_UE_AMF_DISCOVERY_ABOVE_MINOR_THRESHOLD
• AUDIT_TIMER_CAPACITY_FOR_UE_AMF_DISCOVERY_ABOVE_MAJOR_THRESHOLD
• AUDIT_TIMER_CAPACITY_FOR_UE_AMF_DISCOVERY_ABOVE_CRITICAL_THRESHOLD
• AUDIT_TIMER_CAPACITY_FOR_UE_N1N2_SUBSCRIBE_ABOVE_MINOR_THRESHOLD
• AUDIT_TIMER_CAPACITY_FOR_UE_N1N2_SUBSCRIBE_ABOVE_MAJOR_THRESHOLD
• AUDIT_TIMER_CAPACITY_FOR_UE_N1N2_SUBSCRIBE_ABOVE_CRITICAL_THRESHOLD
• AUDIT_TIMER_CAPACITY_FOR_UE_N1N2_TRANSFER_ABOVE_MINOR_THRESHOLD
• AUDIT_TIMER_CAPACITY_FOR_UE_N1N2_TRANSFER_ABOVE_MAJOR_THRESHOLD
• AUDIT_TIMER_CAPACITY_FOR_UE_N1N2_TRANSFER_ABOVE_CRITICAL_THRESHOLD
• UE_N1N2_SUBSCRIBE_REATTEMPT_FAILURE_ABOVE_CRITICAL_THRESHOLD
• UE_N1N2_SUBSCRIBE_REATTEMPT_FAILURE_ABOVE_MAJOR_THRESHOLD
• UE_N1N2_SUBSCRIBE_REATTEMPT_FAILURE_ABOVE_MINOR_THRESHOLD
• UE_N1N2_TRANSFER_REATTEMPT_FAILURE_ABOVE_CRITICAL_THRESHOLD
• UE_N1N2_TRANSFER_REATTEMPT_FAILURE_ABOVE_MAJOR_THRESHOLD
• UE_N1N2_TRANSFER_REATTEMPT_FAILURE_ABOVE_MINOR_THRESHOLD
• UE_AMF_DISCOVERY_REATTEMPT_FAILURE_ABOVE_CRITICAL_THRESHOLD
• UE_AMF_DISCOVERY_REATTEMPT_FAILURE_ABOVE_MAJOR_THRESHOLD
• UE_AMF_DISCOVERY_REATTEMPT_FAILURE_ABOVE_MINOR_THRESHOLD
• UE_N1N2_TRANSFER_FAILURE_NOTIFICATION_REATTEMPT_FAILURE_ABOVE_MINOR_THRESHOLD
• UE_N1N2_TRANSFER_FAILURE_NOTIFICATION_REATTEMPT_FAILURE_ABOVE_MAJOR_THRESHOLD
• UE_N1N2_TRANSFER_FAILURE_NOTIFICATION_REATTEMPT_FAILURE_ABOVE_CRITICAL_THRESHOLD

4.8 Pod Congestion Control in Policy Services

The Pod Congestion Control feature in Policy application is a crucial mechanism to ensure consistent service availability and performance, especially in scenarios with high traffic and resource utilization. It is designed to identify congestion conditions and apply load shedding rules to maintain optimal service levels. The following Policy services implements the Pod Congestion Control mechanism:

• AM Service Pod Congestion Control
• Notifier Service Pod Congestion Control
• User Service Pod Congestion Control
• Diameter Connector Pod Congestion Control
• UE Service Pod Congestion Control
• SM Service Pod Congestion Control
• PDS Pod Congestion Control
• Usage Monitoring Pod Congestion Control
• PCRF Core Pod Congestion Control
• Binding Service Pod Congestion Control
• Bulwark Pod Congestion Control
• Diameter Pod Congestion Control

4.8.1 AM Service Pod Congestion Control

The Access and Mobility Management (AM) service, a key component in Policy services is responsible for managing user equipment (UE) registration, authentication, and mobility across the network. At times, an excessive traffic from consumer services toward AM service can be observed in the network, which can result in a high CPU utilization, high memory utilization. The AM service gets congested and can cause performance degradation in its service response time and eventually reach a state of service unavailability. To handle this, the AM service implements congestion control mechanism. and ensures that its service is protected from congestion and, also its service is consistently available to the consumer services.

The Pod Congestion Control feature in AM service is a crucial mechanism to ensure consistent service availability and performance, especially in scenarios with high traffic and resource utilization. It is designed to identify congestion conditions and apply load shedding rules to maintain optimal service levels.

The AM service receives every incoming requests, the congestion control mechanism decides to either accept or reject the request based on pods congestion state defined request priority. It invokes the load shedding rules when congestion state persist in the AM pods. The pod congestion control mechanism involves:

1. Determining Pod Congestion State
2. Triggering Pod Congestion Control

Determining Pod Congestion State

In congestion control mechanism different congestion levels are defined, each level indicates how congested the pod is, and which requests can be served when pod is on certain congestion level. The congestion control works at following five congestion levels or states:

• NORMAL
• DANGER_OF_CONGESTION (DOC)
• CONGESTION_L1
• CONGESTION_L2
• CONGESTED

Each AM service pod monitors its congestion state. The pod's congestion state is decided based on CPU consumption and Queue.

1. CPU: The CPU usage for congestion state is calculated by comparing the CPU usage of the container (monitored using cgroup parameter, cpuacct.usage, which provides current cpu usage in nanoseconds) with the configured threshold.
2. Queue: For the DOC, CONGESTION_L1, CONGESTION_L2, and CONGESTED pod states, compare the number of pending messages in the queue with the configured pending messages threshold.

To avoid toggling between these states due to traffic pattern, it is required for the pod to be in a particular state for a given period before transitioning to another state. The below configurations are used to define the period that the pod has to be in a particular state for:

• stateChangeSampleCount: This REST API parameter can be configured to specify after how many continuous intervals, the pod state can be changed. This value can range from 1 to 2147483647.
• stateCalculationInterval: This REST API parameter can be configured to specify the time duration or interval, after which the pod congestion state will be re-verified. This interval is configured in milliseconds and can range from 50 to 2147483647.

For more information about these congestion control configurations, see Congestion Control Settings section in CNC Console.

The pod's state changes when its resources, namely the CPU and Queue buffer usage exceeds the predefined congestion threshold, checked at regular intervals. An active CPU and Queue default threshold profile can be viewed using CNC Console at Policy → Overload and Congestion Control → Congestion Control → Thresholds section. The user can create new threshold profile and make it active. The AM service pod's different congestion states and their default congestion parameters, CPU, and Queue pending counts are provided in the following table:

Table 4-17 AM Service Congestion States

Congestion States	CPU (%)	Queue Count (Pending Requests)
DANGER_OF_CONGESTION (DOC	77	140
CONGESTION_L1	78	160
CONGESTION_L2	79	180
CONGESTED	80	200

For more information about these CPU and Queue count thresholds configurations, see Congestion Control Thresholds section in CNC Console.

Triggering Pod Congestion Control

With Congestion Control feature enabled for AM service, every time a message is fetched for processing, the system checks the current congestion state of the pod. If the current state is either in DOC, CONGESTION_L1, CONGESTION_L2, or Congested state, then the congestion control mechanism is triggered. After verifying that the message type is a request, a request priority is assigned to it. If the request priority is greater than or equal to the discard priority, then the message is rejected, otherwise it is accepted.

Congestion Control Load Shedding using Discard and Request Priority

The AM service pods performs load shedding by considering the load rule configured for the current congestion state. The load shedding rule is based on message priority configuration. A default load shedding rule is active and the messages are discarded based on it. You can configure these load rules using the Overload and Congestion Control menu in CNC Console. The priority value ranges between 0 to 31, with 0 being the highest, and 31 being the lowest priority. The default discard priority for load shedding rules used in AM service:

Table 4-18 AM Service Default Discard Priorities:

Congestion State	Discard Priority (Default Value)
DANGER_OF_CONGESTION	28
CONGESTION_L1	25
CONGESTION_L2	20
CONGESTED	17

For more information about discard priority configurations, see Congestion Control Load Shedding Rules section in CNC Console.

Computing the Congestion Control Resource Usage

The Exponential Moving Average (EMA) algorithm calculates the congestion resource usage by considering the resource consumption data over time, giving more weight to recent usage data, which provides a more accurate picture of current resource utilization compared to a simple average across all data points. This resource usage data is used for pod state change thus enabling smooth transition of congestion states during traffic spikes. For AM pod to use EMA algorithm for computing its CPU and Queue resources, add the following advanced key value while editing the Congestion Control Settings for AM service in CNC Console.

Table 4-19 Congestion Control EMA Configurations for AM Service

Key	Value	Description
CPU_CONGESTION_RESOURCE_CALC_ALGORITHM	EMA	This enables the congestion control CPU resource calculation to use the algorithm configured.
CPU_CONGESTION_RESOURCE_CALC_INTERVAL_MS	50	This configuration sets the time interval in milliseconds for CPU congestion resource to be calculated by the configured algorithm.
QUEUE_CONGESTION_RESOURCE_CALC_ALGORITHM	EMA	This enables the congestion control Queue resource calculation to use the algorithm provided.
QUEUE_CONGESTION_RESOURCE_CALC_INTERVAL_MS	50	This configuration sets the time interval in milliseconds for Queue congestion resource to be calculated by the configured algorithm.
EMA_CPU_CONGESTION_RESOURCE_CALC_RATIO	70:30	This configuration will be used to set the EMA ratio in which congestion CPU resource(s) calculated using EMA algorithm to be considered for calculation.
EMA_QUEUE_CONGESTION_RESOURCE_CALC_RATIO	70:30	This configuration will be used to set the EMA ratio in which congestion Queue resource(s) calculated using EMA algorithm to be considered for calculation.

For more information about the EMA algorithm, see Congestion Control Resource Usage Calculation Using EMA Algorithm feature.

You can configure the message priority for different rest endpoints for AM Service using using CNC Console at Policy → Service Configurations → PCF Access and Mobility → Advanced Settings section. The message priority value ranges between 0 to 31, with 0 being the highest, and 31 being the lowest priority. If an invalid value is provided, then the default priority shall be considered. You can add the following keys to configure the message priority for different rest endpoints at AM service:

Table 4-20 AM Service Request Default Priorities

Advanced Settings Key	Default Priority
AM_GET_SUBSCRIBER_SESSIONS_REQUEST_PRIORITY	28
AM_CREATE_REQUEST_PRIORITY	24
AM_UPDATE_REQUEST_PRIORITY	18
AM_NOTIFICATION_REQUEST_PRIORITY	18
AM_UPDATE_PDSLOCATIONINFO_REQUEST_PRIORITY	18
AM_DELETE_REQUEST_PRIORITY	16
AM_AUDIT_NOTIFY_REQUEST_PRIORITY	30

The following points needs to be known while assigning request or message priority to an request API:

• For requests coming from Diameter Gateway, the requests priority number is retrieved from oc-message-priority parameter in the http request header. But if this request header parameter is not present or its value is not set, then the message priority shall be based on the configured values from Advanced Settings or Default priority values.
• For requests coming from Ingress Gateway, the priority is based on 3gpp-sbi-message-priority parameter in http request header. But if this request header parameter is not present or its value is not set, then the priority shall be based on configured values from Advanced Settings or on the default priority values.
• The request priority value ranges between 0 to 31, with 0 being the highest, and 31 being the lowest priority. If an invalid value is provided, then the default priority shall be considered.

Thus the precedence order for assigning message priority shall be from oc-message-priority → 3gpp-sbi-message-priority → Advanced Settings Priority → Default Priority.

When AM service is in congestion state, its response can be configured using PCF Access and Mobility service advanced settings in CNC Console, using the key CONGESTION_RESPONSE_CODE. You can configure the result codes for the rejected requests when configuring the load rules. The response code configured should be either 1xx, or 3xx, or 4xx, or 5xx status code. By default, AM service sends 503 as response code with error cause as 'NF_CONGESTION'.

In the response body, an error header is sent to the consumer service, providing the congestion error details as understood by the error-handler framework. A sample JSON error response:

{
    "status": 503
    "cause" : "NF_CONGESTION",
    "detail" : "Pod <pod-name> is in CONGESTION_L1"
}

Managing AM service Pod Congestion Control

Enable

By default, the Pod Congestion Control is disabled for AM service. You can enable this feature using CNC Console or REST API for Policy.

Configure Using CNC Console

To enable the feature using CNC Console, set the Enable parameter in Settings page under Congestion Control for Overload and Congestion Control Configurations for AM Service.

To configure AM service pod congestion control feature in CNC Console, see Congestion Control section.

To configure AM service pod congestion control discard messages in CNC Console, see the Advanced Settings section in PCF Access and Mobility.

Configure Using REST API

Perform the feature configurations as described in "Congestion Control" section in Oracle Communications Cloud Native Core, Converged Policy REST Specification Guide.

Observability

Metrics:

The following common service metrics are used to provide information about this feature:

• occnp_pod_congestion_state
• occnp_pod_resource_stress
• occnp_pod_resource_congestion_state
• occnp_pod_cong_state_report_total
• occnp_pod_resource_congestion_state_report_total
• occnp_congestion_http_pending_request_active_counter
• occnp_http_congestion_message_reject_total

For information about the metrics, see Pod Congestion Metrics section.

Alerts

The following alerts are generated for this feature:

• POD_CONGESTED
• POD_CONGESTION_L2
• POD_CONGESTION_L1
• POD_DANGER_OF_CONGESTION
• POD_PENDING_REQUEST_CONGESTED
• POD_PENDING_REQUEST_CONGESTION_L2
• POD_PENDING_REQUEST_CONGESTION_L1
• POD_PENDING_REQUEST_DANGER_OF_CONGESTION
• POD_CPU_CONGESTED
• POD_CPU_CONGESTION_L2
• POD_CPU_CONGESTION_L1
• POD_CPU_DANGER_OF_CONGESTION

For more information about alerts, see Common Alerts.

4.8.2 Notifier Service Pod Congestion Control

The Notifier service is provided by the Policy Control Function (PCF). It is a notification framework used to send notifications such as events or messages to external notification servers such as HTTP server, SMS Gateway, Short Message Service Center (SMSC), and Mail Transfer Agent (MTA).

Figure 4-27 Notifier Service interactions with other Services

At times, an excessive traffic from consumer services toward Notifier service can be observed in the network, which can result in a high CPU utilization, high memory utilization. The Notifier service gets congested and can cause performance degradation in its service response time and eventually reach a state of service unavailability. To handle this, the Notifier service implements congestion control mechanism. and ensures that its service is protected from congestion and, also its service is consistently available to the consumer services.

The Pod Congestion Control feature in Notifier service is a crucial mechanism to ensure consistent service availability and performance, especially in scenarios with high traffic and resource utilization. It is designed to identify congestion conditions and apply load shedding rules to maintain optimal service levels.

The Notifier service receives every incoming requests, the congestion control mechanism decides to either accept or reject the request based on pods congestion state defined request priority. It invokes the load shedding rules when congestion state persist in the Notifier pods. The pod congestion control mechanism involves:

1. Determining Pod Congestion State
2. Triggering Pod Congestion Control

Determining Pod Congestion State

In congestion control mechanism different congestion levels are defined, each level indicates how congested the pod is, and which requests can be served when pod is on certain congestion level. The congestion control works at following five congestion levels or states:

• NORMAL
• DANGER_OF_CONGESTION (DOC)
• CONGESTION_L1
• CONGESTION_L2
• CONGESTED

Each Notifier service pod monitors its congestion state. The pod's congestion state is decided based on CPU consumption and Queue.

1. CPU: The CPU usage for congestion state is calculated by comparing the CPU usage of the container (monitored using cgroup parameter, cpuacct.usage, which provides current cpu usage in nanoseconds) with the configured threshold.
2. Queue: For the DOC, CONGESTION_L1, CONGESTION_L2, and CONGESTED pod states, compare the number of pending messages in the queue with the configured pending messages threshold.

To avoid toggling between these states due to traffic pattern, it is required for the pod to be in a particular state for a given period before transitioning to another state. The below configurations are used to define the period that the pod has to be in a particular state for:

• stateChangeSampleCount: This parameter can be configured to specify after how many continuous intervals, the pod state can be changed. This value can range from 1 to 2147483647.
• stateCalculationInterval: This parameter can be configured to specify the time duration or interval, after which the pod congestion state will be re-verified. This interval is configured in milliseconds and can range from 50 to 2147483647.

For more information about these congestion control configurations, see Congestion Control Settings section in CNC Console.

The pod's state changes when its resources, namely the CPU and Queue buffer usage exceeds the predefined congestion threshold, checked at regular intervals. An active CPU and Queue default threshold profile can be viewed using CNC Console at Policy → Overload and Congestion Control → Congestion Control → Thresholds section. The user can create new threshold profile and make it active. The Notifier service pod's different congestion states and their default congestion parameters, CPU, and Queue pending counts are provided in the following table:

Table 4-21 Notifier Service Congestion States

Congestion States	CPU (%)	Queue Count (Pending Requests)
DANGER_OF_CONGESTION (DOC	77	140
CONGESTION_L1	78	160
CONGESTION_L2	79	180
CONGESTED	80	200

For more information about these CPU and Queue count thresholds configurations, see Congestion Control Thresholds section in CNC Console.

Triggering Pod Congestion Control

With Congestion Control feature enabled for Notifier service, every time a message is fetched for processing, the system checks the current congestion state of the pod. If the current state is either in DOC, CONGESTION_L1, CONGESTION_L2, or Congested state, then the congestion control mechanism is triggered. After verifying that the message type is a request, a request priority is assigned to it. If the request priority is greater than or equal to the discard priority, then the message is rejected, otherwise it is accepted.

Congestion Control Load Shedding using Discard and Request Priority

The Notifier service pods performs load shedding by considering the load rule configured for the current congestion state. The load shedding rule is based on message priority configuration. A default load shedding rule is active and the messages are discarded based on it. You can configure these load rules using the Overload and Congestion Control menu in CNC Console. The priority value ranges between 0 to 31, with 0 being the highest, and 31 being the lowest priority. The default discard priority for load shedding rules used in Notifier service:

Table 4-22 Notifier Service Default Discard Priorities:

Congestion State	Discard Priority (Default Value)
DANGER_OF_CONGESTION	27
CONGESTION_L1	19
CONGESTION_L2	17
CONGESTED	15

For more information about discard priority configurations, see Congestion Control Load Shedding Rules section in CNC Console.

Computing the Congestion Control Resource Usage

The Exponential Moving Average (EMA) algorithm calculates the congestion resource usage by considering the resource consumption data over time, giving more weight to recent usage data, which provides a more accurate picture of current resource utilization compared to a simple average across all data points. This resource usage data is used for pod state change thus enabling smooth transition of congestion states during traffic spikes. For Notifier pod to use EMA algorithm for computing its CPU and Queue resources, add the following advanced key value while editing the Congestion Control Settings for Notifier service in CNC Console.

Table 4-23 Congestion Control EMA Configurations for Notifier Service

Key	Value	Description
CPU_CONGESTION_RESOURCE_CALC_ALGORITHM	EMA	This enables the congestion control CPU resource calculation to use the algorithm configured.
CPU_CONGESTION_RESOURCE_CALC_INTERVAL_MS	50	This configuration sets the time interval in milliseconds for CPU congestion resource to be calculated by the configured algorithm.
QUEUE_CONGESTION_RESOURCE_CALC_ALGORITHM	EMA	This enables the congestion control Queue resource calculation to use the algorithm provided.
QUEUE_CONGESTION_RESOURCE_CALC_INTERVAL_MS	50	This configuration sets the time interval in milliseconds for Queue congestion resource to be calculated by the configured algorithm.
EMA_CPU_CONGESTION_RESOURCE_CALC_RATIO	70:30	This configuration will be used to set the EMA ratio in which congestion CPU resource(s) calculated using EMA algorithm to be considered for calculation.
EMA_QUEUE_CONGESTION_RESOURCE_CALC_RATIO	70:30	This configuration will be used to set the EMA ratio in which congestion Queue resource(s) calculated using EMA algorithm to be considered for calculation.

For more information about the EMA algorithm, seeCongestion Control Resource Usage Calculation Using EMA Algorithm feature.

You can configure the message priority for different rest endpoints for Notifier Service using using CNC Console at Policy → Service Configurations → Notifier Service → Advanced Settings section. The message priority value ranges between 0 to 31, with 0 being the highest, and 31 being the lowest priority. If an invalid value is provided, then the default priority shall be considered. You can add the following keys to configure the message priority for different rest endpoints at Notifier service:

Table 4-24 Notifier Service Request Default Priorities

Message Type	Advanced Settings Key	Default Priority
Update Subscriber Notification	NOTIFIER.NOTIFY.PRIORITY	20

For more information about the Notifier service advanced settings, see Notifier Configurations section.

To override the message priority value received from the core service to PRE when we need to send a different value to the notifier we can use the new option of the currents blocklys. This depends on the type of notification being sent (SMPP or HTTP), as there is a constraint of having only one endpoint for both types of notifications.

The existing Blockly for HTTP and SMPP notifications now has a new option to override the oc-message-priority parameter. This helps in providing more control over the header value sent to the notifier for each notification request, especially when the policy uses more than one Blockly.

Figure 4-28 Block to Override Message Priority

For more information about the different blocklys, see Oracle Communications Cloud Native Core, Policy Design Guide.

The following points needs to be known while assigning request or message priority to an request API:

• For requests coming from Diameter Gateway, the requests priority number is retrieved from oc-message-priority parameter in the http request header. But if this request header parameter is not present or its value is not set, then the message priority shall be based on the configured values from Advanced Settings or Default priority values.
• For requests coming from Ingress Gateway, the priority is based on 3gpp-sbi-message-priority parameter in http request header. But if this request header parameter is not present or its value is not set, then the priority shall be based on configured values from Advanced Settings or on the default priority values.
• The request priority value ranges between 0 to 31, with 0 being the highest, and 31 being the lowest priority. If an invalid value is provided, then the default priority shall be considered.

Thus the precedence order for assigning message priority shall be from oc-message-priority → 3gpp-sbi-message-priority → Advanced Settings Priority → Default Priority.

When Notifier service is in congestion state, its response can be configured using Notifier service advanced settings in CNC Console, using the key CONGESTION_RESPONSE_CODE. You configure the result codes for the rejected requests when configuring the load rules. The response code configured should be 5xx error status only. By default, Notifier service sends 503 as response code.

Managing Notifier service Pod Congestion Control

Enable

By default, the Pod Congestion Control is disabled for Notifier service. You can enable this feature using CNC Console or REST API for Policy.

Configure Using CNC Console

To enable the feature using CNC Console, set the Enable parameter in Settings page under Congestion Control for Overload and Congestion Control Configurations for Notifier Service.

To configure Notifier service pod congestion control feature in CNC Console, see Congestion Control section.

To configure Notifier service pod congestion control discard messages in CNC Console, see the Advanced Settings section in Notifier Configurations.

Configure Using REST API

Perform the feature configurations as described in "Congestion Control" section in Oracle Communications Cloud Native Core, Converged Policy REST Specification Guide.

Observability

Metrics:

The following common service metrics are used to provide information about this feature:

• occnp_pod_congestion_state
• occnp_pod_resource_stress
• occnp_pod_resource_congestion_state
• occnp_pod_cong_state_report_total
• occnp_pod_resource_congestion_state_report_total
• occnp_congestion_http_pending_request_active_counter
• occnp_http_congestion_message_reject_total

For information about the metrics, see Pod Congestion Metrics section.

Alerts

The following alerts are generated for this feature:

• POD_CONGESTED
• POD_CONGESTION_L2
• POD_CONGESTION_L1
• POD_DANGER_OF_CONGESTION
• POD_PENDING_REQUEST_CONGESTED
• POD_PENDING_REQUEST_CONGESTION_L2
• POD_PENDING_REQUEST_CONGESTION_L1
• POD_PENDING_REQUEST_DANGER_OF_CONGESTION
• POD_CPU_CONGESTED
• POD_CPU_CONGESTION_L2
• POD_CPU_CONGESTION_L1
• POD_CPU_DANGER_OF_CONGESTION

For more information about alerts, see Common Alerts.

4.8.3 User Service Pod Congestion Control

Policy User service is a connector service comprising of UDR and CHF connectors. UDR Connector interacts with UDR network function to fetch the latest subscriber information. CHF Connector interacts with CHF network function to fetch the latest charging information.

• UDR Connector - UDR Connector is a protocol specific layer which converts the PDS requests to nUDR specific request format and forwards it to UDR network function for subscription information. It also provides an ability to subscribe for notification in case of subscriber profile changes at UDR.
• CHF Connector – CHF Connector is a protocol specific layer which converts the PDS requests to nCHF specific request format and forwards it to CHF network function for fetching policy counter information. As per the 3gpp standards, it automatically subscribes for any profile changes at CHF.

Figure 4-29 PCF User Service interactions with other services

The Policy User service provides these subscriber and policy counter information to the core services such as SM, AM and UE services. It handles data requests from various policy services such as SM, AM, UE, NRF Client and PDS services. At times, an excessive traffic from these consumer services toward User service can be observed in the network, which can result in a high CPU utilization, high memory utilization. This can cause performance degradation in User service responses and eventually reach a state of service unavailability. Congestion control helps to identify such conditions and invoke load shedding rules to address these situations when these load conditions persist. With User service supporting the congestion control mechanism feature, it helps to protects its pods from congestion and ensures consistent service availability to its consumer.

The pod congestion control mechanism involves:

1. Determining Pod Congestion State
2. Triggering Pod Congestion Control

Determining Pod Congestion State

In the pod congestion control mechanism, each User service pod monitors its congestion state. The congestion control works at 5 levels or states:

• NORMAL
• DANGER_OF_CONGESTION (DOC)
• CONGESTION_L1
• CONGESTION_L2
• CONGESTED

The pod's congestion state is decided based on CPU consumption and Queue.

1. CPU: The CPU usage for congestion state is calculated by comparing the CPU usage of the container (monitored using cgroup parameter, cpuacct.usage, which provides current cpu usage in nanoseconds) with the configured threshold.
2. Queue: For the DOC, CONGESTION_L1, CONGESTION_L2, and CONGESTED pod states, compare the number of pending messages in the queue with the configured pending messages threshold.

To avoid toggling between these states due to traffic pattern, it is required for the pod to be in a particular state for a given period before transitioning to another state. The below configurations are used to define the period that the pod has to be in a particular state for:

• stateChangeSampleCount: This REST API parameter can be configured to specify after how many continuous intervals, the pod state can be changed. The default value is 5. This value can range from 1 to 2147483647.
• stateCalculationInterval: This REST API parameter can be configured to specify the time duration or interval, after which the pod resource will be re-calculated. The default value is 200ms. This interval is configured in milliseconds and can range from 50 to 2147483647.

A pod's state changes when its resources, namely the CPU and Queue buffer usage exceeds the predefined congestion threshold, checked at regular intervals. An active CPU and Queue default threshold profile can be viewed using CNC Console at Policy → Overload and Congestion Control → Congestion Control → Thresholds section. The user can create new threshold profile and make it active. The UDR and CHF connector service pod's congestion states and their default congestion parameters, CPU, and Queue counts are provided in the following table:

Table 4-25 UDR Connector Congestion States

Congestion States	CPU (%)	Queue Count (Pending Requests)
DANGER_OF_CONGESTION (DOC)	50	2100
CONGESTION_L1	55	2400
CONGESTION_L2	60	2700
CONGESTED	65	3000

Table 4-26 CHF Connector Congestion States

Congestion States	CPU (%)	Queue Count (Pending Requests)
DANGER_OF_CONGESTION (DOC)	60	3000
CONGESTION_L1	65	3400
CONGESTION_L2	70	3800
CONGESTED	75	4200

For more information about congestion control threshold profiles, see Thresholds section in CNC Console.

Triggering Pod Congestion Control

Every time User service receives requests from other services, it checks for the current congestion state of the pod. The Congestion Control mechanism is triggered if the pod's congestion state is in Danger of Congestion (DOC) or Congested_L1 or Congested_L2, or Congested. After verifying that the message request type, a priority is assigned to it. If the assigned priority is less than discard priority, the message is accepted and if the assigned priority is greater than or equal to discard priority then, the message is rejected.

Congestion Control Load Shedding

Based on the pod's current congestion state, a load shedding rule is applied to perform priority-based load shedding. The load shedding rule is based on message priority. For example, when the User service pod state is CONGESTED and the priority of discard messages is 30, then it determines if the message with the assigned priority is less than discard priority, the message is accepted and if the assigned priority is greater than or equal to discard priority than the message is rejected.

The User service pods performs load shedding by considering the load rule configured for current congestion state. You can configure these load rules using the Overload and Congestion Control menu in CNC Console. The User service drops the requests based on discard priority.

Priority-Based Load Shedding

You can configure load shedding rule for User service by providing the discard priority for each of the congestion state. If not, a default load shedding rule is active, and messages are discarded based on it. The default load shedding rules for UDR and CHF Connector service:

Table 4-27 UDR Connector Load Shedding Rules

Congestion State	Discard Priority (Default Value)
DANGER_OF_CONGESTION	29
CONGESTION_L1	23
CONGESTION_L2	17
CONGESTED	15

Table 4-28 CHF Connector Load Shedding Rules

Congestion State	Discard Priority (Default Value)
DANGER_OF_CONGESTION	29
CONGESTION_L1	23
CONGESTION_L2	17
CONGESTED	15

You can add the following keys to configure the message priority for different rest endpoints using User service advanced settings in CNC Console. If any invalid or incorrect values are provided then the default priority values shall be considered.

Table 4-29 Configuring Message Priority

Key	Value	Description
UDR_GET_USER_DATA_REQUEST_PRIORITY	24	0-31
UDR_DELETE_USER_DATA_REQUEST_PRIORITY	16	0-31
UDR_PATCH_USER_DATA_REQUEST_PRIORITY	18	0-31
UDR_SUBS_TO_NOTIFY_REQUEST_PRIORITY	22	0-31
UDR_NOTIFY_REQUEST_PRIORITY	18	0-31
UDR_UM_NOTIFY_REQUEST_PRIORITY	18	0-31
CHF_GET_SPENDING_LIMIT_REQUEST_PRIORITY	24	0-31
CHF_DELETE_SPENDING_LIMIT_REQUEST_PRIORITY	16	0-31
CHF_TERMINATE_NOTIFY_REQUEST_PRIORITY	17	0-31
CHF_NOTIFY_REQUEST_PRIORITY	18	0-31

The user can configure the result codes for the rejected requests when configuring the load rules. The default response code is 503 Service Unavailable for HTTP messages. You can configure with any valid non-2xx response codes only. The response can be configured using User service advanced settings in CNC Console, using the following keys:

• UDR_CONGESTION_RESPONSE_CODE
• CHF_CONGESTION_RESPONSE_CODE

In the response body, an error header is sent to the consumer service, providing the congestion error details as understood by the error-handler framework. A sample JSON error header:

{
  "errorDetails":{
  "status":"503",
  "cause":"NF_CONGESTION",
  "message":"Pod <pod-name> is in CONGESTION_L1",
  "targetService":"UDR_C"
  }
}

Propagation of Message Priority as Header Attribute

For internal requests toward User service, the priority is based on oc-message-priority header attribute. And for notification requests from Ingress Gateway, the priority is based on 3gpp-sbi-message-priority header attribute. But if the priority values are not provided in the respective requests headers, then the message priority shall be based on the configured values in Advanced Settings or Default message priority values. Thus, the precedence order for assigning message priority shall be oc-message-priority → 3gpp-sbi-message-priority → Advanced Settings Priority → Default Priority.

The User service sends the oc-message-priority header attribute to upstream services and the value of this header depends on the priority precedence order. You can decide to include the priority information in 3gpp-sbi-message-priority header toward Egress Gateway and NRF Client by adding the following keys in the User service advanced settings in CNC Console:

• UDR_ADD_3GPP_SBI_MSG_PRIORITY
• CHF_ADD_3GPP_SBI_MSG_PRIORITY

Again, the value of 3gpp-sbi-message-priority is based on the above mentioned precedence order. The default value of these keys are false. The oc-message-priority header shall always propagate from User service to Egress Gateway and NRF Client.

It is recommended that Egress Gateway should not propagate oc-message-priority headers to external NFs. And by default behavior, oc-message-priority header will be dropped by Egress Gateway. But in case if you want to send these headers to external NFs, then remove these headers name under globalRemoveRequestHeader parameter in custom_values.yaml file.

Sample of customizable yaml file:

egress-gateway:
  globalRemoveRequestHeader:
    - name: ocLogId #DO NOT REMOVE OR EDIT THIS. This header holds the value of TraceId and need to be removed from outgoing traffic.
    - name: oc-message-priority # Do not remove this. This is an internal header that holds the message priority value.
  #  - name: 3gpp-Sbi-Origination-Timestamp
  #  - name: 3gpp-Sbi-Max-Rsp-Time
  #  - name: 3gpp-Sbi-Sender-Timestamp

For more information about Egress Gateway Helm parmeters, see "Basic Configurations in Egress Gateway" section in Oracle Communications Cloud Native Core, Converged Policy Installation, Upgrade, and Fault Recovery Guide.

Call flow diagram for User Service Congestion Control

For this call flow, assume the load shedding rule for UDR Connector is set as:

Table 4-30 Example: UDR Connector Load Shedding Rule

Congestion States	Discard Priority
DANGER_OF_CONGESTION	29
CONGESTION_L1	23
CONGESTION_L2	17
CONGESTED	15

Figure 4-30 Call flow diagram for UDR Connector Congestion Control

UDR Connector pod is in DOC state and the discard priority is configured as 29:

• PDS service sends a GET user request with message priority value set to 24 toward UDR Connector service.
• UDR Connector service responds with a success status.

UDR Connector pod is in Congestion_L1 state and the discard priority is configured as 23:

• PDS sends a GET user request with message priority value set to 24 toward UDR Connector.
• UDR Connector responds with a reject 503 status or with any configured error code and message.
• UDR sends notify request to Ingress Gateway.
• Ingress Gateway sends a notification request with message priority value set to 18 toward UDR Connector.
• UDR Connector responds with a success status to Ingress Gateway.
• Ingress Gateway service responds with a success status to UDR.

UDR Connector pod is in Congestion_L2 state and the discard priority is configured as 17:

• UDR sends notify request to Ingress Gateway.
• Ingress Gateway sends a notification request with message priority value set to 18 toward UDR Connector.
• UDR Connector responds with a reject 503 status or with any configured error code and message to Ingress Gateway.
• Ingress Gateway forwards the error response to the UDR.
• PDS sends DELETE user data request with priority value set to 16 toward UDR Connector.
• UDR Connector responds with a success status to PDS.

UDR Connector pod is in Congested state and the discard priority is configured as 15:

• PDS sends DELETE user data request with priority value set to 16 toward UDR Connector.
• UDR Connector responds with a reject 503 status or with any configured error code and message to PDS.

For this call flow, assume the load shedding rule for CHF Connector is set as:

Table 4-31 Example: CHF Connector Load Shedding Rule

Congestion States	Discard Priority
DANGER_OF_CONGESTION	29
CONGESTION_L1	23
CONGESTION_L2	17
CONGESTED	15

Figure 4-31 Call flow diagram for CHF Connector Congestion Control

CHF Connector pod is in DOC state and the message priority is configured as 29:

• PDS service sends a GET user request with message priority value set to 24 toward CHF Connector service.
• CHF Connector service responds with a success status.

CHF Connector pod is in Congestion_L1 state and the discard priority is configured as 23:

• PDS sends a GET user request with message priority value set to 24 toward CHF Connector.
• CHF Connector responds with a reject 503 status or with any configured error code and message.
• CHF sends notify request to Ingress Gateway.
• Ingress Gateway sends a notification request with message priority value set to 18 toward CHF Connector.
• CHF Connector responds with a success status to Ingress Gateway.
• Ingress Gateway service responds with a success status to UDR.

CHF Connector pod is in Congestion_L2 state and the discard priority is configured as 17:

• CHF sends notify request to Ingress Gateway.
• Ingress Gateway sends a notification request with message priority value set to 18 toward CHF Connector.
• CHF Connector responds with a reject 503 status or with any configured error code and message to Ingress Gateway.
• Ingress Gateway forwards the error response to the CHF.
• PDS sends DELETE user data request with priority value set to 16 toward CHF Connector.
• CHF Connector responds with a success status to PDS.

CHF Connector pod is in Congested state and the discard priority is configured as 15:

• PDS sends DELETE user data request with priority value set to 16 toward CHF Connector.
• CHF Connector responds with a reject 503 status or with any configured error code and message to PDS.

Managing User service Pod Congestion Control

Enable

By default, the Pod Congestion Control is disabled for User service. You can enable this feature using CNC Console or REST API for Policy.

Configure Using CNC Console

To enable the feature using CNC Console, set the Enable parameter in Settings page under Congestion Control for Overload and Congestion Control Configurations for User Service.

To configure User service pod congestion control feature in CNC Console, see Congestion Control section.

To configure User service pod congestion control discard messages in CNC Console, see the Advanced Settings section in PCF User Connector.

Configure Using REST API

Perform the feature configurations as described in "Congestion Control" section in Oracle Communications Cloud Native Core, Converged Policy REST Specification Guide.

Observability

Metrics:

The following common service metrics are used to provide information about this feature:

• occnp_pod_congestion_state
• occnp_pod_resource_stress
• occnp_pod_resource_congestion_state
• occnp_pod_cong_state_report_total
• occnp_pod_resource_congestion_state_report_total
• occnp_congestion_http_pending_request_active_counter
• occnp_http_congestion_message_reject_total

For information about the metrics, see Pod Congestion Metrics section.

Alerts

The following alerts are generated for this feature:

• POD_CONGESTED
• POD_CONGESTION_L2
• POD_CONGESTION_L1
• POD_DANGER_OF_CONGESTION
• POD_PENDING_REQUEST_CONGESTED
• POD_PENDING_REQUEST_CONGESTION_L2
• POD_PENDING_REQUEST_CONGESTION_L1
• POD_PENDING_REQUEST_DANGER_OF_CONGESTION
• POD_CPU_CONGESTED
• POD_CPU_CONGESTION_L2
• POD_CPU_CONGESTION_L1
• POD_CPU_DANGER_OF_CONGESTION

For more information about alerts, see Common Alerts.

Maintain

Warning logs are generated to indicate the congestion level. However, error logs are not generated when messages are rejected to avoid additional resource usage to write error logs.

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.

4.8.4 Diameter Connector Pod Congestion Control

Diameter Gateway acts as a gateway for all diameter traffic to the Policy solution. And, the Diameter Connector accepts diameter messages from Diameter Gateway and converts them to Http messages, and sends them to the other PCF components

At times, an excessive traffic from the consumer services toward Diameter Connector service can be observed in the network, which can result in a high CPU utilization, high memory utilization. This can cause performance degradation in Diameter Connector service responses and eventually reach a state of service unavailability. Congestion control helps to identify such conditions and invoke load shedding rules to address these situations when these load conditions persist. With Diameter Connector service supporting the congestion control mechanism feature, it helps to protects its pods from congestion and ensures consistent service availability to its consumer.

The pod congestion control mechanism involves:

1. Determining Pod Congestion State
2. Triggering Pod Congestion Control

Determining Pod Congestion State

In the pod congestion control mechanism, each Diameter Connector service pod monitors its congestion state. The congestion control works at 5 levels or states:

• NORMAL
• DANGER_OF_CONGESTION (DOC)
• CONGESTION_L1
• CONGESTION_L2
• CONGESTED

The pod's congestion state is decided based on CPU consumption and Queue.

1. CPU: The CPU usage for congestion state is calculated by comparing the CPU usage of the container (monitored using cgroup parameter, cpuacct.usage, which provides current cpu usage in nanoseconds) with the configured threshold.
2. Queue: For the DOC, CONGESTION_L1, CONGESTION_L2, and CONGESTED pod states, compare the number of pending messages in the queue with the configured pending messages threshold.

To avoid switching between these states due to traffic pattern, it is required for the pod to be in a particular state for a given period before transitioning to another state. The below configurations are used to define the period that the pod has to be in a particular state for:

• stateChangeSampleCount: This REST API parameter can be configured to specify after how many continuous intervals, the pod state can be changed. The default value is 5. This value can range from 1 to 2147483647.
• stateCalculationInterval: This REST API parameter can be configured to specify the time duration or interval, after which the pod congestion state will be re-verified. The default value is 200ms. This interval is configured in milliseconds and can range from 50 to 2147483647.

A pod's state changes when its resources, namely the CPU and Queue buffer usage exceeds the predefined congestion threshold, checked at regular intervals. An active CPU and Queue default threshold profile can be viewed using CNC Console at Policy → Overload and Congestion Control → Congestion Control → Thresholds section. The user can create new threshold profile and make it active. The Diameter Connector service pod's congestion states and their default congestion parameters, CPU, and Queue counts are provided in the following table:

Table 4-32 Diameter Connector Congestion States

Congestion States	CPU (%)	Queue Count (Pending Requests)
DANGER_OF_CONGESTION (DOC)	97	99997
CONGESTION_L1	98	99997
CONGESTION_L2	99	99997
CONGESTED	100	10000

For more information about congestion control threshold profiles, see Thresholds section in CNC Console.

Triggering Pod Congestion Control

Every time Diameter Connector service receives requests from other services, it checks for the current congestion state of the pod. The Congestion Control mechanism is triggered if the pod's congestion state is in Danger of Congestion (DOC) or Congested_L1 or Congested_L2, or Congested. After verifying that the message request type, a priority is assigned to it. If the assigned priority is greater than or equal to discard priority, the message is rejected.

Congestion Control Load Shedding

Based on the pod's current congestion state, a load shedding rule is applied to perform priority-based load shedding. The load shedding rule is based on message priority. For example, when the Diameter Connector service pod state is CONGESTED and the priority of discard messages is 30, then it determines if the message with the assigned priority should be rejected or accepted.

The Diameter Connector pods performs load shedding by considering the load rule configured for current congestion state. You can configure these load rules using the Overload and Congestion Control menu in CNC Console. The Diameter Connector drops the requests based on discard priority.

Priority-Based Load Shedding

You can configure the load shedding rule for Diameter Connector service by providing the discard priority for each of the congestion state. If not, a default load shedding rule is active, and messages are discarded based on it. The default load shedding rules for Diameter Connector service:

Table 4-33 Diameter Connector Load Shedding Rules

Congestion State	Discard Priority (Default Value)
DANGER_OF_CONGESTION	28
CONGESTION_L1	25
CONGESTION_L2	20
CONGESTED	17

Table 4-34 Messages Default Priorities

Advanced Settings Key	Default Priority	Message Type
SM.NOTIFY.REQUEST.PRIORITY	25	Re Authorization notification (RAR)
SM.NOTIFY.TERMINATE.REQUEST.PRIORITY	20	Terminate notify (ASR)
PDS.FETCH.REQUEST.PRIORITY	25	PDS Fetch SLR
PDS.NOTIFY.TERMINATE.REQUEST.PRIORITY	20	PDS Notify terminate (STR)

Table 4-35 Diameter Messages Default Priorities

Advanced Settings Key	Default Priority	Diameter Message Type
RX.AAR.REQUEST.PRIORITY	30	Rx AAR
RX.STR.REQUEST.PRIORITY	20	Rx STR
RX.ASR.REQUEST.PRIORITY	25	Rx ASR
SY.SNR.DEFAULT.PRIORITY	25	Sy SNR

You can add the following keys to configure the message priority for different rest endpoints using Diameter Connector advanced settings in CNC Console. If any invalid or incorrect values are provided then the default priority values shall be considered.

Table 4-36 Configuring Response Code

Key	Value	Description
CONGESTION.USE.EXPERIMENTAL.RESULT.CODE	false	To set if user wants to use experimental result code when rejecting diameter messages. Allowed values are true or false. By default it will be false.
CONGESTION.VENDOR.ID	0	This is to configure the diameter vendor id for the congestion control discards and data type of value will be numerical. If value is non-zero, then the CONGESTION_DIAMETER_RESPONSE_CODE considered as the experimental result code. If value is zero / not configured, then CONGESTION_DIAMETER_RESPONSE_CODEconsidered as the normal result code. Examples: CONGESTION_DIAMETER_VENDOR_ID=10415 CONGESTION_DIAMETER_VENDOR_ID=21274

You can also configure the result codes for the rejected requests when configuring the load rules. For diameter requests, the Diameter Connector rejects request with default DIAMETER_TOO_BUSY (3004) result code.

Table 4-37 Response Code

Key	Value	Description
CONGESTION.DIAMETER.RESPONSE.CODE	3004	To set response code when rejecting diameter messages. Only valid 3xxx, 4xxx, 5xxx response codes are allowed.
CONGESTION.HTTP.RESPONSE.CODE	503	Configure the response code of any rejected requests by Diameter Connector Core service due to congestion state. By default, the service sends 503 as response code. If configured then it shall be 1xx, 3xx, 4xx or 5xx response code.

In the response body, an error header is sent to the consumer service, providing the congestion error details as understood by the error-handler framework. A sample JSON error response:

{
  "errorDetails":{
  "status":"503",
  "cause":"NF_CONGESTION",
  "message":"Pod <pod-name> is in CONGESTION_L1",
  "targetService":"DIAMETER_CONNECTOR"
  }
}

Propagation of Message Priority as Header Attribute

For internal requests toward Diameter Connector service, the priority is based on oc-message-priority AVP. But if the priority values are not provided in the requests headers, then the message priority shall be based on the configured values in Advanced Settings or Default message priority values. Thus, the precedence order for assigning message priority shall be oc-message-priority → Advanced Settings Priority → Default Priority.

Managing User service Pod Congestion Control

Enable

By default, the Pod Congestion Control is disabled for Diameter Connector service. You can enable this feature using CNC Console or REST API for Policy.

Configure Using CNC Console

To enable the feature using CNC Console, set the Enable parameter in Settings page under Congestion Control for Overload and Congestion Control Configurations for Diameter Connector Service.

To configure Diameter Connector service pod congestion control feature in CNC Console, see Congestion Control section.

Configure Using REST API

Perform the feature configurations as described in "Congestion Control" section in Oracle Communications Cloud Native Core, Converged Policy REST Specification Guide.

Observability

Metrics:

The following common service metrics are used to provide information about this feature:

• occnp_pod_congestion_state
• occnp_pod_resource_stress
• occnp_pod_resource_congestion_state
• occnp_pod_cong_state_report_total
• occnp_http_congestion_message_reject_total
• occnp_congestion_http_pending_request_active_counter

For information about the metrics, see Pod Congestion Metrics section.

The following common service metrics are used to provide information about this feature:

• occnp_diam_congestion_message_reject_total
• occnp_http_pending_requests_total
• occnp_diam_pending_requests_total
• occnp_congestion_diam_pending_request_active_counter
• occnp_congestion_http_pending_request_active_counter
• occnp_congestion_diam_pending_request_end_to_end_id_map_size
• occnp_congestion_DiamMsgBuffer_queue_msg_count

For information about the metrics, see Diameter Connector Service Metrics section.

Alerts

The following alerts are generated for this feature:

• POD_CONGESTED
• POD_CONGESTION_L2
• POD_CONGESTION_L1
• POD_DANGER_OF_CONGESTION
• POD_PENDING_REQUEST_CONGESTED
• POD_PENDING_REQUEST_CONGESTION_L2
• POD_PENDING_REQUEST_CONGESTION_L1
• POD_PENDING_REQUEST_DANGER_OF_CONGESTION
• POD_CPU_CONGESTED
• POD_CPU_CONGESTION_L2
• POD_CPU_CONGESTION_L1
• POD_CPU_DANGER_OF_CONGESTION

For more information about alerts, see Common Alerts.

4.8.5 UE Service Pod Congestion Control

The UE Policy Control service is provided by the Policy Control Function (PCF). This service is used as part of the provisioning of UE policies determined by the PCF to the UE via the AMF. At times, an excessive traffic from consumer services toward UE service can be observed in the network, which can result in a high CPU utilization, high memory utilization. The UE service gets congested and can cause performance degradation in its service response time and eventually reach a state of service unavailability. By implementing Congestion Control mechanism in UE service ensures that its service is protected from congestion and also its service is consistently available to the consumer services.

Congestion control mechanism identifies congestion conditions and invokes load shedding rules when such load conditions persist in UE service. The pod congestion control mechanism involves:

1. Determining Pod Congestion State
2. Triggering Pod Congestion Control

Determining Pod Congestion State

In the pod congestion control mechanism, each UE service pod monitors its congestion state. The congestion control works at 5 levels or states:

• NORMAL
• DANGER_OF_CONGESTION (DOC)
• CONGESTION_L1
• CONGESTION_L2
• CONGESTED

Each state indicates how congested the Pod is, and which requests can be served when the Pod is in certain congestion state.

The pod's congestion state is decided based on CPU consumption and Queue.

1. CPU: The CPU usage for congestion state is calculated by comparing the CPU usage of the container (monitored using cgroup parameter, cpuacct.usage, which provides current cpu usage in nanoseconds) with the configured threshold.
2. Queue: For the DOC, CONGESTION_L1, CONGESTION_L2, and CONGESTED pod states, compare the number of pending messages in the queue with the configured pending messages threshold.

The UE service pod's congestion states and their default congestion parameters, CPU, and Queue counts are provided in the following table:

Table 4-38 UE Service Congestion States

Congestion States	CPU (%)	Queue Count (Pending Requests)
DANGER_OF_CONGESTION (DOC	77	140
CONGESTION_L1	78	160
CONGESTION_L2	79	180
CONGESTED	80	200

To avoid toggling between these states due to traffic pattern, it is required for the pod to be in a particular state for a given period before transitioning to another state. The below configurations are used to define the period that the pod has to be in a particular state for:

• stateChangeSampleCount: This REST API parameter can be configured to specify after how many continuous intervals, the pod state can be changed. This value can range from 1 to 2147483647.
• stateCalculationInterval: This REST API parameter can be configured to specify the time duration or interval, after which the pod congestion state will be re-verified. This interval is configured in milliseconds and can range from 50 to 2147483647.

Triggering Pod Congestion Control

Every time UE service receives requests from other services, it checks for the current congestion state of the pod. The Congestion Control mechanism is triggered if the pod's congestion state is in DOC or Congested_L1 or Congested_L2 or Congested.

The requests to the UE service might have priority included as oc-message-priority attribute in the request header. The priority value ranges between 0 to 31 with 0 being the highest and 31 being the lowest priority.

Priority-Based Load Shedding

Based on the pod's current congestion state, a load shedding rule is applied to perform priority-based load shedding. The load shedding rule is based on message priority. For example, when the UE service pod state is CONGESTED and the priority of discard messages is 30, then it determines if the message with the assigned priority should be rejected or accepted.

The user can configure load shedding rule for UE service by providing the discard priority for each of the congestion state. If not, a default load shedding rule is active, and messages are discarded based on it. The user can configure the result codes for the rejected requests when configuring the load rules. The default result code is 503 Service Unavailable for HTTP messages.

The default load shedding rules for UE service:

- state: DANGER_OF_CONGESTION        
      discardPriority: 28
- state: CONGESTION_L1
      discardPriority: 25
- state: CONGESTION_L2
      discardPriority: 20       
- state: CONGESTED
      discardPriority: 17

When UE service is in congestion state, its response can be configured using UE service advanced settings in CNC Console, using the key CONGESTION.HTTP.RESPONSE.CODE. This key is used to configure the response code of the messages that are rejected by the UE service due to pod's congestion state. By default, UE Service responds with a response code of 503. The response code configured should be 5xx error status only. Following is the list of configurable keys that can be added to set the message priority:

Table 4-39 Configuring Message Priority

Key	Default Value	Allowed Values
UE.GET.SUBSCRIBER.SESSIONS.PRIORITY	28	0-31
UE.GET.POLICY.ASSOCIATION.PRIORITY	18	0-31
UE.CREATE.PRIORITY	24	0-31
UE.UPDATE.PRIORITY	18	0-31
UE.UPDATE.NOTIFICATION.PRIORITY	18	0-31
UE.DELETE.PRIORITY	16	0-31
UE.AUDIT.NOTIFY.PRIORITY	30	0-31
UE.N1.NOTIFICATION.MESSAGE.PRIORITY	18	0-31
UE.N1.FAILURE.NOTIFICATION.MESSAGE.PRIORITY	18	0-31
CONGESTION.HTTP.RESPONSE.CODE	503	1xx, 3xx, 4xx, or 5xx

Managing UE service Pod Congestion Control

Enable

By default, the Pod Congestion Control is disabled for UE service. You can enable this feature using CNC Console or REST API for Policy.

Configure Using CNC Console

To enable the feature using CNC Console, set the Enable parameter in Settings page under Congestion Control for Overload and Congestion Control Configurations.

To configure UE service pod congestion control feature in CNC Console, see Congestion Control section.

To configure UE service pod congestion control discard messages in CNC Console, see the Advanced Settings section in PCF UE Policy Service.

Configure Using REST API

Perform the feature configurations as described in "Congestion Control" section in Oracle Communications Cloud Native Core, Converged Policy REST Specification Guide.

Observability

Metrics:

The following common service metrics are used to provide information about this feature:

• occnp_pod_congestion_state
• occnp_pod_resource_stress
• occnp_pod_resource_congestion_state
• occnp_pod_cong_state_report_total
• occnp_pod_resource_congestion_state_report_total

For information about the metrics, see Pod Congestion Metrics section.

The metric occnp_http_congestion_message_reject_total was added to the UE service for this feature. For information about the metrics, see UE Service Metrics section.

Alerts

The following alerts are generated for this feature:

• POD_CONGESTED
• POD_CONGESTION_L2
• POD_CONGESTION_L1
• POD_DANGER_OF_CONGESTION
• POD_PENDING_REQUEST_CONGESTED
• POD_PENDING_REQUEST_CONGESTION_L2
• POD_PENDING_REQUEST_CONGESTION_L1
• POD_PENDING_REQUEST_DANGER_OF_CONGESTION
• POD_CPU_CONGESTED
• POD_CPU_CONGESTION_L2
• POD_CPU_CONGESTION_L1
• POD_CPU_DANGER_OF_CONGESTION

For more information about alerts, see Common Alerts.

Maintain

Warning logs are generated to indicate the congestion level. However, error logs are not generated when messages are rejected to avoid additional resource usage to write error logs.

To resolve any alerts at the system or application level, see Alerts section. In case the alerts still persist, perform the following:

• Collect the logs: For more information on how to collect logs, see Oracle Communications Clout Native Core, Converged Policy Troubleshotting Guide.
• Raise a service request: See My Oracle Support.

4.8.6 SM Service Pod Congestion Control

The Session Management (SM) service performs provisioning, update and removal of session related policies and PCC rules by PCF to Session Management Function (SMF). SM service interacts with other PCF services, as shown in the following diagram:

Figure 4-32 Policy Services and SM service interaction

• SMF interacts with SM service to Create/Update/Delete Policy associations.
• AF interacts with SM service to Create/Update/Delete App Sessions.
• PDS interacts with SM service to notify user data change and UDR subscription failures.
• Audit service interacts with SM service to process stale data.

At times, an excessive traffic from these services toward SM service can be observed in the network, which can result in a high CPU utilization, high memory utilization. This can cause performance degradation in SM service responses and eventually reach a state of service unavailability. Congestion control helps to identify such conditions and invoke load shedding rules to address these situations when these load conditions persist.

The SM service pod congestion control mechanism ensures consitent service availability to its consumer.

The pod congestion control mechanism involves:

1. Determining Pod Congestion State
2. Triggering Pod Congestion Control

Determining Pod Congestion State

In the pod congestion control mechanism, each SM service pod monitors its congestion state. The congestion control works at 5 levels or states:

• NORMAL
• DANGER_OF_CONGESTION (DOC)
• CONGESTION_L1
• CONGESTION_L2
• CONGESTED

The pod's congestion state is decided based on CPU consumption and Queue.

1. CPU: The CPU usage for congestion state is calculated by comparing the CPU usage of the container (monitored using cgroup parameter, cpuacct.usage, which provides current cpu usage in nanoseconds) with the configured threshold.
2. Queue: For the DOC, CONGESTION_L1, CONGESTION_L2, and CONGESTED pod states, compare the number of pending messages in the queue with the configured pending messages threshold.

The SM service pod's congestion states and their default congestion parameters, CPU, and Queue counts are provided in the following table:

Table 4-40 SM Service Congestion States

Congestion States	CPU (%)	Queue Count (Pending Requests)
DANGER_OF_CONGESTION (DOC)	77	140
CONGESTION_L1	78	160
CONGESTION_L2	79	180
CONGESTED	80	200

To avoid toggling between these states due to traffic pattern, it is required for the pod to be in a particular state for a given period before transitioning to another state. The below configurations are used to define the period that the pod has to be in a particular state for:

• stateChangeSampleCount: This REST API parameter can be configured to specify after how many continuous intervals, the pod state can be changed. This value can range from 1 to 2147483647.
• stateCalculationInterval: This REST API parameter can be configured to specify the time duration or interval, after which the pod congestion state will be re-verified. This interval is configured in milliseconds and can range from 50 to 2147483647.

Triggering Pod Congestion Control

Every time SM service receives requests from other services, it checks for the current congestion state of the pod. The Congestion Control mechanism is triggered if the pod's congestion state is in DOC or Congested_L1 or Congested_L2 or Congested.

The requests to the SM service might have priority included as oc-message-priority attribute in the request header. The priority value ranges between 0 to 100 with 0 being the highest and 100 being the lowest priority.

Priority-Based Load Shedding

Based on the pod's current congestion state, a load shedding rule is applied to perform priority-based load shedding. The load shedding rule is based on message priority. For example, when the SM service pod state is CONGESTED and thepriority of discard messages is 30, then it determines if the message with the assigned priority should be rejected or accepted.

The user can configure load shedding rule for SM service by providing the discard priority for each of the congestion state. If not, a default load shedding rule is active, and messages are discarded based on it. The user can configure the result codes for the rejected requests when configuring the load rules. The default result code is 503 Service Unavailable for HTTP messages.

The default load shedding rules for SM service:

- state: DANGER_OF_CONGESTION        
      discardPriority: 27
- state: CONGESTION_L1
      discardPriority: 19
- state: CONGESTION_L2
      discardPriority: 17       
- state: CONGESTED
      discardPriority: 15

When SM service is in congestion state, its response can be configured using SM service advanced settings in CNC Console, using the key CONGESTION_RESPONSE_CODE. This key is used to configure the response code of the messages that are rejected by the SM service due to pod's congestion state. By default, SM Service responds with a response code of 503. The response code configured should be 5xx error status only. Following is the list of configurable keys that can be added to set the message priority:

Table 4-41 Configuring Message Priority

Key	Default Value	Allowed Values
SM.TDF.SESSION.DELETE.PRIORITY	16	0-31
SM.TDF.SESSION.UPDATE.PRIORITY	18	0-31
SM.UPDATE.EVENT.SUBS.PRIORITY	18	0-31
SM.CREATE.PRIORITY	24	0-31
SM.SUB.FAIL.NOTIFY.PRIORITY	26	0-31
SM.USER.SERVICE.NOTIFY.PRIORITY	18	0-31
SM.UPDATE_PRIORITY	18	0-31
SM.REAUTH_PRIORITY	20	0-31
SM.DELETE.PRIORITY	16	0-31
SM.POLICY.CLEANUP.PRIORITY	20	0-31
SM.APP.SESSION.CREATE.PRIORITY	24	0-31
SM.APP.SESSION.DELETE.PRIORITY	16	0-31
SM.APP.SESSION.CLEANUP.PRIORITY	20	0-31
SM.AUDIT.NOTIFY.PRIORITY	30	0-31
SM.GET.APP.SESSION.PRIORITY	28	0-31
SM.GET.ASSOC.PRIORITY	28	0-31
SM.GET.SUBSCRIBER.SESSIONS.PRIORITY	28	0-31
SM.GET.ASSOC.QUERY.PRIORITY	28	0-31
SM.PDS.LOCATION.INFO.NOTIFY.PRIORITY	30	0-31
CONGESTION_RESPONSE_CODE	503	5xx

Managing SM service Pod Congestion Control

Enable

By default, the Pod Congestion Control is disabled for SM service. You can enable this feature using CNC Console or REST API for Policy.

Configure Using CNC Console

To enable the feature using CNC Console, set the Enable parameter in Settings page under Congestion Control for Overload and Congestion Control Configurations.

To configure SM service pod congestion control feature in CNC Console, see Congestion Control section.

To configure SM service pod congestion control discard messages in CNC Console, see the Advanced Settings section in PCF Session Management section.

Configure Using REST API

Perform the feature configurations as described in "Congestion Control" section in Oracle Communications Cloud Native Core, Converged Policy REST Specification Guide.

Observability

Metrics:

The following metrics are used to provide information about this feature:

• occnp_pod_congestion_state
• occnp_pod_resource_stress
• occnp_pod_resource_congestion_state
• pod_cong_state_report_total
• pod_resource_congestion_state_report_total
• http_congestion_message_reject_total

For information about the metrics, see Pod Congestion Metrics.

Alerts

The following alerts are generated for this feature:

• POD_CONGESTED
• POD_CONGESTION_L2
• POD_CONGESTION_L1
• POD_DANGER_OF_CONGESTION
• POD_PENDING_REQUEST_CONGESTED
• POD_PENDING_REQUEST_CONGESTION_L2
• POD_PENDING_REQUEST_CONGESTION_L1
• POD_PENDING_REQUEST_DANGER_OF_CONGESTION
• POD_CPU_CONGESTED
• POD_CPU_CONGESTION_L2
• POD_CPU_CONGESTION_L1
• POD_CPU_DANGER_OF_CONGESTION

For more information about alerts, see Common Alerts.

Maintain

Warning logs are generated to indicate the congestion level. However, error logs are not generated when messages are rejected to avoid additional resource usage to write error logs.

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.

4.8.7 PDS Pod Congestion Control

The Policy Data Source (PDS) stores the User or Subscriber State Variable (SSV) information. PDS interacts with other Policy services, such as:

• The core services such as AM/UE/SM and PCRF Core services send requests to PDS. It would be a request to either fetch, update, or delete the SSV data.
• User service, SOAP Connector, and Diameter Connector send notification requests to PDS.
• Query service sends request to PDS to either get or delete SSV data. It also gets the default workflow details from the PDS.
• Audit service sends audit notification request to PDS.

At times, an excessive traffic from these services toward PDS service can be observed in the network, which can result in a high CPU utilization, high memory utilization. This can cause performance degradation in PDS service responses and eventually reach a state of service unavailability. Congestion control helps to identify such conditions and invoke load shedding rules to address these situations when these load conditions persist.

The PDS pod congestion control mechanism ensures consitent service availability to its consumer.

The pod congestion control mechanism involves:

1. Determining Pod Congestion State
2. Triggering Pod Congestion Control

Determining Pod Congestion State

In the pod congestion control mechanism, each PDS service pod monitors its congestion state. The congestion control works at 5 levels or states:

• NORMAL
• DANGER_OF_CONGESTION (DOC)
• CONGESTION_L1
• CONGESTION_L2
• CONGESTED

The pod's congestion state is decided based on CPU consumption and Queue.

1. CPU: The CPU usage for congestion state is calculated by comparing the CPU usage of the container (monitored using cgroup parameter, cpuacct.usage, which provides current cpu usage in nanoseconds) with the configured threshold.
2. Queue: For the DOC, CONGESTION_L1, CONGESTION_L2, and CONGESTED pod states, compare the number of pending messages in the queue with the configured pending messages threshold.

The PDS service pod's congestion states and their default congestion parameters, CPU, and Queue counts are provided in the following table:

Table 4-42 PDS Congestion States

Congestion States	CPU (%)	Queue Count (Pending Requests)
DANGER_OF_CONGESTION (DOC)	65	50
CONGESTION_L1	70	100
CONGESTION_L2	75	150
CONGESTED	80	200

To avoid toggling between these states due to traffic pattern, it is required for the pod to be in a particular state for a given period before transitioning to another state. The below configurations are used to define the period that the pod has to be in a particular state for:

• stateChangeSampleCount: This REST API parameter can be configured to specify after how many continuous intervals, the pod state can be changed. This value can range from 1 to 2147483647.
• stateCalculationInterval: This REST API parameter can be configured to specify the time duration or interval, after which the pod congestion state will be re-verified. This interval is configured in milliseconds and can range from 50 to 2147483647.

Triggering Pod Congestion Control

Every time PDS service receives requests from other services, it checks for the current congestion state of the pod. The Congestion Control mechanism is triggered if the pod's congestion state is in DOC or Congested_L1 or Congested_L2 or Congested.

Assigning Message Priority:

The requests to the PDS service might have priority included as oc-message-priority attribute in the request header. The priority value ranges between 0 to 100 with 0 being the highest and 100 being the lowest priority. If the priority header is not provided in the requests, then the message priority shall be decided based on the configured or default values set for PDS service. Thus message priority precedence order shall be oc-message-priority → priority set in PDS Advanced Settings → Default Priority.

Currently Policy services such as SM, PCRF Core, UDR Connector, and CHF Connector services propagates oc-message-priority header to PDS service. The other Policy services shall also support this header propagation to PDS service in future releases.

Priority-Based Load Shedding

Based on the pod's current congestion state, a load shedding rule is applied to perform priority-based load shedding. The load shedding rule is based on message priority. For example, when the PDS service pod state is CONGESTED and the priority of discard messages is 30, then it determines if the message with the assigned priority should be rejected or accepted.

The user can configure load shedding rule for PDS service by providing the discard priority for each of the congestion state. If not, a default load shedding rule is active, and messages are discarded based on it. The user can configure the result codes for the rejected requests when configuring the load rules. The default result code is 503 Service Unavailable for HTTP messages.

The default load shedding rules for PDS service:

- state: DANGER_OF_CONGESTION        
      discardPriority: 28
- state: CONGESTION_L1
      discardPriority: 20
- state: CONGESTION_L2
      discardPriority: 17       
- state: CONGESTED
      discardPriority: 15

When PDS service is in congestion state, its response can be configured using PDS service advanced settings in CNC Console, using the key CONGESTION_RESPONSE_CODE. This key is used to configure the response code of the messages that are rejected by the PDS service due to pod's congestion state. By default, PDS service responds with a response code of 503. The user can configure this parameter with either 1xx, 3xx, 4xx, or 5xx response codes. Following are the list of configurable keys that can be added to set the message priority:

Table 4-43 Configuring Message Priority

Key	Default Value	Allowed Values
PDS_NOTIFY_USER_DATA_REQUEST_PRIORITY	18	0-100
PDS_GET_USER_DATA_REQUEST_PRIORITY	18	0-100
PDS_UPDATE_USER_DATA_REQUEST_PRIORITY	18	0-100
PDS_DELETE_USER_DATA_REQUEST_PRIORITY	16	0-100
PDS_AUDIT_NOTIFY_REQUEST_PRIORITY	27	0-100
CONGESTION_RESPONSE_CODE	503	1xx, 3xx, 4xx, or 5xx

Note:

For Policy application with Aspen Serivce Mesh (ASM) setups, add the CONGESTION_RESPONSE_CODE set to 500 using PDS Advanced Settings.

Example for Congestion Control Call Flow/Scenario

For the below call flows, consider the following load shedding rule configuration:

Table 4-44 Load Shedding Rule

Congestion State	Discard Priority
DOC	27
CONGESTION_L1	23
CONGESTION_L2	17
CONGESTED	15

The call flow describes the PDS service congestion control mechanism handling the requests from the other Policy services such as SM and Audit services when it is in different congestion state.

Figure 4-33 PDS Congestion Control Call Flow

PDS pod congestion is in DOC state and the discard priority is configured as 27:

• Audit service sends a notification request with discard priority value set to 30 toward PDS service.
• PDS service responds with a reject 503 status or with any configured error code and message.
• SM service sends a GET user information request with discard priority value set to 24 toward PDS service.
• PDS service responds with the success status.

PDS pod congestion is in Congestion_L1 state and the discard priority is configured as 23:

• SM service sends a GET user information request with discard priority value set to 24 toward PDS service.
• PDS service responds with a reject 503 status or with any configured error code and message.
• SM service sends an Update SSV request with discard priority value set to 18 toward PDS service.
• PDS service responds with the success status.

PDS pod congestion is in Congestion_L2 state and the discard priority is configured as 17:

• SM service sends an Update SSV request with discard priority value set to 18 toward PDS service.
• PDS service responds with a reject 503 status or with any configured error code and message.
• SM service sends a Delete user information request with discard priority value set to 16 toward PDS service.
• PDS service responds with the success status.

PDS pod congestion is in Congested state and the discard priority is configured as 15:

• SM service sends a Delete user information request with discard priority value set to 16 toward PDS service.
• PDS responds with a reject 503 or with any configured error code and message.

Managing PDS service Pod Congestion Control

Enable

By default, the Pod Congestion Control is disabled for PDS service. You can enable this feature using CNC Console or REST API for Policy.

Configure Using CNC Console

To enable the feature using CNC Console, set the Enable parameter in Settings page under Congestion Control for Overload and Congestion Control Configurations.

To configure SM service pod congestion control feature in CNC Console, see Congestion Control section.

To configure SM service pod congestion control discard messages in CNC Console, see the Advanced Settings section in PDS Settings section.

Configure Using REST API

Perform the feature configurations as described in "Congestion Control" section in Oracle Communications Cloud Native Core, Converged Policy REST Specification Guide.

Observability

Metrics:

The following metrics are used to provide information about this feature:

• occnp_pod_congestion_state
• occnp_pod_resource_stress
• occnp_pod_resource_congestion_state
• pod_cong_state_report_total
• pod_resource_congestion_state_report_total
• http_congestion_message_reject_total

For information about the metrics, see Pod Congestion Metrics.

Alerts

The following alerts are generated for this feature:

• POD_CONGESTED
• POD_CONGESTION_L2
• POD_CONGESTION_L1
• POD_DANGER_OF_CONGESTION
• POD_PENDING_REQUEST_CONGESTED
• POD_PENDING_REQUEST_CONGESTION_L2
• POD_PENDING_REQUEST_CONGESTION_L1
• POD_PENDING_REQUEST_DANGER_OF_CONGESTION
• POD_CPU_CONGESTED
• POD_CPU_CONGESTION_L2
• POD_CPU_CONGESTION_L1
• POD_CPU_DANGER_OF_CONGESTION

For more information about alerts, see Common Alerts.

Maintain

Warning logs are generated to indicate the congestion level. However, error logs are not generated when messages are rejected to avoid additional resource usage to write error logs.

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.

4.8.8 Usage Monitoring Pod Congestion Control

The Policy Usage Monitoring service interacts with PRE and UDR services to get usage monitoring related Policy decisions and it also sends notifications to the subscribers about their current data usage.

Usage Monitoring interacts with other Policy services, as shown in the following diagram:

Figure 4-34 Usage Monitoring Service and other Policy services

• The PCRF core services send requests to Usage Monitoring service.
• Audit service sends requests to Usage Monitoring service for stale session notification.
• Usage Monitoring service sends requests to PRE for retrieving Policy decisions.
• Usage Monitoring service sends requests to PDS for Subscriber information.

At times, an excessive traffic from these services toward Usage Monitoring service can be observed in the network, which can result in a high CPU utilization, high memory utilization. This can cause performance degradation in Usage Monitoring service responses and eventually reach a state of service unavailability. Congestion control helps to identify such conditions and invoke load shedding rules to address these situations when these load conditions persist. The Usage Monitoring serivce pod congestion state is identified by CPU utilization and pending requests in the Queue.

The Usage Monitoring pod congestion control mechanism ensures consitent service availability to its consumer.

The pod congestion control mechanism involves:

1. Determining Pod Congestion State
2. Triggering Pod Congestion Control

Determining Pod Congestion State

In the pod congestion control mechanism, each Usage Monitoring service pod monitors its congestion state. The congestion control works at 5 levels or states:

• NORMAL
• DANGER_OF_CONGESTION (DOC)
• CONGESTION_L1
• CONGESTION_L2
• CONGESTED

The pod's congestion state is decided based on CPU consumption and Queue.

1. CPU: The CPU usage for congestion state is calculated by comparing the CPU usage of the container (monitored using cgroup parameter, cpuacct.usage, which provides current cpu usage in nanoseconds) with the configured threshold.
2. Queue: For the DOC, CONGESTION_L1, CONGESTION_L2, and CONGESTED pod states, compare the number of pending messages in the queue with the configured pending messages threshold.

The Usage Monitoring service pod's congestion states and their default congestion parameters, CPU, and Queue values are provided in the following table:

Table 4-45 Usage Monitoring Service Congestion States

Congestion States	CPU (%)	Queue (Pending Requests)
DANGER_OF_CONGESTION (DOC)
CONGESTION_L1
CONGESTION_L2
CONGESTED

To avoid toggling between these states due to traffic pattern, it is required for the pod to be in a particular state for a given period before transitioning to another state. The below configurations are used to define the period that the pod has to be in a particular state for:

• stateChangeSampleCount: This REST API parameter can be configured to specify after how many continuous intervals, the pod state can be changed. This value can range from 1 to 2147483647.
• stateCalculationInterval: This REST API parameter can be configured to specify the time duration or interval, after which the pod congestion state will be re-verified. This interval is configured in milliseconds and can range from 50 to 2147483647.

Triggering Pod Congestion Control

Every time Usage Monitoring service receives requests from other services, it checks for the current congestion state of the pod. The Congestion Control mechanism is triggered if the pod's congestion state is in DOC or Congested_L1 or Congested_L2 or Congested.

The requests to the Usage Monitoring service might have priority included as oc-message-priority attribute in the request header. If the prioirity is not included in the request, then the default priorities defined in the Usage Monitoring, CNC Console is considered. The priority value ranges between 0 to 31 with 0 being the highest and 31 being the lowest priority.

Priority-Based Load Shedding

Based on the pod's current congestion state, a load shedding rule is applied to perform priority-based load shedding. The load shedding rule is based on message priority. For example, when the Usage Monitoring service pod state is CONGESTED and the priority of discard messages is 30, then it determines if the message with the assigned priority should be rejected or accepted.

The user can configure load shedding rule for Usage Monitoring service by providing the discard priority for each of the congestion state. If not, a default load shedding rule is active, and messages are discarded based on it. The user can configure the result codes for the rejected requests when configuring the load rules. The default result code is 503 Service Unavailable for HTTP messages.

The default load shedding rules for Usage Monitoring service:

- state: DANGER_OF_CONGESTION        
      discardPriority: 30
- state: CONGESTION_L1
      discardPriority: 27
- state: CONGESTION_L2
      discardPriority: 24        
- state: CONGESTED
      discardPriority: 20

When Usage Monitoring service is in congestion state, its response can be configured using Usage Monitoring service Message Default Priority for Congestion Control settings in CNC Console, using the key CONGESTION ERROR CODE. This key is used to configure the response code of the messages that are rejected by the Usage Monitoring service due to pod's congestion state. By default, Usage Monitoring service responds with a response code of 503. The response code configured should be 5xx error status only. Following is the list of configurable Usage Monitoring API message default priorities for Congestion Control:

Table 4-46 Configuring Message Priority

Key	Default Value	Allowed Values
UM Session Create API	20	0-31
UM Session Update API	17	0-31
UM Session Terminate API	15	0-31
UM Session Notify API	17	0-31
UM Session Audit Subscriber API	31	0-31
UM Session Search Subscriber API	30	0-31
UM Session Audit Notify API	31	0-31
Congestion Error Code	503	5xx

Managing Usage Monitoring service Pod Congestion Control

Enable

By default, the Pod Congestion Control is disabled for Usage Monitoring service. You can enable this feature using CNC Console or REST API for Policy.

Configure Using CNC Console

To enable the feature using CNC Console, set the Enable parameter in Settings page under Congestion Control for Overload and Congestion Control Configurations.

To configure SM service pod congestion control feature in CNC Console, see Congestion Control section.

To configure SM service pod congestion control discard messages in CNC Console, see Message Default Priority for Congestion Control fields in Configuring Usage Monitoring section.

Configure Using REST API

Perform the feature configurations as described in "Congestion Control" section in Oracle Communications Cloud Native Core, Converged Policy REST Specification Guide.

Observability

Metrics:

The following metrics are used to provide information about this feature:

• occnp_pod_congestion_state
• occnp_pod_resource_stress
• occnp_pod_resource_congestion_state
• pod_cong_state_report_total
• pod_resource_congestion_state_report_total
• um_http_congestion_message_reject_total

For information about the metrics, see Pod Congestion Metrics.

Alerts

The following alerts are generated for this feature:

• POD_CONGESTED
• POD_CONGESTION_L2
• POD_CONGESTION_L1
• POD_DANGER_OF_CONGESTION
• POD_PENDING_REQUEST_CONGESTED
• POD_PENDING_REQUEST_CONGESTION_L2
• POD_PENDING_REQUEST_CONGESTION_L1
• POD_PENDING_REQUEST_DANGER_OF_CONGESTION
• POD_CPU_CONGESTED
• POD_CPU_CONGESTION_L2
• POD_CPU_CONGESTION_L1
• POD_CPU_DANGER_OF_CONGESTION

For more information about alerts, see Common Alerts.

Maintain

Error logs are generated when the system is congested and the actions are taken to bring the system back to normal. Warning logs are generated to indicate the congestion level. However, error logs are not generated when messages are rejected to avoid additional resource usage to write error logs.

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.

4.8.9 PCRF Core Pod Congestion Control

Policy and Charging Rules Function (PCRF) service integrates with various Policy services. It receives requests from Diameter Gateway, PDS, PRE or Binding services. At times, an excessive traffic from these services toward PCRF Core service can be observed in the network, which can result in a high CPU and memory utilization. The PCRF Core service gets congested and can cause performance degradation in its service response time and eventually reach a state of service unavailability. By implementing Congestion Control mechanism in PCRF service ensures that its service is protected from congestion and also its service is consistently available to the consumer services.

Congestion control feature in PCRF Core service is an improvement to its Admission Control feature. Admission Control feature decides the congestion state based on pending requests in diameter queue, whereas Congestion Control decides based on the pending requests existing at the overall application level and on the CPU utilization by the pod. By default Admission Control feature is enabled, and Congestion Control feature is disabled.

Note:

To use Congestion Control feature, it is recommended to disable Admission Control feature by setting ADMISSION.Enabled as false in PCRF Core service advanced settings.

Congestion control mechanism identifies congestion conditions and invokes load shedding rules when such load conditions persist in PCRF Core service. The pod congestion control mechanism involves:

1. Determining Pod Congestion State
2. Triggering Pod Congestion Control

Determining Pod Congestion State

In the pod congestion control mechanism, each PCRF Core service pod monitors its congestion state. The congestion control works at 5 levels or states:

• NORMAL
• DANGER_OF_CONGESTION (DOC)
• CONGESTION_L1
• CONGESTION_L2
• CONGESTED

Each state indicates how congested the Pod is, and which requests can be served when the Pod is in certain congestion state.

The pod's congestion state is decided based on CPU consumption and Queue.

1. CPU: The CPU usage for congestion state is calculated by comparing the CPU usage of the container (monitored using cgroup parameter, cpuacct.usage, which provides current cpu usage in nanoseconds) with the configured threshold.
2. Queue: For the DOC, CONGESTION_L1, CONGESTION_L2, and CONGESTED pod states, compare the number of pending messages in the queue with the configured pending messages threshold.

To avoid toggling between these states due to traffic pattern, it is required for the pod to be in a particular state for a given period before transitioning to another state. The below configurations are used to define the period that the pod has to be in a particular state for:

• stateChangeSampleCount: This parameter can be configured to specify after how many continuous intervals, the pod state can be changed. This value can range from 1 to 2147483647.
• stateCalculationInterval: This parameter can be configured to specify the time duration or interval, after which the pod congestion state will be re-verified. This interval is configured in milliseconds and can range from 50 to 2147483647.

For more information about these congestion control configurations, see Congestion Control Settings section in CNC Console.

The pod's state changes when its resources, namely the CPU and Queue buffer usage exceeds the predefined congestion threshold, checked at regular intervals. An active CPU and Queue default threshold profile can be viewed using CNC Console at Policy → Overload and Congestion Control → Congestion Control → Thresholds section. The user can create new threshold profile and make it active. The PCRF Core service pod's congestion states and their default congestion parameters, CPU, and Queue counts are provided in the following table:

Table 4-47 PCRF Core Service Congestion States

Congestion States	CPU (%)	Queue Count (Pending Requests)
DANGER_OF_CONGESTION (DOC	65	250
CONGESTION_L1	70	300
CONGESTION_L2	75	350
CONGESTED	85	400

For more information about these CPU and Queue count thresholds configurations, see Congestion Control Thresholds section in CNC Console.

Triggering Pod Congestion Control

With Congestion Control feature enabled for PCRF service, every time a message is fetched for processing, the system checks the current congestion state of the pod. If the current state is either in DOC, CONGESTION_L1, CONGESTION_L2, or Congested state, then the congestion control mechanism is triggered. After verifying that the message type is a request, a request priority is assigned to it. If the request priority is greater than or equal to the discard priority, then the message is rejected, otherwise it is accepted.

Congestion Control Load Shedding using Discard and Request Priority

The PCRF Core service pods performs load shedding by considering the load rule configured for the current congestion state. The load shedding rule is based on message priority configuration. A default load shedding rule is active and the messages are discarded based on it. You can configure these load rules using the Overload and Congestion Control menu in CNC Console. The Diameter Gateway discards the requests based on Priority.

Table 4-48 PCRF Core Service Default Discard Priorities:

Congestion State	Discard Priority (Default Value)
DANGER_OF_CONGESTION	29
CONGESTION_L1	23
CONGESTION_L2	17
CONGESTED	15

For more information about discard priority configurations, see Congestion Control Load Shedding Rules section in CNC Console.

Assigning Message Priority:

The HTTP requests to the PCRF service may have message priority included as oc-message-priority attribute in the request header. The message priority value ranges between 0 to 100 with 0 being the highest and 100 being the lowest priority. If the priority header is not provided in the requests, then the message priority that is either configured in the Advanced Settings of PCRF Core service or default priority values will be considered. Following is the list of configurable keys that can be added to set the HTTP message priority:

Table 4-49 Configuring Message Priority

Key	Default Value	Description
CONGESTION.HTTP.RESPONSE.CODE	503	Configure the response code of any rejected requests by PCRF Core service due to congestion state. By default, the service sends 503 as response code. If configured then it shall be either 1xx, or 3xx, or 4xx, or 5xx status code.
PDS.NOTIFY.REQUEST.PRIORITY	18	Set request priority for post PDS notification request. Allowed Values: 0-100
UM.NOTIFY.REQUEST.PRIORITY	18	Set request priority for post Usage monitoring notification request. Allowed Values: 0-100
PCRF.SESSION.DELETE.REQUEST.PRIORITY	30	Set request priority for deleting PCRF session request. Allowed Values: 0-100
PCRF.SESSION.GET.REQUEST.PRIORITY	30	Set request priority for fetching PCRF session request. Allowed Values: 0-100
AUDIT.NOTIFY.REQUEST.PRIORITY	30	Set request priority for post Audit notification request. Allowed Values: 0-100

The Diameter requests to the PCRF service may have AVP named as OC-Message-Priority. The message priority value for this AVP ranges between 0 to 100. If Diameter Gateway,

• on receiving Diameter Routing Message Priority (DRMP) from the clients, it sets OC-Message-Priority to DRMP*2 and sends it to PCRF Core service.
• on not receiving DRMP from client, then it will not send OC-Message-Priority to PCRF Core service.

If the priority AVP is not provided in the request, then the message priority that is either configured in the Advanced Settings of PCRF Core service or default priority values will be considered.

Table 4-50 Configuring Message Priority

Key	Default Value	Description
CONGESTION.USE.EXPERIMENTAL.RESULT.CODE	false	To set if user wants to use experimental result code when rejecting diameter messages. Allowed values are true or false. By default it will be false.
CONGESTION.VENDOR.ID	0	To set the vendor id when user wants to send experimental response code. To use experimental result code, set CONGESTION.USE.EXPERIMENTAL.RESULT.CODE as true, and set CONGESTION.VENDOR.ID as non-zero positive integer.
CONGESTION.DIAMETER.RESPONSE.CODE	3004	To set response code when rejecting diameter messages. Only valid 3xxx, 4xxx, 5xxx response codes are allowed.
GX.CREATE.REQUEST.PRIORITY	24	Set message priority for Diameter message Gx CCR-I. Allowed Values: 0-100
GX.MODIFY.REQUEST.PRIORITY	18	Set message priority for Diameter message Gx CCR-U. Allowed Values: 0-100
GX.DELETE.REQUEST.PRIORITY	16	Set message priority for Diameter message Gx CCR-T. Allowed Values: 0-100
RX.CREATE.REQUEST.PRIORITY	24	Set message priority for Diameter message Rx AAR-I. Allowed Values: 0-100
RX.MODIFY.REQUEST.PRIORITY	18	Set message priority for Diameter message Rx AAR-U. Allowed Values: 0-100
RX.DELETE.REQUEST.PRIORITY	16	Set message priority for Diameter message Rx STR. Allowed Values: 0-100
SD.MODIFY.REQUEST.PRIORITY	18	Set message priority for Diameter message Sd CCR-U. Allowed Values: 0-100
SD.DELETE.REQUEST.PRIORITY	16	Set message priority for Diameter message Sd CCR-T. Allowed Values: 0-100

Note:

Currently Diameter Gateway sends OC-Message-Priority AVP only when it receives Diameter Routing Message Priority (DRMP) AVP. During PCRF Core pod in congestion state, if Diameter messages received do not have DRMP AVP, then either the configured or default message priority will be considered based on the AppId, CmdCode and RequestType. Due to all these considerations, Pcrf-core may reject requests for APNs and Service-URNs for emergency calls, MCPTT calls, and other special session requests.

Congestion Response Code

You can also configure the result codes for the rejected requests when configuring the load rules. By default, PCRF Core service sends 503 as response code. You can configure the response code using PCRF service advanced settings key CONGESTION.HTTP.RESPONSE.CODE in CNC Console. This key is used to configure the response code of the HTTP messages that are rejected by the PCRF service due to pod's congestion state. The configurable response code could be set to 1xx, or 3xx, or 4xx, or 5xx response code.

For Diameter requests, the PCRF Core discards the requests with default 3004 DIAMETER_TOO_BUSY. You can configure the response code using PCRF service advanced settings key CONGESTION_DIAMETER_RESPONSE_CODE in CNC Console. The configurable response code could be set to either 3xxx, 4xxx, or 5xxx response code.

For more information about the advanced keys in PCRF Core service, see Settings menu in CNC Console.

For more information about different response codes that can be configured, see Congestion Control Discard Message Response Code section.

Example for Congestion Control Call Flow/Scenario

For the below call flows, consider the following load shedding rule configuration:

Table 4-51 Load Shedding Rule

Congestion State	Discard Priority
DOC	29
CONGESTION_L1	23
CONGESTION_L2	17
CONGESTED	15

The call flow describes the PCRF Core service congestion control mechanism handling the requests from the other Policy services such as Diameter Gateway, PDS and Audit services when its Pod exists in different congestion state.

Figure 4-35 PCRF Core Service Congestion Control Call Flow

PCRF Core pod is in DOC state and the discard priority is configured as 29:

• Diameter Gateway service sends a Gx CCR-I request with discard priority value set to 24 toward PCRF service.
• PCRF Core service responds with a success status.
• Audit service sends a notification request with discard priority value set to 30 toward PCRF service.
• PCRF Core service responds with a reject 503 status or with any configured error code and message.

PCRF Core pod is in Congestion_L1 state and the discard priority is configured as 23:

• Diameter Gateway service sends a Gx CCR-I request with discard priority value set to 24 toward PCRF service.
• PCRF Core service responds with a reject 3004 status or with any configured error code and message.
• Diameter Gateway service sends a Gx CCR-U request with discard priority value set to 18 toward PCRF service.
• PCRF Core service responds with a success status.
• PDS service sends a notification request with discard priority value set to 18 toward PCRF service.
• PCRF Core service responds with a success status.

PCRF Core pod is in Congestion_L2 state and the discard priority is configured as 17:

• Diameter Gateway service sends a Gx CCR-I request with discard priority value set to 24 toward PCRF service.
• PCRF Core service responds with a reject 3004 status or with any configured error code and message.
• Diameter Gateway service sends a Gx CCR-T request with discard priority value set to 16 toward PCRF service.
• PDS service responds with the success status.

PCRF Core pod is in Congested state and the discard priority is configured as 15:

• Diameter Gateway service sends a Gx CCR-T request with discard priority value set to 16 toward PCRF service.
• PCRF Core service responds with a reject 3004 status or with any configured error code and message.

Managing PCRF Core service Pod Congestion Control

Enable

By default, the Pod Congestion Control is disabled for PCRF Core service. You can enable this feature using CNC Console or REST API for Policy.

Configure Using CNC Console

To enable the feature using CNC Console, set the Enable parameter in Settings page under Congestion Control for Overload and Congestion Control Configurations.

Note:

• In a Policy fresh installation the CPU EMA ratio is set to 90:10.
• When upgrading from 24.3.x to 25.1.200 or higher version then user has to update custom threshold profiles manually, by considering the default values as a reference. Also, it is recommended that user should set CPU EMA ratio as 90:10 in Congestion Control Settings.
• When upgrading from versions lower than 24.3.0 to 25.1.200 or higher version, then the default profile will be activated and by default CPU EMA ratio will be set as 90:10 in Congestion Control Settings.
• When exporting data from 24.3.x and importing it in 25.1.200 or higher version then user has to update the custom threshold profiles manually by considering the default values as a reference. Also, it is recommended that user should set CPU EMA ratio as 90:10 in Congestion Control Settings.

To configure PCRF service pod congestion control feature in CNC Console, see Congestion Control section.

To configure PCRF service pod congestion control discard messages in CNC Console, see the Advanced Settings section in Settings of PCRF Core service.

Configure Using REST API

Perform the feature configurations as described in "Congestion Control" section in Oracle Communications Cloud Native Core, Converged Policy REST Specification Guide.

Observability

Metrics:

The following common service metrics are used to provide information about this feature:

• occnp_pod_congestion_state
• occnp_pod_resource_stress
• occnp_pod_resource_congestion_state
• occnp_pod_cong_state_report_total
• occnp_pod_resource_congestion_state_report_total
• occnp_congestion_http_pending_request_active_counter

For information about the metrics, see Pod Congestion Metrics section.

The following PCRF Core service metrics are used to provide information about this feature:

• occnp_http_congestion_message_reject_total
• occnp_diam_congestion_message_reject_total
• occnp_http_pending_requests_total
• occnp_diam_pending_requests_total
• occnp_congestion_diam_pending_request_active_counter
• occnp_congestion_diam_pending_request_end_to_end_id_map_size
• occnp_congestion_DiamMsgBuffer_queue_msg_count

For information about the metrics, see PCRF Core Metrics section.

Alerts

The following alerts are generated for this feature:

• POD_CONGESTED
• POD_CONGESTION_L2
• POD_CONGESTION_L1
• POD_DANGER_OF_CONGESTION
• POD_PENDING_REQUEST_CONGESTED
• POD_PENDING_REQUEST_CONGESTION_L2
• POD_PENDING_REQUEST_CONGESTION_L1
• POD_PENDING_REQUEST_DANGER_OF_CONGESTION
• POD_CPU_CONGESTED
• POD_CPU_CONGESTION_L2
• POD_CPU_CONGESTION_L1
• POD_CPU_DANGER_OF_CONGESTION

For more information about alerts, see Common Alerts.

Maintain

Warning logs are generated to indicate the congestion level. However, error logs are not generated when messages are rejected to avoid additional resource usage to write error logs.

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.

4.8.10 Binding Service Pod Congestion Control

Binding Service, a Policy microservice provides:

• session binding information on receiving binding request from SM service.
• subscriber/Data Network Name (DNN) session limit check across Gx and N7 session or within multiple sessions for a 4G/5G deployments.
• context owner information to Diameter Gateway for routing Rx messages for a 4G/5G deployments.

Figure 4-36 Binding Service and Other Policy Services

The above diagram shows Binding service interaction with Policy SM, PCRF Core, cnDBTier, Audit, Diameter Gateway and Egress Gateway services. At times, an excessive traffic from these services can be observed in the network, which can result in a high CPU utilization, high memory utilization. This can cause performance degradation in Binding service responses and eventually reach a state of service unavailability. Congestion control is used in order to help in identifying such conditions and invoke rules that address these situations when these load conditions persist.

Pod Congestion Control Mechanism

The Pod congestion control mechanism involves:

1. Determining Pod Congestion State
2. Triggering Pod Congestion Control

Determining Pod Congestion State

Binding service pods exist in any of the following five states at any given time:

• Normal
• Danger of Congestion (DOC)
• CONGESTION_L1
• CONGESTION_L2
• CONGESTED

Figure 4-37 Different Pod Congestion States

Periodically, the state of the pod's congestion gets determined. This interval is configurable, and the default setting is 200 milliseconds.

The pod's state gets determined by considering the following points.

1. Calculate the congestion state for the following resources:
   1. Queue: For the DOC, CONGESTION_L1, CONGESTION_L2 and CONGESTED pod states, compare the number of pending messages in the queue with the configured pending messages threshold.
   2. CPU: The CPU usage for congestion state is calculated by comparing the CPU usage of the Container (monitored using cgroup parameter - cpuacct.usage that provides current cpu usage in nanoseconds) with the configured threshold.
2. The congestion state for pod gets assigned a maximum congested state based on the congestion state of the resources.

The Binding service pod's can be in following Congestion states:

Table 4-52 Binding service Congestion States

Congestion States	CPU Count	Queue Count
DANGER_OF_CONGESTION (DOC)	70	120
CONGESTION_L1	75	150
CONGESTION_L2	80	180
CONGESTED	85	200

Triggering Pod Congestion Control

Every time Binding service receives requests from other services, it checks for the current congestion state of the pod. The Congestion Control mechanism is triggered if the pod's congestion state is in DOC or Congested_L1 or Congested_L2 or Congested.

The requests to the Binding service might have priority included as oc-message-priority attribute in the request header. The priority value ranges between 0 to 100 with 0 being the highest and 100 being the lowest priority.

Priority-Based Load Shedding

Based on the pods current congestion state a load shedding rule is applied to perform priority-based load shedding. The load shedding rule is based on message priority, e.g., when the Binding service Pod state is CONGESTED, then discard messages with priority 30. It determines if the message with the assigned priority should be rejected or accepted.

The user can configure load shedding rule for Binding service by providing the discard priority for each of the congestion state. If not, a default load shedding rule is active, and messages are discarded based on it. The user can configure the result codes for the rejected requests when configuring the load rules. The default result code is 503 Service Unavailable for HTTP messages.

The default load shedding rules for Binding service:

- state: DANGER_OF_CONGESTION        
      discardPriority: 30
- state: CONGESTION_L1
      discardPriority: 27
- state: CONGESTION_L2
      discardPriority: 24       
- state: CONGESTED
      discardPriority: 20

When Binding service is in congestion state, it's response can be configured using Binding service Advanced settings in CNC Console, using the key CONGESTION_RESPONSE_CODE. This key is used to configure for response code of the messages that is rejected by the Binding service due to pod congestion state. By default Binding Service responds with a response code of 503. The user can configure this parameter with either 1xx, 3xx, 4xx, or 5xx response codes. Following are the list of configurable keys that can be added to set the message priority:

Table 4-53 Configuring Message Priority

Key	Default Value	Allowed Values
AUDIT_MESSAGE_PRIORITY	30	0-100
BSF_AUDIT_MESSAGE_PRIORITY	27	0-100
DEPENDENT_CONTEXT_BINDING_REGISTER_MESSAGE_PRIORITY	24	0-100
DEPENDENT_CONTEXT_BINDING_DEREGISTER_MESSAGE_PRIORITY	16	0-100
DEPENDENT_CONTEXT_BINDING_FIND_CONTEXT_OWNER_MESSAGE_PRIORITY	16	0-100
SESSION_BINDING_REGISTER_MESSAGE_PRIORITY	24	0-100
SESSION_BINDING_UPDATE_MESSAGE_PRIORITY	20	0-100
SESSION_BINDING_DEREGISTER_MESSAGE_PRIORITY	16	0-100
SESSION_BINDING_SEARCH_MESSAGE_PRIORITY	30	0-100
SESSION_BINDING_FIND_CONTEXT_OWNER_MESSAGE_PRIORITY	16	0-100
SESSION_BINDING_CLEANUP_MESSAGE_PRIORITY	30	0-100
BSF_SESSION_UPDATE_MESSAGE_PRIORITY	20	0-100
STALE_SESSION_TRACKER_REFRESH_MESSAGE_PRIORITY	30	0-100

Note:

• When upgrading from 24.1.x to 24.2.x or higher version then user has to update custom Threshold profiles manually, by taking new default values as a reference. When upgrading from versions lower than 24.1.0 to 24.2.x or higher version then the DEFAULT profile will be activated with new values.
• When exporting data from 24.1.x and importing it in 24.2.x or higher version then user has to update the custom Threshold profiles value manually by taking new default values as a reference before import.

Congestion Control Call Flow/Scenario

For the below call flows, consider the following Load shedding rule configuration:

Table 4-54 Load Shedding Rule

Congestion State	Discard Priority
DOC	27
CONGESTION_L1	23
CONGESTION_L2	18
CONGESTED	10

Binding Service Call Flow in Doc State

The call flow describes the Binding service congestion control mechanism handling the requests from the other Policy services such as SM/PCRF core, Audit, Diameter Gateway, and Query services when it is in Danger of Congestion (DOC) state.

Figure 4-38 Binding Service Pod in DOC State

• SM/PCRF-Core services sends a register request with discard priority set to 24 to Binding service and it responds back with success status.
• Audit service sends a audit notification request with discard priority set to 30 to Binding service and it responds back with a reject 503 status.
• SM service sends a de-register request with discard priority set to 16 to Binding service and it responds back with success status.
• Diameter Gateway service sends a find context owner request with discard priority set to 16 to Binding service and it responds with a success status.
• Query Gateway service sends a find context owner request with discard priority set to 30 to Binding service and it responds back with a reject 503 status.

Binding Service Call Flow in Congestion_L2 State

The call flow describes the Binding service congestion control mechanism handling the requests from the other Policy services such as SM/PCRF core, Audit, Diameter Gateway, and Query services when it is in Congestion_L2 state.

Figure 4-39 Binding Service in Congestion_L2 State

• SM/PCRF-Core service sends a register request with discard priority set to 24 to Binding service and it responds back with a reject 503 status.
• Audit service sends a audit notification request with discard priority set to 30 to Binding service and it responds back the a reject 503 status.
• SM service sends a de-register request with discard priority set to 16 to Binding service and it responds back with success status.
• Diameter Gateway service sends a find context owner request with discard priority set to 16 to Binding service and it responds back with success status.
• Query Gateway service sends a find context owner request with discard priority set to 30 to Binding service and it responds back with a reject 503 status.

Managing Binding service Pod Congestion Control

Enable

By default, the Pod Congestion control is disabled for Binding service. You can enable this feature using CNC Console or REST API for Policy.

Configure Using CNC Console

To enable the feature using CNC Console set the Enable parameter in Settings page under Congestion Control for Overload and Congestion Control Configurations.

Perform the Binding service Congestion Control feature configurations on the Settings, Threshold and Load Shedding Rules in CNC Console as described in Congestion Control section.

Perform the Binding service Congestion Control feature discard message configurations at Advanced Settings in CNC Console as described in Binding Service section.

Configure Using REST API

Perform the feature configurations as described in "Congestion Control" section in Oracle Communications Cloud Native Core, Converged Policy REST Specification Guide.

Observability

Metrics:

Following metrics were updated in the Pod Congestion Metrics section.

• occnp_pod_congestion_state
• occnp_pod_resource_stress
• occnp_pod_resource_congestion_state
• pod_cong_state_report_total
• pod_resource_congestion_state_report_total
• http_congestion_message_reject_total

Alerts

The following alerts generated for this feature:

• POD_CONGESTED
• POD_CONGESTION_L2
• POD_CONGESTION_L1
• POD_DANGER_OF_CONGESTION
• POD_PENDING_REQUEST_CONGESTED
• POD_PENDING_REQUEST_CONGESTION_L2
• POD_PENDING_REQUEST_CONGESTION_L1
• POD_PENDING_REQUEST_DANGER_OF_CONGESTION
• POD_CPU_CONGESTED
• POD_CPU_CONGESTION_L2
• POD_CPU_CONGESTION_L1
• POD_CPU_DANGER_OF_CONGESTION

For more information about alerts, see Common Alerts.

Maintain

Error logs are generated when the system is congested and the actions are taken to bring the system back to normal. Warning logs are generated to indicate the congestion level. However, error logs are not generated when messages are rejected to avoid additional resource usage to write error logs.

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.

4.8.11 Bulwark Pod Congestion Control

Bulwark, a Policy microservice provides distributed lock mechanism using distributed coherence. It handles concurrent transactions across consumer services. Since the lock is distributed, the deployed pods request a lock for a resource based on a unique identifier in the global system rather than acquiring a lock locally in a single pod.

The traffic at Bulwark service is high as all the consumer services use its distributed lock mechanism to handle concurrent transactions. In the production environment, the Bulwark pods must be protected from traffic congestion. Bulwark pod congestion control functionality helps in regulating the traffic and improves its service availability. The Pod congestion control mechanism is designed to identify congestion conditions and apply load shedding rules to maintain optimal service levels.

The Bulwark service receives every incoming requests, the congestion control mechanism decides to either accept or reject the request based on pods congestion state defined request priority. It invokes the load shedding rules when congestion state persist in the pods. The pod congestion control mechanism involves:

1. Determining Pod Congestion State
2. Triggering Pod Congestion Control

Determining Pod Congestion State

In congestion control mechanism different congestion levels are defined, each level indicates how congested the pod is, and which requests can be served when pod is on certain congestion level. The congestion control works at following five congestion levels or states:

1. Normal
2. Danger of Congestion (DOC)
3. CONGESTION_L1
4. CONGESTION_L2
5. Congested

Each pod monitors its congestion state. The pod's congestion state is decided based on CPU consumption and Queue.

The pod's state gets determined by considering the following points.

1. CPU - The CPU usage for congestion state is calculated by comparing the CPU usage of the Container (monitored using cgroup parameter - cpuacct.usage that provides current cpu usage in nanoseconds) with the configured threshold. The following formula calculates the CPU usage:
2. Queue: For the DOC, CONGESTION_L1, CONGESTION_L2, and CONGESTED pod states, compare the number of pending messages in the queue with the configured pending messages threshold.

To avoid toggling between these states due to traffic pattern, it is required for the pod to be in a particular state for a given period before transitioning to another state. The below configurations are used to define the period that the pod has to be in a particular state for:

• stateChangeSampleCount: This parameter can be configured to specify after how many continuous intervals, the pod state can be changed. The default value is 5. This value can range from 1 to 2147483647.
• stateCalculationInterval: This parameter can be configured to specify the time duration or interval, after which the pod congestion state will be re-verified. The default value is 200ms. This interval is configured in milliseconds and can range from 50 to 2147483647.

For more information about these congestion control configurations, see Congestion Control Settings section in CNC Console.

CPU and Queue Threshold

The pod's state changes when its resources, namely the CPU and Queue buffer usage exceeds the predefined congestion threshold, checked at regular intervals. An active CPU and Queue default threshold profile can be viewed using CNC Console at Policy → Overload and Congestion Control → Congestion Control → Thresholds section. The user can create new threshold profile and make it active. The CPU and Queue threshold should be added in the order of DOC → Congestion_L1 → Congestion_L2 → Congested states. The Bulwark service pod's different congestion states and their default congestion parameters, CPU, and Queue pending counts are provided in the following table:

Table 4-55 Bulwark Service Congestion States

Congestion States	CPU (%)	Queue Count (Pending Requests)
DANGER_OF_CONGESTION (DOC)	60	6300
CONGESTION_L1	70	7200
CONGESTION_L2	80	8100
CONGESTED	90	9000

For more information about these CPU and Queue count thresholds configurations, see Congestion Control Thresholds section in CNC Console.

Triggering Congestion Control

With Congestion Control feature enabled for Bulwark service, every time a message is fetched for processing, the system checks the current congestion state of the pod. If the current state is either in DOC, CONGESTION_L1, CONGESTION_L2, or Congested state, then the congestion control mechanism is triggered. After verifying that the message type is a request, a request priority is assigned to it. If the request priority is greater than or equal to the discard priority, then the message is rejected, otherwise it is accepted.

Congestion Control Load Shedding using Discard and Request Priority

Bulwark pods performs load shedding by considering the load rule configured for the current congestion state. The load shedding rule is based on message priority configuration. A default load shedding rule is active and the messages are discarded based on it. You can create new load rules using the Overload and Congestion Control menu in CNC Console and make it active. The discard priorities should be added in the order of DOC → Congestion_L1 → Congestion_L2 → Congested states.

Table 4-56 Priority based Message Discards

Congestion State	Discard Priority (Default Value)
DANGER_OF_CONGESTION	27
CONGESTION_L1	19
CONGESTION_L2	17
CONGESTED	15

For more information about these Priority discards configurations, see Congestion Control Load Shedding Profiles page in CNC Console.

SM Service Supporting the Priority Header for Lock and Unlock requests

SM service supports bulwark congestion control by adding the priority attribute oc-message-priority in the lock/unlock requests header. The 3gpp-Sbi-Message-Priority header is used to specify the message priority for 3GPP service based interfaces. This header is included in messages when a priority for the message must be conveyed. By default the oc-message-priority uses the 3gpp-Sbi-Message-Priority value to evaluate message priority. Requests without 3gpp-Sbi-Message-Priority header are assigned default values. If the user wants to assign a different priority to the response message than the default ones, this can be configured using the Advanced settings of SM service in the CNC Console. Following are the advanced setting configurable parameters:

Table 4-57 SM Service Request Default Priorities

Advanced Settings Key	Value	Message Type
REQUEST_PRIORITY_FOR_SM_CREATE	24	Create
REQUEST_PRIORITY_FOR_SM_UPDATE	18	Update
REQUEST_PRIORITY_FOR_SM_UPDATE_NOTIFY	18	Update Notify
REQUEST_PRIORITY_FOR_SM_DELETE	16	Delete
REQUEST_PRIORITY_FOR_SM_CLEANUP	18	Cleanup
USE_TGPP_SBI_MSG_PRIORITY	true	Set this to false, if the SM service does not want to consider the 3gpp-Sbi-Message-Priority value for oc-message-priority.

Congestion Response Code

You can also configure the result codes for the rejected requests when configuring the load rules. By default, Bulwark service sends 503 as response code. You can configure the response code and cause by adding Advance Settings key and value at Bulwark Settings page in CNC Console. The following are the advances settings key and value:

Table 4-58 Advance Setting

Key	Value	Description
CONGESTION_RESPONSE_CODE	503	This is to configure the bulwark result code for the congestion control discards and its value shall be numerical. The value can be set to either 1xx, 3xx, 4xx, or 5xx response codes. If this value is not configured, then default congestion result code shall be 503. Default Value: 503

When Bulwark pod is in congestion state, the response code for the rejected requests can be configured using the responseCode Helm parameter in the values.yaml file. By default, the responseCode parameter for Bulwark service is set to 503 Service Unavailable response code. The user can configure this parameter with either 1xx, 3xx, 4xx, or 5xx response codes.

Sample Helm Configuration for Bulwark Service:

  congestion:   
       responseCode: 503

For more information about different response codes that can be configured, see Congestion Control Discard Message Response Code section.

Call Flow

Below diagram shows the call flow for SM service supporting the priority header functionality for the 5 states of congestion, namely, Danger of Congestion, Congestion_L1, Congestion_L2, and Congested.

Figure 4-40 Call Flow Diagram for Bulwark Congestion Control

• Bulwark receives an SM service lock request with priority set to 10 when it is in the DOC state with the reject priority set to 5. On comparing both priorities, bulwark rejects the message with result code since the message priority value is higher than the reject priority. The message returns with result code 503 Service unavailable or any configurable error code with message.
• Bulwark receives an SM service unlock request with priority set to 3 when it is in the DOC state with the reject priority set to 5. On comparing both priorities, bulwark accepts the message with result code Success since the message priority value is lower than the reject priority.
• Bulwark receives an SM service lock request with priority set to 10 when it is in the CONGESTED state with reject priority set to 1. On comparing both priorities, bulwark rejects the message with result code since the message priority value is higher than the reject priority. The message returns with result code 503 Service unavailable or any configurable error code with message.
• Bulwark receives an SM service unlock request with priority set to 5 when it is in the CONGESTED state with reject priority set to 1. On comparing both priorities, bulwark rejects the message with result code since the message priority value is higher than the reject priority. The message returns with result code 503 Service unavailable or any configurable error code with message.
• Bulwark receives an SM service lock or unlock request when it is in the NORMAL state. Bulwark accepts the message with result code Success since the requests do not have priority value set.

Feature Upgrade Impact

With upgrade of Policy application from any of the previous release versions to 25.1.200, the Bulwark pod Congestion Control feature can be updated to use the common Congestion Control mechanism available in 25.1.200. In order to do this, there are some considerations to address, especially due to the difference in configuration data. Bulwark service pod congestion control configurations from the previous version should be migrated to use the current version configurations. The data migration process is manual and one-time activity that user has to perform, by using either the CNC Console or Congestion Control migration APIs.

Feature Transition

Bulwark Pod Congestion Control feature transition between older version to the Policy 25.1.200 Congestion Control mechanism is based on migration status of the Policy application after the upgrade. The migration status can be either in "Before Migration" or "After Migration".

False (Before Migration): After upgrading to Policy version 25.1.200, the Bulwark pod congestion control feature still operates under the configurations and designs of the pre-upgrade version until the user actively migrates the setup. In this "False" state, the users will only see:

• Old Configurations: The Bulwark Congestion Control configurations from the previous application version.
• Previous CNC Console pages: User will have access to the older user interface rather than the new screen designed for Congestion Control feature.
• Legacy REST APIs: Calls to APIs will still work with the previous version's endpoints.

To enable the common Congestion Control mechanism for Bulwark service, users will need to complete the data migration process.

True (After Migration): After the upgrade to Policy version 25.1.200, perform the data migration for Bulwark pod Congestion Control feature. With this, the migration status will be "True" and Bulwark services can use the updated Congestion Control mechanisms.

For more information related to Congestion Control configuration migration, see "Migration of Bulwark Service Congestion Control Configurations" section in Congestion Control Settings page in CNC Console.

Note:

When Policy 25.1.200 or any of the later versions is fresh installed or when Policy is upgraded from any of the previous versions to Policy 25.1.200 or later versions, after the Bulwark congestion migration is completed, the updated Congestion Control REST API does not accept the configuration of activeThresholdProfile parameter in the request body. This is inline with all services congestion control behaviour.

Sample REST API:

Method: PUT
URL: ../oc-cnpolicy-configuration/v1/congestionConfigurations/bulwark
Header:
  Content-Type: application/json
  Accept: application/json
Body:
{
 "enable":true,
 "stateChangeSampleCount":5,
 "stateCalculationInterval":5000
}

When Policy is upgraded from any of the previous versions to 25.1.200 or later versions, before the Bulwark congestion migration completed, the updated Congestion Control REST API accepts the activeThresholdProfile parameter in the Request Body as this is old Bulwark congestion behaviour and is not inline with all services congestion control behaviour.

Sample REST API:

Method: PUT
URL: ../oc-cnpolicy-configuration/v1/congestionConfigurations/bulwark
Header:
  Content-Type: application/json
  Accept: application/json
Body:
{
 "activeThresholdProfile":"DEFAULT",
 "enable":true,
 "stateChangeSampleCount":5,
 "stateCalculationInterval":5000
}

Managing Bulwark Pod Congestion Control

Enable

By default, the Pod Congestion control is disabled for Bulwark service. You can enable this feature using CNC Console or REST API for Policy.

Feature Migration

If the Policy application is upgraded to 25.1.200, then you can enable this feature by performing the migration process. For more information how to perform the data migration, see "Migration of Congestion Control Configuration Data" section in Congestion Control Settings page using CNC Console.

Configure

You can customize the configurations related to this feature using the CNC Console or REST APIs for Policy:

• Configure using CNC Console:

  To enable the feature using CNC Console, set the Enable parameter in Settings page under Congestion Control for Overload and Congestion Control Configurations for Bulwark Service.

  To configure Bulwark service pod congestion control feature in CNC Console, see Congestion Control section.

• Configure using REST API:

  To enable this feature using REST API, perform the feature configurations as described in "Congestion Control" APIs section in Oracle Communications Cloud Native Core, Converged Policy REST Specification Guide.

  If the Policy application is upgraded to 25.1.200, then you can enable this feature by performing the migration process. For more information how to perform the data migration using Congestion Control Migration APIs, see "Congestion Migration" APIs section in Oracle Communications Cloud Native Core, Converged Policy REST Specification Guide.

Observability

Metrics:

Following metrics were updated in the Pod Congestion Metrics section.

• occnp_pod_congestion_state
• occnp_pod_resource_stress
• occnp_pod_resource_congestion_state
• occnp_pod_cong_state_report_total
• occnp_pod_resource_congestion_state_report_total
• occnp_congestion_http_pending_request_active_counter
• occnp_http_congestion_message_reject_total

Note:

Prometheus automatically injects name of the pod with label name "kubernetes_pod_name" to the metric. This information is further used for alerting purposes.

Alerts:

Following alerts are used by this feature:

• POD_CONGESTED
• POD_CONGESTION_L2
• POD_CONGESTION_L1
• POD_DANGER_OF_CONGESTION
• POD_PENDING_REQUEST_CONGESTED
• POD_PENDING_REQUEST_CONGESTION_L2
• POD_PENDING_REQUEST_CONGESTION_L1
• POD_PENDING_REQUEST_DANGER_OF_CONGESTION
• POD_CPU_CONGESTED
• POD_CPU_CONGESTION_L2
• POD_CPU_CONGESTION_L1
• POD_CPU_DANGER_OF_CONGESTION

Maintain

Error logs are generated when the system is congested and the actions taken to bring the system back to normal. Warning logs are generated to indicate the congestion level. However, error logs are not generated when messages are rejected to avoid additional resource usage to write error logs.

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.

4.8.12 Congestion Control Discard Message Response Code

In Congestion Control mechanism, on Pod being in any of the congested states the messages are discarded based on the message priority. The discarded messages responses can have customized error response. In Policy application, the services supporting the Congestion Control mechanism can configure the discarded messages error response in their service specific Advanced Settings page in CNC Console.

The following table lists the supported HTTP response code:

Table 4-59 Supported HTTP Response Codes

Series	Code	Cause	Type
1xx	101	Continue	INFORMATIONAL
1xx	102	Switching Protocols	INFORMATIONAL
1xx	103	Processing	INFORMATIONAL
1xx	104	Early Hints	INFORMATIONAL
3xx	300	Multiple Choices	REDIRECTION
3xx	301	Moved Permanently	REDIRECTION
3xx	302	Found	REDIRECTION
3xx	303	See Other	REDIRECTION
3xx	304	Not Modified	REDIRECTION
3xx	305	Use Proxy	REDIRECTION
3xx	307	Temporary Redirect	REDIRECTION
3xx	308	Permanent Redirect	REDIRECTION
4xx	400	Bad Request	CLIENT_ERROR
4xx	401	Unauthorized	CLIENT_ERROR
4xx	402	Payment Required	CLIENT_ERROR
4xx	403	Forbidden	CLIENT_ERROR
4xx	404	Not Found	CLIENT_ERROR
4xx	405	Method Not Allowed	CLIENT_ERROR
4xx	406	Not Acceptable	CLIENT_ERROR
4xx	407	Proxy Authentication Required	CLIENT_ERROR
4xx	408	Request Timeout	CLIENT_ERROR
4xx	409	Conflict	CLIENT_ERROR
4xx	410	Gone	CLIENT_ERROR
4xx	411	Length Required	CLIENT_ERROR
4xx	412	Precondition Failed	CLIENT_ERROR
4xx	413	Payload Too Large	CLIENT_ERROR
4xx	414	URI Too Long	CLIENT_ERROR
4xx	415	Unsupported Media Type	CLIENT_ERROR
4xx	416	Requested range not satisfiable	CLIENT_ERROR
4xx	417	Expectation Failed	CLIENT_ERROR
4xx	418	I'm a teapot	CLIENT_ERROR
4xx	419	Insufficient Space On Resource	CLIENT_ERROR
4xx	420	Method Failure	CLIENT_ERROR
4xx	421	Destination Locked	CLIENT_ERROR
4xx	422	Unprocessable Entity	CLIENT_ERROR
4xx	423	Locked	CLIENT_ERROR
4xx	424	Failed Dependency	CLIENT_ERROR
4xx	425	Too Early	CLIENT_ERROR
4xx	426	Upgrade Required	CLIENT_ERROR
4xx	428	Precondition Required	CLIENT_ERROR
4xx	429	Too Many Requests	CLIENT_ERROR
4xx	431	Request Header Fields Too Large	CLIENT_ERROR
4xx	451	Unavailable For Legal Reasons	CLIENT_ERROR
5xx	500	Internal Server Error	SERVER_ERROR
5xx	501	Not Implemented	SERVER_ERROR
5xx	502	Bad Gateway	SERVER_ERROR
5xx	503	Service Unavailable	SERVER_ERROR
5xx	504	Gateway Timeout	SERVER_ERROR
5xx	505	HTTP Version not supported	SERVER_ERROR
5xx	506	Variant Also Negotiates	SERVER_ERROR
5xx	507	Insufficient Storage	SERVER_ERROR
5xx	508	Loop Detected	SERVER_ERROR
5xx	509	Bandwidth Limit Exceeded	SERVER_ERROR
5xx	510	Not Extended	SERVER_ERROR
5xx	511	Network Authentication Required	SERVER_ERROR

Note:

If the congestion response code other than above supported HTTP response codes is configured, then the default response code 503 shall be assigned and below log message will be logged:

Log line => Exception occurred: No matching constant for '512' Rejecting request with default response code: 503.

The following table lists the supported Diameter result codes:

Table 4-60 Supported Diameter Result Codes

Series	Code	Name
3xxx	3001	DIAMETER_COMMAND_UNSUPPORTED
3xxx	3002	DIAMETER_UNABLE_TO_DELIVER
3xxx	3003	DIAMETER_REALM_NOT_SERVED
3xxx	3004	DIAMETER_TOO_BUSY
3xxx	3005	DIAMETER_LOOP_DETECTED
3xxx	3006	DIAMETER_REDIRECT_INDICATION
3xxx	3007	DIAMETER_APPLICATION_UNSUPPORTED
3xxx	3008	DIAMETER_INVALID_HDR_BITS
3xxx	3009	DIAMETER_INVALID_AVP_BITS
3xxx	3010	DIAMETER_UNKNOWN_PEER
4xxx	4001	DIAMETER_AUTHENTICATION_REJECTED
4xxx	4002	DIAMETER_OUT_OF_SPACE
4xxx	4003	ELECTION_LOST
4xxx	4010	DIAMETER_END_USER_SERVICE_DENIED
4xxx	4011	DIAMETER_CREDIT_CONTROL_NOT_APPLICABLE
4xxx	4012	DIAMETER_CREDIT_LIMIT_REACHED
4xxx	4999	SPLIT_BRAIN_SUSPECTED
5xxx	5001	DIAMETER_AVP_UNSUPPORTED
5xxx	5003	DIAMETER_AUTHORIZATION_REJECTED
5xxx	5004	DIAMETER_INVALID_AVP_VALUE
5xxx	5005	DIAMETER_MISSING_AVP
5xxx	5006	DIAMETER_RESOURCES_EXCEEDED
5xxx	5007	DIAMETER_RESOURCES_EXCEEDED
5xxx	5008	DIAMETER_AVP_NOT_ALLOWED
5xxx	5009	DIAMETER_AVP_OCCURS_TOO_MANY_TIMES
5xxx	5010	DIAMETER_NO_COMMON_APPLICATION
5xxx	5011	DIAMETER_UNSUPPORTED_VERSION
5xxx	5012	DIAMETER_UNABLE_TO_COMPLY
5xxx	5013	DIAMETER_INVALID_BIT_IN_HEADER
5xxx	5014	DIAMETER_INVALID_AVP_LENGTH
5xxx	5015	DIAMETER_INVALID_MESSAGE_LENGTH
5xxx	5016	DIAMETER_INVALID_AVP_BIT_COMBO
5xxx	5017	DIAMETER_NO_COMMON_SECURITY
5xxx	5030	DIAMETER_USER_UNKNOWN
5xxx	5031	DIAMETER_RATING_FAILED
5xxx	5032	DIAMETER_ERROR_BYTEME

Note:

If the congestion response code other than the above supported diameter result codes is configured, then the default response code 3004 shall be assigned, and below logs message will be logged:

Log line => Configured 1234: {} does not belongs to 3xxx, 4xxx or 5xxx series. using default response code: 3004

The following table lists the supported Experimental result code:

Table 4-61 Experimental Result Codes

Series	Code	Name	Vendor Id	Vendor Name
5xxx	5011	DIAMETER_ERROR_FEATURE_UNSUPPORTED	10415	3GPP
5xxx	5997	NO_CAPACITY	21274	Tekelec
5xxx	5453	DIAMETER_ERROR_LATE_OVERLAPPING_REQUEST	10415	3GPP
5xxx	5454	DIAMETER_ERROR_TIMED_OUT_REQUEST	10415	3GPP

4.9 Stale Binding Detection Audit, Report and Recover

While checking the validity of a binding record for a PDU Session in the backend core services, Binding service also verifies if the binding association for the PDU session exists in BSF. Existence of the binding association for the PDU session in BSF confirms the binding association being valid in BSF. If the binding association is missing in BSF, it is restored by validating the association in BSF.

Note:

This functionality requires the audit service to be enabled for Binding service. Binding service does not revalidate the binding records reaching TTL expiry within TTL with BSF.

Session Binding Revalidation with BSF

During audit, Binding service verifies the staleness of the binding records of a PDU session from Policy microservices such as SM service. If the binding is valid, it revalidates the binding associations with BSF.

Binding service validates the staleness of the session in Policy microservices. If the session is valid, it revalidates the session binding in BSF.

During revalidation, if the following parameters in the request matches with the stored binding object in BSF, BSF considers it as duplicate and does not perform any database update:

• SUPI/GPSI
• UE IP(IPV4/IPV6),
• IPDomain(if IPV4 was present for UE IP)
• dnn
• snssai
• diamHost/fqdn
• pcfId

If the parameters do not match, Binding service recreates a binding in BSF as it was originally registered, retaining all the headers and attributes with its values except for the Sender Timestamp header.

Restoring PCF Session Binding Association in BSF

During revalidation of the binding session in BSF, Binding Service sends the Binding Association Request as was sent originally, retaining all the headers and attributes with its values except for the Sender Timestamp header. To support the original headers and attributes, Binding service must retrieve the related HTTP headers from the payload object included in the stale session response from Policy microservices, and use them to populate the revalidation request header.

The successful (201) response from BSF includes a location HTTP header field that contains the URI of the created binding information. For example, "{apiRoot}/nbsf-management/v1/pcfBindings/{bindingId}" where {bindingId}" is the new binding identifier for the session. This URI is updated in contextbinding table in Policy.

Call Flow

The following diagram depicts a sample call flow for revalidating the binding information for an SM session with the following configured in Binding service:

• Audit is enabled
• Revalidate with BSF is enabled

Figure 4-41 Stale binding detection and revalidation

1. Audit Service sends an audit notification for the contextbinding records in TTL expiry.

2. Binding service sends a request with contextId to SM service to check the staleness of the PDU session.

3. If SM service responds with 404 Session Stale indicating that the PDU session is stale, Binding service sends a request to BSF Management service to deregister the binding for the stale PDU session.

4. BSF Management session deletes the biding record for the stale PDU session and responds to Binding service.

5. Binding service deletes the corresponding information in its database as well.

6. If SM service responds with 200 valid session indicating that the PDU session is still valid, Binding service sends a revalidation request with binding request object in its request body to BSF Management service. It uses the REST API: POST {apiRoot}/nbsf-management/v1/pcfBindings to send the request.

7. BSF performs a lookup in pcf_binding table to search if it is a duplicate binding request. The matching criteria is: SUPI, UE IP(IPV4/IPV6), IPDomain(if IPV4 was present for UE IP), dnn and snssai.

8. If the duplicate binding is found for the same session, indicated by matching any one of pcfId, pcfFqdn, pcfDiamHost, pcfIpEndPoints from the request, BSF returns 201 with the same binding_id, If the duplicate binding is not found, BSF creates a new binding and return 201 with session binding info in the response body.

9. Binding Service receives the response from BSF and updates the binding record only with the new binding_id. Also it updates lastAuditedTime, lastModifiedTime and reset auditAttempts for the same record.

10. Binding Service updates and stores the 3gpp-sbi-target-apiroot header in contextbinding record, if received in revalidation response from BSF in indirect communication.

Note:

Enable Binding Revalidation field under BSF Management Service in CNC Console for Binding Service must be enabled before or together with Revalidate with BSF fields under Audit section on Binding Service page in Service Configurations in CNC Console for Policy. Without enabling Enable Binding Revalidation in BSF will cause all revalidation requests to recreate a new binding association in BSF with a different binding_id.

Managing Stale Binding Detection Audit, Report and Recover

Enable

This feature can be enabled using CNC Console as well as REST API.

Enable using CNC Console

To enable this feature using CNC Console, use Enable and Revalidate with BSF fields under Audit section in Binding Service page for Service Configurations in CNC Console.

For more information, see Binding Service.

Also configure Enable Binding Revalidation field on Management Service page under Service Configurations in CNC Console for BSF.

For more information, see Management Service section in Oracle Commuications Cloud Native Core, Binding Support Function User Guide.

Enable using REST API

To enable this feature using REST API, configure the enable and revalidateEnable parameters under audit section in Binding service API: {apiRoot}/oc-cnpolicy-configuration/v1/services/binding

For more information, see Binding Service section in Oracle Communications Cloud Native Core, Converged Policy REST Specification Guide.

Also, configure enableBindingRevalidation parameter in BSF Management Service API: {apiRoot}/oc-bsf-configuration/v1/services/managementservice

For more information, see Management Service section in Oracle Communications Cloud Native Core, Binding Support Function REST Specification Guide.

Configure

This feature requires configuring Binding Service in Policy as well as BSF Management Service in BSF.

This feature can be configured using CNC Console as well as REST API.

Configure using CNC Console

To configure the Binding Service in Policy, configure the fields under Audit section along with SESSION_BINDING_REVALIDATION_MESSAGE_PRIORITY advanced settings key on Binding Service page for Service Configurations in CNC Console for Poliocy.

For more information, see Binding Service.

Also configure Enable Binding Revalidation field on Management Service page under Service Configurations in CNC Console for BSF.

For more information, see Management Service section in Oracle Commuications Cloud Native Core, Binding Support Function User Guide.

Configure using REST API

Configure the parameters under audit section in Binding Service API: {apiRoot}/oc-cnpolicy-configuration/v1/services/binding.

For more information, see Binding Service section in Oracle Communications Cloud Native Core, Converged Policy REST Specification Guide.

Also, configure the EnableBindingrevalidate parameter under Management Service API for BSF: {apiRoot}/oc-bsf-configuration/v1/services/managementservice.

For more information, see Management Service section in Oracle Communications Cloud Native Core, Binding Support Function REST Specification Guide.

Observability

Metrics

The following Binding service metrics are used to monitor this feature in Policy:

• occnp_session_binding_revalidation_request_total
• occnp_session_binding_revalidation_response_total
• ocpm_egress_response_total (existing one)

For more information, see Binding Service Metrics

The following BSF Management service metrics are used to monitor this feature in BSF:

• ocbsf_binding_revalidation_request_total
• ocbsf_binding_revalidation_response_total
• ocbsf_binding_revalidation_pcfBinding_missing_total

For more information, see BSF Management Service section under BSF Metrics in Oracle Commuications Cloud Native Core, Binding Support Function User Guide.

Alerts

The following Policy alerts are used for this feature:

• SESSION_BINDING_MISSING_FROM_BSF_EXCEEDS_CRITICAL_THRESHOLD
• SESSION_BINDING_MISSING_FROM_BSF_EXCEEDS_MAJOR_THRESHOLD
• SESSION_BINDING_MISSING_FROM_BSF_EXCEEDS_MINOR_THRESHOLD
• SESSION_BINDING_REVALIDATION_WITH_BSF_FAILURE_EXCEEDS_CRITICAL_THRESHOLD
• SESSION_BINDING_REVALIDATION_WITH_BSF_FAILURE_EXCEEDS_MAJOR_THRESHOLD
• SESSION_BINDING_REVALIDATION_WITH_BSF_FAILURE_EXCEEDS_MINOR_THRESHOLD

For more information, see Common Alerts

The following BSF alerts are used for this feature:

• BINDING_REVALIDATION_PCF_BINDING_MISSING_MINOR
• BINDING_REVALIDATION_PCF_BINDING_MISSING_MAJOR
• BINDING_REVALIDATION_PCF_BINDING_MISSING_CRITICAL

For more information, see List of Alerts in Oracle Commuications Cloud Native Core, Binding Support Function User Guide.

Logging

The following logs with a specific marker "marker":{"name":"BINDING"}, "Binding Audit:<additional log text>" are generated for this feature:

• If BSF returns 201 with new binding_id, it indicates that the missing binding was recreated in BSF. PCF updates its logs. The updated PCF logs include:
  • SUPI
  • DNN
  • S-NSSAI
  • UE-IP (IPv6/IPV4)
  • IPDomain if available
  • PCF FQDN
  • BSF Instance ID at “WARN” level
• If PCF can not reestablish BSF binding after all the session retries, PCF updates its logs. The updated logs include:
  • SUPI
  • DNN
  • S-NSSAI
  • UE-IP (IPv6/IPV4)
  • IPDomain if available
  • PCF FQDN
  • BSF Instance ID at “WARN” level
• If PCF can not reestablish BSF binding after all the reattempts of binding operation, PCF updates its logs. The updated logs include:
  • SUPI
  • DNN
  • S-NSSAI
  • UE-IP (IPv6/IPV4)
  • IPDomain if available
  • PCF FQDN
  • BSF Instance ID at “WARN” level
• If PCF internal Audit check (PDU Session revalidation on core services) of the binding association returns 404: NOT_FOUND, PCF updates its logs. The updated logs include:
  • SUPI
  • DNN
  • S-NSSAI
  • UE-IP (IPv6/IPV4)
  • IPDomain if available
  • PCF FQDN
  • BSF Instance ID at “WARN” level
• For Revalidation request, if the response from BSF indicates that the binding association is not present in BSF, BSF updates its logs with the failure for the revalidation request. The updated logs include:
  • SUPI
  • DNN
  • S-NSSAI
  • UE-IP (IPv6/IPV4)
  • IPDomain if available
  • PCF FQDN
  • error code and cause at “WARN” level
• For Revalidation request, if BSF can not re-establish or restore the BSF binding after all session retries, BSF updates its logs with the failure for the restoration request.
  • SUPI
  • DNN
  • S-NSSAI
  • UE-IP (IPv6/IPV4)
  • IPDomain if available
  • PCF FQDN
  • error code and cause at “WARN” level

4.10 Congestion Control Resource Usage Calculation Using EMA Algorithm

The Congestion Control mechanism used by different Policy services manages the flow of data traffic and prevent pod congestion. It monitors the system to detect situations that match conditions like high CPU usage or queue buffer congestion which can impact the performance under heavy loads.

The Congestion Control feature maintains two pod state, namely NORMAL or CONGESTED(DANGER OF CONGESTION, CONGESTION_L1, CONGESTION_L2, CONGESTED) state. A pod's state changes when its resource usage exceeds the predefined congestion threshold, checked at regular intervals. During uneven incoming traffic, the pods frequently switches states, leading to high volume of WARN level logs that complicates system monitoring.

The Congestion Control mechanism implements the Exponential Moving Average (EMA) algorithm for resource usage calculations, helping to smooth out rapid congestion state changes during fluctuating traffic. An EMA is a type of moving average (MA) that places a greater weight and significance on the most recent data points. It is also referred to as the Exponentially Weighted Moving Average (EWMA).

The EMA algorithm calculates the congestion resource usage by considering the resource consumption data over time, giving more weight to recent usage data, which provides a more accurate picture of current resource utilization compared to a simple average across all data points. This resource usage data is used for pod state change thus enabling smooth transition of congestion states during traffic spikes.

Figure 4-42 Sample Resource Usage Monitoring

Figure 4-43 Sample Resource Usage Monitoring using EMA

Figure 4-44 Another Sample Resource Usage Monitoring

Figure 4-45 Another Sample Resource Usage Monitoring using EMA

The user can configure the Congestion Control feature to use EMA algorithm for resource usage calculations. By default this is disabled and it can be enabled by adding the following keys to the Congestion Control Settings menu, Advance Settings section in the CNC Console:

Table 4-62 EMA Configurable Key and Value

Key	Value	Description
CPU_CONGESTION_RESOURCE_CALC_ALGORITHM	EMA	This enables the congestion control CPU resource calculation to use the algorithm provided.
CPU_CONGESTION_RESOURCE_CALC_INTERVAL_MS	50ms	This configuration sets the time interval in milliseconds for CPU congestion resource to be calculated by the configured algorithm.
QUEUE_CONGESTION_RESOURCE_CALC_ALGORITHM	EMA	This enables the congestion control Queue resource calculation to use the algorithm provided.
QUEUE_CONGESTION_RESOURCE_CALC_INTERVAL_MS	70ms	This configuration sets the time interval in milliseconds for Queue congestion resource to be calculated by the configured algorithm.

Configure the percentage ratio to consider for current congestion resource usage data point and previous congestion resource usage data point by adding following Advanced setting keys to the Congestion Control Settings menu, Advance Settings section in the CNC Console:

Table 4-63 Configure percentage ratio

Key	Value	Description
EMA_CPU_CONGESTION_RESOURCE_CALC_RATIO	70:30	This configuration will be used to set the EMA ratio in which congestion resource(s) calculated using EMA algorithm to be considered for calculation.
EMA_QUEUE_CONGESTION_RESOURCE_CALC_RATIO	70:30	This configuration will be used to set the EMA ratio in which congestion resource(s) calculated using EMA algorithm to be considered for calculation.

For more information about Congestion Control EMA configurations, see Settings section in CNC Console.

Managing Congestion Control Resource Usage Using EMA Algorithm

Enable

By default, this feature is disabled for all Policy services that support Congestion Control feature. You can enable this feature using CNC Console or REST API for Policy.

Configure Using CNC Console

To enable this feature using CNC Console for Policy services that uses Congestion Control, add the CPU_CONGESTION_RESOURCE_CALC_ALGORITHM and QUEUE_CONGESTION_RESOURCE_CALC_ALGORITHM advanced keys in the Settings page under Congestion Control for Overload and Congestion Control Configurations.

For more information, see Congestion Control Settings section.

Configure Using REST API

Perform the feature configurations as described in "Congestion Control" section in Oracle Communications Cloud Native Core, Converged Policy REST Specification Guide.

4.11 Message Feed for SBI Monitoring

In order to enable correlation of the internal and external (request/response) messages for all the transactions initiated by the producer and consumer NFs, Policy supports copying the messages at Ingress and Egress Gateways.

This feature allows NFs using Ingress and Egress Gateways to report every incoming and outgoing message to Oracle Communications Network Analytics Data Director (OCNADD) monitoring system.

That is, OCNADD is a message store to keep a copy of each request and response processed through Ingress and Egress Gateways.

The insights on these messages enable NFs to integrate with external 5G SBI monitoring system for:

• Call Tracing / Tracking
• Live debugging

Architecture

Figure 4-46 Policy Message Feed Architeture

OCNADD is a Network Data Broker part of the Network Analytics suite of products. OCNADD receives network data traffic information from various sources such as 5G NFs and Non-5G Nodes and sends the data securely to subscribed consumer (3rd Party tools) after applying its powerful and configurable filtering, replication, and aggregation rule corresponding to subscribed consumers. For more information on OCNADD, see Oracle Communications Network Analytics Data Director User Guide.

5G NF Kafka Producer is used as the source to send the data stream towards OCNADD. The 5G NFs use integrated Kafka producer services to stream the 5G South Bound Interface (SBI) messages along with metadata added by NFs to OCNADD.

Managing Message Feed for SBI Monitoring

Enable

Message feed feature can be enabled using Helm parameters either at the time of Policy installation or during the software upgrade.

ingress-gateway.message-copy.enabled parameter is used to enable copying messages passing through Ingress Gateway.

egress-gateway.message-copy.enabled parameter is used to enable copying messages passing through Egress Gateway.

For more information, see Configuring Ingress Gateway, Configuring Egress Gateway, and Configuring Kafka for NF Message Feed sections in Oracle Communications Cloud Native Core, Converged Policy, Upgrade, and Fault Recovery Guide.

Configure

Message feed feature can be configured using Helm parameters either at the time of Policy installation or during the software upgrade.

For more information, see Configuring Ingress Gateway, Configuring Egress Gateway, and Configuring Kafka for NF Message Feed sections in Oracle Communications Cloud Native Core, Converged Policy, Upgrade, and Fault Recovery Guide.

SASL_SSL Configuration for Policy Message Copy

As there is no certificate-based client authentication required, a trustStore is created at Policy.

Policy contains placeholders to accept caroot certificates, which are then translated into trustStore using Gateway init-containers.

Policy uses native SSL functionality provided by Gateway services. SSL service block gets activated or used, when enableIncomingHttps is set to true. The same configuration is used for message copy SSL configuration too.

To configure only Policy-DD SSL communication without native SSL functionality, configure caBundle and trustStorePassword sections with appropriate secret configurations.

To use both native SSL functionality and Policy-DD SSL communication, add the caRoot certificate of Kafka broker to the existing caRoot certificate by appending Kafka broker ca certificate after the existing certificate.

1. Generate SSL certificates.

   Note:

   Creation process for private keys, certificates and passwords is based on discretion of user or operator.
2. Before copying the certificates to the secret, add the DD Root certificates contents into the CA certificate(caroot.cer) generated for NRF.

   Note:

   Make sure to add 8 hyphens "-" between 2 certificates.

   -----BEGIN CERTIFICATE-----
   <existing caroot-certificate content>
   -----END CERTIFICATE-----
   --------
   -----BEGIN CERTIFICATE-----
   <DD caroot-certificate content>
   -----END CERTIFICATE-----

3. Create a secret for authentication with DD.

   To create a secret store the password in a text file and use the same file to create a new secret.

   kubectl create secret generic ocingress-secret --from-file=ssl_ecdsa_private_key.pem --from-file=rsa_private_key_pkcs1.pem --from-file=ssl_truststore.txt --from-file=ssl_keystore.txt --from-file=caroot.cer --from-file=ssl_rsa_certificate.crt --from-file=ssl_ecdsa_certificate.crt --from-file=sasl.txt -n <namespace>
   
   kubectl create secret generic ocegress-secret --from-file=ssl_ecdsa_private_key.pem --from-file=ssl_rsa_private_key.pem --from-file=ssl_truststore.txt --from-file=ssl_keystore.txt --from-file=ssl_cabundle.crt --from-file=ssl_rsa_certificate.crt --from-file=ssl_ecdsa_certificate.crt --from-file=sasl.txt -n <namespace>

4. Provide appropriate values for the SSL section.

   SSL configuration:

   service:
     ssl:
        
       privateKey:
         k8SecretName: ocegress-secret
         k8NameSpace: pcf
         rsa:
           fileName: rsa_private_key_pkcs1.pem
         ecdsa:
           fileName: ssl_ecdsa_private_key.pem
    
       certificate:
         k8SecretName: ocegress-secret
         k8NameSpace: pcf
         rsa:
           fileName: tmp.cer
         ecdsa:
           fileName: ssl_ecdsa_certificate.crt
    
       caBundle:
         k8SecretName: ocegress-secret
         k8NameSpace: pcf
         fileName: caroot.cer
    
       keyStorePassword:
         k8SecretName: ocegress-secret
         k8NameSpace: pcf
         fileName: key.txt
    
       trustStorePassword:
         k8SecretName: ocegress-secret
         k8NameSpace: pcf
         fileName: trust.txt
    
       initialAlgorithm: RS256

5. Configure the message copy feature.

   messageCopy:
     enabled: true
     copyPayload: true
     topicName: PCF
     ackRequired: false
     retryOnFailure: 0
     security:
       enabled: true
       protocol: SASL_SSL
       tlsVersion: TLSv1.2
       saslConfiguration:
        userName: ocnadd
        password:
          k8SecretName: ocegress-secret
          k8NameSpace: pcf
          fileName: sasl.txt

6. Make sure to configure the correct SASL_SSL port in kafka.bootstrapAddress attribute. To get the correct value of this, refer to DD Kafka's Values.yaml file.

Observability

Metrics

The following metrics are used to count the ingress and egress messages at the gateways:

• oc_ingressgateway_msgcopy_requests_total
• oc_ingressgateway_msgcopy_responses_total
• oc_egressgateway_msgcopy_requests_total
• oc_egressgateway_msgcopy_responses_total

For more information, see:

• Ingress Gateway Metrics
• Egress Gateway Metrics

Alerts

The following alerts are raised when OCNADD is not reachable:

• INGRESS_GATEWAY_DD_UNREACHABLE_MAJOR
• EGRESS_GATEWAY_DD_UNREACHABLE_MAJOR

For more information, see

• INGRESS_GATEWAY_DD_UNREACHABLE_MAJOR
• EGRESS_GATEWAY_DD_UNREACHABLE_MAJOR

4.12 Support for Dual Stack

Using the dual stack mechanism, applications or NFs can establish connections with pods and services in a Kubernetes cluster using either IPv4, IPv6, or both, depending on the configured deployment mode. Dual stack provides:

• Coexistence strategy that allows hosts to reach IPv4 and IPv6.
• IP address allocation to the Kubernetes clusters during cluster creation. This allocation is applicable for all Kubernetes resources unless explicitly specified during cluster creation.

Note:

• The dual stack feature is not supported on Oracle Cloud Native Environment (CNE) but is supported on third-party CNEs.
• Operator needs to redeploy (Fresh install) the Policy to enable IP Dual Stack functionality.

Note:

The dual stack feature is not supported on Oracle Cloud Native Environment (CNE) but is supported on third-party CNEs.

Note:

Externally communicating services of type LoadBalancer such as Ingress Gateway and Diameter Gateway supports dual stack with IPv6 preference on dual stack IPv4 preferred infrastructure. Internally communicating services such as DBTier, CM, and so on, uses single stack IPv6 for communication on dual stack IPv4 preferred infrastructure.

Note:

Communication between services and CoreDNS, as well as the Kubernetes API, depends on the cluster's network preference.

IP Address Allocation to Pods

IP address allocation to pods depends on the IP address preference set in the Kubernetes cluster. Pods do not have the privilege to choose an IP address. Consider the following example of a pod deployed in an IPv4 preferred infrastructure. Here, if the Kubernetes cluster has IPv4 preferred configuration, both IPv4 and IPv6 are allocated to the pod, but the primary IP address is IPv4. Example:

IP:               10.xxx.xxx.xxx
IPs:
  IP:           10.xxx.xxx.xxx
  IP:           fd00::1:cxxx:bxxx:8xxx:xxxx

IP Address Allocation to Services

IP address allocation to all the Policy services, depends on theDeploymentMode Helm parameter configuration. This Helm parameter automatically configures IP Family Policy and IP Families attributes for the Policy services. For more information about DeploymentMode, see the "Customising Policy" section in the Oracle Communications Cloud Native Core, Converged Policy Installation, Upgrade, and Fault Recovery Guide.

You can customize the IP address allocation to services based on the DeploymentMode Helm parameter. Services route the traffic to the destination endpoints based on this configuration. If theDeploymentMode Helm parameter is set to IPv4, then IPv4 is allocated to services, and services use IPv4 pod IPs to send the traffic to endpoints.

The following table describes how IP address allocation, IP Family Policy, and IP Families vary based on the DeploymentMode Helm parameter configuration for services:

Table 4-64 IP Address Allocation

Infrastructure Preference	Application Preference (DeploymentMode Helm Parameter)	IP Family Policy Attribute	IP Families Attribute	Pod IP	Service IP	Endpoints
IPv4 Preferred	IPv4	SingleStack	IPv4	IPv4,IPv6	IPv4	IPv4
IPv6 Preferred	IPv4	SingleStack	IPv4	IPv6,IPv4	IPv4	IPv4
IPv4 Preferred	IPv6	SingleStack	IPv6	IPv4,IPv6	IPv6	IPv6
IPv6 Preferred	IPv6	SingleStack	IPv6	IPv6,IPv4	IPv6	IPv6
IPv4 Preferred	IPv4_IPv6 (IPv4Preferred)	RequireDualStack	IPv4 Preferred	IPv4,IPv6	IPv4,IPv6	IPv4
IPv6 Preferred	IPv4_IPv6 (IPv4Preferred)	RequireDualStack	IPv4 Preferred	IPv6,IPv4	IPv6,IPv4	IPv4
IPv4 Preferred	IPv6_IPv4 (IPv6Preferred)	RequireDualStack	IPv6 Preferred	IPv4,IPv6	IPv4,IPv6	IPv6
IPv6 Preferred	IPv6_IPv4 (IPv6Preferred)	RequireDualStack	IPv6 Preferred	IPv6,IPv4	IPv6,IPv4	IPv6

Note:

In 25.1.0 release, dual stack is not supported for the Egress traffic on LDAP, PER, and Notification service.

Enable

Dual Stack support can be enabled by setting the global.deploymentMode parameter to IPv4_IPv6 or IPv6_IPv4 depending on the preference needed. For more information, see the Oracle Communications Cloud Native Core, Converged Policy Installation, Upgrade, and Fault Recovery Guide.

Configure

You can configure dual stack using the following parameters:

• global.deploymentMode
• global.egressRoutingMode
• global.isIpvSixSetup
• diam-gateway. envSupportedIpAddressType
• diameter-gateway.dualStackPreferredDnsResolutionIpAddressType

For more information on these parameters, see "Configuration Parameters for Dual Stack" section in the Oracle Communications Cloud Native Core, Converged Policy Installation, Upgrade, and Fault Recovery Guide.

Observe

There are no Metrics, KPIs, or Alerts available for this feature.

4.13 Handling of Multiple N1N2Transfer Messages

PCF processes the requests received from the external NFs to initiate the policy evaluation and then triggers the N1N2Transfer to UE. Following is the list of triggers for the policy evaluation:

• UE Policy Data updateNotifications received from UDR
• Asynchronous CHF response to Subscription
• Notifications received from CHF
• UE Policy Update from AMF
• N1N2Notifications failure from AMF
• N1 Message Notify from AMF carrying the UE message of N1 Message Reject or N1 Message complete

The triggers may arrive to PCF when last N1N2 transfer is still in progress. After processing and evaluating the triggers, the policy evaluation results (Install UPSI, Remove UPSI, or UPSIs that needs to be transferred to UE) are sequenced. If PCF receives more than one trigger while the previous N1N12 transfer is in progress and this feature is enabled, then it consolidates and stores the UPSIs with URSP rules that needs to be transferred to UE. Once the UE notification is received for the in-progress N1N2 transfer, final consolidation is performed and consolidated UE policy actions are sent out to UE in a single (assuming no fragmentation is required) N1N2 transfer.

Whenever consolidation will be performed for UE policy action, next N1N2 transfer carrying consolidated UE policy action will have an updated Procedure Transaction Identity (PTI).

Users can optimize the install action using the UE.POLICY.INSTALLATION.OPTIMIZATION.ENABLED key in the Advanced Settings of UE service. Here, install action can be optimized by not installing the subscriber session if particular UPSI or URSP specific to PLMN is installed by PCF in current subscriber session. Policy supports the following scenarios:

Scenario 1:

• During Create, Install [UPSI-1 and UPSI-2] received as UE policy action and N1 message Notify successfully received with command complete.
• During Update from AMF, Policy Action is Install [UPSI-2 and UPSI-3].

Case 1: Install Optimization is enabled

Next N1N2 transfer - Install [UPSI-3]. Here, there is no action for UPSI-2 as it is already successfully installed so will not be installed. Install optimization of Policy transfers for UPSI-2 is performed here.

Case 2: Install Optimization is disabled (Default)

Next N1N2 transfer - Install [UPSI-2 and UPSI-3]

Scenario 2:

• During Create, Install [UPSI-1 and UPSI-2] received as UE policy action and N1N2 transfer is sent out and is in progress.
• During Update from AMF, Policy Action is Install [UPSI-2 and UPSI-3] as last N1N2 transfer is still in progress. So, the current policy evaluation will be sequenced.
• N1 message notify received with command Reject for UPSI-1. Policy evaluation result on N1 notify reject is retransmit UPSI-1.
• Consolidation will be performed for sequenced policy evaluation with current policy decision. Consolidated UE policy action: Install [UPSI-1, UPSI-2, UPSI-3].

Case 1: Install Optimization is enabled

Next N1N2 transfer - Install UPSI-1 and UPSI-3 Here, there is no action for UPSI-2 as it is already successfully installed so it will not be installed. Install optimization of Policy transfers for UPSI-2 is performed here.

Case 2: Install Optimization is disabled (Default)

Next N1N2 transfer - Install [UPSI-1, UPSI-2, and UPSI-3]

Managing the Feature

Enable

This feature can be enabled by setting the Enable Consolidation of UE Policy Decisions attribute to true.

The consolidation for Re-transmissions on T 3501 can be enabled by setting the Enable Consolidation of UE Policy Decisions for Re-transmission on T3501 Expiration to true. It is applicable only if the Enable Consolidation of UE Policy Decisions feature is enabled.

Bulwark must be enabled to ensure exclusive locking for UE policy processing in the Handling of Multiple N1N2Transfer Messages feature. User can set the following advanced setting keys for bulwark in CNC Console:

• CONCURRENCY.N15.UE_NOTIFICATION.LOCK_REQUEST_RETRY_COUNT
• CONCURRENCY.N15.UE_NOTIFICATION.LOCK_REQUEST_RETRY_BACKOFF
• CONCURRENCY.N15.UE_NOTIFICATION.LOCK_LEASE_DURATION
• CONCURRENCY.N15.UE_NOTIFICATION.LOCK_WAIT_DURATION
• CONCURRENCY.N15.UE_NOTIFICATION.ENABLED

For more information, see PCF UE Policy Service.

Configure

Optimization for Install Action: To optimize the install action UE.POLICY.INSTALLATION.OPTIMIZATION.ENABLED key must be set to true in the Advanced Settings of PCF UE Policy configurations. It is disabled by default.

For more information, see PCF UE Policy Service.

The following Policy blocks have been added to UE for policy blocks execution:

• Pending/In transfer
• Discard/Discard All

The Operation type Policy block has been updated with T3501 Expiry option.

For more information, see "PCF UE Policy" section in Oracle Communications Cloud Native Core, Converged Policy Design Guide.

Observability

The following metrics are used for this feature:

• ue_n1_policy_sequencing
• ue_n1_policy_consolidation

For more information, see UE Service Metrics.

The following alerts are used for this feature:

• UE_N1N2_NOTIFY_REJECTION_RATE_ABOVE_MINOR_THRESHOLD
• UE_N1N2_NOTIFY_REJECTION_RATE_ABOVE_MAJOR_THRESHOLD
• UE_N1N2_NOTIFY_REJECTION_RATE_ABOVE_CRITICAL_THRESHOLD
• UE_N1N2_TRANSFER_FAILURE_RATE_ABOVE_MINOR_THRESHOLD
• UE_N1N2_TRANSFER_FAILURE_RATE_ABOVE_MAJOR_THRESHOLD
• UE_N1N2_TRANSFER_FAILURE_RATE_ABOVE_CRITICAL_THRESHOLD
• UE_N1N2_TRANSFER_T3501_TIMER_EXPIRY_RATE_ABOVE_MINOR_THRESHOLD
• UE_N1N2_TRANSFER_T3501_TIMER_EXPIRY_RATE_ABOVE_MAJOR_THRESHOLD
• UE_N1N2_TRANSFER_T3501_TIMER_EXPIRY_RATE_ABOVE_CRITICAL_THRESHOLD

For more information, see PCF Alerts.

4.14 PCF support to not send ASR while Notify-Update fails

Policy Control Function (PCF) receives AAR-I and sends AAA success response immediately, if (Protocol Data Unit) PDU Session is successfully retrieved and mapped. The Notify-Update request is sent asynchronously for the established Rx session. In case, there are some issues at PCF such as network issues, SMF is overloaded, PCF can not send Notify-Update to SMF, or Notify-Update to SMF fails, then PCF triggers an Abort Session Request (ASR) to Application Function (AF) to terminate the voice call.

This feature enables PCF to Notify-Terminate the Policy Authorization/Rx session which does not contain any media type configured by user when PCF is not able to successfully update the required PCC and session rules to SMF for the Rx session of a PDU session. This lets the voice data packets or any other media type configured by user to be carried over default IMS QOS flow.

Managing the Feature

Enable

By default, this feature is disabled. The operator can enable this feature through the CNC Console configurations.

Configure using CNC Console

You can configure the feature by:

1. Adding new configurations for "Rx ReAuth Profile" in Common Data under Service Configurations in the CNC Console.

   For more information, see Rx Reauth Profiles.

2. Selecting the new "Rx ReAuth Profile" in PCF Session Management under Service Configurations in the CNC Console.

   For more information, see PCF Session Management.

Observability

The metric occnp_suppress_notify_total has been added to measure the number of ASR not send, ASR sent, and RAR sent when the feature is enabled.

For more information, see SM Service Metrics.

The following alerts are used for this feature:

• UPDATE_NOTIFY_FAILURE_ABOVE_30_PERCENT
• UPDATE_NOTIFY_FAILURE_ABOVE_50_PERCENT
• UPDATE_NOTIFY_FAILURE_ABOVE_70_PERCENT

For more information, see List of Alerts.

4.15 LDAP Timeout and Retry Mechanism

The existing LDAP request timeout can be configured through Helm. To make this run time configurable, the operator must configure Timeout value in milliseconds while creating or editing the LDAP datasource.

With this feature, Policy supports retry functionality towards external LDAP server. The operator must first enable the Retry Enabled flag to use this functionality. Then, the operator can configure the Max number of retries and Retries on errors/timeout to configure the multiple error codes including the error code for LDAP timeout (85).

Note:

There is no classification about permanent or temporary error for LDAP failure response. Hence, all the failure responses come under the error category. The timeout is observed as error code 85 (timeout) and connection related error is observed as error code 91 (connectError) by the ldap-gw applications. In the case of timeout/connection retry, operator has to set corresponding value in the retry error code list in CNC Console.

When retry condition hits the LDAP, the request is retried or reattempted to the next available LDAP server configured in LDAP datasource. The LDAP request retry happens based on next available (connected) server and not based on read connection setup for the server.

Note:

The retries are immediate retry and there is no backoff timer or delayed retry. The retry related to connection is automatically selected as per Data Source configurations, no specific error code configuration is required for such case.

In case multiple servers are configured, the retries would happen as mentioned in the following table:

Table 4-65 LDAP Retry for Multiple Configured Servers

Servers Available	Initial Request	First Retry
Primary, Secondary, Teritiary	Primary	Secondary
Primary, Secondary,	Primary	Secondary
Primary, Teritiary	Primary	Teritiary
Secondary, Teritiary	Secondary	Teritiary
Primary	Primary	Primary
Secondary	Secondary	Secondary
Teritiary	Teritiary	Teritiary

Managing the Feature

Enable

By default, this feature is disabled. The operator can enable this feature through the CNC Console configurations.

Configure Using CNC Console

You can enable the LDAP Retry functionality by using the Retry Enabled toggle button.

For more information, see Data Sources.

Configure Using Helm

The following parameters must be used to establish the connection with the LDAP servers configured after reading the datasource configuration:

• LDAP_CONNECTION_CONNECT_ALL_SERVERS
• LDAP_CONNECTION_DATASOURCE_RETRY_COUNT

For more information, see "LDAP Configurations" section in Oracle Communications Cloud Native Core, Converged Policy Installation, Upgrade, and Fault Recovery Guide.

Observability

The following metrics are used to count the number of LDAP search requests and responses at the LDAP Gateway:

• occnp_ldap_search_request_total
• occnp_ldap_search_response_total

For more information, see LDAP Gateway.

4.16 Logging Support for Error Response

Error handling framework was introduced in earlier release of Policy as a general purpose error handling tool. This feature used the error handling framework to add more details to the error using 3GPP error response format.

Policy sends error responses to consumer NFs due to some exceptions, such as signaling, validations, and internal errors. These error responses have payloads containing the problem title, status, details, and cause of the error that are used to investigate the error. Policy has been enhanced to support logs for the error responses. Policy support the following services for this feature:

• SM Service
• AM Service
• UE Service
• PDS Service
• User Service
• Binding Service
• PRE Service

From 25.1.200, this feature has been enhanced to support logging for error responses during SM call flows at their default log level. It provides sufficient visibility into issues within or across the external facing interfaces such as SM, UDR Connector, CHF Connector, and Binding service. The current default log level for PCF microservices is WARN.

When sending any error response triggered by an HTTP Request, this error response format will be mapped into the following general log format:

PCF as a Producer

{
  “errorStatus”: “Value”, (problem details error status)
  “errorTitle”: “Value”, (problem details error title)
  “errorDetails”: “Value”, (problem details error data)
  “errorCause”: “Value”  (problem details error cause)
  “sender”: “Value”, (nfType-instanceId)
  “subscriberId”: “Value” (UE ID associated with event if present)
  “method”: “Value”,  
  “URI”: “Value”,
  “associationId”: “Value”,
}

Note:

associationId is only applicable for SM call flows.

PCF as a Consumer

{
  “errorStatus”: “Value”, (problem details error status)
  “errorTitle”: “Value”, (problem details error title)
  “errorDetails”: “Value”, (problem details error data)
  “errorCause”: “Value”  (problem details error cause)
  “sender”: “Value”, (nfType-instanceId)
  “receiver“: “Value" (nfType-instanceId)
  “subscriberId”: “Value” (UE ID associated with event if present)
  “method”: “Value”,  
  “URI”: “Value”,
  “associationId”: “Value”,
}

Note:

associationId is only applicable for SM call flows.

Table 4-66 General Log Format

Parameter	Description	Example
errorStatus	Specifies the status code of the error.	404, 500, etc.
errorTitle	Specifies the title of the error.	Subscription not found
errorDetails	Specifies the error detail produced by error handling framework in case of PCF as producer. Note: For errorDetails field to be populated in the required format, error handling framework should be enabled in CNC Console for the required service.	ocpcf.oracle.com:UDRC:SC:USER NOT FOUND.EI-01-404-01-01-03.USER_NOT_FOUND:EC-OCPCF-UDRC-EI-01-01-404-00008-01-03
errorCause	Specifies the cause of the error.	SUBSCRIPTION_NOT_FOUND
sender	Specifies the sender which is composed by the nfType plus the instanceId. Note: In case of PCF as producer of error, the sender field will be PCF plus the instanceId of the PCF. In case of PCF as consumer of error, the sender field will be the external NF plus the instanceId of the external NF.	PCF-0adae7a4-ffcd-41ec-aff0-b734789f4477
reciever	Specifies the reciever which is composed by the nfType plus the instanceId. Note: Receiver field will only be present when logging error as a consumer. PCF will get the instanceId of the responding NF from the server header present in the response. In case the server header is not present it will be logged as null (example: UDR-null).	UDR-0adae7a4-ffcd-41ec-aff0-b734789f4477
subscriberId	Specifies the subscriberId which can be SUPI, GPSI, or PEI. It is used per the availabablity. In case all the subscriberIds are available, following will be the priority order: SUPI GPSI PEI	imsi-65008100001061
method		POST, DELETE, GET
URI		HTTP address
associationId

Managing Enhancements to Logging Support for Error Response

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

Enable

By default, this feature is disabled. The operator can enable this feature through the CNC Console configurations.

Configure

You can configure logging support for error response using the Enable Enhanced Logging and Enable UE Identifier Information toggle buttons. These toggle buttons are availabe in General Settings under General Configurations on CNC Console for Policy. For information about how to configure for Policy Management Service in CNC Console, see General Settings.

Observe

There are no new metrics in Policy for this feature.

4.17 Concurrency Handling at Bulwark Service to Reduce Processing Latency of Service

Policy supports the Bulwark service to handle the concurrent requests coming from other Policy services. Bulwark Service provides lock and unlock mechanism over a key (such as SUPI or GPSI) and allows only one notification at a time to proceed. For more information on handling concurrent requests, see Support for Concurrency Handling using Bulwark Service in Policy

Concurrency handling of different service requests for the same key at SM service or PDS (Policy microservices) has high latency in acquiring lock from Bulwark service, on reattempt, if lock was not acquired in the first attempt.

That is, when SM service or PDS sends a lock acquision request to Bulwark service and Bulwark service fails to acquire the lock within the lockWaitTimeout timer, SM service or PDS will have to wait until the CONCURRENCY.LOCK_REQUEST_RETRY_BACKOFF expires to resend a lock acquision request to Bulwark service again.

Note:

CONCURRENCY.LOCK_REQUEST_RETRY_BACKOFF is an advanced settings key defined at SM service or PDS that indicates the amount of time after which the SM service or PDS can retry to gain the lock, incase the lock acquisition request fails.

SM service or PDS can fail to acquire the lock due to the following reasons:

• Fail to deliver lock request (for reasons due to transport issues, sidecar congestion, or bulwark pods restart).
• Lock is already acquired/busy.

SM service or PDS reattempts to acquire lock after CONCURRENCY.LOCK_REQUEST_RETRY_BACKOFF timer expires. SM service or PDS is not aware if the lock is available or if the lock that is released during this time and is available can be gained within the CONCURRENCY.LOCK_REQUEST_RETRY_BACKOFF timer expiry duration. This adds to the latency of processing concurrent requests.

Note:

Currently, this feature is implemented only for SM service and PDS.

Policy reduces the latency in processing different concurrent service requests at SM service or PDS (Policy microservices) by acquiring the lock for the service request when available earlier than the CONCURRENCY.LOCK_REQUEST_RETRY_BACKOFF timer, instead of waiting for CONCURRENCY.LOCK_REQUEST_RETRY_BACKOFF timer to expire, if lock acquisition had failed previously.

Latency caused by CONCURRENCY.LOCK_REQUEST_RETRY_BACKOFF timer is addressed by using Long polling mechanism.

With this mechanism, SM service or PDS request lock from Bulwark service and wait for lockWaitTimeout or RequestTimeout period, for Bulwark service to respond. If Bulwark service is able to acquire a lock, it responds with acquired lock.

If Bulwark service cannot acquire lock, it uses the Long polling functionality to retry to acquire the lock for the given key (SUPI/GPSI). It starts polling to know when the exiting lock is released. For this purpose, Bulwark service creates a polling task and starts polling to know when the existing lock is released. Whenever an existing lock is released, it tries to acquire the lock for the same key.

If the lock acquisition is successful, it informs SM service or PDS with the acquired lock information, if lockWaitTimeout has not expired.

If the acquire lock request fails again, Bulwark service creates a new polling task and retries to acquire the lock within the lockWaitTimeout period. If lockWaitTimeout is expired, SM service or PDS will request after CONCURRENCY.LOCK_REQUEST_RETRY_BACKOFF timer again and the same steps to acquire a lock will be followed until maximum number of lock attempts is reached. Bulwark service then sends a failure notice to SM service or PDS .

The maximum number of lock requests to be allowed can be configured using Maximum Pending Lock Requests allowed per Key field under Server Retry on-Already Locked Keys section on Bulwark Settings page in CNC Console.

This feature can be enabled/disabled at SM service and/or PDS as well as at Bulwark service.

This feature can be enabled/disabled at SM service by configuring CONCURRENCY.LOCK_RETRY_MODE advance settings key on Session Management service page under Service Configurations section in CNC Console.

This feature can be enabled/disabled at PDS by configuring CONCURRENCY.LOCK_RETRY_MODE advance settings key on PDS Settings page under Service Configurations section in CNC Console.

This feature can be enabled and configured at Bulwark service using the fields under Server Retry On Already Locked Keys section on Bulwark Settings page in CNC Console.

If the feature is enabled at SM service and/or PDS, SM service and/or PDS should send the request initiation timestamp (oc-origination-request-timestamp) as header. Otherwise, the retry mechanism is not enabled for that request.

The time interval between which Bulwark service can poll to know if an existing lock is released can be configured using polling.interval Helm parameter.

The maximum number of times Bulwark service can retry to attempt the lock can be configured using polling.maxLockAttempts Helm parameter.

Note:

Bulwark service supports Long polling functionality for both single and multi keys.

Call Flow

Figure 4-47 If lock is not available. Register for Long polling mechanism with the configured polling interval (20ms) and max lock re-attempts (5)

1. In case of multiple Create, Update, Delete, Notify, Update Notify requests for the same subscriber, SM service or PDS request a lock for the SUPI or GPSI value from the Bulwark service.
2. Bulwark service processes the lock request and fetches the identifier for which the lock is required.
3. Bulwark service tries to gain a lock from its cache. If there is no existing lock held by the given identifier, Bulwark service acquires a lock with the specified timeout value and a unique identifier (UUID) for the acquired lock.
4. Bulwark service responds to SM service or PDS (lock requesting service) with the lock details.
5. If Bulwark service fails to acquire the lock, it creates a new polling task and retries to acquire the lock within the lockWaitTimeout period.
6. If lockWaitTimeout has expired, Bulwark service sends a 423 lock failure response to SM service or PDS which is requesting the lock.
7. If lockWaitTimeout has not yet expired, Bulwark service creates a polling task with the default configuration (polling.interval=20ms and polling.maxLockAttempts=5).
8. After every 20ms, Bulwark service checks if an existing lock is released and reattempts to acquire the lock.
9. If the acquire lock request fails, Bulwark service continues to check every 20ms to know the availability of a lock and reattempts to acquire the lock until the maximum number of reattempts (polling.maxLockAttempts) reaches 5.
10. If Bulwark service acuires the lock during the reattempt, Bulwark service responds to SM service or PDS with the lock details.
11. If the maximum number of reattempts (polling.maxLockAttempts) reaches 5 and Bulwark service fails to acquire the lock, Bulwark service sends a 423 lock failure response to SM service or PDS which is requesting the lock.

Note:

If feature is enabled at Bulwark service, if the lockWaitTimeOut is non-zero, and oc-origination-request-timestamp is present in the header, polling mechanism at Bulwark service will be enabled for that request.

SM service or PDS must send the request initiation timestamp (oc-origination-request-timestamp) as header. Otherwise, retry mechanism can not be enabled for that request.

Inoder to add the oc-origination-request-timestamp to the hearder in the lock request from SM service or PDS service to Bulwark service, the LOCK_RETRY_MODE must be either SERVER_ONLY or CLIENT_AND_SERVER.

Managing Notifications from Bulwark Service to the Service Requestor When Lock is Released

Enable

This feature can be enabled/disabled either at SM service and/or PDS as well as Bulwark service.

This feature can be enabled/disabled at SM service by configuring CONCURRENCY.LOCK_RETRY_MODE advance settings key on Session Management service page under Service Configurations section in CNC Console.

This feature can be enabled/disabled at PDS by configuring CONCURRENCY.LOCK_RETRY_MODE advance settings key on PDS Settings page under Service Configurations section in CNC Console.

This feature can be enabled and configured at Bulwark service using the fields under Server Retry On Already Locked Keys section in Bulwark Settings page in CNC Console.

For more information, see Bulwark Settings

Configure

This feature can be configured using Helm parameters, CNC Console, and REST API.

To configure the polling functionality by Bulwark service using Helm parameters, configure polling.interval and polling.maxLockAttempts parameters.

To configure using CNC Console:

• Configure the fields under Server Retry on-Already Locked Keys section on Bulwark Settings page in CNC Console.

  For more information, see Bulwark Settings.

• To indicate whether the lock retry must be triggered under which service, configure the CONCURRENCY.LOCK_RETRY_MODE advanced settings key available under PCF Session Management and PDS pages in CNC Console.
  For more information, see:

  • PCF Session Management
  • PDS Settings

To configure using REST API, configure the parameters in the following APIs:

• Acquire Lock
• Release Lock
• Server Retry on already locked keys

For more information, see Oracle Communications Cloud Native Core, Converged Policy REST API Guide.

Observability

Metrics

The following metrics are used for this feature:

• lock_request_total
• lock_response_total
• lock_collision_total

For more information, see Bulwark Metrics.

Alerts

The following alerts are used for this feature:

• LOCK_ACQUISITION_EXCEEDS_MINOR_THRESHOLD
• LOCK_ACQUISITION_EXCEEDS_MAJOR_THRESHOLD
• LOCK_ACQUISITION_EXCEEDS_CRITICAL_THRESHOLD

For more information, see List of Alerts.

4.18 Support for Stale Requests Cleanup

Policy supports minimizing the processing of stale requests and stale responses by any of the Policy microservices.

The header part of every request that a microservice such as PCRF Core, SM service, or UE Policy service receives includes the timestamp of the request and the maximum timeframe to receive the request.

If the time taken for a request to be received by the microservice is more than the maximum timeframe specified in the header, then that request is considered as stale.

Similarly, if the time taken by the microservice to process the received request and send its response back to the requester such as Diameter Gateway or Ingress Gateway is more than the timeframe specified, such a response is considered as stale response.

The Policy microservice stops further processing of such stale requests and responses and sends a 504 error to the requested NF.

The following sections describe how the stale requests and responses are detected and cleaned at each of the Policy microservices.

Note:

Currently, the stale request cleanup functionality is implemented for SM service, PCRF Core, Binding service, Diameter Connector, UDR Connector, UE Policy Service, and CHF Connector.

Stale Requests Cleanup for PCRF Core

A request from Diameter Gateway, PDS, PRE, or Usage Monitoring to PCRF Core is considered as stale when the request takes longer time than the configured time period to reach PCRF Core.

Also, a response from PCRF Core to Diameter Gateway, PDS, PRE, or Usage Monitoring is considered as stale, when PCRF Core takes a longer time than the configured time period to process a request and respond to any of these microservices.

Stale requests or responses by PCRF Core are detected using Attribute Value Pairs (AVPs) for Diameter requests, and using 3GPP headers for HTTP requests.

The following 3GPP headers are included in every request that comes to, or is sent by PCRF Core:

Table 4-67 3GPP Headers in HTTP Requests

Header	Definition
3gpp-Sbi-Origination-Timestamp	The header contains the date and time (with a millisecond granularity) when the originating entity initiated the request.
3gpp-Sbi-Max-Rsp-Time	This header may be used in a HTTP request to indicate the duration in milliseconds during which the HTTP client waits for a response.
3gpp-Sbi-Sender-Timestamp	The header contains the date and time (with a millisecond granularity) at which an HTTP request or response is originated.

If there are no headers included in the Diameter requests, PCRF Core uses the following custom AVPs:

Table 4-68 Custom AVPs in Diameter Requests

Custom AVP	Definition
OC-Origination-Time-Stamp	The AVP contains the date and time (with a millisecond granularity) when the originating entity initiated the request.
OC-Max-Response-Time	This AVP indicates the duration in milliseconds during which the Diameter Gateway waits for a response.
OC-Sender-Time-Stamp	The AVP contains the date and time (with a millisecond granularity) at which a Diameter request or response is originated.

When OC-Sender-Time-Stamp AVP or 3gpp-Sbi-Sender-Timestamp header is present, and (currentTime >= OC-Sender-Time-Stamp + Max-Response-Time), then PCRF Core stops processing the request and returns a 504 error response.

When the OC-Sender-Time-Stamp AVP is not present, but OC-Origination-Time-Stamp is present and (currentTime >= OC-Origination-Time-Stamp + Max-Response-Time), then PCRF Core stops processing the request and returns a 504 error response.

Otherwise, if OC-Origination-Time-Stamp, OC-Sender-Time-Stamp, or OC-Max-Response-Time is not present in the headers, PCRF Core processes the request and sends the expected successful response to Diameter Gateway.

PCRF Core rejects the stale requests with the following error codes:

Table 4-69 Error Codes

Response	Default Value
Diameter Response	5454 (DIAMETER_ERROR_TIMED_OUT_REQUEST)
HTTP Response	504 (Gateway Timeout)

When PCRF Core cancels a request, but the request is already sent to PDS, PRE, or Usage Monitoring service, then no cleanup is required.

When PCRF Core cancels a request, but the request is already sent to Bulwark service, it is expected to free the lock related to the request.

Note:

Any stale session being left behind by PCRF Core in other services, such as PDS, or Usage Monitoring is cleaned up during the audit cycle. PCRF Core does not send any cleanup request related to a stale request cancellation.

Call Flow

Figure 4-48 Sample call flow for stale requests cleanup by PCRF Core

1. PCRF Core receives a request from Diameter Gateway containing either the custom AVPs or HTTP headers for stale request cleanup functionality.

2. PCRF Core verifies if the request is stale by checking the timestamp of the request.

3. If the request is stale, PCRF Core responds to Diameter Gateway with a 5454 (DIAMETER_ERROR_TIMED_OUT_REQUEST) error.

4. If the request is not stale, PCRF Core sends a request to PDS with the timestamp headers. These headers are used to detect the staleness of the request.

5. PDS processes the request and sends a response back to PCRF Core.

6. PCRF Core verifies if the response received from PDS is stale.

7. If the response from PDS is stale, PCRF Core responds to Diameter Gateway with 5454 (DIAMETER_ERROR_TIMED_OUT_REQUEST) error.

8. If the response from PDS is not stale, PCRF Core sends the request to PRE for evaluation.

9. PRE processes the request and responds to PCRF Core.

10. PCRF Core verifies if the response from PRE is stale.

11. If the response from PRE is stale, PCRF Core responds to Diameter Gateway with 5454 (DIAMETER_ERROR_TIMED_OUT_REQUEST) error.

12. If the response from PRE is not stale, PCRF Core sends the details to be processed in the database and receives a response.

13. If the response for the database processing is stale, PCRF Core responds to Diameter Gateway with 5454 (DIAMETER_ERROR_TIMED_OUT_REQUEST) error.

14. If the response for the database processing is not stale, PCRF Core sends the expected successful response to Diameter Gateway.

Stale Requests Cleanup for SM Service

A request from microservices such as Ingress Gateway to SM service is considered as stale when the request takes longer time than the configured time period to reach SM service.

Also, a response from SM service to the requesting microservice such as Ingress Gateway is considered as stale, when SM service takes a longer time than the configured time period to process a request and respond to any of these microservices.

Stale requests or responses by SM service are detected and cleaned using the following 3GPP headers:

• 3gpp-Sbi-Origination-Timestamp
• 3gpp-Sbi-Max-Rsp-Time
• 3gpp-Sbi-Sender-Timestamp

When ENABLE_LATE_PROCESSING Advanced Settings key in PCF Session Management page under Service Configurations in CNC Console is enabled:

• If 3gpp-Sbi-Sender-Timestamp header is present and 3gpp-Sbi-Sender-Timestamp + 3gpp-Sbi-Max-Rsp-Time is before the current time, it means the request has already timed out. Hence, the request gets canceled and SM service responds to Ingress Gateway with 504 (Gateway Timeout) error.

  Note:

  When ENABLE_LATE_PROCESSING is enabled, stale check filter responsible for returning 504 Error Response takes precedence over other error response codes.

• If the 3gpp-Sbi-Sender-Timestamp header is not present, but 3gpp-Sbi-Origination-Timestamp is present and 3gpp-Sbi-Origination-Timestamp + 3gpp-Sbi-Max-Rsp-Time is before the current time, it means the request has already timed out. Hence, the request gets canceled. SM service responds to Ingress Gateway with 504 (Gateway Timeout) error.
• Otherwise, if 3gpp-Sbi-Origination-Timestamp, 3gpp-Sbi-Sender-Timestamp, or 3gpp-Sbi-Max-Rsp-Time are not present in the headers, SM service processes the request normally.

Call Flow

Figure 4-49 Sample call flow for stale requests cleanup by SM Service

1. SM service receives a request from Ingress Gateway containing HTTP headers for stale request cleanup functionality.
2. SM service verifies if the request is stale by checking the timestamp of the request.
3. If the request is stale, SM service responds to Ingress Gateway with 504 error.
4. If the request is not stale, SM service sends the request to PDS containing the custom headers for stale request cleanup functionality.
5. PDS processes the request and sends a response back to SM service.
6. If PDS responds with a success message, SM service checks if the response is received within the configured timeframe or if it is stale.
7. If the response from PDS is stale, SM service responds to Ingress Gateway with 504 error.
8. If the response from PDS is not stale, SM service sends the request to PRE for evaluation.
9. PRE processes the request and responds to SM service.
10. If PRE responds with a success message, SM service checks if the response is received within the configured timeframe or if it is stale.
11. If the response from PRE is stale, SM service responds to Ingress Gateway with 504 error.
12. . If the response from PRE is not stale, SM service sends a request to Binding service to create the binding for the session.
13. Binding service processes the request and responds to SM service.
14. If Binding service responds with a success message, SM service checks if the response is received within the configured timeframe or if it is stale.
15. If the response from Binding service is stale, SM service responds to Ingress Gateway with 504 error.
16. If the response from Binding service is not stale, SM service sends a request to other external databases for any database operation and receives a response.
17. If the response for the database processing is stale, SM service responds to Ingress Gateway with 504 error.
18. If the response for the database processing is not stale, SM service sends the expected successful response to Ingress Gateway.

Note:

Currently, Policy does not support validating the staleness of the following requests in the SM service call flow:

• Notification requests received from PDS
• Notification response forwarded towards PDS
• Staleness verification before sending notification request to PRE
• Staleness verification after receiving notification response from PRE
• Asynchronous requests sent towards PDS
• Asynchronous requests forwarded towards Binding services
• Signalling generated internally by PCF and coming to SM

Stale Requests Cleanup for Binding service

A request from SM service or PCRF Core to Binding service is considered as stale when the request takes longer time than the configured time period to reach Binding service.

Also, a response from Binding service is considered as stale, when Binding service takes a longer time than the configured time period to process a request and respond to any of these microservices.

Binding service validates the staleness of the request in the following scenarios:

• Whenever Binding service receives a request, it checks if the request has gone stale.
• While Binding service processes a request, it checks before or after performing a task that can take more time if the request has not gone stale.

Stale requests or responses by Binding service are detected and cleaned using 3GPP headers in HTTP requests.

The following 3GPP headers are included in every request that comes to, or is sent by Binding service:

Table 4-70 3GPP Headers in HTTP Requests

Header	Definition
3gpp-Sbi-Origination-Timestamp	The header contains the date and time (with a millisecond granularity) when the originating entity initiated the request. Example value: Fri, 29 Oct 2021 20:43:00.000 GMT
3gpp-Sbi-Max-Rsp-Time	This header may be used in a HTTP request to indicate the duration in milliseconds during which the HTTP client waits for a response. Example value: 3000
3gpp-Sbi-Sender-Timestamp	The header contains the date and time (with a millisecond granularity) at which an HTTP request or response is originated. Example value: Tue, 15 Oct 2030 16:53:35.000 GMT

The stale request cleanup feature for Binding service can be enabled by configuring the value of ENABLE_LATE_ARRIVAL and ENABLE_LATE_PROCESSING advanced settings key for Binding Service on CNC Console to true. By default, the value of these keys are set to false.

A request is identified as stale based on the following criteria:

• When ENABLE_LATE_ARRIVAL advanced settings key for Binding service is enabled on CNC Console, and if the Sender-Timestamp header/AVP is present and currentTime >= Sender-Timestamp + Max-Response-Time, Binding service stops processing the request and returns a 504 (Gateway Timeout) error response.
• When ENABLE_LATE_ARRIVAL advanced settings key for Binding service is enabled on CNC Console, and if the Sender-Timestamp header is not present, but Origination-Timestamp is present and currentTime >= Origination-Timestamp + Max-Response-Time, Binding service stops processing the request and returns a 504 (Gateway Timeout) error response.
• Otherwise, Origination-Timestamp, Sender-Timestamp, or Max-Response-Time are not present in the header, Binding service processes the request normally.

Late arrival requests: Whenever Binding service receives a request, it determines if the received request has gone stale or not upon request arrival based on the timestamp in the header. ENABLE_LATE_ARRIVAL is used to check the staleness of the request when a request is received (before doing any time consuming operations). This task is performed in bounded elastic thread just at the moment it changes from XNIO thread to bounded elastic in Binding service.

Late processing: Whenever Binding service starts processing a request, each time a response is obtained from BSF, it determines if the original request is still on time. ENABLE_LATE_PROCESSING is used to check the staleness of the request further in the flow (after the database operations and responses from BSF).

Whenever Binding service rejects a request, it returns a 504 (Gateway Timeout) error response. 504 (Gateway Timeout) is the default value of the error response, which can be configured using the Advanced Settings keys for Binding service in CNC Console.

Call Flow

Figure 4-50 Sample call flow for stale requests cleanup by Binding service

1. Binding service receives a request from SM service or PCRF Core through Diameter Gateway containing HTTP headers for stale request cleanup functionality.

2. Binding service verifies if the request is stale by checking the timestamp of the request.

3. If the request is stale, Binding service responds to SM service or PCRF Core through Diameter Gateway with a 504 (GATEWAY_TIMEOUT) error.

   If the request is not stale, Binding service sends a Session Binding Request to BSF.

   Binding service saves the session binding information received from BSF in context_binding table.

4. Binding service verifies if the response from BSF is stale.

5. If the response from BSF is stale, Binding service stops the further database operation for limiting the number of sessions and responds to SM service or PCRF Core through Diameter Gateway with a 504 (GATEWAY_TIMEOUT) error.

6. If the response from BSF is not stale, Binding service responds to SM service or PCRF Core through Diameter Gateway with session binding information.

Stale Requests Cleanup for Diameter Connector

All requests from Policy microservices such as SM service or PCRF Core to Diameter Gateway is passed through Diameter Connector. Such requests originated from Policy microservices are considered stale at Diameter Connector when the request takes longer time than the configured time period to reach Diameter Connector.

Also, a response from Diameter Connector to other Policy microservices is considered as stale, when Diameter Connector takes a longer time than the configured time period to process a request and respond to any of these microservices.

Stale requests cleanup functionality for Diameter Connector can be enabled using enable.late.arrival and enable.late.processing fields in Diameter Connector page under Service Configurations in CNC Console.

By default, this functionality is disabled.

Stale requests or responses by Diameter Connector are detected and cleaned using Attribute Value Pairs (AVPs) for Diameter requests and using 3GPP headers for HTTP requests.

The following 3GPP headers are included in every request that comes to, or is sent by Diameter Connector:

Table 4-71 3GPP Headers in HTTP Requests

Header	Definition
3gpp-Sbi-Origination-Timestamp	The header contains the date and time (with a millisecond granularity) when the originating entity initiated the request. Example: Fri, 29 Oct 2021 20:43:00.000 GMT
3gpp-Sbi-Max-Rsp-Time	This header may be used in a HTTP request to indicate the duration in milliseconds during which the HTTP client waits for a response. Example: 3000
3gpp-Sbi-Sender-Timestamp	The header contains the date and time (with a millisecond granularity) at which an HTTP request or response is originated. Example: Tue, 15 Oct 2030 16:53:35.000 GMT

If there are no headers included in the requests, Diameter Connector uses the following custom AVPs:

Table 4-72 Custom AVPs in Diameter Requests

Custom AVP	Definition
Origination-Timestamp	The AVP contains the date and time (with a millisecond granularity) when the originating entity initiated the request. Example: Fri, 29 Oct 2021 20:43:00.000 GMT
Max-Response-Time	This AVP indicates the duration in milliseconds during which the HTTP client waits for a response. Example: 3000
Sender-Timestamp	The AVP contains the date and time (with a millisecond granularity) at which a Diameter request or response is originated. Example: Tue, 15 Oct 2030 16:53:35.000 GMT

When Sender-Timestamp AVP or 3gpp-Sbi-Sender-Timestamp header is present, and (currentTime >= Sender-Timestamp + Max-Response-Time), then stop processing the request and return 504 or 5454 error response.

When Sender-Timestamp AVP or 3gpp-Sbi-Sender-Timestamp header is not present, and (currentTime >= Origination-Timestamp + Max-Response-Time), stop processing the request and return 504 or 5454 error response.

Otherwise, if Origination-Timestamp, Sender-Timestamp, or Max-Response-Time are not present in the headers, process the request normally.

Late arrival requests: In the event where the resulting time of 3gpp-Sbi-Origination-Timestamp + 3gpp-Sbi-Max-Rsp-Time is in the past, Diameter Connector rejects the message with 504 or 5454 error response.

Late processing: Whenever Diameter-Gateway processes a request, each time a response is obtained from a microservice such as SM service, it determines if the original request is still on time. This process is known as late processing

Diameter Connector rejects the stale requests with the following error codes:

Table 4-73 Error Codes

Response	Default Value
Diameter Response	5454 (DIAMETER_ERROR_TIMED_OUT_REQUEST)
HTTP Response	504 (Gateway Timeout)

Skipping stale request cleanup for terminate requests

By default, when stale request cleanup for late arrival and late processing requests is enabled, Diameter Connector checks for all types of incoming requests. However, Diameter Connector can be configured to skip this check for TERMINATE requests, as sometimes it is not desirable to leave stale sessions on other services or databases.

This skipping the stale request cleanup for TERMINATE requests can be configured using Skip Late Processing For Terminate field under Diameter Connector page for Service Configurations in CNC Console.

Call Flow

Figure 4-51 Sample call flow for stale Rx requests cleanup by Diameter Connector

1. Diameter Connector receives a request from AF through Diameter Gateway containing either the custom AVPs or HTTP headers for stale request cleanup functionality.

   In this case, stale request cleanup for late arrival requests is enabled (enable.late.arrival=true)) and stale request cleanup for late processing requests is enabled (enable.late.processing=true and skip stale request cleanup for TERMINATE requests is disabled (skip.late.processing.for.terminate=false).

2. Diameter Connector verifies if the request is stale by checking the timestamp of the request.

3. If the request is stale, Diameter Connector responds to Diameter Gateway with a 5454 (DIAMETER_ERROR_TIMED_OUT_REQUEST) error.

4. If the request is not stale, Diameter Connector sends the request to SM service for further processing of the request with the custom AVPs or custom headers for stale request cleanup functionality.

5. SM service processes the request and sends a response back to Diameter Connector.

6. Diameter Connector verifies if the response received from SM service is stale.

7. If the response from SM service is stale, Diameter Connector responds to Diameter Gateway with 5454 (DIAMETER_ERROR_TIMED_OUT_REQUEST) error.

8. If the response from SM service is not stale, Diameter Connector continues further processing of the RX request.

Figure 4-52 Sample call flow for stale SLR requests cleanup by Diameter Connector

1. Diameter Connector receives an SLR request from PDS containing either the custom AVPs or HTTP headers for stale request cleanup functionality.

   In this case, stale request cleanup for late arrival requests is enabled (enable.late.arrival=true)) and stale request cleanup for late processing requests is enabled (enable.late.processing=true and skip stale request cleanup for TERMINATE requests is disabled (skip.late.processing.for.terminate=false).

2. Diameter Connector verifies if the SLR request is stale by checking the timestamp of the request.

3. If the request is stale, Diameter Connector responds to PDS with a 504 (GATEWAY_TIME_OUT_REQUEST) error.

4. If the request is not stale, Diameter Connector sends the request to OCS for further processing of the request with the custom AVPs or custom headers for stale request cleanup functionality.

5. OCS processes the request and sends a response back to Diameter Connector.

6. Diameter Connector verifies if the response received from OCS is stale.

7. If the response from OCS is stale, Diameter Connector responds to PDS with a 504 (GATEWAY_TIME_OUT_REQUEST) error.

8. If the response from OCS is not stale, Diameter Connector continues further processing of the SLR request.

Stale Requests Cleanup for User Service (CHF Connector or UDR Connector)

Whenever User Service (UDR-connector/CHF-connector) receives a request from PDS, it is possible that either the request takes too much time to be received or User Service takes too much time to process the request and send back a response. User Service identifies such requests as stale requests if it takes longer than the configured time to reach the destination. User Service stops further processing of such stale requests and rejects them with 504( Gateway Timeout) error.

A request from PDS to User Service is considered as stale when the request takes longer time than the configured time period to reach User Service (CHF Connector or UDR Connector).

Also, a response from User Service to PDS is considered as stale, when User Service takes a longer time than the configured time period to process a request and respond to any of these microservices.

Note:

Currently, this feature does not validate the staleness of the notification requests received from CHF or UDR to User Service.

User Service forwards the notifications from CHF and UDR to PDS without any validation.

PDS must be configured to handle cleanup of any stale requests received from CHF or UDR.

The stale request cleanup functionality for User Service (CHF Connector and UDR Connector) can be enabled either using Helm parameters at the time of installation or using the following Advanced Settings keys on User Service page under Service Configurations in CNC Console:

• CHF.enable.late.arrival
• UDR.enable.late.arrival
• CHF.enable.late.processing
• UDR.enable.late.processing
• CHF.skip.late.processing.for.terminate
• UDR.skip.late.processing.for.terminate

Helm parameters:

• CHF.enableLateArrival
• CHF.enableLateProcessing
• CHF.skipLateProcessingForTerminate
• UDR.enableLateArrival
• UDR.enableLateProcessing
• UDR.skipLateProcessingForTerminate

Stale requests or responses by User Service are detected and cleaned using 3GPP headers for HTTP requests.

The following 3GPP headers are included in every request that comes to, or is sent by User Service:

Table 4-74 3GPP Headers in HTTP Requests

Header	Definition
3gpp-Sbi-Origination-Timestamp	The header contains the date and time (with a millisecond granularity) when the originating entity initiated the request. Example: Fri, 29 Oct 2021 20:43:00.000 GMT
3gpp-Sbi-Max-Rsp-Time	This header may be used in a HTTP request to indicate the duration in milliseconds during which the HTTP client waits for a response. Example: 3000 Note: If the external NF provides negative MRT then it will not be considered and the stale checks will not fail for any requests based on MRT. Currently, the 3gpp-Sbi-Max-Rsp-Time header is not readjusted in any microservice to account for the processing time needed for the individual microservices. Hence when PDS sends this header to User Service it does not keep any buffer time itself to process a data in case User Service sends back the response in the verge of timeout. Cleanup of any CHF subscription will not be triggered by PDS automatically. For validation of such requests, there must be a provision kept by the caller microservice to modify the headers to subtract some time from 3gpp-Sbi-Max-Rsp-Time to account for it's own processing time.
3gpp-Sbi-Sender-Timestamp	The header contains the date and time (with a millisecond granularity) at which an HTTP request or response is originated. Example: Tue, 15 Oct 2030 16:53:35.000 GMT

When Sender-Timestamp AVP or 3gpp-Sbi-Sender-Timestamp header is present, and (currentTime >= Sender-Timestamp + Max-Response-Time), then stop processing the request and return 504 error response.

When Sender-Timestamp AVP or 3gpp-Sbi-Sender-Timestamp header is not present, and (currentTime >= Origination-Timestamp + Max-Response-Time), stop processing the request and return 504 error response.

Otherwise, if Origination-Timestamp, Sender-Timestamp, or Max-Response-Time are not present in the headers, process the request normally.

Late arrival requests: Whenever User Service receives a request, it determines if the received request has gone stale or not upon request arrival.

Late processing requests: Whenever User Service starts processing a request, each time a response is obtained from another service (NRF Client, Alternate Route Service), it determines if the original request is still on time.

Note:

Irrespective of the type of request that user Service receives, if the request includes the required headers, User Service performs late arrival stale checks if it is enabled. But, it may not perform the late processing check as notification requests are not checked in late processing part.

By default, User Service does not perform any cleanup of stale requests. Changes made to other services remains until an audit process identifies these sessions as stale and removes them.

Note:

If SBI TIMER is enabled and origination timestamp is sent, STS is prioritized over OTS and STS is generated by User Service when SBI TIMER is enabled in User Service and no STS is sent. Hence, late arrival check will not be performed, but late processing check can happen in self populated STS value.

Skipping Stale Request check for Terminate Requests

When UDR.skipLateProcessingForTerminate or CHF.skipLateProcessingForTerminate Helm parameters are enabled, or if the value of UDR.skip.late.processing.for.terminate or CHF.skip.late.processing.for.terminate Advanced Settings key is set to true, User Service skips validating the staleness of the TERMINATE requests.

Validation of the TERMINATE requests are skipped only in case of late processing.

Late arrival TERMINATE requests are rejected similar to the other late arrival requests.

Call Flow

Figure 4-53 Sample call flow for stale requests cleanup by User Service

1. User Service (nCHF Connector or nUDR Connector) receives a GET request from PDS containing the HTTP headers for stale request cleanup functionality.

2. User Service (nCHF Connector or nUDR Connector) verifies if the request is stale by checking the timestamp of the request.

3. If the request is stale, User Service (nCHF Connector or nUDR Connector) responds to PDS with a 504 (GATEWAY_TIME_OUT) error.

4. If the request is not stale, User Service (nCHF Connector or nUDR Connector) sends a request to NRF Client containing the custom headers for stale request cleanup functionality to discover the CHF or UDR profile.

5. If the response from NRF Client to User Service (nCHF Connector or nUDR Connector) is stale, User Service (nCHF Connector or nUDR Connector) responds to PDS with a 504 (GATEWAY_TIME_OUT) error.
6. If the response from NRF Client to User Service (nCHF Connector or nUDR Connector) is not stale, User Service (nCHF Connector or nUDR Connector) sends the request to the discovered CHF or UDR instance.
7. User Service (nCHF Connector or nUDR Connector) sends the response received from CHF or UDR to PDS.
8. When User Service (nCHF Connector or nUDR Connector) receives a POST (Subscription) request from PDS, it verifies if the request is stale.
9. If the received POST request is stale, User Service (nCHF Connector or nUDR Connector) responds to PDS with a 504 (GATEWAY_TIME_OUT) error.
10. If the received POST request is not stale, User Service (nCHF Connector or nUDR Connector) sends a request to NRF Client containing the custom headers for stale request cleanup functionality to discover the CHF or UDR profile.
11. If the response from NRF Client to User Service (nCHF Connector or nUDR Connector) is stale, User Service (nCHF Connector or nUDR Connector) responds to PDS with a 504 (GATEWAY_TIME_OUT) error.
12. If the response from NRF Client to User Service (nCHF Connector or nUDR Connector) is not stale, User Service (nCHF Connector or nUDR Connector) sends the POST request to the discovered CHF or UDR instance.
13. User Service (nCHF Connector or nUDR Connector) sends the response received from CHF or UDR to PDS.
14. If there is a delay of response from external UDR/CHF and feature is enabled, User Service (nCHF Connector or nUDR Connector) closes the channel once Max-Response-Time is reached and responds to PDS with 500 (INTERNAL_SERVER_ERROR) error.

Note:

Stale request functionality for the above mentioned calls are implemented for synchronous calls only.

Stale Requests Cleanup for UE Policy service

A request from Ingress Gateway, PDS, PRE, or Bulwark service to UE Policy service is considered as stale when the request takes longer time than the configured time period to reach UE Policy service.

Also, a response from UE Policy service to Ingress Gateway, PDS, PRE, or Bulwark service is considered as stale, when UE Policy service takes a longer time than the configured time period to process a request and respond to any of these microservices.

UE Policy service validates the staleness of the request in the following scenarios:

• Whenever UE Policy service receives a request, it checks if the request has gone stale.
• While UE Policy service processes a request, it checks before or after performing a task that can take more time if the request has not gone stale.
• Currently, N1N2 notification requests received are not considered for stale request cleanup.

Note:

Asynchronous requests are not considered when handling stale requests. The response received for asynchronous request should not affect or impact the original request check. An example of this asynchronous request is N1N2-Transfer messages.

Stale requests or responses by UE Policy service are detected and cleaned using 3GPP headers in HTTP requests.

The following 3GPP headers are included in every request that comes to, or is sent by UE Policy service:

Table 4-75 3GPP Headers in HTTP Requests

Header	Definition
3gpp-Sbi-Origination-Timestamp	The header contains the date and time (with a millisecond granularity) when the originating entity initiated the request. Example value: Fri, 29 Oct 2021 20:43:00.000 GMT
3gpp-Sbi-Max-Rsp-Time	This header may be used in a HTTP request to indicate the duration in milliseconds during which the HTTP client waits for a response. Example value: 3000
3gpp-Sbi-Sender-Timestamp	The header contains the date and time (with a millisecond granularity) at which an HTTP request or response is originated. Example value: Tue, 15 Oct 2030 16:53:35.000 GMT

A request is identified as stale based on the following criteria:

• When the Sender-Timestamp header/AVP is present and currentTime >= Sender-Timestamp + Max-Response-Time, UE Policy service stops processing the request and returns a 504 (Gateway Timeout) error response.
• When the Sender-Timestamp header is not present, but Origination-Timestamp is present and currentTime >= Origination-Timestamp + Max-Response-Time, UE Policy service stops processing the request and returns a 504 (Gateway Timeout) error response.
• Otherwise, Origination-Timestamp, Sender-Timestamp, or Max-Response-Time are not present in the header, UE Policy service processes the request normally.

Late arrival requests: Whenever UE Policy service receives a request, it determines if the received request has gone stale or not upon request arrival based on the timestamp in the header.

Late processing: Whenever UE Policy service starts processing a request, each time a response is obtained from another service such as PDS, PRE, or Bulwark service, it determines if the original request is still on time.

Whenever UE Policy service rejects a request, it returns a 504 (Gateway Timeout) error response.

Note:

By default, UE Policy service does not perform a cleanup whenever a request has gone stale. Changes made to other services will remain until an Audit process identifies these sessions as stale and removes them.

However, if required, the cleanup functionality can be enabled either by configuring enableLateProcessingCleanup, helm parameter and ENABLE_LATE_PROCESSING_CLEANUP environmental variable, or by configuring ENABLE_LATE_PROCESSING_CLEANUP advanced setting key for UE Policy service in CNC Console.

Skipping Stale Request Cleanup for Terminate Requests:

When late processing is enabled, UE Policy service checks for all types of requests being processed. But, UE Policy service can skip this check for Terminate requests, as sometimes it is not desirable to leave stale sessions on other services or databases.

This feature can be enabled either by configuring skipLateProcessingForTerminate Helm parameter and SKIP_LATE_PROCESSING_FOR_TERMINATE environmental variable, or by configuring skip.late.processing.for.terminate advanced settings key for UE Policy service in CNC Console.

Call Flow

Figure 4-54 Sample call flow for stale requests cleanup by UE Policy service

1. UE Policy service receives a request from AMF through Ingress Gateway containing HTTP headers for stale request cleanup functionality.

   The configuration for UE service in advance settings is the following:

   • ENABLE_LATE_ARRIVAL=true
   • ENABLE_LATE_PROCESSING=true
   • SKIP_LATE_PROCESSING_FOR_TERMINATE=true

2. UE Policy service verifies if the request is stale by checking the timestamp of the request.

3. If the request is stale, UE Policy service responds to AMF through Ingress Gateway with a 504 (GATEWAY_TIMEOUT) error.

   If the request is not stale, UE Policy service sends a acquire lock request to Bulwark service.

   UE Policy service verifies if the response from Bulwark service is stale.

4. If the response from Bulwark service is stale, UE Policy service responds to AMF through Ingress Gateway with a 504 (GATEWAY_TIMEOUT) error.

5. If the response from Bulwark service is not stale, UE Policy service sends a request to PDS with the custom headers for stale request cleanup functionality.

6. PDS processes the request and sends a response back to UE Policy service.

7. UE Policy service verifies if the response received from PDS is stale.

8. If the response from PDS is stale, UE Policy service responds to AMF through Ingress Gateway with a 504 (GATEWAY_TIMEOUT) error.

9. If the response from PDS is not stale, UE Policy service sends the request to PRE for evaluation.

10. PRE processes the request and responds to UE Policy service.

11. UE Policy service verifies if the response from PRE is stale.

12. If the response from PRE is stale, UE Policy service responds to AMF through Ingress Gateway with a 504 (GATEWAY_TIMEOUT) error.

13. If the response from PRE is not stale, UE Policy service sends the details to be processed in the database and receives a response.

14. If the response for the database processing is stale, UE Policy service responds to AMF through Ingress Gateway with a 504 (GATEWAY_TIMEOUT) error.

15. If the response for database processing is not stale, UE Policy service sends unlock request to Bulwark service.
16. UE Policy service verifies if the response from Bulwark service is stale.

    If the response is stale, UE Policy service responds to AMF through Ingress Gateway with a 504 (GATEWAY_TIMEOUT) error.

17. If the response from Bulwark service is not stale, UE Policy service sends the expected successful response to AMF through Ingress Gateway.

Managing Stale Requests Cleanup

Managing Stale Requests Cleanup for PCRF Core

Enable

Stale requests cleanup functionality for PCRF Core can be enabled either using ENABLE_LATE_ARRIVAL and ENABLE_LATE_PROCESSING Helm parameters at the time of Policy installation or using enable.late.arrival enable.late.processing Advanced Settings key in PCRF Core Settings page under Service Configurations in CNC Console.

By default, this functionality is disabled.

For details on how to enable the functionality using Helm parameter, see PCRF-Core Configurations section in Oracle Communications Cloud Native Core, Converged Policy Installation, Upgrade, and Fault Recovery Guide.

For details on how to enable the functionality using CNC Console, see Settings.

Configure

Stale requests cleanup functionality for PCRF Core can be configured either using Helm parameters at the time of Policy installation or using CNC Console.

Configure using Helm parameters

Configure the following Helm parameters in custom-values.yaml file:

• ENABLE_LATE_ARRIVAL
• ENABLE_LATE_PROCESSING
• LATE_ARRIVAL_MAX_RESPONSE_TIME
• SBI_TIMER_ENABLED
• SKIP_LATE_PROCESSING_FOR_TERMINATE

For more information on these Helm parameters, see PCRF-Core Configurations and Diameter Gateway and Diameter Connector Configuration sections in Oracle Communications Cloud Native Core, Converged Policy Installation, Upgrade, and Fault Recovery Guide.

Configure using CNC console

Configure the following Advanced Settings keys in PCRF Core Settings page under Service Configurations in CNC Console:

• enable.late.arrival
• enable.late.processing
• late.arrival.max.resp.time
• skip.late.processing.for.terminate
• sbi.timer.enabled

For more information, see Settings.

Note:

If there are no Advanced Settings related to stale request cleanup are present, then the Helm configurations will be used. However, if Advanced Settings are present, values of the Advanced Settings keys are used instead of Helm configurations.

Managing Stale Requests Cleanup for SM Service

Enable

Stale request cleanup functionality for SM service can be enabled using ENABLE_LATE_PROCESSING Advanced Settings key in PCF Session Management page under Service Configurations in CNC Console.

By default, this functionality is disabled.

For more information, see PCF Session Management.

Configure

Configure the ENABLE_LATE_PROCESSING Advanced Settings keys in PCF Session Management page under Service Configurations in CNC Console:

For more information, see PCF Session Management.

Managing Stale Requests Cleanup for Binding service

Enable

Stale requests cleanup functionality for Binding service can be enabled either using ENABLE_LATE_ARRIVAL and ENABLE_LATE_PROCESSING Advanced Settings keys in Binding Service page under Service Configurations in CNC Console.

By default, this functionality is disabled.

For details on how to enable the functionality using CNC Console, see Binding Service.

Configure

Stale requests cleanup functionality for Binding service can be configured using CNC Console.

Configure using CNC console

Configure the following Advanced Settings keys in Binding Service page under Service Configurations in CNC Console:

• ENABLE_LATE_ARRIVAL
• ENABLE_LATE_PROCESSING

For more information, see Binding Service.

In configure DIAMETER.Timer.Enabled advanced settings key under Settings page for Diameter Configuration under Service Configurations in CNC Console.

For more information, see Settings.

Managing Stale Requests Cleanup for Diameter Connector

Enable

Stale requests cleanup functionality for Diameter Connector can be enabled using enable.late.arrival and enable.late.processing fields in Diameter Connector page under Service Configurations in CNC Console.

By default, this functionality is disabled.

For details on how to enable the functionality using CNC Console, see Diameter Connector.

Configure

Stale requests cleanup functionality for Diameter Connector can be configured using CNC Console.

Configure using CNC console

Configure the following fields in Diameter Connector page under Service Configurations in CNC Console:

• enable.late.arrival
• enable.late.processing
• skip.late.processing.for.terminate
• sbi.timer.enabled

For more information, see Diameter Connector.

If diameter Gateway does not receive the timer AVPs in request, configure diameter Gateway to generate them and send them to Diam Connector by configuring DIAMETER.Timer.Enabled Advanced Settings key under Diameter Configurations page in Service Configurations.

For more information, see Settings

Managing Stale Requests Cleanup for User Service (CHF Connector and UDR Connector)

Enable

The stale request cleanup functionality for User Service (CHF Connector and UDR Connector) can be enabled either using Helm parameters at the time of installation or using CNC Console.

By default, this functionality is disabled.

Enable using Helm parameters:

• CHF.enableLateArrival
• CHF.enableLateProcessing
• CHF.skipLateProcessingForTerminate
• UDR.enableLateArrival
• UDR.enableLateProcessing
• UDR.skipLateProcessingForTerminate

For more information on these Helm parameters, see Enabling/Disabling Services Configurations sections in Oracle Communications Cloud Native Core, Converged Policy Installation, Upgrade, and Fault Recovery Guide.

Enable using CNC Console:

Configure the following Advanced Settings keys on User Service page under Service Configurations in CNC Console:

• CHF.enable.late.arrival
• UDR.enable.late.arrival
• CHF.enable.late.processing
• UDR.enable.late.processing
• CHF.skip.late.processing.for.terminate
• UDR.skip.late.processing.for.terminate

For details on how to enable the functionality using CNC Console, see PCF User Connector.

Configure

Stale requests cleanup functionality for User Service can be configured using Helm parameters at the time of installation or using CNC Console.

Configure using Helm parameters

• CHF.enableLateArrival
• CHF.enableLateProcessing
• CHF.skipLateProcessingForTerminate
• UDR.enableLateArrival
• UDR.enableLateProcessing
• UDR.skipLateProcessingForTerminate

For more information on these Helm parameters, see Enabling/Disabling Services Configurations sections in Oracle Communications Cloud Native Core, Converged Policy Installation, Upgrade, and Fault Recovery Guide.

Configure using CNC console

Configure the following Advanced Settings keys on User Service page under Service Configurations in CNC Console:

• CHF.enable.late.arrival
• UDR.enable.late.arrival
• CHF.enable.late.processing
• UDR.enable.late.processing
• CHF.skip.late.processing.for.terminate
• UDR.skip.late.processing.for.terminate

For details on how to enable the functionality using CNC Console, see PCF User Connector.

Managing Stale Requests Cleanup for UE Policy service

Enable

Stale requests cleanup functionality for UE Policy service can be enabled either using enableLateArrival and enableLateProcessing Helm parameters at the time of Policy installation or using ENABLE_LATE_ARRIVAL and ENABLE_LATE_PROCESSING Advanced Settings keys in PCF UE Policy page under Service Configurations in CNC Console.

By default, this functionality is disabled.

For details on how to enable the functionality using Helm parameter, see Enabling/Disabling Services Configurations section in Oracle Communications Cloud Native Core, Converged Policy Installation, Upgrade, and Fault Recovery Guide.

For details on how to enable the functionality using CNC Console, see PCF UE Policy Service.

Configure

Stale requests cleanup functionality for UE Policy service can be configured either using Helm parameters at the time of Policy installation or using CNC Console.

Configure using Helm parameters

Configure the following Helm parameters in custom-values.yaml file:

• enableLateArrival
• enableLateProcessing
• skipLateProcessingForTerminate

For more information on these Helm parameters, see Enabling/Disabling Services Configurations sections in Oracle Communications Cloud Native Core, Converged Policy Installation, Upgrade, and Fault Recovery Guide.

Configure using CNC console

Configure the following Advanced Settings keys in PCF UE Policy page under Service Configurations in CNC Console:

• ENABLE_LATE_ARRIVAL
• ENABLE_LATE_PROCESSING
• SKIP_LATE_PROCESSING_FOR_TERMINATE

For more information, see PCF UE Policy Service.

Note:

If there are no Advanced Settings related to stale request cleanup are present, then the Helm configurations will be used. However, if Advanced Settings are present, values of the Advanced Settings keys are used instead of Helm configurations.

Observability

Metrics

Metrics for PCRF Core

The following metrics are used for handling stale requests cleanup functionality for PCRF Core:

• occnp_stale_diam_request_cleanup_total
• occnp_stale_http_request_cleanup_total

For more information, see PCRF Core Metrics.

Metrics for SM service

The occnp_late_processing_rejection_total metric is used for handling stale requests cleanup functionality for SM service.

For more information, see SM Service Metrics.

Metrics for Binding service

The following metrics are used for handling stale requests cleanup functionality for Binding service:

• occnp_late_arrival_rejection_total
• occnp_late_processing_rejection_total

For more information, see Binding Service Metrics.

Metrics for Diameter Connector

The occnp_stale_diam_request_cleanup_total metric is used for handling stale requests cleanup functionality for Diameter Connector:.For more information, see Diameter Connector Service Metrics.

Metrics for User Service

The following metrics are used for handling stale requests cleanup functionality for User Service:

• occnp_late_arrival_rejection_total
• occnp_late_processing_rejection_total

For more information, see User Service Metrics.

Metrics for UE Policy service

The ocpm_late_arrival_rejection_total and occnp_late_processing_rejection_total metrics are used for handling stale requests cleanup functionality for UE Policy service.

For more information, see UE Service Metrics.

Alerts

Alerts for PCRF Core

The following alerts are used for handling stale requests cleanup functionality for PCRF Core:

• STALE_DIAMETER_REQUEST_CLEANUP_MINOR
• STALE_DIAMETER_REQUEST_CLEANUP_MAJOR
• STALE_DIAMETER_REQUEST_CLEANUP_CRITICAL

For more information, see Common Alerts.

Alerts for SM service

The following alerts are used for handling stale requests cleanup functionality for SM service:

• SM_STALE_REQUEST_PROCESSING_REJECT_MINOR
• SM_STALE_REQUEST_PROCESSING_REJECT_MAJOR
• SM_STALE_REQUEST_PROCESSING_REJECT_CRITICAL

For more information, see Common Alerts.

Alerts for Binding service

The following alerts are used for handling stale requests cleanup functionality for Binding service:

• STALE_BINDING_REQUEST_REJECTION_CRITICAL
• STALE_BINDING_REQUEST_REJECTION_MAJOR
• STALE_BINDING_REQUEST_REJECTION_MINOR

For more information, see Common Alerts.

Alerts for Diameter Connector

The following alerts are used for handling stale requests cleanup functionality for Binding service:

• STALE_DIAMETER_CONNECTOR_REQUEST_CLEANUP_MINOR
• STALE_DIAMETER_CONNECTOR_REQUEST_CLEANUP_MAJOR
• STALE_DIAMETER_CONNECTOR_REQUEST_CLEANUP_CRITICAL

For more information, see Common Alerts.

Alerts for User Service

The following alerts are used for handling stale requests cleanup functionality for User Service:

• CHF_C_STALE_HTTP_REQUEST_CLEANUP_MINOR
• CHF_C_STALE_HTTP_REQUEST_CLEANUP_MAJOR
• CHF_C_STALE_HTTP_REQUEST_CLEANUP_CRITICAL
• UDR_C_STALE_HTTP_REQUEST_CLEANUP_MINOR
• UDR_C_STALE_HTTP_REQUEST_CLEANUP_MAJOR
• UDR_C_STALE_HTTP_REQUEST_CLEANUP_CRITICAL

For more information, see Common Alerts.

Alerts for UE Policy service

The following alerts are used for handling stale requests cleanup functionality for UE Policy service:

• UE_STALE_REQUEST_PROCESSING_REJECT_MINOR
• UE_STALE_REQUEST_PROCESSING_REJECT_MAJOR
• UE_STALE_REQUEST_PROCESSING_REJECT_CRITICAL
• UE_STALE_REQUEST_ARRIVAL_REJECT_MINOR
• UE_STALE_REQUEST_ARRIVAL_REJECT_MAJOR
• UE_STALE_REQUEST_ARRIVAL_REJECT_CRITICAL

For more information, see Common Alerts.

4.19 Support for Diameter Message Response Time Latency Metrics

CnPolicy Diameter Gateway implements latency metrics that provides the time taken to service a request/response in a Diameter call flow. This ensures that the cnPolicy meets the required service level agreements (SLAs) for latency as set by the Customer. The latency measurements are indicators of network health and stability. A sudden increase in latency value can signal an issue either within the cnPolicy or in its interactions with other network elements. Monitoring latency values helps the user to quickly identify and troubleshoot without leading to any service disruptions.

The following latency histograms are implemented to track latency in Diameter Gateway:

• occnp_diam_response_latency_seconds: This metrics provides information on individual call latency time for any calls made by Diameter Gateway towards any network peers or internal back end services.
• occnp_diam_service_overall_processing_time_seconds: This metrics provide an overall time tracking latency for any request towards Diameter Gateway.

For Diameter Gateway, a sample of the histogram latency bucket and percentile ranges in milliseconds is provided:

diam_response_latency.histogram.latency_bucket=1,2,3,4,6,8,10,20,30,40,60,80,100,200,300,400,600,800,1000,2000,3000,4000,6000,8000,10000,+inf
diam_response_latency.histogram.percentile=0.50, 0.90, 0.95, 0.99

Observability

Metrics:

The following common service metrics are used to provide information about this feature:

• occnp_diam_response_latency_seconds
• occnp_diam_service_overall_processing_time_seconds

For more information about metrics, see Diameter Gateway Metrics section.

Maintain

To resolve any alerts at the system or application level, see Alerts section. In case the alerts still persist, perform the following:

• Collect the logs: For more information on how to collect logs, see Oracle Communications Clout Native Core, Converged Policy Troubleshotting Guide.
• Raise a service request: See My Oracle Support.

4.20 Support for TLS

Policy uses Hypertext Transfer Protocol Secure (HTTPS) to establish secured connections with consumer NFs and producer NFs, respectively. These communication protocols are encrypted using Transport Layer Security (TLS).

TLS comprises the following components:

• Handshake Protocol: Exchanges the security parameters of a connection.
• Record Protocol: Receives the messages to be transmitted, fragments the data into multiple blocks, secures the records, and then transmits the result. Received data is delivered to higher-level peers.

This feature enables the support for TLS 1.3 to all consumer NFs, producer NFs, the Data Director, SBI Interfaces, and any interfaces previously supporting TLS 1.2. Support for TLS 1.2 will remain available.

Note:

If both TLS 1.2 and TLS 1.3 are supported, TLS 1.3 is given priority.

TLS 1.2 and TLS 1.3 Handshake

This section describes the differences between TLS 1.3 and TLS 1.2, as well as the advantages of TLS 1.3 over TLS 1.2 and earlier versions.

Figure 4-55 TLS 1.2 and TLS 1.3 Handshake

TLS 1.2

Step 1: The connection or handshake starts when the client sends a "client hello" message to the server. This message consists of cryptographic information such as supported protocols and cipher suites. It also contains a random value or random byte string.

Step 2: To respond to the "client hello" message, the server sends a 'server hello' message. This message contains the CipherSuite that the server has selected from the options provided by the client. The server also sends its certificate, along with the session ID and another random value.

Step 3: The client verifies the certificate sent by the server. When the verification is complete, it sends a byte string encrypted using the public key of the server's certificate.

Step 4: When the server receives the secret, both the client and server generate a master key along with session keys (ephemeral keys). These session keys are used for symmetrically encrypting the data.

Step 5: The client sends an "HTTP Request" message to the server to enable the server to transition to symmetric encryption using the session keys.

Step 6: To respond to the client’s "HTTP Request" message, the server does the same and switches its security state to symmetric encryption. The server concludes the handshake by sending an HTTP response.

Step 7: The client-server handshake is completed in two round trips.

TLS 1.3

Step 1: The connection or handshake begins when the client sends a "client hello" message to the server, which includes the list of supported cipher suites and the client's key share for the specific key agreement protocol.

Step 2: To respond to the "client hello" message, the server sends the key agreement protocol that it has chosen. The "Server Hello" message includes the server key share, server certificate, and the "Server Finished" message.

Step 3: The client verifies the server certificate, generates keys since it has the server's key share, and then sends the "Client Finished" message along with an HTTP request.

Step 4: The server completes the handshake by sending an HTTP response.

Note:

ASM and TLS are not supported together.

The following table provides comparison of TLS 1.2 with TLS 1.3:

Table 4-76 Comparison of TLS 1.2 with TLS 1.3

Feature	TLS 1.2	TLS 1.3
TLS Handshake	This is less efficient as it requires more round-trips to complete the handshake process.	This is more efficient as it requires less round-trips to complete the handshake process.
Cipher Suites	This has less secured Cipher Suites.	This has more secured Cipher Suites. They support the following ciphers: TLS_CHACHA20_POLY1305_SHA256 TLS_AES_128_GCM_SHA256 TLS_AES_256_GCM_SHA384 TLS_AES_128_CCM_8_SHA256: This Cipher is not supported by Java library. TLS_AES_128_CCM_SHA256: This Cipher is not supported by Java library.
Round-Trip Time (RTT)	This has higher RTT during TLS handshake.	This has low RTT.
Performance	This has higher latency during TLS handshake.	This has low latency during TLS handshake.

Note:

• Policy does not prioritize cipher suites on the basis of priorities. To select cipher on the basis of priorities, you must write the cipher suites in the decreasing order of priority.
• Policy does not prioritize supported groups on the basis of priorities. To select supported group on the basis of priorities, you must write the supported group values in the decreasing order of priority.
• If you want to provide values for the signature_algorithms extension using the clientSignatureSchemes parameter, the following comma-separated values must be provided to deploy the pods:

  • rsa_pkcs1_sha512
  • rsa_pkcs1_sha384
  • rsa_pkcs1_sha256
• The mandatory extensions as listed in RFC 8446 cannot be disabled on the client or server side. The following is the list of the extensions that cannot be disabled:
  • supported_versions
  • key_share
  • supported_groups
  • signature_algorithms
  • pre_shared_key

The following digital signature algorithms of TLS 1.2 and TLS 1.3 are supported in TLS handshake:

Table 4-77 Digital Signature Algorithms

Algorithm	Key Size (Bits)	Elliptic Curve (EC)
RS256 (RSA)	2048	NA
	4096 This is the recommended value.	NA
ES256 (ECDSA)	NA	SECP384r1 This is the recommended value.

Note:

The following functionalities from TLS 1.3 specifications are not supported:

• Zero round-trip time (0-RTT) mode.
• Pre-Shared Key (PSK) exchange.

4.20.1 Support for TLS Using HTTPs

Policy uses Hypertext Transfer Protocol Secure (HTTPS) to establish secured connections with consumer NFs and producer NFs, respectively. These communication protocols are encrypted using Transport Layer Security (TLS).

Enable

This feature is enabled by default at the time of Gateway Services deployment by completing the required Helm configurations.

Configure

You can configure this feature using Helm. For information about Helm configurations, see "Global Parameters" in Oracle Communications Cloud Native Core, Converged Policy Installation, Upgrade, and Fault Recovery Guide.

Observe

The following metrics are available for this feature:

• oc_ingressgateway_incoming_tls_connections
• oc_egressgateway_outgoing_tls_connections
• security_cert_x509_expiration_seconds

For more information about metrics, see section TLS Metrics.

The following alerts are available for this feature:

• CERTIFICATE_EXPIRY_CRITICAL
• CERTIFICATE_EXPIRY_MAJOR
• CERTIFICATE_EXPIRY_MINOR
• POLICY_CONNECTION_FAILURE

For more information about alerts, see Alerts section.

Maintain

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

In case the alert still persists, perform the following:

1. Collect the logs and Troubleshooting Scenarios: For more information on how to collect logs and troubleshooting information, see Oracle Communications Cloud Native Core, Converged Policy Troubleshooting Guide.
2. Raise a service request: See My Oracle Support for more information on how to raise a service request.

4.20.2 Support for TLS in Diameter Gateway

Policy uses Diameter Gateway to establish secured connections with consumer NFs and producer NFs, respectively. These communication protocols are encrypted using Transport Layer Security (TLS).

Enable

This feature is disabled by default. It can be enabled using TLS_ENABLED parameter using Helm configurations. For information about Helm configurations, see "Global Parameters" in Oracle Communications Cloud Native Core, Converged Policy Installation, Upgrade, and Fault Recovery Guide.

Configure

You can configure this feature using Helm. For information about Helm configurations, see "Global Parameters" in Oracle Communications Cloud Native Core, Converged Policy Installation, Upgrade, and Fault Recovery Guide.

Peer level support for TLS versions can be configured using CNC Console. For more information, see Peer Nodes section.

Observe

The following metrics are available for this feature:

• diam_conn_network
• diam_failed_conn_network
• diam_conn_network_responder
• dgw_tls_cert_expiration_seconds

For more information about metrics, see TLS Metrics section.

The following alerts are available for this feature:

• DGW_TLS_CONNECTION_FAILURE
• DIAM_GATEWAY_CERTIFICATE_EXPIRY_MINOR
• DIAM_GATEWAY_CERTIFICATE_EXPIRY_MAJOR
• DIAM_GATEWAY_CERTIFICATE_EXPIRY_CRITICAL

For more information about alerts, see Alerts section.

Following extensions are available for TLS in Diameter Gateway:

• status_request (0x0005)
• status_request_v2 (0x0011)
• supported_groups (0x000A)
• ec_point_formats (0x000B)
• extended_master_secret (0x0017)
• session_ticket (0x0023)
• signature_algorithms (0x000D)
• signature_algorithms_cert (0x0032)
• supported_versions (0x002B)
• psk_key_exchange_modes (0x002D)
• key_share (0x0033)
• renegotiation_info (0xFF01)

Maintain

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

In case the alert still persists, perform the following:

1. Collect the logs and Troubleshooting Scenarios: For more information on how to collect logs and troubleshooting information, see Oracle Communications Cloud Native Core, Binding Support Function Troubleshooting Guide.
2. Raise a service request: See My Oracle Support for more information on how to raise a service request.

4.21 Traffic Segregation

This feature provides end-to-end traffic segregation to Policy based on traffic types. Within a Kubernetes cluster, traffic segregation can divide applications or workloads into distinct sections such as OAM, SBI, Kubernetes control traffic, etc. The Multus CNI container network interface (CNI) plugin for Kubernetes enables attaching multiple network interfaces to pods to help segregate traffic from each Policy microservice.

This feature addresses the challenge of logically separating IP traffic of different profiles, which are typically handled through a single network (Kubernetes overlay). The new functionality ensures that critical networks are not cross-connected or sharing the same routes, thereby preventing network congestion.

With traffic segregation, operators can segregate traffic to external feeds and applications more effectively. Previously, all external traffic was routed through the same external network, but now, egress traffic from the Policy pods can be directed through non-default networks to third-party applications. This separation is achieved by leveraging cloud-native infrastructure and the load balancing algorithms in CNE.

The feature supports the configuration of separate networks, Network Attachment Definitions (NADs), and the Cloud Native Load Balancer (CNLB). These configurations are crucial for enabling cloud native load balancing, facilitating ingress-egress traffic separation, and optimizing load distribution within Policy.

Prerequisites

The CNLB feature is only available in Policy if CNE is installed with CNLB and Multus.

Cloud Native Load Balancer (CNLB)

CNE provides Cloud Native Load Balancer (CNLB) for managing the ingress and egress network as an alternate to the existing LBVM, lb-controller, and egress-controller solutions. You can enable or disable this feature only during a fresh CNE installation. When this feature is enabled, CNE automatically uses CNLB to control ingress traffic. To manage the egress traffic, you must preconfigure the egress network details in the cnlb.ini file before installing CNE.

Note:

CNLB is supported only for IPv4 stack.

For more information about enabling and configuring CNLB, see Oracle Communications Cloud Native Core, Cloud Native Environment User Guide, and Oracle Communications Cloud Native Core, Cloud Native Environment Installation, Upgrade, and Fault Recovery Guide.

Network Attachment Definitions for CNLB

A Network Attachment Definition (NAD) is a resource used to set up a network attachment, in this case, a secondary network interface to a pod. Policy supports two types of CNLB NADs:

1. Ingress Network Attachment Definitions

   Ingress NADs are used to handle inbound traffic only. This traffic enters the CNLB application through an external interface service IP address and is routed internally using interfaces within CNLB networks.

   • Naming Convention:nf-<service_network_name>-int
2. Egress Only Network Attachment Definitions

   Egress Only NADs enable outbound traffic only. An NF pod can initiate traffic and route it through a CNLB application, translating the source IP address to an external egress IP address. An egress NAD contains network information to create interfaces for NF pods and routes to external subnets.

   • Requirements: Destination (egress) subnet addresses are known beforehand and defined under the cnlb.ini file's egress_dest variable to generate NADs.
   • Naming Convention:nf-<service_network_name>-egr
3. Ingress/Egress Network Attachment Definitions

   Ingress/Egress Network Attachment Definitions enable inbound/outbound traffic. An NF pod can initiate traffic and route it through a CNLB app, translating source IP address to an external egress IP address (defined under cnlb.ini file egress_addr variable). An Ingress/Egress Network Attachment Definition contains network information to create interfaces for NF pods and routes to external subnets. Even though an Ingress/Egress Network Attachment Definition enables outbound traffic, it also handles inbound traffic, so if inbound/outbound traffic is needed an Ingress/Egress Network Attachment Definition should be used.

   • Requirements: Source (ingress) and destination (egress) subnet addresses are known beforehand and defined under cnlb.ini file egress_dest variable to generate Network Attachment Definitions.
   • Naming Convention:nf-<service_network_name>-ie

Managing Ingress and Egress Traffic Segregation

Enable:

This feature is disabled by default. To enable this feature, you must configure the network attachment annotations in the custom values file.

Configuration

For more information about Traffic Segregation configuration, see " Configuring Traffic Segregation" section in Oracle Communications Cloud Native Core, Converged Policy Installation, Upgrade, and Fault Recovery Guide..

Observe

There are no Metrics, KPIs, or Alerts available for this feature.

Maintain

To resolve any alerts at the system or application level, see Alerts section. If the alerts persist, perform the following:

1. Collect the logs: For more information on how to collect logs, see Oracle Communications Cloud Native Core, Converged Policy Troubleshooting Guide.
2. Raise a service request: See My Oracle Support for more information on how to raise a service request.

4.22 Support for Prevention of Requests Accumulation at Undertow Worker Queue

Prevention of Requests Accumulation at Undertow Worker Queue

The Congestion Control feature helps in pod protection during congestion state by rejecting the incoming requests based on their discard and request priorities. The request rejection are done by XNIO task threads. But during traffic bursts it is possible that XNIO task threads may get blocked. Due to this the rejection of requests because of pod congestion feature may not work resulting in requests accumulation in undertow worker queue. Since the undertow worker queue is unbounded and the lot of requests have accumulated in its queue the pod may crash or restart due to out of memory issue.

The Undertow Queue Request Limiter functionality helps to handle this issue. The queue request limiter checks the undertow worker queue size, and if this size is greater than or equal to maximum acceptable size it starts rejecting the requests based on the configured discard priority and message priority. If the message priority is less than discard priority then that request is accepted,if not it will be rejected.

Currently this functionality is supported in SM, PDS, Binding, Bulwark, UDR Connector, and CHF-Connector services. By default, this functionality is disabled for all of these services. The Users can enable this functionality, and also can customize the maxAcceptRequestCount size and discardPriority by adding the following parameters in custom values.yaml file for SM, PDS, Binding, Bulwark, UDR Connector, and CHF Connector services. Here is a sample Helm configuration for PDS service:

policyds:
  serverHttpEnableBlockingReadTimeout: true
  undertow:
    queueRequestLimiter:
      enable: true
      discardPriority: 0
      maxAcceptRequestCount: 5000

Here is a sample Helm configurations for UDR and CHF Connector services:

user-service:
  serverHttpEnableBlockingReadTimeout: true
  UDR:
    undertow:
     queueRequestLimiter:
        enable: false
        maxAcceptRequestCount: 5000
        discardPriority: 0
  CHF:
    undertow:
      queueRequestLimiter:
        enable: false
        maxAcceptRequestCount: 5000
        discardPriority: 0

Note:

On enabling Undertow queueRequestLimiter, the requests are rejected without even passing to the Undertow worker queue and hence no application logic will be executed.

Managing Prevention of Requests Accumulation at Undertow Worker Queue

Enable

By default, this feature is disabled for the supported Policy services. You can enable this feature using helm parameters in custom values.yaml file.

For more information on Helm parameters, see "Configurations Parameters for Undertow Server Queue" section in Oracle Communications Cloud Native Core, Converged Policy Installation, Upgrade and Fault Recovery Guide.

Observability

Metrics:

The following metrics are used to provide information about this feature:

• undertow_queue_limiter_request
• occnp_undertow_queue_request_limiter_active_threads_count

For information about the metrics, see Undertow Server Metrics.

4.23 Support for Optimizing Database Encoding in PCRF Core

This feature aims to optimize encoding and decoding the database fields of PCRF Cores services to reduce the size of data transferred during replication and improve the performance in the call flows.

PCRF Core stores and transfers the data in Java Script Object Notation (JSON) object. In JSON object the key/name describes the value, and the value is the actual data. At present, the PCRF Core JSON objects stored in the database is overly verbose, redundant keys and repetitive structures has increased the data size, causing longer data transfer times during replication.

The feature is implemented by:

• a data encoding technique that shortens all the overly verbose attribute names, and uses a mapping table that holds the long and short names.
• a data encoding technique that shortens all the overly verbose constants or default or enumeration attribute values, and uses a mapping table that holds the long and short values.
• to remove all unused and irrelevant JSON attributes from the value columns in gxsession, rxsession, sdsession tables.

Shorten JSON Attribute Keys

In the data encoding technique, every time before a record is stored in the gxsession, rxsession, sdsession tables it is encoded by mapping long attribute names to short names; when the same record is retrieved it is decoded by converting the short attribute names to its original long names.

For example: "eventReportIndicationTriggerMask" shorten as "eRITM"

Shorten JSON Attribute Values

In the data encoding technique, JSON attribute containing longer fixed or default or enumeration values are mapped to shorter values.

For example:

geographicLocationField": {"type": "PCRFDiameterTrackingAreaEUTRANCellGlobalIdentifierImpl"

In the above example, the different values that "type" key can take and its mapping is shown below:

"PCRFDiameterTrackingAreaEUTRANCellGlobalIdentifierImpl",  we can map it to "PDTAE";
"PCRFDiameterTrackingAreaIdentifierImpl", we can map it to "PDTAI";
"PCRFDiameterTrackingUpdateImpl", we can map it to "PDUI"

In PCRF Core services following Advanced keys are added to implement this feature:

• DB.GX.DATA.ENCODING.Enabled
• DB.RX.DATA.ENCODING.Enabled
• DB.SD.DATA.ENCODING.Enabled
• DB.GX.ENCODING.MAP.Version
• DB.RX.ENCODING.MAP.Version
• DB.SD.ENCODING.MAP.Version
• DB.ENCODING.MAP.LIST

Managing Support for Optimizing Database Encoding in PCRF Core

Enable

By default, this feature is disabled for PCRF Core service. You can enable this feature for gxsession, rxsession and rdsession using CNC Console.

Configure

To enable the feature using CNC Console, add the following Advanced Settings keys in the PCRF Core services and set their respective values to true:

• DB.GX.DATA.ENCODING.Enabled
• DB.RX.DATA.ENCODING.Enabled
• DB.SD.DATA.ENCODING.Enabled

For more information about the configurations, see PCRF Core Settings

Observability

Metrics

The following metrics are added to provide information about this feature:

• occnp_data_encoding_total
• occnp_data_decoding_total
• occnp_data_decoding_fail_total
• occnp_data_encoding_size_before_total
• occnp_data_encoding_size_after_total

For information about the metrics, see PCRF Core Metrics section.

4.24 Support for policyDecFailureReports Attribute

Policy Decision Error Handling is one of the 3GPP-defined features responsible for enabing the policyDecFailureReports attribute.

If the Policy Decision Error Handling is supported and the SMF receives one or more policy decisions and/or condition data which are not referred by any PCC rules or session rules as defined in 3GPP but the storage of the policy decisions and/or condition data was unsuccessful , the SMF behaves as follows:

• When the PCF receives update notify response or SM Update request, it considers all the instances of the policy decisions and/or condition data which are provisioned in the request message as removed from the SMF.
• When the PCF receives the response with HTTP "400 Bad Request" status code but the "policyDecFailureReports" attribute is not included, the PCF considers the request message as removed from the SMF.

The PCF does not remove the PCC rule in case the updatenotify request for rule remove failure. With introduction of the new flag RULE.ENABLE_PCC_RULE_REMOVE_ON_FAILURE set to true and if rule remove updatenotify request fails with "400 BAD Request" HTTP error, the association will be updated with PCC rule removed.

Note:

If SMF responds with 200 error code and policyDecFailureReport includes the policyDecisionFailureCode for which the policy decision object were not sent will also be processed by PCF and the available policy decision object will be removed. Moreover, if SMF responds with 400 error code and policyDecFailureReport includes the policyDecisionFailureCode for which the policy decision object were not sent, then policy decision objects which were part of update notify request will be removed.

Managing Support for policyDecFailureReports Attribute

Enable and Configure

By default, this feature is not configured on the CNC Policy deployment. You can opt to configure the policyDecFailureReports attribute using the following ways in CNC Console.

• From the navigation menu under Policy, navigate to Service Configurations to select PolicyDecisionErrorHandling from the drop-down menu of Override Supported Features parameter.
• From the navigation menu under Policy, navigate to Service Configurations to add RULE.ENABLE_PCC_RULE_REMOVE_ON_FAILURE key in the Advanced Settings.

For more information about these configurations, see PCF Session Management.

Observe

The occnp_feature_info_received_total metric is is used to support policyDecFailureReports attribute. For more information, see SM Service Metrics.

4.25 Enhancements to Error Response

Policy sends error responses to consumer NFs due to some exceptions, such as signaling, validations, and internal errors. These error responses have payloads containing the problem title, status, details, and cause of the error that are used to investigate the error. The details section is now enhanced with application error IDs.

The error handling module gives provision to configure the error response dynamically and the same is responded when Policy is producer of the call flow.

With the enhanced error response mechanism, Policy sends additional information such as server FQDN, micro-service ID, error category, and application error ID in the detail attribute of the ProblemDetails. This enhancement provides more information about the error and troubleshoot them.

Note:

As per the definition of ProblemDetails data type in 3GPP, the title and cause fields are optional and can be null or empty.

Application error ID follows the below format.

[ EC] [NF ID] [Microservice ID] [Category] [Error ID]

An error code dictionary will be provided to identify the cause and possible solution of the error. For more details of the error code dictionaries for AM, UE, SM, UDR, CHF, and Binding services, see Error Code Dictionary.

Managing Enhancements to Error Response

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

Enable

By default, this feature is disabled. The operator can enable this feature through the CNC Console configurations.

Configure

You can configure error handling functionality under Error Handling on CNC Console for Policy. For information about how to configure for AM, UE, SM, UDR, CHF, and Binding services in CNC Console, see Error Handling.

Observe

The following metrics have been added in AM, UE, SM, Binding, and User service (UDR and CHF) for this feature:

• error_handler_exec_total
• error_handler_in_total
• error_handler_out_total

For more information, see CNC Policy Metrics.

4.26 OAuth Access Token Based Authorization

OAuth (Open Authorization) 2.0 an authorization protocol, allows a application to access resources hosted by other API applications on behalf of a user. OAuth provides an authentication layer and separates the role of client from that of the resource owner. On client requests access to resources controlled by the resource owner and hosted by the resource server, OAuth issues Access Tokens, a different set of credentials than those of the resource owner. An Access Token is a string that represents the authorization to access resources on behalf of the end user.

Policy supports OAuth 2.0 to authorize requests coming from consumer NFs. Policy application issues the Access Token as JSON Web Token (JWT). This enables Policy, the token issuer to include authorization data in the token itself. The consumer NF requests for Access Token from the issuer Policy, and sends them as part of its requests to Policy. Policy validates the requests and either approves or discards based on Access Token authorization received in the request.

The Access Token is validated with the configured public key certificate in Policy. Policy uses NRF Instance ID to validate the Access Token, where Ingress Gateway stored public keys against NRF instance Id. Policy also uses multiple public certificates for validating Access Tokens by adding support for Key-ID (K-ID) based access token validation, in addition to the existing NRF Instance ID based access token validation.

Ingress Gateway operates in the following three different OAuth Validation Modes:

• INSTANCEID_ONLY : This is the default OAuth Validation Mode used by Ingress Gateway. Ingress Gateway validates access token based on public keys indexed with NRF Instance ID in the issuer field.
• K-ID based ONLY: Ingress Gateway validates Access Token based on public keys indexed with key-id only.
• KID_PREFERRED (K-ID based with Instance ID based as fallback):
  • Ingress Gateway validates Access Token based on public keys indexed with Key-ID. If Key-ID is not FOUND in Access Token, Ingress Gateway attempts token validation using public keys indexed with NRF instance ID in the issuer field.
  • Fallback happens only if the received access token does not contain Key-ID or contains Key-ID but without public key configurations.

Note:

• For more information on OAuth client functionality, see "OAuth Authentication and Validation" section in Oracle Communications Cloud Native Core, Egress Gateway User Guide.
• For more information on OAuth validator functionality, see "Ingress Gateway Open Authorization (OAuth) Module" section in Oracle Communications Cloud Native Core, Ingress Gateway User Guide.
• For more information on parameters and their supported values in Policy, see OAUTH Configuration section in Oracle Communications Cloud Native Core, Converged Policy Installation, Upgrade and Fault Recovery Guide.
• For information about OAuth access token attributes like kid, typ, iss, aud, scope etc., see https://www.rfc-editor.org/rfc/rfc7515.html page.

Managing OAuth Access Token Based Authorization

Token based Authorization Using Key-ID and NRF Instance ID

For configurations required to enable Access Tokens before deploying Policy, see "Configuring Secrets to Enable Access Token " section in Oracle Communications Cloud Native Core, Converged Policy Installation, Upgrade and Fault Recovery Guide .

Configure

To enable access token validation, configure both Helm-based and REST-based configurations on Ingress Gateway.

Configure Using Helm Configuration

For Helm configurations, see "OAUTH Configuration" section in Oracle Communications Cloud Native Core, Converged Policy Installation, Upgrade and Fault Recovery Guide .

REST API Configuration

After the Helm configuration, send the REST requests to use configured public key certificates. For more information about REST API configuration, see "OAuth Validator REST API Configuration" section in Oracle Communications Cloud Native Core, Converged Policy REST API Specification Guide.

Observability

Metrics

For information on Metrics, see "Oauth Metrics" section in Egress Gateway Metrics.

4.27 Support for End-to-End Log Identifier Across Policy Services

Without a unique end-to-end log identifier, it is difficult to debug use cases where the problem can be at any microservice level.

This feature includes a unique end-to-end identifier to every log message, which can be used to identify the set of logs belonging to a given call flow across all the microservices. For example, a end-to-end log identifier is used across all microservices in an SM Create call flow. Similarly, end-to-end log identifiers used in an SM Update, SM Delete, SM Notify call flows across microservices involved in the flow. This end-to-end log identifier called ocLogId is included in the metadata of every log. the same identifier is used across all the microservices so that logs can be mapped between microservices. Also, a common identifier is used to track a user per microservice.

This feature supports the following call flow for Policy microservices:

• SM Create
• SM Update
• SM Delete
• SM Notify
• SM Rx call flow
• SM Rx RAR call flow
• SM Rx STR call flow
• AM Create
• AM Update
• AM Delete
• AM Notify
• UE Create
• UE Update
• UE Delete
• UE Notify
• AMF discovery for UE Create
• AMF discovery for UE Update
• NRF discovery for Alternate Route Retry call flow
• Binding service call flow for stale session detection
• Audit call flow using Audit service
• Sy interface
• Sd interface
• PCRF callflows passing through the following interfaces:
  • PCRF Core Gx interface
  • Pcrf core Rx
  • N36 interface to interact with UDR
• Audit callflows for PCRF Core
• PCRF Core interaction with Bulwark service
• PCRF Core binding callflows
• Notifier service
• Usage mon service
• Soap Connector

Separate log identifiers are created in every georedundancy site. That is, every site creates its own identifier and log the same.

Note:

Currently, only Ingress Gateway and Diameter Gateway services can generate ocLogId (when a request from an external NF arrives) and Audit when sending a notification. As a result, there are certain flows and services that are not part of the reception, addition to log metadata and propagation of ocLogId and for which Log Correlation is not ensured. Some of these unsupported services and flows worth to mention are the following:

The following are some of those services for which this feature is not supported:

• Configuration Flows: Configuration flows for each service are not supported as these involve only the services for which configuration is changed and the services where the configuration was added through.
• Config Service: Config service is not supported as the configuration is either changed or the configuration is add through.
• Base Diameter Messages as CER/A and DWR/A. ocLogId will not be generated or propagated.
• CMService: Log Correlation is not supported and CMservice can not generate ocLogId. Any flow that was originated by CMService is not supported, including configuration and session viewer flows.
• Query Service: Query service is not supported. This service can not receive or propagate ocLogId.
• LDAP-Gateway
• Alternate Route Service

If any of the supported services receive requests originated or coming from any of the not yet supported ones, directly or indirectly, ocLogId is not ensured to be received as the propagation through any valid mechanism might be yet implemented.

End-to-end log identifier at different services

The Ingress Gateway creates the ocLogId and adds the same in each log that is generated.

The Ingress Gateway passes the ocLogId in the header to Policy microservice such as SM service.

Note:

For SM Rx call flows (AAR and STR), the ocLogId is generated by Diameter Gateway instead of Ingress gateway.

When Audit service sends a notification to the other services, the ocLogId is generated by Audit service

Logging by SM service

• When SM service receives the ocLogId from Ingress Gateway, it uses the ocLogId while generating the logs. This information is included as part of all the log levels.
• SM service in turn passes the identifier to other backend services such as PRE, PDS, Egress Gateway, Bulwark, and Binding service.
• When SM service receives the ocLogId for the notification from Audit service, they log the messages with ocLogId.
• When SM service receives the ocLogId for the notification from PDS Service or Binding Service, they log the messages with ocLogId.
• When SM service receives the ocLogId from Diameter Connector for Rx call flow, it uses the ocLogId while generating the logs. This information is included as part of all the log levels.
• SM service in turn passes the identifier as header to other backend services.

Logging by AM service

• When AM service receives the ocLogId from Ingress Gateway, it uses the ocLogId while generating the logs. This information is included as part of all the log levels.
• AM service in turn passes the identifier to other backend services such as PRE, PDS, Egress Gateway, and NRF Client.
• When AM service receives the ocLogId for the notification from Audit service, they log the messages with ocLogId.
• When AM service receives the ocLogId for the notification from PDS service or Binding Service, it logs the messages with ocLogId.

Logging by UE Policy service

• When UE Policy service receives the ocLogId from Ingress Gateway, it uses the ocLogId while generating the logs. This information is included as part of all the log levels.
• UE Policy service in turn passes the identifier to other backend services such as PRE, PDS, Egress Gateway, and NRF Client.
• When UE Policy service receives the ocLogId for the notification from Audit service, they log the messages with ocLogId.
• When UE Policy service receives the ocLogId for the notification from PDS service or Binding Service, it logs the messages with ocLogId.

Logging at PDS

• When PDS receives the ocLogId from SM service, AM service, or UE Policy service, it uses the ocLogId while generating the logs.
• PDS passes this ocLogId as the header to the backend services such as UDR Connector, CHF Connector, LDAP, Diameter Gateway, Diameter Connector.
• When PDS receives the ocLogId for the notification from UDR Connector, CHF Connector, Diameter Gateway, Diameter Connector, or Audit service, PDS logs the messages with ocLogId.
• PDS passes the ocLogId as the header to Policy services such as SM service, AM service, or UE Policy service, while sending the notification. PDS uses the ocLogId saved in the context and does not generate any new identifier.

  Note:

  Only when PDS receives a notification from CHF or UDR, a new ocLogId gets created.

Logging at UDR Connector

• When UDR Connector receives the ocLogId from PDS, it uses the ocLogId while generating the logs.
• UDR Connector passes this ocLogId as the header to the backend services such as Egress Gateway.
• When UDR Connector receives the ocLogId for the notification from Ingress Gateway, it logs the messages with ocLogId.

Logging at CHF Connector

• When CHF Connector receives the ocLogId from PDS, it uses the ocLogId while generating the logs.
• CHF Connector passes the ocLogId as the header to the backend service such as Egress Gateway.
• When CHF Connector receives the ocLogId for the notification from Ingress Gateway, it logs the messages with ocLogId.

Logging at Egress Gateway

When Egress Gateway receives the ocLogId from SM service, CHF Connector, UDR Connector, AM service, or UE Policy service, it uses the ocLogId while generating the logs.

Logging at Audit service

• When Audit service detects a possible stale session, audit service generates the ocLogId.
• Audit service includes the ocLogId in the header and sends it to SM service, AM service, UE Policy service, PDS, and Binding service.

Logging at Binding service

• When Binding service receives the ocLogId for the SM service or Audit service, it logs the messages with ocLogId.
• Also, Binding service receives the ocLogId when BSF sends a request to check if a PcfBinding is still valid or not.

Logging at Diameter Gateway

• Diameter Gateway generates the ocLogId and includes it in all the messages for all the Gx, Rx, and Sd flows coming from external NFs.
• Diameter Gateway uses the ocLogId while generating the logs.
• Diameter Gateway sends the ocLogId as headers/AVP to the backend services such as Diameter Connector and Binding service.

Logging at Diameter Connector

• When Diameter Connector receives the ocLogId from Diameter Gateway, it logs the messages with ocLogId.
• Diameter Connector sends the ocLogId as header to the backend services such as SM service.

Logging at PRE

• When PRE receives the ocLogID from SM service, AM service, UE Policy service, or PDS, it uses the ocLogId while generating the logs.
• PRE sends the ocLogId as headers/AVP to the backend service.

Logging at Bulwark service

When Bulwark service receives the ocLogID from SM service, it uses the ocLogId while generating the logs.

Logging at NRF Client

• When NRF Client receives the ocLogId from AM service or UE Policy service, it logs the messages with ocLogId.
• NRF Client sends the ocLogId as headers to the backend services.
• When there is a request initiated by NRF Client (not something from UE or AM) NRF creates the ocLogId by itself and sends it to the subsequent services.

Logging at PCRF Core

• When PCRF Core receives the ocLogId from Diameter Gateway, it uses the ocLogId while generating the logs.
• When PCRF Core service receives the ocLogId for the notification from PDS, Audit Service, or Usage Monitoring service, it logs the messages with ocLogId.
• PCRF Core service sends the ocLogId as headers/AVP to the backend service such as Usage Monitoring service and PRE.

Logging at Notifier service

Notifier service uses the ocLogId while generating the logs.

Logging at Usage Monitoring service

• When Usage Monitoring service receives the ocLogId from PCRF Core, it logs the messages with ocLogId.
• Usage Monitoring service sends the ocLogId as headers/AVP to the backend service such as PDS.
• Usage Monitoring service sends the ocLogId as headers/AVP as the notification to PCRF Core.

Figure 4-56 Example: Unique Identifier for SM Create Call Flow

1. Ingress Gateway receives SM session create request from SMF. Ingress Gateway generates the ocLogId and passes the ocLogId in the header to SM service.
2. SM service sends a Get request to PDS to get the SMAssociation details and uses the ocLogId while generating the logs.
3. PDS sends the query to User Service (UDR Connector, CHF Connector). PDS uses the ocLogId while generating the logs. Also, PDS passes this ocLogId as the header to the backend services such as UDR Connector and CHF Connector.
4. UDR Connector inturn forwards the request to UDR through Egress Gateway. UDR Connector uses the ocLogId while generating the logs. Also, it passes the ocLogId as a header to Egress Gateway.
5. UDR responds to the request with the SM Policy data.
6. User service then sends a request to UDR for the subscription through Egress Gateway. The logs generated at Egress Gateway are saved with ocLogId.
7. UDR responds with the subscription details. UDR Connector forwards the subscription details to SM service and logs the transaction with ocLogId.
8. SM service interacts with PRE for Policy evaluation. PRE uses the ocLogId while generating the logs.
9. SM service sends a session binding request with BSF and includes the ocLogId in the header. The session binding request containing ocLodId is sent to BSF through Egress Gateway.
10. SM service receives the response to session binding request from BSF through Ingress Gateway. SM service updates the details in SMAssociation database and logs the transaction with ocLogId.

Managing the End-to-End Log Identifier across Policy Services

TRACE_ID_GENERATION_ENABLED Helm parameter is used to enable or disable the addition of the end-to-end identifier through Ingress Gateway. This same flag is also present in Diameter Gateway, Audit service, and NRF Client.

By default, TRACE_ID_GENERATION_ENABLED is enabled.

Audit service uses it when initiating a stale session notification.

Diameter Gateway uses the Helm parameter to decide ocLogId generation for all the Gx, Rx, and Sd flows.

NRF Client uses it when initiating a request by its own (a request that was not received from other services).

By default, the value this parameter is set to true and the feature is enabled.

When this feature is enabled, Ingress Gateway generates the ocLogId and propagates the headers to the succeeding microservices, Audit service, Diameter Gateway, NRF Client.

Ingress Gateway passes the ocLogId generated as the header and sends the same to other Policy microservices such as SM service, AM service, or UE Policy service.

4.28 Support for Automated Certificate Lifecycle Management

Public Key Interface (PKI) is the set of elements such as public/private keys, certificate signing request, and certificates that are required to handle secure communications and transactions. Policy uses secure protocols for its communications, such as HTTPS and Secure Socket Layer (SSL) / Transport Layer Security (TLS) technologies to handle these secure communications. This is achieved with the use of Public and Private Keys, and the presence of trusted authorities, also known as Certificate Authorities (CA), which create and issue certificates. These certificates have a determined validity period. These certificates must be renewed before expiry. They can also be revoked when the CA or its keys are compromised. These certificates must be recreated when required.

This feature enables Policy to support automation of certificate lifecycle management in integration with Oracle Communications Certificate Manager (OCCM).

OCCM provides the option to automatically create, renew, and delete certificates for a given CA, with the possibility to track previously created certificates and renew/delete them when required.

The certificate lifecycle management includes:

• Certificate Creation,
• Certificate Deletion,
• Certificate Monitoring (including the ones that were created using a different tool from OCCM),
• Certificate Renewal.

Note:

OCCM do not support OAuth token generation and distribution (currently handled by NRF) used for SBI signalling.

Figure 4-57 Policy Integration with OCCM

There is no direct communication between OCCM and Policy. All the communications are handled using monitoring Kubernetes Secrets.

All the required certificates are configured using OCCM.

After OCCM creates these Kubernetes Secrets, or monitors the already existing ones, the Ingress and Egress Gateways monitor these Secrets and keep track of their current status:

• VALID: A Kubernetes Secret which holds a certificate that has not expired and it is properly signed,
• EXPIRED: A Kubernetes Secret which holds a certificate that has met its expiration date (the value determined in its notAfter value),
• MISSING: A Kubernetes Secret which has its certificate missing, or any other essential file for the TLS/SSL bundle.
• CORRUPT: A Kubernetes Secret which has its certificate corrupt, either invalid file, invalid signature, or invalid format.

Managing the keys and certificates

Install Guide Considerations

• Upgrade: When Policy is deployed with OCCM, follow the specific upgrade sequence as mentioned in the Oracle Communications, Cloud Native Core Solution Upgrade Guide.
• Rollback: You can remove Kubernetes secrets if the current version of Policy does not use that secret by checking the occnp_custom_values.yaml file. Before deleting, please make sure that there is no plan to rollback to the Policy version which uses these secrets. Otherwise Rollback will fail. For more information on migrating the secrets from Policy to OCCM and removal of Kubernetes secrets from the yaml file, see Upgrade Strategy in Oracle Communications Cloud Native Core, Converged Policy Installation, Upgrade, and Fault Recovery Guide.

Configure

To configure HTTPS in ingress-gateway, the following parameters must be configured in custom-value.yaml file in the ingress-gateway section:

• ingress-gateway.enableIncomingHttps
• ingress-gateway.service.ssl.privateKey.k8SecretName
• ingress-gateway.service.ssl.privateKey.k8NameSpace
• ingress-gateway.service.ssl.privateKey.rsa.fileName
• ingress-gateway.service.ssl.certificate.k8SecretName
• ingress-gateway.service.ssl.certificate.k8NameSpace
• ingress-gateway.service.ssl.certificate.rsa.fileName
• ingress-gateway.service.ssl.caBundle.k8SecretName
• ingress-gateway.service.ssl.caBundle.k8NameSpace
• ingress-gateway.service.ssl.caBundle.fileName
• ingress-gateway.service.ssl.keyStorePassword.k8SecretName
• ingress-gateway.service.ssl.keyStorePassword.k8NameSpace
• ingress-gateway.service.ssl.keyStorePassword.fileName
• ingress-gateway.service.ssl.trustStorePassword.k8SecretName
• ingress-gateway.service.ssl.trustStorePassword.k8NameSpace
• ingress-gateway.service.ssl.trustStorePassword.fileName

For more information, see Basic Configurations in Ingress Gateway section in Oracle Communications Cloud Native Core, Converged Policy Installation, Upgrade, and Fault Recovery Guide.

To configure HTTPS in egress-gateway, configure the following parameters under egress-gateway section in custom-value.yaml file:

• egress-gateway.enableOutgoingHttps
• egress-gateway.egressGwCertReloadEnabled
• egress-gateway.egressGwCertReloadPath
• egress-gateway.service.ssl.privateKey.k8SecretName
• egress-gateway.service.ssl.privateKey.k8NameSpace
• egress-gateway.service.ssl.privateKey.rsa.fileName
• egress-gateway.service.ssl.privateKey.ecdsa.fileName
• egress-gateway.service.ssl.certificate.k8SecretName
• egress-gateway.service.ssl.certificate.k8NameSpace
• egress-gateway.service.ssl.certificate.rsa.fileName
• egress-gateway.service.ssl.certificate.ecdsa.fileName
• egress-gateway.service.ssl.caBundle.k8SecretName
• egress-gateway.service.ssl.caBundle.k8NameSpace
• egress-gateway.service.ssl.caBundle.fileName
• egress-gateway.service.ssl.keyStorePassword.k8SecretName
• egress-gateway.service.ssl.keyStorePassword.k8NameSpace
• egress-gateway.service.ssl.keyStorePassword.fileName
• egress-gateway.service.ssl.trustStorePassword.k8SecretName
• egress-gateway.service.ssl.trustStorePassword.k8NameSpace
• egress-gateway.service.ssl.trustStorePassword.fileName

For more information, see Basic Configurations in Egress Gateway section in Oracle Communications Cloud Native Core, Converged Policy Installation, Upgrade, and Fault Recovery Guide.

Observability

Monitoring the keys and certificates

Policy supports monitoring and automatic renewal of its' TLS certificates in integration with OCCM.

It is validated that the renewed certificate and key are picked up for any new TLS connections.

Also, the existing TLS connections using the previous key and certificate are gracefully brought down.

Clean up of the certificates are also handled through OCCM.

For information about enabling HTTPS, see Configuring Secrets for Enabling HTTPS in Oracle Communications Cloud Native Core, Converged Policy Installation, Upgrade, and Fault Recovery Guide.

.

Metrics

The oc_certificatemanagement_tls_certificate_info metric is used to support automated certificate lifecycle management.

For more information, see Metrics for Automated Certificate Lifecycle Management.

4.29 Support for Handling Requests From Reduced Capability Devices

Policy supports handling the requests from reduced capability devices (RedCap) to support IoT ecosystem.

RedCap is a device class that is designed to provide a cost-effective way to connect devices that do not require the full capabilities of the 5G system. It reduces device complexity through fewer RX or TX antennas, lesser bandwidth requirement, lower power consumption, relaxed data rates, relaxed processing time and processing capability to support some exciting use cases, primarily around industrial wireless sensors, video surveillance and wearables.

Policy identifies the incoming request from the RedCap devices based on the NR_REDCAP enumerated value in the request that indicates NR RedCap RAT Type.

Based on this value, interactions with PRE are performed to make appropriate decisions for the reduced capability UEs.

Note:

Policy supports policy decisions on NR RedCap RAT Type for:

• create, update, update notify, and delete message for SM service
• create message for AM service and UE Policy service

Support for NR_REDCAP value for RAT Type over Rx Interface

PCF supports voice and video calls by reduced capability on Voice over Long-Term Evolution (VoLTE) and Voice over New Radio (VoNR).

For this purpose, PCF establishes binding sessions with BSF and supports Rx diameter procedures for these sessions for RedCap devices by sending RatType attribute with NR_REDCAP value to BSF, P-CSCF in AAA and RAR.

When an Rx session is established upon receiving a AAR-I for a RedCap device, if Redcap Support for Rx Interface field on Diameter Connector page under General section in CNC console is enabled and the RAT Type is NR_REDCAP, PCF sends a AAA message to P-CSCF containing RATType AVP with value NR_REDCAP.

For more information on configuring Redcap Support for Rx Interface field, see Diameter Connector.

When PCF receives SM Update Request from SMF and if policy control request trigger conditions are met or the event occurs, for which P-CSCF has subscribed (that is, IP-CAN type change Notification and RATType has changed for the device), if Redcap Support for Rx Interface field is enabled and RATType is NR_REDCAP, PCF sends a RAR message to P-CSCF containing RATType AVP with value NR_REDCAP.

The AAA and RAR messages for the PDU sessions are sent through Diameter Connector service and Diameter Gateway to BSF containing RATType AVP with value NR_REDCAP.

Note:

When Redcap Support for Rx Interface field is disabled and Rx session is established for the RedCap devices, PCF accepts the session and sends AAA success without RATType.

Managing the Support for RedCap Devices

Enable

To enable support for reduced capability devices, configure value of RatType block under Policy Projects in CNC Console to NR_REDCAP.

For more information on the RatType block, see PCF UE Policy section in Oracle Communications Cloud Native Core, Converged Policy Design Guide.

To enable support for NR_REDCAP value for RAT Type over Rx interface

You can enable the support for NR_REDCAP value for a RAT Type over Rx interface using CNC Console as well as using REST API.

Enable using CNC console

To enable support for NR_REDCAP value in RATType AVP, configure Redcap Support for Rx Interface field under General section on Diameter Connector page for Service Configurations in CNC Console.

For more information, see Diameter Connector.

Enable using REST API

To enable support for NR_REDCAP value in RATType AVP, configure ratTypeNRRedCapEnabled parameter for Diameter Connector API.

For more information, see Diameter Connector section in Oracle Communications Cloud Native Core, Converged Policy REST Specification Guide..

Installation and Upgrade Impact

The feature configuration using Redcap Support for Rx Interface field under Diameter Connector page for Service Configurations will be available in CNC Console for Policy only after installing or upgrading to Policy 25.1.200 or later versions.

Note:

• This feature does not involve any change to the context data for SM service.
• This feature does not involve any change to Policy evaluation.
• This feature must be enabled only after all the sites in the mated region are upgraded.

Observability

Metrics

The diam_avp_dropped metric is used to support voice and video calls by reduced capability devices on Voice over Long-Term Evolution (VoLTE) and Voice over New Radio (VoNR) feature.

Note:

The diam_avp_dropped metric is pegged only when the flag is disabled, and still, SM service sends the NR_REDCAP value in RATType AVP to the Diameter Connector service when sending AAA and RAR messages.

For more information, see Diameter Connector Service Metrics.

Logging

Following is a sample log that can be used to troubleshoot problems with supporting voice or video calls by RedCap devices in VoLTE or VoNR.

{
  "instant": {
    "epochSecond": 1738745556,
    "nanoOfSecond": 301226519
  },
  "thread": "boundedElastic-2",
  "level": "DEBUG",
  "loggerName": "ocpm.diameter.DiameterIncident",
  "message": "Peer oc-diam-gateway(TCP 10.233.109.20:32804 10.233.116.94:3868): Sent message(AAA): \nDiameter Message: AAA\nVersion: 1\nMsg Length: 232\nCmd Flags: PXY\nCmd Code: 265\nApp-Id: 16777236\nHop-By-Hop-Id: 4028189085\nEnd-To-End-Id: 3779477398\n  Session-Id (263,M,l=10) = s4\n  Origin-Host (264,M,l=13) = ocpcf\n  Origin-Realm (296,M,l=18) = xxx.com\n  Auth-Application-Id (258,M,l=12) = 16777236\n  Result-Code (268,M,l=12) = DIAMETER_SUCCESS (2001)\n  IP-CAN-Type (1027,VM,v=10415,l=16) = THREEGPP_5GS (8)\n  RAT-Type (1032,V,v=10415,l=16) = NR_REDCAP (1039)\n  Supported-Features (628,V,v=10415,l=56) = \n    Feature-List-ID (629,V,v=10415,l=16) = 1\n    Vendor-Id (266,M,l=12) = 10415\n    Feature-List (630,V,v=10415,l=16) = 16\n  Oc-Log-Id (6668,V,v=21274,l=52) = 1738745555727_1_policy-oc-diam-gateway-0\n[1, 0, 0, -24, 64, 0, 1, 9, 1, 0, 0, 20, -16, 25, 73, -99, -31, 70, 63, -106, 0, 0, 1, 7, 64, 0, 0, 10, 115, 52, 0, 0, 0, 0, 1, 8, 64, 0, 0, 13, 111, 99, 112, 99, 102, 0, 0, 0, 0, 0, 1, 40, 64, 0, 0, 18, 111, 114, 97, 99, 108, 101, 46, 99, 111, 109, 0, 0, 0, 0, 1, 2, 64, 0, 0, 12, 1, 0, 0, 20, 0, 0, 1, 12, 64, 0, 0, 12, 0, 0, 7, -47, 0, 0, 4, 3, -64, 0, 0, 16, 0, 0, 40, -81, 0, 0, 0, 8, 0, 0, 4, 8, -128, 0, 0, 16, 0, 0, 40, -81, 0, 0, 4, 15, 0, 0, 2, 116, -128, 0, 0, 56, 0, 0, 40, -81, 0, 0, 2, 117, -128, 0, 0, 16, 0, 0, 40, -81, 0, 0, 0, 1, 0, 0, 1, 10, 64, 0, 0, 12, 0, 0, 40, -81, 0, 0, 2, 118, -128, 0, 0, 16, 0, 0, 40, -81, 0, 0, 0, 16, 0, 0, 26, 12, -128, 0, 0, 52, 0, 0, 83, 26, 49, 55, 51, 56, 55, 52, 53, 53, 53, 53, 55, 50, 55, 95, 49, 95, 112, 111, 108, 105, 99, 121, 45, 111, 99, 45, 100, 105, 97, 109, 45, 103, 97, 116, 101, 119, 97, 121, 45, 48]",
  "endOfBatch": false,
  "loggerFqcn": "org.apache.logging.slf4j.Log4jLogger",
  "threadId": 106,
  "threadPriority": 5,
  "messageTimestamp": "2025-02-05T08:52:36.301+0000",
  "ocLogId": "1738745555727_1_policy-oc-diam-gateway-0"
}

4.30 PCF Support for ME-XX String in Server Header from CHF

When PCF communicates with other NFs, it makes use of a header called server, as defined in 3GPP. PCF uses these header is used by PCF to make decisions on retry strategies when receiving error responses. The header contains the instance or instances that generated the error. Based on the standard defined in 3GPP, the instance(s) inserted in the header must follow the following pattern: "<NFType>-<NF Instance ID>" for an NF, where

• <NF Type> is the type of the NF or network entity generating the error, set to the NFType value as defined in 3GPP.
• <NF Instance ID> is the identity of the NF or network entity generating the error, set to the FQDN of the SCP or SEPP, or to the NF Instance ID of the HTTP server.

For example, when inserted by an NF such as SCP or SEPP, the error originators, the server header pattern looks like "SCP-<SCP FQDN>" for a SCP and "SEPP-<SEPP FQDN>" for a SEPP.

The information carried in the Server Header is useful for troubleshooting. There might be cases where this server header has custom information and does not follow header pattern as defined by the 3GPP. Considering this, if a differently formatted value such as "ME-me-instanceid", is inserted in the header alongside the 3GPP supported ones, PCF, at present, completely ignores the server header, which impacts the retry strategy.

With this feature implementation, PCF core (SM/AM/UE) services ignores the custom server header value such as "ME-me-instanceid" and continue considering the valid SCP, SEPP or other NF type Server Headers.

Model C: PCF (SM/AM/UE) as Consumer Supports Custom Server Header from CHF on N28 Interface

The N28 reference point is defined for the interactions between PCF and Charging Function (CHF). Policy sends initial POST request for subscription to policy counter information from the CHF over N28 interface. If the CHF cannot successfully fulfill the received POST request due to an error, then CHF sends error response to PCF.

On receiving the error response from CHF, the PCF Core services check for Server Header Support field status,

• if the field status is set to Single Instance, then the regular expression evaluates the server header value. From the header value, only one NF instance of the primary/secondary CHF Producer is filtered and custom server header content such as ME-me-instanceid is ignored.
• if the field status is set to Multi Instance, then the regular expression evaluates the server header value. From the header value. two NF instances from all the producer NF instances in the NFSet is filtered and custom server header content such as ME-me-instanceid is ignored.

While creating retry profile, the regular expression to ignore the content in server header is configured for the Policy services. In the CNC Console, a field Ignore Custom server header value is added in Create Retry Profile section under Retry Profile. In this field, you can specify the string pattern that can be ignored in the server header value.

The following table maps the configured regular expression that identifies the matching pattern in the custom server header value. The identified pattern, if exists, is ignored and the remaining value is considered as seen in the Filtered Content column in the following table.

Table 4-78 CHF Server Header Content Pattern Matching Regular Expression

Configured Regular Expression	Server Header Content	Filtered Content	Server Header Support
ME-.+	ME-me-54804518-4191-46b3-955cac631f953eb91 CHF-54804518-4191-46b3-955cac631f953eb91	CHF-54804518-4191-46b3-955cac631f953eb9	Single Instance
ME-.+	ME-me-54804518-4191-46b3-955c-ac631f953ed82 CHF-54804518-4191-46b3-955c-ac631f953ed82 ME-me54804518-4191-46b3-955c-ac631f953eb91 CHF-54804518-4191-46b3-955c-ac631f953eb91	CHF-54804518-4191-46b3-955c-ac631f953ed82 CHF-54804518-4191-46b3-955c-ac631f953eb91	Multi Instance
ME-.+	CHF-54804518-4191-46b3-955cac631f953eb91 ME-me-54804518-4191-46b3-955cac631f953eb91	CHF-54804518-4191-46b3-955cac631f953eb91	Single Instance
ME-.+	CHF-54804518-4191-46b3-955c-ac631f953ed82 CHF-54804518-4191-46b3-955cac631f953eb91	CHF-54804518-4191-46b3-955c-ac631f953ed82 CHF-54804518-4191-46b3-955cac631f953eb91	Multi Instance
(ME|CHF)-.+	ME-me-54804518-4191-46b3-955cac631f953eb91 CHF-54804518-4191-46b3-955cac631f953eb91	Empty	Single Instance

Managing PCF Support for ME-XX String in Server Header from CHF

Enable

PCF supports ME-XX String in Server Header from CHF as a core functionality. You do not need to enable or disable this feature.

Configure Using CNC Console

To add the regular expression in CNC Console, set the Ignore Custom server header value field in Create Retry Profile section under Retry Profile for Common Data Configurations for Policy Services.

Configure Using REST API

Perform the feature configurations as described in "Retry Profile" section in Oracle Communications Cloud Native Core, Converged Policy REST Specification Guide.

Maintain

Error logs are generated when the system is congested and the actions are taken to bring the system back to normal. Warning logs are generated to indicate the congestion level. However, error logs are not generated when messages are rejected to avoid additional resource usage to write error logs.

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.

4.31 Sy SLR Enhancements for Signalling Updates and UDR Notification

The Sy reference point is located between CnPolicy and Online Charging System (OCS). It enables transfer of policy counter status information relating to subscriber spending from OCS to CnPolicy.

CnPolicy considers the subscriber's spending status into account for its Policy decisions. The CnPolicy requests the spending limit report for policy counters from the OCS using the initial or intermediate spending limit request. Currently, CnPolicy supports fetching of OCS counters in the following scenario in a synchronous mode:

• In the initial request i.e., when the request is sent for the first time for a Subscriber, the cnPCRF sets the SL-Request-Type AVP to the value, INITIAL_REQUEST and initiates a diameter Sy Spending Limit Request (SLR) towards OCS.
• On a subsequent request on the second IP CAN session for the same subscriber, the PCRF sets the SL-Request-Type AVP to the value, INTERMEDIATE_REQUEST and updates the OCS counters.

With this feature, CnPCRF and CnPolicy fetches OCS counter status over Sy reference point in the following scenarios in a synchronous mode:

• CnPCRF initiates a Sy SLR intermediate request on receiving CCR-U or SM update request for a given subscriber session-id. CnPolicy evaluates policy based on the latest counters received over Sy and sends the policy rules in the CCA-U or SM update response.
• On receiving UDR notification, cnPCRF issues an Sy SLR initial or intermediate requests. CnPolicy evaluates policy and triggers a RAR or Update Notify toward PGW/SMF for all IP CAN or PDU sessions of the subscriber.

Update Signaling Flow for CnPCRF/SM Services

CnPCRF/SM service, on receiving a CCR update or SM update requests from PGW/SMF, performs OCS counters lookup by invoking OCS Sy Spending Limit Request in a synchronous mode to OCS. At PCRF Core and PCF SM services, a flag Enable Force Lookup for OCS is added. You can enable or disable this flag in the PCRF Core service or PCF Session Management Settings page under User tab in the OCS Spending Limit section in the CNC Console. By default, this flag is disabled. The purpose of this flag is to force PDS to perform OCS Lookup, but at PDS this will be treated as revalidation. If this flag is enabled in the core services, then while initiating the OCS spending limit request the "forceLookup" is sent as true toward PDS.

The following call flow describes the fetching of Sy OCS counters on receiving session updates requests from PGW/SMF:

Figure 4-58 Update signalling flow for CnPCRF/SM service

1. PGW/SMF sends a CCR Update or SM Update request to CnPCRF/SM service.
2. The CnPCRF/SM service sends a GET OCSSpendingLimitRequest with "forceLookup" set to true to PDS.
3. If Sy session is not established then PDS sends SLR-Initial request to Diameter Gateway.
4. Diameter Gateway forwards this request to OCS.
5. If OCS responds with DIAMETER_SUCCESS code to Diameter Gateway.
   1. Diameter Gateway responds with OCS response containing ocsSpendingLimitStatus information to PDS.
   2. PDS forwards the OCS response with ocsSpendingLimitStatus data to CnPCRF/SM service.
6. If OCS responds with DIAMETER_ERROR code to Diameter Gateway.
   1. Diameter Gateway sends the Error Response to PDS. At PDS, an empty context entry is created in the Database if CreateContextOnFailure is enabled from the request from cnPCRF/PCF-SM.
   2. PDS forwards the Error Response to CnPCRF/SM service.
7. If Sy session is already established then PDS sends SLR-Intermediate request to Diameter Gateway
8. Diameter Gateway forwards this request to OCS.
9. If OCS responds back with DIAMETER_SUCCESS code to Diameter Gateway.
   1. Diameter Gateway responds with OCS response containing ocsSpendingLimitStatus information to PDS.
   2. PDS forwards the OCS response with ocsSpendingLimitStatus data to CnPCRF/SM service.
10. If OCS responds back with DIAMETER_ERROR code to Diameter Gateway. Diameter Gateway sends the error response to PDS. At PDS,
    1. On receiving the response, it evaluates the flag createContextOnFailure in the cnPCRF/PCF SM request and if enabled the existing context is updated as dummy context in the database.
    2. With Force Lookup flag enabled, PCF forces PDS to do a lookup towards OCS, but PDS treats this flag as if was part of revalidation flow and retries again as SLR-Initial Revalidation flow.
    3. Deletes the existing record in the database as part of the revalidation procedure.
11. PDS forwards the Error Response to CnPCRF/SM service.
12. CnPCRF/SM service sends a request with OCS information to PRE for Policy evaluation.
13. Policy evaluated information is sent to PGW/SMF as CCA update or SM update response.

UDR Notification Call Flow

In the UDR notification call flow, the PDS workflow Charging Profile selection based on Notification - UDR is added to the list of the existing workflows. On selecting this workflow PDS is instructed to select the user profile based on the notification from UDR. The Charging Profile selection based on Notification - UDR workflow is based on the existing Charging Profile selection based on User Profile - UDR workflow with two extra tasks added to UDR notify workflow namely, the search and PRE tasks.

In order to use the UDR notification flow that initiates any lookup towards OCS, you need to have the following configurations to be set:

• Select the new workflow Charging Profile selection based on Notification - UDR type.
• PDS-OCS dummy context, that is created using either CCR-I/SmCreate or CCR-U/SmUpdate must exist in PDS Database.
• PDS-OCS sy session, that is created using either CCR-I/SmCreate or CCR-U/SmUpdate must exist in PDS Database.

The following call flow describes the fetching of Sy OCS counters during a CCR I/SM Create request from PGW/SMF:

Figure 4-59 UDR PDS - Create Flow

1. PGW/SMF sends a CCR I or SM Create request to CnPCRF/SM service.
2. The CnPCRF/SM service sends a GET OCSSpendingLimitRequest with "createContextonFailure" set to true to PDS.
3. PDS sends SLR-Initial request to Diameter Gateway.
4. Diameter Gateway forwards this request to OCS.
5. If Sy session creation is successful with OCS then it returns DIAMETER_SUCCESS code to Diameter Gateway.
   1. Diameter Gateway responds with OCS response containing ocsSpendingLimitStatus information to PDS.
   2. At PDS the ocsSpendingLimitData and smPolicyData is written into the Database.
6. If Sy session creation is unsuccessful with OCS then it returns DIAMETER_ERROR code to Diameter Gateway.
   1. Diameter Gateway responds with either 404 Not Found or 500 Internal Server Error to PDS.
   2. PDS checks for the attribute "createdContextOnFailure" value. On finding it enabled PDS writes only the OCS context information and smPolicyData into the Database.
   3. PDS checks for the attribute "createdContextOnFailure" value. On finding it disabled PDS writes only smPolicyData into the Database.
7. PDS responds to CnPCRF/SM service.
8. CnPCRF/SM service triggers a CCA I or SM Create response to PGW/SMF.
9. On receiving PRE decision, CnPCRF/SM service triggers a Gx RAR/SM update notify response to PGW/SMF.

The following call flow describes the fetching of Sy OCS counters during a UDR Notification:

Figure 4-60 UDR PDS Notification Flow

1. UDR triggers an UDR Update Notify request with customAttribute set to "FetchOCS" toward Diameter Gateway.
2. Diameter Gateway forwards this request to PDS.
3. PDS performs a DB fetch and sends Policy evaluation request with the UDR Notification information to PRE.
4. PRE responds back with Policy decision request with an action of "OCS Lookup" to PDS.
5. If OCS Context does not exist then PDS sends notification request to CnPCRF/SM service.
6. If either the dummy OCS Context or actual OCS Context exists then PDS initiates either Sy SLR Initial or Sy SLR Intermediate request to OCS via Diameter Gateway.
7. If OCS sends DIAMETER_SUCCESS code to Diameter Gateway then following call flow runs:
   1. Diameter Gateway responds with OCS response containing ocsSpendingLimitStatus information to PDS.
   2. PDS updates the existing OCS context in the database with received OCS data.
   3. PDS sends a notification request with ocsSpendingLimitStatus data to CnPCRF/SM service.
   4. CnPCRF/SM service sends a Policy evaluation request with ocsSpendingLimitStatus to PRE.
8. If OCS sends DIAMETER_ERROR code to Diameter Gateway then following call flow runs:
   1. Diameter Gateway responds with either 404 Not Found or 500 Internal Server Error to PDS.
   2. PDS sends notification with 206 Partial success to CnPCRF/SM service.
   3. CnPCRF/SM service sends a Policy evaluation request to PRE.
9. PRE sends Policy decision response to CnPCRF/SM service.
10. CnPCRF/SM service triggers a Gx RAR/SM update notify response to PGW/SMF.

Managing Sy SLR Enhancements for Signalling Updates and UDR Notification

Enable

By default, the Sy SLR Enhancements for Signalling Updates and UDR Notification feature is disabled. You can enable this feature using CNC Console or REST API for Policy.

Configure Using CNC Console

To configure the feature using CNC Console, set the Enable force lookup on Update parameter to true in OCS Spending Limit section under user tab on the Settings page for PCRF Core Service Configuration.

To enable "createContextOnFailure" during UDR Notification flow using the CNC Console, add following keys:

• "USER.ocsSpendingLimit.createContextOnFailure" parameter in the Advanced Settings key in PCRF Core Service Configurations Settings section.
• "USER.CREATE_CONTEXT_ON_FAILURE_OCS_DATA" parameter in the Advanced Settings key in PCF Session Management section.

In the CNC Console the PDS workflow Charging Profile selection based on Notification - UDR is selected at PDS Workflow section.

Configure Using REST API

Perform the feature configurations as described in "PCRF Core Service", "Session Management Service" and "PDS Workflow" sections in Oracle Communications Cloud Native Core, Converged Policy REST Specification Guide.

Observability

Metrics:

The metric create_context_on_failure_response is added to Diameter Connector Service Metrics section.

Maintain

Error logs are generated when the system is congested and the actions are taken to bring the system back to normal. Warning logs are generated to indicate the congestion level. However, error logs are not generated when messages are rejected to avoid additional resource usage to write error logs.

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 .

4.31.1 Handling N28 and N36 Interfaces Context Information during Subscription Failures

With this feature, PCF supports the N28 and N36 context information such as subscription information, policy and charging related information to be stored in PDS databases during lookup failures. In a scenario, where:

1. SMF initiates a session creation by sending SM create request with received DDN as IMS, the session ID is session-id-ims for a subscriber.
2. The fetch request for subscription details from the N28 and N36 fails. PDS does not store any context information for session-id-ims.
3. SMF initiates a session creation by sending SM create request with received DNN as internet, the session ID is session-id-internet for the same subscriber.
4. If the GET request for subscription details from the N28 and N36 is successful and the POST request for CHF or UDR subscription is also successful then PDS stores the information related to session-id-internet in the subscriber context information.
5. PCF receives a SM delete request for the session-id-internet.

Currently, PCF deletes the session session-id-internet information, even though the other session session-id-ims still exists for the subscriber.

This implementation ensures that PCF does not perform deletion of the message toward CHF or UDR prematurely, and keeps the information in the PDS until the subscriber goes away. This feature is implemented for PCRF Core and SM services.

To implement this feature, PCRF core services uses an existing USER.ocsSpendingLimit.createContextOnFailure flag and the following new flags:

• USER.smPolicyData.createContextOnFailure
• USER.operatorSpecificData.createContextOnFailure

If these flags are set to true, then the subscribers policy data and operator specific data are stored in a dummy context created by PDS service during subscription failures from CHF or UDR.

SM service uses an existing USER.CREATE_CONTEXT_ON_FAILURE_OCS_DATA flag and the following three new flags:

• USER.CREATE_CONTEXT_ON_FAILURE_SM_POLICY_DATA
• USER.CREATE_CONTEXT_ON_FAILURE_CHF_DATA
• USER.CREATE_CONTEXT_ON_FAILURE_OPERATOR_SPECIFIC_DATA

If these flags are set to true, then the subscribers policy data, operator specific data, and charging data are stored in a dummy context created by PDS service during subscription failures from CHF or UDR.

Note:

This feature works only when subscription (subs-to-notify) flag for UDR data source is true. If the subscription flag is false, then PDS does not create any UDR related resources in the database.

For more information on CNC Console configurations, see "Advanced Settings" in PCF Session Management and PCRF Core Settings sections.

Call Flows

This section describes the procedure of dummy context creation by PDS service during subscription failure scenario in SM and PCRF Core services Create, Update, and Delete call flows.

PDS Dummy Context Creation in SM and PCRF Core Services Create Call Flow

This section describes the SM Create call flow and usage of the flag createContextOnFailure during CHF/UDR subscription failure. The same call flow applies to PCRF-Core (CCR-I) without SpendingLimitData (CHF).

Figure 4-61 PDS Dummy Context Creation during SM and PCRF Core Create Call Flow

1. The SMF sends a SM Create request to SM service via Ingress Gateway.
2. If UDR or CHF subscription and charging information is configured in PCF then SM service populates the SM session with these details and sends a request to PDS.
3. The PDS searches for the charging information in the database.
   • If valid data exists, then PDS responds to SM service with the data.
   • If dummy data exists or there is no data, then it sends a GET request for SmPolicyData/OperatorSpecificData toward UDR, and GET request for ChfData toward CHF.
     • UDR responds with SmPolicyData to PDS. This data is stored to the database by PDS.
     • PDS sends Subscription request to UDR. On receiving unsuccessful error response from UDR, PDS checks for the flag "CreateContextOnFailure". If it is set to true, then the SmPolicyData/OperatorSpecificData and ChfData are written to the dummy context by PDS. If the flag is false, there is no database operation done by PDS.
4. PDS sends successful 200 Success response to SM service for CHF and UDR GET requests.
5. PDS sends partial successful 206 Partial Success response to SM service on creation of either one datasource or dummy context.
6. SM service responds with SmCreate response to SMF.

Note:

Upon dummy context creation for the data source, it will contain "lastErrorCode" parameter containing status code that provides error details. For example, on receveing 404 error Not Found from UDR, the "lasterrorcode" will be populated as - lastErrorCode:"USER_NOT_FOUND" or "SUBSCRIPTION_NOT_FOUND" depending on the type of operation performed.

PDS Dummy Context Creation in SM and PCRF Core Services Update Call Flow

This section describes the PCRF Core Update call flow and usage of the flag createContextOnFailure during CHF/UDR subscription failure. The same call flow applies to SM Update with SpendingLimitData (CHF).

Figure 4-62 PDS Dummy Context Creation during SM or PCRF Core Update Call Flow

1. The PGW sends a CCR-U, an Update request to PCRF core service via Diameter Gateway.
2. If UDR or CHF subscription is configured, then PCRF core service populates its session with these details and sends a request to PDS.
3. The PDS searches for the charging information in the database. If valid data exists, then PDS responds to PCRF core service with the data.
4. The PDS searchs for the charging information in the database and if no data or dummy data exists, then
   • If valid data exists, then PDS responds to PCRF core service with the data.
   • If dummy data exists or there is no data, then it sends a GET request for SmPolicyData/OperatorSpecificData toward UDR.
     • UDR responds with SmPolicyData to PDS. This data is stored to the database by PDS.
     • PDS sends Subscription request to UDR. On unsuccessful error response from UDR, PDS checks for the flag "CreateContextOnFailure" value. If it is true, then the SmPolicyData/operatorSpecificData is written to dummy context by PDS. If the flag is false, there is no database operation done by PDS.
5. PDS sends successful 200 Success response to PCRF Core service for UDR GET request.
6. PDS sends partial successful 206 Partial Success response to SM service on creation of either one datasource or dummy context.
7. PCRF Core Service responds with CCA-I or CCA-U response to PGW.

PDS Dummy Context Creation in SM Create/Update Call Flow with OCS in Asynchronous Mode

This section describes PCRF Core CCR-I/CCR-U call flow and usage of the flag createContextOnFailure during CHF/UDR subscription failure. For this call flow, the Online Charging System (OCS) is asynchronously enabled using the flag OCS Aync. The same call flow applies to SM Update with SpendingLimitData (CHF).

Figure 4-63 PDS Dummy Context Creation during SM and PCRF Core Create/Update Call Flow with OCS in Async Mode

1. The PGW/SMF sends a CCR-I/SM Create or CCR-U/SM Update requests to PCRF core/SM services via Diameter Gateway/Ingress Gateway.
2. The PCRF core/SM service sends a GET request with asynchQuery enabled in OCS spending limit header parameter toward PDS.
3. PDS sends successful 200 Success response to PCRF core/SM service.
4. The PCRF core/SM service sends a Policy evaluation to PRE.
5. The PRE service responds with fetch policy counters request to PCRF core/SM service.
6. The PCRF core/SM service sends a GET request with createContextOnFailure enabled in spending limit header parameter toward PDS.
7. PDS sends successful 200 Success response to PCRF core/SM service.
8. The PCRF core/SM service sends a CCA-I/SMCreateResponse or CCA-U/SMUpdateResponse toward PGW/SMF.
9. The PDS performs Database lockup:
   • If dummy context exists, and there is no valid data, then PDS sends SLR-Initial request toward OCS.
   • If valid data exits, then PDS sends SLR-Intermediate request toward OCS.
10. OCS sends successful "ocsSpendingLimitStatus" response to PDS. PDS sends a notification about "ocsSpendingLimitStatus" to PCRF Core/SM service.
11. OCS sends unsuccessful error response to PDS. If createContextOnFailure is enabled then ocsSpendingLimitStatus context information is written to database by PDS. If the flag is false, there is no database operation done by PDS.
12. PDS sends a notification 404 Not Found request to PCRF Core/SM service.
13. PCRF Core/SM services sends policy evaluation request to PRE service.
14. PRE service sends policy evaluation response to PCRF Core/SM service.
15. PCRF Core/SM service sends RAR/UpdateNotify response to PGW/SMF.

PDS Dummy Context during SM Delete or PCRF Core CCR-T Call Flow

This section describes the SM Delete/CCR-T call flow and usage of the flag createContextOnFailure during CHF/UDR subscription failure.

Figure 4-64 PDS Dummy Context during SM Delete or PCRF Core CCR-T Call Flow

1. The PGW/SMF sends a CCR-T/SM Delete request to PCRF Core/SM services via Diameter Gateway/Ingress Gateway.
2. PCRF core/SM services send delete request to PDS.
3. For the given subscriber, if the dummy context does not exists, then PDS deletes it and also the corresponding Subscriber State Variable (SSV).
4. If dummy context for related to the specific subscriber in the request exists then PDS deletes it and the corresponding Subscriber State Variable (SSV).
5. PDS sends successful 200 Success response to PCRF core/SM services.
6. PCRF core/SM services perform policy evaluation and send the result as CCA-T/SM Delete response to PGW/SMF.

4.32 Enhancement to PRE Metrics

The following Policy blocks have been added to PRE to evaluate policy block execution counter and policy blocks execution time.

• Increment Counter Label
• Time

For more information, see "Public Category" section in Oracle Communications Cloud Native Core, Converged Policy Design Guide.

To enable the PRE metrics, enable the Enable Metrics switch in the Policy Engine page under Service Configurations. By default, this switch remains disabled. For more information, see Policy Engine.

The following metrics have been added in PRE service for this feature:

• occnp_block_counter_label
• occnp_block_exec_time_ns

For more information, see PRE Metrics.

4.33 Enhancement to PCF Resiliency

PCF is enhanced to provide the mechanism in consumer service pods to cache the last successful producer pod information and use it when the subsequent producer pod discovery results in failure. Hence, the inter service communication continues to run even when the communication between the Kubernetes services and pods is down.

4.34 Support for cnDBTier APIs in CNC Console

With the implementation of this feature, cnDBTier APIs are integrated into the CNC Console, and Policy users can view specific cnDBTier functions, such as checking the cnDBTier version, status of cnDBTier clusters, and georeplication status on the CNC Console.

Note:

This cnDBTier options can be accessed only through CNC Console.

The following cnDBTier functionalities are read only and can be viewed on the CNC Console:

• Backup List: This API displays the details of stored backups, such as the ID and size of the backup.
• Database Statistics Report: This API displays the number of available database.
• Georeplication Status:
  • Real Time Overall Replication Status: This API displays the overall replication status in multisite deployments. For example, in a four-site deployment, it provides the replication status between the following sites: site1-site2, site1-site3, site1-site4, site2-site3, site2-site4, and site2-site1. This is applicable for all other sites.
  • Site Specific Real Time Replication Status: This API displays the site-specific replication status.
• HeartBeat Status: This API displays the connectivity status between the local site and the remote site to which Policy is connected.
• Georeplication Recovery: This API provides the recovery status of georeplication for the cnDBTier cluster:
  • Update Cluster As Failed: This API is used to mark a disrupted cluster as failed.
  • Start Georeplication Recovery: This API is used to start the georeplication recovery process.
  • Georeplication Recovery Status: This API is used to monitor the recovery status of georeplication for both FAILED and ACTIVE cnDBTier sites.
• Local Cluster Status: This API displays the status of the local cluster.
• On-Demand Backup: This API provides options to initiate as well as the display the status of the on-demand backup. It also displays the status of initiated on-demand backups.
• cnDBTier version: This API displays the cnDBTier version.
• PCF Cluster DB State: This API displays the realtime status of the cluster state and NF database functional state in the cnDBTier database cluster.

Managing cnDBTier Functionalities at CNC Console

Enable

This feature is enabled automatically when cnDBTier is configured as an instance during the CNC Console deployment. For more information about integrating cnDBTier functionalities in CNC Console, see Oracle Communications Cloud Native Core, cnDBTier User Guide.

Important:

In order to enable this feature, make sure that cnDBTier 25.1.200 or later versions is used.

Configure

You can view cnDBTier functionalities at CNC Console in the Viewing cnDBTier APIs in CNC Console section.

Note:

The PCF Cluster DB State configurations can be updated with the custom.values.yaml for AppInfo service along with the Helm install/upgrade process. The Helm process update the configMap with the configurations which are mounted in the AppInfo pods. Normally, an upgrade between releases should restart pods and reflect the configuration changes. In a rare case that an in-release upgrade is needed, it is mandatory to restart the AppInfo pods manually to sync the configuration.

Also, DB status considers the PCF's status reported by NRF Client. The status/category/pcf API is used monitor the PCF status.

Maintain

If you encounter alerts at the system level, see the Alerts section for resolution steps.

In case the alerts persist, perform the following tasks:

1. Collect the logs: For information about how to collect logs, see Oracle Communications Cloud Native Core, Converged Policy Troubleshooting Guide.
2. Raise a service request: For information about how to raise a service request, see My Oracle Support.

4.35 Support for Non-SUPI based On-Demand Discovery Caching of NF Profiles

Policy supports the caching of NF profiles at NRF Client received from non-SUPI based on-demand discovery from NRF. Caching the NF profiles at NRF Client avoids discovering the NF profiles from NRF for every new call flow.

• N15 - AMF Notification for AM Policy (NFSetid based discovery for retry on Notification Request failure)
• N15 - AMF Notification for UE Policy (NFSetid based discovery for retry on Notification Request failure)
• N7 - SMF Notification for SM Policy (NFSetid based discovery for retry on Notification Request failure)
• N15 - AMF discovery, AMF as a producer for UE Policy N1N2 Message Subscribe (GUAMI, amf-region-id,amf-set-id)
• N15 - AMF rediscovery, AMF as a producer for UE Policy N1N2 Message Transfer failure retry (NFSetid based discovery)
• UDR Rediscovery, UDR as a producer for SM, AM and UE Policy session, when POST(if considered subsequent), PUT, PATCH, Delete request failure, (NFSetid based discovery)

This allows NRF client to map and cache discovery query parameters against their on-demand discovery responses, allowing NRF Client to reuse those responses until they expire and reduces the number of requests sent to NRF for such discoveries.

Policy supports:

• caching the discovered producer/Notify Consumers profiles from NRF along with its query parameter for on-demand discovered NFs.
• rediscovering the NF Profiles whose TTLs have expired, when there is an on-demand discovery request for the same. That is, rediscovering the NF profiles based on the query parameter, when required during a signaling or call flow, if the validity period of the cached discovery response has expired. The expired records are updated with the recently rediscovered records after rediscovery is successful with 2xx response code.
• using the expired discovered profiles, which are in Registered state, if PCF cannot reach any NRFs during rediscovery.

The query from SM service, AM service, UE Policy service towards NRF Client can include the following two headers to support this feature:

• OC-Force-Rediscovery: Indicates whether to cache the NF profiles received from NRF in NRF Client or to skip caching and receive the response directly from NRF.

  Value of this parameter can be 0 or 1. By default, value of this parameter is set to 0.

  • When the value of OC-Force-Rediscovery parameter is set to 0, it enables the feature and caches the NF profiles details received from NRF.
  • When the value of OC-Force-Rediscovery parameter is set to 1, it disables the feature and retrieves the NF profiles directly from NRF while responding to the query from the backend services.
• OC-Retention-Period: Indicates the time a record is allowed to stay in database until the expiry period. This parameter accepts an integer value to indicate the retention period in milliseconds. When retention period is not configured/saved as null, backend will not send this header to NRF connector. By default, value of this parameter is set to 0.

Important:

If occnp_nrf_client database is not yet created on NRF Client, you must manually create it. This database is used to store the cached profiles on NRF Client.

For details on how to create the database, see Configuring Database, Creating Users, and Granting Permissions section in Oracle Communications Cloud Native Core, Installation, Upgrade, and Fault Recovery Guide .

These headers can be configured by applying the configurations under NF Discovery Settings group in NF Communication Profiles for Common Data in Service Configuration.

The configurations are saved in common.public.communication-profile topic in the config server.

Note:

The NF communication profile must be created and oc-forced-rediscovery, retentionperiod must be configured before attaching the NF communication profile to service configuration page of SM service, AM service, UE Policy service, and User service.

Call Flow

Figure 4-65 SMF Notification for SM Policy (NFSetid based discovery for retry on Notification Request failure)

1. SMF1 sends an SM Create request to SM service.
2. After the successful creation, SM service responds to SMF1 with a successful message.
3. Whenever there is a notification from UDR regarding any change in the user profile, PDS forwards the notification to SM service.
4. SM service forwards the notification to SMF1 and receives a 5xx error.
5. If the caching feature is enabled, SM service initiates an on-demand discovery caching with the given set ID and Service name and sends the request to NRF client.
6. As this is the first request and the data is not yet cached, NRF client sends the request to NRF to fetch the SMF profile information.
7. NRF responds with the SMF profile information for the given setID and service name.
8. NRF client caches these details in the database and sends the details to SM service.
9. SM service forwards the details to SMF2, which in turn responds with a 200 ok successful message.
10. Whenever PDS forwards an update notification from UDR to SM service.
11. SM service forwards the notification to SMF1 and receives an error in response.
12. SM service sends an on-demand discovery request to NRF client.
13. Now that the data is already cached for the given setID and service name, NRF client fetches the SMF Profiles from the cache and responds to SM service.
14. SM service sends the notification to SMF2 and receives a 200 ok successful message.

Figure 4-66 AMF Notification for AM Policy (NFSetid based discovery for retry on Notification Request failure)

1. AMF1 sends an AM Create request to AM service.
2. After the successful creation, AM service responds to AMF1 with a successful message.
3. Whenever there is a notification from UDR regarding any change in the user profile, PDS forwards the notification to AM service.
4. AM service forwards the notification to AMF1 and receives a 5xx error.
5. If the caching feature is enabled, AM service initiates an on-demand discovery caching with the given set ID and Service name and sends the request to NRF client.
6. As this is the first request and the data is not yet cached, NRF client sends the request to NRF to fetch the AMF profile information for the give set ID and Service name.
7. NRF responds with the AMF profile information for the given setID and service name.
8. NRF client caches these details in the database and sends the details to AM service.
9. AM service forwards the details to AMF2, which in turn responds with a 200 ok successful message.
10. Whenever PDS forwards an update notification from UDR to AM service.
11. AM service forwards the notification to AMF1 and receives an error in response.
12. AM service sends an on-demand discovery request to NRF client.
13. Now that the data is already cached for the given setID and service name, NRF client fetches the AMF profile information from the cache and responds to AM service.
14. AM service sends the notification to AMF2 and receives a 200 ok successful message.

Figure 4-67 AMF Notification for UE Policy (NFSetid based discovery for retry on Notification Request failure)

1. AMF1 sends an UE Create request to UE Policy service.
2. After the successful creation, UE Policy service responds to AMF1 with a successful message.
3. Whenever there is a notification from UDR regarding any change in the user profile, PDS forwards the notification to UE Policy service.
4. UE Policy service forwards the notification to AMF1 and receives a 5xx error.
5. If the caching feature is enabled, UE Policy service initiates an on-demand discovery caching with the given set ID and Service name and sends the request to NRF client.
6. As this is the first request and the data is not yet cached, NRF client sends the request to NRF to fetch the AMF profile information for the give set ID and Service name.
7. NRF responds with the AMF profile information for the given setID and service name.
8. NRF client caches these details in the database and sends the details to UE Policy service.
9. UE Policy service forwards the details to AMF2, which in turn responds with a 200 ok successful message.
10. Whenever PDS forwards an update notification from UDR to UE Policy service.
11. UE Policy service forwards the notification to AMF1 and receives an error in response.
12. UE Policy service sends an on-demand discovery request to NRF client.
13. Now that the data is already cached for the given setID and service name, NRF client fetches the AMF profile information from the cache and responds to UE Policy service.
14. UE Policy service sends the notification to AMF2 and receives a 200 ok successful message.

Figure 4-68 AMF Discovery/ Re-Discovery

1. AMF Sends a UEPolicyAssociation request to UE Policy service.
2. UE Policy service sends a request to NRF Client to discover the NF instances using amf-set-id and amf-region-id.
3. NRF client forwards the request to NRF.
4. NRF responds to NRF client with the list of AMF Profiles matching the given amf-set-id and amf-region-id.
5. NRF Client caches these AMF Profiles and then responds to UE Policy service.
6. UE Policy service sends a N1N2 message subscription request to the AMF matching the amf-set-id and amf-region-id and receives a successful response.
7. When UE Policy service receives the next UEPolicyAssociation create request for the same amf-set-id and amf-region-id, it sends a request to NRF client to fetch the AMF profiles.
8. As the data is already cached, NRF client fetches the AMF profiles from its cache and responds to UE Policy service.
9. UE Policy service sends the N1N2 message subscription request to the required AMF and receives a successful response.

Figure 4-69 Non-SUPI based on-demand discovery caching for User Service

1. SMF sends an SM Create request to SM service.
2. SM service sends a request to NRF client to fetch the UDR profiles details.
3. NRF client sends the request to NRF and receives the list of UDR profiles matching the given nfsetID.
4. If the caching feature is enabled, NRF client caches these UDR profiles and then forwards the details to SM service.
5. After the successful creation of SMPolicyAssociation, SM service responds to SMF.
6. Whenever SMF sends another SM Create request to SM service, SM service sends a request to NRF client to fetch the UDR profiles.
7. As the data is already cached, NRF client fetches the UDR profiles with the matching nfsetID from its cache and responds to SM service.
8. After the successful creation of SMPolicyAssociation, SM service responds to SMF.

Managing the Feature

Enable

By default, this feature is disabled. You can enable caching of the NF Profiles at NRF client using CNC Console or REST API for Policy.

Enable using CNC Console:

To enable the feature using CNC Console configure:

• Force Discovery parameter under On Demand Discovery Caching section on NF Communication Profile page. The NF Communication Profile page is available under Common Data for Service Configurations.
• Enable Caching parameter under On Demand Discovery Caching section on NRF Agent page, The NRF Agent page is available under Service Configurations.

For more information about enabling the feature through CNC Console, see NF Communication Profiles.

Enable using REST API:

You can enable the feature using:

• NF Communication Profiles API by configuring the value of forceDiscovery paramter under onDemandDiscoveryCaching section to 0.
• NRF Agent Service API by configuring the value of enableFeature parameter under onDemandDiscoveryCaching section to true.

For more information about enabling the feature through REST API, see NF Communication Profiles in Oracle Communications Cloud Native Core, Converged Policy REST Specification Guide.

Configure

You can configure this feature using the CNC Console or REST API for Policy.

Configure using CNC Console

• To configure caching of the NF profiles at NRF client at global level, perform the following configurations under On Demand Discovery Caching section on NRF Agent page, The NRF Agent page is available under Service Configurations. For more information, see NRF Agent.
• To configure the retention period of the cached data, perform the following configurations under On Demand Discovery Caching section on NF Communication Profile page. The NF Communication Profile page is available under Common Data for Service Configurations. For more information, see NF Communication Profiles.

Configure using REST API

You can configure this feature using NF Communication Profiles and NRF Agent Service APIs.

For more information, see NF Communication Profiles and NRF Agent sections in Oracle Communications Cloud Native Core, Converged Policy REST Specification Guide.

Observability

Metrics

The following NRF Client metrics are used for this feature:

• occnp_nrfclient_discovery_cache_support_force_discovery_total
• occnp_nrfclient_discovery_cache_support_cache_hit_total
• occnp_nrfclient_discovery_cache_support_about_to_expire_total
• occnp_nrfclient_discovery_cache_support_expired_total
• occnp_nrfclient.discovery.cache.support.failover
• occnp_nrfclient_discovery_cache_support_cache_non_cache_total
• occnp_nrfclient_discovery_cache_support_empty_response_total
• occnp_nrfclient_discovery_cache_support_cache_lookup_seconds
• occnp_nrfclient_discovery_cache_support_cache_lookup_seconds_bucket
• occnp_nrfclient_discovery_cache_support_cache_lookup_seconds_count
• occnp_nrfclient_discovery_cache_support_cache_lookup_seconds_max
• occnp_nrfclient_discovery_cache_support_cache_lookup_seconds_sum
• occnp_nrfclient_discovery_cache_support_backend_response_seconds
• occnp_nrfclient_discovery_cache_support_backend_response_seconds_bucket
• occnp_nrfclient_discovery_cache_support_backend_response_seconds_count
• occnp_nrfclient_discovery_cache_support_backend_response_seconds_max
• occnp_nrfclient_discovery_cache_support_backend_response_seconds_sum
• occnp_nrfclient_discovery_cache_support_profiles_bucket
• occnp_nrfclient_discovery_cache_support_profiles_count
• occnp_nrfclient_discovery_cache_support_profiles_max
• occnp_nrfclient_discovery_cache_support_profiles_sum

For more information, see NRF Client Metrics.

Logging

PCF services

AM-Service:
{"instant":{"epochSecond":1687351821,"nanoOfSecond":727462057},"thread":"HttpLoggingJettyHttpClient@4be14ed1-134","level":"DEBUG","loggerName":"ocpm.pcf.service.am.retry.AlternateRoutingHelper","message":"nfcommunication profile attached in settings NFCommProfile{nfCommunicationProfileName='nfcp_rtp_sameLoc', policyNfCommunicationModel=MODEL_C(3), nfDiscoverySettings=NFDiscoverySettings{discoveryParameters=[ocpm.pcf.resource.common.model.DiscoveryParamCfg@33ee9d8b], sendDiscoveryHeaderInitMsg=false, sendDiscoveryHeaderSubsequentMsg=false, sendTargetApiRootHeaderInitMsg=true, onDemandDiscoverySettings=OnDemandDiscoveryCaching{forceDiscovery=1, retentionPeriod=null}}, nfBindingSettings=NFBindingSettings{cfgBindingLevel=NF_SET(1), sendBindingHeader=true, sendRoutingBindingHeader=true, sendCallbackHeader=true}, nfServerSettings=NFServerSettings{sendServerHeader=false, serverHeaderErrorCodes=null}, retryAndAlternateRoutingSettings=ocpm.pcf.resource.common.model.RetryAndAlternateRoutingSettings@4a752f56, nfCorrelationSettings=null}","endOfBatch":false,"loggerFqcn":"org.apache.logging.slf4j.Log4jLogger","threadId":134,"threadPriority":5,"messageTimestamp":"2023-06-21T12:50:21.727+0000"}
{"instant":{"epochSecond":1687351821,"nanoOfSecond":727672162},"thread":"HttpLoggingJettyHttpClient@4be14ed1-134","level":"DEBUG","loggerName":"ocpm.pcf.service.am.retry.AlternateRoutingHelper","message":"ocForcedRediscovery is 1 and retention Period is null","endOfBatch":false,"loggerFqcn":"org.apache.logging.slf4j.Log4jLogger","threadId":134,"threadPriority":5,"messageTimestamp":"2023-06-21T12:50:21.727+0000"}
SM-Service:

{"instant":{"epochSecond":1694159028,"nanoOfSecond":405961795},"thread":"boundedElastic-4","level":"DEBUG","loggerName":"ocpm.pcf.service.sm.domain.component.retry.profiles.AlternateRoutingHelper","message":" ocForcedRediscovery is 1 and retentionPeriod is 5000 ","endOfBatch":false,"loggerFqcn":"org.apache.logging.slf4j.Log4jLogger","threadId":210,"threadPriority":5,"messageTimestamp":"2023-09-08T07:43:48.405+0000"}

UE-Service:
{"instant":{"epochSecond":1694169865,"nanoOfSecond":366771034},"thread":"pool-3-thread-10","level":"DEBUG","loggerName":"ocpm.pcf.service.uepolicy.routing.AlternateRoutingHelper","message":"NF Communication Profile attached in service configuration is NFCommProfile{nfCommunicationProfileName='nfcp_rtp', policyNfCommunicationModel=MODEL_C(3), nfDiscoverySettings=NFDiscoverySettings{discoveryParameters=[ocpm.pcf.resource.common.model.DiscoveryParamCfg@5d2c8a02], sendDiscoveryHeaderInitMsg=false, sendDiscoveryHeaderSubsequentMsg=false, sendTargetApiRootHeaderInitMsg=true}, onDemandDiscoveryCaching=OnDemandDiscoveryCaching{forceDiscovery=1, retentionPeriod=5000}, nfBindingSettings=NFBindingSettings{cfgBindingLevel=NF_SET(1), sendBindingHeader=true, sendRoutingBindingHeader=true, sendCallbackHeader=true, sendServiceName=false}, nfServerSettings=NFServerSettings{sendServerHeader=false, serverHeaderErrorCodes=null}, retryAndAlternateRoutingSettings=ocpm.pcf.resource.common.model.RetryAndAlternateRoutingSettings@468b7e0a, nfCorrelationSettings=null}","endOfBatch":false,"loggerFqcn":"org.apache.logging.slf4j.Log4jLogger","threadId":890,"threadPriority":5,"messageTimestamp":"2023-09-08T10:44:25.366+0000"}
{"instant":{"epochSecond":1694169865,"nanoOfSecond":366943366},"thread":"pool-3-thread-10","level":"DEBUG","loggerName":"ocpm.pcf.service.uepolicy.routing.AlternateRoutingHelper","message":" ocForcedRediscovery is 1 and retentionPeriod is 5000 ","endOfBatch":false,"loggerFqcn":"org.apache.logging.slf4j.Log4jLogger","threadId":890,"threadPriority":5,"messageTimestamp":"2023-09-08T10:44:25.366+0000"}

User-Service:

{"instant":{"epochSecond":1694170047,"nanoOfSecond":943574493},"thread":"UserService_ThreadPool_16","level":"DEBUG","loggerName":"ocpm.pcf.service.ud.dbplugin.ds.AlternateRouteServiceHelper","message":"NF-Communication Profile is NFCommProfile{nfCommunicationProfileName='nfcp_rtp_diffSet_sameLoc', policyNfCommunicationModel=MODEL_C(3), nfDiscoverySettings=NFDiscoverySettings{discoveryParameters=[ocpm.pcf.resource.common.model.DiscoveryParamCfg@75f2f60d], sendDiscoveryHeaderInitMsg=false, sendDiscoveryHeaderSubsequentMsg=false, sendTargetApiRootHeaderInitMsg=true}, onDemandDiscoveryCaching=OnDemandDiscoveryCaching{forceDiscovery=1, retentionPeriod=5000}, nfBindingSettings=NFBindingSettings{cfgBindingLevel=NF_SET(1), sendBindingHeader=true, sendRoutingBindingHeader=true, sendCallbackHeader=true, sendServiceName=false}, nfServerSettings=NFServerSettings{sendServerHeader=false, serverHeaderErrorCodes=null}, retryAndAlternateRoutingSettings=ocpm.pcf.resource.common.model.RetryAndAlternateRoutingSettings@3b6541ce, nfCorrelationSettings=null}, oc-forced-discovery is 1 and retention period is 5000","endOfBatch":false,"loggerFqcn":"org.apache.logging.slf4j.Log4jLogger","threadId":276,"threadPriority":5,"messageTimestamp":"2023-09-08T10:47:27.943+0000"}
{"instant":{"epochSecond":1694170047,"nanoOfSecond":943677402},"thread":"UserService_ThreadPool_16","level":"DEBUG","loggerName":"ocpm.pcf.service.ud.dbplugin.ds.AlternateRouteServiceHelper","message":" OC-Forced-Rediscovery is 1","endOfBatch":false,"loggerFqcn":"org.apache.logging.slf4j.Log4jLogger","threadId":276,"threadPriority":5,"messageTimestamp":"2023-09-08T10:47:27.943+0000"}

NRF Client

For SM Service:

{"instant":{"epochSecond":1702446905,"nanoOfSecond":450166996},"thread":"XNIO-1 task-2","level":"DEBUG","loggerName":"com.oracle.cgbu.cnc.nrf.core.discoveryrules.DiscoveryRule","message":"Checking if cache applies for a discovery request (DiscoveryCache feature enabled: true, OC-Force-Rediscovery requested: false)","endOfBatch":false,"loggerFqcn":"org.apache.logging.slf4j.Log4jLogger","threadId":90,"threadPriority":5,"messageTimestamp":"2023-12-13T05:55:05.450+0000"}
{"instant":{"epochSecond":1702446905,"nanoOfSecond":507483619},"thread":"XNIO-1 task-2","level":"DEBUG","loggerName":"com.oracle.cgbu.cnc.nrf.core.discoveryrules.DiscoveryRule","message":"Query Parameters validation. IsFullyMatch -> true, Params from request -> [target-nf-type, requester-nf-type, service-names, target-nf-set-id], Params from config -> [target-nf-type, requester-nf-type, service-names, target-nf-set-id]","endOfBatch":false,"loggerFqcn":"org.apache.logging.slf4j.Log4jLogger","threadId":90,"threadPriority":5,"messageTimestamp":"2023-12-13T05:55:05.507+0000"}
{"instant":{"epochSecond":1702446905,"nanoOfSecond":507762621},"thread":"XNIO-1 task-2","level":"INFO","loggerName":"com.oracle.cgbu.cnc.nrf.core.discoveryrules.DiscoveryRule","message":"DiscoveryCache is enabled and queryParameters matched. Proceeding with DiscoveryResponse retrieval from memory","endOfBatch":false,"loggerFqcn":"org.apache.logging.slf4j.Log4jLogger","threadId":90,"threadPriority":5,"messageTimestamp":"2023-12-13T05:55:05.507+0000"}
{"instant":{"epochSecond":1702446905,"nanoOfSecond":508175763},"thread":"XNIO-1 task-2","level":"DEBUG","loggerName":"com.oracle.cgbu.cnc.nrf.core.discoveryrules.DiscoveryEvaluator","message":"Rule applied: CacheRule","endOfBatch":false,"loggerFqcn":"org.apache.logging.slf4j.Log4jLogger","threadId":90,"threadPriority":5,"messageTimestamp":"2023-12-13T05:55:05.508+0000"}
{"instant":{"epochSecond":1702446905,"nanoOfSecond":508393875},"thread":"XNIO-1 task-2","level":"DEBUG","loggerName":"com.oracle.cgbu.cnc.nrf.core.discoveryrules.CacheRule","message":"Applying Cache Rule, grabbing NRF response from Cache","endOfBatch":false,"loggerFqcn":"org.apache.logging.slf4j.Log4jLogger","threadId":90,"threadPriority":5,"messageTimestamp":"2023-12-13T05:55:05.508+0000"}
{"instant":{"epochSecond":1702446905,"nanoOfSecond":813463474},"thread":"XNIO-1 task-2","level":"INFO","loggerName":"com.oracle.cgbu.cnc.nrf.core.usecases.cache.GetCacheDiscoveryResponseUseCase","message":"Unsuccessful retrieval of Discovery Response from Cache/DB, proceeding retrieval from NRF and saving response in Cache/DB","endOfBatch":false,"loggerFqcn":"org.apache.logging.slf4j.Log4jLogger","threadId":90,"threadPriority":5,"messageTimestamp":"2023-12-13T05:55:05.813+0000"}
{"instant":{"epochSecond":1702446905,"nanoOfSecond":813770323},"thread":"XNIO-1 task-2","level":"INFO","loggerName":"com.oracle.cgbu.cnc.nrf.core.usecases.nrf.GetNrfDiscoveryResponseUseCase","message":"SearchData : {\"targetNfType\":\"SMF\",\"serviceNames\":[\"nsmf-pdusession\"],\"requesterNfType\":\"PCF\",\"nfInfoParamsPresent\":false,\"serviceInfoParamsPresent\":true,\"enableF3\":true,\"enableF5\":false,\"targetNfSetId\":\"set001.smfset.5gc.mnc012.mcc345\",\"retentionPeriod\":5000,\"rawQueryParameters\":\"target-nf-type=SMF&requester-nf-type=PCF&target-nf-set-id=set001.smfset.5gc.mnc012.mcc345&service-names=nsmf-pdusession\",\"forceRediscoveryEnabled\":false}","endOfBatch":false,"loggerFqcn":"org.apache.logging.slf4j.Log4jLogger","threadId":90,"threadPriority":5,"messageTimestamp":"2023-12-13T05:55:05.813+0000"}
{"instant":{"epochSecond":1702446905,"nanoOfSecond":814870367},"thread":"pool-10-thread-1","level":"INFO","loggerName":"com.oracle.cgbu.cnc.nrf.api.NRFClientApi","message":"Entering sendOnDemandNfDiscoverRequest function","endOfBatch":false,"loggerFqcn":"org.apache.logging.slf4j.Log4jLogger","threadId":101,"threadPriority":5,"messageTimestamp":"2023-12-13T05:55:05.814+0000"}
{"instant":{"epochSecond":1702446905,"nanoOfSecond":819222220},"thread":"pool-10-thread-1","level":"INFO","loggerName":"com.oracle.cgbu.cnc.nrf.api.NRFClientApi","message":"Send NfDiscover request with searchData: {\"targetNfType\":\"SMF\",\"serviceNames\":[\"nsmf-pdusession\"],\"requesterNfType\":\"PCF\",\"nfInfoParamsPresent\":false,\"serviceInfoParamsPresent\":true,\"enableF3\":true,\"enableF5\":false,\"targetNfSetId\":\"set001.smfset.5gc.mnc012.mcc345\",\"retentionPeriod\":5000,\"rawQueryParameters\":\"target-nf-type=SMF&requester-nf-type=PCF&target-nf-set-id=set001.smfset.5gc.mnc012.mcc345&service-names=nsmf-pdusession\",\"forceRediscoveryEnabled\":false}","endOfBatch":false,"loggerFqcn":"org.apache.logging.slf4j.Log4jLogger","threadId":101,"threadPriority":5,"messageTimestamp":"2023-12-13T05:55:05.819+0000"}
{"instant":{"epochSecond":1702446905,"nanoOfSecond":819761612},"thread":"pool-10-thread-1","level":"DEBUG","loggerName":"com.oracle.cgbu.cnc.nrf.api.NRFClientApi","message":"sendRequestToNrf nrfRequest : NRFRequest [scheme=http, rootURI=nf1stub.gi-dina.svc:8080, resourcePath=/nnrf-disc/v1/nf-instances, method=GET, body=null, headers=[], searchData={\"targetNfType\":\"SMF\",\"serviceNames\":[\"nsmf-pdusession\"],\"requesterNfType\":\"PCF\",\"nfInfoParamsPresent\":false,\"serviceInfoParamsPresent\":true,\"enableF3\":true,\"enableF5\":false,\"targetNfSetId\":\"set001.smfset.5gc.mnc012.mcc345\",\"retentionPeriod\":5000,\"rawQueryParameters\":\"target-nf-type=SMF&requester-nf-type=PCF&target-nf-set-id=set001.smfset.5gc.mnc012.mcc345&service-names=nsmf-pdusession\",\"forceRediscoveryEnabled\":false}, routeCount=0, requestType=NFDISCOVER]","endOfBatch":false,"loggerFqcn":"org.apache.logging.slf4j.Log4jLogger","threadId":101,"threadPriority":5,"messageTimestamp":"2023-12-13T05:55:05.819+0000"}
{"instant":{"epochSecond":1702446905,"nanoOfSecond":823597913},"thread":"pool-10-thread-1","level":"INFO","loggerName":"com.oracle.cgbu.cnc.nrf.api.NRFClientApi","message":"Returning retryConfig for ALL_REQUESTS NRFRetryConfig [serviceRequestType=ALL_REQUESTS, primaryNRFRetryCount=0, nonPrimaryNRFRetryCount=0, alternateNRFRetryCount=-1, errorReasonsForFailure=[503, 504, 500, SocketTimeoutException, JsonProcessingException, UnknownHostException, NoRouteToHostException], gatewayErrorCodes=[503], requestTimeout=10]","endOfBatch":false,"loggerFqcn":"org.apache.logging.slf4j.Log4jLogger","threadId":101,"threadPriority":5,"messageTimestamp":"2023-12-13T05:55:05.823+0000"}
{"instant":{"epochSecond":1702446905,"nanoOfSecond":824455718},"thread":"pool-10-thread-1","level":"DEBUG","loggerName":"com.oracle.cgbu.cnc.nrf.api.NRFClientApi","message":"Sending request to NRF nf1stub.gi-dina.svc:8080, routeCount=0, attempt=0","endOfBatch":false,"loggerFqcn":"org.apache.logging.slf4j.Log4jLogger","threadId":101,"threadPriority":5,"messageTimestamp":"2023-12-13T05:55:05.824+0000"}
{"instant":{"epochSecond":1702446905,"nanoOfSecond":824609434},"thread":"pool-10-thread-1","level":"DEBUG","loggerName":"com.oracle.cgbu.cnc.nrf.api.NRFClientApi","message":"trigger","endOfBatch":false,"loggerFqcn":"org.apache.logging.slf4j.Log4jLogger","threadId":101,"threadPriority":5,"messageTimestamp":"2023-12-13T05:55:05.824+0000"}
{"instant":{"epochSecond":1702446905,"nanoOfSecond":824752596},"thread":"pool-10-thread-1","level":"INFO","loggerName":"com.oracle.cgbu.cnc.nrf.api.NRFClientApi","message":"Returning retryConfig for ALL_REQUESTS NRFRetryConfig [serviceRequestType=ALL_REQUESTS, primaryNRFRetryCount=0, nonPrimaryNRFRetryCount=0, alternateNRFRetryCount=-1, errorReasonsForFailure=[503, 504, 500, SocketTimeoutException, JsonProcessingException, UnknownHostException, NoRouteToHostException], gatewayErrorCodes=[503], requestTimeout=10]","endOfBatch":false,"loggerFqcn":"org.apache.logging.slf4j.Log4jLogger","threadId":101,"threadPriority":5,"messageTimestamp":"2023-12-13T05:55:05.824+0000"}
{"instant":{"epochSecond":1702446905,"nanoOfSecond":928605343},"thread":"pool-10-thread-1","level":"INFO","loggerName":"com.oracle.cgbu.cnc.nrf.api.NRFClientApi","message":"Request returned response with status code : 200","endOfBatch":false,"loggerFqcn":"org.apache.logging.slf4j.Log4jLogger","threadId":101,"threadPriority":5,"messageTimestamp":"2023-12-13T05:55:05.928+0000"}
{"instant":{"epochSecond":1702446906,"nanoOfSecond":28211509},"thread":"pool-10-thread-1","level":"INFO","loggerName":"com.oracle.cgbu.cnc.nrf.api.NRFClientApi","message":"Successful Response code received","endOfBatch":false,"loggerFqcn":"org.apache.logging.slf4j.Log4jLogger","threadId":101,"threadPriority":5,"messageTimestamp":"2023-12-13T05:55:06.028+0000"}
{"instant":{"epochSecond":1702446906,"nanoOfSecond":28712480},"thread":"pool-10-thread-1","level":"INFO","loggerName":"com.oracle.cgbu.cnc.nrf.api.NRFClientApi","message":"sendOnDemandNfDiscoverRequest with searchData: {\"targetNfType\":\"SMF\",\"serviceNames\":[\"nsmf-pdusession\"],\"requesterNfType\":\"PCF\",\"nfInfoParamsPresent\":false,\"serviceInfoParamsPresent\":true,\"enableF3\":true,\"enableF5\":false,\"targetNfSetId\":\"set001.smfset.5gc.mnc012.mcc345\",\"retentionPeriod\":5000,\"...

AM Service:

Discovery of AMF for the first time:

{"instant":{"epochSecond":1702447453,"nanoOfSecond":267776264},"thread":"XNIO-1 task-2","level":"DEBUG","loggerName":"com.oracle.cgbu.cnc.nrf.core.discoveryrules.DiscoveryRule","message":"Checking if cache applies for a discovery request (DiscoveryCache feature enabled: true, OC-Force-Rediscovery requested: false)","endOfBatch":false,"loggerFqcn":"org.apache.logging.slf4j.Log4jLogger","threadId":90,"threadPriority":5,"messageTimestamp":"2023-12-13T06:04:13.267+0000"}
{"instant":{"epochSecond":1702447453,"nanoOfSecond":267885332},"thread":"XNIO-1 task-2","level":"DEBUG","loggerName":"com.oracle.cgbu.cnc.nrf.core.discoveryrules.DiscoveryRule","message":"Query Parameters validation. IsFullyMatch -> true, Params from request -> [target-nf-type, requester-nf-type, target-nf-set-id], Params from config -> [target-nf-type, requester-nf-type, service-names, target-nf-set-id]","endOfBatch":false,"loggerFqcn":"org.apache.logging.slf4j.Log4jLogger","threadId":90,"threadPriority":5,"messageTimestamp":"2023-12-13T06:04:13.267+0000"}
{"instant":{"epochSecond":1702447453,"nanoOfSecond":268118684},"thread":"XNIO-1 task-2","level":"INFO","loggerName":"com.oracle.cgbu.cnc.nrf.core.discoveryrules.DiscoveryRule","message":"DiscoveryCache is enabled and queryParameters matched. Proceeding with DiscoveryResponse retrieval from memory","endOfBatch":false,"loggerFqcn":"org.apache.logging.slf4j.Log4jLogger","threadId":90,"threadPriority":5,"messageTimestamp":"2023-12-13T06:04:13.268+0000"}
{"instant":{"epochSecond":1702447453,"nanoOfSecond":268173836},"thread":"XNIO-1 task-2","level":"DEBUG","loggerName":"com.oracle.cgbu.cnc.nrf.core.discoveryrules.DiscoveryEvaluator","message":"Rule applied: CacheRule","endOfBatch":false,"loggerFqcn":"org.apache.logging.slf4j.Log4jLogger","threadId":90,"threadPriority":5,"messageTimestamp":"2023-12-13T06:04:13.268+0000"}
{"instant":{"epochSecond":1702447453,"nanoOfSecond":268214963},"thread":"XNIO-1 task-2","level":"DEBUG","loggerName":"com.oracle.cgbu.cnc.nrf.core.discoveryrules.CacheRule","message":"Applying Cache Rule, grabbing NRF response from Cache","endOfBatch":false,"loggerFqcn":"org.apache.logging.slf4j.Log4jLogger","threadId":90,"threadPriority":5,"messageTimestamp":"2023-12-13T06:04:13.268+0000"}
{"instant":{"epochSecond":1702447453,"nanoOfSecond":279713217},"thread":"XNIO-1 task-2","level":"INFO","loggerName":"com.oracle.cgbu.cnc.nrf.core.usecases.cache.GetCacheDiscoveryResponseUseCase","message":"Unsuccessful retrieval of Discovery Response from Cache/DB, proceeding retrieval from NRF and saving response in Cache/DB","endOfBatch":false,"loggerFqcn":"org.apache.logging.slf4j.Log4jLogger","threadId":90,"threadPriority":5,"messageTimestamp":"2023-12-13T06:04:13.279+0000"}
{"instant":{"epochSecond":1702447453,"nanoOfSecond":279876856},"thread":"XNIO-1 task-2","level":"INFO","loggerName":"com.oracle.cgbu.cnc.nrf.core.usecases.nrf.GetNrfDiscoveryResponseUseCase","message":"SearchData : {\"targetNfType\":\"AMF\",\"requesterNfType\":\"PCF\",\"nfInfoParamsPresent\":false,\"serviceInfoParamsPresent\":false,\"enableF3\":true,\"enableF5\":false,\"targetNfSetId\":\"set001.region01.amfset.5gc.mnc012.mcc345\",\"retentionPeriod\":3000,\"rawQueryParameters\":\"target-nf-type=AMF&requester-nf-type=PCF&target-nf-set-id=set001.region01.amfset.5gc.mnc012.mcc345\",\"forceRediscoveryEnabled\":false}","endOfBatch":false,"loggerFqcn":"org.apache.logging.slf4j.Log4jLogger","threadId":90,"threadPriority":5,"messageTimestamp":"2023-12-13T06:04:13.279+0000"}
{"instant":{"epochSecond":1702447453,"nanoOfSecond":280256953},"thread":"pool-10-thread-1","level":"INFO","loggerName":"com.oracle.cgbu.cnc.nrf.api.NRFClientApi","message":"Entering sendOnDemandNfDiscoverRequest function","endOfBatch":false,"loggerFqcn":"org.apache.logging.slf4j.Log4jLogger","threadId":101,"threadPriority":5,"messageTimestamp":"2023-12-13T06:04:13.280+0000"}
{"instant":{"epochSecond":1702447453,"nanoOfSecond":282059938},"thread":"pool-10-thread-1","level":"INFO","loggerName":"com.oracle.cgbu.cnc.nrf.api.NRFClientApi","message":"Send NfDiscover request with searchData: {\"targetNfType\":\"AMF\",\"requesterNfType\":\"PCF\",\"nfInfoParamsPresent\":false,\"serviceInfoParamsPresent\":false,\"enableF3\":true,\"enableF5\":false,\"targetNfSetId\":\"set001.region01.amfset.5gc.mnc012.mcc345\",\"retentionPeriod\":3000,\"rawQueryParameters\":\"target-nf-type=AMF&requester-nf-type=PCF&target-nf-set-id=set001.region01.amfset.5gc.mnc012.mcc345\",\"forceRediscoveryEnabled\":false}","endOfBatch":false,"loggerFqcn":"org.apache.logging.slf4j.Log4jLogger","threadId":101,"threadPriority":5,"messageTimestamp":"2023-12-13T06:04:13.282+0000"}
{"instant":{"epochSecond":1702447453,"nanoOfSecond":282199870},"thread":"pool-10-thread-1","level":"DEBUG","loggerName":"com.oracle.cgbu.cnc.nrf.api.NRFClientApi","message":"sendRequestToNrf nrfRequest : NRFRequest [scheme=http, rootURI=nf1stub.gi-dina.svc:8080, resourcePath=/nnrf-disc/v1/nf-instances, method=GET, body=null, headers=[], searchData={\"targetNfType\":\"AMF\",\"requesterNfType\":\"PCF\",\"nfInfoParamsPresent\":false,\"serviceInfoParamsPresent\":false,\"enableF3\":true,\"enableF5\":false,\"targetNfSetId\":\"set001.region01.amfset.5gc.mnc012.mcc345\",\"retentionPeriod\":3000,\"rawQueryParameters\":\"target-nf-type=AMF&requester-nf-type=PCF&target-nf-set-id=set001.region01.amfset.5gc.mnc012.mcc345\",\"forceRediscoveryEnabled\":false}, routeCount=0, requestType=NFDISCOVER]","endOfBatch":false,"loggerFqcn":"org.apache.logging.slf4j.Log4jLogger","threadId":101,"threadPriority":5,"messageTimestamp":"2023-12-13T06:04:13.282+0000"}
{"instant":{"epochSecond":1702447453,"nanoOfSecond":282424344},"thread":"pool-10-thread-1","level":"INFO","loggerName":"com.oracle.cgbu.cnc.nrf.api.NRFClientApi","message":"Returning retryConfig for ALL_REQUESTS NRFRetryConfig [serviceRequestType=ALL_REQUESTS, primaryNRFRetryCount=0, nonPrimaryNRFRetryCount=0, alternateNRFRetryCount=-1, errorReasonsForFailure=[503, 504, 500, SocketTimeoutException, JsonProcessingException, UnknownHostException, NoRouteToHostException], gatewayErrorCodes=[503], requestTimeout=10]","endOfBatch":false,"loggerFqcn":"org.apache.logging.slf4j.Log4jLogger","threadId":101,"threadPriority":5,"messageTimestamp":"2023-12-13T06:04:13.282+0000"}
{"instant":{"epochSecond":1702447453,"nanoOfSecond":282532830},"thread":"pool-10-thread-1","level":"DEBUG","loggerName":"com.oracle.cgbu.cnc.nrf.api.NRFClientApi","message":"Sending request to NRF nf1stub.gi-dina.svc:8080, routeCount=0, attempt=0","endOfBatch":false,"loggerFqcn":"org.apache.logging.slf4j.Log4jLogger","threadId":101,"threadPriority":5,"messageTimestamp":"2023-12-13T06:04:13.282+0000"}
{"instant":{"epochSecond":1702447453,"nanoOfSecond":282579698},"thread":"pool-10-thread-1","level":"DEBUG","loggerName":"com.oracle.cgbu.cnc.nrf.api.NRFClientApi","message":"trigger","endOfBatch":false,"loggerFqcn":"org.apache.logging.slf4j.Log4jLogger","threadId":101,"threadPriority":5,"messageTimestamp":"2023-12-13T06:04:13.282+0000"}
{"instant":{"epochSecond":1702447453,"nanoOfSecond":282628294},"thread":"pool-10-thread-1","level":"INFO","loggerName":"com.oracle.cgbu.cnc.nrf.api.NRFClientApi","message":"Returning retryConfig for ALL_REQUESTS NRFRetryConfig [serviceRequestType=ALL_REQUESTS, primaryNRFRetryCount=0, nonPrimaryNRFRetryCount=0, alternateNRFRetryCount=-1, errorReasonsForFailure=[503, 504, 500, SocketTimeoutException, JsonProcessingException, UnknownHostException, NoRouteToHostException], gatewayErrorCodes=[503], requestTimeout=10]","endOfBatch":false,"loggerFqcn":"org.apache.logging.slf4j.Log4jLogger","threadId":101,"threadPriority":5,"messageTimestamp":"2023-12-13T06:04:13.282+0000"}
{"instant":{"epochSecond":1702447453,"nanoOfSecond":306471240},"thread":"pool-10-thread-1","level":"INFO","loggerName":"com.oracle.cgbu.cnc.nrf.api.NRFClientApi","message":"Request returned response with status code : 200","endOfBatch":false,"loggerFqcn":"org.apache.logging.slf4j.Log4jLogger","threadId":101,"threadPriority":5,"messageTimestamp":"2023-12-13T06:04:13.306+0000"}
{"instant":{"epochSecond":1702447453,"nanoOfSecond":311674972},"thread":"pool-10-thread-1","level":"INFO","loggerName":"com.oracle.cgbu.cnc.nrf.api.NRFClientApi","message":"Successful Response code received","endOfBatch":false,"loggerFqcn":"org.apache.logging.slf4j.Log4jLogger","threadId":101,"threadPriority":5,"messageTimestamp":"2023-12-13T06:04:13.311+0000"}
{"instant":{"epochSecond":1702447453,"nanoOfSecond":311771862},"thread":"pool-10-thread-1","level":"INFO","loggerName":"com.oracle.cgbu.cnc.nrf.api.NRFClientApi","message":"sendOnDemandNfDiscoverRequest with searchData: {\"targetNfType\":\"AMF\",\"requesterNfType\":\"PCF\",\"nfInfoParamsPresent\":false,\"serviceInfoParamsPresent\":false,\"enableF3\":true,\"enableF5\":false,\"targetNfSetId\":\"set001.region01.amfset.5gc.mnc012.mcc345\",\"retentionPeriod\":3000,\"rawQueryParameters\":\"target-nf-type=AMF&requester-nf-type=PCF&target-nf-set-id=set001.region01.amfset.5gc.mnc012.mcc345\",\"forceRediscoveryEnabled\":false} returned status code : 200","endOfBatch":false,"loggerFqcn":"org.apache.logging.slf4j.Log4jLogger","threadId":101,"threadPriority":5,"messageTimestamp":"2023-12-13T06:04:13.311+0000"}
{"instant":{"epochSecond":1702447453,"nanoOfSecond":311992401},"thread":"XNIO-1 task-2","level":"INFO","loggerName":"com.oracle.cgbu.cnc.nrf.core.usecases.nrf.GetNrfDiscoveryResponseUseCase","message":"Received Discovery Result. Code: 200, Body (SearchResult): {\"validityPeriod\": 300, \"nfInstances\": [{\"nfInstanceId\": \"13515195-c537-4645-9b97-96ec797faaaf\", \"nfSetIdList\": [\"set001.region01.amfset.5gc.mnc012.mcc345\"], \"allowedNfTypes\": [\"PCF\", \"SMF\"], \"nfType\": \"AMF\", \"plmnList\": [{\"mcc\": \"450\", \"mnc\": \"05\"}], \"nfStatus\": \"REGISTERED\", \"fqdn\": \"nf2stub.gi-dina.svc\", \"priority\": 1, \"capacity\": 100, \"load\": 50, \"locality\": \"1\", \"amfInfo\": {\"amfRegionId\": \"01\", \"amfSetId\": \"001\", \"guamiList\": [{\"plmnId\": {\"mcc\": \"450\", \"mnc\": \"05\"}, \"amfId\": \"010041\"}]}, \"nfServices\": [{\"serviceInstanceId\": \"aaaa-bbbb-cccc-dddd\", \"serviceName\": \"namf-comm\", \"versions\": [{\"apiVersionInUri\": \"v1\", \"apiFullVersion\": \"1.1.0\", \"expiry\": \"2020-07-30T12:09:55.65Z\"}], \"scheme\": \"http\", \"nfServiceStatus\": \"REGISTERED\", \"ipEndPoints\": [{\"ipv4Address\": null, \"ipv6Address\": null, \"transport\": \"TCP\", \"port\": 8080}], \"allowedPlmns\": [{\"mcc\": \"450\", \"mnc\": \"05\"}]}]}, {\"nfInstanceId\": \"13515195-c537-4645-9b97-96ec797fbbbf\", \"nfSetIdList\": [\"set001.region01.amfset.5gc.mnc012.mcc345\"], \"allowedNfTypes\": [\"PCF\", \"SMF\"], \"nfType\": \"AMF\", \"plmnList\": [{\"mcc\": \"450\", \"mnc\": \"05\"}], \"nfStatus\": \"REGISTERED\", \"fqdn\": \"nf21stub.gi-dina.svc\", \"priority\": 2, \"capacity\": 100, \"load\": 50, \"locality\": \"1\", \"amfInfo\": {\"amfRegionId\": \"01\", \"amfSetId\": \"001\", \"guamiList\": [{\"plmnId\": {\"mcc\": \"450\", \"mnc\": \"05\"}, \"amfId\": \"010041\"}]}, \"nfServices\": [{\"serviceInstanceId\": \"aaaa-bbbb-cccc-dddd\", \"serviceName\": \"namf-comm\", \"versions\": [{\"apiVersionInUri\": \"v1\", \"apiFullVersion\": \"1.1.0\", \"expiry\": \"2020-07-30T12:09:55.65Z\"}], \"scheme\": \"http\", \"nfServiceStatus\": \"REGISTERED\", \"ipEndPoints\": [{\"ipv4Address\": null, \"ipv6Address\": null, \"transport\": \"TCP\", \"port\": 8080}], \"allowedPlmns\": [{\"mcc\": \"450\", \"mnc\": \"05\"}]}]}, {\"nfInstanceId\": \"13515195-c537-4645-9b97-96ec797fcccf\", \"nfSetIdList\": [\"set001.region01.amfset.5gc.mnc012.mcc345\"], \"allowedNfTypes\": [\"PCF\", \"SMF\"], \"nfType\": \"AMF\", \"plmnList\": [{\"mcc\": \"450\", \"mnc\": \"05\"}], \"nfStatus\": \"REGISTERED\", \"fqdn\": \"nf3stub.gi-dina.svc\", \"priority\": 4, \"capacity\": 100, \"load\": 60, \"locality\": \"2\", \"amfInfo\": {\"amfRegionId\": \"01\", \"amfSetId\": \"001\", \"guamiList\": [{\"plmnId\": {\"mcc\": \"450\", \"mnc\": \"05\"}, \"amfId\": \"010041\"}]}, \"nfServices\": [{\"serviceInstanceId\": \"aaaa-bbbb-cccc-dddd\", \"serviceName\": \"namf-comm\", \"versions\": [{\"apiVersionInUri\": \"v1\", \"apiFullVersion\": \"1.1.0\", \"expiry\": \"2020-07-30T12:09:55.65Z\"}], \"scheme\": \"http\", \"nfServiceStatus\": \"REGISTERED\", \"ipEndPoints\": [{\"ipv4Address\": null, \"ipv6Address\": null, \"transport\": \"TCP\", \"port\": 8080}], \"allowedPlmns\": [{\"mcc\": \"450\", \"mnc\": \"05\"}]}]}, {\"nfInstanceId\": \"13515195-c537-4645-9b97-96ec797fdddf\", \"nfSetIdList\": [\"set001.region01.amfset.5gc.mnc012.mcc345\"], \"allowedNfTypes\": [\"PCF\", \"SMF\"], \"nfType\": \"AMF\", \"plmnList\": [{\"mcc\": \"450\", \"mnc\": \"05\"}], \"nfStatus\": \"REGISTERED\", \"fqdn\": \"nf31stub.gi-dina.svc\", \"priority\": 2, \"capacity\": 100, \"load\": 50, \"locality\": \"2\", \"amfInfo\": {\"amfRegionId\": \"01\", \"amfSetId\": \"001\", \"guamiList\": [{\"plmnId\": {\"mcc\": \"450\", \"mnc\": \"05\"}, \"amfId\": \"010041\"}]}, \"nfServices\": [{\"serviceInstanceId\": \"aaaa-bbbb-cccc-dddd\", \"serviceName\": \"namf-comm\", \"versions\": [{\"apiVersionInUri\": \"v1\", \"apiFullVersion\": \"1.1.0\", \"expiry\": \"2020-07-30T12:09:55.65Z\"}], \"scheme\": \"http\", \"nfServiceStatus\": \"REGISTERED\", \"ipEndPoints\": [{\"ipv4Address\": null, \"ipv6Address\": null, \"transport\": \"TCP\", \"port\": 8080}], \"allowedPlmns\": [{\"mcc\": \"450\", \"mnc\": \"05\"}]}]}, {\"nfInstanceId\": \"13515195-c537-4645-9b97-96ec797feeef\", \"nfSetIdList\": [\"set001.region01.amfset.5gc.mnc012.mcc345\"], \"allowedNfTypes\": [\"PCF\", \"SMF\"], \"nfType\": \"AMF\", \"plmnList\": [{\"mcc\": \"450\", \"mnc\": \"05\"}], \"nfStatus\": \"REGISTERED\", \"fqdn\": \"nf32stub.gi-dina.svc\", \"priority\": 5, \"capacity\": 100, \"load\": 60, \"locality\": \"2\", \"amfInfo\": {\"amfRegionId\": \"01\", \"amfSetId\": \"001\", \"guamiList\": [{\"plmnId\": {\"mcc\": \"450\", \"mnc\": \"05\"}, \"amfId\": \"010041\"}]}, \"nfServices\": [{\"serviceInstanceId\": \"aaaa-bbbb-cccc-dddd\", \"serviceName\": \"namf-comm\", \"versions\": [{\"apiVersionInUri\": \"v1\", \"apiFullVersion\": \"1.1.0\", \"expiry\": \"2020-07-30T12:09:55.65Z\"}], \"scheme\": \"http\", \"nfServiceStatus\": \"REGISTERED\", \"ipEndPoints\": [{\"ipv4Address\": null, \"ipv6Address\": null, \"transport\": \"TCP\", \"port\": 8080}], \"allowedPlmns\": [{\"mcc\": \"450\", \"mnc\": \"05\"}]}]}]}","endOfBatch":false,"loggerFqcn":"org.apache.logging.slf4j.Log4jLogger","threadId":90,"threadPriority":5,"messageTimestamp":"2023-12-13T06:04:13.311+0000"}
{"instant":{"epochSecond":1702447453,"nanoOfSecond":313001061},"thread":"XNIO-1 task-2","level":"INFO","loggerName":"com.oracle.cgbu.cnc.nrf.core.usecases.nrf.GetNrfDiscoveryResponseUseCase","message":"Dynamic discovery cache enabled : false","endOfBatch":false,"loggerFqcn":"org.apache.logging.slf4j.Log4jLogger","threadId":90,"threadPriority":5,"messageTimestamp":"2023-12-13T06:04:13.313+0000"}
{"instant":{"epochSecond":1702447453,"nanoOfSecond":353052224},"thread":"XNIO-1 task-2","level":"INFO","loggerName":"com.oracle.cgbu.cnc.nrf.core.usecases.cache.GetCacheDiscoveryResponseUseCase","message":"Discovery Response fetched : DiscoverySearchResult{queryParams='target-nf-type=AMF&requester-nf-type=PCF&target-nf-set-id=set001.region01.amfset.5gc.mnc012.mcc345', searchResult={\"validityPeriod\":300,\"nfInstances\":[{\"nfInstanceId\":\"13515195-c537-4645-9b97-96ec797faaaf\",\"nfType\":\"AMF\",\"nfStatus\":\"REGISTERED\",\"plmnList\":[{\"mcc\":\"450\",\"mnc\":\"05\"}],\"fqdn\":\"nf2stub.gi-dina.svc\",\"allowedNfTypes\":[\"PCF\",\"SMF\"],\"priority\":1,\"capacity\":100,\"load\":50,\"locality\":\"1\",\"nfSetIdList\":[\"set001.region01.amfset.5gc.mnc012.mcc345\"],\"amfInfo\":{\"amfSetId\":\"001\",\"amfRegionId\":\"01\",\"guamiList\":[{\"plmnId\":{\"mcc\":\"450\",\"mnc\":\"05\"},\"amfId\":\"010041\"}]},\"nfServices\":[{\"serviceInstanceId\":\"aaaa-bbbb-cccc-dddd\",\"serviceName\":\"namf-comm\",\"versions\":[{\"apiVersionInUri\":\"v1\",\"apiFullVersion\":\"1.1.0\",\"expiry\":\"2020-07-30T12:09:55.650Z\"}],\"scheme\":\"http\",\"nfServiceStatus\":\"REGISTERED\",\"ipEndPoints\":[{\"transport\":\"TCP\",\"port\":8080}],\"allowedPlmns\":[{\"mcc\":\"450\",\"mnc\":\"05\"}]}]},{\"nfInstanceId\":\"13515195-c537-4645-9b97-96ec797fbbbf\",\"nfType\":\"AMF\",\"nfStatus\":\"REGISTERED\",\"plmnList\":[{\"mcc\":\"450\",\"mnc\":\"05\"}],\"fqdn\":\"nf21stub.gi-dina.svc\",\"allowedNfTypes\":[\"PCF\",\"SMF\"],\"priority\":2,\"capacity\":100,\"load\":50,\"locality\":\"1\",\"nfSetIdList\":[\"set001.region01.amfset.5gc.mnc012.mcc345\"],\"amfInfo\":{\"amfSetId\":\"001\",\"amfRegionId\":\"01\",\"guamiList\":[{\"plmnId\":{\"mcc\":\"450\",\"mnc\":\"05\"},\"amfId\":\"010041\"}]},\"nfServices\":[{\"serviceInstanceId\":\"aaaa-bbbb-cccc-dddd\",\"serviceName\":\"namf-comm\",\"versions\":[{\"apiVersionInUri\":\"v1\",\"apiFullVersion\":\"1.1.0\",\"expiry\":\"2020-07-30T12:09:55.650Z\"}],\"scheme\":\"http\",\"nfServiceStatus\":\"REGISTERED\",\"ipEndPoints\":[{\"transport\":\"TCP\",\"port\":8080}],\"allowedPlmns\":[{\"mcc\":\"450\",\"mnc\":\"05\"}]}]},{\"nfInstanceId\":\"13515195-c537-4645-9b97-96ec797fcccf\",\"nfType\":\"AMF\",\"nfStatus\":\"REGISTERED\",\"plmnList\":[{\"mcc\":\"450\",\"mnc\":\"05\"}],\"fqdn\":\"nf3stub.gi-dina.svc\",\"allowedNfTypes\":[\"PCF\",\"SMF\"],\"priority\":4,\"capacity\":100,\"load\":60,\"locality\":\"2\",\"nfSetIdList\":[\"set001.region01.amfset.5gc.mnc012.mcc345\"],\"amfInfo\":{\"amfSetId\":\"001\",\"amfRegionId\":\"01\",\"guamiList\":[{\"plmnId\":{\"mcc\":\"450\",\"mnc\":\"05\"},\"amfId\":\"010041\"}]},\"nfServices\":[{\"serviceInstanceId\":\"aaaa-bbbb-cccc-dddd\",\"serviceName\":\"namf-comm\",\"versions\":[{\"apiVersionInUri\":\"v1\",\"apiFullVersion\":\"1.1.0\",\"expiry\":\"2020-07-30T12:09:55.650Z\"}],\"scheme\":\"http\",\"nfServiceStatus\":\"REGISTERED\",\"ipEndPoints\":[{\"transport\":\"TCP\",\"port\":8080}],\"allowedPlmns\":[{\"mcc\":\"450\",\"mnc\":\"05\"}]}]},{\"nfInstanceId\":\"13515195-c537-4645-9b97-96ec797fdddf\",\"nfType\":\"AMF\",\"nfStatus\":\"REGISTERED\",\"plmnList\":[{\"mcc\":\"450\",\"mnc\":\"05\"}],\"fqdn\":\"nf31stub.gi-dina.svc\",\"allowedNfTypes\":[\"PCF\",\"SMF\"],\"priority\":2,\"capacity\":100,\"load\":50,\"locality\":\"2\",\"nfSetIdList\":[\"set001.region01.amfset.5gc.mnc012.mcc345\"],\"amfInfo\":{\"amfSetId\":\"001\",\"amfRegionId\":\"01\",\"guamiList\":[{\"plmnId\":{\"mcc\":\"450\",\"mnc\":\"05\"},\"amfId\":\"010041\"}]},\"nfServices\":[{\"serviceInstanceId\":\"aaaa-bbbb-cccc-dddd\",\"serviceName\":\"namf-comm\",\"versions\":[{\"apiVersionInUri\":\"v1\",\"apiFullVersion\":\"1.1.0\",\"expiry\":\"2020-07-30T12:09:55.650Z\"}],\"scheme\":\"http\",\"nfServiceStatus\":\"REGISTERED\",\"ipEndPoints\":[{\"transport\":\"TCP\",\"port\":8080}],\"allowedPlmns\":[{\"mcc\":\"450\",\"mnc\":\"05\"}]}]},{\"nfInstanceId\":\"13515195-c537-4645-9b97-96ec797feeef\",\"nfType\":\"AMF\",\"nfStatus\":\"REGISTERED\",\"plmnList\":[{\"mcc\":\"450\",\"mnc\":\"05\"}],\"fqdn\":\"nf32stub.gi-dina.svc\",\"allowedNfTypes\":[\"PCF\",\"SMF\"],\"priority\":5,\"capacity\":100,\"load\":60,\"locality\":\"2\",\"nfSetIdList\":[\"set001.region01.amfset.5gc.mnc012.mcc345\"],\"amfInfo\":{\"amfSetId\":\"001\",\"amfRegionId\":\"01\",\"guamiList\":[{\"plmnId\":{\"mcc\":\"450\",\"mnc\":\"05\"},\"amfId\":\"010041\"}]},\"nfServices\":[{\"serviceInstanceId\":\"aaaa-bbbb-cccc-dddd\",\"serviceName\":\"namf-comm\",\"versions\":[{\"apiVersionInUri\":\"v1\",\"apiFullVersion\":\"1.1.0\",\"expiry\":\"2020-07-30T12:09:55.650Z\"}],\"scheme\":\"http\",\"nfServiceStatus\":\"REGISTERED\",\"ipEndPoints\":[{\"transport\":\"TCP\",\"port\":8080}],\"allowedPlmns\":[{\"mcc\":\"450\",\"mnc\":\"05\"}]}]}],\"nrfSupportedFeatures\":\"72\"}, sourceType=NRF}","endOfBatch":false,"loggerFqcn":"org.apache.logging.slf4j.Log4jLogger","threadId":90,"threadPriority":5,"messageTimestamp":"2023-12-13T06:04:13.353+0000"}




Discovery of AMF for the second time

{"instant":{"epochSecond":1702447495,"nanoOfSecond":560602127},"thread":"XNIO-1 task-2","level":"DEBUG","loggerName":"com.oracle.cgbu.cnc.nrf.core.discoveryrules.DiscoveryRule","message":"Checking if cache applies for a discovery request (DiscoveryCache feature enabled: true, OC-Force-Rediscovery requested: false)","endOfBatch":false,"loggerFqcn":"org.apache.logging.slf4j.Log4jLogger","threadId":90,"threadPriority":5,"messageTimestamp":"2023-12-13T06:04:55.560+0000"}
{"instant":{"epochSecond":1702447495,"nanoOfSecond":560665276},"thread":"XNIO-1 task-2","level":"DEBUG","loggerName":"com.oracle.cgbu.cnc.nrf.core.discoveryrules.DiscoveryRule","message":"Query Parameters validation. IsFullyMatch -> true, Params from request -> [target-nf-type, requester-nf-type, target-nf-set-id], Params from config -> [target-nf-type, requester-nf-type, service-names, target-nf-set-id]","endOfBatch":false,"loggerFqcn":"org.apache.logging.slf4j.Log4jLogger","threadId":90,"threadPriority":5,"messageTimestamp":"2023-12-13T06:04:55.560+0000"}
{"instant":{"epochSecond":1702447495,"nanoOfSecond":560736605},"thread":"XNIO-1 task-2","level":"INFO","loggerName":"com.oracle.cgbu.cnc.nrf.core.discoveryrules.DiscoveryRule","message":"DiscoveryCache is enabled and queryParameters matched. Proceeding with DiscoveryResponse retrieval from memory","endOfBatch":false,"loggerFqcn":"org.apache.logging.slf4j.Log4jLogger","threadId":90,"threadPriority":5,"messageTimestamp":"2023-12-13T06:04:55.560+0000"}
{"instant":{"epochSecond":1702447495,"nanoOfSecond":560773857},"thread":"XNIO-1 task-2","level":"DEBUG","loggerName":"com.oracle.cgbu.cnc.nrf.core.discoveryrules.DiscoveryEvaluator","message":"Rule applied: CacheRule","endOfBatch":false,"loggerFqcn":"org.apache.logging.slf4j.Log4jLogger","threadId":90,"threadPriority":5,"messageTimestamp":"2023-12-13T06:04:55.560+0000"}
{"instant":{"epochSecond":1702447495,"nanoOfSecond":560806304},"thread":"XNIO-1 task-2","level":"DEBUG","loggerName":"com.oracle.cgbu.cnc.nrf.core.discoveryrules.CacheRule","message":"Applying Cache Rule, grabbing NRF response from Cache","endOfBatch":false,"loggerFqcn":"org.apache.logging.slf4j.Log4jLogger","threadId":90,"threadPriority":5,"messageTimestamp":"2023-12-13T06:04:55.560+0000"}
{"instant":{"epochSecond":1702447495,"nanoOfSecond":578396526},"thread":"XNIO-1 task-2","level":"INFO","loggerName":"com.oracle.cgbu.cnc.nrf.core.usecases.cache.GetCacheDiscoveryResponseUseCase","message":"Successful retrieval of Discovery Response stored in Cache/DB, proceeding with validation","endOfBatch":false,"loggerFqcn":"org.apache.logging.slf4j.Log4jLogger","threadId":90,"threadPriority":5,"messageTimestamp":"2023-12-13T06:04:55.578+0000"}
{"instant":{"epochSecond":1702447495,"nanoOfSecond":578450087},"thread":"XNIO-1 task-2","level":"INFO","loggerName":"com.oracle.cgbu.cnc.nrf.core.usecases.cache.GetCacheDiscoveryResponseUseCase","message":"Discovery Response retrieved from Cache/DB isAboutToExpire value : false ","endOfBatch":false,"loggerFqcn":"org.apache.logging.slf4j.Log4jLogger","threadId":90,"threadPriority":5,"messageTimestamp":"2023-12-13T06:04:55.578+0000"}
{"instant":{"epochSecond":1702447495,"nanoOfSecond":578490288},"thread":"XNIO-1 task-2","level":"INFO","loggerName":"com.oracle.cgbu.cnc.nrf.core.usecases.cache.GetCacheDiscoveryResponseUseCase","message":"Discovery Response retrieved from Cache/DB is expired value : false ","endOfBatch":false,"loggerFqcn":"org.apache.logging.slf4j.Log4jLogger","threadId":90,"threadPriority":5,"messageTimestamp":"2023-12-13T06:04:55.578+0000"}
{"instant":{"epochSecond":1702447495,"nanoOfSecond":589440279},"thread":"XNIO-1 task-2","level":"INFO","loggerName":"com.oracle.cgbu.cnc.nrf.core.usecases.cache.GetCacheDiscoveryResponseUseCase","message":"Discovery Response fetched : DiscoverySearchResult{queryParams='target-nf-type=AMF&requester-nf-type=PCF&target-nf-set-id=set001.region01.amfset.5gc.mnc012.mcc345', searchResult={\"validityPeriod\":300,\"nfInstances\":[{\"nfInstanceId\":\"13515195-c537-4645-9b97-96ec797faaaf\",\"nfType\":\"AMF\",\"nfStatus\":\"REGISTERED\",\"plmnList\":[{\"mcc\":\"450\",\"mnc\":\"05\"}],\"fqdn\":\"nf2stub.gi-dina.svc\",\"allowedNfTypes\":[\"PCF\",\"SMF\"],\"priority\":1,\"capacity\":100,\"load\":50,\"locality\":\"1\",\"nfSetIdList\":[\"set001.region01.amfset.5gc.mnc012.mcc345\"],\"amfInfo\":{\"amfSetId\":\"001\",\"amfRegionId\":\"01\",\"guamiList\":[{\"plmnId\":{\"mcc\":\"450\",\"mnc\":\"05\"},\"amfId\":\"010041\"}]},\"nfServices\":[{\"serviceInstanceId\":\"aaaa-bbbb-cccc-dddd\",\"serviceName\":\"namf-comm\",\"versions\":[{\"apiVersionInUri\":\"v1\",\"apiFullVersion\":\"1.1.0\",\"expiry\":\"2020-07-30T12:09:55.650Z\"}],\"scheme\":\"http\",\"nfServiceStatus\":\"REGISTERED\",\"ipEndPoints\":[{\"transport\":\"TCP\",\"port\":8080}],\"allowedPlmns\":[{\"mcc\":\"450\",\"mnc\":\"05\"}]}]},{\"nfInstanceId\":\"13515195-c537-4645-9b97-96ec797fbbbf\",\"nfType\":\"AMF\",\"nfStatus\":\"REGISTERED\",\"plmnList\":[{\"mcc\":\"450\",\"mnc\":\"05\"}],\"fqdn\":\"nf21stub.gi-dina.svc\",\"allowedNfTypes\":[\"PCF\",\"SMF\"],\"priority\":2,\"capacity\":100,\"load\":50,\"locality\":\"1\",\"nfSetIdList\":[\"set001.region01.amfset.5gc.mnc012.mcc345\"],\"amfInfo\":{\"amfSetId\":\"001\",\"amfRegionId\":\"01\",\"guamiList\":[{\"plmnId\":{\"mcc\":\"450\",\"mnc\":\"05\"},\"amfId\":\"010041\"}]},\"nfServices\":[{\"serviceInstanceId\":\"aaaa-bbbb-cccc-dddd\",\"serviceName\":\"namf-comm\",\"versions\":[{\"apiVersionInUri\":\"v1\",\"apiFullVersion\":\"1.1.0\",\"expiry\":\"2020-07-30T12:09:55.650Z\"}],\"scheme\":\"http\",\"nfServiceStatus\":\"REGISTERED\",\"ipEndPoints\":[{\"transport\":\"TCP\",\"port\":8080}],\"allowedPlmns\":[{\"mcc\":\"450\",\"mnc\":\"05\"}]}]},{\"nfInstanceId\":\"13515195-c537-4645-9b97-96ec797fcccf\",\"nfType\":\"AMF\",\"nfStatus\":\"REGISTERED\",\"plmnList\":[{\"mcc\":\"450\",\"mnc\":\"05\"}],\"fqdn\":\"nf3stub.gi-dina.svc\",\"allowedNfTypes\":[\"PCF\",\"SMF\"],\"priority\":4,\"capacity\":100,\"load\":60,\"locality\":\"2\",\"nfSetIdList\":[\"set001.region01.amfset.5gc.mnc012.mcc345\"],\"amfInfo\":{\"amfSetId\":\"001\",\"amfRegionId\":\"01\",\"guamiList\":[{\"plmnId\":{\"mcc\":\"450\",\"mnc\":\"05\"},\"amfId\":\"010041\"}]},\"nfServices\":[{\"serviceInstanceId\":\"aaaa-bbbb-cccc-dddd\",\"serviceName\":\"namf-comm\",\"versions\":[{\"apiVersionInUri\":\"v1\",\"apiFullVersion\":\"1.1.0\",\"expiry\":\"2020-07-30T12:09:55.650Z\"}],\"scheme\":\"http\",\"nfServiceStatus\":\"REGISTERED\",\"ipEndPoints\":[{\"transport\":\"TCP\",\"port\":8080}],\"allowedPlmns\":[{\"mcc\":\"450\",\"mnc\":\"05\"}]}]},{\"nfInstanceId\":\"13515195-c537-4645-9b97-96ec797fdddf\",\"nfType\":\"AMF\",\"nfStatus\":\"REGISTERED\",\"plmnList\":[{\"mcc\":\"450\",\"mnc\":\"05\"}],\"fqdn\":\"nf31stub.gi-dina.svc\",\"allowedNfTypes\":[\"PCF\",\"SMF\"],\"priority\":2,\"capacity\":100,\"load\":50,\"locality\":\"2\",\"nfSetIdList\":[\"set001.region01.amfset.5gc.mnc012.mcc345\"],\"amfInfo\":{\"amfSetId\":\"001\",\"amfRegionId\":\"01\",\"guamiList\":[{\"plmnId\":{\"mcc\":\"450\",\"mnc\":\"05\"},\"amfId\":\"010041\"}]},\"nfServices\":[{\"serviceInstanceId\":\"aaaa-bbbb-cccc-dddd\",\"serviceName\":\"namf-comm\",\"versions\":[{\"apiVersionInUri\":\"v1\",\"apiFullVersion\":\"1.1.0\",\"expiry\":\"2020-07-30T12:09:55.650Z\"}],\"scheme\":\"http\",\"nfServiceStatus\":\"REGISTERED\",\"ipEndPoints\":[{\"transport\":\"TCP\",\"port\":8080}],\"allowedPlmns\":[{\"mcc\":\"450\",\"mnc\":\"05\"}]}]},{\"nfInstanceId\":\"13515195-c537-4645-9b97-96ec797feeef\",\"nfType\":\"AMF\",\"nfStatus\":\"REGISTERED\",\"plmnList\":[{\"mcc\":\"450\",\"mnc\":\"05\"}],\"fqdn\":\"nf32stub.gi-dina.svc\",\"allowedNfTypes\":[\"PCF\",\"SMF\"],\"priority\":5,\"capacity\":100,\"load\":60,\"locality\":\"2\",\"nfSetIdList\":[\"set001.region01.amfset.5gc.mnc012.mcc345\"],\"amfInfo\":{\"amfSetId\":\"001\",\"amfRegionId\":\"01\",\"guamiList\":[{\"plmnId\":{\"mcc\":\"450\",\"mnc\":\"05\"},\"amfId\":\"010041\"}]},\"nfServices\":[{\"serviceInstanceId\":\"aaaa-bbbb-cccc-dddd\",\"serviceName\":\"namf-comm\",\"versions\":[{\"apiVersionInUri\":\"v1\",\"apiFullVersion\":\"1.1.0\",\"expiry\":\"2020-07-30T12:09:55.650Z\"}],\"scheme\":\"http\",\"nfServiceStatus\":\"REGISTERED\",\"ipEndPoints\":[{\"transport\":\"TCP\",\"port\":8080}],\"allowedPlmns\":[{\"mcc\":\"450\",\"mnc\":\"05\"}]}]}],\"nrfSupportedFeatures\":\"72\"}, sourceType=CACHE}","endOfBatch":false,"loggerFqcn":"org.apache.logging.slf4j.Log4jLogger","threadId":90,"threadPriority":5,"messageTimestamp":"2023-12-13T06:04:55.589+0000"}

UE Policy Service:

Discovery of AMF for UE policy Association for the first time:

{"instant":{"epochSecond":1702447646,"nanoOfSecond":16500495},"thread":"XNIO-1 task-2","level":"DEBUG","loggerName":"com.oracle.cgbu.cnc.nrf.core.discoveryrules.DiscoveryRule","message":"Checking if cache applies for a discovery request (DiscoveryCache feature enabled: true, OC-Force-Rediscovery requested: false)","endOfBatch":false,"loggerFqcn":"org.apache.logging.slf4j.Log4jLogger","threadId":90,"threadPriority":5,"messageTimestamp":"2023-12-13T06:07:26.016+0000"}
{"instant":{"epochSecond":1702447646,"nanoOfSecond":16566854},"thread":"XNIO-1 task-2","level":"DEBUG","loggerName":"com.oracle.cgbu.cnc.nrf.core.discoveryrules.DiscoveryRule","message":"Query Parameters validation. IsFullyMatch -> true, Params from request -> [target-nf-type, requester-nf-type, target-nf-set-id], Params from config -> [target-nf-type, requester-nf-type, target-nf-set-id]","endOfBatch":false,"loggerFqcn":"org.apache.logging.slf4j.Log4jLogger","threadId":90,"threadPriority":5,"messageTimestamp":"2023-12-13T06:07:26.016+0000"}
{"instant":{"epochSecond":1702447646,"nanoOfSecond":16634530},"thread":"XNIO-1 task-2","level":"INFO","loggerName":"com.oracle.cgbu.cnc.nrf.core.discoveryrules.DiscoveryRule","message":"DiscoveryCache is enabled and queryParameters matched. Proceeding with DiscoveryResponse retrieval from memory","endOfBatch":false,"loggerFqcn":"org.apache.logging.slf4j.Log4jLogger","threadId":90,"threadPriority":5,"messageTimestamp":"2023-12-13T06:07:26.016+0000"}
{"instant":{"epochSecond":1702447646,"nanoOfSecond":16668622},"thread":"XNIO-1 task-2","level":"DEBUG","loggerName":"com.oracle.cgbu.cnc.nrf.core.discoveryrules.DiscoveryEvaluator","message":"Rule applied: CacheRule","endOfBatch":false,"loggerFqcn":"org.apache.logging.slf4j.Log4jLogger","threadId":90,"threadPriority":5,"messageTimestamp":"2023-12-13T06:07:26.016+0000"}
{"instant":{"epochSecond":1702447646,"nanoOfSecond":16697142},"thread":"XNIO-1 task-2","level":"DEBUG","loggerName":"com.oracle.cgbu.cnc.nrf.core.discoveryrules.CacheRule","message":"Applying Cache Rule, grabbing NRF response from Cache","endOfBatch":false,"loggerFqcn":"org.apache.logging.slf4j.Log4jLogger","threadId":90,"threadPriority":5,"messageTimestamp":"2023-12-13T06:07:26.016+0000"}
{"instant":{"epochSecond":1702447646,"nanoOfSecond":26184667},"thread":"XNIO-1 task-2","level":"INFO","loggerName":"com.oracle.cgbu.cnc.nrf.core.usecases.cache.GetCacheDiscoveryResponseUseCase","message":"Unsuccessful retrieval of Discovery Response from Cache/DB, proceeding retrieval from NRF and saving response in Cache/DB","endOfBatch":false,"loggerFqcn":"org.apache.logging.slf4j.Log4jLogger","threadId":90,"threadPriority":5,"messageTimestamp":"2023-12-13T06:07:26.026+0000"}
{"instant":{"epochSecond":1702447646,"nanoOfSecond":26250918},"thread":"XNIO-1 task-2","level":"INFO","loggerName":"com.oracle.cgbu.cnc.nrf.core.usecases.nrf.GetNrfDiscoveryResponseUseCase","message":"SearchData : {\"targetNfType\":\"AMF\",\"requesterNfType\":\"PCF\",\"nfInfoParamsPresent\":false,\"serviceInfoParamsPresent\":false,\"enableF3\":true,\"enableF5\":false,\"targetNfSetId\":\"set001.region48.amfset.5gc.mnc012.mcc345\",\"retentionPeriod\":5000,\"rawQueryParameters\":\"target-nf-type=AMF&requester-nf-type=PCF&target-nf-set-id=set001.region48.amfset.5gc.mnc012.mcc345\",\"forceRediscoveryEnabled\":false}","endOfBatch":false,"loggerFqcn":"org.apache.logging.slf4j.Log4jLogger","threadId":90,"threadPriority":5,"messageTimestamp":"2023-12-13T06:07:26.026+0000"}
{"instant":{"epochSecond":1702447646,"nanoOfSecond":26465561},"thread":"pool-10-thread-1","level":"INFO","loggerName":"com.oracle.cgbu.cnc.nrf.api.NRFClientApi","message":"Entering sendOnDemandNfDiscoverRequest function","endOfBatch":false,"loggerFqcn":"org.apache.logging.slf4j.Log4jLogger","threadId":101,"threadPriority":5,"messageTimestamp":"2023-12-13T06:07:26.026+0000"}
{"instant":{"epochSecond":1702447646,"nanoOfSecond":27251963},"thread":"pool-10-thread-1","level":"INFO","loggerName":"com.oracle.cgbu.cnc.nrf.api.NRFClientApi","message":"Send NfDiscover request with searchData: {\"targetNfType\":\"AMF\",\"requesterNfType\":\"PCF\",\"nfInfoParamsPresent\":false,\"serviceInfoParamsPresent\":false,\"enableF3\":true,\"enableF5\":false,\"targetNfSetId\":\"set001.region48.amfset.5gc.mnc012.mcc345\",\"retentionPeriod\":5000,\"rawQueryParameters\":\"target-nf-type=AMF&requester-nf-type=PCF&target-nf-set-id=set001.region48.amfset.5gc.mnc012.mcc345\",\"forceRediscoveryEnabled\":false}","endOfBatch":false,"loggerFqcn":"org.apache.logging.slf4j.Log4jLogger","threadId":101,"threadPriority":5,"messageTimestamp":"2023-12-13T06:07:26.027+0000"}
{"instant":{"epochSecond":1702447646,"nanoOfSecond":27393966},"thread":"pool-10-thread-1","level":"DEBUG","loggerName":"com.oracle.cgbu.cnc.nrf.api.NRFClientApi","message":"sendRequestToNrf nrfRequest : NRFRequest [scheme=http, rootURI=nf1stub.gi-dina.svc:8080, resourcePath=/nnrf-disc/v1/nf-instances, method=GET, body=null, headers=[], searchData={\"targetNfType\":\"AMF\",\"requesterNfType\":\"PCF\",\"nfInfoParamsPresent\":false,\"serviceInfoParamsPresent\":false,\"enableF3\":true,\"enableF5\":false,\"targetNfSetId\":\"set001.region48.amfset.5gc.mnc012.mcc345\",\"retentionPeriod\":5000,\"rawQueryParameters\":\"target-nf-type=AMF&requester-nf-type=PCF&target-nf-set-id=set001.region48.amfset.5gc.mnc012.mcc345\",\"forceRediscoveryEnabled\":false}, routeCount=0, requestType=NFDISCOVER]","endOfBatch":false,"loggerFqcn":"org.apache.logging.slf4j.Log4jLogger","threadId":101,"threadPriority":5,"messageTimestamp":"2023-12-13T06:07:26.027+0000"}
{"instant":{"epochSecond":1702447646,"nanoOfSecond":27518993},"thread":"pool-10-thread-1","level":"INFO","loggerName":"com.oracle.cgbu.cnc.nrf.api.NRFClientApi","message":"Returning retryConfig for ALL_REQUESTS NRFRetryConfig [serviceRequestType=ALL_REQUESTS, primaryNRFRetryCount=0, nonPrimaryNRFRetryCount=0, alternateNRFRetryCount=-1, errorReasonsForFailure=[503, 504, 500, SocketTimeoutException, JsonProcessingException, UnknownHostException, NoRouteToHostException], gatewayErrorCodes=[503], requestTimeout=10]","endOfBatch":false,"loggerFqcn":"org.apache.logging.slf4j.Log4jLogger","threadId":101,"threadPriority":5,"messageTimestamp":"2023-12-13T06:07:26.027+0000"}
{"instant":{"epochSecond":1702447646,"nanoOfSecond":27597244},"thread":"pool-10-thread-1","level":"DEBUG","loggerName":"com.oracle.cgbu.cnc.nrf.api.NRFClientApi","message":"Sending request to NRF nf1stub.gi-dina.svc:8080, routeCount=0, attempt=0","endOfBatch":false,"loggerFqcn":"org.apache.logging.slf4j.Log4jLogger","threadId":101,"threadPriority":5,"messageTimestamp":"2023-12-13T06:07:26.027+0000"}
{"instant":{"epochSecond":1702447646,"nanoOfSecond":27630106},"thread":"pool-10-thread-1","level":"DEBUG","loggerName":"com.oracle.cgbu.cnc.nrf.api.NRFClientApi","message":"trigger","endOfBatch":false,"loggerFqcn":"org.apache.logging.slf4j.Log4jLogger","threadId":101,"threadPriority":5,"messageTimestamp":"2023-12-13T06:07:26.027+0000"}
{"instant":{"epochSecond":1702447646,"nanoOfSecond":27663824},"thread":"pool-10-thread-1","level":"INFO","loggerName":"com.oracle.cgbu.cnc.nrf.api.NRFClientApi","message":"Returning retryConfig for ALL_REQUESTS NRFRetryConfig [serviceRequestType=ALL_REQUESTS, primaryNRFRetryCount=0, nonPrimaryNRFRetryCount=0, alternateNRFRetryCount=-1, errorReasonsForFailure=[503, 504, 500, SocketTimeoutException, JsonProcessingException, UnknownHostException, NoRouteToHostException], gatewayErrorCodes=[503], requestTimeout=10]","endOfBatch":false,"loggerFqcn":"org.apache.logging.slf4j.Log4jLogger","threadId":101,"threadPriority":5,"messageTimestamp":"2023-12-13T06:07:26.027+0000"}
{"instant":{"epochSecond":1702447646,"nanoOfSecond":60172668},"thread":"pool-10-thread-1","level":"INFO","loggerName":"com.oracle.cgbu.cnc.nrf.api.NRFClientApi","message":"Request returned response with status code : 200","endOfBatch":false,"loggerFqcn":"org.apache.logging.slf4j.Log4jLogger","threadId":101,"threadPriority":5,"messageTimestamp":"2023-12-13T06:07:26.060+0000"}
{"instant":{"epochSecond":1702447646,"nanoOfSecond":65762172},"thread":"pool-10-thread-1","level":"INFO","loggerName":"com.oracle.cgbu.cnc.nrf.api.NRFClientApi","message":"Successful Response code received","endOfBatch":false,"loggerFqcn":"org.apache.logging.slf4j.Log4jLogger","threadId":101,"threadPriority":5,"messageTimestamp":"2023-12-13T06:07:26.065+0000"}
{"instant":{"epochSecond":1702447646,"nanoOfSecond":65848611},"thread":"pool-10-thread-1","level":"INFO","loggerName":"com.oracle.cgbu.cnc.nrf.api.NRFClientApi","message":"sendOnDemandNfDiscoverRequest with searchData: {\"targetNfType\":\"AMF\",\"requesterNfType\":\"PCF\",\"nfInfoParamsPresent\":false,\"serviceInfoParamsPresent\":false,\"enableF3\":true,\"enableF5\":false,\"targetNfSetId\":\"set001.region48.amfset.5gc.mnc012.mcc345\",\"retentionPeriod\":5000,\"rawQueryParameters\":\"target-nf-type=AMF&requester-nf-type=PCF&target-nf-set-id=set001.region48.amfset.5gc.mnc012.mcc345\",\"forceRediscoveryEnabled\":false} returned status code : 200","endOfBatch":false,"loggerFqcn":"org.apache.logging.slf4j.Log4jLogger","threadId":101,"threadPriority":5,"messageTimestamp":"2023-12-13T06:07:26.065+0000"}
{"instant":{"epochSecond":1702447646,"nanoOfSecond":66116142},"thread":"XNIO-1 task-2","level":"INFO","loggerName":"com.oracle.cgbu.cnc.nrf.core.usecases.nrf.GetNrfDiscoveryResponseUseCase","message":"Received Discovery Result. Code: 200, Body (SearchResult): {\"validityPeriod\": 1800, \"nfInstances\": [{\"nfInstanceId\": \"13515195-c537-4645-9b97-96ec797f111a\", \"nfSetIdList\": [\"set001.region48.amfset.5gc.mnc012.mcc345\"], \"allowedNfTypes\": [\"PCF\", \"SMF\"], \"nfType\": \"AMF\", \"plmnList\": [{\"mcc\": \"450\", \"mnc\": \"05\"}], \"nfStatus\": \"REGISTERED\", \"fqdn\": \"nf1stub.gi-dina.svc\", \"priority\": 1, \"capacity\": 100, \"load\": 80, \"locality\": \"2\", \"amfInfo\": {\"amfRegionId\": \"01\", \"amfSetId\": \"001\", \"guamiList\": [{\"plmnId\": {\"mcc\": \"450\", \"mnc\": \"05\"}, \"amfId\": \"010041\"}]}, \"nfServices\": [{\"serviceInstanceId\": \"aaaa-bbbb-cccc-dddd\", \"serviceName\": \"namf-comm\", \"versions\": [{\"apiVersionInUri\": \"v1\", \"apiFullVersion\": \"1.1.0\", \"expiry\": \"2020-07-30T12:09:55.65Z\"}], \"scheme\": \"http\", \"nfServiceStatus\": \"REGISTERED\", \"ipEndPoints\": [{\"ipv4Address\": null, \"ipv6Address\": null, \"transport\": \"TCP\", \"port\": 8080}], \"allowedPlmns\": [{\"mcc\": \"450\", \"mnc\": \"05\"}], \"priority\": 2, \"capacity\": 100, \"load\": 80, \"locality\": \"2\"}]}, {\"nfInstanceId\": \"13515195-c537-4645-9b97-96ec797f1111\", \"nfSetIdList\": [\"set001.region48.amfset.5gc.mnc012.mcc345\"], \"allowedNfTypes\": [\"PCF\", \"SMF\"], \"nfType\": \"AMF\", \"plmnList\": [{\"mcc\": \"450\", \"mnc\": \"05\"}], \"nfStatus\": \"REGISTERED\", \"fqdn\": \"nf12stub.gi-dina.svc\", \"priority\": 2, \"capacity\": 100, \"load\": 80, \"locality\": \"2\", \"amfInfo\": {\"amfRegionId\": \"01\", \"amfSetId\": \"001\", \"guamiList\": [{\"plmnId\": {\"mcc\": \"450\", \"mnc\": \"05\"}, \"amfId\": \"010041\"}]}, \"nfServices\": [{\"serviceInstanceId\": \"aaaa-bbbb-cccc-dddd\", \"serviceName\": \"namf-comm\", \"versions\": [{\"apiVersionInUri\": \"v1\", \"apiFullVersion\": \"1.1.0\", \"expiry\": \"2020-07-30T12:09:55.65Z\"}], \"scheme\": \"http\", \"nfServiceStatus\": \"REGISTERED\", \"ipEndPoints\": [{\"ipv4Address\": null, \"ipv6Address\": null, \"transport\": \"TCP\", \"port\": 8080}], \"allowedPlmns\": [{\"mcc\": \"450\", \"mnc\": \"05\"}], \"priority\": 2, \"capacity\": 100, \"load\": 80, \"locality\": \"2\"}]}, {\"nfInstanceId\": \"13515195-c537-4645-9b97-96ec797f2222\", \"nfSetIdList\": [\"set001.region48.amfset.5gc.mnc012.mcc345\"], \"allowedNfTypes\": [\"PCF\", \"SMF\"], \"nfType\": \"AMF\", \"plmnList\": [{\"mcc\": \"450\", \"mnc\": \"05\"}], \"nfStatus\": \"REGISTERED\", \"fqdn\": \"nf2stub.gi-dina.svc\", \"priority\": 1, \"capacity\": 100, \"load\": 80, \"locality\": \"1\", \"amfInfo\": {\"amfRegionId\": \"01\", \"amfSetId\": \"001\", \"guamiList\": [{\"plmnId\": {\"mcc\": \"450\", \"mnc\": \"05\"}, \"amfId\": \"010041\"}]}, \"nfServices\": [{\"serviceInstanceId\": \"aaaa-bbbb-cccc-dddd\", \"serviceName\": \"namf-comm\", \"versions\": [{\"apiVersionInUri\": \"v1\", \"apiFullVersion\": \"1.1.0\", \"expiry\": \"2020-07-30T12:09:55.65Z\"}], \"scheme\": \"http\", \"nfServiceStatus\": \"REGISTERED\", \"ipEndPoints\": [{\"ipv4Address\": null, \"ipv6Address\": null, \"transport\": \"TCP\", \"port\": 8080}], \"allowedPlmns\": [{\"mcc\": \"450\", \"mnc\": \"05\"}], \"priority\": 1, \"capacity\": 100, \"load\": 80, \"locality\": \"1\"}]}, {\"nfInstanceId\": \"13515195-c537-4645-9b97-96ec797f3333\", \"nfSetIdList\": [\"set001.region48.amfset.5gc.mnc012.mcc345\"], \"allowedNfTypes\": [\"PCF\", \"SMF\"], \"nfType\": \"AMF\", \"plmnList\": [{\"mcc\": \"450\", \"mnc\": \"05\"}], \"nfStatus\": \"REGISTERED\", \"fqdn\": \"nf22stub.gi-dina.svc\", \"priority\": 2, \"capacity\": 100, \"load\": 80, \"locality\": \"1\", \"amfInfo\": {\"amfRegionId\": \"01\", \"amfSetId\": \"001\", \"guamiList\": [{\"plmnId\": {\"mcc\": \"450\", \"mnc\": \"05\"}, \"amfId\": \"010041\"}]}, \"nfServices\": [{\"serviceInstanceId\": \"aaaa-bbbb-cccc-dddd\", \"serviceName\": \"namf-comm\", \"versions\": [{\"apiVersionInUri\": \"v1\", \"apiFullVersion\": \"1.1.0\", \"expiry\": \"2020-07-30T12:09:55.65Z\"}], \"scheme\": \"http\", \"nfServiceStatus\": \"REGISTERED\", \"ipEndPoints\": [{\"ipv4Address\": null, \"ipv6Address\": null, \"transport\": \"TCP\", \"port\": 8080}], \"allowedPlmns\": [{\"mcc\": \"450\", \"mnc\": \"05\"}], \"priority\": 2, \"capacity\": 100, \"load\": 80, \"locality\": \"1\"}]}, {\"nfInstanceId\": \"13515195-c537-4645-9b97-96ec797f4444\", \"nfSetIdList\": [\"set001.region48.amfset.5gc.mnc012.mcc345\"], \"allowedNfTypes\": [\"PCF\", \"SMF\"], \"nfType\": \"AMF\", \"plmnList\": [{\"mcc\": \"450\", \"mnc\": \"05\"}], \"nfStatus\": \"REGISTERED\", \"fqdn\": \"nf21stub.gi-dina.svc\", \"priority\": 5, \"capacity\": 100, \"load\": 80, \"locality\": \"1\", \"amfInfo\": {\"amfRegionId\": \"01\", \"amfSetId\": \"001\", \"guamiList\": [{\"plmnId\": {\"mcc\": \"450\", \"mnc\": \"05\"}, \"amfId\": \"010041\"}]}, \"nfServices\": [{\"serviceInstanceId\": \"aaaa-bbbb-cccc-dddd\", \"serviceName\": \"namf-comm\", \"versions\": [{\"apiVersionInUri\": \"v1\", \"apiFullVersion\": \"1.1.0\", \"expiry\": \"2020-07-30T12:09:55.65Z\"}], \"scheme\": \"http\", \"nfServiceStatus\": \"REGISTERED\", \"ipEndPoints\": [{\"ipv4Address\": null, \"ipv6Address\": null, \"transport\": \"TCP\", \"port\": 8080}], \"allowedPlmns\": [{\"mcc\": \"450\", \"mnc\": \"05\"}], \"priority\": 5, \"capacity\": 100, \"load\": 80, \"locality\": \"1\"}]}]}","endOfBatch":false,"loggerFqcn":"org.apache.logging.slf4j.Log4jLogger","threadId":90,"threadPriority":5,"messageTimestamp":"2023-12-13T06:07:26.066+0000"}
{"instant":{"epochSecond":1702447646,"nanoOfSecond":67989020},"thread":"XNIO-1 task-2","level":"INFO","loggerName":"com.oracle.cgbu.cnc.nrf.core.usecases.nrf.GetNrfDiscoveryResponseUseCase","message":"Dynamic discovery cache enabled : false","endOfBatch":false,"loggerFqcn":"org.apache.logging.slf4j.Log4jLogger","threadId":90,"threadPriority":5,"messageTimestamp":"2023-12-13T06:07:26.067+0000"}
{"instant":{"epochSecond":1702447646,"nanoOfSecond":124766789},"thread":"XNIO-1 task-2","level":"INFO","loggerName":"com.oracle.cgbu.cnc.nrf.core.usecases.cache.GetCacheDiscoveryResponseUseCase","message":"Discovery Response fetched : DiscoverySearchResult{queryParams='target-nf-type=AMF&requester-nf-type=PCF&target-nf-set-id=set001.region48.amfset.5gc.mnc012.mcc345', searchResult={\"validityPeriod\":1800,\"nfInstances\":[{\"nfInstanceId\":\"13515195-c537-4645-9b97-96ec797f111a\",\"nfType\":\"AMF\",\"nfStatus\":\"REGISTERED\",\"plmnList\":[{\"mcc\":\"450\",\"mnc\":\"05\"}],\"fqdn\":\"nf1stub.gi-dina.svc\",\"allowedNfTypes\":[\"PCF\",\"SMF\"],\"priority\":1,\"capacity\":100,\"load\":80,\"locality\":\"2\",\"nfSetIdList\":[\"set001.region48.amfset.5gc.mnc012.mcc345\"],\"amfInfo\":{\"amfSetId\":\"001\",\"amfRegionId\":\"01\",\"guamiList\":[{\"plmnId\":{\"mcc\":\"450\",\"mnc\":\"05\"},\"amfId\":\"010041\"}]},\"nfServices\":[{\"serviceInstanceId\":\"aaaa-bbbb-cccc-dddd\",\"serviceName\":\"namf-comm\",\"versions\":[{\"apiVersionInUri\":\"v1\",\"apiFullVersion\":\"1.1.0\",\"expiry\":\"2020-07-30T12:09:55.650Z\"}],\"scheme\":\"http\",\"nfServiceStatus\":\"REGISTERED\",\"ipEndPoints\":[{\"transport\":\"TCP\",\"port\":8080}],\"allowedPlmns\":[{\"mcc\":\"450\",\"mnc\":\"05\"}],\"priority\":2,\"capacity\":100,\"load\":80,\"locality\":\"2\"}]},{\"nfInstanceId\":\"13515195-c537-4645-9b97-96ec797f1111\",\"nfType\":\"AMF\",\"nfStatus\":\"REGISTERED\",\"plmnList\":[{\"mcc\":\"450\",\"mnc\":\"05\"}],\"fqdn\":\"nf12stub.gi-dina.svc\",\"allowedNfTypes\":[\"PCF\",\"SMF\"],\"priority\":2,\"capacity\":100,\"load\":80,\"locality\":\"2\",\"nfSetIdList\":[\"set001.region48.amfset.5gc.mnc012.mcc345\"],\"amfInfo\":{\"amfSetId\":\"001\",\"amfRegionId\":\"01\",\"guamiList\":[{\"plmnId\":{\"mcc\":\"450\",\"mnc\":\"05\"},\"amfId\":\"010041\"}]},\"nfServices\":[{\"serviceInstanceId\":\"aaaa-bbbb-cccc-dddd\",\"serviceName\":\"namf-comm\",\"versions\":[{\"apiVersionInUri\":\"v1\",\"apiFullVersion\":\"1.1.0\",\"expiry\":\"2020-07-30T12:09:55.650Z\"}],\"scheme\":\"http\",\"nfServiceStatus\":\"REGISTERED\",\"ipEndPoints\":[{\"transport\":\"TCP\",\"port\":8080}],\"allowedPlmns\":[{\"mcc\":\"450\",\"mnc\":\"05\"}],\"priority\":2,\"capacity\":100,\"load\":80,\"locality\":\"2\"}]},{\"nfInstanceId\":\"13515195-c537-4645-9b97-96ec797f2222\",\"nfType\":\"AMF\",\"nfStatus\":\"REGISTERED\",\"plmnList\":[{\"mcc\":\"450\",\"mnc\":\"05\"}],\"fqdn\":\"nf2stub.gi-dina.svc\",\"allowedNfTypes\":[\"PCF\",\"SMF\"],\"priority\":1,\"capacity\":100,\"load\":80,\"locality\":\"1\",\"nfSetIdList\":[\"set001.region48.amfset.5gc.mnc012.mcc345\"],\"amfInfo\":{\"amfSetId\":\"001\",\"amfRegionId\":\"01\",\"guamiList\":[{\"plmnId\":{\"mcc\":\"450\",\"mnc\":\"05\"},\"amfId\":\"010041\"}]},\"nfServices\":[{\"serviceInstanceId\":\"aaaa-bbbb-cccc-dddd\",\"serviceName\":\"namf-comm\",\"versions\":[{\"apiVersionInUri\":\"v1\",\"apiFullVersion\":\"1.1.0\",\"expiry\":\"2020-07-30T12:09:55.650Z\"}],\"scheme\":\"http\",\"nfServiceStatus\":\"REGISTERED\",\"ipEndPoints\":[{\"transport\":\"TCP\",\"port\":8080}],\"allowedPlmns\":[{\"mcc\":\"450\",\"mnc\":\"05\"}],\"priority\":1,\"capacity\":100,\"load\":80,\"locality\":\"1\"}]},{\"nfInstanceId\":\"13515195-c537-4645-9b97-96ec797f3333\",\"nfType\":\"AMF\",\"nfStatus\":\"REGISTERED\",\"plmnList\":[{\"mcc\":\"450\",\"mnc\":\"05\"}],\"fqdn\":\"nf22stub.gi-dina.svc\",\"allowedNfTypes\":[\"PCF\",\"SMF\"],\"priority\":2,\"capacity\":100,\"load\":80,\"locality\":\"1\",\"nfSetIdList\":[\"set001.region48.amfset.5gc.mnc012.mcc345\"],\"amfInfo\":{\"amfSetId\":\"001\",\"amfRegionId\":\"01\",\"guamiList\":[{\"plmnId\":{\"mcc\":\"450\",\"mnc\":\"05\"},\"amfId\":\"010041\"}]},\"nfServices\":[{\"serviceInstanceId\":\"aaaa-bbbb-cccc-dddd\",\"serviceName\":\"namf-comm\",\"versions\":[{\"apiVersionInUri\":\"v1\",\"apiFullVersion\":\"1.1.0\",\"expiry\":\"2020-07-30T12:09:55.650Z\"}],\"scheme\":\"http\",\"nfServiceStatus\":\"REGISTERED\",\"ipEndPoints\":[{\"transport\":\"TCP\",\"port\":8080}],\"allowedPlmns\":[{\"mcc\":\"450\",\"mnc\":\"05\"}],\"priority\":2,\"capacity\":100,\"load\":80,\"locality\":\"1\"}]},{\"nfInstanceId\":\"13515195-c537-4645-9b97-96ec797f4444\",\"nfType\":\"AMF\",\"nfStatus\":\"REGISTERED\",\"plmnList\":[{\"mcc\":\"450\",\"mnc\":\"05\"}],\"fqdn\":\"nf21stub.gi-dina.svc\",\"allowedNfTypes\":[\"PCF\",\"SMF\"],\"priority\":5,\"capacity\":100,\"load\":80,\"locality\":\"1\",\"nfSetIdList\":[\"set001.region48.amfset.5gc.mnc012.mcc345\"],\"amfInfo\":{\"amfSetId\":\"001\",\"amfRegionId\":\"01\",\"guamiList\":[{\"plmnId\":{\"mcc\":\"450\",\"mnc\":\"05\"},\"amfId\":\"010041\"}]},\"nfServices\":[{\"serviceInstanceId\":\"aaaa-bbbb-cccc-dddd\",\"serviceName\":\"namf-comm\",\"versions\":[{\"apiVersionInUri\":\"v1\",\"apiFullVersion\":\"1.1.0\",\"expiry\":\"2020-07-30T12:09:55.650Z\"}],\"scheme\":\"http\",\"nfServiceStatus\":\"REGISTERED\",\"ipEndPoints\":[{\"transport\":\"TCP\",\"port\":8080}],\"allowedPlmns\":[{\"mcc\":\"450\",\"mnc\":\"05\"}],\"priority\":5,\"capacity\":100,\"load\":80,\"locality\":\"1\"}]}],\"nrfSupportedFeatures\":\"72\"}, sourceType=NRF}","endOfBatch":false,"loggerFqcn":"org.apache.logging.slf4j.Log4jLogger","threadId":90,"threadPriority":5,"messageTimestamp":"2023-12-13T06:07:26.124+0000"}



Discovery of AMF for UE policy association for the second time:

{"instant":{"epochSecond":1702447706,"nanoOfSecond":365554062},"thread":"XNIO-1 task-2","level":"DEBUG","loggerName":"com.oracle.cgbu.cnc.nrf.core.discoveryrules.DiscoveryRule","message":"Checking if cache applies for a discovery request (DiscoveryCache feature enabled: true, OC-Force-Rediscovery requested: false)","endOfBatch":false,"loggerFqcn":"org.apache.logging.slf4j.Log4jLogger","threadId":90,"threadPriority":5,"messageTimestamp":"2023-12-13T06:08:26.365+0000"}
{"instant":{"epochSecond":1702447706,"nanoOfSecond":365614917},"thread":"XNIO-1 task-2","level":"DEBUG","loggerName":"com.oracle.cgbu.cnc.nrf.core.discoveryrules.DiscoveryRule","message":"Query Parameters validation. IsFullyMatch -> true, Params from request -> [target-nf-type, requester-nf-type, target-nf-set-id], Params from config -> [target-nf-type, requester-nf-type, target-nf-set-id]","endOfBatch":false,"loggerFqcn":"org.apache.logging.slf4j.Log4jLogger","threadId":90,"threadPriority":5,"messageTimestamp":"2023-12-13T06:08:26.365+0000"}
{"instant":{"epochSecond":1702447706,"nanoOfSecond":365677878},"thread":"XNIO-1 task-2","level":"INFO","loggerName":"com.oracle.cgbu.cnc.nrf.core.discoveryrules.DiscoveryRule","message":"DiscoveryCache is enabled and queryParameters matched. Proceeding with DiscoveryResponse retrieval from memory","endOfBatch":false,"loggerFqcn":"org.apache.logging.slf4j.Log4jLogger","threadId":90,"threadPriority":5,"messageTimestamp":"2023-12-13T06:08:26.365+0000"}
{"instant":{"epochSecond":1702447706,"nanoOfSecond":365705820},"thread":"XNIO-1 task-2","level":"DEBUG","loggerName":"com.oracle.cgbu.cnc.nrf.core.discoveryrules.DiscoveryEvaluator","message":"Rule applied: CacheRule","endOfBatch":false,"loggerFqcn":"org.apache.logging.slf4j.Log4jLogger","threadId":90,"threadPriority":5,"messageTimestamp":"2023-12-13T06:08:26.365+0000"}
{"instant":{"epochSecond":1702447706,"nanoOfSecond":365727980},"thread":"XNIO-1 task-2","level":"DEBUG","loggerName":"com.oracle.cgbu.cnc.nrf.core.discoveryrules.CacheRule","message":"Applying Cache Rule, grabbing NRF response from Cache","endOfBatch":false,"loggerFqcn":"org.apache.logging.slf4j.Log4jLogger","threadId":90,"threadPriority":5,"messageTimestamp":"2023-12-13T06:08:26.365+0000"}
{"instant":{"epochSecond":1702447706,"nanoOfSecond":370207433},"thread":"XNIO-1 task-2","level":"INFO","loggerName":"com.oracle.cgbu.cnc.nrf.core.usecases.cache.GetCacheDiscoveryResponseUseCase","message":"Successful retrieval of Discovery Response stored in Cache/DB, proceeding with validation","endOfBatch":false,"loggerFqcn":"org.apache.logging.slf4j.Log4jLogger","threadId":90,"threadPriority":5,"messageTimestamp":"2023-12-13T06:08:26.370+0000"}
{"instant":{"epochSecond":1702447706,"nanoOfSecond":370252164},"thread":"XNIO-1 task-2","level":"INFO","loggerName":"com.oracle.cgbu.cnc.nrf.core.usecases.cache.GetCacheDiscoveryResponseUseCase","message":"Discovery Response retrieved from Cache/DB isAboutToExpire value : false ","endOfBatch":false,"loggerFqcn":"org.apache.logging.slf4j.Log4jLogger","threadId":90,"threadPriority":5,"messageTimestamp":"2023-12-13T06:08:26.370+0000"}
{"instant":{"epochSecond":1702447706,"nanoOfSecond":370285114},"thread":"XNIO-1 task-2","level":"INFO","loggerName":"com.oracle.cgbu.cnc.nrf.core.usecases.cache.GetCacheDiscoveryResponseUseCase","message":"Discovery Response retrieved from Cache/DB is expired value : false ","endOfBatch":false,"loggerFqcn":"org.apache.logging.slf4j.Log4jLogger","threadId":90,"threadPriority":5,"messageTimestamp":"2023-12-13T06:08:26.370+0000"}
{"instant":{"epochSecond":1702447706,"nanoOfSecond":378912228},"thread":"XNIO-1 task-2","level":"INFO","loggerName":"com.oracle.cgbu.cnc.nrf.core.usecases.cache.GetCacheDiscoveryResponseUseCase","message":"Discovery Response fetched : DiscoverySearchResult{queryParams='target-nf-type=AMF&requester-nf-type=PCF&target-nf-set-id=set001.region48.amfset.5gc.mnc012.mcc345', searchResult={\"validityPeriod\":1800,\"nfInstances\":[{\"nfInstanceId\":\"13515195-c537-4645-9b97-96ec797f111a\",\"nfType\":\"AMF\",\"nfStatus\":\"REGISTERED\",\"plmnList\":[{\"mcc\":\"450\",\"mnc\":\"05\"}],\"fqdn\":\"nf1stub.gi-dina.svc\",\"allowedNfTypes\":[\"PCF\",\"SMF\"],\"priority\":1,\"capacity\":100,\"load\":80,\"locality\":\"2\",\"nfSetIdList\":[\"set001.region48.amfset.5gc.mnc012.mcc345\"],\"amfInfo\":{\"amfSetId\":\"001\",\"amfRegionId\":\"01\",\"guamiList\":[{\"plmnId\":{\"mcc\":\"450\",\"mnc\":\"05\"},\"amfId\":\"010041\"}]},\"nfServices\":[{\"serviceInstanceId\":\"aaaa-bbbb-cccc-dddd\",\"serviceName\":\"namf-comm\",\"versions\":[{\"apiVersionInUri\":\"v1\",\"apiFullVersion\":\"1.1.0\",\"expiry\":\"2020-07-30T12:09:55.650Z\"}],\"scheme\":\"http\",\"nfServiceStatus\":\"REGISTERED\",\"ipEndPoints\":[{\"transport\":\"TCP\",\"port\":8080}],\"allowedPlmns\":[{\"mcc\":\"450\",\"mnc\":\"05\"}],\"priority\":2,\"capacity\":100,\"load\":80,\"locality\":\"2\"}]},{\"nfInstanceId\":\"13515195-c537-4645-9b97-96ec797f1111\",\"nfType\":\"AMF\",\"nfStatus\":\"REGISTERED\",\"plmnList\":[{\"mcc\":\"450\",\"mnc\":\"05\"}],\"fqdn\":\"nf12stub.gi-dina.svc\",\"allowedNfTypes\":[\"PCF\",\"SMF\"],\"priority\":2,\"capacity\":100,\"load\":80,\"locality\":\"2\",\"nfSetIdList\":[\"set001.region48.amfset.5gc.mnc012.mcc345\"],\"amfInfo\":{\"amfSetId\":\"001\",\"amfRegionId\":\"01\",\"guamiList\":[{\"plmnId\":{\"mcc\":\"450\",\"mnc\":\"05\"},\"amfId\":\"010041\"}]},\"nfServices\":[{\"serviceInstanceId\":\"aaaa-bbbb-cccc-dddd\",\"serviceName\":\"namf-comm\",\"versions\":[{\"apiVersionInUri\":\"v1\",\"apiFullVersion\":\"1.1.0\",\"expiry\":\"2020-07-30T12:09:55.650Z\"}],\"scheme\":\"http\",\"nfServiceStatus\":\"REGISTERED\",\"ipEndPoints\":[{\"transport\":\"TCP\",\"port\":8080}],\"allowedPlmns\":[{\"mcc\":\"450\",\"mnc\":\"05\"}],\"priority\":2,\"capacity\":100,\"load\":80,\"locality\":\"2\"}]},{\"nfInstanceId\":\"13515195-c537-4645-9b97-96ec797f2222\",\"nfType\":\"AMF\",\"nfStatus\":\"REGISTERED\",\"plmnList\":[{\"mcc\":\"450\",\"mnc\":\"05\"}],\"fqdn\":\"nf2stub.gi-dina.svc\",\"allowedNfTypes\":[\"PCF\",\"SMF\"],\"priority\":1,\"capacity\":100,\"load\":80,\"locality\":\"1\",\"nfSetIdList\":[\"set001.region48.amfset.5gc.mnc012.mcc345\"],\"amfInfo\":{\"amfSetId\":\"001\",\"amfRegionId\":\"01\",\"guamiList\":[{\"plmnId\":{\"mcc\":\"450\",\"mnc\":\"05\"},\"amfId\":\"010041\"}]},\"nfServices\":[{\"serviceInstanceId\":\"aaaa-bbbb-cccc-dddd\",\"serviceName\":\"namf-comm\",\"versions\":[{\"apiVersionInUri\":\"v1\",\"apiFullVersion\":\"1.1.0\",\"expiry\":\"2020-07-30T12:09:55.650Z\"}],\"scheme\":\"http\",\"nfServiceStatus\":\"REGISTERED\",\"ipEndPoints\":[{\"transport\":\"TCP\",\"port\":8080}],\"allowedPlmns\":[{\"mcc\":\"450\",\"mnc\":\"05\"}],\"priority\":1,\"capacity\":100,\"load\":80,\"locality\":\"1\"}]},{\"nfInstanceId\":\"13515195-c537-4645-9b97-96ec797f3333\",\"nfType\":\"AMF\",\"nfStatus\":\"REGISTERED\",\"plmnList\":[{\"mcc\":\"450\",\"mnc\":\"05\"}],\"fqdn\":\"nf22stub.gi-dina.svc\",\"allowedNfTypes\":[\"PCF\",\"SMF\"],\"priority\":2,\"capacity\":100,\"load\":80,\"locality\":\"1\",\"nfSetIdList\":[\"set001.region48.amfset.5gc.mnc012.mcc345\"],\"amfInfo\":{\"amfSetId\":\"001\",\"amfRegionId\":\"01\",\"guamiList\":[{\"plmnId\":{\"mcc\":\"450\",\"mnc\":\"05\"},\"amfId\":\"010041\"}]},\"nfServices\":[{\"serviceInstanceId\":\"aaaa-bbbb-cccc-dddd\",\"serviceName\":\"namf-comm\",\"versions\":[{\"apiVersionInUri\":\"v1\",\"apiFullVersion\":\"1.1.0\",\"expiry\":\"2020-07-30T12:09:55.650Z\"}],\"scheme\":\"http\",\"nfServiceStatus\":\"REGISTERED\",\"ipEndPoints\":[{\"transport\":\"TCP\",\"port\":8080}],\"allowedPlmns\":[{\"mcc\":\"450\",\"mnc\":\"05\"}],\"priority\":2,\"capacity\":100,\"load\":80,\"locality\":\"1\"}]},{\"nfInstanceId\":\"13515195-c537-4645-9b97-96ec797f4444\",\"nfType\":\"AMF\",\"nfStatus\":\"REGISTERED\",\"plmnList\":[{\"mcc\":\"450\",\"mnc\":\"05\"}],\"fqdn\":\"nf21stub.gi-dina.svc\",\"allowedNfTypes\":[\"PCF\",\"SMF\"],\"priority\":5,\"capacity\":100,\"load\":80,\"locality\":\"1\",\"nfSetIdList\":[\"set001.region48.amfset.5gc.mnc012.mcc345\"],\"amfInfo\":{\"amfSetId\":\"001\",\"amfRegionId\":\"01\",\"guamiList\":[{\"plmnId\":{\"mcc\":\"450\",\"mnc\":\"05\"},\"amfId\":\"010041\"}]},\"nfServices\":[{\"serviceInstanceId\":\"aaaa-bbbb-cccc-dddd\",\"serviceName\":\"namf-comm\",\"versions\":[{\"apiVersionInUri\":\"v1\",\"apiFullVersion\":\"1.1.0\",\"expiry\":\"2020-07-30T12:09:55.650Z\"}],\"scheme\":\"http\",\"nfServiceStatus\":\"REGISTERED\",\"ipEndPoints\":[{\"transport\":\"TCP\",\"port\":8080}],\"allowedPlmns\":[{\"mcc\":\"450\",\"mnc\":\"05\"}],\"priority\":5,\"capacity\":100,\"load\":80,\"locality\":\"1\"}]}],\"nrfSupportedFeatures\":\"72\"}, sourceType=CACHE}","endOfBatch":false,"loggerFqcn":"org.apache.logging.slf4j.Log4jLogger","threadId":90,"threadPriority":5,"messageTimestamp":"2023-12-13T06:08:26.378+0000"}

UDR:

Discovery of UDR for th first time:



{"instant":{"epochSecond":1702447911,"nanoOfSecond":703559369},"thread":"XNIO-1 task-2","level":"DEBUG","loggerName":"com.oracle.cgbu.cnc.nrf.core.discoveryrules.DiscoveryRule","message":"Checking if cache applies for a discovery request (DiscoveryCache feature enabled: true, OC-Force-Rediscovery requested: false)","endOfBatch":false,"loggerFqcn":"org.apache.logging.slf4j.Log4jLogger","threadId":90,"threadPriority":5,"messageTimestamp":"2023-12-13T06:11:51.703+0000"}
{"instant":{"epochSecond":1702447911,"nanoOfSecond":703624658},"thread":"XNIO-1 task-2","level":"DEBUG","loggerName":"com.oracle.cgbu.cnc.nrf.core.discoveryrules.DiscoveryRule","message":"Query Parameters validation. IsFullyMatch -> true, Params from request -> [target-nf-type, requester-nf-type, service-names, target-nf-set-id], Params from config -> [target-nf-type, requester-nf-type, service-names, target-nf-set-id]","endOfBatch":false,"loggerFqcn":"org.apache.logging.slf4j.Log4jLogger","threadId":90,"threadPriority":5,"messageTimestamp":"2023-12-13T06:11:51.703+0000"}
{"instant":{"epochSecond":1702447911,"nanoOfSecond":703677942},"thread":"XNIO-1 task-2","level":"INFO","loggerName":"com.oracle.cgbu.cnc.nrf.core.discoveryrules.DiscoveryRule","message":"DiscoveryCache is enabled and queryParameters matched. Proceeding with DiscoveryResponse retrieval from memory","endOfBatch":false,"loggerFqcn":"org.apache.logging.slf4j.Log4jLogger","threadId":90,"threadPriority":5,"messageTimestamp":"2023-12-13T06:11:51.703+0000"}
{"instant":{"epochSecond":1702447911,"nanoOfSecond":703715314},"thread":"XNIO-1 task-2","level":"DEBUG","loggerName":"com.oracle.cgbu.cnc.nrf.core.discoveryrules.DiscoveryEvaluator","message":"Rule applied: CacheRule","endOfBatch":false,"loggerFqcn":"org.apache.logging.slf4j.Log4jLogger","threadId":90,"threadPriority":5,"messageTimestamp":"2023-12-13T06:11:51.703+0000"}
{"instant":{"epochSecond":1702447911,"nanoOfSecond":703735621},"thread":"XNIO-1 task-2","level":"DEBUG","loggerName":"com.oracle.cgbu.cnc.nrf.core.discoveryrules.CacheRule","message":"Applying Cache Rule, grabbing NRF response from Cache","endOfBatch":false,"loggerFqcn":"org.apache.logging.slf4j.Log4jLogger","threadId":90,"threadPriority":5,"messageTimestamp":"2023-12-13T06:11:51.703+0000"}
{"instant":{"epochSecond":1702447911,"nanoOfSecond":711068647},"thread":"XNIO-1 task-2","level":"INFO","loggerName":"com.oracle.cgbu.cnc.nrf.core.usecases.cache.GetCacheDiscoveryResponseUseCase","message":"Unsuccessful retrieval of Discovery Response from Cache/DB, proceeding retrieval from NRF and saving response in Cache/DB","endOfBatch":false,"loggerFqcn":"org.apache.logging.slf4j.Log4jLogger","threadId":90,"threadPriority":5,"messageTimestamp":"2023-12-13T06:11:51.711+0000"}
{"instant":{"epochSecond":1702447911,"nanoOfSecond":711135709},"thread":"XNIO-1 task-2","level":"INFO","loggerName":"com.oracle.cgbu.cnc.nrf.core.usecases.nrf.GetNrfDiscoveryResponseUseCase","message":"SearchData : {\"targetNfType\":\"UDR\",\"serviceNames\":[\"nudr-dr\"],\"requesterNfType\":\"PCF\",\"nfInfoParamsPresent\":false,\"serviceInfoParamsPresent\":true,\"enableF3\":true,\"enableF5\":false,\"targetNfSetId\":\"set001.udrset.5gc.mnc012.mcc345\",\"retentionPeriod\":5000,\"rawQueryParameters\":\"target-nf-type=UDR&requester-nf-type=PCF&service-names=nudr-dr&target-nf-set-id=set001.udrset.5gc.mnc012.mcc345\",\"forceRediscoveryEnabled\":false}","endOfBatch":false,"loggerFqcn":"org.apache.logging.slf4j.Log4jLogger","threadId":90,"threadPriority":5,"messageTimestamp":"2023-12-13T06:11:51.711+0000"}
{"instant":{"epochSecond":1702447911,"nanoOfSecond":711380511},"thread":"pool-10-thread-1","level":"INFO","loggerName":"com.oracle.cgbu.cnc.nrf.api.NRFClientApi","message":"Entering sendOnDemandNfDiscoverRequest function","endOfBatch":false,"loggerFqcn":"org.apache.logging.slf4j.Log4jLogger","threadId":101,"threadPriority":5,"messageTimestamp":"2023-12-13T06:11:51.711+0000"}
{"instant":{"epochSecond":1702447911,"nanoOfSecond":712130386},"thread":"pool-10-thread-1","level":"INFO","loggerName":"com.oracle.cgbu.cnc.nrf.api.NRFClientApi","message":"Send NfDiscover request with searchData: {\"targetNfType\":\"UDR\",\"serviceNames\":[\"nudr-dr\"],\"requesterNfType\":\"PCF\",\"nfInfoParamsPresent\":false,\"serviceInfoParamsPresent\":true,\"enableF3\":true,\"enableF5\":false,\"targetNfSetId\":\"set001.udrset.5gc.mnc012.mcc345\",\"retentionPeriod\":5000,\"rawQueryParameters\":\"target-nf-type=UDR&requester-nf-type=PCF&service-names=nudr-dr&target-nf-set-id=set001.udrset.5gc.mnc012.mcc345\",\"forceRediscoveryEnabled\":false}","endOfBatch":false,"loggerFqcn":"org.apache.logging.slf4j.Log4jLogger","threadId":101,"threadPriority":5,"messageTimestamp":"2023-12-13T06:11:51.712+0000"}
{"instant":{"epochSecond":1702447911,"nanoOfSecond":712257461},"thread":"pool-10-thread-1","level":"DEBUG","loggerName":"com.oracle.cgbu.cnc.nrf.api.NRFClientApi","message":"sendRequestToNrf nrfRequest : NRFRequest [scheme=http, rootURI=nf1stub.gi-dina.svc:8080, resourcePath=/nnrf-disc/v1/nf-instances, method=GET, body=null, headers=[], searchData={\"targetNfType\":\"UDR\",\"serviceNames\":[\"nudr-dr\"],\"requesterNfType\":\"PCF\",\"nfInfoParamsPresent\":false,\"serviceInfoParamsPresent\":true,\"enableF3\":true,\"enableF5\":false,\"targetNfSetId\":\"set001.udrset.5gc.mnc012.mcc345\",\"retentionPeriod\":5000,\"rawQueryParameters\":\"target-nf-type=UDR&requester-nf-type=PCF&service-names=nudr-dr&target-nf-set-id=set001.udrset.5gc.mnc012.mcc345\",\"forceRediscoveryEnabled\":false}, routeCount=0, requestType=NFDISCOVER]","endOfBatch":false,"loggerFqcn":"org.apache.logging.slf4j.Log4jLogger","threadId":101,"threadPriority":5,"messageTimestamp":"2023-12-13T06:11:51.712+0000"}
{"instant":{"epochSecond":1702447911,"nanoOfSecond":712395565},"thread":"pool-10-thread-1","level":"INFO","loggerName":"com.oracle.cgbu.cnc.nrf.api.NRFClientApi","message":"Returning retryConfig for ALL_REQUESTS NRFRetryConfig [serviceRequestType=ALL_REQUESTS, primaryNRFRetryCount=0, nonPrimaryNRFRetryCount=0, alternateNRFRetryCount=-1, errorReasonsForFailure=[503, 504, 500, SocketTimeoutException, JsonProcessingException, UnknownHostException, NoRouteToHostException], gatewayErrorCodes=[503], requestTimeout=10]","endOfBatch":false,"loggerFqcn":"org.apache.logging.slf4j.Log4jLogger","threadId":101,"threadPriority":5,"messageTimestamp":"2023-12-13T06:11:51.712+0000"}
{"instant":{"epochSecond":1702447911,"nanoOfSecond":712450944},"thread":"pool-10-thread-1","level":"DEBUG","loggerName":"com.oracle.cgbu.cnc.nrf.api.NRFClientApi","message":"Sending request to NRF nf1stub.gi-dina.svc:8080, routeCount=0, attempt=0","endOfBatch":false,"loggerFqcn":"org.apache.logging.slf4j.Log4jLogger","threadId":101,"threadPriority":5,"messageTimestamp":"2023-12-13T06:11:51.712+0000"}
{"instant":{"epochSecond":1702447911,"nanoOfSecond":712478555},"thread":"pool-10-thread-1","level":"DEBUG","loggerName":"com.oracle.cgbu.cnc.nrf.api.NRFClientApi","message":"trigger","endOfBatch":false,"loggerFqcn":"org.apache.logging.slf4j.Log4jLogger","threadId":101,"threadPriority":5,"messageTimestamp":"2023-12-13T06:11:51.712+0000"}
{"instant":{"epochSecond":1702447911,"nanoOfSecond":712505815},"thread":"pool-10-thread-1","level":"INFO","loggerName":"com.oracle.cgbu.cnc.nrf.api.NRFClientApi","message":"Returning retryConfig for ALL_REQUESTS NRFRetryConfig [serviceRequestType=ALL_REQUESTS, primaryNRFRetryCount=0, nonPrimaryNRFRetryCount=0, alternateNRFRetryCount=-1, errorReasonsForFailure=[503, 504, 500, SocketTimeoutException, JsonProcessingException, UnknownHostException, NoRouteToHostException], gatewayErrorCodes=[503], requestTimeout=10]","endOfBatch":false,"loggerFqcn":"org.apache.logging.slf4j.Log4jLogger","threadId":101,"threadPriority":5,"messageTimestamp":"2023-12-13T06:11:51.712+0000"}
{"instant":{"epochSecond":1702447911,"nanoOfSecond":731529927},"thread":"pool-10-thread-1","level":"INFO","loggerName":"com.oracle.cgbu.cnc.nrf.api.NRFClientApi","message":"Request returned response with status code : 200","endOfBatch":false,"loggerFqcn":"org.apache.logging.slf4j.Log4jLogger","threadId":101,"threadPriority":5,"messageTimestamp":"2023-12-13T06:11:51.731+0000"}
{"instant":{"epochSecond":1702447911,"nanoOfSecond":736236543},"thread":"pool-10-thread-1","level":"INFO","loggerName":"com.oracle.cgbu.cnc.nrf.api.NRFClientApi","message":"Successful Response code received","endOfBatch":false,"loggerFqcn":"org.apache.logging.slf4j.Log4jLogger","threadId":101,"threadPriority":5,"messageTimestamp":"2023-12-13T06:11:51.736+0000"}
{"instant":{"epochSecond":1702447911,"nanoOfSecond":736285120},"thread":"pool-10-thread-1","level":"INFO","loggerName":"com.oracle.cgbu.cnc.nrf.api.NRFClientApi","message":"sendOnDemandNfDiscoverRequest with searchData: {\"targetNfType\":\"UDR\",\"serviceNames\":[\"nudr-dr\"],\"requesterNfType\":\"PCF\",\"nfInfoParamsPresent\":false,\"serviceInfoParamsPresent\":true,\"enableF3\":true,\"enableF5\":false,\"targetNfSetId\":\"set001.udrset.5gc.mnc012.mcc345\",\"retentionPeriod\":5000,\"rawQueryParameters\":\"target-nf-type=UDR&requester-nf-type=PCF&service-names=nudr-dr&target-nf-set-id=set001.udrset.5gc.mnc012.mcc345\",\"forceRediscoveryEnabled\":false} returned status code : 200","endOfBatch":false,"loggerFqcn":"org.apache.logging.slf4j.Log4jLogger","threadId":101,"threadPriority":5,"messageTimestamp":"2023-12-13T06:11:51.736+0000"}
{"instant":{"epochSecond":1702447911,"nanoOfSecond":736499801},"thread":"XNIO-1 task-2","level":"INFO","loggerName":"com.oracle.cgbu.cnc.nrf.core.usecases.nrf.GetNrfDiscoveryResponseUseCase","message":"Received Discovery Result. Code: 200, Body (SearchResult): {\"validityPeriod\": 100, \"nfInstances\": [{\"nfInstanceId\": \"fe7d992b-0541-4c7d-ab84-555550000000\", \"nfSetIdList\": [\"set001.udrset.5gc.mnc012.mcc345\"], \"nfType\": \"UDR\", \"nfStatus\": \"REGISTERED\", \"plmnList\": null, \"nsiList\": null, \"fqdn\": \"nf2stub.gi-dina.svc\", \"interPlmnFqdn\": null, \"ipv4Addresses\": null, \"ipv6Addresses\": null, \"priority\": 1, \"capacity\": 50, \"load\": 10, \"locality\": \"1\", \"pcfInfo\": null, \"udmInfo\": null, \"ausfInfo\": null, \"amfInfo\": null, \"smfInfo\": null, \"upfInfo\": null, \"groupId\": \"udr1\", \"udrInfo\": {\"supiRanges\": [{\"start\": \"450081000000000\", \"end\": \"450081002000000\"}], \"gpsiRanges\": [{\"start\": \"13100000000\", \"end\": \"13102000000\"}], \"supportedDataSets\": [\"POLICY\"]}, \"bsfInfo\": null, \"customInfo\": null, \"recoveryTime\": null, \"nfServices\": [{\"serviceInstanceId\": \"94d8d19a-b0d9-4d6d-994f-39a49ed5c111\", \"serviceName\": \"nudr-dr\", \"versions\": [{\"apiVersionInUri\": \"v1\", \"apiFullVersion\": \"1.15.1.0\", \"expiry\": \"2019-08-03T18:55:08.871+0000\"}], \"scheme\": \"http\", \"nfServiceStatus\": \"REGISTERED\", \"fqdn\": null, \"interPlmnFqdn\": null, \"ipEndPoints\": [{\"ipv4Address\": null, \"ipv6Address\": null, \"transport\": \"TCP\", \"port\": 8080}], \"apiPrefix\": null, \"defaultNotificationSubscriptions\": null, \"allowedPlmns\": null, \"allowedNfTypes\": [\"CHF\", \"PCF\"], \"allowedNfDomains\": null, \"allowedNssais\": null, \"priority\": 1, \"capacity\": 100, \"load\": 50, \"locality\": \"1\", \"recoveryTime\": 1542876663222, \"supportedFeatures\": null}]}, {\"nfInstanceId\": \"fe7d992b-0541-4c7d-ab84-555551111111\", \"nfSetIdList\": [\"set001.udrset.5gc.mnc012.mcc345\"], \"nfType\": \"UDR\", \"nfStatus\": \"REGISTERED\", \"plmnList\": null, \"nsiList\": null, \"fqdn\": \"nf21stub.gi-dina.svc\", \"interPlmnFqdn\": null, \"ipv4Addresses\": null, \"ipv6Addresses\": null, \"priority\": 2, \"capacity\": 50, \"load\": 20, \"locality\": \"2\", \"pcfInfo\": null, \"udmInfo\": null, \"ausfInfo\": null, \"amfInfo\": null, \"smfInfo\": null, \"upfInfo\": null, \"groupId\": \"udr1\", \"udrInfo\": {\"supiRanges\": [{\"start\": \"450081000000000\", \"end\": \"450081002000000\"}], \"gpsiRanges\": [{\"start\": \"13100000000\", \"end\": \"13102000000\"}], \"supportedDataSets\": [\"POLICY\"]}, \"bsfInfo\": null, \"customInfo\": null, \"recoveryTime\": null, \"nfServices\": [{\"serviceInstanceId\": \"94d8d19a-b0d9-4d6d-994f-39a49ed5c111\", \"serviceName\": \"nudr-dr\", \"versions\": [{\"apiVersionInUri\": \"v1\", \"apiFullVersion\": \"1.15.1.0\", \"expiry\": \"2019-08-03T18:55:08.871+0000\"}], \"scheme\": \"http\", \"nfServiceStatus\": \"REGISTERED\", \"fqdn\": null, \"interPlmnFqdn\": null, \"ipEndPoints\": [{\"ipv4Address\": null, \"ipv6Address\": null, \"transport\": \"TCP\", \"port\": 8080}], \"apiPrefix\": null, \"defaultNotificationSubscriptions\": null, \"allowedPlmns\": null, \"allowedNfTypes\": [\"CHF\", \"PCF\"], \"allowedNfDomains\": null, \"allowedNssais\": null, \"priority\": 2, \"capacity\": 50, \"load\": 20, \"recoveryTime\": 1542876663222, \"supportedFeatures\": null}]}, {\"nfInstanceId\": \"fe7d992b-0541-4c7d-ab84-555553333333\", \"nfSetIdList\": [\"set001.udrset.5gc.mnc012.mcc345\"], \"nfType\": \"UDR\", \"nfStatus\": \"REGISTERED\", \"plmnList\": null, \"nsiList\": null, \"fqdn\": \"nf11stub.gi-dina.svc\", \"interPlmnFqdn\": null, \"ipv4Addresses\": null, \"ipv6Addresses\": null, \"priority\": 4, \"capacity\": 50, \"load\": 10, \"locality\": \"1\", \"pcfInfo\": null, \"udmInfo\": null, \"ausfInfo\": null, \"amfInfo\": null, \"smfInfo\": null, \"upfInfo\": null, \"groupId\": \"udr1\", \"udrInfo\": {\"supiRanges\": [{\"start\": \"450081000000000\", \"end\": \"450081002000000\"}], \"gpsiRanges\": [{\"start\": \"13100000000\", \"end\": \"13102000000\"}], \"supportedDataSets\": [\"POLICY\"]}, \"bsfInfo\": null, \"customInfo\": null, \"recoveryTime\": null, \"nfServices\": [{\"serviceInstanceId\": \"94d8d19a-b0d9-4d6d-994f-39a49ed5c111\", \"serviceName\": \"nudr-dr\", \"versions\": [{\"apiVersionInUri\": \"v1\", \"apiFullVersion\": \"1.15.1.0\", \"expiry\": \"2019-08-03T18:55:08.871+0000\"}], \"scheme\": \"http\", \"nfServiceStatus\": \"REGISTERED\", \"fqdn\": null, \"interPlmnFqdn\": null, \"ipEndPoints\": [{\"ipv4Address\": null, \"ipv6Address\": null, \"transport\": \"TCP\", \"port\": 8080}], \"apiPrefix\": null, \"defaultNotificationSubscriptions\": null, \"allowedPlmns\": null, \"allowedNfTypes\": [\"CHF\", \"PCF\"], \"allowedNfDomains\": null, \"allowedNssais\": null, \"priority\": 4, \"capacity\": 50, \"load\": 10, \"recoveryTime\": 1542876663222, \"supportedFeatures\": null}]}, {\"nfInstanceId\": \"fe7d992b-0541-4c7d-ab84-555554444444\", \"nfSetIdList\": [\"set002.udrset.5gc.mnc012.mcc345\"], \"nfType\": \"UDR\", \"nfStatus\": \"REGISTERED\", \"plmnList\": null, \"nsiList\": null, \"fqdn\": \"nf12stub.gi-dina.svc\", \"interPlmnFqdn\": null, \"ipv4Addresses\": null, \"ipv6Addresses\": null, \"priority\": 5, \"capacity\": 50, \"load\": 40, \"locality\": \"2\", \"pcfInfo\": null, \"udmInfo\": null, \"ausfInfo\": null, \"amfInfo\": null, \"smfInfo\": null, \"upfInfo\": null, \"groupId\": \"udr1\", \"udrInfo\": {\"supiRanges\": [{\"start\": \"450081000000000\", \"end\": \"450081002000000\"}], \"gpsiRanges\": [{\"start\": \"13100000000\", \"end\": \"13102000000\"}], \"supportedDataSets\": [\"POLICY\"]}, \"bsfInfo\": null, \"customInfo\": null, \"recoveryTime\": null, \"nfServices\": [{\"serviceInstanceId\": \"94d8d19a-b0d9-4d6d-994f-39a49ed5c111\", \"serviceName\": \"nudr-dr\", \"versions\": [{\"apiVersionInUri\": \"v1\", \"apiFullVersion\": \"1.15.1.0\", \"expiry\": \"2019-08-03T18:55:08.871+0000\"}], \"scheme\": \"http\", \"nfServiceStatus\": \"REGISTERED\", \"fqdn\": null, \"interPlmnFqdn\": null, \"ipEndPoints\": [{\"ipv4Address\": null, \"ipv6Address\": null, \"transport\": \"TCP\", \"port\": 8080}], \"apiPrefix\": null, \"defaultNotificationSubscriptions\": null, \"allowedPlmns\": null, \"allowedNfTypes\": [\"CHF\", \"PCF\"], \"allowedNfDomains\": null, \"allowedNssais\": null, \"priority\": 5, \"capacity\": 50, \"load\": 40, \"recoveryTime\": 1542876663222, \"supportedFeatures\": null}]}, {\"nfInstanceId\": \"fe7d992b-0541-4c7d-ab84-555552222222\", \"nfSetIdList\": [\"set002.udrset.5gc.mnc012.mcc345\"], \"nfType\": \"UDR\", \"nfStatus\": \"REGISTERED\", \"plmnList\": null, \"nsiList\": null, \"fqdn\": \"nf22stub.gi-dina.svc\", \"interPlmnFqdn\": null, \"ipv4Addresses\": null, \"ipv6Addresses\": null, \"priority\": 3, \"capacity\": 50, \"load\": 30, \"locality\": \"1\", \"pcfInfo\": null, \"udmInfo\": null, \"ausfInfo\": null, \"amfInfo\": null, \"smfInfo\": null, \"upfInfo\": null, \"groupId\": \"udr1\", \"udrInfo\": {\"supiRanges\": [{\"start\": \"450081000000000\", \"end\": \"450081002000000\"}], \"gpsiRanges\": [{\"start\": \"13100000000\", \"end\": \"13102000000\"}], \"supportedDataSets\": [\"POLICY\"]}, \"bsfInfo\": null, \"customInfo\": null, \"recoveryTime\": null, \"nfServices\": [{\"serviceInstanceId\": \"94d8d19a-b0d9-4d6d-994f-39a49ed5c111\", \"serviceName\": \"nudr-dr\", \"versions\": [{\"apiVersionInUri\": \"v1\", \"apiFullVersion\": \"1.15.1.0\", \"expiry\": \"2019-08-03T18:55:08.871+0000\"}], \"scheme\": \"http\", \"nfServiceStatus\": \"REGISTERED\", \"fqdn\": null, \"interPlmnFqdn\": null, \"ipEndPoints\": [{\"ipv4Address\": null, \"ipv6Address\": null, \"transport\": \"TCP\", \"port\": 8080}], \"apiPrefix\": null, \"defaultNotificationSubscriptions\": null, \"allowedPlmns\": null, \"allowedNfTypes\": [\"CHF\", \"PCF\"], \"allowedNfDomains\": null, \"allowedNssais\": null, \"priority\": 3, \"capacity\": 50, \"load\": 30, \"recoveryTime\": 1542876663222, \"supportedFeatures\": null}]}]}","endOfBatch":false,"loggerFqcn":"org.apache.logging.slf4j.Log4jLogger","threadId":90,"threadPriority":5,"messageTimestamp":"2023-12-13T06:11:51.736+0000"}
{"instant":{"epochSecond":1702447911,"nanoOfSecond":737221498},"thread":"XNIO-1 task-2","level":"INFO","loggerName":"com.oracle.cgbu.cnc.nrf.core.usecases.nrf.GetNrfDiscoveryResponseUseCase","message":"Dynamic discovery cache enabled : false","endOfBatch":false,"loggerFqcn":"org.apache.logging.slf4j.Log4jLogger","threadId":90,"threadPriority":5,"messageTimestamp":"2023-12-13T06:11:51.737+0000"}
{"instant":{"epochSecond":1702447911,"nanoOfSecond":770303926},"thread":"XNIO-1 task-2","level":"INFO","loggerName":"com.oracle.cgbu.cnc.nrf.core.usecases.cache.GetCacheDiscoveryResponseUseCase","message":"Discovery Response fetched : DiscoverySearchResult{queryParams='target-nf-type=UDR&requester-nf-type=PCF&service-names=nudr-dr&target-nf-set-id=set001.udrset.5gc.mnc012.mcc345', searchResult={\"validityPeriod\":100,\"nfInstances\":[{\"nfInstanceId\":\"fe7d992b-0541-4c7d-ab84-555550000000\",\"nfType\":\"UDR\",\"nfStatus\":\"REGISTERED\",\"fqdn\":\"nf2stub.gi-dina.svc\",\"priority\":1,\"capacity\":50,\"load\":10,\"locality\":\"1\",\"nfSetIdList\":[\"set001.udrset.5gc.mnc012.mcc345\"],\"udrInfo\":{\"supiRanges\":[{\"start\":\"450081000000000\",\"end\":\"450081002000000\"}],\"gpsiRanges\":[{\"start\":\"13100000000\",\"end\":\"13102000000\"}],\"supportedDataSets\":[\"POLICY\"]},\"nfServices\":[{\"serviceInstanceId\":\"94d8d19a-b0d9-4d6d-994f-39a49ed5c111\",\"serviceName\":\"nudr-dr\",\"versions\":[{\"apiVersionInUri\":\"v1\",\"apiFullVersion\":\"1.15.1.0\",\"expiry\":\"2019-08-03T18:55:08.871Z\"}],\"scheme\":\"http\",\"nfServiceStatus\":\"REGISTERED\",\"ipEndPoints\":[{\"transport\":\"TCP\",\"port\":8080}],\"allowedNfTypes\":[\"CHF\",\"PCF\"],\"priority\":1,\"capacity\":100,\"load\":50,\"recoveryTime\":\"2018-11-22T08:51:03.222Z\",\"locality\":\"1\"}],\"groupId\":\"udr1\"},{\"nfInstanceId\":\"fe7d992b-0541-4c7d-ab84-555551111111\",\"nfType\":\"UDR\",\"nfStatus\":\"REGISTERED\",\"fqdn\":\"nf21stub.gi-dina.svc\",\"priority\":2,\"capacity\":50,\"load\":20,\"locality\":\"2\",\"nfSetIdList\":[\"set001.udrset.5gc.mnc012.mcc345\"],\"udrInfo\":{\"supiRanges\":[{\"start\":\"450081000000000\",\"end\":\"450081002000000\"}],\"gpsiRanges\":[{\"start\":\"13100000000\",\"end\":\"13102000000\"}],\"supportedDataSets\":[\"POLICY\"]},\"nfServices\":[{\"serviceInstanceId\":\"94d8d19a-b0d9-4d6d-994f-39a49ed5c111\",\"serviceName\":\"nudr-dr\",\"versions\":[{\"apiVersionInUri\":\"v1\",\"apiFullVersion\":\"1.15.1.0\",\"expiry\":\"2019-08-03T18:55:08.871Z\"}],\"scheme\":\"http\",\"nfServiceStatus\":\"REGISTERED\",\"ipEndPoints\":[{\"transport\":\"TCP\",\"port\":8080}],\"allowedNfTypes\":[\"CHF\",\"PCF\"],\"priority\":2,\"capacity\":50,\"load\":20,\"recoveryTime\":\"2018-11-22T08:51:03.222Z\"}],\"groupId\":\"udr1\"},{\"nfInstanceId\":\"fe7d992b-0541-4c7d-ab84-555553333333\",\"nfType\":\"UDR\",\"nfStatus\":\"REGISTERED\",\"fqdn\":\"nf11stub.gi-dina.svc\",\"priority\":4,\"capacity\":50,\"load\":10,\"locality\":\"1\",\"nfSetIdList\":[\"set001.udrset.5gc.mnc012.mcc345\"],\"udrInfo\":{\"supiRanges\":[{\"start\":\"450081000000000\",\"end\":\"450081002000000\"}],\"gpsiRanges\":[{\"start\":\"13100000000\",\"end\":\"13102000000\"}],\"supportedDataSets\":[\"POLICY\"]},\"nfServices\":[{\"serviceInstanceId\":\"94d8d19a-b0d9-4d6d-994f-39a49ed5c111\",\"serviceName\":\"nudr-dr\",\"versions\":[{\"apiVersionInUri\":\"v1\",\"apiFullVersion\":\"1.15.1.0\",\"expiry\":\"2019-08-03T18:55:08.871Z\"}],\"scheme\":\"http\",\"nfServiceStatus\":\"REGISTERED\",\"ipEndPoints\":[{\"transport\":\"TCP\",\"port\":8080}],\"allowedNfTypes\":[\"CHF\",\"PCF\"],\"priority\":4,\"capacity\":50,\"load\":10,\"recoveryTime\":\"2018-11-22T08:51:03.222Z\"}],\"groupId\":\"udr1\"},{\"nfInstanceId\":\"fe7d992b-0541-4c7d-ab84-555554444444\",\"nfType\":\"UDR\",\"nfStatus\":\"REGISTERED\",\"fqdn\":\"nf12stub.gi-dina.svc\",\"priority\":5,\"capacity\":50,\"load\":40,\"locality\":\"2\",\"nfSetIdList\":[\"set002.udrset.5gc.mnc012.mcc345\"],\"udrInfo\":{\"supiRanges\":[{\"start\":\"450081000000000\",\"end\":\"450081002000000\"}],\"gpsiRanges\":[{\"start\":\"13100000000\",\"end\":\"13102000000\"}],\"supportedDataSets\":[\"POLICY\"]},\"nfServices\":[{\"serviceInstanceId\":\"94d8d19a-b0d9-4d6d-994f-39a49ed5c111\",\"serviceName\":\"nudr-dr\",\"versions\":[{\"apiVersionInUri\":\"v1\",\"apiFullVersion\":\"1.15.1.0\",\"expiry\":\"2019-08-03T18:55:08.871Z\"}],\"scheme\":\"http\",\"nfServiceStatus\":\"REGISTERED\",\"ipEndPoints\":[{\"transport\":\"TCP\",\"port\":8080}],\"allowedNfTypes\":[\"CHF\",\"PCF\"],\"priority\":5,\"capacity\":50,\"load\":40,\"recoveryTime\":\"2018-11-22T08:51:03.222Z\"}],\"groupId\":\"udr1\"},{\"nfInstanceId\":\"fe7d992b-0541-4c7d-ab84-555552222222\",\"nfType\":\"UDR\",\"nfStatus\":\"REGISTERED\",\"fqdn\":\"nf22stub.gi-dina.svc\",\"priority\":3,\"capacity\":50,\"load\":30,\"locality\":\"1\",\"nfSetIdList\":[\"set002.udrset.5gc.mnc012.mcc345\"],\"udrInfo\":{\"supiRanges\":[{\"start\":\"450081000000000\",\"end\":\"450081002000000\"}],\"gpsiRanges\":[{\"start\":\"13100000000\",\"end\":\"13102000000\"}],\"supportedDataSets\":[\"POLICY\"]},\"nfServices\":[{\"serviceInstanceId\":\"94d8d19a-b0d9-4d6d-994f-39a49ed5c111\",\"serviceName\":\"nudr-dr\",\"versions\":[{\"apiVersionInUri\":\"v1\",\"apiFullVersion\":\"1.15.1.0\",\"expiry\":\"2019-08-03T18:55:08.871Z\"}],\"scheme\":\"http\",\"nfServiceStatus\":\"REGISTERED\",\"ipEndPoints\":[{\"transport\":\"TCP\",\"port\":8080}],\"allowedNfTypes\":[\"CHF\",\"PCF\"],\"priority\":3,\"capacity\":50,\"load\":30,\"recoveryTime\":\"2018-11-22T08:51:03.222Z\"}],\"groupId\":\"udr1\"}],\"nrfSupportedFeatures\":\"72\"}, sourceType=NRF}","endOfBatch":false,"loggerFqcn":"org.apache.logging.slf4j.Log4jLogger","threadId":90,"threadPriority":5,"messageTimestamp":"2023-12-13T06:11:51.770+0000"}


Discovery of UDR for the second time:

{"instant":{"epochSecond":1702448069,"nanoOfSecond":173667948},"thread":"XNIO-1 task-2","level":"DEBUG","loggerName":"com.oracle.cgbu.cnc.nrf.core.discoveryrules.DiscoveryRule","message":"Checking if cache applies for a discovery request (DiscoveryCache feature enabled: true, OC-Force-Rediscovery requested: false)","endOfBatch":false,"loggerFqcn":"org.apache.logging.slf4j.Log4jLogger","threadId":90,"threadPriority":5,"messageTimestamp":"2023-12-13T06:14:29.173+0000"}
{"instant":{"epochSecond":1702448069,"nanoOfSecond":173707825},"thread":"XNIO-1 task-2","level":"DEBUG","loggerName":"com.oracle.cgbu.cnc.nrf.core.discoveryrules.DiscoveryRule","message":"Query Parameters validation. IsFullyMatch -> true, Params from request -> [target-nf-type, requester-nf-type, service-names, target-nf-set-id], Params from config -> [target-nf-type, requester-nf-type, service-names, target-nf-set-id]","endOfBatch":false,"loggerFqcn":"org.apache.logging.slf4j.Log4jLogger","threadId":90,"threadPriority":5,"messageTimestamp":"2023-12-13T06:14:29.173+0000"}
{"instant":{"epochSecond":1702448069,"nanoOfSecond":173763918},"thread":"XNIO-1 task-2","level":"INFO","loggerName":"com.oracle.cgbu.cnc.nrf.core.discoveryrules.DiscoveryRule","message":"DiscoveryCache is enabled and queryParameters matched. Proceeding with DiscoveryResponse retrieval from memory","endOfBatch":false,"loggerFqcn":"org.apache.logging.slf4j.Log4jLogger","threadId":90,"threadPriority":5,"messageTimestamp":"2023-12-13T06:14:29.173+0000"}
{"instant":{"epochSecond":1702448069,"nanoOfSecond":173787036},"thread":"XNIO-1 task-2","level":"DEBUG","loggerName":"com.oracle.cgbu.cnc.nrf.core.discoveryrules.DiscoveryEvaluator","message":"Rule applied: CacheRule","endOfBatch":false,"loggerFqcn":"org.apache.logging.slf4j.Log4jLogger","threadId":90,"threadPriority":5,"messageTimestamp":"2023-12-13T06:14:29.173+0000"}
{"instant":{"epochSecond":1702448069,"nanoOfSecond":173803555},"thread":"XNIO-1 task-2","level":"DEBUG","loggerName":"com.oracle.cgbu.cnc.nrf.core.discoveryrules.CacheRule","message":"Applying Cache Rule, grabbing NRF response from Cache","endOfBatch":false,"loggerFqcn":"org.apache.logging.slf4j.Log4jLogger","threadId":90,"threadPriority":5,"messageTimestamp":"2023-12-13T06:14:29.173+0000"}
{"instant":{"epochSecond":1702448069,"nanoOfSecond":178149415},"thread":"XNIO-1 task-2","level":"INFO","loggerName":"com.oracle.cgbu.cnc.nrf.core.usecases.cache.GetCacheDiscoveryResponseUseCase","message":"Successful retrieval of Discovery Response stored in Cache/DB, proceeding with validation","endOfBatch":false,"loggerFqcn":"org.apache.logging.slf4j.Log4jLogger","threadId":90,"threadPriority":5,"messageTimestamp":"2023-12-13T06:14:29.178+0000"}
{"instant":{"epochSecond":1702448069,"nanoOfSecond":178179123},"thread":"XNIO-1 task-2","level":"INFO","loggerName":"com.oracle.cgbu.cnc.nrf.core.usecases.cache.GetCacheDiscoveryResponseUseCase","message":"Discovery Response retrieved from Cache/DB isAboutToExpire value : false ","endOfBatch":false,"loggerFqcn":"org.apache.logging.slf4j.Log4jLogger","threadId":90,"threadPriority":5,"messageTimestamp":"2023-12-13T06:14:29.178+0000"}
{"instant":{"epochSecond":1702448069,"nanoOfSecond":178199339},"thread":"XNIO-1 task-2","level":"INFO","loggerName":"com.oracle.cgbu.cnc.nrf.core.usecases.cache.GetCacheDiscoveryResponseUseCase","message":"Discovery Response retrieved from Cache/DB is expired value : true ","endOfBatch":false,"loggerFqcn":"org.apache.logging.slf4j.Log4jLogger","threadId":90,"threadPriority":5,"messageTimestamp":"2023-12-13T06:14:29.178+0000"}
{"instant":{"epochSecond":1702448069,"nanoOfSecond":178405635},"thread":"XNIO-1 task-2","level":"INFO","loggerName":"com.oracle.cgbu.cnc.nrf.core.usecases.cache.GetCacheDiscoveryResponseUseCase","message":"Discovery Response has expired, updating and retrieving from NRF to Cache","endOfBatch":false,"loggerFqcn":"org.apache.logging.slf4j.Log4jLogger","threadId":90,"threadPriority":5,"messageTimestamp":"2023-12-13T06:14:29.178+0000"}
{"instant":{"epochSecond":1702448069,"nanoOfSecond":178450502},"thread":"XNIO-1 task-2","level":"INFO","loggerName":"com.oracle.cgbu.cnc.nrf.core.usecases.nrf.GetNrfDiscoveryResponseUseCase","message":"SearchData : {\"targetNfType\":\"UDR\",\"serviceNames\":[\"nudr-dr\"],\"requesterNfType\":\"PCF\",\"nfInfoParamsPresent\":false,\"serviceInfoParamsPresent\":true,\"enableF3\":true,\"enableF5\":false,\"targetNfSetId\":\"set001.udrset.5gc.mnc012.mcc345\",\"retentionPeriod\":5000,\"rawQueryParameters\":\"target-nf-type=UDR&requester-nf-type=PCF&service-names=nudr-dr&target-nf-set-id=set001.udrset.5gc.mnc012.mcc345\",\"forceRediscoveryEnabled\":false}","endOfBatch":false,"loggerFqcn":"org.apache.logging.slf4j.Log4jLogger","threadId":90,"threadPriority":5,"messageTimestamp":"2023-12-13T06:14:29.178+0000"}
{"instant":{"epochSecond":1702448069,"nanoOfSecond":178601367},"thread":"pool-10-thread-1","level":"INFO","loggerName":"com.oracle.cgbu.cnc.nrf.api.NRFClientApi","message":"Entering sendOnDemandNfDiscoverRequest function","endOfBatch":false,"loggerFqcn":"org.apache.logging.slf4j.Log4jLogger","threadId":101,"threadPriority":5,"messageTimestamp":"2023-12-13T06:14:29.178+0000"}
{"instant":{"epochSecond":1702448069,"nanoOfSecond":179243376},"thread":"pool-10-thread-1","level":"INFO","loggerName":"com.oracle.cgbu.cnc.nrf.api.NRFClientApi","message":"Send NfDiscover request with searchData: {\"targetNfType\":\"UDR\",\"serviceNames\":[\"nudr-dr\"],\"requesterNfType\":\"PCF\",\"nfInfoParamsPresent\":false,\"serviceInfoParamsPresent\":true,\"enableF3\":true,\"enableF5\":false,\"targetNfSetId\":\"set001.udrset.5gc.mnc012.mcc345\",\"retentionPeriod\":5000,\"rawQueryParameters\":\"target-nf-type=UDR&requester-nf-type=PCF&service-names=nudr-dr&target-nf-set-id=set001.udrset.5gc.mnc012.mcc345\",\"forceRediscoveryEnabled\":false}","endOfBatch":false,"loggerFqcn":"org.apache.logging.slf4j.Log4jLogger","threadId":101,"threadPriority":5,"messageTimestamp":"2023-12-13T06:14:29.179+0000"}
{"instant":{"epochSecond":1702448069,"nanoOfSecond":179374539},"thread":"pool-10-thread-1","level":"DEBUG","loggerName":"com.oracle.cgbu.cnc.nrf.api.NRFClientApi","message":"sendRequestToNrf nrfRequest : NRFRequest [scheme=http, rootURI=nf1stub.gi-dina.svc:8080, resourcePath=/nnrf-disc/v1/nf-instances, method=GET, body=null, headers=[], searchData={\"targetNfType\":\"UDR\",\"serviceNames\":[\"nudr-dr\"],\"requesterNfType\":\"PCF\",\"nfInfoParamsPresent\":false,\"serviceInfoParamsPresent\":true,\"enableF3\":true,\"enableF5\":false,\"targetNfSetId\":\"set001.udrset.5gc.mnc012.mcc345\",\"retentionPeriod\":5000,\"rawQueryParameters\":\"target-nf-type=UDR&requester-nf-type=PCF&service-names=nudr-dr&target-nf-set-id=set001.udrset.5gc.mnc012.mcc345\",\"forceRediscoveryEnabled\":false}, routeCount=0, requestType=NFDISCOVER]","endOfBatch":false,"loggerFqcn":"org.apache.logging.slf4j.Log4jLogger","threadId":101,"threadPriority":5,"messageTimestamp":"2023-12-13T06:14:29.179+0000"}
{"instant":{"epochSecond":1702448069,"nanoOfSecond":179497176},"thread":"pool-10-thread-1","level":"INFO","loggerName":"com.oracle.cgbu.cnc.nrf.api.NRFClientApi","message":"Returning retryConfig for ALL_REQUESTS NRFRetryConfig [serviceRequestType=ALL_REQUESTS, primaryNRFRetryCount=0, nonPrimaryNRFRetryCount=0, alternateNRFRetryCount=-1, errorReasonsForFailure=[503, 504, 500, SocketTimeoutException, JsonProcessingException, UnknownHostException, NoRouteToHostException], gatewayErrorCodes=[503], requestTimeout=10]","endOfBatch":false,"loggerFqcn":"org.apache.logging.slf4j.Log4jLogger","threadId":101,"threadPriority":5,"messageTimestamp":"2023-12-13T06:14:29.179+0000"}
{"instant":{"epochSecond":1702448069,"nanoOfSecond":179552046},"thread":"pool-10-thread-1","level":"DEBUG","loggerName":"com.oracle.cgbu.cnc.nrf.api.NRFClientApi","message":"Sending request to NRF nf1stub.gi-dina.svc:8080, routeCount=0, attempt=0","endOfBatch":false,"loggerFqcn":"org.apache.logging.slf4j.Log4jLogger","threadId":101,"threadPriority":5,"messageTimestamp":"2023-12-13T06:14:29.179+0000"}
{"instant":{"epochSecond":1702448069,"nanoOfSecond":179577169},"thread":"pool-10-thread-1","level":"DEBUG","loggerName":"com.oracle.cgbu.cnc.nrf.api.NRFClientApi","message":"trigger","endOfBatch":false,"loggerFqcn":"org.apache.logging.slf4j.Log4jLogger","threadId":101,"threadPriority":5,"messageTimestamp":"2023-12-13T06:14:29.179+0000"}
{"instant":{"epochSecond":1702448069,"nanoOfSecond":179601014},"thread":"pool-10-thread-1","level":"INFO","loggerName":"com.oracle.cgbu.cnc.nrf.api.NRFClientApi","message":"Returning retryConfig for ALL_REQUESTS NRFRetryConfig [serviceRequestType=ALL_REQUESTS, primaryNRFRetryCount=0, nonPrimaryNRFRetryCount=0, alternateNRFRetryCount=-1, errorReasonsForFailure=[503, 504, 500, SocketTimeoutException, JsonProcessingException, UnknownHostException, NoRouteToHostException], gatewayErrorCodes=[503], requestTimeout=10]","endOfBatch":false,"loggerFqcn":"org.apache.logging.slf4j.Log4jLogger","threadId":101,"threadPriority":5,"messageTimestamp":"2023-12-13T06:14:29.179+0000"}
{"instant":{"epochSecond":1702448069,"nanoOfSecond":197764440},"thread":"pool-10-thread-1","level":"INFO","loggerName":"com.oracle.cgbu.cnc.nrf.api.NRFClientApi","message":"Request returned response with status code : 200","endOfBatch":false,"loggerFqcn":"org.apache.logging.slf4j.Log4jLogger","threadId":101,"threadPriority":5,"messageTimestamp":"2023-12-13T06:14:29.197+0000"}
{"instant":{"epochSecond":1702448069,"nanoOfSecond":203073867},"thread":"pool-10-thread-1","level":"INFO","loggerName":"com.oracle.cgbu.cnc.nrf.api.NRFClientApi","message":"Successful Response code received","endOfBatch":false,"loggerFqcn":"org.apache.logging.slf4j.Log4jLogger","threadId":101,"threadPriority":5,"messageTimestamp":"2023-12-13T06:14:29.203+0000"}
{"instant":{"epochSecond":1702448069,"nanoOfSecond":203133658},"thread":"pool-10-thread-1","level":"INFO","loggerName":"com.oracle.cgbu.cnc.nrf.api.NRFClientApi","message":"sendOnDemandNfDiscoverRequest with searchData: {\"targetNfType\":\"UDR\",\"serviceNames\":[\"nudr-dr\"],\"requesterNfType\":\"PCF\",\"nfInfoParamsPresent\":false,\"serviceInfoParamsPresent\":true,\"enableF3\":true,\"enableF5\":false,\"targetNfSetId\":\"set001.udrset.5gc.mnc012.mcc345\",\"retentionPeriod\":5000,\"rawQueryParameters\":\"target-nf-type=UDR&requester-nf-type=PCF&service-names=nudr-dr&target-nf-set-id=set001.udrset.5gc.mnc012.mcc345\",\"forceRediscoveryEnabled\":false} returned status code : 200","endOfBatch":false,"loggerFqcn":"org.apache.logging.slf4j.Log4jLogger","threadId":101,"threadPriority":5,"messageTimestamp":"2023-12-13T06:14:29.203+0000"}
{"instant":{"epochSecond":1702448069,"nanoOfSecond":203337703},"thread":"XNIO-1 task-2","level":"INFO","loggerName":"com.oracle.cgbu.cnc.nrf.core.usecases.nrf.GetNrfDiscoveryResponseUseCase","message":"Received Discovery Result. Code: 200, Body (SearchResult): {\"validityPeriod\": 100, \"nfInstances\": [{\"nfInstanceId\": \"fe7d992b-0541-4c7d-ab84-555550000000\", \"nfSetIdList\": [\"set001.udrset.5gc.mnc012.mcc345\"], \"nfType\": \"UDR\", \"nfStatus\": \"REGISTERED\", \"plmnList\": null, \"nsiList\": null, \"fqdn\": \"nf2stub.gi-dina.svc\", \"interPlmnFqdn\": null, \"ipv4Addresses\": null, \"ipv6Addresses\": null, \"priority\": 1, \"capacity\": 50, \"load\": 10, \"locality\": \"1\", \"pcfInfo\": null, \"udmInfo\": null, \"ausfInfo\": null, \"amfInfo\": null, \"smfInfo\": null, \"upfInfo\": null, \"groupId\": \"udr1\", \"udrInfo\": {\"supiRanges\": [{\"start\": \"450081000000000\", \"end\": \"450081002000000\"}], \"gpsiRanges\": [{\"start\": \"13100000000\", \"end\": \"13102000000\"}], \"supportedDataSets\": [\"POLICY\"]}, \"bsfInfo\": null, \"customInfo\": null, \"recoveryTime\": null, \"nfServices\": [{\"serviceInstanceId\": \"94d8d19a-b0d9-4d6d-994f-39a49ed5c111\", \"serviceName\": \"nudr-dr\", \"versions\": [{\"apiVersionInUri\": \"v1\", \"apiFullVersion\": \"1.15.1.0\", \"expiry\": \"2019-08-03T18:55:08.871+0000\"}], \"scheme\": \"http\", \"nfServiceStatus\": \"REGISTERED\", \"fqdn\": null, \"interPlmnFqdn\": null, \"ipEndPoints\": [{\"ipv4Address\": null, \"ipv6Address\": null, \"transport\": \"TCP\", \"port\": 8080}], \"apiPrefix\": null, \"defaultNotificationSubscriptions\": null, \"allowedPlmns\": null, \"allowedNfTypes\": [\"CHF\", \"PCF\"], \"allowedNfDomains\": null, \"allowedNssais\": null, \"priority\": 1, \"capacity\": 100, \"load\": 50, \"locality\": \"1\", \"recoveryTime\": 1542876663222, \"supportedFeatures\": null}]}, {\"nfInstanceId\": \"fe7d992b-0541-4c7d-ab84-555551111111\", \"nfSetIdList\": [\"set001.udrset.5gc.mnc012.mcc345\"], \"nfType\": \"UDR\", \"nfStatus\": \"REGISTERED\", \"plmnList\": null, \"nsiList\": null, \"fqdn\": \"nf21stub.gi-dina.svc\", \"interPlmnFqdn\": null, \"ipv4Addresses\": null, \"ipv6Addresses\": null, \"priority\": 2, \"capacity\": 50, \"load\": 20, \"locality\": \"2\", \"pcfInfo\": null, \"udmInfo\": null, \"ausfInfo\": null, \"amfInfo\": null, \"smfInfo\": null, \"upfInfo\": null, \"groupId\": \"udr1\", \"udrInfo\": {\"supiRanges\": [{\"start\": \"450081000000000\", \"end\": \"450081002000000\"}], \"gpsiRanges\": [{\"start\": \"13100000000\", \"end\": \"13102000000\"}], \"supportedDataSets\": [\"POLICY\"]}, \"bsfInfo\": null, \"customInfo\": null, \"recoveryTime\": null, \"nfServices\": [{\"serviceInstanceId\": \"94d8d19a-b0d9-4d6d-994f-39a49ed5c111\", \"serviceName\": \"nudr-dr\", \"versions\": [{\"apiVersionInUri\": \"v1\", \"apiFullVersion\": \"1.15.1.0\", \"expiry\": \"2019-08-03T18:55:08.871+0000\"}], \"scheme\": \"http\", \"nfServiceStatus\": \"REGISTERED\", \"fqdn\": null, \"interPlmnFqdn\": null, \"ipEndPoints\": [{\"ipv4Address\": null, \"ipv6Address\": null, \"transport\": \"TCP\", \"port\": 8080}], \"apiPrefix\": null, \"defaultNotificationSubscriptions\": null, \"allowedPlmns\": null, \"allowedNfTypes\": [\"CHF\", \"PCF\"], \"allowedNfDomains\": null, \"allowedNssais\": null, \"priority\": 2, \"capacity\": 50, \"load\": 20, \"recoveryTime\": 1542876663222, \"supportedFeatures\": null}]}, {\"nfInstanceId\": \"fe7d992b-0541-4c7d-ab84-555553333333\", \"nfSetIdList\": [\"set001.udrset.5gc.mnc012.mcc345\"], \"nfType\": \"UDR\", \"nfStatus\": \"REGISTERED\", \"plmnList\": null, \"nsiList\": null, \"fqdn\": \"nf11stub.gi-dina.svc\", \"interPlmnFqdn\": null, \"ipv4Addresses\": null, \"ipv6Addresses\": null, \"priority\": 4, \"capacity\": 50, \"load\": 10, \"locality\": \"1\", \"pcfInfo\": null, \"udmInfo\": null, \"ausfInfo\": null, \"amfInfo\": null, \"smfInfo\": null, \"upfInfo\": null, \"groupId\": \"udr1\", \"udrInfo\": {\"supiRanges\": [{\"start\": \"450081000000000\", \"end\": \"450081002000000\"}], \"gpsiRanges\": [{\"start\": \"13100000000\", \"end\": \"13102000000\"}], \"supportedDataSets\": [\"POLICY\"]}, \"bsfInfo\": null, \"customInfo\": null, \"recoveryTime\": null, \"nfServices\": [{\"serviceInstanceId\": \"94d8d19a-b0d9-4d6d-994f-39a49ed5c111\", \"serviceName\": \"nudr-dr\", \"versions\": [{\"apiVersionInUri\": \"v1\", \"apiFullVersion\": \"1.15.1.0\", \"expiry\": \"2019-08-03T18:55:08.871+0000\"}], \"scheme\": \"http\", \"nfServiceStatus\": \"REGISTERED\", \"fqdn\": null, \"interPlmnFqdn\": null, \"ipEndPoints\": [{\"ipv4Address\": null, \"ipv6Address\": null, \"transport\": \"TCP\", \"port\": 8080}], \"apiPrefix\": null, \"defaultNotificationSubscriptions\": null, \"allowedPlmns\": null, \"allowedNfTypes\": [\"CHF\", \"PCF\"], \"allowedNfDomains\": null, \"allowedNssais\": null, \"priority\": 4, \"capacity\": 50, \"load\": 10, \"recoveryTime\": 1542876663222, \"supportedFeatures\": null}]}, {\"nfInstanceId\": \"fe7d992b-0541-4c7d-ab84-555554444444\", \"nfSetIdList\": [\"set002.udrset.5gc.mnc012.mcc345\"], \"nfType\": \"UDR\", \"nfStatus\": \"REGISTERED\", \"plmnList\": null, \"nsiList\": null, \"fqdn\": \"nf12stub.gi-dina.svc\", \"interPlmnFqdn\": null, \"ipv4Addresses\": null, \"ipv6Addresses\": null, \"priority\": 5, \"capacity\": 50, \"load\": 40, \"locality\": \"2\", \"pcfInfo\": null, \"udmInfo\": null, \"ausfInfo\": null, \"amfInfo\": null, \"smfInfo\": null, \"upfInfo\": null, \"groupId\": \"udr1\", \"udrInfo\": {\"supiRanges\": [{\"start\": \"450081000000000\", \"end\": \"450081002000000\"}], \"gpsiRanges\": [{\"start\": \"13100000000\", \"end\": \"13102000000\"}], \"supportedDataSets\": [\"POLICY\"]}, \"bsfInfo\": null, \"customInfo\": null, \"recoveryTime\": null, \"nfServices\": [{\"serviceInstanceId\": \"94d8d19a-b0d9-4d6d-994f-39a49ed5c111\", \"serviceName\": \"nudr-dr\", \"versions\": [{\"apiVersionInUri\": \"v1\", \"apiFullVersion\": \"1.15.1.0\", \"expiry\": \"2019-08-03T18:55:08.871+0000\"}], \"scheme\": \"http\", \"nfServiceStatus\": \"REGISTERED\", \"fqdn\": null, \"interPlmnFqdn\": null, \"ipEndPoints\": [{\"ipv4Address\": null, \"ipv6Address\": null, \"transport\": \"TCP\", \"port\": 8080}], \"apiPrefix\": null, \"defaultNotificationSubscriptions\": null, \"allowedPlmns\": null, \"allowedNfTypes\": [\"CHF\", \"PCF\"], \"allowedNfDomains\": null, \"allowedNssais\": null, \"priority\": 5, \"capacity\": 50, \"load\": 40, \"recoveryTime\": 1542876663222, \"supportedFeatures\": null}]}, {\"nfInstanceId\": \"fe7d992b-0541-4c7d-ab84-555552222222\", \"nfSetIdList\": [\"set002.udrset.5gc.mnc012.mcc345\"], \"nfType\": \"UDR\", \"nfStatus\": \"REGISTERED\", \"plmnList\": null, \"nsiList\": null, \"fqdn\": \"nf22stub.gi-dina.svc\", \"interPlmnFqdn\": null, \"ipv4Addresses\": null, \"ipv6Addresses\": null, \"priority\": 3, \"capacity\": 50, \"load\": 30, \"locality\": \"1\", \"pcfInfo\": null, \"udmInfo\": null, \"ausfInfo\": null, \"amfInfo\": null, \"smfInfo\": null, \"upfInfo\": null, \"groupId\": \"udr1\", \"udrInfo\": {\"supiRanges\": [{\"start\": \"450081000000000\", \"end\": \"450081002000000\"}], \"gpsiRanges\": [{\"start\": \"13100000000\", \"end\": \"13102000000\"}], \"supportedDataSets\": [\"POLICY\"]}, \"bsfInfo\": null, \"customInfo\": null, \"recoveryTime\": null, \"nfServices\": [{\"serviceInstanceId\": \"94d8d19a-b0d9-4d6d-994f-39a49ed5c111\", \"serviceName\": \"nudr-dr\", \"versions\": [{\"apiVersionInUri\": \"v1\", \"apiFullVersion\": \"1.15.1.0\", \"expiry\": \"2019-08-03T18:55:08.871+0000\"}], \"scheme\": \"http\", \"nfServiceStatus\": \"REGISTERED\", \"fqdn\": null, \"interPlmnFqdn\": null, \"ipEndPoints\": [{\"ipv4Address\": null, \"ipv6Address\": null, \"transport\": \"TCP\", \"port\": 8080}], \"apiPrefix\": null, \"defaultNotificationSubscriptions\": null, \"allowedPlmns\": null, \"allowedNfTypes\": [\"CHF\", \"PCF\"], \"allowedNfDomains\": null, \"allowedNssais\": null, \"priority\": 3, \"capacity\": 50, \"load\": 30, \"recoveryTime\": 1542876663222, \"supportedFeatures\": null}]}]}","endOfBatch":false,"loggerFqcn":"org.apache.logging.slf4j.Log4jLogger","threadId":90,"threadPriority":5,"messageTimestamp":"2023-12-13T06:14:29.203+0000"}
{"instant":{"epochSecond":1702448069,"nanoOfSecond":203984193},"thread":"XNIO-1 task-2","level":"INFO","loggerName":"com.oracle.cgbu.cnc.nrf.core.usecases.nrf.GetNrfDiscoveryResponseUseCase","message":"Dynamic discovery cache enabled : false","endOfBatch":false,"loggerFqcn":"org.apache.logging.slf4j.Log4jLogger","threadId":90,"threadPriority":5,"messageTimestamp":"2023-12-13T06:14:29.203+0000"}

4.36 Handling Race Condition Between Gx and Sy Sessions in two sites

Policy supports handling race condition between Gx and Sy sessions in two sites that result in Sy stale sessionsin PDS.

Race condition between Gx and Sy sessions

A sample race condition is when the PGW opens two different sessions (such as data and voice or data and data sessions) with two different PCRF Core instances on site1 and site2, termination request for both the sessions are sent to different sites.

While the session create Diameter Credit-Control-Request (CCR)-I appears to come in a sequence succession, first data and then voice, the terminate request for both voice and data are received at the same time in two different sites, while the device disconnects from the network.

As this is happening at the same time, both sites Site 1 and Site 2 in their local database find that there is another Gx session open. Both sites close their own Gx sessions, but as they both (at this time) see a remaining Gx session at the other site, they keep the Sy session as open.

As the Session Termination Request (Sy-STR) is missing, the session remains active in OCS resulting in stale Sy session.

Note:

Currently, Policy only supports minimizing the number of stale sessions, but cannot completely avoid the race condition.

Also, Policy does not support error handling for this feature.

Handling Stale Sy sessions

Revalidating the Sy session to ensure that the Sy session is still valid by polling OCS (ResetContext)

1. Upon establishment of the first Gx session for the subscriber, if the Sy data is present on PDS, PDS sends an Sy Spending-Limit-Request (SLR)-Intermediate to OCS requesting all the policy counters.
2. If PDS receives a success response from OCS, it indicates that PDS is in sync with OCS.
3. If PDS receives UNKNOWN_SESSION_ID error, PDS deletes the old Sy session and creates a new one.

Figure 4-70 SLA Returns Success

1. PCRF Core receives a CCR-I for first session through Diameter Gateway.
2. PCRF Core sends a Get request to PDS with resetContext flag set to true.
3. PDS searches for the corresponding user data in its database.
4. If the data exists, PDS sends an Sy SLR-Intermediate request to OCS to fetch all the policy counters. PDS sends this request through Diameter Connector routed through Diameter Gateway.
5. OCS reponds with Spending Limit Answer (SLA) with success result code 2001. The response is sent from OCS to Diameter Connector routed through Diameter Gateway.
6. Diameter Connectors returns the success response to PDS.
7. PDS updates the details in its database and returns the response to PCRF Core.
8. PCRF Core responds to the CCR-I request for session 1 with Diameter Credit-Control-Request (CCA).

Figure 4-71 SLA Returns 5002, Get New Sy Session, PDS Update Sy Session

1. PCRF Core receives a CCR-I for first session through Diameter Gateway.
2. PCRF Core sends a Get request to PDS with resetContext flag set to true.
3. PDS searches for the corresponding user data in its database.
4. If the data exists, PDS sends an Sy SLR-Intermediate request to OCS to fetch all the policy counters. PDS sends this request through Diameter Connector routed through Diameter Gateway.
5. OCS reponds with Spending Limit Answer (SLA) with success result code 5002 indicating Diameter Unknown Session Id. The response is sent from OCS to Diameter Connector routed through Diameter Gateway.
6. Diameter Connector sends a 404 error to PDS.
7. PDS sends a GET request with SLR Type: Initial to Diameter Connector to get the new Sy session.
8. Diameter Connector forwards the SLR - Initial request to OCS through Diameter Gateway.
9. OCS sends SLA with Result-Code 2001 to Diameter Connetor through Diameter Gateway indicating Diameter Success.
10. Diameter Connector returns the success response to PDS.
11. PDS updates its database and returns the response to PCRF Core.
12. PCRF Core responds to the CCR-I request for session 1 with Diameter Credit-Control-Request (CCA).

Note:

For any unsuccessful response other than 5002 (404) the existing record will be deleted.

Handling stale Sy sessions by limiting the number of Gx sessions that can be associated with an Sy session for a specific APN

1. PCRF provides Max Sessions Count to specify how many Gx sessions can be associated with an Sy session for a specific APN.
2. If Max Sessions Count exceeds the limit, PCRF revalidates the Sy session with OCS.

This method protects against cases where Gx CCR-T are not sent by the PGW/received by the PCRF for a specific APN.

Here is an example call flow with Max Sessions Count=1. The request for the first Gx session results with a success response, while the second request is revalidated.

Figure 4-72 First Gx Session

1. PCRF Core receives a CCR-I for first session through Diameter Gateway.
2. PCRF Core sends a Get request to PDS with resetContext flag set to true along with other parameters such as DNN (with Data Network Name), SST (with Slice or Service Type) and SD (with Slice Differentiator Name).
3. PDS searches for the data in its database.
4. If the data does not exist for the given Sy SessionId, PDS sends an Sy SLR-Intermediate request to OCS to fetch all the policy counters. PDS sends this request through Diameter Connector routed through Diameter Gateway.
5. OCS reponds with Spending Limit Answer (SLA) with success result code 2001. The response is sent from OCS to Diameter Connector routed through Diameter Gateway.
6. Diameter Connectors returns the success response to PDS.
7. PDS updates the details in its database and returns the response to PCRF Core.
8. PCRF Core responds to the CCR-I request for session 1 with Diameter Credit-Control-Request (CCA).

Figure 4-73 Second Gx Session

1. PCRF Core receives a CCR-I for second session through Diameter Gateway.
2. PCRF Core sends a Get request to PDS with resetContext flag set to false along with other parameters such as DNN (with Data Network Name), SST (with Slice or Service Type) and SD (with Slice Differentiator Name).
3. PDS searches for the data in its database.
4. If the data exists for the given Sy SessionId, PDS sends an Sy SLR-Intermediate request to OCS to fetch all the policy counters. PDS sends this request through Diameter Connector routed through Diameter Gateway.
5. OCS reponds with Spending Limit Answer (SLA) with success result code 2001. The response is sent from OCS to Diameter Connector routed through Diameter Gateway.
6. Diameter Connectors returns 204 no data response to PDS.
7. PDS updates the details in its database and returns the response to PCRF Core.
8. PCRF Core responds to the CCR-I request for session 2 with Diameter Credit-Control-Request (CCA).

Figure 4-74 Second Gx Session: SLA Returns 5002, Get New Sy Session, PDS Update Sy Session

1. PCRF Core receives a CCR-I for second session through Diameter Gateway.
2. PCRF Core sends a Get request to PDS with resetContext flag set to false along with other parameters such as DNN (with Data Network Name), SST (with Slice or Service Type) and SD (with Slice Differentiator Name).
3. PDS searches for the data in its database.
4. If the data exists for the given Sy SessionId, PDS sends an Sy SLR-Intermediate request to OCS to fetch all the policy counters. PDS sends this request through Diameter Connector routed through Diameter Gateway.
5. OCS reponds with Spending Limit Answer (SLA) with success result code 5002. The response is sent from OCS to Diameter Connector routed through Diameter Gateway.
6. Diameter Connectors returns 404 error to PDS.
7. PDS sends a GET request with SLR Type: Initial to Diameter Connector to get the new Sy session.
8. Diameter Connector forwards the SLR - Initial request to OCS through Diameter Gateway.
9. OCS sends SLA with Result-Code 2001 to Diameter Connetor through Diameter Gateway indicating Diameter Success.
10. Diameter Connector returns the 204 response to PDS.
11. PDS updates its database and returns the response to PCRF Core.
12. PCRF Core responds to the CCR-I request for session 1 with Diameter Credit-Control-Request (CCA).

Managing Handling Race Condition Between Gx and Sy Sessions over two sites

Enable

To enable the PDS revalidation functionality:

You can enable the PDS revalidation functionality using the CNC Console or REST API for Policy.

• Enable using CNC Console:

  To enable revalidation of the Sy stale sessions, set the value of USER.ocsSpendingLimit.resetContextOnGxCreate key under Advanced Settings in Settings page for PCRF Core to true.

  For more details, see PDS Settings.

• Enable using REST API:

  To enable the revalidation functionality, configure the advanced settings keys in the ​{apiRoot}​/oc-cnpolicy-configuration​/v1​/services​/pcrfcore​/settings REST API.

  For more details, see Policy REST Specifications section in Oracle Communications Cloud Native Core, Converged Policy REST Specification Guide.

Configure

You can configure the revalidation functionality to handle the stale Sy sessions using CNC Console or REST API for Policy.

• Configure using CNC Console:

  For revalidating Sy sessions, configure Enable Fetch and Resubscribe and Session Count per DNN/APN List Settings under Settings page for PDS.

  For more information, see PDS Settings.

• Configure using REST API: Policy provides {apiRoot}​/oc-cnpolicy-configuration​/v1​/services​/pds​/pdsSettings REST API to configure the PDS revalidation functionality.

Observability

Metrics

The following PDS metrics are used to revalidate the Sy sessions:

• revalidation_request
• revalidation_response

For more details on these metrics, see Policy DS Metrics.

4.37 Support for Policy Action to Send the Notify Terminate

PCF provide policy rules to network functions SMF/AMF. It integrates with AMF for Access and Mobility Policy Control and User Equipment (UE) related policies and with SMF for session management policies. To provide updated Policies, PCF initiates an update notification request toward SMF/AMF. On receiving SMF/AMF response, the PCF either decides to update the Policies or sends request to terminate the policy association.

The PCF policy engine evaluates configured Policies that are triggered by events received from SMF, AMF, CHF, and UDR. The PCF receives policy triggers during the following cases:

• UDR notifies the PCF about a Policy subscription changes
• CHF notifies PCF of Policy counter status changes
• AMF notifies PCF for AM and UE Policy updates
• SMF notifies PCF for session and PCC updates

On receiving policy trigger information from PCF, the Policy Runtime Engine (PRE) evaluates the Policies and makes the requested policy decision. Based on the policy decision that is made after evaluating the Policies, the PCF may decide to send an update or terminate request toward AMF/SMF. PCF applies these policy decision by interacting with AMF/SMF.

PCF Triggering AM UpdateNotify Terminate

The following flowchart illustrates the flow of PCF triggering AM terminateNotify request toward AMF for termination of the Policy association.

Figure 4-75 PCF Triggering AM UpdateNotify Terminate

1: Start

2: If notifications requests are coming from either UDR or CHF or AMF, go to step 3, if not, go to step 7.

3: User/Spending limit data updated in AM association.

4: Request from AM service goes to PRE.

5: PRE evaluates the policies. If ReleaseSession action (with or without cause) is present go to step 6, if not, go to step 7.

6: Trigger AM terminate notify toward AMF.

7: AM Terminate notify is not triggered.

Policy blockly Release Session with cause holds the PCF cause for termination of AM policy association. The cause for termination is configurable by the user and the default cause value is UE_SUBSCRIPTION.

PCF request for Termination of AM/SM/UE Policy Association

If PCF requests the termination of AM/SM Policy association, it sends an HTTP Post request with "{notificationUri}/terminate" as URI (where the notification URI was previously supplied by the AMF). The request body of termination notification includes:

• the policy association Id encoded as "polAssoId" attribute; and
• the cause as to why PCF requests the termination of the policy association encoded as "cause" attribute

The following figure, illustrates the request for termination of the policy association from PCF.

Figure 4-76 Deletion of Policy Association

Termination of AM/UE Policy Association

For termination of AM/UE Policy associations, PCF invokes Npcf_AMPolicyControl_UpdateNotify and Npcf_UEPolicyControl_UpdateNotify respective service operation towards AMF.

PCF termination notification request toward SMF is made with TerminationNotification data type.

Table 4-79 Definition of Type TerminationNotification

Attribute Name	Data Type	Description
resourceUri	Uri	The resource URI of each AM/UE policy association related to the notification.
cause	PolicyAssociationReleaseCause	The cause for PCF requesting for AM Policy association termination.

The user can set the cause in TerminationNotification. The default cause is set to "UE_SUBSCRIPTION". The user shall be able to customize the termination causes as per need to other 3gpp defined causes. The enumeration PolicyAssociationReleaseCause represents the cause for PCF requests for AM policy association termination.

Table 4-80 Enumeration PolicyAssociationReleaseCause

Enumeration value	Description
UNSPECIFIED	This value is used for unspecified reasons.
UE_SUBSCRIPTION	This value indicates that the policy association needs to be terminated because the subscription of UE has changed such as removal of a subscription.
INSUFFICIENT_RES	This value indicates that the server is overloaded and needs to terminate the policy association.

Policy blockly Release Session with cause holds the PCF cause for termination of AM/UE policy association.

Figure 4-77 Release Sesssion with cause for PCF-AM

Figure 4-78 Release Sesssion with cause for PCF-UE

Termination of SM Policy Association

For termination of SM Policy association, PCF invokes Npcf_SMPolicyControl_UpdateNotify service operation to the SMF. PCF termination notification request toward SMF is made with TerminationNotification data type.

Table 4-81 Definition of Type TerminationNotification

Attribute Name	Data Type	Description
resourceUri	Uri	The resource URI of each SM policy association related to the notification.
cause	SMPolicyAssociationReleaseCause	The cause for PCF requesting for SM Policy association termination.

The user can set the cause in TerminationNotification. The default cause is set to "UNSPECIFIED". The user shall be able to customize the termination causes as per need to other 3gpp defined causes. The enumeration SmPolicyAssociationReleaseCause represents the cause for PCF requests for SM policy association termination.

Table 4-82 Enumeration SMPolicyAssociationReleaseCause

Enumeration value	Description
UNSPECIFIED	This value is used for unspecified reasons.
UE_SUBSCRIPTION	This value indicates that the policy association needs to be terminated because the subscription of UE has changed such as removal of a subscription.
INSUFFICIENT_RES	This value indicates that the server is overloaded and needs to terminate the policy association.
REACTIVATION_REQUESTED	This value indicates that policy association needs to be terminated, since PCF is not able to maintain the existing PDU session and requests for PDU session reactivation.

Policy blockly Release Session with cause holds the PCF cause for termination of SM policy association.

Figure 4-79 Release Sesssion with cause for PCF-SM

AMF/SMF on receiving post request for termination from PCF, either sends a 204 No Content response for the successful processing or an appropriate failure response. After successful processing of PCF request, AMF/SMF invokes Npcf_AMPolicyControl_Delete or Npcf_SMPolicyControl_Delete or Npcf_UEPolicyControl_Delete service operation to terminate the policy associations respectively. Upon receiving the delete request, PCF deletes the Policy association and its associated sessions in UDR. It sends either a 204 No Content response indicating the success of the deletion or an appropriate failure response.

When PCF does not receive the delete request from AMF/SMF, the Policy association is not deleted in Policy and thus its associated resources with the external NFs are not deleted.

When PCF receives an error response from AMF/SMF, it handles the error as defined in "Error Handling" feature.

PCF Decision Not to Terminate AM/SM Policy Association

In case of the PCF decision, to keep the Policy associations and not to terminate it, the default policy is used and data is not fetched from the UDR.

If PCF decides to keep the Policy associations, the default policy is used and not the data from UDR. PCF invokes UpdateNotify service operation toward AMF/SMF to update the AM/SM Policy control information. PCF updates the local database as ampolicydata/smpolicydata. Since the data from UDR is not present for the subscriber, UDR should not have any subscription for this subscriber.

When PCF receives update of a Policy association from the AMF/SMF for this session, it performs UDR query request based on configurations from am-data/sm-data. If UDR sends an error response due to USER_NOT_FOUND, then PCF takes actions according to "Error handling feature for AM/SM Policy" feature.

AM Session Termination Call Flows

Figure 4-80 Call Flow for AM Terminate for UDR updateNotify with delResources

1. AMF sends a UE session established message to AM Policy service.
2. At UDR when a user data is deleted then, UDR sends an updateNotify request to AM service. The updateNotify request includes the delResources property containing the path of the resource that was deleted.
3. AM Policy service forwards the 200 OK message to UDR.
4. AM Policy service sends a Policy evaluation request to PRE to evaluate the details.
5. Depending on the evaluation, PRE includes Release Session action in its response to AM Policy service.
6. In case of termination, AM Policy service sends a terminateNotify request to AMF.
7. AMF sends a 204 No Content response to AM Policy service indicating that the request was successful.
8. AMF triggers a delete session requests and sends AM Policy delete request to AM Policy service.
9. AM Policy service deletes the AMPolicyAssociation from the database and sends an unsubscribe request to CHF.
10. CHF removes the subscription and responds to AM Policy service with 204 No Content message.

Figure 4-81 Call Flow for AM Terminate for CHF updateNotify or TerminateNotify

1. AMF sends an AM session established message to AM Policy service.
2. When the Policy Counters for a subscriber is deleted in CHF, it sends an updateNotify orterminateNotify request to AM Policy service.
3. AM Policy service forwards the 200 OK message to CHF.
4. AM Policy service sends a Policy evaluation request to PRE to evaluate the details.
5. Depending on the evaluation, PRE includes Release Session action in its response to AM Policy service.
6. AM Policy service sends a notifyTerminate request to AMF.
7. AMF sends a 204 No Content response to AM Policy service indicating that the request was successful.
8. AMF triggers a delete session request and sends a AMPolicy delete request to AM Policy service.
9. AM Policy service deletes the AMPolicyAssociation from the database and sends an unsubscribe request to UDR, if subscribed.
10. UDR removes the subscription and responds to AM Policy service with 204 No Content message.

UE Session Termination Call Flows

Figure 4-82 Call Flow for UE Terminate for UDR updateNotify with delResources

1. AMF sends a UE Session established message to UE Policy service.
2. When a user data is deleted in UDR, UDR sends an updateNotify request to UE Policy service. The updateNotify request includes the delResources property, containing the path of the resource that was deleted.
3. UE Policy service sends a Policy evaluation request to PRE to evaluate the details.
4. Depending on the evaluation, PRE includes Release Session action in its response to UE Policy service.
5. UE Policy service sends a notifyTerminate request to AMF.
6. AMF sends a 204 No Content response to UE Policy service indicating that the request was successful.
7. UE Policy service forwards the 204 No Content message to UDR.
8. AMF triggers a delete session request and sends a UEPolicy delete request to UE Policy service.
9. UE Policy service deletes the UEPolicyAssociation from the database and sends an unsubscribe request to CHF, if subscribed.
10. CHF removes the subscription and responds to UE Policy service with 204 No Content message.

Figure 4-83 Call Flow for UE Terminate for CHF updateNotify or updateNotifyTerminate

1. AMF sends a UE Session established message to UE Policy service.
2. When the Policy Counters for a subscriber is deleted in CHF, CHF sends an updateNotify or updateNotify Terminate request to UE Policy service.
3. UE Policy service sends a Policy evaluation request to PRE to evaluate the details.
4. Depending on the evaluation, PRE includes Release Session action in its response to UE Policy service.
5. UE Policy service sends a notifyTerminate request to AMF.
6. AMF sends a 204 No Content response to UE Policy service indicating that the request was successful.
7. UE Policy service forwards the 204 No Content message to CHF.
8. AMF triggers a delete session request and sends a UEPolicy delete request to UE Policy service.
9. UE Policy service deletes the UEPolicyAssociation from the database and sends an unsubscribe request to UDR, if subscribed.
10. UDR removes the subscription and responds to UE Policy service with 204 No Content message.

Support for ReleaseToReactivate in SM Service

The ReleaseToReactivate feature indicates that the PCF can request the SMF for reactivation of a PDU session based on an SM Policy association release cause, REACTIVATION_REQUESTED. This happens with supported features negotiation through the "suppFeat" field. When a session is terminated with REACTIVATION_REQUESTED termination cause, then SMF informs UE and AMF, that the UE should reactivate its PDU session.

To support this feature in PCF during a SM session creation, a configuration ReleaseToReactivate value is added to the Override Supported Features field in PCF-SM service in CNC Console. This configuration can be either enabled or disabled by the operator by considering the following requirements:

• If SMF supports ReleaseToReactivate feature, and ReleaseToReactivate configuration is selected in Override Supported Features in SM configurations, then SM service returns this update as part of suppFeat attribute in its response message towards SMF.
• If SMF supports ReleaseToReactivate feature, and ReleaseToReactivate configuration is not selected in Override Supported Features in SM configurations, then SM service returns suppFeat attribute without any updates in its response message towards SMF. Also, it does not send "REACTIVATION_REQUESTED" in SmPolicyAssociationReleaseCause, instead it sends "UNSPECIFIED" as the termination cause.
• If SMF does not support ReleaseToReactivate feature, and ReleaseToReactivate configuration is selected in Override Supported Features in SM Configuration, then SM service returns suppFeat attribute without any updates in its response message towards SMF.

Policy blockly Release Session with cause holds the PCF causes for termination of SM/AM/UE policy association.

This flow represents the feature negotiation for ReleaseToReactivate only if both SMF and SM support for the feature ReleaseToReactivate.

Figure 4-84 SM and SMF support for ReleaseToReactivate Feature

1. SMF sends POST request for SM Policy creation toward SM service.
2. SM service responds with SmPolicyDecision along with ReleaseToReactivate added to the list of supported features.
3. SMF initiates a reactivate PDU session request toward UE service.
4. SMF initiates a reactivate PDU session request toward AMF.

ReleaseToReactivate in SM Service Call Flows

Figure 4-85 SM Terminate for CHF updateNotify or updateNotifyTerminate:

1. CHF triggers updateNotify/UpdateNotify Termination request toward along with release cause to SM service.
2. On receiving the CHF request, SM service sends request to PRE for Policy evaluation.
3. PRE responds to SM service with 200 OK SM session termination.
4. SM service sends Notify/Terminate request to SMF.
5. SMF responds with 204 No Content message to SM service.
6. SM service sends 204 No Content message to CHF.
7. SMF triggers SMPolicy delete request to SM service.
8. SM service sends 204 No Content toward SMF.
9. SM service initiates SM delete session from the database, sends unsubscribe request to UDR and deregister request to BSF.

Figure 4-86 SM Terminate for UDR updateNotify with (or without) delResources:

1. On user data deletion at UDR, it triggers an updateNotify request toward along with delResource and release cause properties to SM service.
2. On receiving the UDR request, SM service sends request to PRE for Policy evaluation.
3. PRE responds to SM service with 200 OK SM session termination.
4. SM service sends Notify/Terminate request to SMF.
5. SMF responds with 204 No Content message to SM service.
6. SM service sends 204 No Content toward UDR.
7. SMF triggers session delete request to SM service.
8. SM service sends 204 No Content toward SMF.
9. SM service initiates SM delete session from the database, sends unsubscribe request to CHF.

Managing Support of Policy Action to Send the Notify Terminate

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 Blockly

New blocks UDR delResources contains, Release Session with cause and Release session without cause are introduced in AM/UE/SM services. For more information, see Oracle Communications Cloud Native Core, Converged Policy Design Guide.

Observability

Metrics:

The following AM service metrics are used for this feature:

• ocpm_egress_request_total
• ocpm_egress_response_total

The following SM and UE metrics are used for this feature:

• http_in_conn_request
• http_out_conn_response

UDR service uses ocpm_userservice_inbound_count_total metric for this feature.

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.

4.38 Support for UDR Discovery Using Group ID

PCF interfaces with UDR to receive subscriber related data for the UE (uePolicySet) AM (amPolicyData) and SM (smPolicyData) information. On PCF receiving requests from AMF or SMF, it performs UDR discovery using NRF.

With user equipment existing in millions, thousands of UDR discovery requests are sent to NRF. Many UE's subscription data will be associated to a single UDR in form of UDR groups. PCF, by performing UDR discovery using the UDR group id reduces the number of discovery requests to NRF for the same UDR. The UDR Group ID refers to one or more UDR instances managing a specific set of SUPI's.

SMF/AMF makes following PCF GET and initial POST requests with UDR group id oc-policy-udr-group-id-list to receive Policy associations associated with the user or SUPI.

• AMF for AM Policy association, POST ../npcf-am-policy-control/v./policies/ (PolicyAssociationRequest)
• AMF for UE Policy association,POST ../npcf-ue-policy-control/v./policies/ (PolicyAssociationRequest)
• SMF for SM Policy association,POST ../npcf-smpolicycontrol/v./sm-policies (SmPolicyContextData)

Core services (SM/ AM/UE) accepts requests containing oc-policy-udr-group-id-list header from NF consumer and forwards it to PDS. PDS forwards it to UDR connector. Based on the discovery parameters and the NF communication profile configurations received in the request, UDR connector selects query parameters and forms a request toward NRF client for UDR discovery or rediscovery.

For example the request toward NRF:

GET ../nnrf-disc/v./nf-instances?target-nf-type=UDR&requester-nf-type=PCF&group-id-list=<Value from XXX-UDR-Group-Id>&data-set=POLICY

Based on query parameters for UDR discovery or rediscovery and configurations, NRF client supports either non-SUPI or SUPI based caching.

Customizing Header Name Containing udr-group-id-list

PCF receives the service requests with header that contain UDR Group Id associated with the user/SUPI. Default custom header name is oc-policy-udr-group-id-list. The user shall be able to customize the header name as per their requirements at routesConfig in PCF custom_values.yaml file. Adding header for the following routes:

• SMF for SM Policy association - sm_create_session_route
• AMF for UE Policy association - ue_create_session_route
• AMF for AM Policy association - am_create_session_route

An example of default header structure in the custom_values.yaml file:

routesConfig:
    - id: sm_create_session_route
      uri: http://{{ .Release.Name }}-occnp-pcf-sm:{{ .Values.global.servicePorts.pcfSmServiceHttp }}
      path: /npcf-smpolicycontrol/*/sm-policies
      order: 1
      method: POST
      readBodyForLog: true
      filters:
        subLog: true,CREATE,SM
        customReqHeaderEntryFilter:
          headers:
            - methods:
              - POST
              headersList:
                - headerName: 3gpp-Sbi-Message-Priority
                  defaultVal: 24
                  source: incomingReq
                  sourceHeader: 3gpp-Sbi-Message-Priority
                  override: false
                - headerName: oc-policy-udr-group-id-list
                  source: incomingReq
                  sourceHeader: oc-policy-udr-group-id-list
                  override: false

UDR Discovery in Model B and Model C Communications

SMF/AMF sends SM/AM Policy association requests with oc-policy-udr-group-id-list to PCF. And then PCF performs UDR discovery/rediscovery based on oc-policy-udr-group-id-list request header to NRF.

Figure 4-87 UDR Discovery with oc-policy-udr-group-id-list Header to NRF

During the GET and initial POST requests, PCF along with existing query parameters, target-nf-set-id, data-set, preferred-locality, dnn, snssais, guami for a NF communication profile, now will also have the following parameters for UDR discovery.

• group-id-list
• supi

The following table shows the query parameters (supi, group-id-list) that go from UDR connector to NRF Client for UDR discovery.

Table 4-83 Query Parameters

Query Parameters Selected to Sent from UDR Connector to NRF Client	Discovery Parameters Received by UDR Connector from PDS	Query Parameters Sent to NRF Client for UDR Discovery
group-id-list	group-id-list, supi	group-id-list
group-id-list	supi	supi
supi	group-id-list, supi	supi
supi	supi	supi
supi and group-id-list	group-id-list, supi	group-id-list, supi
supi and group-id-list	supi	supi
NF Communication Profile is not configured	supi	supi
NF Communication Profile is not configured	Group-Id-List, SUPI	SUPI

Note:

• UE Policy uses the UDR selected for the UE during AM Policy association. When UDR_RELATED_RESOURCE for amPolicyData and UEPolicySet are enabled, PCF does not perform UDR discovery again during UE Policy association for the UE for which AM Policy association is already established
• UE Policy gets NFProfiles again from NRF if the same UDR that sent amPolicyData during AM Policy association is giving error and when the UDR_RELATED_RESOURCE for amPolicyData and UEPolicySet are enabled.

Call Flows

Figure 4-88 SMF sends SM Policy Association Request with oc-policy-udr-group-id

1. SMF sends SM Create request with oc-policy-udr-group-id-list:"udr1,udr2" to SM service.
2. SM service sends a GET request along with udr group id lists as request parameters to PDS.
3. PDS sends a GET request along with udr group id lists as request parameters to UDR Connector
4. UDR Connector sends a GET request along with udr group id lists as request parameters to NRF Client.
5. NRF Client sends UDR discovery request along with SUPI, GroupId, target-nf-type,requester-nf-type, and service-name request parameters to UDR via NRF.
6. NRF Client sends the UDR profiles to UDR Connector.
7. UDR responds back with smpolicydata to UDR Connector.
8. UDR connector forwards the response to SM service via PDS.
9. With successful creation of SM Policy association, SM service responds back to SMF with SM Create success.

Figure 4-89 AMF sends AM Policy Association Request with oc-policy-udr-group-id

1. AMF sends AM Create request with oc-policy-udr-group-id-list:"udr1,udr2" to AM service.
2. AM service sends a GET request along with udr group id lists as request parameters to PDS.
3. PDS sends a GET request along with udr group id lists as request parameters to UDR Connector
4. UDR Connector sends a GET request along with udr group id lists as request parameters to NRF Client.
5. NRF Client sends UDR discovery request along with SUPI, GroupId, target-nf-type,requester-nf-type, and service-name request parameters to UDR via NRF.
6. NRF Client sends the UDR profiles to UDR Connector.
7. UDR responds back with ampolicydata to UDR Connector.
8. UDR connector forwards the response to AM service via PDS.
9. With successful creation of AM Policy association, AM service responds back to AMF with AM Create success.

Figure 4-90 AMF sends UE Policy Association Request with oc-policy-udr-group-id

1. AMF sends UE Create request with oc-policy-udr-group-id-list:"udr1,udr2" to UE service.
2. UE service sends a GET request along with udr group id lists as request parameters to PDS.
3. PDS sends a GET request along with udr group id lists as request parameters to UDR Connector
4. UDR Connector sends a GET request along with udr group id lists as request parameters to NRF Client.
5. NRF Client sends UDR discovery request along with SUPI, GroupId, target-nf-type,requester-nf-type, and service-name request parameters to UDR via NRF.
6. NRF Client sends the UDR profiles to UDR Connector.
7. UDR responds back with uePolicySet to UDR Connector.
8. UDR connector forwards the response to UE service via PDS.
9. With successful creation of UE Policy association, UE service responds back to AMF with UE Create success.

Policy Features Impacted due to UDR Discovery using Group-id-list

Impact on Non-SUPI based Caching: When non-SUPI based caching is enabled, UDR discovery/rediscovery is done using group-id-list. NRF client cache's the discovered NF profiles along with query parameters. The following table shows if NRF Client cache's the NF profile or not when non-SUPI based caching is enabled:

Table 4-84 NRF Client Caching

NRF Agent Query Parameters Configurations	Query Parameter for UDR Discovery at NRF Client	Caching at NRF Client
group-id-list	group-id-list	True
group-id-list	group-id-list, supi	False
group-id-list	supi	False
Other than group-id-list	group-id-list	False (as query parameters sent to NRF client and configured should be same)

For more information about non-supi based caching, see the Support for Non-SUPI based On-Demand Discovery Caching of NF Profiles section.

Impact on SUPI-based Caching: When SUPI-based caching is enabled, UDR discovery/rediscovery is done using SUPI and (SUPI,Group-Id-List). Enabling the non-SUPI-based caching will not be applicable as the query parameter contains SUPI. For more information, see Support for SUPI based NRF Discovery Optimization and Response Caching from UDR section.

Impact on Session Retry: For GET and initial POST requests, this feature is not impacted and the UDR discovery happens based on query parameters as configured in NF communication profile. For more information, see Support for Session Retry and Alternate Route Service section.

UDR Discovery in Model D Communication

SMF/AMF sends SM/AM Policy association requests with oc-policy-udr-group-id-list to PCF. And then PCF performs UDR discovery using 3gpp-Sbi-Discovery-group-Id-list request header to SCP.

Figure 4-91 UDR Discovery with 3gpp-Sbi-Discovery-group-Id-list Header to SCP

UDR connector compares NF communication profile configurations, NF discovery settings, Model D configurations and discovery parameters received from PDS and accordingly sends the request header to SCP based on the following table:

Table 4-85 Query Parameters

NF Communication Configurations	Values Received by UDR Connector	Header Sent to SCP
udr-group-id-list	udr-group-id-list, supi	3gpp-Sbi-Discovery-group-Id-list
udr-group-id-list	supi	No Header
supi	udr-group-id-list, supi	3gpp-Sbi-Discovery-SUPI
supi	supi	3gpp-Sbi-Discovery-SUPI
udr-group-id-list, supi	udr-group-id-list, supi	3gpp-Sbi-Discovery-group-Id-list, 3gpp-Sbi-Discovery-SUPI
udr-group-Id-list, supi	supi	3gpp-Sbi-Discovery-SUPI

Note:

If configured, the UDR discovery happens for subsequent sessions for the same subscriber based on udr-group-id-list.

Call Flow

Figure 4-92 Model D, AMF sends UE Policy Association Request with oc-policy-udr-group-id-list

1. AMF sends UE Create request with oc-policy-udr-group-id-list:"udr1,udr2" to UE service.
2. UE service sends a GET request along with udr group id lists as request parameters to PDS.
3. PDS sends a GET request along with udr group id lists as request parameters to UDR Connector
4. UDR Connector sends a GET request along with 3gpp-Sbi-Discovery-group-Id-list header to Egress Gateway.
5. Egress Gateways sends a GET request along with 3gpp-Sbi-Discovery-group-Id-list header to SCP.
6. SCP responds with uePolicySet to Egress Gateway.
7. Egress Gateways forwards uePolicySet to UDR Connector.
8. UDR connector forwards the response to UE service via PDS.
9. With successful creation of UE Policy association, UE service responds back to AMF with UE Create success.

Managing Supports UDR Discovery using Group ID

Enable

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

Helm

You can customize the custom headers using headerName and sourceHeader routing parameters for SM/UE/AM service in custom_values.yaml file. For more information about routing configurations, see the "Custom Header Name for UDR Group Id" section in Oracle Communications Cloud Native Core, Converged Policy Installation, Upgrade, and Fault Recovery Guide.

Configure Using CNC Console

The initial discovery parameters for Model B and C Communication profiles now supports the following parameters:

• target-nf-set-id
• supi
• group-id-list

Model D Communication profile supports the following parameters:

• target-nf-set-id
• supi
• data-set
• preferred-locality
• dnn
• snssais
• guami
• group-id-list

For more information about these discovery parameters, see the NF Communication Profiles section in the Common Data group, under Service settings in CNC Console.

The on demand discovery of caching in NRF client supports a new query parmeter group-id-list. For more information, see the NRF Agent section under Service settings in CNC Console.

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.

4.39 Network Policies

Network Policies are an application-centric construct that allows you to specify how a pod communicates with various network entities. It creates pod-level rules to control communication between the cluster's pods and services, and to determine which pods and services can access one another inside a cluster.

Previously, the pods under Policy deployment could be contacted by any other pods in the Kubernetes cluster without any restrictions. Now, Network Policies provide namespace-level isolation, which allows secured communications to and from Policy with rules defined in respective Network Policies. The Network Policies enforce access restrictions for all the applicable data flows except communication from Kubernetes node to pod for invoking container probe. For example, PCF internal microservices cannot be contacted directly by any other pods.

The key purpose of implementing Network Policies is to support principle of zero trust, the concept that no service or network can be trusted, including in house services and networks.

The following table lists the different access policies to be used by Policy traffic flows.

Note:

This list is not exhaustive but tries to represent all the data flows supported by Policy traffic flows.

Microservice	Direction	Client/Server	Port	Access Policy
Configuration Svc	Egress	Database K8s API server for K8s secret	3306, K8s API Server Port	K8s Network Policies
Configuration Svc	Egress	Jaeger Agent	6831	K8s Network Policies
Configuration Svc	Ingress	Console Egress Gateway for configuration Ingress Gateway for configuration Perf-info for configuration App-info for configuration ATS ARS NrfClient	8081	K8s Network Policies
Configuration Svc	Ingress	Prometheus Liveness Readiness	9000	K8s Network Policies
Ingress Gateway	Egress	Jaeger Agent	6831	K8s Network Policies
Ingress Gateway	Egress	Database K8s API Server for K8s Secret	3306, K8s API Server Port	K8s Network Policies
Ingress Gateway	Egress	Coherence	8000, 7	K8s Network Policies
Ingress Gateway	Ingress	Perf Info	8000	K8s Network Policies
Ingress Gateway	Ingress	SBI Peer	80, 443	3GPP-defined Access Policies
Ingress Gateway	Ingress	Coherence	7, 8000, 8095, 8096	K8s Network Policies
Ingress Gateway	Ingress	Prometheus Liveness Readiness	9000	K8s Network Policies
Egress Gateway	Egress	Jaeger Agent	6831	No Access Policy due to SBI Egress*
Egress Gateway	Egress	Database K8s API Server for K8s Secret	3306	No Access Policy due to SBI Egress*
Egress Gateway	Egress	Coherence	7, 8000	No Access Policy due to SBI Egress*
Egress Gateway	Egress	SBI Peer	Decided at run-time	3GPP-defined Access Policies
Egress Gateway	Egress	ARS	ARS Port	K8s Network Policies
Egress Gateway	Ingress	Egress Gateway for coherence	7, 8000	K8s Network Policies
Egress Gateway	Ingress	Prometheus Liveness Readiness	9000	K8s Network Policies
Egress Gateway	Ingress	Coherence	7, 8000	K8s Network Policies
Audit	Ingress	Prometheus Liveness Readiness	9000	K8s Network Policies
Audit	Egress	Database K8s API Server for K8s Secret	3306, K8s API Server Port	K8s Network Policies
App Info	Ingress	Registration Subscription Auditor	8000	K8s Network Policies
App Info	Ingress	Prometheus Liveness Readiness	9000	K8s Network Policies
App Info	Egress	DB monitoring port	8080	K8s Network Policies
diam-gateway	Egress	Jaeger Agent	6831	K8s Network Policies
diam-gateway	Ingress	Prometheus Liveness Readiness	9000	K8s Network Policies
diam-gateway	Egress	Database K8s API Server for K8s Secret	3306, K8s API Server Port	K8s Network Policies
diam-gateway	Ingress	Peer	3868	K8s Network Policies
Query-Svc	Ingress	Prometheus Liveness Readiness	9000	K8s Network Policies
Query-Svc	Egress	Jaeger Agent	6831	K8s Network Policies
User svc	Ingress	Prometheus Liveness Readiness	9000	K8s Network Policies
User svc	Ingress	Monitoring	8000, 9443	K8s Network Policies
User svc	Egress	Jaeger	6831	K8s Network Policies
Policy DS	Ingress	Prometheus Liveness Readiness	9000	K8s Network Policies
Policy DS	Ingress	Monitoring	8000, 9443	K8s Network Policies
Policy DS	Egress	Database K8s API Server for K8s Secret	3306, K8s API Server Port	K8s Network Policies
Policy DS	Egress	Jaeger	6831	K8s Network Policies
Notifier	Ingress	Prometheus Liveness Readiness	9000	K8s Network Policies
Notifier	Egress	Jaeger	6831	K8s Network Policies
Notifier	Egress	Signaling	8080	K8s Network Policies
Nwdaf-agent	Ingress	Prometheus Liveness Readiness	9000	K8s Network Policies
Nwdaf-agent	Egress	Database K8s API Server for K8s Secret	3306, K8s API Server Port	K8s Network Policies
Nwdaf-agent	Egress	Jaeger	6831	K8s Network Policies
Bulwark	Ingress	Prometheus Liveness Readiness	9000	K8s Network Policies
Bulwark	Egress	Signaling	8080	K8s Network Policies
Bulwark	Egress	Jaeger	6831	K8s Network Policies
Performance	Ingress	Prometheus Liveness Readiness	9000	K8s Network Policies
Performance	Egress	Signaling	8080	K8s Network Policies
alternate route svc	Ingress	Coherence	7, 8000, 8095, 8096	K8s Network Policies
alternate route svc	Ingress	Prometheus Liveness Readiness	9000	K8s Network Policies
soap-connector	Egress	Signaling	8000, 8443	K8s Network Policies
soap-connector	Egress	Jaeger Agent	6831	K8s Network Policies
soap-connector	Ingress	Prometheus Liveness Readiness	9000	K8s Network Policies
soap-connector	Ingress	Monitoring	9000	K8s Network Policies
usage-mon	Egress	Jaeger Agent	6831	K8s Network Policies
usage-mon	Egress	Database K8s API Server for K8s Secret	3306	K8s Network Policies
usage-mon	Egress	Signaling	8000	K8s Network Policies
usage-mon	Ingress	Prometheus Liveness Readiness	9000	K8s Network Policies
ldap-gateway	Egress	Jaeger Agent	6831	K8s Network Policies
ldap-gateway	Egress	Signaling	8000, 8443	K8s Network Policies
ldap-gateway	Ingress	Prometheus Liveness Readiness	9000	K8s Network Policies
diam-connector	Egress	Signaling	8000	K8s Network Policies
diam-connector	Ingress	Diameter	3868	K8s Network Policies
diam-connector	Ingress	Monitoring	9000	K8s Network Policies
diam-connector	Ingress	Prometheus Liveness Readiness	9000	K8s Network Policies
Biding	Egress	Signaling	8000, 9443	K8s Network Policies
Biding	Egress	Jaeger Agent	6831	K8s Network Policies
Biding	Egress	Database K8s API Server for K8s Secret	3306, K8s API Server Port	K8s Network Policies
Biding	Ingress	Monitoring	9000	K8s Network Policies
Biding	Ingress	Prometheus Liveness Readiness	9000	K8s Network Policies
pcrf-core	Egress	Signaling	8000, 9443	K8s Network Policies
pcrf-core	Egress	Jaeger Agent	6831	K8s Network Policies
pcrf-core	Ingress	Diameter	3868	K8s Network Policies
pcrf-core	Ingress	Monitoring	9000	K8s Network Policies
pcrf-core	Ingress	Prometheus Liveness Readiness	9000	K8s Network Policies
SM Service	Egress	Jaeger Agent	6831	K8s Network Policies
SM Service	Egress	Signaling	8000, 9443	K8s Network Policies
SM Service	Egress	Database K8s API Server for K8s Secret	3306, K8s API Server Port	K8s Network Policies
SM Service	Ingress	Prometheus Liveness Readiness	9000	K8s Network Policies
SM Service	Ingress	Monitoring	9000	K8s Network Policies
AM Service	Egress	Jaeger Agent	6831	K8s Network Policies
AM Service	Egress	Database K8s API Server for K8s Secret	3306, K8s API Server Port	K8s Network Policies
AM Service	Egress	Signaling	8000, 9443	K8s Network Policies
AM Service	Ingress	Prometheus Liveness Readiness	9000	K8s Network Policies
AM Service	Ingress	Monitoring	9000	K8s Network Policies
UE Service	Egress	Jaeger Agent	6831	K8s Network Policies
UE Service	Egress	Database K8s API Server for K8s Secret	3306, K8s API Server Port	K8s Network Policies
UE Service	Egress	Signaling	8000, 9443	K8s Network Policies
UE Service	Ingress	Prometheus Liveness Readiness	9000	K8s Network Policies
UE Service	Ingress	Monitoring	9000	K8s Network Policies
PRE	Egress	Jaeger Agent	6831	K8s Network Policies
PRE	Egress	Signaling	8000	K8s Network Policies
PRE	Ingress	Prometheus Liveness Readiness	9000	K8s Network Policies
PRE	Ingress	Monitoring	9000	K8s Network Policies
nrf-client	Egress	Jaeger Agent	6831	K8s Network Policies
nrf-client	Egress	Performance Platform	8000
nrf-client	Egress	Cache Service	8095, 8096
nrf-client	Egress	Database K8s API Server for K8s Secret	3306, K8s API Server Port	K8s Network Policies
nrf-client	Ingress	Prometheus Liveness Readiness	9000	K8s Network Policies

As an assumption when deploying Policy, the following labels are set by default:

Table 4-86 Default Labels

Pod	Label
<name_of_the_pod>	np Note: This label is only used as long as NRF pods do not use the label app.kubernetes.io/part-of with occnp value.
<name_of_each_service>	app.kubernetes.io/name:

np is custom global label that must be added as follows:

1. Open occnp-custom-values.yaml file.
2. Add the label under customExtention-allResources-labels section.
   For example:

   customExtension:
      # The `factoryLabelTemplates` and `factoryAnnotationTemplates` can
      # accept templates rather than plain text.
      factoryLabelTemplates: {}
      factoryAnnotationTemplates: {}
      allResources:
        labels: {
          "np": "cnpolicy"
        }

3. Run the following Helm upgrade command.

   helm upgrade <helm_name> <build_file.tgz> -f <custom_values.yaml> --namespace
       <namespace>

   When the upgrade is complete, the new tag must be observed on all pods.

PCF Security Policies:

• deny-ingress-all: To block all ingress traffic of pods present in a PCF deployment.

• allow-ingress-network-sbi: To allow traffic on the Ingress Gateway Pods on container ports 8000 and 9443 to allow sbi traffic.

• allow-ingress-diameter-traffic: To allow Ingress traffic for diameter gateway, diameter connnector, and PCRF Core on port 3868.

• allow-ingress-local-prometheus: To allow Ingress traffic for all services on port 9000.

• allow-ingress-local-policy-flow: To allow Ingress traffic between pods inside PCF.

• allow-ingress-network-gui: To allow ingress traffic on port 8000 for CM Service to access CNC Console.

• deny-egress-all: To block all egress traffic for all the pods.

• allow-egress-network-all-gws: To allow Egress traffic on all ports for these pods [occnp-egress-gateway, diam-gateway, ldap-gateway, occnp-alternate-route].

• allow-egress-network-pre: To allow Egress traffic on all ports for PRE (only use this when PER is enabled).

• allow-egress-local-database: To allow Egress traffic on ports 3306 & 8080 for connection with database.

• allow-egress-local-k8sapi: To allow Egress traffic on port 6443.

• allow-egress-local-jaeger: To allow Egress traffic on port 6831.

• allow-egress-local-dns: To allow Egress traffic on port 53.

• allow-egress-local-flow: To allow Egress traffic between pods inside PCF.

Note:

The default Network Policies to be applied for Policy are the recommended even though they are not very granular but they keep operational overhead to the minimum and still achieve access control security.

Managing Network Policies

Enable

To use this feature, Network Policies need to be applied to the namespace wherein Policy is applied.

Configure

You can configure this feature using Helm. For information about configuring network policy for Policy deployment, see Configuring Network Policy section in Oracle Communications Cloud Native Core, Converged Policy Installation, Upgrade, and Fault Recovery Guide.

Observe

There are no specific metrics and alerts required for the Network Policies feature.

4.40 Support for SUPI based NRF Discovery Optimization and Response Caching from UDR

This feature helps in optimizing SUPI based NRF discoveries between the query and subscription (GET and POST) of the policy data request towards UDR.

PCF discovers the NF Profiles from NRF along with the query parameters used in discovery request, which are discovered on demand based on SUPI. SUPI based NRF discovery result for UDR GET request is cached till the POST request is completed. The on demand discovery based on SUPI is currently supported only for UDR discovery. The cache for the discovered UDR profiles expires even if the UDR POST result is success or fail.

The following diagram shows the SUPI based NRF discovery result for UDR GET request is cached till the POST request is completed.

Figure 4-93 UDR GET Discovery Result Reused in UDR POST

1. PCF sends SUPI based NRF discovery request to NRF.
2. NRF discovers the NF profile using SUPI.
3. PCF sends UDR GET request to UDR1.
4. UDR1 sends response message to PCF.
5. PCF sends UDR POST request to UDR1.
6. UDR 1 responds with an error.
7. PCF does SUPI based NRF discovery if the POST is initial.
8. NRF provides the corresponding discovery result.
9. PCF sends UDR POST to UDR2.
10. UDR2 responds with success or error. If it is successful, cache data is cleared. If it fails and there are no futher retry attempts, then POST fails and cache data is cleared.

Instead of doing discovery for amPolicyData and uePolicySet separately, the UDR information used in fetching amPolicyData can be reused in fetching uePolicySet and vice versa. PCF can rediscover the NF profiles for UDR based on the query parameter SUPI, from NRF during POST, if POST fails and uses the discovered profiles from the cache that was cached during GET.

The following diagram shows the reuse of UDR profile for amPolicyData GET in uePolicySet GET.

Figure 4-94 Reuse of UDR profile for amPolicyData GET in uePolicySet GET

1. For AM-Create request, PCF sends SUPI based NRF discovery request to NRF.
2. NRF discovers the NF profile using SUPI.
3. PCF sends UDR GET request to UDR1.
4. UDR1 sends response message to PCF.
5. For UE-Create request, PCF sends the GET to same UDR where GET for AM was sent.
6. UDR1 sends corresponding response message to PCF.

Managing the Feature

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

Enable and Configure

By default, this feature is disabled. You can enable using CNC Console by configuring the following advanced settings:

• Set value of the following keys under the Advanced Settings section on the PDS Settings page:
  • UDR_FETCH_RELATED_RESOURCE
  • UPDATE_SSV_DATASOURCE_INFO_ON_CHANGE

  For information about how to configure for in CNC Console, see PDS Settings.

• Set value of the following keys under the Advanced Settings section on the PCF User Connector page:
  • UDR_NF_PROFILE_COOKIE_ENABLED
  • UDR_NF_PROFILE_COOKIE_COMPRESS
  • UDR_NF_PROFILE_COOKIE_LIMIT
  • UDR_GET_USE_RELATED_RESOURCE

  For information about how to configure for in CNC Console, see PCF User Connector.

Observe

The following metrics have been added for this feature:

• Policy DS Metrics
  • occnp_nf_cookie_forwarded_total
  • occnp_nf_cookie_recieved_total

  For more information, see Policy DS Metrics.

• User Service Metrics
  • occnp_udr_nf_cookie_enabled_total
  • occnp_udr_use_related_resource

  For more information, see User Service Metrics .

4.41 RAA Error Code Handling

RAA error code handling helps in error handling at SM and PA services. The operator should be able to take corrective actions on the receipt of error response from Diameter Connector for initiated update-notify or RAR message.

The operator can configure the corrective action on the error handling configuration page for PA service. Based on this configuration, the PA service receives the error response from Diameter Connector. The Diameter Connector forwards the received diameter error result code in the error header of the response.

Following are the actions that PA service can use:

• Terminate the transaction: To terminate the transaction or call.

  Note:

  If error handling configuration is not done, the default behavior is to terminate the transaction.
• Cleanup session: To delete the corresponding Rx session locally. The PA service initiates the delete request internally that causes the corresponding PCC rule to be removed by SM service by sending Update_Notify request to SMF and also send dependentContextBinding delete request. In this case, no more ASR or STR messages get exchanged.

  Note:

  In case of 5002 DIAMETER_UNKNOWN_SESSION_ID, the default behavior is to cleanup the session. The 'Terminate the transaction' action should be configured only in case of an explicit requirement.

Note:

There is no retry action of update notify http request (RAR) by error handling library at SM/PA service and all the attempts for retry for RAR must be performed as part of diameter session retry at Diameter Gateway.

Managing RAA Error Code Handling

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

Enable

To enable RAA error handling, set the value of SYSTEM.PA_ERROR_HANDLER_ENABLED key to true in the Advanced Settings of PA service. For more information, see PCF Policy Authorization.

Configure

Once the service is enabled, you can configure the RAA error handling functionality under Error Handling on CNC Console for Policy. For information about how to configure for in CNC Console, see Error Handling.

Observe

The following metrics have been added in PCF Session Management service for this feature:

• error_handler_exec_total
• error_handler_in_total
• error_handler_out_total

For more information, see SM Service Metrics.

4.42 IPv6 Support in Converged Policy Mode

CNC Policy and its microservices can be deployed in a K8s Kubernetes environment that supports the IPv6 addressing. It supports the complete range of IPv6 prefixes as defined in the 3GPP TS 29.571 and 3GPP TS 29.510 specifications.

Note:

CNC Policy supports either IPv6 or IPv4 protocol for communication.

The protocol configurations can be performed during deployment using the Custom Values YAML file for CNC Policy. For more information about the confgurations, see Oracle Communications Cloud Native Core, Converged Policy Installation, Upgrade and Fault Recovery Guide.

External Communications

With the support for IPv6 protocol, CNC Policy allows communication with external NFs over the following interfaces:

• The DNS (Domain Name System) for the resolution of FQDNs
• The SBI interface over the HTTP/2 and HTTPS protocols for the following types of connections:
  • Consumer Connections
  • Producer Connections
• Diameter interface for the following types of connections:
  • Connection as a server. For example, connection with PGW
  • Connection as a client. For example, connection to OCS over Sy
• Service IP endpoints
• Provisioning interface for connection with Cloud Native Core Console (CNCC)
• CNC Policy Rest API interface for the REST API Client configurations over IPv6

Internal Communications

CnPolicy supports all the internal communication over IPv6 addresses for PCF, PCRF, and Converged Policy modes.

The internal communications include:

• Inter microservice communication
• Communication with CnDbTier
• Communication with IGW, EGW
• Communication with Diameter Gateway and Diameter connector
• DNS for FQDN resolution
• Integration with common services using IPv6 addressing for observability - logging, monitoring and tracing
• Communication with platform components supporting retrieval of certificates/public/private keys

Managing IPv6 Support in Converged Policy Mode

Deploy and Configure

To deploy Policy in the IPv6 environment:

1. The cnDBTier must have IPv6 enabled. For information about installing cnDBTier, see "Installing cnDBTier" in Oracle Communications cnDBTier Installation Guide.
2. Deploy Policy over the IPv6 supported cnDBTier site. For information about installing and deploying Policy, see Oracle Communications Converged Policy Installation and Upgrade Guide.

You need to configure the IPv6 support during installation using the Custom Values YAML file for CNC Policy. The following parameters must be updated in the custom values file for CNC Policy:

Table 4-87 IPv6 Parameters

Parameter	Description
ingress-gateway.isIpv6Enabled	Set the value to true for this parameter when Policy is deployed in IPv6 cluster.
egress-gateway.isIpv6Enabled	Set the value to true for this parameter when Policy is deployed in IPv6 cluster.
alternate-route.isIpv6Enabled	Set the value to true for this parameter when Policy is deployed in IPv6 cluster.
diam-gateway.envSupportedIpAddressType	Set the value to IPV6 for this parameter when Policy is deployed in IPv6 cluster.
global.isIpvSixSetup	Set the value to "true" if you are going to require HTTP communication over IPv6.

For more information about configuring the parameter value, see "Customizing CNC Policy" in Oracle Communications Converged Policy Installation and Upgrade Guide.

4.43 Handling Rx Stale Sessions

Policy Control Function (PCF) supports auditing the Rx session periodically to detect and remove stale sessions. This helps to avoid unlimited system memory utilization growth.

An Rx session is considered as stale when an association exists in PCF, but is not used by Proxy Call Session Control Function (P-CSCF) or Application Function (AF) for a specific time period. The time period after which the session is considered as stale is configurable.

PCF detects an Rx stale session based on:

• Configured Time To Live (TTL)
• Authorization Lifetime using:
  • Support of Rx Subscription Expiry
  • Authorization Lifetime Attribute Value Pair (AVP)

TTL is the time period for which an Rx session can be active. When the TTL of an Rx session reaches its maximum as configured by the user, the Rx session will be considered as stale.

Authorization Lifetime is the maximum lifetime of an Rx session. When the life time of a session reaches its Authorization Life Time, the session is considered as stale and is cleaned up.

Note:

Currently, the value of Authorization Lifetime is just echoed back and it is expected to be the same value as configured in TTL under Audit settings in Policy Authorization service (PA service).

The P-CSCF provides Authorization Lifetime AVP and the Support of Rx Subscription Expiry feature bit for the Supported-Feature AVP in Rx Authorization Authentication Request Initial (AAR-I).

PCF echoes back the value in Authorization Lifetime AVP in Authorization Authentication Answer (AAA) response to P-CSCF along with the Support of Rx Subscription Expiry feature bit in the Supported-Feature AVP.

The P-CSCF sends Authorization Authentication Request Update (AAR-U) according to the Authorization Lifetime AVP.

PCF updates the last access timestamp of the Rx session when it receives AAR-U from P-CSCF.

PCF sends abort session request to P-CSCF and removes the stale Rx Session locally along with the related PCC rules in SMF, upon detection.

Detection and removal of stale Rx session generates appropriate alert and log entries.

Call Flow

Figure 4-95 Rx Stale Session Detection and Deletion Based on TTL and Authorization-Lifetime

1. If the Enable Audit field is enabled under Audit group in PCF Policy Authorization page for Service Configurations, SM service registers with Audit service for monitoring Rx sessions.
2. SM service receives AAR-I message from P-CSCF with Support of Rx Subscription Expiry feature bit for the Supported-Feature AVP.
3. If the Enable Authorization Lifetime field is enabled under System group in PCF Policy Authorization page for Service Configurations, and the AAR-I message includes Authorization-Lifetime AVP, SM service sends Authorization-Lifetime to P-CSCF in Rx AAA messages. It returns the same value of Authorization-Lifetime AVP to P-CSCF, as the value received from P-CSCF.
4. SM service registers with the Audit service for monitoring the Rx session.
5. Audit service analyzes the EXPIRY_TIMESTAMP and compares it with TTL value. If necessary, it sends a message to SM service as mentioned in the next step.
6. If AAR-U for an Rx session is not received and its TTL expires, Audit service sends a message to SM service with Max TTL Expired = true.
7. SM service sends an Abort Session Request (ASR) to P-CSCF for that Rx session.
8. P-CSCF sends a successful Abort Session Answer (ASA) response to SM service.
9. P-CSCF also sends a STR to SM service.
10. SM service responds to P-CSCF with STA message.

Figure 4-96 Rx session cleanup when Audit service detects a stale session

If Enable Audit field is enabled, SM service registers with Audit service for auditing Rx sessions. Depending on the value of EXPIRY_TIMESTAMP field in AppSession database, the Audit service considers that the Max TTL of an Rx session has expired. SM service updates EXPIRY_TIMESTAMP after every successful AAR-I and AAR-U messages. In case of georedundancy, the Audit service uses SITEID field in AppSession database to filter and handle the Rx sessions for multiple sites.

1. When Audit service detects that some of the Rx sessions expired and for any reason these Rx sessions are not deleted after TTL expiry, Audit service sends the list of such Rx sessions to PA service for which the Max TTL has expired.
2. For all the Rx sessions in the list, PA service sends PDU Session Termination request to SM service.
3. SM service sends ASR to P-CSCF and waits for a configured time period to receive a successful Abort Session Answer (ASA) response from P-CSCF.
   • When sending ASR, if SM service receives any response that is not success (except for timeout), it cleans up the session.

     • If ASA times out, SM service checks if AppSession exists for these sessions in Audit service. SM service deletes the Rx Session and the associated resources internally. Also, it deletes the associated PCC Rules from SMF externally, by sending Update Notification to SMF.
     • If SM service receives ASA with error code other than 5002 (for reasons like the ASR request did not go out of PCF), then the Audit service does not delete the AppSession for such sessions. Depending on the configuration, SM service resends the ASR to P-CSCF. If all the retries fail with timeout or any other error, SM service deletes the Rx Session and associated resources internally. Also, it deletes the associated PCC Rules from SMF externally, by sending Update Notification to SMF.
   • If SM service receives a successful ASA from P-CSCF, it waits for receiving a STR from P-CSCF.

4. PCF uses AF_MAX_WAIT_DURATION_FOR_STR timer to receive the STR from P-CSCF.

   If AF_MAX_WAIT_DURATION_FOR_STR timer expires and SM service does not receive STR from P-CSCF, SM service checks if AppSession exists for these sessions. SM service deletes the Rx Session and the associated resources internally. Also, it deletes the associated PCC Rules from SMF externally, by sending Update Notification to SMF.

5. If SM service receives a successful STR from P-CSCF, SM service checks if AppSession exists for these sessions. SM service cleans up these Rx sessions and the associated resources externally and internally. Also, it deletes the associated PCC Rules from SMF externally, by sending Update Notification to SMF.
6. SM service responds to P-CSCF with STA.

• When there are bulk of stale Rx records detected, in order to avoid performance impact on the system, Policy allows to configure:
  • the rate at which ASR is sent to P-CSCF.
  • the rate at which the records are deleted.

Managing Handling Rx Stale Sessions

Enable

By default, this feature is disabled. You can enable stale Rx session audit and deletion using CNC Console or REST API for Policy.

Enable using CNC Console:

To enable the Rx Stale Session detection based on TTL and Authorization-Lifetime:

• To enable auditing by Audit service, configure:
  • Enable Audit parameter to true under Audit group in PCF Policy Authorization page for Service Configurations.
  • Configure App Session Age (in minutes) parameter under Audit group in PCF Policy Authorization page for Service Configurations.
• To enable detection and deletion of stale sessions based on Authorization Lifetime, enable Enable Authorization Lifetime parameter under Systems group in PCF Policy Authorization page for Service Configurations.

For more information about enabling the feature through CNC Console, see PCF Policy Authorization.

Enable using REST API

To enable the feature, set the value of enable parameter to true in Audit group in Policy Authorization Service API.

For more information about enabling the feature through REST API, see Policy Authorization Service in Oracle Communications Cloud Native Core, Converged Policy REST Specification Guide.

Configure

You can configure this feature using the CNC Console or REST API for Policy.

Configure using CNC Console: Perform the feature configurations under Audit group in PCF Policy Authorization page for Service Configurations. For more information, see PCF Policy Authorization.

Configure using REST API: Configure the parameters under Audit group in Policy Authorization Service API. For more information about configuring the feature through REST API, see Policy Authorization Service in Oracle Communications Cloud Native Core, Converged Policy REST Specification Guide.

Note:

• On upgrade, SITEID and EXPIRY_TIMESTAMP contains null values in all AppSession records until there is an update on the AppSession.
• As SITEID and EXPIRY_TIMESTAMP contains null values, the default value of Handle NULL As Stale parameter is set to false. You must enable this setting after the desired TTL has passed after site upgrade. This will cleanup all AppSessions for which SITEID and EXPIRY_TIMESTAMP contains null value. That is, they did not receive an update for the duration after upgrade and now these sessions are considered as stale.

Observability

Metrics

The following SM service metrics are used to differentiate between SM and PA deletions:

• audit_delete_records_max_ttl_count
• audit_notifications_sent
• audit_delete_records_count
• audit_terminate_notify

For more details on these metrics, see SM Service Metrics.

4.44 Data Compression

Data compression can be used to reduce the data size and hence the storage used by database. It can also be used to improve the communication latency between application and DB when compression is performed at the application level.

Following are the available options for data compression schemes:

• MySQL_Compressed: Compression and decompression performed at MySql level
• Zlib_Compressed: Compression and decompression performed at application level

Binding and PDS services support this feature only with Zlib_Compressed scheme. PCRF-core and SM service supports this feature only with MySQL_Compressed scheme.

Managing the Feature

Enable

This feature is disabled by default. It can be enabled by choosing the compression scheme from respective service configuration. For more information, see the details of the Data Compression Scheme field in PDS, Binding Service, and PCF Session Management in the Configuring Policy Using CNC Console section.

Configure

You can configure this feature using Helm for PCF Session Management and CNC Console for PCF Session Management, PDS, and Binding service as follows:

• Helm: Set the value of the parameter smDataCompressionScheme and paDataCompressionScheme to 0, 1, or 2 during install or upgrade. For more information, see the Oracle Communications Cloud Native Core, Converged Policy Installation, Upgrade, and Fault Recovery Guide.
• CNC Console: You can configure this feature using the Data Compression Scheme field in PDS, Binding Servie, and PCF Session Management in the Configuring Policy Using CNC Console section.

Observe

The following metric has been added in PCF Session Management service for this feature:

• occnp_db_overall_processing_time

For more information, see SM Service Metrics.

4.45 Usage Monitoring on Gx Interface

Cloud Native 4G Policy implements Usage Monitoring or Quota Management using the combination of PCRF Core and Usage Monitoring. These two microservices have their respective policy engines and thus separate policy projects. Each of the two microservices (along with their respective policies) has the following functions with respect to Quota Management:

• PCRF Core - Controls PCC and/or Session Rules, and Charging Description.
• Usage Monitoring - Controls the Quota Selection, Accumulation and Grant.

For details on PCRF Core, see PCRF Core Service

For details on Usage Monitoring Service, see Usage Monitoring Service

To achieve end to end use cases of 4G quota, the policies must be split into these two microservice functions.

The configuration of Quota plans can be done at two places:

• CNC Policy - Quota plans that are not per subscriber can be configured directly on CNC Policy and used in Policy Configuration. Fore more details, see Usage Monitoring Service.
• UDR - Quota plans that need to be assigned per subscriber can be provisioned on the UDR.

  For details on UDR Quota plans, see Converged Quota Support section in Oracle Communications Cloud Native Core, Unified Data Repository User Guide.

Note:

Quota plans when configured in CNC Policy will avoid duplication of the plan data in UDR for every subscriber.

Quota Management for a Subscriber

Usage Monitoring supports different quota plans for a subscriber such as Basic, Dynamic, Daily, Roaming, Monthly quota based on volume of usage.

Basic Quota

Basic quota specifies restrictions on the amount of data volume, active session time, or service-specific events that a subscriber can consume.

A single quota can express limits on any combination of volume, time, or events. A Basic quota is also referred as a plan. For example, Domestic/Home/ Roaming plan.

Plan

A plan describes a subscriber's basic, recurring service. A plan can be a basic plan, or a pass or a top-up.

The quota plan for a subscriber is provisioned at UDR. For details on provisioning quota and dynamic quota for a subscriber, see Convered Quota Support section in Oracle Communications Cloud Native Core, Unified Data Repository User Guide.

Plans include policy characteristics such as time and volume limits. These characteristics can be computed automatically or through policy rules. Policy actions grant plans, based on a subscriber's tier provisioned on CnUDR.

The following fields under Usage Monitoring page for Service configurations can be used to configure the time and volume limits for a plan:

• Minimum Volume Grant (bytes): Minimum grant value (in bytes) that can be approved for volume based usage monitoring.
• Maximum Volume Grant (bytes): Maximum grant value (in bytes) that can be approved for volume based usage monitoring.
• Minimum Time Grant (seconds): Minimum grant value (in seconds) that can be approved for time based usage monitoring.
• Maximum Time Grant (seconds): Maximum grant value (in seconds) that can be approved for time based usage

  monitoring.

The default volume and time grants for the plan can be configured using the fields available under Default Volume Grant and Default Time Grant sections in Usage Monitoring page.

A plan can have associated quota controls, which in turn can be subject to modification or over-ride through Passes, Top-ups, and Roll-overs.

Reset frequency can be:

• Hourly
• Daily
• Weekly
• Monthly
• Yearly
• Never

Postpaid monthly data plans are monthly recurring data plans that have defined volume/time thresholds associated. Users are notified about the user’s current usage at various levels. On reaching the threshold, the user’s access is subjected to suspension of service or reduced quality of service.

The default usage levels can be configured using the following fields under Default Usage Levels section in Usage Monitoring page for Services Configuration in CNC Console:

• Minor Usage Level (%): Threshold value in percentage indicating minor usage.
• Major Usage Level (%): Threshold value in percentage indicating major usage.
• Critical Usage Level (%): Threshold value in percentage indicating critical usage.
• Exhausted Usage Level (%): Threshold value in percentage indicating usage level has exhausted allowed limit.

Dynamic Quota

Dynamic quotas are one-time changes to a subscriber’s service.

There are two types of dynamic quotas:

• Passes
• Top-ups.

Passes

Passes allow the service providers to grant resources outside of a subscriber’s normal/default plan.

A pass is a one-time override quota that a subscriber can purchase that temporarily replaces or adds to a subscriber's default plan.

It allows users to access data till a predefined quota (either volume, time or event based) for a specific validity period.

For short time users, there can be different types of data passes:

• Hourly
• Daily
• Weekly
• Monthly
• Yearly
• Never

A subscriber can have multiple passes. An active Pass can modify the QoS controls, charging parameters, or other configurable rules associated with a subscriber’s service.

A Pass may:

• be valid for a restricted interval
• start when provisioned, or at a specific time, or upon occurrence of a triggering event within its validity interval
• end at a specific time, or after given duration once activated, or upon a particular event
• apply continuously, or only during certain time periods, or only under certain conditions (e.g. when roaming)
• apply to the subscriber’s overall usage, or be more limited (e.g. applying only to specific applications, flows, traffic types, or pre-defined rules)

Passes are common options for pre-paid subscribers, who frequently have limited or no data access via their basic plan, and may purchase Passes to gain access to such services. They can also be used to allow Casual Use plans for pre- or post-paid subscribers to purchase services on an occasional basis which they would not otherwise subscribe for on an ongoing basis.

Users are notified about the user’s current usage at various levels. On reaching the threshold, the user’s access is subjected to suspension of service or reduced quality of service.

Pass configuration options can be modified. The dynamic PCC rules are updated based on the changes on the Pass Configuration.

Upon deletion of a pass, the pass is exhausted immediately.

Top-up

A Top-up allows to extend access to services beyond the time or volume limits typically enforced by a plan. A top-up is processed if the default plan is exhausted, or the quota is expired. There can be multiple Top-ups for a subscriber based on time or volume.

Note:

Passes cannot not have Top-ups.

Top-up configuration options can be modified. The dynamic PCC rules are updated based on the changes on the Top-up configuration.

Upon deletion of a Top-up, the Top-up is exhausted immediately.

The quota plan for a subscriber is provisioned at UDR. For details on provisioning quota and dynamic quota for a subscriber, see Convered Quota Support section in Oracle Communications Cloud Native Core, Unified Data Repository User Guide.

Quota details are configured at UDR based on ueID using the REST API: {apiRoot}/nudr-dr-prov/v1/policy-data/{ueId}. For more details on how to add the quota information, see Provisioning Operations for PCF Data section in Oracle Communications Cloud Native Core, Unified Data Repository REST Specification Guide.

Whenever there is a change in the subscriber quota information, UDR notifies Policy through updateNotify message.

The order/priority of basic plan, pass or top-ups can be specified using Selection Order 1, Selection Order 2, and Selection Order 3 fields under Data Limit Selection section in Usage Monitoring page for Service configurations in CNC Console for Policy. For more information, see Usage Monitoring Service.

Exhaustion (Quota)

Exhaustion occurs when reports indicate that usage of a metered unit has equalled or exceeded the specified quota limit. If a recurring quota is exhausted, typically the subscriber’s sessions are subjected to more restrictive policies until the end of the plan period or billing cycle.

Expiration (Quota)

Expiration occurs when a periodic plan reaches the end of the plan period or billing cycle, or when a one-time pass or top-up reaches its established End Time or close to the validity period.

Note:

The time-based expiration of a Quota is quite different from the exhaustion of a Quota restricting the active session Time of a subscriber’s usage.

A plan (periodic quota) is typically reset at expiration.

Rollover

A rollover allows a subscriber to carry forward unused units from one billing cycle to another.

For example, if a subscriber is allowed 10 GB of data a month and only uses 9 GB, the remaining 1 GB of data can be saved for use in the next month.

Rollover units can accumulate and can be carried across multiple months.

Data units are rolled over based on multiple conditions such as:

• Rollover unused data when it is more than a minimum threshold.
• Total data (base data + rollover data) may not exceed a maximum cap.
• Rollover certain percentage of unused data.
• Data may be rolled over for a fixed number of billing cycles.

When data is rolled over without any restriction, the leftover volume/time can be added to the base volume/time in the next billing cycle.

When data is rolled over with restrictions on duration of usage (for example, a maximum number of rollover periods/cycles), it needs to be tracked as separate rollover definitions (data limits).

The data rollover for a plan can be enabled using Data Rollover field under Usage Monitoring page for Service Configurations.

The data rollover can be configured based on a particular profile. The rollover profiles can be created by configuring the fields in Data Rollover Profiles page under Usage Monitoring in Policy Data Configurations.

You can create multiple profiles and specify profile to be used for the plan using Data Rollover Profile field under Usage Monitoring page for Service Configurations.

Also, you can specify the default rollover profile to be used in Default Data Rollover Profile field.

Support for Multiple Passes for a subscriber

Usage Monitoring supports One time passes.

Support for Multiple Top-Ups

Usage Monitoring supports One time top-ups.

Matchlist for Quota use cases

To identify the geographical location where the data usage is occurring as well as to ensure that the correct quota plan is applied, Policy uses match lists while defining the MCC/MNC allocations, RAT-Type, Service GW IP address, APN Lists.

• IPv4 Subnet - When a Match List is created with a data type of IPv4 subnet, the Items are configured with valid IPv4 subnet addresses in CIDR notation.

  For example, 192.168.10.0/24.

  PRE evaluates if an IPv4 address belongs to one of the subnets configured in the match list.

• IPv6 Subnet - When a Match List is created with a data type of IPv6 subnet, the Items are configured with valid IPv6 subnet addresses in CIDR notation.

  For example, 2001:db8:abcd:0012::0/64.

  PRE evaluates if an IPv6 address or an IPv6 Prefix belongs to one of the subnets configured in the match list.

• Regular Expression - When a Match List is created with a data type of Regular Expression, the Items are configured with valid Regular Expressions, such as ^([a-zA-Z0-9. _-])+$.

  PRE evaluates if a string matches one of the Regular Expressions configured in the match list.

Support for flexible billing day change

Billing day for an active plan can be changed from monthly to yearly, weekly, daily, or hourly. The billing day change can be applied to either the current billing cycle or next billing cycle.

The Apply Billing Day / Data Plan Change field under Usage Monitoring page for Service configurations in CNC Console can be used to indicate whether the billing change should be applied to current billing cycle or to the next billing cycle.

With flexible billing day change, the billing day for plans will also be changed with the same periodicity. But, Policy supports changing the periodicity as well.

The billing date change should take place and determine if the usage should be pro-rated.

• Delayed behavior: Allows the billing day change to take effect on the next billing cycle irrespective of the current usage. Quota will be reset after the current billing cycle end date is reached.
• Immediate behavior: Allows the billing day change to take effect immediately. Quota will also be reset immediately.
• Default behavior: Allows the flexible billing day changes to take place immediately. For a user with no current usage and for a user that has current usage, billing day change will take place after the end of the user’s current billing cycle is reached.

The Enable Pro-rated Data at The Time of Billing Day Change field under Usage Monitoring page for Service configurations can be used to indicate whether pro-rated data calculation should be applied to the selected plan at a time of billing day change.

When billing day change is set to current cycle and a billing day change is performed, the lastresetTime field in umdata stores the previous billing day and resettime field stores the updated billing day.

Usage monitoring support at PCC rule level

Policy supports Usage monitoring either at PCC rule level or at session level.

Usage monitoring can be requested on an individual rule (PCC rule level) or on all rules activated during a IP-CAN session (session level).

• Based on certain custom attributes on CnUDR, quota can be granted for an application like whatsapp or facebook although the pass or a top-up volume been exhausted.

• Differentiate unlimited usage of certain application and not volume accumulate those applications for overall quota monitoring. For example: Plans with Facebook unlimited.

Multiple quotas contain single session-level and multiple PCC-level grants.

Rollover will be applicable for PCC-level grants.

• PCCRule data can be provisioned at UDR or configured at Policy. This can be of type BASE, TOP-UP and PASS.

• PCCRule can also be rollover. All rollover configurations will be applicable for PCCRule data limits.

• PCCRule can also allow excessUsage data.

• PCCRule can be of Type BASE, Top-up and pass.

You can configure the usage monitoring at PCC rule level using the following blocks available under Policy Projects in CNC Console.

• PCC Rule Hint: Allows to access the value of PCCRuleHint from Data limit profile and apply the same in UMPolicyDecision in monitoring key.
• Active Monitoring Key with PCCRuleHint: Allows to select a monitoring key for the configured PCCRule from usage monitoring policy decision which fulfills the value from active monitoring with PccRuleHint attribute.

For more information on configuring the PCC rules for usage monitoring, see Usage Monitoring section in Oracle Communications Cloud Natvie Core, Policy Design Guide.

Pro-Rating of quota limits

Policy supports pro-rating of quota volume. If a subscriber’s profile billing day is changed, a shorter than usual period occurs (either from the date of change, or after the next scheduled reset).

For example, if the user has a plan with a monthly quota of 30GB and the plan start date is the 1st of every month, now the plan is activating at the 10th of that month, so rather than allocating the complete 30GB to the user, only 20GB will be allocated to the user as the expected activation date is the 1st of the month, but the plan activates after 10 days, so the remaining data is 20GB for that month.

The following parameters under Usage Monitoring page for Service Configurations can be used to configure the pro-rating of the quota:

• Enable Pro-rated Data at The Time of Activation: Iindicates whether pro-rated data calculation should be applied to the selected plan at a time of activation or not.
• Enable Pro-rated Data at The Time of Billing Day Change: Iindicates whether pro-rated data calculation should be applied to the selected plan at a time obilling day change .

Pro-rating can be configured per plan to reduce the quota allocation for the short period.

Note:

Pro rating is not applicable for one-time plan.

Quota Policy conditions

The Policy supports a number of blocks, actions, and conditions that can be used for constructing Policy rules, such as:

• where the user has greater than number of rollover units of type unit type for plan name and usage type.

• where the user is using greater than 80 percent and less than 100 percent of total volume for Monthly1,Daily1

• where the user is using greater than 100 percent of total volume for Monthly1,Daily1

For more information on the blocks, actions, and conditions available to wrtite Policy rules, see see Usage Monitoring section in Oracle Communications Cloud Natvie Core, Policy Design Guide..

PRE support for Usage Monitoring

Policy uses Policy Runtime Engine (PRE) to enable and manage the following usage monitoring use cases:

• Grant pass or top-ups.
• Enable time of day quota. For example, If time of day is between HH:MM:SS - HH:MM:SS grant x% of volume and Y QoS
• Quota Plans can be activated by Policy Rule Conditions which look for attributes on
  • Gx attributes : MCC-MNC, RAT Type, Serving GW IP address.
  • CnUDR such as Tier, Entitlement, or Custom Field(s)values provisioned in the Subscriber Profile

PRE performs the Policy evaluation when it receives a notification from UDR regarding quota or state data update.

Possible change of parameters include:

• Reset of Quota, triggers an action to throttle, block, or re-direct user to charging portal
• Billing day change triggers pro-rata calculation
• Subscriber Tier change
• Any customer attribute definition change

Support for profiles based configuration

Data Limit Profiles

When a subscriber is provisioned with multiple quota plans with different priorities, a separate profile can be used to track each plan. For example, if a subscriber is provisioned a daily plan and a monthly plan, one profile is used to track the daily quota limit and another profile is used to track the monthly quota limit.

A unique name and identifier can be assigned to each data limit profile and details such as plan type, profile type, parent plan, priority, usage level, reset period and billing day can be configured for the profile.

Data Limit Profiles can be configured using CNC Console and REST API.

• Using CNC Console: Apply the configurations in Data Limit Profiles page under Usage Monitoring in Policy Data Configurations.

  For more information, see Data Limit Profiles.

• Using REST API: Configure the parameters in UM Data Limit Profile API.

  For more information, see UM Data Limit Profile section in Oracle Communications, Cloud Native Core, REST API Guide.

Data Limit Selection Profiles

A set of rules can be used to select one or more data plans based on certain conditions.

For example, if a subscriber is provisioned with one monthly limit quota plan and two roaming plans: roam1 and roam2, a selection rule can be used to select a plan based on home zone and roaming zone. Separate selection profiles can be created for each selection rule.

A unique name can be assigned to each selection profile and details such as rule type, rule priority, parameter type (forwarded attribute/Policy decision tag), attribute name, and match list can be configured for the profile.

Data Limit Selection Profiles can be configured using CNC Console and REST API.

• Using CNC Console: Apply the configurations in Data Limit Selection Profiles page under Usage Monitoring in Policy Data Configurations.

  For more information, see Data Limit Selection Profiles.

• Using REST API: Configure the parameters in UM Data Limit Selection Profile API.

  For more information, see UM Data Limit Selection Profile section in Oracle Communications, Cloud Native Core, REST API Guide.

Data Limit Sorting Profiles

Sorting rule is a set of rules to sort data limits.

When a subscriber is provisioned with multiple quota plans, a sorting rule can be applied to sort the quota plan based on a criteria. For example, if a subscriber is provisioned with two Monthly Limit Quota plan with different priority plan1 - priority1 and plan2 - priority2, a sorting rule can be created to select plan with higher priority. Separate sorting profiles can be created for sorting rules.

The sorting rules can be configured based on order of index, parameter type, attribute name, and order.

If selection rules are configured, sorting rules are applied after applying selection rules and when the output of selection rules results in more than one data limit.

Data Limit Sorting Profiles can be configured using CNC Console and REST API.

• Using CNC Console: Apply the configurations in Data Limit Sorting Profiles page under Usage Monitoring in Policy Data Configurations.

  For more information, see Data Limit Sorting Profiles.

• Using REST API: Configure the parameters in UM Data Limit Sorting Profile API.

  For more information, see Data Limit Sorting Profile section in Oracle Communications, Cloud Native Core, REST API Guide.

Data Rollover Profiles

When data rollover is enabled, data rollover profile can be used to configure the rollover.

The data rollover profile can be configured with details such as:

• rollover data consumption
• maximum number of rollovers
• data rollover percentage
• maximum rollover threshold
• minimum rollover threshold
• data limit cap

Data Rollover Profiles can be configured using CNC Console and REST API.

• Using CNC Console: Apply the configurations in Data Rollover Profiles page under Usage Monitoring in Policy Data Configurations.

  For more information, see Data Rollover Profiles.

• Using REST API: Configure the parameters in UM Data Limit Sorting Profile API.

  For more information, see Data Rollover Profile section in Oracle Communications, Cloud Native Core, REST API Guide.

Attribute Forwarding Profiles

Policy supports forwarding the value of attributes such as Serving Gateway MCC MNC / IP Address, and APN from PCRF Core to Usage Monitoring Service. An attribute forwarding profile is used to configure the list of attributes to be forwarded from PCRF Core to Usage Monitoring.

An attribute forwarding profile can be configured with details such as attribute name, attribute source, attribute selection (predefined/custom), request message type (diameter message/HTTP message), and attribute location.

The attribute forwarding profile name must be specified in PCRF Core settings.

Attribute forwarding profiles can be configured using CNC Console or REST API:

• Using CNC Console: Apply the configurations in Attribute Forwarding Profiles page under Common Data for Service Configurations.

  For more information, see Attribute Forwarding Profiles.

• Using REST API: Configure the parameters in Attribute Forwarding Profile API.

  For more information, see Attribute Forwarding Profile section in Oracle Communications, Cloud Native Core, REST API Guide.

Data Compression in Usage Monitoring

In order to handle the growing size of the Usage Monitoring database and the replication volume, Policy supports compressing the Usage Monitoring data.

Usage Monitoring service application is used to reduce the V columns in UmContext table for data persisted in the database.

Data Compression Scheme flag available under Usage Monitoring page for Service Configurations in CNC Console is used to configure the compression status on the V columns in UmContext table.

When accessing the data from UmContext.v, the application determines the compression status based on the value of COMPRESSION_SCHEME and does the decompression accordingly.

The Data Compression Scheme flag accepts the following values:

• Disabled: Indicates that the data will not be compressed and will be stored in the column in uncompressed format. The value of COMPRESSION_SCHEME for that row is set to the default value 0.
• MySQL Compressed: Indicates that the data will be compressed using MySQL and will be stored in the column in compressed format. The value of COMPRESSION_SCHEME for that row is set to 1.
• Application Compressed: Indicates that the data will be compressed using Zlib and will be stored in the column in compressed format. The value of COMPRESSION_SCHEME for that row is set to 2.

Note:

• The existing data will remain in uncompressed format and their COMPRESSION_SCHEME` is set to default NULL. Once the "Data Compression Scheme" changes to "MySQL Compressed" or "Application Compressed", all future v column data will be in compressed format.
• Existing session's data will be compressed once we send CCR-U/UDR Notify with compression enabled.

For more information on configuring data compression for Usage Monitoring, see Configuring Usage Monitoring.

Managing the Feature

This section provides information on enabling, configuring, observability and logging for Usage Monitoring on Gx Interface.

Enable

By default, the Usage Monitoring service is disabled.

To enable the service, set the Enabled parameter under Usage Monitoring group in PCRF Core Settings page for Service Configuration. to true at the time of installing or upgrading Policy.

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

The Enable PRE field under Usage Monitoring page for Service configurations in CNC Console can be used to enable or disable the interaction with PRE for Policy evaluation as per the match list.

Configure

You can configure the Usage Monitoring for Gx interface using CNC Console and REST API.

• Configure using CNC Console: To configure Usage Monitoring for Gx interface using CNC Console, perform the configurations as described in the following sections:

  • Configuring Usage Monitoring
  • Settings
  • Attribute Forwarding Profiles
  • Usage Monitoring

  For details on the blocks used to create Policy projects, see Oracle Communications Cloud Native Core, Converged Policy Design Guide.

• Configure using REST API: Refer to the Usage Monitoring section in Oracle Communications Cloud Native Core, Converged Policy REST Specification Guide.

4.45.1 Migrating Subscribers from OCPM to PCRF Deployment

Quota details for both OCPM (4G) and Converged Policy (5G) are configured and provisioned at the individual subscriber level in OCUDR and CnUDR respectively.

For details on how CnUDR provisions and manages the quota information for PCRF, see Convered Quota Support section in Oracle Communications Cloud Native Core, Unified Data Repository User Guide.

Using Provisioning Gateway, 4G provisioning system provisions OCPM data over SOAP/XML interface on CnUDR. Provisioning Gateway converts SOAP/XML to REST/JSON and forwards to CnUDR. CnUDR converges the OCPM quota and dynamic quota data to Converged data model and stores in CnUDR.

For details on how CnUDR integreates with the provisioning gateway, see Cloud Native Core, Provisioning Gateway Interface Specification Guide.

CnPCRF interacts with CnUDR to access and manage both OCPM and converged quota information. cnPCRF uses the N36 interface toward CnUDR for OCPM call flows.

The OCPM data that CnPCRF receives from CnUDR includes:

• Quota data: the runtime quota data of a subscriber. That is, the data time and/or volume consumed by that subscriber and the other meta-data. For example, plan activation date, reset date, any roll-over plans and their corresponding usages.

  The remaining quota must be derived based on the consumed data retrieved from 4G UDR.

• Dynamic quota data: includes the provisioning data for dynamic plans which are also known as passes and top-ups.

Important:

Since the 4G data structures for quota usages and monitoring are not defined by 3GPP standards, there must be a mapping from the proprietary 4G data structures to 3GPP defined 5G Data structures.

The following diagram depicts the connectivity between OCPM and CnUDR which will be swicthed to CnPCRF and CnUDR.

Diverting the subscribers from OCPM deployment to PCRF deployment involves the following procedures:

Migrating Subscribers from OCUDR to CnUDR

Subscribers from OCUDR are migrated to CnUDR either using the migration tool or on-demand.

Using the migration tool, the subscribers are migrated in batches based on subscriber range during the off peak hours.

The subscriber data is exported in EXML format, which is compatible with 4G OCUDR export format. It supports the export of 4G policy data (VSA and umData/umDataLimits) in EXML format from 5G UDR to 4G OCUDR using the subscriber export tool. In case of any error during the migration, the EXML format supports rollback of exported data.

For more details on the data export, see Support for EXML Format section in Oracle Communications Cloud Native Core, Unified Data Repository User Guide.

Note:

When Migration is in progress, dual provisioning at both OCUDR and CnUDR is not supported.

For more details on how the subscribers are migrated from OCUDR to CnUDR, see Migrating Subscriber Data from 4G UDR to 5G UDR section in Oracle Communications Cloud Native Core, Unified Data Repository User Guide.

The migration of the subscriber data can be monitored using the metrics mentioned under nudr-migration-service Metrics section in Oracle Communications Cloud Native Core, Unified Data Repository User Guide.

In case of migration failure for any reason either at OCUDR or at CnUDR, the quota for the subscriber must be reprovisioned to make up for any quota loss.

In case of new deployment, CnUDR must provision usage monitoring level, which indicates the level of the usage monitoring instance (PDU Session level or per Service). When Enable Quota Migration parameter is enabled, CnPCRF reads InitialServiceSpecific from OCUDR and sets the UsageMonLevel in CnUDR.

To set the UsageMonLevel, configure the following mandatory parameters in UDR for SM Policy data for subscriber profile:

Table 4-88 Mandatory Parameters

Parameter	Description
umDataLimits.endDate	Indicates the end date and time till when the usage monitoring level to be applied.
umDataLimits.name	Uniquely identifies the UM Data Limit Profile by a name.
umDataLimits.limitId	Specifies the limit identifier. Multiple limit identifiers may have the same priority.
umDataLimits.umLevel	Indicates the level of the usage monitoring instance (PDU Session level or per Service).
umDataLimits.startDate	Indicates the start date and time from when the usage monitoring level to be applied.
umDataLimits.usageLimit.duration	Indicates the duration of the usage limit in seconds. Range: 3600 - 31536000 (1 Year)
umDataLimits.usageLimit.totalVolume	Specifies the total data octets for both downlink and uplink. Range: 512 - 1073741824000 (1000 GB)
umDataLimits.usageLimit.uplinkVolume	Specifies the uplink data octets. Range: 512 - 1073741824000 (1000 GB)
umDataLimits.usageLimit.downlinkVolume	Specifies the downlink data octets. Range: 512 - 1073741824000 (1000 GB)
umDataLimits.resetPeriod.period	Indicates whether the periodicity is "YEARLY", "MONTHLY", "WEEKLY", "DAILY" or "HOURLY". Default value: Monthly
umDataLimits.Type	Indicates which day of the period to reset the usage limit. Default value: LAST_DAY Note: If this configuration is updated, the new configuration shall be applied in the next billing cycle.
umDataLimits.Priority	A Priority is used to weigh it with other Data Limit Profiles and UDR provisioned Data Limits of the same Plan Type. The priority can be used by Policy or Data Limit Selection Profile for choosing among different candidate profiles. The Plan Type, Priority within that Plan Type and the Selection Order of Plan Types together decide the order of selection of Data Plans.

For disaster recovery purposes on CnUDR, the database is backed up as described in Manual Database Backup and Restore section in Oracle Communications Cloud Native Core, Unified Data Repository Installation, Upgrade, and Fault Recovery Guide.

Diverting the Sh Traffic from OCPM to CnUDR

OCPM interacts with CnUDR over Sh interface.

To migrate the incoming traffic from OCPM to CnUDR:

1. Log in to the OCPM Console with the given credentials.
2. Add the new data source.
   1. Under Configuration section for MPE_CLUSTER, click Data Sources tab.
   2. Add the new data source as explained in Adding a Data Source section in Oracle Communications Policy Management Configuration Management Platform Wireless User's Guide.
3. Configure Sh data source.
   1. Under Configuration section for MPE_CLUSTER, click Data Sources tab.
   2. Click Modify.
   3. Add the Sh data source as as explained in Configuring an Sh Data Source section in Oracle Communications Policy Management Configuration Management Platform Wireless User's Guide.
4. Configure the server information as explained in Configuring Sh Server Information section in Oracle Communications Policy Management Configuration Management Platform Wireless User's Guide. Perform all the necessary
5. Reports tab under Configuration section for MPE Clusters can be used to monitor the status and activity of the connection. For more details, see Policy Server Reports section in Oracle Communications Policy Management Configuration Management Platform Wireless User's Guide.

   Note:

   If CnUDR receives any Sh-UDR request from OCPM and the subscriber profile is not yet migrated to CnUDR, CnUDR fetches the data from OCUDR on-demand and responds to OCPM.

On the CnUDR front, you can monitor the connectivity to OCPM using the metrics mentioned under Diameter Gateway Metrics and nudr-diameterproxy-service Metrics sections in Oracle Communications Cloud Native Core, Unified Data Repository User Guide.

In case of errors from cnUDR, rollback the Sh connection from CnUDR to OCUDR by configuring the data source back to OCUDR and changing the server connectivity as explained in Configuring Sh Server Information section in Oracle Communications Policy Management Configuration Management Platform Wireless User's Guide.

Configuring CnPCRF to fetch the data from CnUDR

1. Configure the CnPCRF to fetch the data from CnUDR.
   1. Perform the following congurations in Usage Monitoring page under Service Configurations in CNC Console:
      1. Enable Enable Quota Migration field to allow retrieval of OCPM data from CnUDR.
      2. Configure the following fields under Custom Attribute Mapping:
         • Reset Day & Time
         • Data Plan Name
         • Data Plan Priority
         • Data Plan Type
         • Data Rollover
         • Data Rollover Profile
         • Parent Plan Name
         • Parent Plan Source

         Data migrated from CnUDR includes the volume usage as is in custom attributes. Based on the Total available volume, CnPCRF calculates the InputVolume and OutputVolume for both Monthly quota and Dynamic Quota for Passes and Top-Ups.

      3. Verify the priority of the plans and configure Reverse Priority field accordingly to make sure that the order or priority in both OCPM and CnPCRF are aligned.

      For more details, see Configuring Usage Monitoring section in Oracle Communications Cloud Native Core, Converged Policy User Guide.

   2. If Data Limit Sorting Profiles is enabled, configure the fields in Data Limit Sorting Profiles page under Usage Monitoring in Policy Data Configurations.

      For more details, see Data Limit Sorting Profiles section in Oracle Communications Cloud Native Core, Converged Policy User Guide.

   3. Create the Policy projects for OCPM subscribers using the blocks in Policy Projects under Policy Management in CNC Console.

      With more number of subscribers migrated from OCUDR to CnUDR, more number of subscribers can be configured on CnPCRF to fetch the profiles from CnUDR.

      For more details on writing polices, see Oracle Communications Cloud Native Core, Converged Policy Design Guide.

   4. Once all the OCPM subscribers are migrated to CnPCRF, terminate the sessions at OCPM and configure the subscriber range to divert the subscribers to CnPCRF. Only CnPCRF will send the GET request to CnUDR for subscriber profiles.

   5. In case of any failure either at CnUDR or at CnPCRF during the migration:
      1. Disable Enable Quota Migration flag
      2. Bring up the OCPM again.
      3. Configure the OCPM to fetch the data from CnUDR over Sh interface.

      Any quota loss during the fallback from CnPCRF to OCPM is made up by reprovisioning the quota.

For details on the metrics used to monitor the successful migration at CnPCRF, see Usage Monitoring Metrics section in Oracle Communications Cloud Native Core, Converged Policy User Guide.

For detail on the metrics used to monitor the successful migration at CnUDR, see the following sections in Oracle Communications Cloud Native Core, Unified Data Repository User Guide:

• nudr-dr-service Metrics
• nudr-notify-service Metrics
• nudr-ondemand-migration-service Metrics

Note:

Configuring the PGW to connect to CnPCRF instead of OCPM and also setting the subscriber range at PGW is not in the scope of this document as PGW is outside the Oracle system.

4.45.2 Performance Considerations while Running Quota Management

The following configurations are required in order to achieve optimal performance while running quota management scenarios:

1. Enable compression scheme for both PolicyDS and Usage Monitoring Service. For more information, see PDS Settings and Configuring Usage Monitoring.
2. Optimize PolicyDS database query with SINGLE_UE_ID_PREFERENTIAL_SEARCH. For more information, see PDS UE ID Configuration.

4.46 Support for Autoenrollment of Subscribers

Policy supports autoprovisioning of the subscribers at UDR when the subscriber profile is not present in UDR.

1. When PCRF Core receives a CCR-i request, it tries to retrieve the subscriber profile from UDR.
2. If the subscriber profile is not present at UDR, PCRF Core handles the subscriber plan as configured at PCRF Core. The plan is chosen based on MCC-MNC, APN received in the request Message. It applies the right quota to the user and triggers a PATCH towards UDR.
3. A PATCH request is sent to UDR on SM-Data with details of policy-data including UM-Data.
4. UDR triggers autoprovisioning of the profile.

Call Flow

The following call flow depicts the scenario when the subscriber profile is not provisioned at UDR.

Figure 4-97 Scenario when user profile is not avaiable in UDR

1. PCRF Core receives a CCR-I request.
2. PCRF Core sends a GET request to PDS with the autoenrollment flag set to true.
3. PDS sends the GET request to UDR Connector, which in turn forwards the request to UDR.
4. If the subscriber profile is not present at UDR, UDR responds with a 404 message.
5. UDR connector forwards the error message to PDS.
6. PDS receives the 404 response and then reads the autoenrollment flag. It generates the default SM Policy data and adds the last error code as 404 indicating that UDR sent the 404 error in the same SM Policy data.
7. PDS sends the generated SM Policy data to the core service.
8. Optionally, Usage Monitoring service can send a GET request to PDS requesting for the quota profile.
9. PDS sends the GET request to UDR Connector, which in turn forwards the request to UDR.
10. If the quota profile is not present at UDR, UDR responds with 404 error and UDR connector forwards the 404 error message to PDS.
11. PDS reads the autoenrollment flag and generates a default UMquota with last error code as 404 and sends the data to Usage Monitoring service.
12. The default UM data that is generated at PDS is inserted into the association table with all the context information.
13. The Usage Monitoring service generates quota based on APN, MCC and MNC and sends a PATCH request to PDS.
14. PDS creates an entry in the database and sends this PATCH request to UDR Connector, which in turn forwards the request to UDR.
15. Once the autoprovisioning is done at UDR, it responds with a 200 success message.
16. After the PATCH request is successful, PDS sends a subscription request to UDR to subscribe for umData.

The following call flow depicts the scenario when the subscriber profile is provisioned at UDR, but the umData is not provisioned.

Figure 4-98 Scenario when the subscriber profile is provisioned at UDR, but the umData is not provisioned

1. PCRF Core receives a CCR-I request.
2. PCRF Core sends a GET request to PDS with the autoenrollment flag set to true.
3. PDS sends the GET request to UDR Connector, which in turn forwards the request to UDR.
4. If the subscriber profile is present at UDR, UDR responds with a 200 ok message with the subscriber data.
5. UDR connector forwards the message to PDS.
6. PDS sends the SM Policy data to the core service.
7. Optionally, Usage Monitoring service can send a GET request to PDS requesting for the quota profile.
8. PDS sends the GET request to UDR Connector, which in turn forwards the request to UDR.
9. If the quota profile is not present at UDR, UDR responds with 404 error and UDR connector forwards the 404 error message to PDS.
10. PDS reads the autoenrollment flag and generates a default UMquota with last error code as 404 and sends the data to Usage Monitoring service.
11. The default UM data that is generated at PDS is inserted into the association table with all the context information.
12. The Usage Monitoring service generates a quota based on APN, NCC and MNC and sends a PATCH request to PDS.
13. PDS creates an entry in its database and sends this PATCH request to UDR Connector, which in turn forwards the request to UDR.
14. Once the autoenrollment is done at UDR, it responds with a 200 success message.
15. After the PATCH request is successful, PDS sends a subscription request to UDR to subscribe for umData.

Managing the Feature

This section provides information on enabling, configuring, observability and logging for Support for autoenrollment for the subscriber.

Enable

You can enable the support for autoenrollment of the subscribers using CNC Console.

To enable the autoprovisioning of the subscriber profile at UDR when the subscriber profile is not available, enable Auto Enrollment on UDR parameter for SmPolicyData under User group in PCRF Core Settings page for Service Configuration.

For more information, see Settings.

Configure

You can configure the the support for autoenrollment of the subscribers using CNC Console.

For more information, see SmPolicyData under User group in Settings section.

4.47 Support for Subscriber Notification Using SMPP

Policy supports sending subscriber notification (SMS alerts regarding Quota management or usage reporting and activation/deactivation of services) to subscribers through SMPP (Short Message Peer-to-Peer) protocol. This feature enables transfer of short messages between External Short Message Entities (ESME) and Message Centres (MC).

To support notification through SMPP, Policy uses the HTTP notification framework.

Policy supports this feature using Notifier Service. You must enable the Notifier Service to use this feature. For more information, see Notifier Service.

Note:

Currently, this feature is supported only for PCRF-Core call flows.

Call Flow

Figure 4-99 Call flow for sending messages using SMPP protocol

1. PRE receives a Policy Evaluate request.
2. After the evaluation, PRE sends a notification message to the Notifier Service.
3. Notifier service evaluates the request and sends the notification to SMS Gateway (SMSC).
4. The SMS Gateway acknowledges the notification request.
5. The SMS Gateway sends a delivery receipt to Notifier Service.
6. The Notifier Service acknowledges the delivery receipt to the SMS Gateway.
7. The Notifier Service updates the metrics and then notify response to PRE.
8. PRE sends the Policy evaluation response to the core service.

Managing Support for Subscriber Notification Using SMPP

Enable

User can enable Subscriber Notification through SMPP using CNC Console or REST API for Policy.

• Enable using CNC Console: Set the value of Enable SMPP parameter to true under Notifier Configurations page in CNC Console.

  For more information, see Notifier Configurations.

• Enable using REST API: Set the value of smppConfiguration.isEnabled parameter under {apiRoot}/oc-cnpolicy-configuration/v1/notifier API to true.

  For more information, see Notifier Configurations section in Oracle Communications Cloud Native Core, Converged Policy REST Specification Guide.

Configure

User can configure Subscriber Notification through SMPP using CNC Console or REST API for Policy.

• Configure using CNC Console: To configure the Subscriber Notification through SMPP, perform the configurations under Notifier Configurations, Notification Server, SMS Gateway Group, and SMSC Host Info pages in CNC Console.

  For more information, see Notifier Configurations.

• Configure using REST API: To configure the Subscriber Notification through SMPP use the following REST APIs:
  • To enable and configure the notification through SMPP: {apiRoot}/oc-cnpolicy-configuration/v1/notifier
  • To configure the SMS Gateway: {apiRoot}/oc-cnpolicy-configuration/v1/smsGateway
  • To configure the SMSC Host Info: {apiRoot}/oc-cnpolicy-configuration/v1/smsHostInfo

  For more information, see Notifier Configurations section in Oracle Communications Cloud Native Core, Converged Policy REST Specification Guide.

Observe

The following metrics are added to support the subscriber notification using SMPP:

• http_in_conn_request_total
• http_in_conn_response_total
• smpp_request_total
• smpp_response_total
• active_smsc_conn_count

For more details on metrics, see Notifier Metrics.

The SMSC_CONNECTION_DOWN alert is added to trigger an alarm when the connection to Short Message Service Center (SMSC) Host is down.

For more information, see SMSC_CONNECTION_DOWN.

4.48 Support for Query on Update and Subscription to UDR

PCF uses the Query data procedure to retrieve user data from the UDR, when Policy core services such as SM, AM, or UE receives an update request.

If queryOnUpdate and subscriberToNotify flags are enabled and an update request is received then PCF makes a GET Query request along and Post Subscriber request to the UDR.

That is,

• Policy should query and subscribe to UDR during Update request if subscribeToNotify and queryOnUpdate flags are enabled and the previous GET or POST requests failed (could be in the Create request or a previous Update request).
• Policy should not query UDR once GET or POST request is successful and subscription is successful.

Call Flow

Figure 4-100 Retrieving user data from UDR upon a GET or Update request to a Policy Service

1. Policy Service (SM Service/ AM Service/ UE Policy Service) receives a create request from SMF/AMF.
2. Policy Service sends a request to PDS to get the user data.
3. PDS sends a GET request to UDR to retrieve the data.
4. If the user data does not exist, UDR responds with an error and subscription to user data from UDR is also not performed.
5. If the user data is found, UDR responds with a 200 OK message.
6. PDS sends a POST Subscription to UDR to subscribe for any update to the user data.
7. The respective Policy service (SM Service/ AM Service/ UE Policy Service) creates an association for the request and responds to SMF/AMF.
8. When the Policy service (SM Service/ AM Service/ UE Policy Service) receives an update request from SMF/AMF, the service do not send a GET request to PDS to retrieve the user data from UDR with queryOnUpdate and subscribeToNotify flags are enabled.
9. PDS sends the GET request to UDR and receives a 200 OK response.
10. If the previous GET or POST Subscription request to UDR has failed, PDS sends a POST subscription request to UDR once again to subscribe for notification on any update to user data in UDR.
11. PDS forwards the successful response to the respective Policy Service (SM Service/ AM Service/ UE Policy Service), which in turn forwards the response to SMF/AMF.

PDS Handling Subscription Failure from UDR

If UDR subscription fails with subscribeToNotify flag enabled, the user must configure the following advanced settings keys under PDS Settings page on CNC Console to reattempt the subscription call on next SM update.

• NOTIFY_PCF_SM_ON_SUBSCRIPTION_FAILURE
• SUBSCRIPTION_FAILURE_NOTIFICATION_DELAY
• SUBSCRIPTION_FAILURE_NOTIFICATION_RETRY_COUNT
• SUBSCRIPTION_FAILURE_NOTIFICATION_RETRY_DELAY

For more information, see PDS Settings.

Note:

In this case, queryOnUpdate flag for SM Service must be set to false.

With these configurations, PCF sends the subscription request towards UDR on receiving subscription failure notification from SM service.

Note:

For AM and UE Policy services, UDR subscription request is reattempted using queryOnUpdate flag.

If PDS receives 404 status code from UDR, it performs user-level clean up for core services and session-level clean up for Pcrf-Core.

When re-validation and resetContext flags are set to false and the request is same for the existing context without the subscription information and the fetch request from the data source is successful, PDS updates the database with subscriber and context information.

The core services (SM, UE, or AM services) have flags to persist subscription failure. The flag is set to false when GET operation is performed and set to true when subscription failure notification is received from PDS.

A new property called "subscriptionFailure" is added to the JSON schema of SmPolicyAssociation. This property holds an integer value, whether there is a subscription failure or not. This property value is determined by setting some specific bits in the integer number. The following table shows which bit specifies the type of data subscription failure:

Table 4-89 SmPolicyAssociation Data Type

Data Type	Bit Number
smData	1
operatorSpecificData	2

Managing the Query on Update feature

Enable

You can enable the Query on Update feature using CNC Console or REST API for Policy.

• Enable using CNC Console:

  • To enable the feature for SM Service, set the value of Query User on Update parameter to true under User group on PCF Session Management page.

    For more information, see PCF Session Management.

  • To enable the feature for AM Service, set the value of Query User on Update parameter to true under User group on PCF Access and Mobility page.

    For more information, see PCF Access and Mobility.

  • To enable the feature for UE Policy Service, set the value of Query User on Update parameter to true under User group on PCF UE Policy Service page.

    For more information, see PCF UE Policy Service.

• Enable using REST API:

  • Set the value of queryUserOnUpdate parameter under {apiRoot}/oc-cnpolicy-configuration/v1/services/pcfsm API to true.

    For more information, see Session Management Service section in Oracle Communications Cloud Native Core, Converged Policy REST Specification Guide.

  • Set the value of queryUserOnUpdate parameter under {apiRoot}/oc-cnpolicy-configuration/v1/services/pcfam API to true.

    For more information, see Access and Mobility Service section in Oracle Communications Cloud Native Core, Converged Policy REST Specification Guide.

  • Set the value of queryUserOnUpdate parameter under {apiRoot}/oc-cnpolicy-configuration/v1/services/pcfue API to true.

    For more information, see UE Policy section in Oracle Communications Cloud Native Core, Converged Policy REST Specification Guide.

Configure

You can configure the Query on Update feature using the CNC Console or REST API for Policy.

• Configure using CNC Console: To configure Query on Update feature for SM Service, AM Service and UE Policy service, perform the feature configurations under the User group on the respective service configurations page. For more information, see the following sections:
  • PCF Session Management
  • PCF Access and Mobility
  • PCF UE Policy Service
• Configure using REST API: Policy provides the following REST API to configure the Query on Update feature:
  • {apiRoot}/oc-cnpolicy-configuration/v1/services/pcfsm
  • {apiRoot}/oc-cnpolicy-configuration/v1/services/pcfam
  • {apiRoot}/oc-cnpolicy-configuration/v1/services/pcfue

Observe

The following PDS metrics provide the information about query on update feature:

• server_request_total
• server_response_total

For more information, see Policy DS Metrics.

4.49 Support for Presence Reporting Area

PCF supports the Presence Reporting Area (PRA) functionality to comply with the 3GPP standards.

Policy supports PRA functionality for SM Service, AM Service and UE Policy Service.

The Presence Reporting Area is an area defined within the 3GPP packet domain for reporting the presence of UE within that area. This is required for policy control and in charging scenarios. In E-UTRAN, the PRA can consist in a set of neighbor or non-neighbor Tracking Areas, or eNBs or cells.

There are two types of Presence Reporting Areas:

• UE-dedicated Presence Reporting Areas: Defined in the subscriber profile and composed of a short list of TAs and/or NG-RAN nodes and/or cells identifiers in a PLMN.
• Core Network pre-configured Presence Reporting Areas: Predefined in the AMF and composed of a short list of TAs and/or NG-RAN nodes and/or cells identifiers in a PLMN.

If the PRA feature is supported and SMF or AMF receives the PRA information from the serving node indicating any of the following:

• the UE is inside or outside of one or more PRAs
• any of the presence reporting areas is set to inactive

the SMF or AMF checks if the reported PRA identifier corresponds to a PRA that is relevant for the PCF. In that case, the SMF or AMF within the SmPolicyUpdateContextData or AmPolicyUpdateContextData or UEPolicyUpdateContextData data structure includes the PRA_CH within the repPolicyCtrlReqTriggers attribute and one or more PRA information report within the repPraInfos attribute. For each PresenceInfo data structure, the SMF or AMF includes the PRA status within the presenceState attribute and the PRA identifier within the praId attribute for each of the presence reporting areas reported by the serving node.

If the SMF or AMF receives additional presence reporting area information along with the PRA Identifier, the SMF or AMF only provides the PCF with the presence reporting area information corresponding to the additional PRA information.

• The SMF or AMF receives additional presence reporting area information when the UE enters or leaves one or more presence reporting areas related to a PRA set. In that case, the additional presence reporting area information corresponds to the actual individual presence reporting area. The received presence reporting area identifier corresponds to the PRA set ID and is used to identify the requester (PCF or CHF) of the notification information.
• PCF can acquire the necessary data for presence reporting from the UDR.
• Homogeneous support of PRA in a network is assumed.
• The serving node can activate the reporting for the PRAs which are inactive as described in the 3GPP TS 23.501 [2].

The following figure shows a call flow for PRA functionality for SM Service:

Figure 4-101 PRA Support for SM Service

The call flow is described as follows:

1. UE initiates a PDU session establishment request.
2. SMF sends an Npcf_SMPolicyControl_Create request message to PCF to establish an SM policy control correlation including the PDU session related information.
3. PCF completes the policy calculation based on the policy configuration and subscription information and user information. The PCF sends an Npcf_SMPolicyControl_Create response message to the SMF, including an SM policy and PRA information. The PRA type can be either UE-dedicated PRA or Set of Core Network PRA.

   Note:

   Currently, UE-dedicated PRA is not supported for SM Service.
4. When the user changes across the PRA, the SMF sends an Npcf_SMPolicyControl_Update request message to PCF to modify the SM policy control correlation, and report the change in location of the user to the PCF. The message contains the information related to change of UE presence in Presence Reporting Area.
5. The PCF sends an Npcf_SMPolicyControl_Update response message to the SMF, including the updated SM policy.

Figure 4-102 UE Policy Association create scenario:

1. UE Policy Service receives a UE Policy Association create request from AMF.
2. UE Policy Service sends a GET request to PDS along with a POST subscribe to fetch the user data from UDR.
3. PDS sends the request to UDR via the UDR Connector.
4. UDR responds with the user data as well as the triggers for UE location change and PRA change.
5. PDS forwards the details to UE Policy Service.
6. UE Policy Service sends the details to PRE for evaluation.
7. PRE evaluates and installs the PRA successfully.
8. If there is a Policy Evaluation that requires N1/N2 Policy transfer, AMF subscribes and transfers N1N2 messages.

Figure 4-103 UE Policy Association update scenario

1. UE Policy Service receives a UE update request from AMF which includes the UE Policy update along with PRA_CH and praStatuses.
2. UE Policy service sends the updates to PRE for evaluation.
3. PRE evaluates the details and triggers the appropriate action on the PRA. '
4. UE Policy Service responds to AMF with a UE Policy update successful message.
5. If there is a Policy Evaluation that requires N1/N2 Policy transfer, AMF transfers N1N2 messages.

Managing Presence Reporting Area

Enable

The PRA functionality is a part of Policy configurations. You do not need to enable or disable this feature.

Configure

You can add new PRAs and configure the them using the CNC Console or REST API for Policy.

• Configure using CNC Console: Perform the configurations on the PCF Presence Reporting Area page. For more information about configuring PRAs, see PCF Presence Reporting Area.

• Configure using REST API: Policy provides the following REST API for PRA configuration:

  API: {apiRoot}/ocpm/pcrf/v1/configuration/policy/pra

  You can perform the POST, PUT, or GET operations to configure the PRA feature. For more information about REST API configuration, see "PRA" in Oracle Communications Cloud Native Core, Converged Policy REST Specification Guide.

4.50 Handling Install and Remove Conflict for Same Rule

This section describes a high-level design of the Conflict Resolution of INSTALL and REMOVE actions on the same PCC/Session Rules when the remove action is Remove (ALL, Predefined, Dynamic, Conditioned, non-conditioned) in the policy project.

In certain policies, install/update and remove actions are applied for the same rule - which can be either a session rule or a PCC rule.

The following screen capture illustrates a policy to show conflicts in same session rule. In this example, the install, update, and remove actions are applied to the same session rule, that is, session_rule1:

Figure 4-104 Example of Policy with Conflicts in a Session Rule

In previous releases, after executing a similar policy, SM service would remove the rule. However, with this feature, PCF is enhanced to configure the precedence and resolve the conflicting install and remove actions on the same rule.

When SM service receives two action types, such as install and remove for the same rule, SM service processes the remove action for the first rule, and then installs it. However, if install is not configured for the rule, SM service can remove it.

Policy allows its users to select how to resolve such conflicts in the most suitable manner by using the Install/Remove Rule Conflicts Strategy parameter under PCF Session Management service configurations.

Managing Install/Remove Rule Conflicts Handling

Enable

The Handling Install/Remove Rule Conflicts is the core functionality of Policy configurations. You do not need to enable or disable this feature.

Configure

You can configure the managing Rule conflict functionality using the CNC Console or REST API for Policy.

• Configure using CNC Console: Set value of the Install/Remove Rule Conflicts Strategy parameter under the Rule group on the PCF Session Management page. For more information, see configurations for Rule in PCF Session Management.

• Configure using REST API: Policy provides the following REST API for Install/Remove Rule Conflicts configuration:

  API: {apiRoot}/oc-cnpolicy-configuration/v1/services/pcfsm

  Set value of the ruleConflictsStrategy parameter in the Session Management Service API. For more information about REST API configuration, see Rule Configurations of the "Session Management Service" in Oracle Communications Cloud Native Core, Converged Policy REST Specification Guide.

4.51 Diameter Session Retry

In PCF, diameter connector sends the request messages such as Rx RAR (Re-Authorization Request) or Rx ASR (Abort Session Request) via the diameter gateway to Application Function (AF). AF acknowledges these commands by sending a successful or failed messages Re-Authorization Answer (RAA) or Abort Session Answer (ASA) respectively to PCF.

The RAA or ASA messages answers when received with protocol errors such as 3002 (DIAMETER_UNABLE_TO_DELIVER) or 3004 (DIAMETER_TOO_BUSY) or session timeout, the operator would want to retry sending the same Rx RAR or Rx ASR diameter messages from PCF to AF through a different or an alternate BSF (Binding Support Function) or DRA (Diameter Routing Agent).

The Diameter Message Retry for Rx RAR and Rx ASR diameter messages is enabled through the Error Mapping Framework feature in the diameter gateway service. This framework resolves application errors and takes necessary action based on the error context. The error handler framework tries to find an alternate solutions based on the configurations set in CNC Console. If the error is resolved, it sends back the success result to the caller, else it either retries based on the configured maximum resolution attempts number or terminates by forwarding the last known error.

The operator should have configured a host and realm for retry of failed diameter messages in the diameter routing table. Diameter Gateway finds the alternate peer from the routing table. If the diameter routing table is not configured then there is no retry behavior from policy.

Note:

Default number of retry attempts is one, when the alternate peers are available. If alternate peers are not available, no retry attempt is made.

PCF retries resending Rx-RAR and Rx-ASR diameter messages for the following configurable error code series:

• 3xxx (Protocol Errors)
• 4xxx (Transient Failures)
• 5xxx (Permanent Failure)

For more information about these error codes refer to Diameter Error Codes feature section.

Figure 4-105 The block diagram represents the diamater Rx RAR and Rx ASR message flow with a retry:

The block diagram represents the diamater Rx RAR and Rx ASR message flow with a retry using the Error Handler Framework in Policy.

1. The diameter connector sends the diameter request and the diameter gateway receives the diameter request.
2. The diameter gateway forwards this diameter request to available BSF1 based on routing table and priority.
3. The BSF1 is not able to deliver this message to AF due to some reason.
4. The diameter gateway receives the failed diameter answer from the BSF1 then it redirects the request context to Error Handler.
5. Error Handler gets the request context from the failed diameter request and finds the alternate retry action configured.
6. The Error Handler provides the retry action for the same request to next available alternate BSF2.
7. The diameter gateway sends the retry diameter request to next alternate BSF2.
8. BSF2 sends the retry request to AF.
9. AF sends the answer to BSF2 back.
10. BSF2 sends the answer to diameter gateway.
11. The diameter gateway forwards the answer received from BSF2 to the diameter connector.

Session Retry Call Flows

The following call flow describes a successful transmission of Rx RAR or Rx ASR message to AF.

Figure 4-106 Call Flow Rx RAR or Rx ASR one time message retry - Success Case:

1. Diameter connector sends RAR or ASR request to diameter gateway.
2. Diameter Gateway sends the request to the available BSF, here to BSF1.
3. BSF1 is unable to deliver the RAR or ASR message to AF.
4. BSF1 returns a failed RAA or ASA message along with an error code to diameter gateway.
5. Diameter Gateway interprets the error code, and retries to send the failed message to the next available BSF, here BSF2 gets the message.
6. BSF2 sends the RAR or ASR message successfully to AF.
7. AF returns successful RAA or ASA message response to BSF2.
8. BSF2 sends this successful response to diameter gateway.
9. Diameter Gateway sends this response to diameter connector.

The following call flow describes a successful retry in case of a response timeout for Rx RAR or Rx ASR.

Figure 4-107 Call Flow RX RAR or RX ASR Timeout Retry - Success Case:

1. Diameter connector sends RAR or ASR request to diameter gateway.
2. Diameter Gateway sends the request to the available BSF, here to BSF1.
3. BSF1 is unable to deliver the RAR or ASR message to AF.
4. BSF1 returns a failed RAA or ASA message along with an error code to diameter gateway.
5. Diameter Gateway interprets the error code, and retries to send the failed message to the next available BSF, here BSF2 gets the message.
6. BSF2 sends the RAR or ASR message successfully to AF.
7. AF returns RAA or ASA message successful response to diameter gateway.
8. Diameter Gateway sends this response to diameter connector.

Retry Attempts

The user can choose to configure the number of retries to find a Peer for sending the Rx-RAR and Rx-ASR diameter messages. This retries is possible only when the alternate peers are available i.e., the Peer is alive, if it is not available i.e., the Peer is not alive then there is no retry attempt made. The default number of retry attempts is 1. The number of retry value can be any positive number between 1 to 2147483647.

The number of retries can be set through the advance settings configurations using the following advance setting keys:

• DIAMETER.ErrorHandler.MaxRetryCount.Rx.RAR
• DIAMETER.ErrorHandler.MaxRetryCount.Rx.ASR

If the above advance settings configurations are not supported in the CNC Console, then the default retry attempt is 1. If retry attempt value configured is a zero or negative number, then the default retry attempt value shall be considered.

Peer Cycle Back Retry

The user can choose to perform Peer retry in a cyclic manner if the number of retries configured is more than the number of alternate peers available for both Rx RAR and RX ASR message retries. This retries is possible only when the alternate peers are available i.e., the Peer is alive, if it is not available i.e., the Peer is not alive, then there is no retry attempt made. The user configures this in CNC Console by setting retry peer cycle back field to true.

This peer cycle back retry configuration is performed using the following advance setting keys:

• DIAMETER.ErrorHandler.CycleBackRetry.Rx.RAR
• DIAMETER.ErrorHandler.CycleBackRetry.Rx.ASR

If above advance settings configurations are not supported in the CNC Console, then the default peer cycle back retry is false.

Described below are the scenario that shows how the Diameter message retry mechanism works.

For example 1: Consider, the number of configured retries is 2 and only 2 BSF/DRA are configured as alternate peers in PCF. Both the peers are alive.

• The Rx RAR message is sent via (PCF-1) - (BSF1/DRA1) - (PCSCF-1) but the response has failed with error code 5012/timeout/3002/3004
• Then the message is resent (retry 1) via (PCF-1) - (BSF2/DRA2) - (PCSCF-1) but the response has failed with error code 5012/timeout/3002/3004.
• Then the message is resent (retry 2) again via (PCF-1) - (BSF1/DRA1) - (PCSCF-1) but the response has failed with error code timeout.

During the second time, the message is resent using the first peer again as only 2 BSF/DRA are available and alive, and peer cycle back retry mechanism is applied.

For example 2: Consider that the number of configured retries is 3 and only 2 BSF/DRA are configured as alternate peers in PCF and just one of the Peer BSF/DRA is alive.

• The Rx RAR message is sent via (PCF-1) - (BSF1/DRA1) - (PCSCF-1) but the response has failed with error code 5012/timeout/3002/3004
• Then the message is resent (retry 1) via (PCF-1) - (BSF1/DRA1) - (PCSCF-1) but the response has failed with error code 5012/timeout/3002/3004.
• Then the message is resent (retry 2) again via (PCF-1) - (BSF1/DRA1) - (PCSCF-1) but the response has failed with error code timeout.

The message is resent 3 times through the same peer as only one BSF/DRA is alive, and cycle back retry mechanism is applied

The following call flow describes the peer cycle back retry when the number of retry count is higher than the alternate peers available.

Figure 4-108 RX RAR/RX ASR Retry - Peer Cycle Back When Retry Count > Alternate Peers

1. Diameter connector sends ASR or RAR request to the diameter gateway
2. Diameter Gateway sends the request to the available BSF, here to BSF1.
3. BSF1 is unable to deliver the RAR or ASR message to AF.
4. BSF1 returns a failed RAA or ASA message along with an error code to diameter gateway.
5. Diameter Gateway tries to resend the failed message to the next available BSF, here BSF2 gets the message.
6. BSF2 sends the RAR or ASR message successfully to AF.
7. AF responds with failed RAA/ASA response to BSF2.
8. BSF2 sends the failed RAA/ASA response to diameter gateway.
9. At Diameter Gateway, if retry cycle back is enabled, then it resend the RAR or ASR message back to BSF1.
10. BSF1 sends the RAR or ASR message successfully to AF.
11. AF returns RAA or ASA message successful response to BSF1.
12. BSF1 returns RAA or ASA message successful response to diameter gateway.
13. Diameter Gateway returns RAA or ASA message successful response to diameter connector.

Error Originator Peer

The Error Originator Peer indicates the peer host where the Rx RAR or Rx ASR failed message error occurred/originated while sending or retry sending the Diameter messages. The user can customize the error origination peer by using Error Originator filed in the CNC Console and the customizing options are based on:

• An error received from an intermediate peer (INTERMEDIATE PEER).
• An error received from the destination peer, which is not an intermediate peer (DESTINATION PEER).
• An error received from any peer (ANY).

An intermediate peer is BSF/DRA and a destination peer (not intermediate peer) is P-CSCF.

By default, the error originator peer option is any peer. If multiple error originator peers are configured for the same error code, then the first priority error originator configurations, applies for the response failures.

In case of response timeout, the error originator would be considered based on:

• The destination host in RAR/ASR is af.xxx.com. If message is sent to bsf.xxx.com and if response timeout happens, then it is considered as error originated from intermediate peer.
• The destination host in RAR/ASR is af.xxx.com. If message is sent to af.xxx.com and if response timeout happens, then it is considered as error originated from destination peer.

The following call flow describes the error origination by intermediate peer.

Figure 4-109 RX RAR/RX ASR Retry - Error Originated by Intermediate Peer

1. Diameter connector sends ASR or RAR request to the diameter gateway.
2. Diameter Gateway sends the request to the available BSF, here to BSF1.
3. BSF1 gets DIAMETER TOO BUSY error.
4. BSF1 forwards this error to diameter gateway.
5. Diameter Gateway retries sending this failed message through BSF2.
6. BSF2 sends this message to AF.
7. AF returns RAA or ASA message successful response to BSF2.
8. BSF2 returns RAA or ASA message successful response to diameter gateway.
9. Diameter Gateway returns RAA or ASA message successful response to diameter connector.

The following call flow describes the error origination by destination peer (not intermediate peer).

Figure 4-110 RX RAR/RX ASR Retry - Error Originated by Destination Peer (Not Intermediate Peer)

1. Diameter connector sends ASR or RAR request to the diameter gateway.
2. Diameter Gateway sends the request to the available BSF, here to BSF1.
3. BSF1 sends the RAR or ASR message successfully to AF.
4. AF (Destination Peer) sends the failed RAA/ASA response to BSF1.
5. BSF1 sends the failed RAA/ASA response to diameter gateway.
6. Diameter Gateway retries sending this failed message through BSF2.
7. BSF2 sends this message to AF.
8. AF returns RAA or ASA message successful response to BSF2.
9. BSF2 returns RAA or ASA message successful response to diameter gateway.
10. Diameter Gateway returns RAA or ASA message successful response to diameter connector.

Default Error Handling Configuration

PCF provides the default error handling configuration to attempt diameter session retry on all error codes (except diameter result code 2xxx) and timeout for Rx RAA and Rx ASA failed diameter messages. When the diameter message retry feature is enabled on Rx interface, these default error handling configurations get applied by default. The user has an option to enable/disable these default configurations through the CNC Console edit configurations.

The error configuration consists of error state and error cause. Error state, a mandatory parameter provides the details about the error that occurred. Error cause, a optional parameter provides additional information on the error occurred such as sub-status, error message. The error configuration can be assigned a priority of evaluation in case the error matches with more than one error state.

For all default error handling configurations, the value for retry attempt is 1 and peer cycle back retry is false. The number of retry value can be any positive number between 1 to 2147483647.

Note:

If retry attempt value configured is a zero or any negative number, then the default retry attempt value shall be considered.

A sample default configuration looks like:

• Message - Rx-RAR, Status code - ANY (except 2001)
• Message - Rx-ASR, Status code - ANY (except 2001)
• Message - Rx-RAR, Status code - ANY, Error Cause Message - TIMEOUT_EXCEPTION
• Message - Rx-ASR, Status code - ANY, Error Cause Message - TIMEOUT_EXCEPTION

Managing Diameter Session Retry

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

Enable

By default, Diameter Message Retry behavior is disabled for Rx interface and operator can enable this feature through the CNC Console configurations.

Configure Using CNC Console

Perform the feature configurations in CNC Console as described in Error Configurations section.

Configure Using REST API

Perform the export/import error configurations as described in "Error Configurations" section in Oracle Communications Cloud Native Core, Converged Policy REST Specification Document

Observability

Metrics

Following metrics were updated in the Diameter Gateway Metrics section:

• occnp_diam_request_local_total
• occnp_diam_request_network_total
• occnp_diam_request_inter_total

Alerts

Following alerts are used by this feature:

• RAA_RX_FAIL_COUNT_EXCEEDS_CRITICAL_THRESHOLD
• RAA_RX_FAIL_COUNT_EXCEEDS_MAJOR_THRESHOLD
• RAA_RX_FAIL_COUNT_EXCEEDS_MINOR_THRESHOLD
• ASA_RX_FAIL_COUNT_EXCEEDS_CRITICAL_THRESHOLD
• ASA_RX_FAIL_COUNT_EXCEEDS_MAJOR_THRESHOLD
• ASA_RX_FAIL_COUNT_EXCEEDS_MINOR_THRESHOLD

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.

4.52 Monitoring the Availability of SCP using HTTP2 OPTIONS

Policy determines the availability and reachability status of all SCPs irrespective of the configuration types.

This feature is an enhancement to the existing SBI routing functionality. Egress Gateway microservice interacts with SCP on their health API endpoints using HTTP2 OPTIONS method. It monitors the health of configured SCP peers to ensure that the traffic is routed directly to the healthy peers. This enhancement avoids routing or rerouting towards unhealthy peers, thus minimizing the latency time.

Egress Gateway microservice maintains the health status of all available and unavailable SCPs. It maintains the latest health of SCPs by periodically monitoring and uses this data to route egress traffic to the most preferred healthy SCP.

Figure 4-111 New SCP selection mechanism

Once peerconfiguration, peersetconfiguration, routesconfiguration, and peermonitoringconfiguration parameters are configured at Egress Gateway microservice, and all SCPs (after Alternate Route Service (ARS) resolution, if any vFQDN is configured) are marked initially as healthy. The peers attached to the associated peerset are scheduled to run health API checks and update the health status continuously.

During the installation, the value of the parameter peermonitoringconfiguration is set to false by default. Since, this feature is an add-on to the existing SBI Routing feature and will be activated if the sbirouteconfig feature is enabled. To enable this feature, perform the following:

• configure peerconfiguration with healthApiPath
• configure peersetconfiguration
• configure sbiroutingerroractionsets
• configure sbiroutingerrorcriteriasets
• configure routesconfiguration
• enable peermonitoring

If SBI Routing feature is enabled before upgrading, the healthApi in peerconfiguration should be attached manually to existing configured peers. If the operator tries to enable peermonitoringconfiguration and the targeted peers do not have the healthApiPath then an appropriate error response is sent.

Managing Monitoring the Availability of SCP Using SCP Health APIs

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

Configure

You can configure the Monitoring the Availability of SCP using the REST API.

Configure Using REST API: Perform the following feature configurations as described in Oracle Communications Cloud Native Core, Converged Policy REST Specification Document:

• create or update peer Peer Configuration with health status endpoint details.
• create or update the peerset peersetconfiguration to assign these peers
• enable the feature using the below peermonitoring configuration peermonitoringconfiguration.

Note:

Health Monitoring of the peer will start only after the feature is enabled and the corresponding peerset is used in sbirouteconfig.

Observe

Following metrics are added in the CNC Policy Metrics section:

• oc_egressgateway_peer_health_status
• oc_egressgateway_peer_health_ping_request_total
• oc_egressgateway_peer_health_ping_response_total
• oc_egressgateway_peer_health_status_transitions_total
• oc_egressgateway_peer_count
• oc_egressgateway_peer_available_count

Alert

Following alerts are added in the Alert section:

• SCP_PEER_UNAVAILABLE
• SCP_PEER_SET_UNAVAILABLE

4.53 Supports 3gpp-Sbi-Correlation-Info Header

The 3gpp-Sbi-Correlation-Info header contains correlation information, User Equipment (UE) identity that is used by an operator in various offline network management, performance analysis, and troubleshooting tools and applications to identify messages (requests, responses, subscriptions, and notifications) related to a particular subscriber.

In CNC Console, enable this feature in the global configuration page. By enabling this, the correlation-info header gets applied across all of the PCF external interfaces like PCF Session Management(SM), PCF Access and Mobility(AM), PCF UE Policy, PCF User Connector and Gateways. The generation of new correlation-info headers and forwarding them to producer NF's is not managed by this global configuration UI option.

The generation of new correlation-info header in PCF is managed by the NF Communication Profiles configuration page. Communication profiles once attached with the respective interfaces (PCF SM, PCF AM, PCF UE Policy, and PCF User Connector) allows to enable or disable of header generation along with the flexibility of selecting correlation type to be used for the header. The Correlation types namely SUPI, GPSI or both are supported for this release. For more details about NF Communication Profiles, see the NF Communication Profiles section.

The following conditions are to be met for header generation in PCF:

1. Correlation-info header, not sent by consumer NF towards PCF interfaces.
2. CNC Console global settings configuration is enabled.
3. Communication profile attached to the respective interface has the required configuration.

Further, the received or generated headers are forwarded only when the setting Send Correlation-Info Header is set to Enable.

3gpp-Sbi-Correlation-Info

The header contains correlation information e.g., UE identifier related to the HTTP request or response.

Note:

1. The possibility to include more than 1 correlationinfo parameter in the 3gpp-Sbi-Correlation-Info header is kept for future extensibility.

   correlationinfo = ctype "-" cvalue

   ctype = "imsi" / "impi" / "suci" / "nai" / "gci" / "gli" / "impu" / "msisdn" / "extid" / "imei" / "imeisv" / "mac" / "eui" / token

2. The token is defined for future extensibility.

   The token of ctype shall not use the dash ("-") character.

   cvalue = 1*tchar

Table 4-90 The format of cvalue shall comply with the data type description.

ctype	Description
SUPI	VarUeId format defined for IMSI and starting after the string "imsi-"
GPSI	VarUeId format defined for MSISDN and starting after the string "msisdn-"

Table 4-91 3GPP defined Custom HTTP Headers

Header	Description	Example
3gpp-sbi-correlation-info	This header may be used to contain correlation information (e.g., UE identity), that may be used by an operator in various offline network management, performance analysis and troubleshooting tools/applications to identify messages (requests, responses, subscriptions, notifications) related to a particular subscriber.	EXAMPLE 1: When UE identifier used is SUPI and SUPI type is an IMSI: 3gpp-Sbi-Correlation-Info: imsi-345012123123123 EXAMPLE 2: When UE identifier used is GPSI and GPSI type is an MSISDN:3gpp-Sbi-Correlation-Info: msisdn-1234567890 EXAMPLE 3: When UE identifiers used are SUPI and GPSI where SUPI type is an IMSI and GPSI type is an MSISDN:3gpp-Sbi-Correlation-Info: imsi-345012123123123; msisdn-1234567890

Identifier Precedence for Generation of Correlation Header in request Toward other NFs

The UDR Connector service supports configurations to provide default user identifier that takes precedence over other identifiers. This ensures that these configured identifier should be considered while sending the requests toward external NFs like NRF or UDR. This key precedence UDR.KeyPrecedence value can be set by the user in the advanced settings of PCF User Connector service page in CNC Console. For more details, see the Advanced Settings in PCF User Connector section.

The configured precedence identifiers affects the generation of correlation header. The first identifier in the configuration shall be considered for the generation of the correlation header.

Consider a scenario where SBI Correlation header is configured and the default key precedence's are set to IMSI,GPSI. If both of the identifiers exists in the request then one of them takes priority based on the configured default key precedence. In this case IMSI shall be used for generating the correlation header while sending requests to external NFs UDR or NRF. If the precedence's are changed to GPSI, SUPI then for generation of correlation header GPSI is considered while sending the request to external NFs UDR or NRF.

Managing SBI messages correlation using Subscriber Identity

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

Configure

In CNC Console, enable this feature by enabling Enable SBI Correlation field in the general settings page, see General Settings.

Configure Using REST API

For configuring the SBI messages correlation using Subscriber Identity feature using REST APIs, see Oracle Communications Cloud Native Core, Policy REST API Specification Guide.

Observe

Following metrics are added in Correlation-Info Header Metrics section:

• occnp_correlation_info_header_received
• occnp_correlation_info_header_forwarded
• occnp_correlation_info_header_generated

4.54 HTTP Error Codes

Policy can handle Protocol or Application errors and a few other additional defined errors for various scenarios. When Policy encounters an error in processing a request, it sends error codes in the response message to the request. With this enhanced functionality, Policy allows users to mitigate errors from different NFs.

Error Mapping for CHF and UDR Interfaces

Configure

In UDR and CHF, the session retry functionality is used to mitigate the errors. For more information, see Support for Session Retry and Alternate Route Service.

In addition to session retry, we can mitigate the errors using the object expressions with action as "Reject session with error code" blockly. If this blockly is not configured, PCF responds to SMF or AMF with "400" error code and "USER_UNKNOWN" cause code for any error response received from UDR while fetching subscriber profile. For more information, see "PCF-SM" section in Oracle Communications Converged Policy Design Guide.

Enable

To enable Error Handling feature where the Error Codes from CHF & UDR to reach the core services, the following flags needs to be updated in the Advanced Settings specific to the service:

• For UDR, UDR_ errorHandlerEnabled key must be set to true, in the advanced settings for PCF User Connector service.
• For CHF, CHF_errorHandlerEnabled key must be set to true, in the advanced settings for PCF User Connector service.
• For PDS, PDS_ERROR_HANDLER_ENABLED key must be set to true, in the advanced settings for PDS service.

For more information, see Configuring Policy Using CNC Console.

Observe

Added the following metrics for Error Mapping for CHF and UDR Interfaces :

• error_handler_in_total
• error_handler_out_total

Note:

When the UDR Connector, CHF Connector, and PDS act as a consumer of the error and the Error Handler feature is integrated with these services and is enabled, and if these services are generating any error while interacting with other services, then the above metrics will increment. Whereas, When the UDR Connector, CHF Connector act as a producer of the error, the Error Handler feature is not considered. Hence, these metrics does not get incremented even when the feature is enabled.

For more information, see Error Mapping Metrics.

Error Mapping for AM, SM, and UE Interfaces

In AM, SM, and UE, the session retry functionality is used to mitigate some of the errors. For more information, see Support for Session Retry and Alternate Route Service.

Enable

This is a core functionality of Policy. You do not need to enable or disable this feature.

Configure

The following blockly has been added in the PCF-SM to reject a session with error code:

Figure 4-112 Reject Session with Error Code and Error Cause

This action blockly allow to reject the session with a custom error code and a custom error cause.

For more information, refer to Oracle Communications Cloud Native Core, Policy Design Guide.

Observe

The following metrics is incremented in case of error mapping for AM, SM, and UE interface:

• ocpm_ingress_response_total

For more information, see

Error Mapping for NRF Interface

In NRF, the Policy retries with primary and non-primary NRFs to configure the errors.

Enable

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

notifySemanticValidationEnabled

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

Configure

This feature can be configured using the notifySemanticValidationEnabled parameter.

Observe

Added the following metrics for Error Mapping for NRF Interface :

• nrfclient_nw_conn_in_response_total
• nrfclient_nw_conn_out_notify_response_total

For more information, see NRF Client Metrics.

For the list and the details of the HTTP error codes of CHF, UDR, AM, SM, UE, and NRF interfaces, see HTTP Error Codes Supported by Policy.

4.55 Diameter Error Codes

Policy can handle protocol or application errors and a few other additional defined errors for various scenarios. When Policy encounters an error in processing a request, it sends error codes in the response message to the request. Policy interacts with BSF and at Rx interface during the life of a session there could be an error scenario.

Policy should handle error gracefully and there should be defined path for each error scenario for effective functioning of NF. With this enhanced functionality, Policy allows users to configure error codes.

The error codes are configured by adding customized values, for a defined condition, for the following fields:

• Error Description
• Diameter Result Code
• Experimental Result
  • Vendor ID
  • Experimental Result Code

Configure

To configure the diameter error codes for Policy, users can use any of the following ways:

• CNC Console: Perform the configurations on the Diameter Error Codes page. For more information, see Diameter Error Configurations .
• REST API: Perform the configurations using POST, PUT, or GET operations. For more information about REST API configuration, see Cloud Native Core Policy REST Specification Document.

Observe

The occnp_diam_response_local _total and occnp_diam_response_network_total metrics are applicable for this feature. For more details, see Diameter Gateway Metrics.

4.56 Configurations for Pre and Post Upgrade/Install Validations

This feature applies validation checks that are required on the application, databases, and its related tables before and after the upgrade/installation of Policy application.

On enabling this mandatory pre-flight and post-flight validation checks, for successful upgrade/installation following are validated:

• does the related database exists
• does all the required tables exist
• does the required table schema exist for all the required tables
• does all the required infrastructure exists

This pre-flight and post-flight checks ensures that all the dependent databases, tables, schema, applications are in right order for performing successful update/installation.

For more information on how to how to set the parameter value for pre and post flight checks, see Configurations for Pre and Post Upgrade/Install Validations in Cloud Native Core, Converged Policy Installation, Upgrade and Fault Recovery Guide.

4.57 Support Multiple Cluster Deployment at CNC Console

The CNC Console supports both single and multiple cluster deployments.

In a single cluster deployment, the CNC Console can manage NFs and Oracle Communications Cloud Native Core, Cloud Native Environment (CNE) common services deployed in the local Kubernetes clusters.

In a multiple instances deployment, the CNC Console can manage multiple Policy instances and CNE common services deployed within a Kubernetes cluster. For more information about single and multiple cluster deployments, see Oracle Communications Cloud Native Core, Cloud Native Configuration Console Installation, Upgrade and Fault Recovery Guide.

The following image represents a Kubernetes cluster with one instance of CNC Console and two instances of Policy. The single instance of the CNC Console is configuring two instances of Policy with different namespaces.

Figure 4-113 Support for Multiple Instance Deployment

With the support of multicluster deployment, Policy deployed in multiple Kubernetes clusters can be accessed using CNC Console. In a multicluster deployment, the CNC Console can manage Policy and CNE common services deployed in the remote Kubernetes clusters.

The following image represents multiple Kubernetes clusters with one CNC Console and two Policy deployments. The single instance of the CNC Console is configuring two instances of Policy with different namespaces deployed in different clusters.

Figure 4-114 Support for Multicluster Deployment

4.58 NetLoc Support

NetLoc is one of the 3GPP-defined features responsible for retrieving access network information in IMS network architecture. Depending on the operator's policy configuration and subscription, the NetLocfeature helps in fetching User Equipment (UE) time zone information and User location information from the access network. Such information is called Network Provided Location Information (NPLI). Operators can use the NPLI information for the following:

• Lawful interception
• Charging
• IMS Emergency Calls Routing
• Retention of Location Information Data
• Special Call Routing for Localized Services
• Location-based service triggering

4.58.1 NetLoc Support in PCF

Based on the response that it receives from SMF over the N7 interface, PCF provides this NPLI to the Application Function (AF) over the Rx interface.

The Application Function initiates a request towards PCF requesting NPLI using the "ACCESS_NETWORK_INFO_REPORT" within Specific-Action AVP and Required-Access-Info AVPs. PCF, upon receiving this request, initiates Npcf_SMPolicyControl_UpdateNotify procedure for AN_INFO event trigger requesting NPLI in terms of user location and/or user timezone information. SMF, upon receiving NPLI information from core network (AMF), provides that info PCF using Npcf_SMPolicyControl_Update procedure. Then, PCF forwards that information to AF using RAR message using 3GPP-User-Location-Info, 3GPP-MS-TimeZone, 3GPP-SGSN-MCC-MNC AVPs.

By default, this feature is not configured on the CNC Policy deployment. You must configure the NetLoc feature using the CNC Console or REST API.

Feature Negotiation

Once the feature has been enabled, feature negotiation needs to happen between AF and PCF during Npcf_PolicyAuthorization_Create Service operation. As defined by the 3GPP feature negotiation mechanism, the following conditions must be met for AF and PCF to agree upon the NetLoc feature:

• NF consumer or AF advertises the support for "NetLoc" feature within the attribute supportedFeatures (suppFeat) as part of SmPolicyData when sending a request to create SM policy association.
• In turn, PCF advertises the same value for the supportedFeatures (suppFeat) while sending the response for the policy association create request.

Managing NetLoc Support

Enable and Configure

By default, this feature is not configured on the CNC Policy deployment. You can opt to configure the NetLoc using the CNC Console or REST API.

On PCF Session Management page, under Service Configurations, select NetLoc from the drop-down menu of Override Supported Features parameter. For more information about the configurations, see PCF Session Management.

Using the REST APIs for Session Management Service, you can enable the feature by updating the value as NetLoc for the following parameter under the system group:

overrideSupportedFeatures": [
      "NetLoc"
    ],

Observe

No new alarms or alerts are introduced specific to this feature.

4.58.2 NetLoc Support in PCRF

Based on the response that it receives from PGW (PCEF) over the Gx interface, PCRF provides this NPLI to the Application Function (AF) over the Rx interface.

The AF initiates a request (AAR-I/U, STR) towards PRCF requesting NPLI using "ACCESS_NETWORK_INFO_REPORT" within Specific-Action AVP and Required-Access-Info AVPs (USER_LOCATION and/or MS_TIME_ZONE). PRCF, upon receiving this request, initiates RAR procedure for AN_INFO event trigger requesting NPLI in terms of user location and/or user timezone information. PGW (PCEF), upon receiving NPLI information from core network (AMF) provides the information to PCRF through CCR-Update. PCRF forwards that information to AF using RAR message using 3GPP-User-Location-Info, User-Location-Info-Time, 3GPP-MS-TimeZone, 3GPP-SGSN-MCC-MNC AVPs.

Feature Negotiation

PGW (PCEF) sends in Supported-Features "Feature List": "1024" in CCR-Initial advertising that NetLoc is supported. PCRF sends the same "Feature List": "1024" in CCA with DIAMETER_SUCCESS, else it receives a diameter Error. AF sends in AAR-I/U Supported-Features "Feature List": "32" when soliciting NetLoc Information. Then, PCRF sends the same "Feature List": "32" in AAA with DIAMETER_SUCCESS.

Managing NetLoc Support

Enable and Configure

By default, this feature is not configured on the CNC Policy deployment. You must configure the NetLoc feature using the CNC Console or REST API.

This feature can be configured or customized using the following Advanced Settings keys in the PCRF Core services in the CNC Console:

• DIAMETER.ENF.AFDirectReply
• DIAMETER.AF.MaxWaitForInfoOnTermination

Fore more information, see Settings.

Observe

No new alarms or alerts are introduced specific to this feature.

4.59 Subscription to Notification Support for Signaling Path Status

Policy supports notification of the AF signaling Transmission Path Status (SMF → Policy → AF), subscription to notification of the AF signaling Transmission Path Status (AF → Policy → SMF), and cancellation of subscription to notification of the AF signaling Transmission Path Status (AF → Policy → SMF).

PCRF-Core supports notification of the AF signaling Transmission Path Status (PGW → PCRF-Core → AF), subscription to notification of the AF signaling Transmission Path Status (AF → PCRF-Core → PGW ), and cancellation of subscription to notification of the AF signaling Transmission Path Status (AF → PCRF-Core → PGW ).

For Policy, during a PDU session establishment procedure, the SMF includes the IMS_SIG value within the qosFlowUsage attribute and the PCF accepts that default QoS flow is dedicated to IMS signaling, the PCF within the SmPolicyDecision data structure must include the IMS_SIG value within the qosFlowUsage attribute.

For more information on IMS_SIG value update in the CNC Console, see PCF Session Management.

For, PCRF-Core, during a PDU session establishment procedure, the SMF includes the IMS_SIGNALLING value within the bearerusage attribute and the PCF accepts that default QoS flow is dedicated to IMS signaling, the PCF within the SmPolicyDecision data structure must include the IMS_SIGNALLING value within the bearerusage attribute.

For more information on IMS_SIGNALLING value update in the CNC Console, see PCRF Core .

Notification of the AF Signaling Transmission

When the Policy is notified of the release of resources associated to the PCC or QoS rules corresponding with AF Signaling IP Flows, the Policy informs the AF about the release of the signaling Transmission path by sending a Re‑Authorization Request (RAR) command to the AF.

The RAR includes the Specific-Action AVP set to the value "INDICATION_OF_RELEASE_OF_BEARER (4)" and the deactivated IP Flow encoded in the Flows AVP.

On Sm Update/CCR-U with the IMS Signalling Rule set as inactive, at a minimum, we are able to send an Rx ASR.

Figure 4-115 Notification of the AF Signaling Transmission in 5G

Figure 4-116 Notification of the AF Signaling Transmission in 4G

Subscription to notification of the AF Signaling Transmission

When AF receives an initial register SIP message from an attached UE, it subscribes to the notifications of the AF signaling transmission path status.

The AF provides the following:

• UE’s IP address (using either the Framed-IP-Address AVP or the Framed-Ipv6-Prefix AVP)
• Specific-Action AVP requesting the subscription to "INDICATION_OF_RELEASE_OF_BEARER"

  • INDICATION_OF_RELEASE_OF_BEARER (4)

    In the AAR, this value indicates that the AF requests the server to provide a notification at the removal of a bearer

• The AF shall additionally provide a Media-Component-Description AVP including a single Media-Sub-Component AVP with the Flow-Usage AVP set to the value "AF_signaling"
• The Media-Component-Description AVP shall contain the Media-Component-Number AVP set to "0

On Rx AAR with the flow-usage as IMS Signalling, we link the Rx session with the IMS Signalling rule. We do not need to send a Gx RAR or SmUpdateNotify.

If we do not find an IMS Signalling rule, then bind it to the first PCC rule so we get an ASR only on CCR-T.

Figure 4-117 Subscription to notification of the AF Signaling Transmission in 5G

Figure 4-118 Subscription to notification of the AF Signaling Transmission in 4G

Cancellation of subscription to notification of the AF Signaling Transmission

If the Rx Diameter Session is only used for subscription to Notification of signaling Path Status, the AF may cancel the subscription to notifications of the status of the AF signaling transmission path. In this case, the AF uses a Session-Termination-Request (STR) command to the CNCPolicy, which gets acknowledged with a Session-Termination-Answer (STA) command.

On Rx STR, we simply unlink the Rx session from the Gx session / sm session and IMS Signalling Rule, but we do not remove the IMS Signalling Rule from the Gx or SM.

Figure 4-119 Cancellation of subscription to notification of the AF Signaling Transmission in 5G

Figure 4-120 Cancellation of subscription to notification of the AF Signaling Transmission in 4G

4.60 Support for SessionRuleErrorHandling

The Session Rule Error Handling is a 3GPP 29.512 TS defined feature. If the SessionRuleErrorHandling feature is supported and SMF receives one or more session rules but it does not enforce some or all session rules then the SMF provides sessionRuleReports.

When SMF detects that the provisioning of some or all the session rules is unsuccessful, it sends a Session Rule Error Report in the Npcf_SMPolicyControl_Update and Npcf_SMPolicyControl_UpdateNotify Response. Depending on the Session Rule Error Report sent by SMF, the PCF may decide whether to retain the old session rule, re-installation, modification, or removal of the session rule.

As per the sessionRuleReport, you can write policy conditions matching the ruleStatus and sessRuleFailureCode received for the session rule and take action of installation, modification, and removal of the session rule. The blocks are available only when you select PCC/Session Rule Error Report under PCF-SM service while configuring the Policy Project. For more information about these blocks, see Oracle Communications Cloud Native Core, Converged Policy Design Guide.

Feature Negotiation

Once the feature has been enabled, feature negotiation needs to happen between SMF and PCF during Npcf_SMPolicyControl_Create service operation. As defined by the 3GPP feature negotiation mechanism, the following conditions must be met for SMF and PCF to agree upon the SessionRuleErrorHandling feature:

• NF consumer or SMF advertises "SessionRuleErrorHandling" feature within the attribute supportedFeatures (suppFeat) as part of SmPolicyData when sending a request to create SM policy association.
• In turn, PCF advertises the same value for the supportedFeatures (suppFeat) while sending the response for the policy association create request.

Enable

By default, this feature is not enabled on the Policy deployment. You can enable the SessionRuleErrorHandling feature using the CNC Console or REST API.

• CNC Console: On PCF Session Management page, under Service Configurations, select SessionRuleErrorHandling from the drop-down menu of Override Supported Features parameter. For more information about the configurations, see PCF Session Management.
• REST API: Using the REST APIs for Session Management Service, you can enable the feature by updating the value as SessionRuleErrorHandling for the following parameter under the System group in the {apiRoot}/oc-cnpolicyconfiguration/v1/services/pcfsm REST API:

  overrideSupportedFeatures": [
        "SessionRuleErrorHandling"
      ],

Observe

The following metrics have been enhanced for this feature:

• occnp_http_in_conn_request_total
• occnp_http_in_conn_response_total
• occnp_http_out_conn_request_total
• occnp_http_out_conn_response_total

Note:

The "sessRuleReports" dimension has been added for occnp_http_in_conn_request_total and occnp_http_in_conn_response_total metrics.

The following metric have been added for this feature:

• occnp_sm_sess_rule_failure_total

For more information, see SM Service Metrics.

No new alerts are introduced for this feature.

Maintain

Logs are added for processing of sessionRuleReports attribute as part of SM-Update request and SM-UpdateNotify response.

4.61 3GPP-User-Location-Info AVP in Rx RAR

This section describes the inclusion of 3GPP-User-Location-Info in Rx RAR, when the UserLocation attribute is received on the SMF-N7 flows.

The following call flow describes the message flow from PCF to send 3GPP-User-Location-Info AVP towards AF:

Figure 4-121 3GPP-User-Location-Info Call Flow

PCF performs the following steps to send 3GPP-User-Location-Info AVP towards AF:

1. Application Function (AF) forwards the supported feature Attribute Value Pair (AVP) with LTE_Phase3 value in the first Authentication Request (AAR) of AF/Rx towards the PCF. In response, PCF exchanges the same AVP in Authentication Answer (AAA).
2. The AF subscribes for any of the specific-action between INDICATION_OF_SUCCESSFUL_RESOURCE_ALLOCATION and INDICATION_OF_RELEASE_OF_BEARER.
3. After establishing the AF session successfully, Session Management Function (SMF) sends repPolicyCtrlReqTriggers with SUCC_RES_ALLO or RES_RELEASE along with ruleReports and userLocationInfo to PCF.
4. SM service generates event notification request for Diameter Connector over N5 along with ueLoc attribute.
5. The Diameter Connector generates a Re-Auth-Request (RAR) with 3GPP-User-Location-Info AVP for AF over Rx interface.

ueLoc Attribute

In case of 3GPP access, the PCF includes the user location information in the ueLoc attribute in N5 interface. The ueLoc atrribute has eutraLocation and nrLocation attributes.

eutraLocation: The data type for the eutraLocation attribute is EutraLocation. It has the following attributes:

Table 4-92 eutraLocation

Attribute Name	Data Type	Description
tai	Tai	The Type Allocation Code (TAC) of the Tracking Area Identity (TAI) is set to one reserved value. For an example 0x0000 is the TAC of a TAI attribute. If the TAI information is not available, see clause 19.4.2.3 of 3GPP TS 23.003 [7]).
ecgi	Ecgi	E-UTRA Cell Identity
ignoreEcgi	Boolean	This attribute indicates that the Ecgi is ignored. This attribute is set to false by default. When it is set as true, the Ecgi is ignored.
globalNgenbId	GlobalRanNodeId	It indicates the global identity of the ng-eNodeB in which the UE is currently located.
globalENbId	GlobalRanNodeId	It indicates the global identity of the eNodeB in which the UE is currently located.

nrLocation: The data type for the nrLocation attribute is NrLocation. It has the following attributes:

Table 4-93 NrLocation

Attribute Name	Data Type	Description
tai	Tai	The TAC of the TAI is set to one reserved value. For an example 0x0000 is the TAC of a TAI attribute.
ncgi	Ncgi	NR Cell Identity
ignoreNcgi	Boolean	This attribute indicates that the Ncgi is ignored. This attribute is set to false by default.
globalGnbId	GlobalRanNodeId	This attribute indicates the global identity of the gNodeB in which the UE is currently located.

For more information on ueLocation, see the 3GPP technical specification 29.514.

In the RAR message, GeographicLocation is used. Following are the types of GeographicLocation used in the RAR message:

• TAI(128): Tracking Area ID for E-UTRAN.
• ECGI(129): Evolved Cell Global ID for E-UTRAN.
• TAI_ECGI(130): Tracking Area ID and Evolved Cell Global ID for E-UTRAN.
• ENODEB(131): global identity of the ng-eNodeB for E-UTRAN.
• TAI_ENODEB(132) : Tracking Area ID and global identity of the eNodeB for E-UTRAN.
• EXTENDEDNODEB(133): global identity of the eNodeB for E-UTRAN.
• TAI_EXTENDEDNODEB(134) : Tracking Area ID and global identity of the eNodeB for E-UTRAN.
• NCGI(135) : NR Cell Global Identity for NR.
• TAI5G(136) : Tracking Area ID for NR.
• TAI5G_NCGI(137) : Tracking Area ID and NR Cell Global Identity for E-UTRAN.
• NGRANNODE(138) : global identity of the gNodeB for NR.
• TAI5G_NGRANNODE(139) : Tracking Area ID and global identity of the gNodeB for NR.

Following is the sample N7 update request for the userLocationInfo attribute:

"userLocationInfo": {
    "eutraLocation": {
      "tai": {
        "plmnId": {
          "mnc": "313",
          "mcc": "350"
        },
        "tac": "790"
      },
      "ecgi": {
        "plmnId": {
          "mnc": "313",
          "mcc": "350"
        },
        "eutraCellId": "AB0912"
      },
      "ageOfLocationInformation": 233,
      "ueLocationTimestamp": "2019-03-13T06:44:14.34Z",
      "geographicalInformation": "AAD1234567890123",
      "geodeticInformation": "AAD1234567890123BCEF",
      "globalNgenbId": {
        "plmnId": {
          "mnc": "313",
          "mcc": "350"
        },
        "n3IwfId": "n3iwfid"
      }
    }
  }

Following is the sample N5 Notification Request for the ueLoc attribute:

"ueLoc": {
    "eutraLocation": {
        "tai": {
        "plmnId": {
          "mcc": "313",
          "mnc": "350"
        },
        "tac": "790"
      },
      "ecgi": {
        "plmnId": {
          "mcc": "313",
          "mnc": "350"
        },
        "eutraCellId": "AB0912"
      }
    },
    "nrLocation": null,
    "n3gaLocation": null
  }

Following is the sample Diameter RAR message:

Sample Diameter RAR request:
Diameter Message: RAR
Version: 1
Msg Length: 232
Cmd Flags: REQ,PXY
Cmd Code: 258
App-Id: 16777236
Hop-By-Hop-Id: 4144052655
End-To-End-Id: 2394693330
  Session-Id (263,M,l=9) = 1
  Origin-Host (264,M,l=28) = diam-conn.oracle.com
  Origin-Realm (296,M,l=18) = oracle.com
  Destination-Realm (283,M,l=24) = test.example.com
  Destination-Host (293,M,l=28) = diamcliaf.oracle.com
  Auth-Application-Id (258,M,l=12) = 16777236
  Specific-Action (513,VM,v=10415,l=16) = INDICATION_OF_SUCCESSFUL_RESOURCES_ALLOCATION (8)
  Flows (510,VM,v=10415,l=44) =
    Media-Component-Number (518,VM,v=10415,l=16) = 1
    Flow-Number (509,VM,v=10415,l=16) = 2
  User-Location-Info-3GPP (22,V,v=10415,l=25) = Type=TAI_ECGI(130) MCCMNC=313350 TAC=1936 ECI=11208978

For more information, see the following 3GPP specification:

• 29.512
• 29.514
• 29.214
• 29.229

Enable

This feature is enabled automatically at the time of Policy installation.

Configure

Diameter connector has an environment variable PRIORITY_SPECIFIC_ACTION which prioritizes the action while sending RAR message, if AF has subscribed for INDICATION_OF_FAILED_RESOURCE_ALLOCATION and INDICATION_OF_RELEASE_OF_BEARER.

4.62 Support for Server Header

PCF handles various requests from consumer Network Functions (NFs) and other network entities over HTTP protocol. On receiving these requests, PCF validates and processes them before responding to these requests. In case, PCF sends an error response, then the consumer NFs need to know the source of the error to trouble shoot the error and take corrective measures. The integration of this feature at PCF helps to determine the originator of the error response.

This feature offers the support for Server Header in PCF responses, which contains information about the origin of an error response and the type of the error encountered. The Server Header includes the type of NF as "NF Type", followed by a “-” and the identity of the NF or the network entity. It is expected to be present in all PCF responses in the following format:

<NF_Type>-<NF_Instance_Id>

Where,

• <NF Type> is the type of the NF generating the error.
• <NF Instance-Id> is the unique identifier of the NF instance generating the error response.

For example: PCF-54804518-4191-46b3-955c-ac631f953ed8

The inclusion of the Server header in the PCF response is configurable, and can be enabled or disabled using a flag. Also the error codes that are included as part of the Server header in the error response are also configurable. The configuration of these parameters are done through either with REST APIs that are exposed through configuration server or Helm Configurations.

The operation mode that is either REST or HELM for Server Header configuration is done using the below flag:

ingress-gateway: 
  serverHeaderConfigMode: REST # Possible values: HELM, REST. Based on this value, the feature flag for "server"  header will need to be enabled either in Helm configuration or Rest  configuration.

Note:

Nf Type and Nf Instance Id are mandatory fields for Server Header to get included in the error response. If either of the fields Nf Type or Nf Instance Id are configured as empty, then the Server Header will not get included in the error response.

Managing Server Header

Enable

By default, this feature is disabled.

You can enable the Server Header feature using Helm or REST API configurations as follows:

• Helm: To enable the server header feature using Helm configuration, set the value for parameter serverHeaderConfigMode to HELM in the custom-values.yaml file. Then, set the value for parameter serverHeaderEnabled.enabled to true under routesConfig for ingress-gateway.

  For more information, see the Oracle Communications Cloud Native Core, Converged Policy Installation, Upgrade, and Fault Recovery Guide.

• REST API: To enable the server header feature using REST configuration, set the value for parameter serverHeaderConfigMode to REST in the custom-values.yaml file. Using REST API, set the enabled parameter to true in the following resource URI:

  {apiRoot}/PCF/nf-common-component/v1/igw/serverheaderdetails

  For more information, see the section Server Header at Ingress Gateway in Oracle Communications Cloud Native Core, Converged Policy REST Specification Guide.

Configure

You can configure the server header feature using the REST API or CNC Console:

• Configure using REST API:Perform the REST API configurations in the following sequence to configure this feature:
  1. Configure serverheaderdetails to enable the feature.

     {apiRoot}/PCF/nf-common-component/v1/igw/serverheaderdetails

  2. Configure routesconfiguration to map route ID and its corresponding route-level configuration.

     {apiRoot}/PCF/nf-common-component/v1/igw/routesconfiguration

  3. Configure errorcodeserieslist to update the errorcodeserieslist that are used to list the configurable exception or error for an error scenario in Ingress Gateway.

     {apiRoot}/PCF/nf-common-component/v1/{serviceName}/errorcodeserieslist

  Note:

  If you define server header configuration at both global and route levels, the route level configuration takes precedence over the global level configuration.

  For more information, see the "Server Header at Ingress Gateway" section in Oracle Communications Cloud Native Core, Converged Policy REST API Specification Guide.

• Configure using helm: When parameter serverHeaderConfigMode is set to HELM and to configure the Server Header at Ingress Gateway, you need to perform the helm configurations either at Global or at Route level.

  
  # All attributes under "serverHeaderDetails" will need to be configured only if "serverHeaderConfigMode" is set as "HELM"
  serverHeaderDetails:
    enabled: true
    errorCodeSeriesId: E1
    configuration:
      nfType: PCF    
      nfInstanceId: INS-1
   
  # Use below configuration to define errorCodeSeries list
  errorCodeSeriesList:
    # Value of "id" attribute will need to used for assigning "errorCodeSeriesId" either at Global or Route level conf for Server header.
  - id: E1
    errorCodeSeries:
    - errorSet: 4xx
      errorCodes:
      - 400
      - 408
    - errorSet: 5xx
      errorCodes:
      - 500
      - 503
  - id: E2
    errorCodeSeries:
    - errorSet: 4xx
      errorCodes:
      - -1

  Following Helm Configuration performed at Route Level:

  
  routesConfig:
  - id: backend_ms1_route
    uri: https://backend-ms1:8440/
    path: /ms1/**
    order: 1
    metadata:
      # All attributes under "serverHeaderDetails" will need to be configured only if "serverHeaderConfigMode" is set as "HELM" and Route level configuration is required. If not defined, Global configurations will be used
      serverHeaderDetails:
        enabled: true     # Since this flag is set to true at Route level, "server" header configuration will be enabled for this Route with respective "errorCodeSeriesId" as E2
        errorCodeSeriesId: E2 # This attribute will need to be defined if "server" header configuration is enabled at Route level.
  - id: backend_ms2_route
    uri: https://backend-ms2:8550/
    path: /ms2/**
    order: 2
    metadata:
      # All attributes under "serverHeaderDetails" will need to be configured only if "serverHeaderConfigMode" is set as "HELM" and Route level configuration is required. If not defined, Global configurations will be used
      serverHeaderDetails:
        enabled: false    # Since this flag is set to false at Route level, "server" header configuration will be disabled for this Route altogether.

  Note:

  If you define server header configuration at both global and route levels, the route level configuration takes precedence over the global level configuration.

  For more information, see the Oracle Communications Cloud Native Core, Converged Policy Installation, Upgrade, and Fault Recovery Guide.

• Configure using CNC Console: A new group, NF Server Settings is added to the NF Communication Profile page. For more information, see NF Communication Profiles.

4.63 SBI Timer Handling

PCF-SM service receives requests from ingress Gateway with the help of the following 3GPP headers:

• 3gpp-Sbi-Origination-Timestamp- contains the date and time (with a millisecond granularity) when the originating entity initiated the request.
• 3gpp-Sbi-Sender-Timestamp- contains the date and time (with a millisecond granularity) at which an HTTP request or response is originated.
• 3gpp-Sbi-Max-Rsp-Time- contains the time duration expressed in milliseconds since the absolute time is indicated in the 3gpp-Sbi-Origination-Timestamp header.

The timer profile sets request timeout values for UDR, CHF, BSF, SMF, and AMF messages in applications or interfaces. Policy applies the specific timeout profile while sending requests to external NFs. For more information on managing timer configurations, see Support for Timer Configurations.

The timeout value used towards different interfaces of PCF such as UDR, CHF, BSF, SMF, and AMF also depends on the message communication towards the HTTP server. The message communication towards the HTTP server can be synchronous or asynchronous:

1. Synchronous:
   • When Timer headers are available:
     • When current time is subtracted from the sum of 3gpp-Sbi-Origination-Timestamp and 3gpp-Sbi-Max-Rsp-Time and the result is greater than zero, then it is considered as potential_requestTimeout. In this case, if the validation fails you must immediately fail the request towards upstream. Thereafter, a similar check is done by the upstream service.
     • If TimerProfile is configured and applicable for a respective interface on service, then the minimum value out of potential_requestTimeout or TimerProfile_value is taken as request timeout.
     • If TimerProfile is not configured or applicable for respective interfaces, then the minimum value out of potential_requestTimeout or Static timeout value of service is taken as request timeout. Here, the static timeout value is the value timeout that the user configures in the Helm.
   • When Timer headers are not available:
     • If TimerProfile is configured and applicable for respective interfaces of the service, then TimerProfile_value is used as request timeout.
     • If TimerProfile is not configured or applicable for respective interfaces of the service, then static timeout is used as request timeout.
2. Asynchronous
   • If TimerProfile is configured for a respective interfaces on service, then use value of the TimerProfile request timeout.
   • If TimerProfile is not configured or applicable for respective interface on service, then set the static timeout as request timeout. While setting the static timeout value, you must ensure that the value of static timeout is greater than any timeout profile value.

The timeout value is calculated as per message instead of per interface. It allows the user to configure a different timeout, whether the UDR connector or NRF interface is sending a Get or Subscribe message. The user can calculate the timeout using UDR messages. For more information on managing the timeout, see Support for Timer Configurations.

Managing SBI Timer

Enable

To enable the SBI Timer Header, set the isSbiTimerEnabled parameter to true, under the ingress-gateway configurations in the custom values.yaml file for Policy.

If the isSbiTimerEnabled parameter is 'true' then:

• 3gpp-Sbi-Sender-Timestamp, 3gpp-Sbi-Max-Rsp-Time, and 3gpp-Sbi-Origination-Timestamp are used along with route level (if configured) and global level request timeout to calculate final request timeout.
• After calculating the final request timeout, the original values of 3gpp-Sbi-Sender-Timestamp, 3gpp-Sbi-Max-Rsp-Time, and 3gpp-Sbi-Origination-Timestamp are published in the Orig-3gpp-Sbi-Sender-Timestamp, Orig-3gpp-Sbi-Max-Rsp-Time, and Orig-3gpp-Sbi-Origination-Timestamp respective custom headers.

If isSbiTimerEnabled is 'false', then the SBI headers are not taken into consideration even if, they are present and the custom headers are not published.

Configure

You can configure the parameters for SBI Timer by updating the custom values file for Policy. For more information about configuring the parameter value, see Late Arrival Handling Configuration in Oracle Communications Cloud Native Core, Converged Policy Installation, Upgrade and Fault Recovery Guide.

Observe

The ocpm_udr_tracking_request_timeout_total, ocpm_udr_tracking_request_timeout_total, ocpm_egress_request_timeout_total, and ocpm_timeout_total metrics are applicable for SBI timers. For information related to SBI Timer metrics, see CNC Policy Metrics .

4.64 Detection and Handling of Late Arrival Requests

PCF Service receives requests from Ingress Gateway with the 3GPP headers. These requests help in the detection of the response time for the SM service. Following headers are received from the Ingress Gateway:

• 3gpp-Sbi-Origination-Timestamp- It contains the timestamp when the originating entity initiates the request.
• 3gpp-Sbi-Max-Rsp-Time- It contains the time duration expressed in milliseconds since the absolute time is indicated in the 3gpp-Sbi-Origination-Timestamp header.
• 3gpp-Sbi-Sender-Timestamp- It contains the date and time (with a millisecond granularity) at which an HTTP request or response is originated from the previous NF.

PCF must be able to read the 3gpp-Sbi-Origination-Timestamp and 3gpp-Sbi-Max-Rsp-Time headers to be able to respond as per the request. The following scenarios can be considered:

• If the sum of 3gpp-Sbi-Origination-Timestamp and 3gpp-Sbi-Max-Rsp-Time is less than the current time, the PCF service must reject the message with a 504 HTTP code and the message: "TIMED_OUT_REQUEST".
• If the request does not include either 3gpp-Sbi-Origination-Timestamp, 3gpp-Sbi-Sender-Timestamp, or 3gpp-Sbi-Max-Rsp-Time headers, then this request is accepted and the call flow continues as normal with the inclusion of collision detection.
• If 3gpp-Sbi-Max-Rsp-Time receives a negative value, this header is considered invalid. In this case, the service fallbacks to the default behavior and accepts the request irrespective of the origination/Sender timestamp value.

In case of collision detection, PCF needs to trigger a cleanup internally on the rest of the services so that there is only one association per user at a time.

Collision Detection of SM PDU Sessions

When SM Service receives a new SM PDU Session Create request and if the value of SYSTEM.COLLISION_DETECTION.TERMINATE_NOTIFY.ENABLED advanced settings key is set to true, SM Service detects and cleans up duplicate requests of SM Sessions (Collision Detection) and sends Terminate Notify to SMF when .

SM service deletes the older session from SMPolicyAssociation database and sends the Terminate Notify request to SMF.

Figure 4-122 Sample call flow for sending Terminate Notify when duplicate session is found (collision detection) and SM service cleans up the older session from database

1. SM service receives a SM CREATE request from SMF through Ingress Gateway.
2. SM service sends a GET request to PDS to get the subscriber details from UDR, initiates a binding session request with Binding Service and then sends a request to PRE for policy evaluation. After the session is successfully created, SM services responds to SMF with 201 created message.
3. SM service receives another CREATE request from SMF, which is a duplicate of the session that is already created.
4. SM service processes the new CREATE request and deletes the older session.
5. SM service sends a Terminate Notify message to SMF through Egress Gateway.

6. After deleting the details of the older session, SMF responds to SM service with 204 No Content message.

Managing Late Arrival requests and Collision Detection

Enable

The detection and handling of late arrival feature can be enabled or disabled using ENABLE_LATE_ARRIVAL parameter. For more information about configuring the parameter value, see Detection and Handling of Late Arrival Requests in Oracle Communications Cloud Native Core, Converged Policy Installation, Upgrade, and Fault Recovery Guide.

For collision detection, the SYSTEM.COLLISION.DETECTION parameter is available to the user. It is set to false, by default. When the parameter is set to true, PCF-SM checks for collision in the SMPolicyAssociation table, based on User Equipment information (ie. SUPI) and the PDU Session ID.

PCF-UE and PCF-AM checks for collision in the UEPolicyAssociation and AMPolicyAssociation table respectively, based on User Equipment information (ie. SUPI).

Configure

You can configure the parameters for late arrival handling by updating the custom values file for Policy. For more information about configuring the parameter value, see Detection and Handling of Late Arrival Requests in Oracle Communications Cloud Native Core, Converged Policy Installation, Upgrade, and Fault Recovery Guide.

Observe

Policy provides metrics specific to late arrival requests and collision detection. For information related to late arrival requests and collision detection metrics, see Late Arrival Requests and Collision Detection Metrics .

4.64.1 PCF Support for Detection and Handling of Late Arrival Requests in BSF

Each microservice propagates the 3gpp-Sbi-Origination-Timestamp header and updates the 3gpp-Sbi-Sender-Timestamp from PCF to BSF with the current timestamp when it receives a request from SMF or SCP.

For adding Detection and Handling of Late Arrival functionality in BSF, it is necessary to make sure these headers and a new Custom header are propagated from PCF to BSF. Moreover, as required by the user, PCF supports to set the value of Custom-Sbi-Sender-Timestamp header.

To create Custom-Sbi-Sender-Timestamp it is necessary to add the following configuration to PCF ingress-gateway:

routesConfig:
    - id: sm_create_session_route
      uri: http://{{ .Release.Name }}-occnp-pcf-sm:{{ .Values.global.servicePorts.pcfSmServiceHttp }}
      path: /npcf-smpolicycontrol/*/sm-policies
      order: 1
      method: POST
      readBodyForLog: true
      filters:
        subLog: true,CREATE,SM
        customReqHeaderEntryFilter:
          headers:
            - methods:
              - POST
              headersList:
                - headerName: 3gpp-Sbi-Message-Priority
                  defaultVal: 24
                  source: incomingReq
                  sourceHeader: 3gpp-Sbi-Message-Priority
                  override: false
                - headerName: Custom-Sbi-Sender-Timestamp
                  defaultVal: func:currentTime(EEE, d MMM yyyy HH:mm:ss.SSS z,gmt)
                  source: incomingReq
                  sourceHeader: 3gpp-Sbi-Sender-Timestamp
                  override: false

4.65 Support for Session Retry and Alternate Route Service

For previous releases, Policy and PCF were configured with primary and secondary NRF or SCP statically by limiting to a specific number. Starting with release 1.8.0, Policy provides the Session Retry functionality. This feature enables the alternate recovery mechanisms to mitigate the impact of any unavailable resource. The policy system provides flexible and configurable retry behavior for selected interfaces.

A retry profile specifies when and how the signaling message from one network function to another are retried and rerouted on failures. For example, if heartbeat messages that PCF sends to NRF fail consistently, the PCF should choose a different (secondary or next priority) NRF that is available to send the subsequent heartbeat messages. Similarly, the retry or reroute mechanisms are required for messages going towards UDR, CHF, and so on. Even the notifications to SMF and AMF may need to be retried and rerouted based on the configuration.

Retry

Retry is initiated when PCF microservices initiate an egress request, but it fails to reach the egress gateway. The reason can be connection failure or Aspen Service Mesh failure. Session retry enables alternate recovery mechanisms to mitigate impact of any unavailable resource. Policy system provides flexible and configurable retry behavior for selected interfaces. You can configure retry profile for the following destination NFs: UDR, CHF, BSF, SMF, AMF, and AF through CNC Console.

The following figure shows a scenario when PCF microservice initiates an egress request, but it fails to reach the egress gateway:

Figure 4-123 PCF Microservice Initiates Egress Request

Alternate routing

Alternate routing is initiated when egress gateway fails to reach external network function (NF) or external NFs fail with an error code, or external NFs do not respond. Alternate destination can be chosen by using static configuration or by using DNS-SRV records. For more information about static and DNS-SRV configurations, see "Configurable Parameters for Alternate Route Service Configuration" in Oracle Communications Cloud Native Core, Converged Policy Installation, Upgrade and Fault Recovery Guide.

The following figure shows a scenario when egress gateway reaches the NF, but NF responds with an error code:

Figure 4-124 Egress Gateway get Error Response

To support this behavior, PCF provides the capability to perform DNS SRV Query. The DNS SRV Query discovers the NFs, such as NRF, SCP, and alternate producers. It also notifies consumers during failures to enable the retry mechanisms. This feature provides support to configure virtual FQDNs and adds capability to perform DNS SRV or local configuration Look up to retrieve alternate failover NFs which can be maintained dynamically at the DNS Server.

With SRV Records, you can configure and maintain NF FQDN dynamically at the DNS Server, which can be further selected by Policy, when there is a NF failure. This is achieved by performing a SRV query on the virtual FQDN configured at the Policy, rather than configuring primary and secondary NRF or SCP, statically in every Policy, only during instantiation time. This option of DNS lookup for SRV records would also provide alternate NFs to the Policy during failover.

Egress Gateway

Policy supports session retry functionality at Egress Gateway. When Egress Gateway receives HTTP error response based on the matching errorcriteria, there is retry of failed request through an alternate SCP based on the defined erroractionset. The errorcriteria defines matching HTTP methods, status codes, and causes (optional). The erroractionset defines number of reattempted counts and blacklist configurations. The respective errorcriteria and erroractionset should be mapped to the routesConfig.

The following sample shows the mapping of errorcriteria and erroractionset with routesConfig:

routesConfig:
 - id: scp_direct2
   uri: https://dummy.dontchange2
   path: /<Intended Path>/**
   order: 3
   metadata:
    httpsTargetOnly: false
    httpRuriOnly: false
    sbiRoutingEnabled: false
   filterName1:
     name: SbiRouting
     args:
       peerSetIdentifier: set0
       customPeerSelectorEnabled: false
       errorHandling:
        - errorCriteriaSet: scp_direct2_criteria_1
          actionSet: scp_direct2_action_1
          priority: 1
        - errorCriteriaSet: scp_direct2_criteria_0
          actionSet: scp_direct2_action_0
          priority: 2

- id: scp_direct2_criteria_1
    method:
      - GET
      - POST
      - PUT
      - DELETE
      - PATCH
    response:
      cause:
        ignoreCauseIfMissing: false      
        path: ".cause"
        reason:
         - "cause-1"
         - "cause-2"
      statuses:
        - statusSeries: 4xx
          status:
            - 400

- id: scp_direct2_action_0
   action: reroute
   attempts:2
   blackList:
    enabled: false
    duration: 60000

errorcriteria can also be configured only with the status code. Following is the sample:

sbiRoutingErrorCriteriaSets:  
 - id: scp_direct2_criteria_1
    method:
      - GET
      - POST
      - PUT
      - DELETE
      - PATCH
    response:
      statuses:
        - statusSeries: 4xx
          status:
            - 400
            - 404
        - statusSeries: 5xx
          status:
            - 500
            - 503

Following are the different use cases:

• When the HTTP response is received at the Egress Gateway only with the error code, then the error code is matched with the errorcriteriaset and rerouted to alternate SCP.
• When the HTTP response is received at the Egress Gateway with error code and error cause, then the error code and error cause is matched with the errorcriteriaset and rerouted to alternate SCP.
• When configured path is not found in the response and ignoreCauseIfMissing is true, then the response is received at Egress Gateway from SCP.
• When configured path is not found in the response and ignoreCauseIfMissing is false, then the response is sent back to Policy.
• When the cause is empty or null in the response body, errorcriteria is not considered as a match irrespective of ignoreCauseIfMissing is true or false and corresponding erroractionset is not executed.

For more information on configuration, see "SCP Configurations" in Oracle Communications Cloud Native Core, Converged Policy Installation, Upgrade, and Fault Recovery Guide.

The following diagram shows a scenario when the NF sends the error code and rerouting to alternate SCP is performed.

Figure 4-125 Session Retry at Egress Gateway

Policy sends the service request to the NF through SCP. When the NF sends the error code with cause to the Egress Gateway, the Egress Gateway compares the error code and error cause with errorcriteriaset. When it matches, it reroutes the request based on the erroractionset to the alternate SCP. If the maximum reattempts exhausts, the request is sent back to Policy.

Using Binding Headers, NFSets, and Server Headers

Policy supports session retry and alternate routing using Binding Headers, NFSets, and Server Headers.

When indirect communication model is selected without delegated discovery, when the target NFs throw errors, SCP performs the task of reselecting target NFs to perform service operations. The reselection of alternate target NFs is based on various considerations such as binding headers, NFSets, and server headers sent by the HTTP client or consumer. In certain scenarios, reselection is based on error response and server headers as well. This feature also determines the action for Policy when no retry is required and all attempts are exhausted by SCP.

Session Retry for Notifications on N7 Interfaces

Policy supports the session retry functionality for failed notifications over N7 interface. In case of a notification towards SMF fails, then the PCF sends an On-Demand discovery towards NRF based on the SetID received in the CREATE or UPDATE request from the SMF as part of the 3gpp-Sbi-Binding header. NRF performs a SetID based resolution and sends back a list of NFs under the same SetID. PCF selects the alternate SMF based on the configurations and sends the next notification.

Note:

The following conditions must be met for the Session Retry for Notifications functionality: :

• The NF Set Resolution configuration must be enabled. For more information about the configuration, see Managing Session Retry and Alternate Route Service.
• NF must send the Binding headers with nfSetid in the CREATE or UPDATE request.

The following diagram depicts an example call flow for retry notification from UDR to SMF:

Figure 4-126 On demand NF Discovery is enabled (NF Set Resolution is set to NRF Discovery)

The call flow is explained as follows:

1. SMF 1 sends an SM Create request with the notification URI towards UDR. The request binding header contains the NFSetID.
2. After successful processing of the request, UDR sends a notification to SMF 1 through PCF.
3. On notification failure, SMF 1 sends a notification failure response with the error code to PCF.
4. PCF checks the Retry Profile configurations and if the value for the NF Set Resolution parameter under the Retry Profile configurations in Policy is set to NRF Discovery, then it performs an on demand discovery with SetID through NRF and receives the list of SMFs with the same SetID as SMF 1.
5. PCF retries sending the notification to SMF 2 based on the NFSetID list and receives 200 Success response.

Managing Session Retry and Alternate Route Service

Enable

You can enable the Retry Profile and Alternate Routing functionality using the CNC Console or REST API for Policy.

• Enable using CNC Console: Enable the Retry on Internal Send Failure and Enable Alternate Routing parameters on the Retry Profile page. For more information about enabling the feature through CNC Console, see Retry Profiles.

  Retry Subscription Message enables the operator to choose Retry Logic for SUBSCRIBE/POST. For more information about retry subscription message, see PCF User Connector.

• Enable using REST API: Set the enableRetry and enableAlternateRouting parameter value to true in the Retry Profile configuration API. For more information about enabling the feature through REST API, see "Retry Profile" in Oracle Communications Cloud Native Core, Converged Policy REST Specification Guide.

Configure

You can configure the Retry Profile and Alternate Routing functionality using the CNC Console or REST API for Policy.

• Configure using CNC Console: Perform the feature configurations on the Retry Profile page. For more information about configuring audit service, see Retry Profiles.
• Configure using REST API: Policy provides the following REST API for Session Retry and Alternating Routing configuration:

  API: {apiRoot}/oc-cnpolicy-configuration/v1/services/common/retryprofiles

  You can perform the POST, PUT, or GET operations to configure the feature. For more information about REST API configuration, see "Retry Profile" in Oracle Communications Cloud Native Core, Converged Policy REST Specification Guide.

You can configure the parameter for alternate route service by updating the custom values file for Policy. For more information about configuring the parameter value, see "Alternate Route Service Configuration" in Oracle Communications Cloud Native Core, Converged Policy Installation, Upgrade and Fault Recovery Guide.

Observe

Policy provides the Alternate Routing request and response metrics in the User Services. For more information, see User Service Metrics.

4.66 Support for Honor retry-after Header in Egress Gateway

This section describes the retry-after header functionality in Egress Gateway. This header is received as a response, from the Egress gateway. Based on the header information, the producer data is collected to block the producer FQDN for the number of seconds mentioned in the retry-after header.

Initial Call for Producer FQDN

The following call flow describes the initial call to Egress Gateway from the Producer FQDN:

Figure 4-127 Initial CallS for Producer FQDNs

The initial call for producer FQDN is explained as follows:

1. The backend microservice or the consumer NF sends request to Egress Gateway.
2. The Egress Gateway verifies that the producer FQDN available in 3GPP SBI target apiroot header is not blocked.
3. Since, this is an initial request to Egress Gateway for the given producer, the producer FQDN is not blocked and the request is sent to the producer NF or SCP.
4. The producer NF or SCP sends a response to Egress Gateway.
5. If the response received by Egress Gateway is a configured error code, such as 503 or 429 for retry-after functionality, then the Egress Gateway cache the producer FQDN data to blocklist. It blocks the subsequent requests for the number of seconds mentioned in the retry-after header.
6. Egress Gateway sends a response to back end microservice or consumer NF that includes the retry-header.

Subsequent Call for Producer FQDN

The following call flow describes the subsequent call to Egress Gateway from the Producer FQDN:

Figure 4-128 Subsequent Calls for Producer FQDN

The subsequent call for producer FQDN is explained as follows:

1. The backend microservice or the consumer NF sends request to Egress Gateway.
2. The Egress Gateway verifies that the producer FQDN available in 3GPP SBI target apiroot header is not blocked.
   • If the producer FQDN available in 3gpp SBI target apiroot header is blocked, then the Egress Gateway responds back to the backend microservice or consumer NF with the configured returnErrorCode.
   • If the producer FQDN available in 3gpp SBI target apiroot header is not blocked, then the flow continues by sending request to producer NF / SCP.
3. The producer NF or SCP sends a response to Egress Gateway.
   • If the response received by Egress Gateway is a configured error code, such as 503 or 429 for retry-after functionality, then the Egress Gateway cache the producer FQDN data to blocklist. It blocks the subsequent requests for the number of seconds mentioned in the retry-after header.
   • If the response received by Egress Gateway does not have any configured error code, then no producer FQDN data is collected to be blocked.
4. Egress Gateway sends a response to backend microservice or consumer NF that includes the retry-header.

Managing Honor retry-after Header in Egress Gateway

Enable and Configure

To enable this feature in Policy, set the egress-gateway.retryAfter.enabled parameter to true under the egress-gateway configurations in the custom-values.yaml file for Policy.

Here is a sample configuration for this feature in custom-values.yaml file for Policy:

egress-gateway:
   retryAfter:
    enabled: true    
    errorCodesToLook: 429,503  
    #Provide error code with comma separated and no space 
    returnErrorCode: 425
    #Error code expected to be sent to Backend NF when 3gpp-Sbi-Target- 
    Apiroot header 
    is provided with producer and request route/path which is blacklisted
    in egress 
    gateway for a period mentioned in retry-after header
    blacklist-period: 0 #Seconds
    #This value is used when configured response code's are received from
    producer NF
    but retry-after header is absent. If retry-after value is configured
    with any
    value greater than 0 then it is considered in the absence of retryafter 
    header from   
    producer NF.

4.67 Stale Session Handling

Policy offers the signaling services such as, SM service, AM service, UE service, Binding Management service, Policy DS and, so on. These services are stateless in nature, thereby offloading session state to the centralized Oracle MySQL database (DB) for Policy.

As the session processing microservices and the DB are different components that communicate over a network, there are chances for certain transaction failures during transit. For example, failures can occur in overload situations or as a result of code bugs. To manage such failed transactions, Policy provides a database audit mechanism that monitors the stale records and clean them up to not exhaust the database memory. The audit mechanism also notifies the microservice about the stale records so that the service can trigger signaling messages, if required. The stale session handling functionality ensures that the stale sessions are released by the consumer NFs. If applicable, the feature also releases the associated sessions from the same or other NFs. For example, deleting a stale SM association may require to delete the associated PA sessions.

Note:

Policy supports the stale session handling for the following services:

• SM service
• AM service
• PCRF Core
• PDS
• Binding service
• UE Service
• Usage Monitoring Service

Feature Design

The following diagram provides a high level design for stale session handling through session state Audit service:

Figure 4-129 High Level Design for Stale Session Handling using Audit Service

As shown in the above diagram:

1. The Policy service registers as a consumer with the Audit service and starts auditing the service database.
2. When a stale record is detected, the Audit service takes any of the following actions as requested by the Policy service during the registration:
   • Deletes the stale records from the database.
   • Sends a notification to the service about the stale records.
   • Deletes the stale records from the database and notify the service.
3. The Audit service implements a minimum wait time between consecutive audits and the consecutive notifications for the same record.

   Note:

   • The Audit service stores the service registration details in the DB to be recovered after the pod restart or upgrade.
   • The audit service supports the local time zone.

Call Flow

Timeline View of Audit Service

The following figure shows a time line view of the Audit service for a record:

Figure 4-130 Timeline view of Audit Service

Stale Session Detection and Handling in SM Service

The following figure shows an example call flow of handling of stale session notification by the Policy SM service:

Figure 4-131 Example call flow for Stale Session Detection and Handling in SM Service

As shown in the call flow, after receiving a stale session notification from Audit service, SM service checks the maxTtl flag status and takes the following actions :

• If the maxTtl flag is TRUE then SM service triggers the TERMINATE action and deletes the record from the database.

• If the maxTtl flag is FALSE then SM service triggers another notification towards SMF to check if the particular SM association record exists with SMF:

  • If SMF responds with 204, No Content status code then SM will update the timestamp of the SM Association record.
  • Else if SMF responds with 404, Not Found status code then SM service triggers the TERMINATE action and deletes the record from the database..

Sending Terminate Notify to SMF

SM Service sends Terminate Notify to SMF when it detects and cleans up duplicate requests of SM PDU Session Create (Collision Detection) and stale SMPolicyAssociation (Max TTL reached for session).

When Audit service sends a notification to SM service that Max TTL has reached and if the value of AUDIT_SMPOLICY_ASSOCIATION.MAX_TTL.TERMINATE_NOTIFY.ENABLED advanced settings key is set to true, the details are deleted from the SMPolicyAssociation database. Also, a Terminate Notify is sent to SMF. SMF performs the appropriate action to remove the stale SMPolicyAssociation.

Also, when a newer session is received, SM service checks if the value of SYSTEM.COLLISION_DETECTION.TERMINATE_NOTIFY.ENABLED advanced settings key is set to true. It identifies the new session as duplicate and deletes the older session from SMPolicyAssociation database. Also, SM service sends a Terminate Notify to SMF.

For details on collision detection of duplicate Create session requests, see Detection and Handling of Late Arrival Requests.

Figure 4-132 Sample call flow for sending Terminate Notify when Max TTL notification is received from Audit service.

1. SM service receives a SM CREATE request from SMF through Ingress Gateway.
2. SM service sends a GET request to PDS to get the subscriber details from UDR, initiates a binding session request with Binding Service and then sends a request to PRE for policy evaluation. After the session is successfully created, SM services responds to SMF with 201 created message.
3. When the MaxTTL for the session is reached, the Audit service sends a MaxTTL Audit notification to SM service. SM service deletes the session details from its local SMPolicyAssociation database and then sends a Terminate Notify message to SMF through Egress Gateway.
4. After deleting the details of the older session, SMF responds to SM service with 204 No Content message.

Stale Session Detection and Handling in UE Service

A UE Policy Association on PCF is considered as stale when the association exists in PCF, but has no corresponding session on the AMF.

When a UE Policy Association is detected as stale, the UE service deletes the association from the database.

Figure 4-133 Example call flow for Stale Session Detection and Handling in UE Service

As shown in the call flow, after receiving a stale session notification from Audit service, UE service checks the status of maxTtlReached and queryAMF flags and takes the following actions:

• If the maxTtlReached flag is TRUE, the UE service triggers the TERMINATE action and deletes the record from the database.

• If the maxTtlReached flag is FALSE and queryAMF flag is TRUE, the UE Service sends the stale session notification to AMF via the Egress Gateway to check whether this particular UE Association record exists with AMF.

  The AMF replies with a stale session notification response to UE service.

  • If the stale session notification response includes a 404 Not Found status code, the UE Service triggers the TERMINATE action and deletes the record from the database.
  • If the stale session notification response includes a 204 No Content status code, the UE Service updates the timestamp of the UE Association record in the database.

  If either AMF does not respond, or is not reachable, no action is taken until maxTtlReached is reached.

• If the maxTtlReached flag is FALSE and queryAMF flag is FALSE, the UE Service triggers the TERMINATE action and deletes the record from the database.

Stale Session Detection and Handling in AM Service

Figure 4-134 Example call flow for Stale Session Detection and Handling in AM Service:

.

As shown in the call flow, after receiving a stale session notification from Audit service, AM service checks the maxTtl flag status and takes the following actions:

• If the maxTtl flag is TRUE then AM service will trigger it's TERMINATE leg.
• If the maxTtl flag is FALSE then AM Service will check the status of queryAMF flag.
• If queryAMF flag is set to true AM Service will trigger another notification towards AMF to check whether this particular AM Association record exists with AMF or not.
• If AMF responds with 204 No Content status code then AM will update the timestamp of the AM Association record.
• Else if AMF responds with 404 Not Found status code then AM Service will trigger its TERMINATE leg.
• Otherwise, if queryAMF flag is set to false then AM service will trigger it's TERMINATE leg.

Stale Session Detection and Handling in PCRF Core Service

Figure 4-135 Example call flow for Stale Session Detection and Handling in PCRF Core Service

Audit service audits the Gx sessions, Rx sessions and Sd sessions.

Note:

PDS takes care of cleaning the Sy sessions.

Depending on the status of maxTTL flag, the Audit service send the notification to PCRF Core and initiates the stale session cleanup activity.

• For Rx session: If the maxTTL flag is TRUE, Rx sessions are cleaned.

  Note:

  The cleanup functionality is not implemented for Rx sessions, if the maxTTL flag is false.
• For Gx session:
  • DIAMETER.Cleanup.OverrideCleanupAudit Advance settings key will also be checked along with maxTTL flag.
  • If both maxTTL and DIAMETER.Cleanup.OverrideCleanupAudit are TRUE, the Gx sessions are cleaned without querying the PGW. Dependent Rx sessions will also be deleted as part for cleanup.
  • If the maxTTL flag is FALSE,
    • pcrf-core service will trigger notification towards PGW to check whether this particular Diameter Session exists in the PGW or not.
    • If PGW responds with 2001 DIAMETER_SUCCESS then pcrf-core will update the timestamp of the diameter session record.
    • Else, if PGW responds with 5002 DIAMETER_UNKNOWN_SESSION_ID then pcrf-core Service will trigger its TERMINATE (CCR-T) leg.
• For Sd session: If the maxTTL flag is TRUE then Sd sessions are cleaned.

Stale Session Detection and Handling in Binding Service

Figure 4-136 Example call flow for Stale Session Detection and Handling in Binding Service

Audit Service uses the lastAuditedTime to check the staleness of the record.

1. For every Minimum Audit Passes Interval (frequency), Audit Service queries the database to get all the records that are older than the defined TTl.
2. If the records older than TTl have not yet reached MaxTTl, the Audit Service sends a audit notification to Binding Service with maxTTl=false. The Binding Service validates the staleness of the record with the contextOwner by sending request to core services.
   1. If the ContextOwner, has a valid session (Status code 200) - the binding service updates the lastAuditedTimestamp.
   2. Else, if the ContextOwner, does not have a valid session (Status code 404 from PCM-SM, 204 from PCRF-Core) - the Binding service deregisters the session as mentioned in the point 3.
3. If the records older than TTl and have reached MaxTTl, but not yet reached maxTTLforceInterval, the Audit Service sends a stale session notification to Binding Service.

   In case of ContextBinding, the Binding Service sends a deregister request to BSF, deletes the record in the Binding Service database and marks the dependent session (if any) as stale.

   In case of dependentcontextbinding, deletes the record from Binding Service database.

4. If the records older than the TTl and have reached MaxTTl, as well as maxTTLforceInterval, the Audit Service deletes the records in binding tables directly and no notification is sent.

Note:

maxTTLforceInterval is configurable from deployment file of audit service. The Default value is of maxTTLforceInterval is 3 days (259200 seconds).

Stale Session Detection and Handling in Usage Monitoring Service

Usage Monitoring service identifies the stale sessions based on lastAccessTime.

Figure 4-137 Example call flow for Stale Session Detection and Handling in Usage Monitoring Service

1. The Usage Monitoring service sends register/de-register request to Audit service and takes necessary action on notifications received from Audit service.

2. Usage Monitoring service receives stale UM session notification from Audit service.

3. Usage Monitoring service checks the status of maxTTL flag.

4. If the value of maxTTL flag is TRUE, Usage Monitoring service initiates a UM session TERMINATE request for the oldest session to PDS to delete the session from UMContext database.

   Usage Monitoring service deletes the record from its UmContext database only when it is the last session for that record.

5. Usage Monitoring service sends a GET request to PCRF Core to check if the Usage Monitoring session exists with PCRF Core service.

6. If PCRF Core service responds with 2xx status code, the Usage Monitoring service updates the timestamp of the Usage Monitoring session for that subscriber, updates the lastAccessTime with the oldest session timestamp and resets the value of Minimum Audit Attempt field to 0.
7. If PCRF Core service responds with 404 Not Found status code and the MaxTTL is expired, the Usage Montoring service triggers TERMINATE and also sends a DELETE request to PDS.
8. If PCRF Core service responds with 4xx/5xx , except 404 , the Usage Monitoring service increaments the value of Minimum Audit Attempt count in the database.
9. Also, Usage Monitoring service sends a DELETE request to PDS, which in turn sends a DELETE request to UDR through UDR Connector to delete the subscription.

If forceTTL is triggered from Audit service, Audit service will delete the entire subscriber entry from Usage Monitoring (UMContext) database. Usage Monitoring service will not send the TERMINATE and unsubscribe request in that case.

For example, when there is a Usage Monitoring session for a subscriber that is qualified for forceTTL and the session is stale. In the interim, if Usage Monitoring service receives a new session with a different AVP for the same subscriber prior to the forceTTL being triggered, even then Audit service deletes the entire record for the subscriber.

Managing Stale Session Handling

Enable

You can enable the Stale Session Handling functionality using the CNC Console or REST API for Policy.

• Enable using CNC Console: To enable this feature, set the Audit Enabled parameter value to true on the Audit Service page. For more information about enabling the feature through CNC Console, see Audit Service.

• Enable using REST API: Set the auditEnabled parameter value to true in the Audit Service configuration API. For more information about enabling the feature through REST API, see "Audit Service" in Oracle Communications Converged Policy REST API Specification Guide.

Configure

You can configure the Stale Session Handling functionality using the CNC Console or REST API for Policy.

• Configure using CNC Console: To configure stale session handling feature for various services, perform the feature configurations under the Audit group on the respective service configurations page. For more information, see the following sections:
  • PCF Session Management
  • PCF Access and Mobility
  • Settings (for PCRF Core)
  • PDS Settings
  • PCF UE Policy Service
  • Configuring Usage Monitoring
  .
• Configure using REST API: Policy provides the following REST API for Stale Session Handling configuration:

  SM service: {apiRoot}/oc-cnpolicy-configuration/v1/services/pcfsm

  AM service: {apiRoot}/oc-cnpolicy-configuration/v1/services/pcfam

  PCRF Core: {apiRoot}/oc-cnpolicy-configuration/v1/services/pcrfcore/settings

  PDS: {apiRoot}/oc-cnpolicy-configuration/v1/services/pds/pdsSettings

  UE service: ​{apiRoot}/oc-cnpolicy-configuration/v1/services/pcfue

  You can perform the PUT operation to configure the feature. For more information about REST API configuration, see Oracle Communications Cloud Native Core, Converged Policy REST Specification Guide.

• Usage Monitoring service: {apiRoot}/oc-cnpolicy-configuration/v1/services/pcfum

Observe

Policy provides metrics and alerts specific to Audit Service. For information related to Audit Service metrics, see Audit Service Metrics.

Maintain

The Stale Session Handling functionality provides audit logging. At the end of each audit pass, an audit log is published on the Grafana dashboard with the following details of the pass:

• Database and Table audited
• Number of records found to be stale
• Number of records removed (for the DELETE action)
• Number of notifications sent (for the NOTIFY action)
• Time taken to complete the audit pass
• Any exceptions occurred

The following is a sample of the audit report for SM service:

Audit Report {
"database" : "pcf_smservice_161",
"table" : "SmPolicyAssociation",
"staleRecords" : 18869,
"recordsDeleted" : 0,
"timeToCompletePass" : 20,
"recordsEnqueuedForNotification" : 18869,
"exceptions" : [ ]
}

The following is a sample of the audit report for PDS:

Audit Report:
{
 	"database" : "occnp_policyds",
 	"table" :  "pdssubscriber", 
 	"staleRecords" : 1,
 	"recordsDeleted" : 0,
 	"timeToCompletePass" : 0,
 	"recordsEnqueuedForNotification" : 1,
 	"exceptions" : [ ]
 } 
Audit Report:
 {
	"database " :  "occnp_policyds ",
	"table " :  "pdsprofile ", 
	"staleRecords " : 1, 
	"recordsDeleted " : 0, 
	"timeToCompletePass " : 0,
	"recordsEnqueuedForNotification " : 1,
	"exceptions " : [ ]
}

The following is a sample of the audit report for UE Service:

4.68 Support for 3GPP NF Sets and Binding Headers

Policy supports the 3GPP NF Sets and binding headers in Model-B (Direct communication) and Model-C (Indirect communication). The support for 3GPP NF Sets and binding headers allows Policy to use the related headers and attributes for successful call processing.

Note:

PCF can act both as an HTTP Server and HTTP Client.

NF Set: NF set is a group of interchangeable NF instances supporting similar services and network slices. In an NF set, the NF instances can be geographically distributed, but have access to the same context data. The NF instances can be deployed in such a pattern so that several instances are present within an NF set to provide distribution, redundancy, and scalability as a set. The NF instances of an NF set are equivalent and share the same MCC, MNC, NID (for SNPN), NF type, and NF Set ID.

Binding headers: The binding headers indicate the suitable target NF producer instance for NF service instance selection, reselection, and routing of subsequent requests associated with a specific NF producer resource or context. It allows the NF producer to indicate that the NF consumer, for a particular context, must be bound to an NF service instance, or NF set depending on local policies. Binding can also be used by the NF consumer to indicate the suitable NF consumer instances for notification target instance reselection and routing of subsequent notification requests, associated with a specific notification subscription.

PCF as a consumer sends binding headers to producer NFs such as UDR, CHF, BSF (customized), and AMF during explicit subscription. When Send PCF Service Name in Binding Header field under NF Communication Profiles page on CNC Console is enabled, the binding header includes servname along with other details such as nfinst and nfset.

When a notification request from any of the producer NFs such as UDR, CHF, BSF (customized), or AMF to PCF fails, the producer NFs use the details in the binding header to select alternate PCF. Using the service name included in the binding header, producer NFs can select alternate PCF with service level details.

Whenever there is an update in binding level and value, PCF includes the service name in the updated binding header sent to producers in Subscription Update or Notification Response.

Also, PCF sends binding header with scope as callback.

Support for N1N2 Message Transfer

PCF allows to configure sending of the binding header, routing binding header and the discovery header for N1N2 transfer using the below mentioned fields available under AMF group in PCF UE Policy Service page on CNC Console.

• Send SBI Binding Header For N1N2 Transfer Requests
• Send Routing Binding Header For N1N2 Transfer Requests
• Send Discovery Header For N1N2 Transfer Requests

Whenever there is a change in the binding information, UE Policy service sends the SBI binding in the transfer message. It can be configured whether N1N2Transfer must be sent with routing binding header or discovery header.

For N1N2 transfer requests UE Policy service sends the binding header as N1N2 transfer contains the implicit subscription for N1N2 failure notification.

• When NFSet and binding feature is enabled, PCF sends binding header in N1N2Transfer request at NFSet or NFInstance level, as configured by user.

  The user can configure to send SBI binding header for N1N2 Transfer requests by selecting one of the following values for Send SBI Binding Header For N1N2 Transfer Requests field:

  • When binding information changes: To send the binding header in the HTTP request only whenever there is a change in the binding information.
  • Always: To send the binding header in all the N1N2 Transfer requests.
  • Never: Not to send the binding header in any of the N1N2 Transfer requests.

  This configuration will override the values being set towards NF Communication Profile under Non-access stratum (NAS).

  Note:

  The NF Communication Profile for NAS is mandatory to be set in UE service configuration.

• The user can configure to send the routing binding header in N1N2Transfer requests by selectiing one of the following values for Send Routing Binding Header For N1N2 Transfer Requests field.

  • Always: To send the routing binding header in all the N1N2 Transfer requests.
  • Never: Not to send the routing binding header in any of the N1N2 Transfer requests.

• The binding header includes the discovery header when the N1N2 message transfer does not include the routing binding information. That is, UE Policy service adds 3gpp-Sbi-Discovery-target-nf-set-id when 3gpp-Sbi-Routing-Binding is not included in the binding information.

  The user can configure to send the discovery header in N1N2Transfer requests by selecting one of the following values for Send Discovery Header For N1N2 Transfer Requests field when the routing binding header is not present. This configuration is applicable to retransmissions as well.

  • Always: To send the discovery header in all the N1N2 Transfer requests when the routing binding header is not present.
  • Never: Not to send the discovery header in any of the N1N2 Transfer requests.

  For more details on how to configure the binding header, routing binding header, and discovery header for N1N2Transfer, see PCF UE Policy Service.

  Note:

  It can be configured to include 3gpp-Sbi-Discovery-target-header in N1N2Transfer request explicitly and not in any other subsequent messages to AMF like Unsubscription of N1N2Subscription.

Table 4-94 Supported Headers

Header Name	Description
3gpp-Sbi-Binding	This header is used to communicate the binding information from an HTTP server for storage and subsequent use by an HTTP client. This header contains a comma-delimited list of Binding Indications from an HTTP server for storage and use of HTTP clients. The absence of this parameter in a Binding Indication in a service request is interpreted as "callback".
3gpp-Sbi-Callback	This header indicates if a HTTP request is a callback. For example, Notifications. This header is included in HTTP POST messages to request notifications or callbacks towards NF service consumers in indirect communication. This header is used by the SCP to differentiate the notification and callback requests from other service requests. For example, the authorization (access token is not used in notification or callback. This header contains the type of notification and the name of the notify service operation.
3gpp-Sbi-Discovery-*	The discovery parameter can be set using the CNC Console for Policy or the Policy REST API. The headers beginning with the prefix 3gpp-Sbi-Discovery-, are used in indirect communication mode for discovery and selection of a suitable producer by the SCP. Such headers can be included in any SBI message and include information that allows an SCP to find a suitable producer, according to the delegated discovery parameters provided by the consumer. The name of each NF service discovery factors header are constructed by concatenating the string 3gpp-Sbi-Discovery- with the name of the conveyed discovery parameter. For example, 3gpp-Sbi-Discovery-<discovery parameter>. Policy supports the target-nf-set-id discovery parameter. Thus, the supported discovery header is 3gpp-Sbi-Discovery-target-nf-set-id.
3gpp-Sbi-Routing-Binding	This header is used in a service request to send the binding information (3gpp-Sbi-Binding header) to direct the service request to an HTTP server, which has the targeted NF Service Resource context. This header enables alternate routing for subsequent requests at SCP. It contains a routing binding Indication to direct a service request to an HTTP server, which has the targeted NF service resource context.

Policy supports the NF Set and binding header functionality in SM, AM, UE, and PA function interfaces. You can configure NF communication profiles for the following PCF interfaces:

• N7/Npcf interface for notifications towards SMF
• N36/Nudr for requests and responses towards UDR
• N28/Nchf for requests and responses towards CHF
• Nbsf interface towards BSF
• N15/Namf interface for notifications towards AMF
• Npcf interface for notifications towards UE
• Npcf interface for notifications towards PA

You can configure the PCF to support binding header on the selected interface either as an HTTP client or server. If PCF is not configured to support the binding header for an interface, then it ignores the binding header and the information.

Example

The following diagram depicts an example of indirect communication between PCF and other NF, based on NF set and binding header:

Figure 4-138 Example of NF Set and Binding Header based Indirect Communication

The above architecture diagram describes a scenario of indirect communication between PCF and UDR. The PCF acts as an HTTP Client and UDR is the HTTP server. SCP acts as the HTTP proxy that redirects the requests coming from PCF.

In indirect communication, PCF sends the HTTP requests and the binding indication headers to SCP. The request contains the following details:

• 3gpp-Sbi-Target-Apiroot: The target API root that indicates the destination NF endpoint (Target UDR instance).
• 3gpp-Sbi-Discovery header: Contains information about the NF Set of the destination UDR instance. This header is used by SCP in case the first message does not reach the original UDR instance.
• 3gpp-Sbi-Routing-Binding: In case of an insertion request, PCF sends this header. It contains the routing binding indication to direct a subsequent service request to UDR.
• 3gpp-Sbi-Binding (PCF): Contains the NF Set information of PCF. This header is sent by PCF with request message and stored by UDR for subsequent communication.
• 3gpp-Sbi-Binding (UDR): Contains the NF Set information of UDR in the response mesage. This header is sent by UDR in response message and stored by PCF for subsequent communication.

Once the HTTP request is received at SCP, it is then redirected towards the NF instance indicated in the API root. In case of any failure, SCP redirects the request to an alternate destination belonging to the same NF set or a different NF set, as indicated in the 3gpp-Sbi-Binding header.

The values can be set while configuring NF Communication Profile through CNC Console for Policy or REST APIs.

Support for Rerouting Notification from External NFs to Alternate PCF When the Notification Request Fails

PCF supports including the service name in the binding header sent to NFs such as UDR, CHF, AMF, and BSF (customized) when Send PCF Service Name in Binding Header parameter in the NF Communication Profile page is enabled.

The servname parameter in the binding header contains the name of the 3GPP defined PCF service (or aggregate service name applicable only towards CHF), which is invoking the Subscribe request or handling the notification. Invoking or Handler service name to be sent in the binding header is internally identified by PCF for UDR,AMF, and BSF interfaces and no external configuration is required except for the binding header sent towards CHF where the service name to be sent in the binding header is defined using CNC Console for Policy.

For example, the explicit Subscribe request sent towards nUDR on SM Create request for SM data contains servname= npcf-smpolicycontrol in the binding header as SM service is the handler service here.

Below is a sample Binding Header:

3gpp-Sbi-Binding: bl=nf-instance; nfinst=54804518-4191-46b3-955c-ac631f953ed8; nfset=set1.pcfset.5gc.mnc012.mcc345; scope=callback;servname= npcf-smpolicycontrol;

The service name to be forwarded in the binding header sent towards CHF is configured based on the value of PCF Service name in Binding header parameter under CHF group in PCF User Connector page under Service Configurations. The service name in the binding header sent to CHF contains:

• 3GPP defined PCF Service name: As PCF requests the policy counter information from CHF only once and can share with other services, PCF can contain the service name of the first service (for example, npcf-am-policy-control), which is requesting policy counter information from CHF. The service level information such as scheme and port that the first service can be used to represent other services in the same PCF deployment as subsequent notifications from CHF will be consumed by all the services which is sharing the data.

  Below is a sample binding header with 3GPP defined PCF service name sent towards CHF:

  3gpp-Sbi-Binding: bl=nf-instance; nfinst=54804518-4191-46b3-955c-ac631f953ed8; nfset=set1.pcfset.5gc.mnc012.mcc345; scope=callback;servname= npcf-am-policy-control;

• Aggregate/custom service name representing a group of PCF services with aggregated service level information.

  As PCF (PCF1) requests the policy counter information from CHF only once and can share with other services, PCF can contain aggegrate service name approach for sending servname in the binding header. The aggegrate service level information is used to represent group of service with aggegrate service name.

  For example, npcf-custom-service can represent npcf-am-policy-control, npcf-smpolicycontrol, and npcf-ue-policy-control.

  Below is a sample binding header with aggregate/custom service name sent towards CHF:

  3gpp-Sbi-Binding: bl=nf-instance; nfinst=54804518-4191-46b3-955c-ac631f953ed8; nfset=set1.pcfset.5gc.mnc012.mcc345; scope=callback;servname= npcf-custom-service;

  Note:

  Before defining the aggregate/custom service name towards CHF, it is mandatory to register this custom service having aggregated service level information while doing PCF registration with NRF.

Call flow for rerouting a notification message from UDR to an alternate PCF using service name in Binding Header

Here is a sample call flow that depicts rerouting a notification message from UDR to an alternate PCF using service name in the binding header when the NOTIFICATION request from UDR fails to reach PCF.

1. An instance of PCF, PCF1 receives the binding indication header and the discovery header in an SM Policy Control Create request from SMF (Consumer NF).
2. PCF1 queries UDR to get the corresponding SM Policy Data.
3. UDR sends a 200 ok message to PCF1.
4. Also, PCF1 sends the binding header and discovery header (3gpp-Sbi-Binding) in the Subscription request to UDR that includes svcname along with other parameters such as nfinst and nfset. UDR saves this binding information in its database, which will be used while sending any notification from UDR to PCF1.
5. When an update notification from UDR to PCF1 fails with a 500 internal server error, UDR identifies an alternate PCF2 using the service name provided by PCF in the previous binding header.
6. UDR reroutes the notification message to PCF2 and receives a response.

Support for Binding Header and Routing Binding Header in N1N2Transfer Request

Here is a sample UE Policy create call flow depicting Binding Header in N1N2Transfer request.

1. UE Policy service periodically polls the NRF through NRF client to fetch the updated NF profile.
2. Whenever UE Policy service receives a create request from AMF, it queries the UEPolicy Association database to fetch the UE Policy association details.
3. UE Policy service queries the UDR to fetch the user profile.
4. UE Policy service sends a request with the given details to PRE for Policy evaluation.
5. UE Policy service sends a request to NRF through NRF Client to discover the NF instances using amf-set-id and amf-region-id.
6. UE Policy service saves the updated UE Policy Session details in the UEPolicy Association database.
7. UE Policy service responds to AMF with a successful message.
8. UE Policy service sends a subscription request to nAMF for N1N2 message transfer and receives a response.
9. UE Policy service sends N1N2 message Transfer(with added SBI Binding/Routing/Discovery Header) to nAMF for N1N2 message transfer, which in-turn forwards the details to the UE.
10. Whenever the UE Policy service receives an N1N2 notification of type ManageUePolicyComplete/ManageUePolicyCommandReject from nAMF, the UE Policy service tries to retransmit the message to nAMF.
11. Asynchronously, the UE Policy service contacts the PDF to fetach the Spending Limit data.
12. PDS contacts CHF through CHF Connector to subscribe for the policy counters.
13. After receiving the information from CHF, PDS sends a notification to UE Policy service with the SpendingLimit data.
14. UE Policy service processes this information and if needed it sends an update notify to AMF service and also saves the details in UEPolicy Association database.

Managing NF Sets and Binding Header Support

Enable and Configure

The NF Sets and Binding header support can be enabled for SM, AM, UE, and PA service interfaces. An NF communication profile must be configured and assigned to the respective interface to enable this feature.

You can enable and configure the NF Communication Profiles using the CNC Console or REST API for Policy.

• Configure using CNC Console: Perform the feature configurations under:
  • NF Communication Profiles page under Common Data for Service Configurations. For more details, see NF Communication Profiles
  • AMF group in PCF UE Policy page for Service Configurations. For more details, see PCF UE Policy Service.
  • Configure NF Communication Profile parameter for each of the services. For details, see:
    • PCF Session Management
    • PCF Access and Mobility
    • PCF Policy Authorization
    • Binding Service
    • PCF UE Policy Service
  • Configure the parameters under UDR and CHF groups under PCF User Connector. For more details, see PCF User Connector.
• Configure using REST API: Perform the NF Communication Profile configurations under the following REST APIs:
  • {apiRoot}/oc-cnpolicy-configuration/v1/services/common/nfcommprofiles
  • {apiRoot}/oc-cnpolicy-configuration/v1/services/pcfsm
  • {apiRoot}/oc-cnpolicy-configuration/v1/services/pcfam
  • {apiRoot}/oc-cnpolicy-configuration/v1/services/pcfpa
  • {apiRoot}/oc-cnpolicy-configuration/v1/services/pcfue
  • {apiRoot}/oc-cnpolicy-configuration/v1/services/binding
  • {apiRoot}/oc-cnpolicy-configuration/v1/services/pcfuser

  You can perform the POST, PUT, or GET operations to configure the feature. For more information about REST API configuration, see Oracle Communications Cloud Native Core, Converged Policy REST Specification Guide.

Observe

Policy uses the Ingress and Egress metrics for the NF bindings used by PCF. The following metrics contains the information about NF bindings used by PCF:

• For SM, PA, AM, UE, and Binding service:
  • ocpm_ingress_response_total
  • ocpm_egress_request_total
• For UDR Connector service: ocpm_udr_tracking_request_total
• For CHF Connector service: ocpm_chf_tracking_request_total

For more information, see the following sections:

• SM Service Metrics
• User Service Metrics

Maintain

The Policy logs includes the NF binding information received or sent by PCF. The logs include information about the following headers:

• location
• 3gpp-sbi-target-apiroot
• 3gpp-sbi-binding
• 3gpp-sbi-routing-binding
• 3gpp-Sbi-Discovery-target-nf-set-id
• 3gpp-sbi-callback

4.69 Georedundancy Support

The Cloud Native Core architecture supports Geographical Redundant (Georedundant) Policy (PCF, PCRF, and converged Policy) deployments to ensure high availability and redundancy. It offers a two, three, or four-sites georedundancy to ensure service availability when one of the Policy sites is down.

The specifications for georedundancy feature are as follows:

• All the georedundant sites must have helm and REST based configurations except NF Instanced Id, Policy Endpoint, and port.
• The georedundant Policy sites must be reachable from NFs or Peers on all the sites.
• The same NFs or Peers must not communicate to other georedundant Policy sites at the same time for the same session.
• When Policy is deployed as georedundant PCF instances, then:
  • All the sites register with NRF independently and works in active state.
  • All Policy instances share the Session State data by using the replication service of DB tier. This enables service continuity during failure of any of the site.
  • The NFs in a given site can discover Policy instances through NRF. However, local configurations, such as DNS SRV or static configuration are required to determine the primary and secondary or alternate Policy configuration. When the primary instance is available, the NFs send service requests to the primary instance.
  • NRF always reflects current functional status of a given PCF or BSF instance. Thus, during failure of a given PCF or BSF instance, the value of NfStatus is updated to SUSPENDED by either NRF or PCF or BSF instance. Therefore, when NF detects failure of primary instance due to error response or status notification from NRF, the NF redirects its traffic to the secondary instance, while the primary instance remains unavailable and until it becomes available again.
• When Policy is deployed as georedundant PCRF instances, then:
  • All the sites works in active state.
  • All instances share "Session State" data using DB tier's replication service to enable service continuity during site failure.
  • When peer detects failure of primary instance, the peer redirects its traffic to the secondary instance while the primary instance remains unavailable and until it becomes available again.

Policy supports the following types of georedundant deployment:

Two-Site Georedundancy Deployment

The following diagram depicts the topology for two-site georedundant PCF deployment:

Figure 4-139 Two-Site Georedundancy Deployment

The two-site georedundancy is established, when the second site instance of the cnDBTier is created. The DB Tier provides bi-directional replication between both the sites. When the two-sites are correctly replicated, then any update done at one site is replicated to the other remote site in real-time. The changes include creating, changing, or deleting a record.

Three-Site Georedundancy Deployment

The following diagram depicts the topology for three-site georedundant PCF deployment:

Figure 4-140 Three-Site Georedundancy Deployment

In case of three-site georedundancy, bi-directional replication is established from each site to the two other sites. The database updates from each site are replicated to the other two-sites over the replication channel.

The advantages of three-site georedundancy is:

• In case of a single site failure, the remaining two-sites keep establishing the bi-directional replication.
• No action is required in case of a site failure.
• Requires 4 SQL pods and 2 replicated svc (db-rep-svc) at each site

When the three-sites are correctly replicated, then any update done at one site is replicated to the other two remote sites in real-time. The changes include creating, changing, or deleting a record.

Four-Site Georedundancy Deployment

The following diagram depicts the topology for four-site georedundant PCF deployment:

Figure 4-141 Four-Site Georedundancy Deployment

cnDBTier supports the four-site georedundancy deployment. In case of four-site georedundancy, each site participates in a 4-way replication. The database updates from each site are replicated to the other three-sites over the replication channels.

The advantages of four-site georedundancy is:

• In case of a single site failure, the remaining three-sites keep establishing the bi-directional replication.
• No action is required in case of a site failure.
• Requires 6 SQL pods and 3 db-rep-svc at each site.
• Each site uses two SQL nodes for active and standby replication channels for high availability of the replication channels.

When the four-sites are correctly replicated, then any update done at one site is replicated to the other three remote sites in real-time. The changes include creating, changing, or deleting a record.

Managing Georedundancy

Deploy

To deploy Policy in a georedundant environment:

1. Set up the replicated cnDBTier version 1.8.0.0.3 or above, on two or three-sites, as required. For information about installing cnDBTier, see "Installing cnDBTier" in Oracle Communications Cloud Native Core, cnDBTier Installation, Upgrade and Fault Recovery Guide.
2. Deploy Policy over the replicated (two or three) cnDBTier sites. For information about installing and deploying Policy, see Oracle Communications Cloud Native Core, Converged Policy Installation, Upgrade and Fault Recovery Guide.

Configure

To configure georedundancy:

You need to configure the georedundancy functionality while deploying the Policy instances on the replicated sites. The following parameters must be updated in the custom values file for Policy:

Table 4-95 Georedundancy Parameters

Parameter	Description
global.envMysqlHost	The database instance for each site. PCF communicates to the database at the same site only.
global.nfInstanceId	The ID for the site
config-server.envMysqlDatabase	The database for the config server. The two-sites should use different database names for config server
cm-service.envCommonConfigMysqlDatabase	The common configuration database. It should be different on the sites
nrf-client.configmapApplicationConfig.profile	Configuration data for nrf client. The appProfile and the nfInstanceId parameters must be aligned with global.nfInstanceId
nrf-client-nfdiscovery.dbConfig.dbName	The common configuration database. It should be different on the sites
nrf-client-nfmanagement.dbConfig.dbName	The common configuration database. It should be different on the sites
appinfo.dbConfig.dbName	The common configuration database. It should be different on the sites
perf-info.dbConfig.dbName	The common configuration database. It should be different on the sites
policyds.envMysqlDatabaseConfigServer	The database for the config server. The two-sites should use different database names for config server
ingress-gateway.dbConfig.dbName	The common configuration database for ingress gateway. It should be different on the sites
egress-gateway.dbConfig.dbName	The common configuration database for egress gateway. It should be different on the sites
alternate-route.dbConfig.dbName	The common configuration database for alternate route. It should be different on the sites

For more information about configuring the parameter value, see "Alternate Route Service Configuration" in Oracle Communications Cloud Native Core, Converged Policy Installation, Upgrade and Fault Recovery Guide.

Observe

cnDBTier generates critical alerts in case of application or database failure. For more information, see Oracle Communications Cloud Native Core, cnDBTier User's Guide.

Maintain

Policy allows you to monitor the georedundancy deployment through cnDBTier alerts. Access the Prometheus GUI to check for new App alerts.

4.70 Diameter Pod Congestion Control

The Diameter Gateway is a diameter proxy agent for Policy. Being a front-end microservice for diameter traffic for both Ingress Gateway and Egress Gateway, the Diameter Gateway can get congested due to higher traffic and higher CPU usage. Thus, it is imperative to have suitable congestion control features in place for Diameter Gateway pods to avoid adverse impact on latency and performance. Another reason for the need of congestion control mechanism for Diameter Gateway is the nature of diameter connections. These connections are long lived and are distributed by external LoadBalancer. As shown in the following image, when LoadBalancer routes an incoming request from network to Diameter Gateway pod, it does not take into account health or load of the pod. As a result, uneven distribution of traffic may happen and gateway pods experience congestion.

Congestion control helps to identify such conditions and invoke load shedding rules to address these situations when these load conditions persist. With Diameter Gateway service supporting the congestion control mechanism feature, it helps to protects its pods from congestion and ensures consistent service availability to its consumer.

The pod congestion control mechanism involves:

1. Determining Pod Congestion State
2. Triggering Pod Congestion Control

Determining Pod Congestion State

At any given point of time, a pod can be in any one of the following states:

• Normal
• Danger of Congestion (DOC)
• CONGESTION_L1
• CONGESTION_L2
• CONGESTED

Figure 4-142 Different Pod Congestion States

To decide the state of a pod, the following points are taken into consideration:

1. CPU: The CPU usage for congestion state is calculated by comparing the CPU usage of the container (monitored using cgroup parameter, cpuacct.usage, which provides current cpu usage in nanoseconds) with the configured threshold.
2. Queue: For the DOC, CONGESTION_L1, CONGESTION_L2, and CONGESTED pod states, compare the number of pending messages in the queue with the configured pending messages threshold.

To avoid switching between these states due to traffic pattern, it is required for the pod to be in a particular state for a given period before transitioning to another state. Periodically, the state of the pod's congestion gets determined. The following configurations are used to define the period that the pod has to be in a particular state for:

• stateChangeSampleCount: This specifies after how many continuous intervals, the pod state can be changed. The default value is 5. This value can range from 1 to 2147483647. This parameter can be configured to using Policy CNC Console or REST API.
• stateCalculationInterval: This specifies the time duration or interval, after which the pod congestion state will be re-verified. The default value is 200ms. This interval is configured in milliseconds and can range from 50 to 2147483647. This parameter can be configured to using Policy CNC Console or REST API.

For more information about these congestion control configurations, see Congestion Control Settings section in CNC Console.

CPU and Queue Threshold

A pod's state changes when its resources, namely the CPU and Queue buffer usage exceeds the predefined congestion threshold, checked at regular intervals. An active CPU and Queue default threshold profile can be viewed using CNC Console at Policy → Overload and Congestion Control → Congestion Control → Thresholds section. The user can create new threshold profile with the congestion states being in the order of CONGESTED → CONGESTION_L1 → CONGESTION_L2 → CONGESTED states, and make it active. The Diameter Gateway service pod's congestion states and their default congestion parameters, CPU, and Queue counts are provided in the following table:

Table 4-96 Diameter Gateway service Congestion States

Congestion States	CPU Count	Queue (Pending Request)
DANGER_OF_CONGESTION (DOC)	60	6300
CONGESTION_L1	70	7200
CONGESTION_L2	75	8100
CONGESTED	80	9000

For more information about these CPU and Queue count thresholds configurations, see Congestion Control Thresholds section in CNC Console.

Triggering Congestion Control

With Congestion Control feature enabled, every time a message is fetched for processing, the system checks the current congestion state of the pod. If the current state is either in DOC, CONGESTION_L1, CONGESTION_L2, or Congested state, then the congestion control mechanism is triggered. After verifying that the message type is a request, a request priority is assigned to it. If the request priority is greater than or equal to the discard priority, then the message is rejected, otherwise it is accepted.

Congestion Control Load Shedding using Discard and Request Priority

Diameter Gateway pods performs load shedding by considering the load rule configured for the current congestion state. The load shedding rule is based on message priority configuration. A default load shedding rule is active and the messages are discarded based on it. You can configure these load rules with the congestion states being in the order of CONGESTED → CONGESTION_L1 → CONGESTION_L2 → CONGESTED states, using the Overload and Congestion Control menu in CNC Console. The Diameter Gateway discards the requests based on either:

• Priority
• Priority and Percentage

Table 4-97 Priority based Message Discards

Congestion State	Discard Priority
DANGER_OF_CONGESTION	27
CONGESTION_L1	19
CONGESTION_L2	17
CONGESTED	15

Table 4-98 Priority and Percentage based Discards

Congestion State	Discard Priority Range	Discard Percentage
DANGER_OF_CONGESTION	27-31	50
CONGESTION_L1	19-26 27-31	50 75
CONGESTION_L2	17-18 19-26 27-31	50 75 100
CONGESTED	15-31	100

For more information about these Priority or Priority and Percentage discards configurations, see Congestion Control Load Shedding Profiles page in CNC Console.

Propagation of Message Priority from and to Diameter Gateway

The following points needs to be known while assigning request or message priority to an request API:

• When the Diameter Gateway sends a message that includes OC-Message-Priority AVP, it is sending the priority value to the downstream services. The downstream services namely the Diameter Connector and PCRF Core services consider this value as having the highest precedence. This means that, instead of considering the configured message priority rules, these services will directly use the priority in OC-Message-Priority AVP when theirs pods are in congestion state.

• Similarly, when the downstream services namely the Diameter Connector and PCRF Core services sends messages that includes OC-Message-Priority AVP, it is sending the priority value to Diameter Gateway. The Diameter Gateway considers this value as having the highest precedence only if the diameter message priority rule has enabled the OC-Message-Priority option. If the option is not enabled then it will use the configured message priority from the selected Message Priority Profile.

The following two AVP's are added in Pre-Defined AVP Conditions in Diameter Gateway Message Priority Rules configurations at Policy → Overload and Congestion Control → Diameter → Message Priority Profiles in CNC Console.

Table 4-99 Pre-Defined AVP Conditions

Pre-Defined AVP Conditions	Type Operator	Values
DRMP	Equals Not Equals Less Than Less Than Equals Greater Than Greater Than Equals	The Diameter Routing Message Priority (DRMP) AVP allows Diameter Gateway to indicate the priority of diameter messages. This will take numeric values. Allowed numeric value in the range of 0-15.
OC-Message-Priority	Equals Not Equals Less Than Less Than Equals Greater Than Greater Than Equals	The header attribute allows Diameter Gateway to indicate the priority of diameter messages. This will take numeric values. Allowed numeric value in the range of 0-31.

In the Message Priority Profiles for Diameter Gateway, if both DRMP Priority and OC-Message-Priority is selected, then OC-Message-Priority shall be considered as highest priority for message priority rule selection. The message priority range for OC-Message-Priority is 0-31, and for DRMP AVP it is 0-15.

For more information about configuring message priority profiles, see Message Priority Profiles section in CNC Console.

Congestion Response Code

After defining load rules Overload and Congestion Control menu, the response to reject the request can also be configured using the advanced settings in Diameter configurations. The following are the advanced settings key and value:

Table 4-100 Advance Setting

Key	Value	Description
CONGESTION_DIAMETER_RESPONSE_CODE	3004	This is to configure the diameter result code for the congestion control discards and its value shall be numerical. The value can be set to either 3xxx, 4xxx, or 5xxx response codes. If this value is not configured, then default congestion result code shall be 3004 (DIAMETER_TOO_BUSY). Default Value: 3004 Examples: CONGESTION_DIAMETER_RESPONSE_CODE=5065 CONGESTION_DIAMETER_RESPONSE_CODE=3004
CONGESTION_DIAMETER_VENDOR_ID	0	This is to configure the diameter vendor id for the congestion control discards and its value shall be numerical. If the value is non-zero, then the CONGESTION_DIAMETER_RESPONSE_CODE shall be considered as the experimental result code. If value is zero or it is not configured, then CONGESTION_DIAMETER_RESPONSE_CODE shall be considered as the normal result code. Examples: CONGESTION_DIAMETER_VENDOR_ID=10415 CONGESTION_DIAMETER_VENDOR_ID=21274

If above advance settings keys are not configured, then Diameter Gateway will discard the messages with default diameter result code 3004 DIAMETER_TOO_BUSY. Diameter Gateway will continue to use the diameter result code 3004 DIAMETER_TOO_BUSY for the message received from backend services namely, the Diameter Connector and PCRF Core services.

For more information about different response codes that can be configured, see Congestion Control Discard Message Response Code section.

Call Flow

To best understand how the diameter congestion control feature works, consider a scenario where the sample message priority profiles rules are configured as described in the following table:

Table 4-101 Message Priority Profiles

Message	Priority
Default	24
Rx RAR	18
Gx CCR-I	24
Sy SLR	24

Note:

The default message profile is only for the purpose of understanding the feature. No default message priority profiles are configured for Policy.

The discard priority congestion states will be in order like CONGESTED → CONGESTION_L1 → CONGESTION_L2 → CONGESTED states. For this call flow, the discard priority are configured with DOC as 22, and Congested as 20. The result code for rejecting request messages is set as DIAMETER_UNABLE_TO_COMPLY (applicable only for external peers).

Figure 4-143 Call flow diagram for Diameter Congestion Control

• When Diameter Gateway 2, currently is either in DOC or Congested state, receives CCR-I request, the priority is compared against discard priority. As both message priority and discard priority values are same, the message is rejected with result code – DIAMETER_UNABLE_TO_COMPLY.
• When Diameter Gateway 2, currently is either in DOC or Congested state, receives Sy-SLR request, the priority is compared against discard priority. As message priority is low in priority than discard priority, the message is rejected with result code – DIAMETER_TOO_BUSY.
• When Diameter Gateway 2, currently is either in DOC or Congested state, receives Rx RAR request, the priority is compared against discard priority. As message priority is higher than discard priority, the message is accepted with result code – DIAMETER_SUCCESS.
• When Diameter Gateway 2, currently in DOC or Congested state, receives SNR request, the priority is compared against discard priority. Since no priority rule is configured for this message request, the message is accepted with result code – DIAMETER_SUCCESS.

Feature Upgrade Impact

With upgrade of Policy application from any of the previous release versions to 25.1.200, the Diameter Gateway pod Congestion Control feature can be updated to use the common Congestion Control mechanism available in 25.1.200. In order to do this, there are some considerations to address, especially due to the difference in configuration data. Diameter Gateway's pod congestion control configurations from the previous version should be migrated to use the current version configurations. The data migration process is manual and one-time activity that user has to perform, by using either the CNC Console or Congestion Control migration APIs.

Feature Transition

Diameter Gateway Congestion Control feature transition between older version to the Policy 25.1.200 Congestion Control mechanism is based on migration status of the Policy application during the upgrade. The migration status can be either in "False" or "True".

False (Before Migration): After upgrading to Policy version 25.1.200, the Diameter Gateway pod congestion control feature still operates under the configurations and designs of the pre-upgrade version until the user actively migrates the setup. In this "Before Migration" state, the users will only see:

• Old Configurations: The Diameter Gateway Congestion Control configurations from the previous application version.
• Previous CNC Console pages: User will have access to the older user interface rather than the new screen designed for Congestion Control feature.
• Legacy REST APIs: Calls to APIs will still work with the previous version's endpoints.

To enable the common Congestion Control mechanism for Diameter Gateway, users will need to complete the data migration process. For more information related to Diameter Gateway Congestion Control configuration migration, see "Migration of Congestion Control Configuration Data" section in Congestion Control Settings page in CNC Console.

True (After Migration): After the upgrade to Policy version 25.1.200, perform the data migration for Diameter Gateway pod Congestion Control feature. With this, the migration status will be "After Migration" and Diameter Gateway services will be able to use the updated Congestion Control mechanisms.

Managing Diameter Gateway Pod Congestion Control

Enable

By default, the Pod Congestion Control is disabled for Diameter Gateway. You can enable this feature using CNC Console or REST API for Policy.

Feature Migration

If the Policy application is upgraded to 25.1.200, then you can enable this feature by performing the migration process. For more information how to perform the data migration, see "Migration of Congestion Control Configuration Data" section in Congestion Control Settings page using CNC Console.

Configure

You can customize the configurations related to this feature using the CNC Console or REST APIs for Policy:

• Configure using CNC Console:

  To enable the feature using CNC Console, set the Enable parameter in Settings page under Congestion Control for Overload and Congestion Control Configurations for Diameter Gateway Service.

  To configure Diameter Gateway service pod congestion control feature in CNC Console, see Congestion Control section.

• Configure using REST API:

  To enable this feature using REST API, perform the feature configurations as described in "Congestion Control" APIs section in Oracle Communications Cloud Native Core, Converged Policy REST Specification Guide.

  If the Policy application is upgraded to 25.1.200, then you can enable this feature by performing the migration process. For more information how to perform the data migration using Congestion Control Migration APIs, see "Congestion Migration" APIs section in Oracle Communications Cloud Native Core, Converged Policy REST Specification Guide.

Observability

Metrics:

Diameter Gateway service uses the pod congestion metrics for this feature.The following common service Pod Congestion Metrics are used to provide information about this feature:

• occnp_pod_congestion_state
• occnp_pod_resource_stress
• occnp_pod_resource_congestion_state
• occnp_pod_cong_state_report_total
• occnp_pod_resource_congestion_state_report_total
• occnp_congestion_diam_pending_request_active_counter
• occnp_congestion_diam_pending_request_end_to_end_id_map_size
• occnp_congestion_DiamMsgBuffer_queue_msg_count

The following Diameter Gateway Metrics are used to provide information about this feature:

• occnp_pod_resource_congestion_state_report_total
• occnp_congestion_diam_pending_request_active_counter
• occnp_congestion_diam_pending_request_end_to_end_id_map_size
• occnp_congestion_DiamMsgBuffer_queue_msg_count
• occnp_diam_pending_requests_total
• occnp_diam_congestion_message_reject_total

Alerts

The following alerts are generated for this feature:

• POD_CONGESTED
• POD_CONGESTION_L2
• POD_CONGESTION_L1
• POD_DANGER_OF_CONGESTION
• POD_PENDING_REQUEST_CONGESTED
• POD_PENDING_REQUEST_CONGESTION_L2
• POD_PENDING_REQUEST_CONGESTION_L1
• POD_PENDING_REQUEST_DANGER_OF_CONGESTION
• POD_CPU_CONGESTED
• POD_CPU_CONGESTION_L2
• POD_CPU_CONGESTION_L1
• POD_CPU_DANGER_OF_CONGESTION

Maintain

Error logs are generated when the system is congested and the actions taken to bring the system back to normal. Warning logs are generated to indicate the congestion level. However, error logs are not generated when messages are rejected to avoid additional resource usage to write error logs.

The following is a sample error log:

{
  "instant": {
    "epochSecond": 1629306402,
    "nanoOfSecond": 438895435
  },
  "thread": "Thread-10",
  "level": "INFO",
  "loggerName": "ocpm.cne.common.configclient.ConfigurationAgent",
  "message": "Configuration changed, class ConfigurationItem {\n    key: common.congestionthreshold.diam-gateway\n    value: {\"stateCalculationInterval\":10000,\"stateChangeSampleCount\":3,\"thresholds\":[{\"state\":\"DANGER_OF_CONGESTION\",\"resourceUsageLimit\":{\"cpu\":40,\"memory\":40,\"queue\":20}},{\"state\":\"CONGESTED\",\"resourceUsageLimit\":{\"cpu\":80,\"memory\":80,\"queue\":50}}]}\n    version: 8\n    topicInfo: class TopicInfo {\n        id: 6\n        name: common.congestionthreshold.diam-gateway\n        description: Created by config server.\n        modifydate: Wed Aug 18 17:06:42 UTC 2021\n        version: 10\n    }\n    labels: null\n}",
  "endOfBatch": false,
  "loggerFqcn": "org.apache.logging.slf4j.Log4jLogger",
  "threadId": 77,
  "threadPriority": 5,
  "messageTimestamp": "2021-08-18T17:06:42.438+0000"
}

4.71 Overload Control

Overload means when 100% of the planned capacity is exhausted. It can be due to uneven distribution of traffic towards a given policy service instance, network fluctuations leading to traffic bursts or unexpected high traffic volume at any given point of time.

During overload conditions, the service response times may grow to unacceptable levels, and exhaustion of resources can result in downtime or services exhibiting unexpected behavior. Overload management is a critical requirement for any telecom node, server, and service to protect against downtime and ensure serviceability during extreme overload conditions. Thus, the goal of overload management is to prevent service performance from degrading in an uncontrolled manner under heavy load. When policy service starts approaching its saturation or planned limit, response times typically grow high and throughput can degrade substantially. Under such conditions, it is desirable to shed load based on the operator's configuration, instead of causing all messages and signaling flows to experience unacceptable response times, failures, or downtime.

Policy allows to configure a percentage of messages to be rejected. That is, messages are discarded based on configured percentage. This enables system's overload and congestion control to manage gauge system's load with better accuracy. Also, it allows the user to provide less rejections instead of providing 100% rejections.

Percentage of message rejections for each load level is configurable. Also, the rejection percentage for each message priority can be configured.

For example, if the discard value for CCR-I messages is 50% , when system is under load, only alternate CCR-I requests are processed rejected the rest. That is, 1st CCR-I is rejected and 2nd is accepted.

Note:

All CCR-Ts are accepted.

Enable

To enable the overload control functionality, set value for the following parameter to true in the custom-values.yaml file for Policy:

• perf-info.overloadManager.enabled

Then, configure the values for the following parameters in the custom-values.yaml file:

perf-info:
  envMysqlDatabase: ''
  overloadManager:
    enabled: false
    ingressGatewaySvcName: occnp-ingress-gateway
    ingressGatewayPort: *svcIngressGatewayHttp
    # nfType is used to query configuration from common cfg server
    nfType: PCF
    # diam Gateway overload management feature configurations
    diamGWPort: *svcDiamGatewayHttp

For more information about setting the parameter values, see Overload Manager Configurations in Oracle Communications Cloud Native Core, Converged Policy Installation, Upgrade and Fault Recovery Guide.

Configure

You configure the overload control feature either using CNC Console, or through REST API.

• Configure using REST API: Policy provides overloadLevelThreshold and overloadLevelThresholdProfiles API end points to configure overload control feature.

  You can perform the POST, PUT, or GET operations to configure the feature. For more information about REST API configuration, see Overload Level Threshold section in Oracle Communications Cloud Native Core, Converged Policy REST API Specification Guide.

• Configure using CNC Console: Using CNC Console, you can configure the threshold values based on profiles. For more information, see Overload Control Threshold.

Overload Threshold Values

When Overload control feature is enabled, the load on each service is monitored using the following counters:

• CPU: Indicates the maximum CPU usage in terms of percentage.
• Pending message count: Indicates the number of requests from the gateway to the Policy service for which the response is not yet received.
• Failure count: Failed request count for each service. Indicates the number of error responses that the Policy service receives in error series such as 4XX or 5XX. Different routes mapped to the Policy service can have different set of configured error codes and exception list for tracking the failure counts.

  The error codes set must be configured in the routes configuration. The below table lists the route IDs for each of the services for which the error codes set must be configured.

  Table 4-102 Supported Route IDs

  Service	Routes
  SM Service	sm_create_session_route sm_delete_session_route sm_update_session_route pa_create_session_route pa_delete_session_route pa_update_session_route pa_events_subscription_route
  AM Service	am_create_session_route am_delete_session_route am_update_session_route
  UE Policy Service	reverse_ue_service reverse_ue_service_notify
  UDR	udr_notify_route reverse_user_udr_notify_service reverse_user_udr_notify_service
  CHF	chf_terminate_route chf_notify_route reverse_user_chf_notify_service
  NRF Client	reverse_nrf_discovery_service reverse_nrf_management_service reverse_nrf_notify_service
  SOAP Connector	reverse_soapconnector_service

  For details on configuring the route IDs, see Route Level Configuration section in Oracle Communications Cloud Native Core, REST Specification Guide.

Default Overload Threshold Values

This section describes the recommended default overload threshold values for Diameter Connector, PCRF Core, SM Service, AM Service, UE Policy Service, UDR Connector, and CHF Connector. To calculate threshold values, you must consider the resource values for microservices. The following table lists the default resource values for Diameter Connector, PCRF Core, SM Service, AM Service, UE Policy Service, UDR Connector, and CHF Connector:

Table 4-103 Default Resource Values

Resources	Diameter Connector	PCRF Core	SM Service	AM Service	UE Policy Service
CPU (Limits)	4	8	7	8	8
CPU (Requests)	3	7	7	7	7
Maximum CPU Usage	2.5	4.35	5.4	3.39	3.39
Maximum CPU Usage (%)	63	54	68	42	42
Maximum Replicas	8	8	8	8	8
Maximum TPS	2500	2100	880	675	300
Maximum TPS (all replicas)	20000	16800	7040	5400	2400
Worst RTT (assumed)	250 ms	250 ms	250 ms	250 ms	250 ms
Maximum Pending Transactions	5000	4200	1760	1350	600

Based on the values in Table 4-103 table, you can calculate the onset and abatement values for load levels - L1, L2, and L3, as shown in the Table 4-104 table.

Note:

The values shown in Table 4-103 table are the default values and can be changed depending on the deployment model used.

Table 4-104 Formulas to Calculate Default Overload Threshold Levels

Load Level	CPU (%)	Pending Message Count(Absolute Value)	Failure Count(Absolute Value)
L1 - Onset	80% * C	60% * P	05% * T
L1 - Abatement	75% * C	50% * P	03% * T
L2 - Onset	90% * C	75% * P	10% * T
L2 - Abatement	85% * C	70% * P	08% * T
L3 - Onset	95% * C	90% * P	15% * T
L3 - Abatement	91% * C	85% * P	12% * T

Abatement value is the lower range where as the onset value is higher range for that particular level.

Note:

C denotes the maximum CPU utilization per pod of each of the services shown in Table 4-105 table.

T denotes the maximum incoming TPS of a given service listed in Table 4-105 table.

P denotes the maximum pending transaction size value based on worst RTT and maximum incoming TPS (T).

For example, if Maximum TPS (all replicas) (T) =20000 and Worst RTT (assumed) =250, then Maximum Pending Transactions (P) is calculated as (20000/1000) * 250 = 5000.

Note:

You can configure the memory for each of these services.

Table 4-105 Messages to be accounted for calculating Service level Ingress TPS

Service Name	Message Types	Metrics Used
SM Service	SM (Create, Update, Delete) PA (Create, Update, Delete, events subscription, events un-subscription)	ocpm_ingress_request_total ocpm_ingress_response_total For more details on these metrics, see SM Service Metrics.
AM Service	AM (Create, Update, Delete)	ocpm_ingress_request_total ocpm_ingress_response_total For more details on these metrics, see AM Service Metrics.
UE Service	UE (Create, Update, Delete) N1 Message Notify	ocpm_ingress_request_total ocpm_ingress_response_total ue_n1_transfer_request ue_n1_transfer_response ue_n1_transfer_ue_notification_total For more details on these metrics, see UE Service Metrics.
Pcrf-Core	Gx CCR (I/U/T) Rx (AAR, STR)	occnp_diam_request_local_total (CCR-I) occnp_diam_response_local_total (CCA-I) occnp_diam_request_local_total (CCR-U) occnp_diam_response_local_total (CCA-U) occnp_diam_request_local_total (CCR-T) occnp_diam_response_local_total (CCA-T) occnp_diam_request_local_total (AAR-I) occnp_diam_response_local_total (AAA-I) occnp_diam_request_local_total (AAR-U) occnp_diam_response_local_total (AAA-U) occnp_diam_request_local_total (RAR Gx) occnp_diam_response_local_total (RAA Gx) occnp_diam_request_local_total (RAR Rx) occnp_diam_response_local_total (RAA Rx) occnp_diam_request_local_total (STR) occnp_diam_response_local_total (STA) For more details on these metrics, see PCRF Core Metrics.
Diameter Connector	Rx (AAR, STR) Sy SNR	ocpm_ingress_request_total ocpm_ingress_response_total For more details on these metrics, see Diameter Connector Service Metrics.
UDR Connector	Policy Data Change Notification	ocpm_udr_tracking_request_total ocpm_udr_tracking_response_total For more details on these metrics, see UDR Metrics.
CHF Connector	Spending limit report notify Subscription Termination	ocpm_chf_tracking_request_total ocpm_chf_tracking_response_total For more details on these metrics, see CHF Metrics.

The following table lists the default overload threshold values for Diameter Connector:

Table 4-106 Default Overload Threshold Values - Diameter Connector

Load Level	CPU (%)	Pending Message Count	Failure Count
L1 - Onset	51	3000	1000
L1 - Abatement	48	2500	600
L2 - Onset	57	3750	2000
L2 - Abatement	54	3500	1600
L3 - Onset	60	4500	3000
L3 - Abatement	58	4250	2400

The following table lists the default overload threshold values for PCRF Core:

Table 4-107 Default Overload Threshold Values - PCRF Core

Load Level	CPU (%)	Pending Message Count	Failure Count
L1 - Onset	44	2520	840
L1 - Abatement	41	2100	504
L2 - Onset	49	3150	1680
L2 - Abatement	47	2940	1344
L3 - Onset	52	3780	2520
L3 - Abatement	50	3570	2016

Note:

On performing fresh installation of Policy, the system is loaded with only CPU threshold values. Using the sample configurations as a reference, you can set the threshold values for pending count and failure count according to the system's capacity.

The following table lists the default overload threshold values for UDR Connector:

Table 4-108 Default Overload Threshold Values - UDR Connector

Load Level	CPU (%)	Pending Message Count	Failure Count
L1 - Onset	51	1056	352
L1 - Abatement	54	880	208
L2 - Onset	61	1320	704
L2 - Abatement	57	1232	560
L3 - Onset	64	1584	1056
L3 - Abatement	62	1496	848

The following table lists the default overload threshold values for CHF Connector:

Table 4-109 Default Overload Threshold Values - CHF Connector

Load Level	CPU (%)	Pending Message Count	Failure Count
L1 - Onset	54	1056	352
L1 - Abatement	51	880	208
L2 - Onset	61	1320	704
L2 - Abatement	57	1232	560
L3 - Onset	64	1584	1056
L3 - Abatement	62	1496	848

Recommended Overload Threshold Values - SM, AM, and UE Services

The following table lists the default overload threshold values for SM, AM, and UE Services:

Table 4-110 Recommended Overload Threshold Values - SM, AM, and UE Services

Load Level	Service	CPU (%)	Pending Message Count	Failure Count
L1 - Onset	SM Service	55	1056	352
	AM Service	34	810	270
	UE Policy Service	34	360	120
L1 - Abatement	SM Service	51	880	212
	AM Service	32	675	162
	UE Policy Service	32	300	72
L2 - Onset	SM Service	61	1320	704
	AM Service	38	1013	540
	UE Policy Service	38	450	240
L2 - Abatement	SM Service	58	1232	564
	AM Service	36	945	432
	UE Policy Service	36	420	192
L3 - Onset	SM Service	65	1584	1056
	AM Service	40	1215	810
	UE Policy Service	40	540	360
L3 - Abatement	SM Service	62	1496	845
	AM Service	39	1148	648
	UE Policy Service	39	510	288

Note:

These are the recommended values. It can be modified as per the customer requirements.

The pending message count, and failure counts depend on the deployment capacity. The values shown in the above tables are calculated for the default deployment size. These values must be recalculated as per the deployment requirements.

Observe

Policy provides the following metrics specific to Overload Control feature:

• service_resource_stress
• service_resource_overload_level
• load_level
• system_overload_threshold_config_mode
• active_overload_threshold_fetch_failed

For more information, see PerfInfo Metrics section.

Alerts

• Policy provides the following alerts for overload control feature on SBI interface:

  • ServiceOverloaded - This alert is raised whenever a given service is in overload state - L1, L2, and L3.
  • ServiceResourceOverLoaded - This alert is raised when a given service is in overload state - L1, L2, or L3 due to resource types such as memory, CPU, pending count, and failure count.

• Policy provides PERF_INFO_ACTIVE_OVERLOAD_THRESHOLD_FETCH_FAILED alert for overload control threshold configuration. This alert is raised when the service is unable to fetch the current active overload threshold data.

Maintain

Error logs are generated when the system is overloaded and the actions taken to bring the system back to normal. Warning logs are generated to indicate the change in load level.

4.71.1 Overload Control- Diameter

For Diameter Gateway, Policy provides the following means for overload management:

• Pre-defined threshold load levels.
• Tracks number of pending messages of PCRF core and Diameter Connector from Diameter Gateway.
• Tracks CPU and memory usage of PCRF core and Diameter Connector.
• Enforce load shredding during various overload levels based on priority and percentage discard value for each priority. The priority and percentage discard value are configurable.

Configure

To configure the threshold values (REST API only), discard priority, percentage discard value, and error codes for each defined level for overload control, you can use CNC Console as well as REST API.

• Configure using CNC Console: Perform the feature configurations on the Load Shedding Profiles and Message Priority Profiles page. For more information about the configurations, see Load Shedding Profiles.
• Configure using REST API: Policy provides the following REST API for configurating diameter gateway overload control feature:

  Load Shedding Profiles: {apiRoot}/oc-cnpolicy-configuration/v1/diameter/loadsheddingprofiles

  Message Priority Profiles: {apiRoot}/oc-cnpolicy-configuration/v1/diameter/messagepriorityprofiles

  You can perform the POST, PUT, or GET operations to configure the feature. For more information about REST API configuration, see Oracle Communications Cloud Native Core, Converged Policy REST Specification Guide.

The following are the recommended configurations for load shedding profile and message priority profile respectively for overload control:

{
  "name": "default_overload_control_msg_priority_profile",
  "priorityRules": [{
    "ruleName": "Gx_CCR_I",
    "messagePriority": 14,
    "rulePriority": 1,
    "enableDRMPPriority": true,
    "conditions": {
      "application": "Gx",
      "message": "CCR",
      "preDefinedAVPConditions": [{
        "conditionName": "CC-Request-Type",
        "conditionCCRTValue": ["INITIAL_REQUEST"]
      }]
    }
  }, {
    "ruleName": "Rx_AAR_I",
    "messagePriority": 13,
    "rulePriority": 1,
    "enableDRMPPriority": true,
    "conditions": {
      "application": "Rx",
      "message": "AAR",
      "preDefinedAVPConditions": [{
        "conditionName": "Rx-Request-Type",
        "conditionRxRTValue": ["INITIAL_REQUEST"]
      }]
    }
  }, {
    "ruleName": "Gx_CCR_U",
    "messagePriority": 12,
    "rulePriority": 1,
    "enableDRMPPriority": true,
    "conditions": {
      "application": "Gx",
      "message": "AAR",
      "preDefinedAVPConditions": [{
        "conditionName": "CC-Request-Type",
        "conditionCCRTValue": ["UPDATE_REQUEST"]
      }]
    }
  }, {
    "ruleName": "Gx_CCR_T",
    "messagePriority": 8,
    "rulePriority": 1,
    "enableDRMPPriority": true,
    "conditions": {
      "application": "Gx",
      "message": "CCR",
      "preDefinedAVPConditions": [{
        "conditionName": "CC-Request-Type",
        "conditionCCRTValue": ["TERMINATION_REQUEST"]
      }]
    }
  }, {
    "ruleName": "Sy_SNR",
    "messagePriority": 6,
    "rulePriority": 1,
    "enableDRMPPriority": true,
    "conditions": {
      "application": "Sy",
      "message": "Sy-SNR",
      "preDefinedAVPConditions": []
    }
  }, {
    "ruleName": "Rx_STR",
    "messagePriority": 7,
    "rulePriority": 1,
    "enableDRMPPriority": true,
    "conditions": {
      "application": "Rx",
      "message": "STR",
      "preDefinedAVPConditions": []
    }
  }, {
    "ruleName": "Rx_AAR_U",
    "messagePriority": 11,
    "rulePriority": 1,
    "enableDRMPPriority": true,
    "conditions": {
      "application": "Rx",
      "message": "AAR",
      "preDefinedAVPConditions": [{
        "conditionName": "Rx-Request-Type",
        "conditionRxRTValue": ["UPDATE_REQUEST"]
      }]
    }
  }]
}

{
  "name": "default_overload_control_load_shedding_profile",
  "type": "Overload Control",
  "overloadLoadSheddingRules": [{
    "level": "L1",
    "discardPriority": 13,
    "ansWithResultCode": "DIAMETER_TOO_BUSY"
  }, {
    "level": "L2",
    "discardPriority": 11,
    "ansWithResultCode": "DIAMETER_TOO_BUSY"
  }, {
    "level": "L3",
    "discardPriority": 6,
    "ansWithResultCode": "DIAMETER_TOO_BUSY"
  }]
}

Observe

Policy provides the following metrics specific to Overload Control feature for diameter gateway:

• diam_overload_message_reject_total

For more information, see Diameter Gateway Metrics section.

4.71.2 Overload Control- SBI

For HTTP signaling, Policy overload management provides following means for overload management:

• Tracks number of pending messages for an exposed policy service in its NF Profile.
• Tracks number of failed responses (configurable as error code by operator) generated by exposed policy service in its NF Profile.
• Determine the overload level of system using data collected from point 1 and 2, against planned threshold levels (based on planning).
• Enforce load shredding during various overload levels.

Configure

To configure the discard policies, discard policy mapping, and error code profiles for overload control, you may use CNC Console as well as REST API.

Note:

Currently, threshold values can be configured using REST API only.

• Configure using CNC Console: Perform the feature configurations on the Discard Policy Mapping, Discard Policy, and Error Code Profiles pages. For more information about the configurations, see Overload and Congestion Control Configurations.
• Configure using REST API: Policy provides the following REST API for configuring overload control feature on SBI interface:

  OC Policy Mapping: {apiRoot}/PCF/nf-common-component/v1/igw/ocpolicymapping

  OC Discard Policies: {apiRoot}/PCF/nf-common-component/v1/igw/ocdiscardpolicies

  Error Code Profiles: {apiRoot}/PCF/nf-common-component/v1/igw/errorcodeprofiles

  You can perform the GET, PUT, or PATCH operations to configure the feature. For more information about REST API configuration, see Oracle Communications Cloud Native Core, Converged Policy REST Specification Guide.

The following are the recommended configurations for default message priority values for overload control:

Table 4-111 Default Message Priority

Message Type	Priority
Create SM Policy Association	24
Delete SM Policy Association	16
Update SM Policy Association	18
UDR Notify	18
CHF Terminate	18
UDR Notify	18
CHF Notify	18
Create PA Application Session	24
Delete PA Application Session	16
Update PA Application Session	18
Subscribe PA Events	18
Unsubscribe PA Events	18
Create AM Policy Association	24
Delete AM Policy Association	16
Update AM Policy Association	18
Create UE Policy Association	24
Delete UE Policy Association	16
Update UE Policy Association	18

4.72 Load Shedding through Admission Control in PCRF-Core

If you are using Policy 22.4.5 or any other later versions, Load Shedding through Admission Control in PCRF-Core is enabled by default.

The Admission Control enhancement in PCRF-Core performs message load shedding during congestion. Load Shedding through the Admission Control feature is enabled by default in the PCRF-Core. This enhancement enables PCRF-Core to monitor the message backlog. When the number of outstanding messages to be processed exceeds a certain threshold for a certain duration, Admission Control starts rejecting a subset of the messages that it receives.

The default behavior when a node is too busy is to:

• reject Gx CCR-I requests at L1 level of busyness.
• reject Gx CCR-I and Rx AAR-I requests at L2 level of busyness.
• reject all the requests at level L3.

This prevents corresponding sessions to be established, as such if the load is due to these applications, the node matches the backlog and switches to the “busy” state.

Load Shedding through Admission Control in PCRF-Core allows for the definition of up to three levels of busyness based on the amount of backlog: level 1, level 2, and level 3. Level 1 is the least busy level and level 3 is the busiest level.

Note:

The node is busy whenever it is at any of the busy levels.

Another way to look at the different busy levels is by the amount of processing time the node needs to catch up with the backlog. The “catch-up” processing time will translate into increased response latencies. So, as the busy level increases, more drastic measures may need to be taken to attempt to clear the backlog and go back to normal response times.

The entrance criteria for a busy level are:

• The backlog of outstanding messages in a node crossed a pre-defined threshold for the level.
• The backlog has been above the busyness level’s threshold for a minimum amount of time.

The time portion is added as hysteresis to avoid too frequent level transitions. When the thresholds for multiple levels are crossed, the level of busyness is determined by the highest crossed threshold, as long as the time criteria is satisfied.

Note:

A node could bypass levels of busyness if it crosses multiple thresholds. As an example, a node could go from not being busy to being at busy level 2.

The exit criteria from a busyness level are:

• The backlog of outstanding messages has been smaller than a pre-defined threshold for the level.
• The backlog has been below the busyness level’s threshold for a minimum amount of time.

At each level, allow for the following actions per Diameter application, message type and AVPs content:

• Reject with a specific result code (default is DIAMETER_TOO_BUSY)
• Drop

For example, reject Gx CCR-I for APN X at level 1, reject Rx AAR-I message at level 2, and drop Gx CCR-U for APN Y at level 3.

The table below summarizes the default load shedding configuration values with which pcrf-core microservice is shipped with:

Table 4-112 Default Load Shedding Configuration

Busy Level	Entrance Threshold	Entrance Time Criterion (ms)	Exit Threshold	Exit Time Criterion (ms)	Actions
Level 1	300	300	150	500	Reject Gx CCR-I with DIAMETER_TOO_BUSY Accept CCR-I with DRMP=0 (Gx/CCR/CC-Request-Type=1 && DRMP=0)
Level 2	1000	300	600	500	Reject Gx CCR-I with DIAMETER_TOO_BUSY Reject Rx AAR-I with DIAMETER_TOO_BUSY Accept CCR-I with DRMP=0 (Gx/CCR/CC-Request-Type=1 && DRMP=0)
Level 3	2000	300	1500	500	DROP

For details on advanced configuration keys and values that are used for load shedding through admission control, see PCRF-Core Configurations section in Cloud Native Core Policy Installation and Upgrade Guide.

The following metric has been added in Diameter Gateway service for this feature:

• diameter_outstanding_msg_count

For more information, see Diameter Gateway Metrics.

Note:

This metric can be used to create alerts as per the requirement.

4.73 Rate Limiting

With the support for rate limiting feature at Ingress Gateway, Ingress Gateway is expected to screen all configured routes and their respective rate limit configurations. Within the sampling period (configurable using REST APIs), Ingress Gateway calculates the rate for the required route along with the HTTP method. Then, it notifies the route level rate limiter rate about the calculated rate at the end of the sampling period. If the feature is enabled, any request with the sbi-priority header value greater than the configured value is discarded and Ingress Gateway returns the error response with configured errorCode.

Note:

Ingress Gateway determines the number of messages to be silently dropped or rejected in the current sampling period on the basis of extra messages received in previous sampling period that are not rejected.

Managing Rate Limiting

Enable

Perform the following configurations to enable the rate limiting feature at Ingress Gateway:

• CNC Console: By default, this feature is disabled. To enable the rate limiting feature using CNC Console, set the Enable Rate Limiting parameter to true on the Rate Limiting Policy page.

• REST API: By default, this feature is disabled. To enable the rate limiting feature using REST API, set the enabled parameter to true in the following resource URI:

  Define rate limit: {apiRoot}/PCF/nf-common-component/v1/igw/routelevelratelimiting

  Define rate limit at route level: {apiRoot}/PCF/nf-common-component/v1/igw/routesconfiguration

  For more information, see the section Rate Limiting at Ingress Gateway in Oracle Communications Cloud Native Core, Converged Policy REST Specification Guide.

Configure

To configure the rate limiting policy, route level mapping, and error code profiles for rate limiting, you may use CNC Console as well as REST API.

• Configure using CNC Console: Perform the feature configurations on the Rate Limiting Policy, Route Level Mapping, and Error Code Profiles pages. For more information about the configurations, see Overload and Congestion Control Configurations.
• Configure using REST API: PCF provides the following REST API for configuring overload control feature on SBI interface:

  Define error code profiles: {apiRoot}/PCF/nf-common-component/v1/igw/errorcodeprofiles

  Define rate limit: {apiRoot}/PCF/nf-common-component/v1/igw/routelevelratelimiting

  Define rate limit at route level: {apiRoot}/PCF/nf-common-component/v1/igw/routesconfiguration

  You can perform the GET, PUT, or PATCH operations to configure the feature. For more information about REST API configuration, see Oracle Communications Cloud Native Core, Converged Policy REST Specification Guide.

4.74 Topology Hiding for Diameter Gateway

With the Topolgy Hiding feature, it is possible to do the following:

• Hide topology-related information in messages sent to external peers.
• Restore the topology-related information in messages from external peers.

In Policy, the Diameter Gateway acts as a proxy for both incoming and outgoing diameter messages. Irrespective of the direction, request and response of diameter messages must include Origin-Realm and Origin-Host of diameter gateway on reaching external peers.

With Topology Hiding feature enabled, the Diameter Gateway verifies if the Origin-Host value in request or response from backend peers matches one of the managed backend peers, before sending to external peers. If yes, the value of Origin-Host is replaced with the Diameter Gateway identity in the message request and response. If the request or response is not for managed backend peers, no change is made to the Origin-Host.

Configure

To enable and configure this feature using CNC Console, the following parameters have been added under Diameter Configurations:

• Topology Hiding
• Apps to Hide

For more information about setting the parameter values, see Settings for Diameter Configurations.

Observe

Enabling the Topology Hiding feature replaces the Origin-Host dimension value with Diameter Gateway identity. It contains the value as per the message call-flow.

4.75 Two-phase Deployment of Policies

Policy allows you to configure and update the existing policies. However, updating or changing existing policies can impact existing traffic adversely. To overcome this challenge, Policy provides the two phase deployment model. This deployment model supports:

• Creation, modification, or deletion of policies, without impacting the existing policies.
• Testing of new policies with some percentage of live traffic before enabling it for 100% live traffic.

This feature allows you to create a policy project without deploying it. To implement this, Policy provides two possible states, Prod and Dev in the policy project.

By default, the Dev state is assigned to the policy project. Dev projects do not process any traffic in PRE (Policy Runtime Engine), where PRE is a pod. The Prod projects process traffic in PRE.

Managing Two-phase Deployment of Policies

Enable

The Two Phase deployment is a core functionality of Policy. You do not need to enable or disable this feature.

Configure

You can create new policy projects and update the existing projects using the CNC Console for Policy.

For more information about configuring Policy Projects, see Policy Projects.

4.76 Binding Mechanism Support (Nbsf)

PCF Session Binding is used for AF to discover a PCF that contains the PDU session and communicates with that PCF for App session procedures.

The PCF interacts with BSF to maintain the PCF session binding information during the PDU session life cycle.

PCF implements service operations as a consumer defined in clause 4.2 of TS 29.521[11]:

• Nbsf_Management_Register Service Operation
• Nbsf_Management_Deregister Service Operation

PCF invokes Nbsf_Management_Register Service Operation to the BSF to create PCF session binding when creating SM Policy Association. PCF invokes Nbsf_Management_Deregister Service Operation and Nbsf_Management_Register Service Operation when modify SM Policy Association and the UE address information is changed.

The system considers BSF selection based on the IP range to invoke BSF operation.

The interaction with BSF is optional and can be configured in PCF SM Service configuration. For more information about these configurations, see PCF Session Management.

Managing Binding Mechanism Function

Enable

You can enable the Binding mechanism functionality using the CNC Console or REST API for Policy.

• Enable using CNC Console: To enable the feature, set the Binding Operation parameter value to TRUE under the Binding Configurations group on the PCF Session Management page. For more information about enabling the feature through CNC Console, see PCF Session Management Service.
• Enable using REST API: Set the bindingOperationEnabled parameter value to true in the Session Management Service configuration API. For more information about enabling the feature through REST API, see "Session Management Service" in Oracle Communications Cloud Native Core, Converged Policy REST Specification Guide.

Configure

You can configure the Binding mechanism functionality using the CNC Console or REST API for Policy.

• Configure using CNC Console: Perform the feature configurations under the Binding Configurations group on the PCF Session Management page. For more information about configuring the feature through CNC Console, see PCF Session Management Service.
• Configure using REST API: Policy provides the following REST API for Binding mechanism configuration:

  API: {apiRoot}/oc-cnpolicy-configuration/v1/services/pcfsm

  You can perform the PUT operation to configure the feature. For more information about REST API configuration, see Binding Configurations of the "Session Management Service" in Oracle Communications Cloud Native Core, Converged Policy REST Specification Guide.

Observe

Policy provides the Binding requests and response metrics in the Session Management services. For more information, see the Binding service metrics in SM Service Metrics.

4.77 LDAP Support

Policy establishes connections with data sources to retrieve information about subscribers from the database. It queries a data source using a key attribute that uniquely identifies a subscriber and stores the results in its cache. A data source uses this key attribute. For example, the phone or account number of the subscriber to index the information present in the database.

The Policy supports Lightweight Directory Access Protocol (LDAP) data source. It provides support for the following LDAP related functions:

• Configuring LDAP Server Information
• Providing support for LDAP server

Based on the conditions implemented in PCF system, Policy Data Source (PDS) retrieves all the relevant information from LDAP data source based on the rules configured in the system through LDAP gateway.

For information on configuring the LDAP server, see Data Source Configurations.

Managing LDAP

Enable

To enable the LDAP functionality, set value for the following parameter to true in the customer value file for Policy:

• ldapGatewayEnable

On setting the value for the aforementioned parameter to true, the Session Management (SM) or PCRF Core service routes the traffic to LDAP Gateway through PDS. For more information about setting the parameter values, see "Enabling/Disabling Services Configurations" in Oracle Communications Cloud Native Core, Converged Policy Installation, Upgrade and Fault Recovery Guide.

Configure

LDAP credentails are stored as kubernetes secret along with Authentication DN and LDAP name. You must create a kuberenetes secret to store LDAP credentials before setting a PDS as LDAP data source.

To create a kubernetes secret for storing LDAP credentails:

1. Create a yaml file with the following syntax:

   apiVersion: v1
   kind: Secret
   metadata:
     name: ldapsecret
     labels:
       type: ocpm.secret.ldap
   type: Opaque
   stringData:
     name: ldap1
     password: camiant
     authDn: uid=PolicyServer,ou=customer1,c=hu,o=customer1

   where, name is the configured LDAP server name.

   password is the LDAP credential for that data source.

   authDN is the authentication DN for that LDAP datsource.

   Note:

   For LDAP data, more entries can be added in the above format with only the key of the entry specifying LDAP name in the Policy Graphical User Interface (GUI).
2. Create the kubernetes secret by executing the following command:

   kubectl apply -f yaml_file_name -n pcf-namespace

   where:

   yaml_file_name is a name of the yaml file that is created in Step 1.

   pcf-namespace is the deployment namespace used by the helm command.

Configure LDAP Server

If you are using LDAP for storing the user profiles, you must configure the LDAP server as the datasource. You can configure the LDAP server using the CNC Console or REST API for Policy.

• Configure using CNC Console: Perform the configurations for LDAP on the Data Sources page. For information on configuring the LDAP server, see Data Sources.
• Configure using REST API: Policy provides the following REST API for LDAP Server configuration:

  API: {apiRoot}/oc-cnpolicy-configuration​/v1/datasources/{datasourceName}

  You can perform the PUT operation to configure the feature. For more information about REST API configuration, see Data Source in Oracle Communications Cloud Native Core, Converged Policy REST API Specification Guide.

After the configuration, you can use blockly action to retrieve resources from the LDAP datasource. For more information, see PDS Category in Oracle Communications Cloud Native Core, Converged Policy Design Guide.

Observe

Policy provides metrics and alerts specific to LDAP Service. For information related to LDAP Gateway metrics, see LDAP Gateway.

4.78 SOAP Support

Policy establishes connections with data sources to retrieve information about subscribers from the database. It queries a data source using a key attribute that uniquely identifies a subscriber and stores the results in its cache. A data source uses this key attribute. For example, the phone or account number of the subscriber to index the information present in the database.

Policy uses the subscriber data to:

• evaluate policy
• define FUP objects
• billing reset mechanism

Figure 4-144 Fetching subscriber data

1. When Policy recevies an SM Create request from SMF, it sends a request to the LDAP server to retrieve the subscriber profile.

   It uses IMSI, MSISDN, SUPI and GPSI to fetch the data.

2. Policy forwards the subscriber data received from LDAP server to PRE for evaluation.

3. Based on the outcome, Policy sends an SM Create response.to SMF.

Further SM Create request, Policy processes the subscriber profile that is cached. If the subscriber profile data is not available, Policy triggers an LDAP read to update the cache. Based on the evaluation of policy, it sends an SM Create Response.

The Policy uses SOAP (1.2 version) data interface to access subscriber data from an external LDAP Source.

1. Policy receives a notification from a SOAP-XML feed when the profile is updated.

   The SOAP notification message contains the changed LDAP attributes only along with the Subscriber Identifier (IMSI/MSISDN) identifying the affected subscriber. The SOAP notification is expected when at least one subscriber session is active on Policy.

2. Policy processes the notification, uses the subscriber identifier available as part of the SOAP notification to trigger additional LDAP search request.
3. It updates the subscriber profile database, and triggers a policy re-evaluation.

   It uses IMSI, MSISDN, SUPI, or GPSI to process the notification.

4. It then acknowledges the notification with a 200 ok response and discards the inactive sessions.

Managing SOAP

To enable the SOAP support, set value of global.soapConnectorEnable parameter to true in the custom_values.yaml file.

For more information about setting the parameter values, see Enabling/Disabling Services Configurations in Oracle Communications Cloud Native Core, Converged Policy Installation, Upgrade and Fault Recovery Guide.

4.79 Support for Timer Configurations

Managing Timer Configurations

The timer profile sets request timeout values for UDR, CHF, BSF, and SMF messages in applications or interfaces. Policy applies the specific timeout profile while sending request to external NFs. The external NFs include UDR, CHF, BSF, and SMF. Policy updates the appropriate metrics in case of such request timeout.

In Policy, Ingress gateway applies operator configured interface specific timeout and use it as request timeout. It also propagate timeout value in 3gpp-Sbi-Max-Rsp-Time header, so that it can be used by back-end services (if required).

Enable or Configure

When back-end service has to originate a message for producer or consumer NF, the following algorithm for applying request timeout value is used:

• When the corresponding timer profile is not associated for the originating service:
  • If incoming request contains 3gpp-Sbi-Max-Rsp-Time header, then use the value specified in 3gpp-Sbi-Max-Rsp-Time header as timeout. For more information about configuring this value, see SBI Timer Header.
  • If the incoming request does not contain the 3gpp-Sbi-Max-Rsp-Time header, then configure the request timeout during deployment or configuration using CNC Console for Policy. For more information about configuring Timer Profile using CNC Console, see Timer Profiles.

• When the corresponding timer profile is associated for the originating service:
  • If incoming request contains 3gpp-Sbi-Max-Rsp-Time header, then use the minimum of the values specified in 3gpp-Sbi-Max-Rsp-Time header and service or default timeout from the profile. For more information about configuring this value, see SBI Timer Header.
• If incoming request does not contain the 3gpp-Sbi-Max-Rsp-Time header,
  • Use service specific timeout, if configured in timeout profile
  • Otherwise use default timeout from the timeout profile

After the above operations, the originating service also set the timeout value in the 3gpp-Sbi-Max-Rsp-Time header to propagate it for any further producer services. Egress Gateway applies the request timeout from the 3gpp-Sbi-Max-Rsp-Time header and finally uses its blocklisted feature to remove this header from egress message.

SBI Timer Header

SBI Timer Headers are implemented at Ingress Gateway. These are taken into consideration while calculating request timeout for a route along with route level (if configured) and global level request timeout.

Enable

To enable the SBI Timer Header, set the ingress-gateway.isSbiTimerEnabled parameter to true, under the ingress-gateway configurations in the custom-value.yaml file for Policy.

If the ingress-gateway.isSbiTimerEnabled parameter is set to true, then

• 3gpp-Sbi-Sender-Timestamp, 3gpp-Sbi-Max-Rsp-Time, and 3gpp-Sbi-Origination- Timestamp parameters are used along with route level and global level request timeout to calculate the final request timeout.
• After calculating the final request timeout, original values of the 3gpp-Sbi-Sender-Timestamp, 3gpp-Sbi-Max-Rsp-Time, and 3gpp-Sbi-Origination- Timestamp parameters are published in the Orig-3gpp-Sbi-Sender-Timestamp, Orig-3gpp-Sbi- Max-Rsp-Time, and Orig-3gpp-Sbi-Origination-Timestamp respective custom headers.

If the ingress-gateway.isSbiTimerEnabled parameter is set to false, then the SBI headers are not taken into consideration even if, they are present and the custom headers are not published.

4.80 Custom AVP to Support Third-Party Vendor Specific AVPs

An Attribute-Value Pair (AVP) is used to encapsulate protocol-specific information supported by CNC Policy. Diameter messages such as RAA, CCA, CCR, and RAR and so on, are supported by third-party AVP policy conditions. The supported outgoing Diameter messages set or remove third-party AVPs.

Policy allows you to create policy conditions to evaluate the presence of both standard (base) and third-party AVPs in Diameter messages or group AVPs during policy execution. A policy condition can check for the presence of both standard and third-party AVPs in incoming Diameter messages and evaluate their values. A policy action can use standard and third-party AVPs for routing, authentication, authorization, and accounting. Standard AVPs can be included in third-party AVP conditions and actions. To include a standard (base) AVP in a nonstandard application message, or to use a pre-standard AVP as a standard AVP, define it as a custom AVP.

Standard AVPs can be included in third-party AVP conditions and actions. To include a standard (base) AVP in a nonstandard application message, or to use a pre-standard AVP as a standard AVP, you must define it as a Custom AVP. When defined, custom AVPs are located at the end of a parent Diameter message or group AVP. If the parent AVP is null, the custom AVP is inserted at the root level of the message.

For example, a custom AVP definition appears at the end of this Charging-Rule-Install message:

 Charging-Rule-Install ::= < AVP Header: 1001 >
*[ Charging-Rule-Definition ]
*[ Charging-Rule-Name ]
*[ Charging-Rule-Base-Name ]
[ Bearer-Identifier ]
[ Rule-Activation-Time ]
[ Rule-Deactivation-Time ]
[ Resource-Allocation-Notification ]
[ Charging-Correlation-Indicator ]
*[ customAVP ]

A Set or Get SPR user attribute value can be set to the defined third-party AVP in Diameter messages. You can also set or remove the defined third-party AVPs during the execution point.

A third-party AVP is identified by a unique identifier in the following format:

name:vendorId

For example:

Condition

where the request AVP NEW_AVP3:555 value is numerically equal to 2012

Parameters

The AVP name and vendor ID. In the example, the vendor ID is 555.

Description

A well-defined AVP custom name is referred to if the vendor ID is not specified.

When entering and sending a new third-party AVP definition to CNC Policy, the definition must include the AVP name, code, vendor ID, data type, and an optional AVP parameter.

Validation of the AVP code, Name, and vendor ID prohibits a user from overwriting the existing base AVPs.

These AVP actions include the ability to perform the following:

• Routing
• Authentication
• Authorization
• Accounting

For more information about custom AVP, see Custom AVP.

Managing Support for Custom AVP

Enable

This is a core functionality of Policy. This feature remains enabled by default.

Configure

You can add and configure the Custom AVPs using the CNC Console or REST API for Policy.

• Configure using CNC Console: Perform the configurations on the Custom AVP page. For more information about configuring PRAs, see Custom AVP.

• Configure using REST API: Policy provides the following REST API to create Custom AVPs:

  API: {apiRoot}/oc-cnpolicy-configuration/v1/policydata/common/customattributes/avp

  You can perform the POST, PUT, or GET operations to configure the Custom AVP. For more information about REST API configuration, see Custom AVP section in Oracle Communications Cloud Native Core, Converged Policy REST Specification Guide.

After the configuration, you can use blockly actions to set values of Custom Values. For more information, see "PCRF-Core Actions" in Oracle Communications Cloud Native Core, Converged Policy Design Guide.

4.81 Adding Subscription-ID AVPs to STR messages

As part of the Final Spending Limit Report Request (SLR) procedure, PCRF sends a Session Termination Request (STR) to Online Charging System (OCS) through PDS and Diam-Connector to unsubscribe from all the Policy Counters belonging to the Diameter session and terminate the session.

OCS uses Subscription-ID AVPs to associate the STR with the SLR and close the session.

Without the Subscription-ID AVPs in STR, OCS returns a DIAMETER_MISSING_AVP 5005 error to STRs.

Figure 4-145 Communicating STR messages

For this purpose, when PDS sends a GET request, the response header oc-data-source-route-info parameter from Diameter-Connector to PDS includes details such as SusbscriptionIdType and UserIds used in SLR from Diameter-Connector.

This same header is used by the PDS in the subsequent OCS request including INTERMEDIATE and TERMINATE requests.

In case of a TERMINATE request, the Diameter-Connector receives the oc-data-source-route-info header from PDS. It extracts SusbscriptionIdType and UserIds if OCS_ENABLE_SUBS_ID_ON_STR is set to true.

It then sends the Subscription-Id AVP in STR message.

Managing the Adding Subscription-ID AVPs to STR messages feature

Enable

You can enable addition of Subscription-Id information in Subscription-Id AVPs using diam-connector.envSyEnableSubsIdOnSTR Helm parameter during installation. For more information, see Diameter Gateway and Diameter Connector Configuration section in Oracle Communications Cloud Native Core, Converged Policy Installation, Upgrade, and Fault Recovery Guide.

Configure

You can configure addition of subscription-Ids using the diam-connector.envSyEnableSubsIdOnSTR Helm parameter during installation.

For more information, see Diameter Gateway and Diameter Connector Configuration section in Oracle Communications Cloud Native Core, Converged Policy Installation, Upgrade, and Fault Recovery Guide.

4.82 Asynchronized Access to nCHF

The Policy solution supports asynchronized access of subscriber related information from data sources such as CHF.

Managing Asynchronized Access to nCHF

Enable

You can enable the Asynchronized Access to nCHF functionality using the CNC Console or REST API for Policy.

• Enable the Enable Async CHF Query parameter under the User group on the PCF Session Management page. For more information, see information about user configurations in PCF Session Management.

• Enable using REST API: Set the enableChfQueryAll parameter value to true in User Configuration of the Session Management Service API. For more information about enabling the feature through REST API, see "Session Management Service" in Oracle Communications Cloud Native Core, Converged Policy REST Specification Guide.

Configure

After enabling this feature, you can perform the necessary configurations using the Fetch Policy Counters from CHF block for the SM service. Configure this block to fetch policy counters through asynchronous CHF lookup.

For more information about configuring the block, see "Public Category" in Oracle Communications Cloud Native Core, Converged Policy Design Guide.

4.83 Nudr to Support OperatorSpecificData

Policy supports custom JSON feature that allows you to configure flexible data schema as part of OperatorSpecificData for policy validation from Nudr interface and apply policies based on the data set. The advantages of this integration are:

• Uses new data type object for data not mapped to standardized fields
• Object contains IDs and map of Operator specific policy set objects (blobs)

  Blobs can be used to store boolean, number, object, array, null, string <JSON, XML, Base64 encoded binary data>, and so on.

• Aligns with 3GPP

Managing Nudr Support for OperatorSpecificData

Enable

You can enable the Nudr Support for OperatorSpecificData functionality using the CNC Console for Policy.

Enable the Enable Operator Specific Data Query parameter under the User group on the PCF Session Management page. For more information about enabling the feature through CNC Console, see PCF Session Management.

Configure

You can use tThe OperatorSpecificData as an input in different Policy Projects. For more information, see Oracle Communications Cloud Native Core, Converged Policy Design Guide.

4.84 Support for Spending Limit Pending Counter

The Policy solution enables you to use activation time in the pending policy counter as input to the Condition Data for either activation time or deactivation time. This functionality is available for condition data used by PCC rules and session rules.

Note:

This functionality is only supported by Session Management (SM) Associations.

Example:

The following is a sample of Spending Limit Pending Counter:

{
 "supi": "imsi-450081100100001",
 "gpsi": "msisdn-9192503899",
 "PolicyCounterIds": [
 {
 "policyCounterId": "silver",
 "currentStatus": "valid",
 "penPolCounterStatuses": [
 {
 "policyCounterStatus": "start",
 "activationTime": "2020-05-16T16:25:00.659Z"
 }
 ]
 },
 {
 "policyCounterId": "gold",
 "currentStatus": "valid",
 "penPolCounterStatuses": [
 {
 "policyCounterStatus": "start",
 "activationTime": "2020-01-01T00:00:00.000Z"
 },
 {
 "policyCounterStatus": "end",
 "activationTime": "2020-12-31T23:59:59.000Z"
 }
 ]
 }
 ]
}

In the above sample, PCF selects one of the policy counters by policyCounterId and policyCounterStatus. After this, PCF uses the activationTime as the activation time or deactivation time for the condition data of PCC Rule or Session Rule, and finally sends the related PCC Rule or Session Rule to SMF.

The existing policies support the spending limit pending counter functionality. You can perform the following configurations:

• Select the activationTime of pending counter by policyCounterId and policyCounterStatus.
• Install PCC Rule or Apply PCC Rule Profile using the activationTime as activationTime or/and deactivationTime of Condition Data of the PCC Rule or PCC Rule Profile.
• Install/Modify Session Rule using the activationTime as activationTime or/and deactivationTime of Condition Data of the Session Rule

For more information on Activation/Deactivation Time of PCC Rules/Session Rules blockly design for policy design, see PCF-SM Category section in Oracle Communcations Cloud Native Core, Converged Policy Design Guide.

A Policy Sample, this sample is used to install session rule using policy pending counter from the above sample.

Installing Session Rule Using Policy Pending Counter

Managing Spending Limit Pending Counter Support

Enable

This feature remains enabled by default.

Configure

You can configure the Spending Limit Pending Counter functionality by configuring the following SM service functions:

• Policy Counter ID: Perform the Policy Counter Id configurations on the Policy Counter ID page. For more information, see Policy Counter Id,
• Condition Data: Perform the Condition Data configurations on the Condition Data page. For more information, see Condition Data.
• PCC Rule: Perform the PCC Rule configurations on the PCC Rule page. For more information, see PCC Rule.
• Session Rule: Perform the Session Rule configurations on the Session Rule page. For more information, see Session Rule.

After the above configurations, you can use blockly action to install session rule/PCC rule using policy pending counter . For more information, see "PCF-SM Category" in Oracle Communications Cloud Native Core, Converged Policy Design Guide.

4.85 XFCC Header Validation

Overview

With XFCC Header Validation feature, Policy (PCF) as a producer, checks if the SCP that is sending the HTTP request is the same SCP that is configured in the PCF. Policy performs this check by comparing the FQDN of the SCP present in the “x-forwarded-client-cert” (XFCC) of http2 header with the list of FQDN of the SCPs configured in the PCF. This configured list contains all the host FQDNs resolved successfully via DNS-SRV as well as static SCPs. The header validation can be enabled at global as well as at the route level.

Note:

This feature is applicable only when SCP is deployed in the network topology.

XFCC header validation applies to all the interfaces of Policy (PCF), which support indirect communication through SCP. The list of the interfaces is as follows:

• AM, SMF, and AF SBI service requests and responses
• UDR, CHF, and NRF notification messages

Configuring SCPs at Policy

To configure SCP, you need to customize custom-values.yaml at the time of deploying Policy.

In the earlier releases, users could only configure SCPs statically as shown in the following snippet:

xfccHeaderValidation:
    validation:
                 
      enabled: false
      nfList:
        - scp.com
        - smf.com
        - amf.com

Starting Policy release 22.1.0, you can configure single or multiple virtual FQDNs for the SCP along with the static configuration as shown in the following snippet:

global:
    xfccHeaderValidation:
      validation:
        enabled: false
        peerList:
          - name: scp.com
          - name: smf.com
          - name: amf.com
          - name: scp1.com
            enabled: true
          - name: scp2.com
          - name: scp3.com
            enabled: false
          - name: xyz.test.com
            enabled: true
            scheme: http
            type: virtual
          - name: abc.test.com
            enabled: true
            scheme: https
            type: virtual
          - name: xfcc.test.com
            enabled: false
            scheme: http
            type: virtual

Static SCP: To define an SCP instance statically, add the name and set enabled parameter to true in the peerList. If the enabled parameter is set to false for an instance, then it is not included in the list of configured FQDNs. If you do not specify enabled parameter then by default it is considered as true.

Virtual SCP: To define an SCP with virtual FQDN, add the name, scheme as http or https, type as virtual, and set enabled parameter to true. If the enabled parameter is set to false for an instance, then it is not included in the list of configured FQDNs.

Resolving FQDNs to find Authorized SCPs for Policy

During the bootup of Ingress Gateway, it tries to resolve the configured virtual FQDN via Alternate Route service using the following helm configuration:

dnsSrv:
    port: *svcAlternateRouteServiceHttp #Alternate-route port for scheme 'http'. Change is required if the scheme below changes.
    scheme: http

If Alternate Route service is unable to resolve the configured virtual host, Ingress Gateway stores it in the list of failed FQDNs and reattempts the request at 300 s (default value configured for dnsResolutionInterval).

The following metric is used when the request to resolve configured virtual FQDNs is unsuccessful:

• oc_ingressgateway_dns_resolution: This metric is pegged when DNS resolution for a given FQDN fails.
• oc_ingressgateway_dns_resolution_failure: This is a gauge metric that is triggered when DNS resolution for a given FQDN fails.

Handling Traffic Flow

The specification for the XFCC header validation of an incoming request with the FQDN's of SCP configured at the IGW are as follows:

1. When a request is received at IGW, it gets forwarded to the back-end micro-service based on the configured rules.
2. The ingress-gateway.xfccHeaderValidation.validation.matchField parameter configured in IGW remains available in the client certificate field of XFCC header. You must validate this parameter with the configured FQDNs of SCP.
3. If multiple XFCC headers are present in the incoming request to IGW, then the IGW validates the ingress-gateway.xfccHeaderValidation.validation.matchField parameter present in each XFCC header against the configured FQDNs of SCP, until a match is found.

There are following scenarios to handle the XFCC header present in the incoming request to IGW:

• Validation of single XFCC header present in the incoming request to IGW
• Validation of multiple XFCC headers present in the incoming request to IGW

Validating single XFCC Header

The following figure describes the call flow for validation of single XFCC header:

Figure 4-146 Call Flow Validating single XFCC Header

Table 4-113 Single XFCC Header Configuration

Prerequisite	Condition	Steps
Given XFCC Header validation parameter is enabled for the corresponding route match and matchCerts count correctly configured.	If the matchField parameter of client certificate field in XFCC header matches with one of the FQDNs of SCP configured.	Forward the request to back-end microservice and receive a corresponding response.
Given XFCC header validation parameter is enabled for the corresponding route match and matchCerts count correctly configured.	If matchField parameter of client certificate field in XFCC header does not match with the FQDNs of SCP configured.	Return 400 Bad Request response from Ingress Gateway.
Given XFCC header validation parameter is not enabled for the corresponding route match.	The matchfield parameter is not considered.	Forward the request to the back-end microservice and receive a corresponding response.

Example of XFCC Header:

x-forwarded-client-cert: By=http://router1.blr.com;Hash=468ed33be74eee6556d90c0149c1309e9ba61d6425303443c0748a02dd8de68; Subject="/C=US/ST=CA/L=San Francisco/OU=Lyft/CN=Test Client"; URI=http://testenv1.blr.com;DNS=blr.com; DNS=www.blr.com

Validating multiple XFCC Headers

The following figure describes the call flow for validation of multiple XFCC header:

Figure 4-147 Call Flow Validating Multiple XFCC Headers

Table 4-114 Multiple XFCC Headers Configuration

Prerequisite	Condition	Steps
Given XFCC header validation parameter is enabled and matchCerts count correctly configured to validate across XFCC header certificates from the right most entry.	If matchField parameter of the corresponding client certificate field being validated against currently in the corresponding XFCC header matches with the FQDNs of SCP configured at Ingress Gateway.	Consider the request as a valid request and forward the request to the back-end micro-service and receive a corresponding response.
Given XFCC header validation parameter is enabled and matchCerts count correctly configured to validate across XFCC header certificates from the right most entry.	If matchField parameter of client certificate field in corresponding XFCC headers do not match with the FQDNs of SCP configured at Ingress Gateway for the corresponding matchCerts count.	Consider the request as an invalid request and return a 400 Bad Request response from IGW. For more information about error codes, see SBI Ingress Error Code Profiles Collection.
Given XFCC header validation parameter is enabled and matchCerts count -1.	The virtual fqdns should get resolved with the help of ARS.	Consider the request as valid request and match against the corresponding match field in all XFCC headers, if validation successful then forward the request else return 400 BAD Request.
Given XFCC header validation parameter is not enabled.	Behaves normally.	Forward the request to back-end microservice and receive a corresponding response.

Example of XFCC Header:

x-forwarded-client-cert:By=http://router1.blr.com;Hash=468ed33be74eee6556d90c0149c1309e9ba61d6425303443c0748a02dd8de68; Subject="/C=US/ST=CA/L=San Francisco/OU=Lyft/CN=nf1.com"; URI=http://testenv1.blr.com; DNS=nf8.com; DNS=nf1.com; DNS=nf6.com, By=http://router1.blr.com;Hash=468ed33be74eee6556d90c0149c1309e9ba61d6425303443c0748a02dd8de68; Subject="/C=US/ST=CA/L=San Francisco/OU=Lyft/CN=nf10.com"; URI=http://testenv1.blr.com; DNS=nf10.com; DNS=nf8.com; DNS=nf9.com, By=http://routexr1.blr.com;Hash=468ed33be74eee6556d90c0149c1309e9ba61d6425303443c0748a02dd8de68; Subject="/C=US/ST=CA/L=San Francisco/OU=Lyft/CN=nf4.com"; URI=http://testenv1.blr.com; DNS=nf9.com; DNS=nf4.com;DNS=nf1.com

Managing XFCC Header Validation

Enable

• Global Level: To enable or disable the XFCC header validation feature, set the value of the ingress-gateway.global.xfccHeaderValidation.validation.enabled to true or false respectively.
• Route Level: To enable or disable the XFCC header validation feature at route level, set the value of the xfccHeaderValidation.validationEnabled under routesConfig to true or false respectively.

  Note:

  If the xfccHeaderValidation.validationEnabled parameter is defined at route level, then the configuration takes precedence over global configuration.
  For instance, if you want to enable XFCC header validation for selected routes, then set the global parameter as false and make route specific configuration to true.

  global:
      xfccHeaderValidation:
        validation:
          enabled: false

  routesConfig:
      - id: sm_create_session_route
        uri: http://{{ .Release.Name }}-occnp-pcf-sm:{{ .Values.global.servicePorts.pcfSmServiceHttp }}
        path: /npcf-smpolicycontrol/*/sm-policies
        order: 1
        method: POST
        readBodyForLog: true
        filters:
          subLog: true,CREATE,SM
        metadata:
          xfccHeaderValidation:
            validationEnabled: true

For more information about setting the parameter values, see "XFCC Header Validation Configuration" section in Oracle Communications Cloud Native Core, Converged Policy Installation, Upgrade and Fault Recovery Guide.

Configure

You can configure the various parameters related to XFCC Header Validation feature in the custom-values.yaml. For more information, see "XFCC Header Validation Configuration" section in Oracle Communications Cloud Native Core, Converged Policy Installation, Upgrade and Fault Recovery Guide.

Observe

The XFCC Header Validation feature can be observed using the metrics specific to Ingress Gateway. For information related to Ingress Gateway metrics, see Ingress Gateway Metrics.

Configuring Error Codes

When the XFCC header validation feature is enabled and SCP FQDN in the incoming header does not match the configured FQDN in PCF, XFCC header is not present, or XFCC header is invalid, then PCF may return error in the response. Users have the ability to customize the error code returned in the response using the following helm configuration:

errorTrigger:
          - exceptionType: XFCC_HEADER_INVALID
            errorCode: '401'
            errorCause: xfcc header is invalid
            errorTitle: 'Invalid XFCC Header'
            errorDescription: 'Invalid XFCC Header'
          - exceptionType: XFCC_MATCHCERTCOUNT_GREATER_THAN_CERTS_IN_HEADER
            errorCode: '402'
            errorCause: matchCerts count is greater than the certs in the request
            errorTitle: ''
            errorDescription: ''
          - exceptionType: XFCC_HEADER_NOT_PRESENT_OR_EMPTY
            errorCode: '403'
            errorCause: xfcc header is not present or empty in the request
            errorTitle: ''
            errorDescription: ''

If the configured error code in the errorCodeOnValidationFailure field lies in 3xx error series only then the values for retryAfter and redirectUrl if configured under XFCC Header Validation Configuration at Ingress Gateway are used to populate Retry-After and LOCATION headers correspondingly while sending error response from Ingress Gateway.

4.86 Policy Event Records

The Policy Event Records feature enables you to view transaction related information that includes input data set, policies that were evaluated, and resulting policy actions from any transactions. Policy event records provides an insight on the policy flow, conditions that are executed, and policy actions enforced by the Policy solution. Single record is generated including the following information:

• Transaction and input Data input set
• Executed policies
• Flow of the executed policies
• Executed instructions or rules
• Policy results and actions

The format of this data is in accordance with the JSON format.

Following are the attributes of the JSON schema:

• policyStartTime
• policyRequest
• policyExecution
• policyEndTime
• policyResponse

Sample Schema:

{
    "policyStartTime": "2021-09-14T09:00:37.261Z",
    "policyRequest": {
      "request": {
        "requestType": "SMF",
        "operationType": "CREATE"
      }
    },
    "policyExecution": "[\" Start evaluating policy main\",\"utils.getAttributeVal(['request.request.operationType'], request) == 'CREATE' evaluates to be true\",\" INSTALL  Session Rules  
     ['sessionRule2']\",\" End evaluating policy main\"]",
    "policyEndTime": "2021-09-14T09:00:37.262Z",
    "policyResponse": {
      "actions": [],
      "customAttributeActions": [],
      "variables": {},
      "ruleActions": [
        {
          "actionType": "INSTALL",
          "ruleType": "SESSION_RULE",
          "sessionRule": [
            {
              "sessRuleId": "sessionRule2"
            }
          ]
        }
      ]
    }
  }

For more information on configuration parameters related to policy event records, see General Settings section.

4.87 URSP Policy Support

With this enhancement, you should be able to define URSP policy in PCF and deliver the policy to UE. UE Route Selection Policy (URSP) is used by the UE to determine how to route outgoing traffic. Traffic can be routed 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.

• UE policy service should be able to establish UE Policy Association requested by the NF service consumer
• UE policy service should be able to define and deliver URSP message to UE via AMF using N1N2 message

For more information about configuring URSP, see URSP Rule.

Managing URSP

Enable

This is a core functionality of Policy. It remains enabled by default.

Configure

You can configure the URSP Rules using the CNC Console or REST API for Policy.

• Configure using CNC Console: Perform the feature configurations on the URSP Rule page. For more information on configuring the feature through CNC Console, see URSP Rule.
• Configure using REST API: Policy provides the following REST API for URSP configuration:

  API: {apiRoot}/oc-cnpolicy-configuration​/v1/policydata​/pcfue/ursps

  You can perform the POST and PUT operation to configure the feature. For more information on REST API configuration, see "URSP" in Oracle Communications Cloud Native Core, Converged Policy REST Specification Guide.

Observe

Policy provides the UE service metrics for observing all the features related to the service. For more information, see the UE Service metrics in UE Service Metrics.

4.88 AF Integration over Rx

Rx interface handling supports the following:

• Diameter session management (creation, modification and deletion)
• Session association and trigger policies on N7 interface with PCC rules
• Compliant with 29.214 V15.1.0
• Integration with BSF for session binding management
• Integration with UDR for updating policyInfo and SM policy association

4.89 IMS Emergency Session Support

This feature allows a caller to contact local eCNC Policymergency services, such as Police, Fire departement, or ambulance for assistance. To ensure uninterrupted services, separate Data Network Names (DNNs) are defined to support the emergency services sessions. The subscription related information is not relevant for such sessions.

The IMS Emergency Support provides the folowing capabilities:

• • All the devices, with or without SIM can trigger an emergency session and provided access to the emergency services
  • The local operator policies are applied for QoS determination

The following figure describes the call flow for the Emergency Session handling in Policy:

Figure 4-148 Call Flow - IMS Emergency

• SMF sends an HTTP POST message for establishing SM Policy Association and the "dnn" attribute including the Emergency DNN. The SMF includes the SUPI within the "supi" attribute and the GPSI if available within the "gpsi" attribute.
• The PCF detects that the PDU session is restricted to IMS Emergency services when the HTTP POST message is received and the "dnn" attribute includes a data network identifier that matches one of the Emergency DNs from the configurable list.
• Then, suitable PCC Rules are applied restricting the access to Emergency Services in a response message.

  Note:

  Policy does not support the IMS restoration for emergency sessions.

Managing IMS Emergency

Enable

This feature remains enabled by default.

Configure

You can configure the IMS Emergency functionality using the CNC Console or REST API for Policy.

• Configure using CNC Console:
  • To configure emergency DNN which allows for N7 request to be successful without MSISDN or IMSI, perform the feature configurations under the IMS Emergency Session group on the PCF Session Management page. For more information, see PCF Session Management Service.
  • To configure emergency DNN for Rx calls, perform the feature configurations under the IMS Emergency Session group on the PCF Policy Authorization page. For more information, see PCF Policy Authorization.
• Configure using REST API: Policy provides the following REST API for Binding mechanism configuration:
  • To configure emergency DNN which allows for N7 request to be successful without MSISDN or IMSI:

    API: {apiRoot}/oc-cnpolicy-configuration/v1/services/pcfsm

    You can perform the PUT operation to configure the feature. For more information on REST API configuration, see IMS Emergency Session Configuration of the "Session Management Service" in Oracle Communications Cloud Native Core, Converged Policy REST API Specification Guide.

  • To configure eergency DNN for Rx calls:

    API: {apiRoot}/oc-cnpolicy-configuration/v1/services/pcfpa

    You can perform the PUT operation to configure the feature. For more information on REST API configuration, see IMS Emergency Session Configuration of the "Policy Authorization Service" in Oracle Communications Cloud Native Core, Converged Policy REST API Specification Guide.

After the configuration, you can use the blockly actions for IMS Emergency related action. For more information, see "IMS Emergency Session Support" in Oracle Communications Cloud Native Core, Converged Policy Design Guide.

Observe

Policy provides metrics and alerts specific to SM service and Policy Authorization service.

For information related to SM service metrics, see SM Service Metrics.

For information related to Policy Authorization service metrics, see PA Service Metrics.

4.90 IMS Restoration

Policy supports restoring an IMS network as defined in 3GPP TS 29.212V15.4.0.

Also, it supports enhancements to the restoration procedure as defined in 3GPP TS 29.214V15.4.0.

Note:

This feature is applicable only for PCRF flows in Converged mode of deployment.

The automatic restoration procedure involves:

1. If AF provisions information about the AF signalling flows between the UE and the AF, PCRF installs the corresponding dynamic PCC rules by triggering a RAR message.

2. The PCRF provides the Charging-Rule-Install AVP including the Charging-Rule-Definition AVP(s).

   The Charging-Rule-Definition AVPs include:

   • the flow-Information AVP, the signalling flows between UE and the AF.
   • AF-SignallingProtocol AVP set to the value corresponding to the signalling protocol used between the UE and the AF.
3. PCRF shares the AF address with PCEF.
4. PCEF:
   1. Responds to PCEF with a RAA message.
   2. Initiates the corresponding bearer procedure if required.
   3. Extracts the AF address from the PCC rules.
   4. Checks if the monitoring procedure must be started for the corresponding AF.
   5. Starts the monitoring procedure as defined for the different access types.

In case AF de-provisions the information about the AF signalling flows between the UE and the AF, as defined in 3GPP TS 29.214 [10] Section 4.4.5a:

1. PCRF removes the corresponding dynamic PCC rules by triggering a RAR message.
2. PCRF sends the Charging-Rule-Remove AVP including the corresponding Charging-RuleName AVP(s) to PCEF.
3. PCEF uses the AF address associated with the removed rule to check if it can stop monitoring the corresponding AF.
4. PCEF acknowledges by sending a RAA command to the PCRF.

In case of P-CSCF restoration enhancement,

1. PCRF receives a request for P-CSCF restoration from the P-CSCF.
2. PCRF sends a Gx RAR command including the PCSCF-Restoration-Indication AVP set to value 0 (PCSCF_RESTORATION) to the PCEF for the corresponding Gx session.
3. PCEF acknowledges the RAR command by sending an RAA command to the PCRF and initiates the corresponding bearer procedure for the IMS PDN connection as defined in 3GPP TS 23.380 [33].

4.91 Automated Test Suite Support

Policy provides Automated Test Suite (ATS) for validating different functionalities. ATS allows you to execute Policy test cases using an automated testing tool, and then compares the actual results with the expected or predicted results. In this process, there is no intervention from the user is required. For more information, see Oracle Communications Cloud Native Core, ATS User Guide.

4.92 Notification Handling from PDS for PCRF-Core

In earlier releases, PCRF-Core could communicate with 4G UDR and OCS (Sy interface) through Diameter Gateway. PCRF-Core could communicate with LDAP through PDS. With the latest enhancements, PCRF-Core can now communicate with 5G nUDR through PDS to fetch SmPolicyData.

As illustrated in the following call flow diagram, when PCRF-Core receives notify request with SUPI or GPSI from PDS for smPolicyData, that is, from nUDR - PCRF-Core initiates reauthorization request, and populates PolicyUser structure. Then, it sends the evaluation request to PRE. PRE further evaluates policy based on the new structure received. If installed rules or any of its related fields are different from the PRE Evaluation result, then PCRF-Core triggers a RAR request towards PGW.

Figure 4-149 Call flow for notification handling from PDS for PCRF-Core

Enable

To enable this feature, set the values for the following fields to true, on Settings page:

• SmPolicyData (Enable)
• Subscribe to Notify (SmPolicyData Attributes)

4.93 Service mesh for intra-NF Communication

Policy leverages the Istio or Envoy service mesh (Aspen Service Mesh) for all internal and external communication. The service mesh integration provides inter-NF communication and allows API gateway co-working with service mesh. The service mesh integration supports the services by deploying a special sidecar proxy in the environment to intercept all network communication between microservices.

The Aspen Service Mesh (ASM) configurations are classified into:

• Control Plane: It involves adding labels or annotations to inject sidecar.
• Data Plane: It helps in traffic management like handling NF call flows by adding Service Entries (SE), Destination Rules (DR), Envoy Filters (EF) and other resource changes like apiVersion change between versions. This is done manually depending on each NF requirement and ASM deployment.

Managing Service mesh for intra-NF Communication

Enable

To enable Aspen Service Mesh, configure the following parameters under nrf-client-nfdiscovery, ingress-gateway, egress-gateway, and alternate-route sections in the custom values file for Policy:

• serviceMeshCheck
• istioSidecarQuitUrl
• istioSidecarReadyUrl

For more information on enabling the parameter value, see "Aspen Service Mesh Configurations" in Oracle Communications Cloud Native Core, Converged Policy Installation, Upgrade and Fault Recovery Guide.

Configure

The Aspen Service Mesh (ASM) configurations are classified into:

• Control Plane: For information on configuring the parameter values, see "Aspen Service Mesh Configurations" in Oracle Communications Cloud Native Core, Converged Policy Installation, Upgrade and Fault Recovery Guide.
• Data Plane: For information about Data plane configurations, see "Aspen Service Mesh Data Plane Configurations" in Oracle Communications Cloud Native Core, Converged Policy Installation, Upgrade and Fault Recovery Guide.

4.94 Turning off AccessToken signature Validation

OAuth access tokens are used to grant an NF service consumer access to the services of an NF producer of a particular NFType for a specific period of time. With this feature, Policy has the capability to turn off AccessToken signature validation at the application layer. For instance, when service mesh, for example Aspen service mesh, is integrated with Policy, the service mesh may perform the AccessToken validation. In such cases, operator may want Policy to skip validating AccessToken signature. It checks audience and scope fields only, and send 403 - Forbidden response when any of the values do not match. In addition, when Policy receives a request without AccessToken, it sends a 401 - Unauthorized response code.

Configure

To turn of AccessToken signature validation at PCF application, the user must perform configurations that are described in the Oracle Communications Cloud Native Core, Converged Policy Installation, Upgrade and Fault Recovery Guide..

4.95 Pending Transactions on N7 and N15 Interface

Policy Charging and Control (PCC) services, such as Npcf_SMPolicyControl, Npcf_AMPolicyControl service, etc. allow the NF producer to update a given policy association in the following two ways:

1. Unsolicited – In the unsolicited method, NF producer provides updates to the NF consumer using UpdateNotify service operation. For instance, if PCF is a NF producer that needs to notify SMF (NF consumer) about a policy association in an unsolicited manner, then PCF initiates UpdateNotify service operation for Npcf_SMPolicyControl service.
2. Solicited – In the solicited method, NF producer sends a response on receiving a request from the NF consumer. For instance, PCF installs policy decisions on receiving Npcf_SMPolicyControl_Update service request from SMF.

As the request can be initiated by either consumer or producer network function, a situation may arise when requests to modify the same policy are initiated concurrently. Additionally, if an HTTP proxy say Service Communication Proxy (SCP) is deployed for communication between network functions, the messages may get delivered out of order thereby resulting in wrong information maintained for a policy association by NF producer and NF consumer.

Feature Negotiation

Once the feature has been enabled, feature negotiation needs to happen between SMF and PCF during Npcf_SMPolicyControl_Create service operation. As defined by the 3GPP feature negotiation mechanism, the following conditions must be met for SMF and PCF to agree upon the Pending transactions feature:

• NF consumer or SMF advertises "PendingTransaction" feature within the attribute supportedFeatures (suppFeat) when sending a request to create SM policy association.
• In turn, PCF advertises the same value for the supportedFeatures (suppFeat) while sending the response for the policy association create request.

Enable

By default, this feature is not configured on the Policy deployment. You can opt to configure the Pending Transactions on N7 and N15 interface using the CNC Console or REST API.

On PCF Session Management and PCF Access and Mobility page, under Service Configurations, select PendingTransaction from the drop-down menu of Override Supported Features parameter. For more information about the configurations, see PCF Session Management.

Using the REST APIs for Session Management Service, you can enable the feature by updating the value as PendingTransaction for the following parameter under the system group:

overrideSupportedFeatures": [
      "PendingTransaction"
    ],

Configure

Perform the configurations for the pending transactions on N7 and N15 features using the CNC Console or REST API:

Perform the feature configurations on the PCF Session Management page. For more information about the configurations, see PCF Session Management.

Using the REST APIs for Session Management Service, you can configure the feature by updating the values of parameters under the pendingTransaction group:

pendingTransaction": {
    "updateNotifyRetryBackoff": 1000,
    "updateNotifyRetryCount": 2
  },

No helm configurations are required for this feature.

Observe

The existing Ingress and Egress Gateway metrics have been enhanced for this feature.

• ocpm_ingress_request_total
• ocpm_ingress_response_total
• ocpm_egress_request_total
• ocpm_egress_response_total

The following metrics have been added for this feature.

• occnp_http_in_conn_response_total
• occnp_http_in_conn_request_total
• http_bulwark_lock_request_total
• http_bulwark_unlock_request_total
• http_bulwark_lock_response_total
• http_bulwark_lock_request_retry_total
• http_bulwark_unlock_request_retry_total
• occnp_http_ue_request_total
• occnp_http_ue_response_total

No new alerts are introduced for this feature.

Maintain

Logs are generated when the system returns with a 400 error message for a pending transaction. The following is a sample log for SM update-notify request in case of Pending Transaction:

{
  "instant": {
    "epochSecond": 1633660911,
    "nanoOfSecond": 292427900
  },
  "thread": "boundedElastic-4",
  "level": "DEBUG",
  "loggerName": "ocpm.pcf.service.sm.domain.component.SmfManager",
  "message": "is400BadRequestWithPendingTransaction: true",
  "endOfBatch": false,
  "loggerFqcn": "org.apache.logging.slf4j.Log4jLogger",
  "threadId": 166,
  "threadPriority": 5,
  "messageTimestamp": "2021-10-07T22:41:51.292-0400"
}

The following is a sample log when lock is acquired for SM update request:

{
  "instant": {
    "epochSecond": 1633660909,
    "nanoOfSecond": 626486627
  },
  "thread": "PartitionedCacheWorker:0x0000:15",
  "level": "DEBUG",
  "loggerName": "ocpm.common.bulwark.repository.processor.LockProcessor",
  "message": "Lock is acquired for a key: bf87d498-0849-42f3-86ff-d015a97b5721 with value: {\"lockID\":\"bb666052-270a-4e0a-b4a5-017852c86fe3\",\"ttl\":3000,\"serviceInfo\":{\"serviceName\":\"serviceId\",\"serviceID\":\"serviceName\"}}",
  "endOfBatch": false,
  "loggerFqcn": "org.apache.logging.slf4j.Log4jLogger",
  "threadId": 41,
  "threadPriority": 5,
  "messageTimestamp": "2021-10-08T02:41:49.626+0000"
}

4.96 Pending Transactions on Gx Interface

Pending transaction functionality handles race condition and retry logic for Gx messages (CCR-U and RAR).

Feature Negotiation

Once the feature has been enabled, feature negotiation needs to happen between PGW and PCRF during CCR-I operation. As defined by the 3GPP feature negotiation mechanism, the following conditions must be met for PGW and PCRF to agree upon the Pending transactions feature:

• NF consumer or PGW advertises "PendingTransaction" feature within supportedFeatures (AVP) when sending a request to create PCRF.
• In turn, PCRF advertises the same value for the supportedFeatures (AVP) while sending the response for the PGW as a CCA-I message.

Enable and Configure

By default, this feature is not configured on the Policy deployment. You can enable and configure the Pending Transactions on Gx interface using the CNC Console and REST API.

You can configure the pending transaction configurations under Pending Transaction section in Settings page for PCRF Core on Oracle Communications Cloud Native Core, Cloud Native Configuration Console (CNC Console). For more details, see Settings.

Using the REST APIs for Session Management Service, you can configure the feature by updating the values of parameters under the pendingTransaction group:

{
    "pendingTransaction": {
        "enabled": true,
        "rarRetryBackoff": "800",
        "rarRetryCount": "2",
        "userNotifyReauthErrorHandling": 1,
        "afReauthErrorHandling": 1,
        "reauthErrorHandling": 1,
        "waitGxUpdateBeforeRejectDuration": 0,
        "skipPolicyEvaluationOnReauthRetry": true
    }
}

For more information, see "PCRF Core Service" section in Oracle Communications Cloud Native Core, Converged Policy REST API Specification Guide.

Note:

In Rx interface sync mode, the diameter configuration response timeout must be configured till the retry exhausts. The response timeout is calculated as Retry Backoff multiplied by Retry Count. The response timeout must be updated in the CNC Console.

When the pending transactions on Gx interface feature is disabled and there is an error in the Gx RAA triggered by Rx interface in sync mode, then the AAA is not accepted as the message could not re-authenticate the primary session.

Observe

The following metrics have been added or enhanced for this feature:

• occnp_app_request_local_process_total
• occnp_app_response_local_process_total
• occnp_diam_response_local_total

For more information, see PCRF Core Metrics.

4.97 NRF Client Retry and Health Check

With the alternate route retry feature, Policy can attempt service requests to an alternate secondary Network Repository Function (NRF) when the primary NRF throws errors. In addition, the health status check feature actively monitors the health of the NRFs and provides the list of the healthy NRFs for session requests only. The NRF client also provides the health information of NRFs to other services if requested, and notifies any change in the health status.

For a given service request, the NRF client initiates a request towards a healthy and the highest priority NRF. If the NRF client receives a failure response for the request or the request timed-out, it attempts to send the request to the same NRF for NrfRetryConfig.primaryNrfRetryCount number of times. If a success response is received before the retry count gets exhausted, NRF client accepts the response and does not send any further service requests. However, if NRF client fails to receive a success response, it attempts to send the service request to an alternate NRF. The alternate NRF is selected based on the assigned priority and health status.

If the NRF Client receives a retryAfterTime value in the response header from the NRF, the NRF Client halts any further attempts to the NRF and flags the NRF as unhealthy for the specified time period. The NRF client retries the service request to alternate NRFs until any one of the following conditions are met:

• NRF-client receives a success response.
• NrfRetryConfig.alternateNRFRetryCount is exhausted.
• All attempts to available healthy NRFs are exhausted.

Once any of the listed conditions are met, NRF-client accepts the response and proceeds.

NRF Client marks NRF as unhealthy under the following conditions:

• If the NRF Client receives a retryAfterTime value in the response header from the NRF, then NRF will be unhealthy for a time period as defined in retryAfterTime.
• If the status code received is available in the default values for errorCodeReasonsForFailure, then NRF will be unhealthy for a period of time as defined in ConfigMap.data: profile.retryAfterTime.
• If the status code received is available in the default values for errorCodeReasonsForFailure and all the retry attempts are exhausted.
• If NRF Client receives an error from Gateway service and the error is configured in the gatewayErrorCodes with all the exhausted retry attempts.

Note:

• If NRF Client receives an error from Gateway service and the error is not configured in the gatewayErrorCodes, then NRF remains marked as healthy.
• HealthCheckConfig and NRFRetryConfig must be configured for the NRF Client functionality to work as expected.
• NRF Client considers a response as failure only when it is configured in the errorReasonsForFailure parameter in the custom-values.yaml file. The primary and non-primary NRFs must be geo-redundant for the NRF Retry mechanism to work.
• For autonomous procedures such as NfRegistration, NfHeartbeat, NfStatusSubscribe (BSF, CHF, and UDR), and NfDiscovery, NRF-client continues to retry sending service requests till a success response is received.

  For details on NRF Client configuration parameters, see NRF Client Configuration section in Oracle Communications Cloud Native Core, Converged Policy Installation, Upgrade and Fault Recovery Guide.

4.98 Support for PCF Status on NRF on CNC Console

Policy provides a consolidated status of the PCT registered with NRF.

The NRF Status is available under Discovered NF Instances section in Status and Query page on CNC Console.

Under Discovered NF Instances page, you can also view the health status of primary and secondary NRFs, or alternate NRF.

This feature is available for Converged and PCF only deployment modes.

To view the status using CNC Console, see NF Data.

4.99 Support for Stale Binding Detection in BSF

To support BSF to query PCF for suspected stale binding records, the Binding service has been made mandatory in the PCF mode of deployment. In BSF, whenever a binding record is detected as stale on the expiry of its binding age, BSF may send a query to PCF to confirm its status. To support this query to PCF, PCF is first required to send the Vendor-Specific-Attribute containing PCF Notification URL in the Binding Register request. When PCF sends the Vendor-Specific-Attribute in the register request, it is also required to provide the vendorID.

To configure this support, the following two new parameters are added to the Binding Service configurations page:

• Enable Vendor-Specific-Attribute In Register Request
• VendorId

Considering that the support for stale binding detection in BSF is enabled, the following diagram describes the call flow between BSF ad PCF. BSF on receiving an Audit notification request, sends the Audit Notification request to PCF Binding Service via Ingress Gateway. Then, Binding Service sends a request to the PCF Query Service to check if the ContextId (SmPolicyAssociation) exists. If it exists, PCF Bindig service responds with 200 OK.

If the ContextId (SmPolicyAssociation) does not exist, Query service sends 404 Not Found to Binding Service. Then, Binding service returns the same response to BSF.

In case Policy is unable to process the Audit Notification request due to any failures, then it returns the 500 Internal Server error response to BSF.

Figure 4-150 BSF and PCF Interaction for Stale Binding Detection

Based on the system configurations, Policy supports receiving 3gpp-Sbi-Binding header in the Audit Notification requests from BSF. Then, it updates the record in its database and send the updated 3gpp-Sbi-Binding header in the response for Audit Notification request.

Metrics

The following metrics are implemented for this feature:

• occnp_binding_query_request_count
• occnp_binding_query_response_count

Logs

Policy generates logs for request and response messages from BSF including the VSA attribute. In addition, it generates logs for audit notifications requests and responses sent for it.

4.100 Pod Protection at Ingress Gateway

This section describes how to protect the Ingress Gateway pods when they are overloaded with numerous incoming requests.

The Ingress Gateway pods are not protected against any incoming traffic congestion. As a result, the pods are overloaded and congested. This impacts system latency and performance. It also leads to stability issues due to uneven distribution of connections and traffic on Ingress Gateway pods. As a front end microservice for HTTP traffic, it is important for Ingress Gateway to have pod protection implemented.

Policy 25.1.200 or later versions support configuring Rate Limiting for Ingress Gateway service in order to provide pod protection by throttling inbound requests, if they are above configured rate.

Pod protection by rate limiting can be enabled and configured using podProtectionByRateLimiting helm parameters.

Note:

Currently, Policy does not support congestion control and message priority capabilities for Ingress Gateway.

Managing Pod Protection at Ingress Gateway

Enable

Pod protection by rate limiting can be enabled by configuring the value of podProtectionByRateLimiting.enable Helm parameter to true.

For more information, see Basic Configurations in Ingress Gateway section in Oracle Communications Cloud Native Core, Converged Policy Installation, Upgrade, and Fault Recovery Guide

Configure

Pod protection at Ingress Gateway is configured using Helm parameters at the time of installation.

Pod protection by rate limiting can be configured using podProtectionByRateLimiting Helm parameter.

For more information, see Basic Configurations in Ingress Gateway section in Oracle Communications Cloud Native Core, Converged Policy Installation, Upgrade, and Fault Recovery Guide.

Observability

Alerts

POD_PROTECTION_BY_RATELIMIT_REJECTED_REQUEST alert is used for Pod protection by rate limiting. For more information, see POD_PROTECTION_BY_RATELIMIT_REJECTED_REQUEST.

4.101 Support for Concurrency Handling using Bulwark Service in Policy

Policy supports the Bulwark service to handle the concurrent requests coming from other Policy services. Bulwark Service provides lock and unlock mechanism over a SUPI or GPSI key and allows only one notification at a time to proceed.

The Policy Services sends the following parameters to request a lock:

• Key: The key is the identifier value with which the lock is identified. You can select either SUPI or GPSI value to be the key parameter for which the lock acquisition request must be made. By default, SUPI values are used for lock requests.
• Lease Duration: This value defines the duration for which lock is kept once the acquisition is successful. After this duration, the lock will be released automatically.

  Note:

  If the Lease Duration is shorter than the request processing time, then there could be chance of conflict and concurrency handling may not work.

  Note:

  The maximum and minimum configured value of Lease Duration has been fixed by Engineering as 15000 ms and 10 ms respectively. If the given Lease Duration value is higher than the maximum configured value, then it is overwritten to 15000 ms. If the given Lease Duration is lower than the minimum configured value, then it is overwritten to 10 ms.

• Lock Wait Timeout: This defines the duration by which the Policy services wait for the response to get a lock. The same duration is used by Bulwark to poll for the lock in case the lock is not available. The Lock Wait timeout is also considered as the polling interval which sends the request towards Bulwark service periodically to acquire the lock for another create or delete request.
• Retry Count: This defines the count of retry attempts that are made by the Policy services if a lock request fails. In case all the retry attempts fail, the create or delete request is rejected. By default, 3 retry attempts are enabled.

4.101.1 Support for Concurrency Handling using Bulwark Service in SM

The Bulwark Service integrates with the SM service to handle the concurrent requests for the SM Create, SM Update, SM Delete, SM Update-Notify, and SM Clean procedures. The SM service integration with Bulwark service handles the concurrent requests for the same subscriber in a concurrent and efficient manner.

In case of multiple create, update, delete, or clean requests for the same subscriber, the SM service requests a lock for the SUPI or GPSI value from the Bulwark service. Once the lock is acquired, the SM create, SM Update, SM delete, SM Update-Notify, or SM Clean request is executed for the SUPI or GPSI value with which the lock is requested. After the successful completion of the requests, the SM service sends a request to release the lock to Bulwark.

As the notification is locked, pending transaction comes into picture.

When Bulwark-Service is Enabled, the following scenarios can occur between pending transaction and SM Update:

Table 4-115 Pending Transaction and Concurrency in SM Update

Pending Transaction	Concurrency in SM Update	Use-Case
Enabled	Disabled	Single Key - Session level lock will be acquired. Pending-transaction call flow would work.
Disabled	Enabled	Single Key - Subscriber level lock will be acquired. Update-Notify call flow with concurrency would work.
Enabled	Enabled	Multi-Key - Session Level & Subscriber Level locks will be acquired.

When Bulwark-Service is Enabled, the following scenarios can occur between pending transaction and update-notify:

Table 4-116 Pending Transaction and Concurrency in SM Update-Notify

Pending Transaction	Concurrency in Update-Notify	Use-Case
Enabled	Disabled	Single Key - Session level lock will be acquired. Pending-transaction call flow would work.
Disabled	Enabled	Single Key - Subscriber level lock will be acquired. SM-Update call flow would work.
Enabled	Enabled	Multi-Key - Session Level & Subscriber Level locks will be acquired.

When Bulwark-Service is Enabled, the following scenarios can occur between pending transaction and SM Update and SM update-notify:

Table 4-117 Pending Transaction and Concurrency in SM Update as well as SM Update-Notify

Pending Transaction	Concurrency in SM Update	Concurrency in SM Update-Notify	Use-Case
Enabled	Disabled	Disabled	Session Level Lock Acquired - during collision, lock acquisition fails at SessionID
Disabled	Enabled	Disabled	Subscriber Level lock acquired - during collision, lock acquisition fails at subscriberID
Disabled	Enabled	Enabled	Subscriber Level lock acquired - during collision, lock acquisition fails at subscriberID
Enabled	Enabled	Disabled	Session Level & Subscriber Level locks will be acquired - during collision, lock acquisition will fail at SessionID

Call Flow for handling concurrent requests for SM Service

Call Flow for SM Create Request

The following diagram shows a scenario for SM create call flow where no service responds with error:

Figure 4-151 Call Flow - Bulwark Lock Request SM Create Procedure

Call Flow for SM Update-Notify Request

The following diagram shows a scenario for SM Update-Notify call flow for one notification and one session:

Figure 4-152 Call Flow for SM Update-Notify Request (One Notification and One Session)

1. PDS sends a notify request to SM service.
2. SM service fetches the corresponding sessions from database and sends a success response to PDS.
3. A notify request tries to acquire the lock from bulwark service and gets the lock.
4. The notify request starts processing by fetching the session.
5. SM service sends a request to PRE for policy evaluation. PRE, in turn replies with the Policy Decision.
6. SM policy association is saved in DB.
7. On successful save, a notify response is sent to SMF and the lock is released.

The following diagram shows a scenario for SM Update-Notify call flow for one notification and n sessions:

Figure 4-153 Call Flow for SM Update-Notify Request (One Notification and n Sessions)

1. PDS sends a notify request to SM service.
2. SM service fetches the corresponding sessions from database and sends a success response to PDS.
3. A notify request tries to acquire the lock from bulwark service and gets the lock.
4. The notify request starts processing by fetching each sessions one by one.
5. SM service sends a request to PRE for policy evaluation. PRE, in turn replies with the Policy Decision.
6. SM policy association is saved in DB.
7. On successful save, a notify response is sent to SMF and the lock is released.
8. This process gets repeated for n sessions of the Notify request.

The following diagram shows a scenario for SM Update-Notify call flow for two notifications and one session:

Figure 4-154 Call Flow for SM Update-Notify Request (Two Notifications and 1 Session)

1. PDS sends a notify request to SM service.
2. SM service fetches the corresponding sessions from database and sends a success response to PDS.
3. First notify request tries to acquire the lock from bulwark service and gets the lock.
4. Meanwhile, if second notify request tries to acquire lock, it will get an already locked response from Bulwark.
5. First notify request starts processing by fetching each sessions one by one.
6. SM service sends a request to PRE for policy evaluation. PRE, in turn replies with the Policy Decision.
7. SM policy association is saved in DB.
8. On successful save, a notify response is sent to SMF and the lock is released.
9. Then the second notify request will retry to acquire the lock. On lock acquisition, the same process is followed for second request as well.

The following diagram shows a scenario for SM Update-Notify call flow for two notifications from same subscriber and n sessions each:

Figure 4-155 Call Flow for SM Update-Notify Request (Two Notifications from Same Subscriber and n Sessions Each)

1. PDS sends a notify request to SM service.
2. SM service fetches the corresponding sessions from database and sends a success response to PDS.
3. First notify request tries to acquire the lock from bulwark service and gets the lock.
4. Meanwhile, if second notify request tries to acquire lock, it will get an already locked response from Bulwark.
5. First notify request starts processing by fetching each sessions one by one.
6. SM service sends a request to PRE for policy evaluation. PRE, in turn replies with the Policy Decision.
7. SM policy association is saved in DB.
8. On successful save, a notify response is sent to SMF and the lock is released.
9. This process gets repeated for n sessions of first Notify request.
10. Then the second notify request will retry to acquire the lock. On lock acquisition, the same process is followed for second request as well.

Call Flow for SM Update Request

Figure 4-156 Concurrency enabled for SM Update for a single session

In this case, only concurrency is enabled for SM update and pending transaction is disabled. SM Service acquires a single key lock using subscriber ID of the request.

1. SM Service receives an SM Update request from SMF.
2. SM Service sends a lock request to Bulwark Service based on Subscriber ID.
3. SM Service acquires a lock from Bulwark Service.
4. SM Service fetches the session details from the database and sends the update request to PDS.
5. SM service sends a request to PRE for policy evaluation. PRE, in turn replies with the Policy Decision.
6. SM policy association is saved in the database.
7. After the successful completion of the updates, SM Service sends a lock release request to Bulwark Service to release the lock.

Figure 4-157 Concurrency Enabled for SM-Update and multiple updates for the same subscriber

1. SM Service receives the first SM Update request from SMF.
2. SM Service sends a lock request to Bulwark Service based on Subscriber ID.
3. SM Service acquires a lock for first request from Bulwark Service.
4. SM Service receives second SM Update request from SMF for the same subscriber.
5. SM Service sends a lock request to Bulwark Service for the second SM Update request.
6. Bulwark Service responds to SM Service for the second request with a 423 already locked message.
7. SM Service fetches the session details from the database for the first update request and sends the update request to PDS.
8. SM service sends a request to PRE for policy evaluation. PRE, in turn replies with the Policy Decision.
9. SM policy association is saved in the database.
10. After the successful completion of the updates, SM Service sends a lock release request to Bulwark Service to release the lock for the first update request.
11. SM Service retries to acquire the lock for the second update request from Bulwark Service.
12. SM Service acquires a lock for the second update request, processes the update request.
13. After completing the updates for the second request, SM Service sends an unlock request to Bulwark Service to release the lock for the second request.

Figure 4-158 Retrial failure when there are multiple updates for same subscriber in different sessions

1. SM Service receives the first SM Update request from SMF.
2. SM Service sends a lock request to Bulwark Service based on Subscriber ID.
3. SM Service acquires a lock for first request from Bulwark Service.
4. SM Service receives second SM Update request from SMF for the same subscriber.
5. SM Service sends a lock request to Bulwark Service for the second SM Update request.
6. Bulwark Service responds to SM Service for the second request with a 423 already locked message.
7. SM Service fetches the session details from the database for the first update request and sends the update request to PDS.
8. SM service sends a request to PRE for policy evaluation. PRE, in turn replies with the Policy Decision.
9. SM policy association is saved in the database.
10. SM Service retries to acquire the lock for the second update request from Bulwark Service.
11. SM Service receives a 423 already acquired lock for the second lock request from Bulwark Service.
12. After the successful completion of the updates for the first request, SM Service sends a lock release request to Bulwark Service to release the lock for the first update request.

Figure 4-159 Pending transaction and Concurrent SM-Update for same session - Success scenario

1. PDS sends a notify request to SM service.
2. SM service fetches the corresponding sessions from database and sends a success response to PDS.
3. SM Service tries to acquire a lock from Bulwark Service using SessionID and gets the lock.
4. SM Service receives an SM Update request from SMF.
5. SM Service sends a lock request to Bulwark Service using the Session ID as well as Subscriber ID.
6. Bulwark Service responds to SM Service for the second request with a 423 already locked message.
7. After the successful completion of the first SM Update-notify request, SM Service sends an unlock request to Bulwark Service and Bulwark Service releases the lock for the first SM Update-Notify request.
8. SM Service retries to acquire the lock for the SM-Update request from SMF using the same Session ID as well as Subscriber ID.
9. SM Service acquires a lock with the retry.
10. SM Service fetches the session details from the database for the first update request and sends the update request to PDS.
11. SM service sends a request to PRE for policy evaluation. PRE, in turn replies with the Policy Decision.
12. SM policy association is saved in the database.
13. After the successful completion of the updates for the SM Update request, SM Service sends a lock release request to Bulwark Service to release the lock.

Figure 4-160 Pending transaction and Concurrent SM-Update for same session - Retry failure scenario

1. PDS sends a notify request to SM service.
2. SM service fetches the corresponding sessions from database and sends a success response to PDS.
3. SM Service tries to acquire a lock from Bulwark Service using SessionID and gets the lock.
4. SM Service receives an SM Update request from SMF.
5. SM Service sends a lock request to Bulwark Service using the Session ID as well as Subscriber ID.
6. Bulwark Service responds to SM Service for the second request with a 423 already locked message.
7. SM Service processes the SM Update-notify request.
8. SM Service retries to acquire the lock for the SM-Update request from SMF using the same Session ID as well as Subscriber ID.
9. Bulwark Service responds to SM Service for the second request with a 423 already locked message.
10. If the retry count exhausts, SM Service sends an already locked with pending transaction - failure response to SMF.
11. After the successful completion of the updates for the SM Update-Notify request, SM Service sends a lock release request to Bulwark Service to release the lock.

Figure 4-161 Concurrent SM-Update-Notify and Concurrent SM-Update - Success scenario

1. PDS sends a notify request to SM service.
2. SM service fetches the corresponding sessions from database and sends a success response to PDS.
3. SM Service tries to acquire a lock from Bulwark Service using SubscriberID and gets the lock.
4. SM Service receives an SM Update request from SMF.
5. SM Service sends a lock request to Bulwark Service for the same Subscriber ID.
6. Bulwark Service responds to SM Service for the second request with a 423 already locked message.
7. SM Service processes the SM Update-notify request.
8. After the successful completion of the updates for the SM Update-Notify request, SM Service sends a lock release request to Bulwark Service to release the lock.
9. SM Service retries to acquire the lock for the SM-Update request from SMF using the same Subscriber ID and acquires the lock.
10. SM Service fetches the session details from the database for the second update request and sends the update request to PDS.
11. SM service sends a request to PRE for policy evaluation. PRE, in turn replies with the Policy Decision.
12. SM policy association is saved in the database.
13. After the successful completion of the updates for the second request, SM Service sends a lock release request to Bulwark Service to release the lock.

Figure 4-162 Concurrent SM-Update-Notify and Concurrent SM-Update - Failure scenario

1. PDS sends a notify request to SM service.
2. SM service fetches the corresponding sessions from database and sends a success response to PDS.
3. SM Service tries to acquire a lock from Bulwark Service using SubscriberID and gets the lock.
4. SM Service receives an SM Update request from SMF.
5. SM Service sends a lock request to Bulwark Service for the same Subscriber ID.
6. Bulwark Service responds to SM Service for the second request with a 423 already locked message.
7. SM Service processes the SM Update-notify request.
8. SM Service retries to acquire the lock for the SM-Update request from SMF using the same Subscriber ID.
9. Bulwark Service responds to SM Service for the second request with a 423 already locked message.
10. After the successful completion of the updates for the SM Update-Notify request, SM Service sends a lock release request to Bulwark Service to release the lock.

Call Flow for SM Delete Request

The following diagram shows a scenario for SM delete call flow where no service responds with error:

Figure 4-163 Call Flow - Bulwark Lock Request SM Delete Procedure

Call Flow for SM Cleanup (Session Viewer Delete)

Figure 4-164 Requests for SM Clean

The cleanup can be either a local delete or a remote delete. In either case, SM Cleanup API is called to delete the resource.

Figure 4-165 Local delete

1. CM Service (Session Viewer) sends a Resource Delete Request based on policy association ID to Query Service, which in turn sends the Resource Cleanup request to SM Service.
2. If CONCURRENCY.BULWARK_ENABLED_FOR_N7_CLEANUP is enabled, SM Service sends a lock request to Bulwark Service to acquire the lock for the cleanup request.

   SM Service extracts the subscriber value using the policy association ID and uses the same as the key to gain the lock from Bulwark Service.

3. If the lock acquisition is successful:
   1. SM Service sends a delete request to PDS Resource Delete API to delete SM service's user data related to the individual SM policy association or the subscriber.
   2. After the data deletion, PDS responds to SM Service.
   3. SM service sends a delete request to Binding Service Resource Delete API to delete the binding data related to the individual SM policy association or the subscriber.
   4. After the data deletion, Binding Service responds to SM Service.
4. After receiving response from PDS and Binding Service, SM Service sends an unlock request to Bulwark Service to release the lock.
5. If SM Service receives another cleanup request at the same time, it tries to gain a lock for this second request from Bulwark Service.
6. If the lock request fails, SM Service receives a 423 already acquired response from Bulwark Service.
7. As per the configured number of retry counts, SM Service retries to gain the lock.
8. If it gains a lock, the SM Service sends a delete request to PDS and to Binding Service to delete the data.
9. If it fails to gain a lock and the number of retries reaches CONCURRENCY.LOCK_REQUEST_RETRY_COUNT_FOR_CLEANUP, Bulwark Service sends a 500 internal error to SM Service.

Figure 4-166 Remote delete

SM Service cleans up the data remotely when you check Remote checkbox in Session Viewer page on the UI and then click Delete.

1. CM Service (Session Viewer) sends a Resource Delete Request based on policy association ID and deleteScope=Remote to Query Service, which in turn sends the Resource Cleanup request to SM Service.
2. If CONCURRENCY.BULWARK_ENABLED_FOR_N7_CLEANUP is enabled, SM Service sends a lock request to Bulwark Service to acquire the lock for the cleanup request.

   SM Service extracts the subscriber value using the policy association ID and uses the same as the key to gain the lock from Bulwark Service.

3. If the lock acquisition is successful:
   1. SM Service sends a Session Delete Notification to SMF.
   2. If SM Service, receives a 404 not found response, it emulates a Session Delete Request to delete the SM Policy Association.
   3. SM Service deletes the SM Policy Association as per the PA Session Delete Procedure.
4. After the deletion is successful, SM Service sends an unlock request to Bulwark Service to release the lock.
5. If SM Service receives another cleanup request at the same time, it tries to gain a lock for this second request from Bulwark Service.
6. If the lock request fails, SM Service receives a 423 already acquired response from Bulwark Service.
7. As per the configured number of retry counts, SM Service retries to gain the lock.
8. If it gains a lock, the SM Service sends a Session Delete Notification to SMF and deletes the SM Policy Association as per the PA Session Delete Procedure.
9. If it fails to gain a lock and the number of retries reaches CONCURRENCY.LOCK_REQUEST_RETRY_COUNT_FOR_CLEANUP, Bulwark Service sends a 500 internal error to SM Service.

Managing Concurrency Handling for SM Service

Enable

You can enable the concurrency handling through Bulwark using the CNC Console or REST API for Policy.

• Enable using CNC Console: Set value for the following parameters under the Advanced Settings section on the PCF Session Management page:

  • CONCURRENCY.BULWARK_ENABLED_FOR_N7_CREATE
  • CONCURRENCY.BULWARK_ENABLED_FOR_N7_DELETE
  • CONCURRENCY.LOCK_LEASE_DURATION_FOR_UPDATE_NOTIFY
  • CONCURRENCY.LOCK_WAIT_DURATION_FOR_UPDATE_NOTIFY
  • CONCURRENCY.LOCK_REQUEST_RETRY_COUNT_FOR_UPDATE_NOTIFY
  • CONCURRENCY.BULWARK_ENABLED_FOR_N7_UPDATE_NOTIFY
  • CONCURRENCY.UPDATE_USERDATA_IN_ASSOCIATION_ON_LOCKFAILURE
  • CONCURRENCY.LOCK_LEASE_DURATION_FOR_UPDATE
  • CONCURRENCY.LOCK_WAIT_DURATION_FOR_UPDATE
  • CONCURRENCY.LOCK_REQUEST_RETRY_COUNT_FOR_UPDATE
  • CONCURRENCY.BULWARK_ENABLED_FOR_N7_UPDATE
  • CONCURRENCY.LOCK_LEASE_DURATION_FOR_CLEANUP
  • CONCURRENCY.LOCK_WAIT_DURATION_FOR_CLEANUP
  • CONCURRENCY.LOCK_REQUEST_RETRY_COUNT_FOR_CLEANUP
  • CONCURRENCY.BULWARK_ENABLED_FOR_N7_CLEANUP

  Note:

  If you do not make these parameters as configurable, the SM service uses the default values for these parameters.

  For more information about enabling the feature through CNC Console, see PCF Session Management.

• Enable using REST API: Set the Keys and Values for Advanced Settings under PCF Session Management Service. For more information about enabling the feature through REST API, see "PCF Session Management" in Oracle Communications Cloud Native Core, Converged Policy REST Specification Guide.

Configure

You can configure the concurrency handling through Bulwark functionality using the CNC Console or REST API for Policy.

• Configure using CNC Console: Perform the feature configurations under the Advanced Settings section on the PCF Session Management page. For more information about configuring audit service, see PCF Session Management.
• Configure using REST API:Set the Keys and Values for Advanced Settings under PCF Session Management Service. For more information about enabling the feature through REST API, see "PCF Session Management" in Oracle Communications Cloud Native Core, Converged Policy REST Specification Guide.

4.101.2 Support for Concurrency Handling using Bulwark Service in AM

The Bulwark Service integrates with the AM service to handle the concurrent requests for the AM Create, AM Update, AM Delete, and AM Update-Notify procedures. The AM service integration with Bulwark service handles the concurrent requests for the same subscriber in a concurrent and efficient manner.

In case of multiple create, update, or delete requests for the same subscriber, the AM service requests a lock for the SUPI or GPSI value from the Bulwark service. Once the lock is acquired, the AM create, AM Update, AM delete, or AM Update-Notify request is executed for the SUPI or GPSI value with which the lock is requested. After the successful completion of the requests, the AM service sends a request to release the lock to Bulwark.

As the notification is locked, pending transaction comes into picture.

When Bulwark-Service is Enabled, the following scenarios can occur between pending transaction and AM Update:

Table 4-118 Pending Transaction and Concurrency in AM Update

Pending Transaction	Concurrency in AM Update	Use-Case
Enabled	Disabled	Single Key - Session level lock will be acquired. Pending-transaction call flow would work.
Disabled	Enabled	Single Key - Subscriber level lock will be acquired. Update-Notify call flow with concurrency would work.
Enabled	Enabled	Multi-Key - Session Level & Subscriber Level locks will be acquired.

When Bulwark-Service is Enabled, the following scenarios can occur between pending transaction and update-notify:

Table 4-119 Pending Transaction and Concurrency in AM Update-Notify

Pending Transaction	Concurrency in Update-Notify	Use-Case
Enabled	Disabled	Single Key - Session level lock will be acquired. Pending-transaction call flow would work.
Disabled	Enabled	Single Key - Subscriber level lock will be acquired. AM-Update call flow would work.
Enabled	Enabled	Multi-Key - Session Level & Subscriber Level locks will be acquired.

When Bulwark-Service is Enabled, the following scenarios can occur between pending transaction and AM Update and AM update-notify:

Table 4-120 Pending Transaction and Concurrency in AM Update as well as AM Update-Notify

Pending Transaction	Concurrency in AM Update	Concurrency in AM Update-Notify	Use-Case
Enabled	Disabled	Disabled	Session Level Lock Acquired - during collision, lock acquisition fails at SessionID
Disabled	Enabled	Disabled	Subscriber Level lock acquired - during collision, lock acquisition fails at subscriberID
Disabled	Enabled	Enabled	Subscriber Level lock acquired - during collision, lock acquisition fails at subscriberID
Enabled	Enabled	Disabled	Session Level & Subscriber Level locks will be acquired - during collision, lock acquisition will fail at SessionID

Call Flow for handling concurrent requests for AM Service

Call flow for two AM-Create requests for same subscriber and retry success

Figure 4-167 Call flow for two AM-Create requests for same subscriber and retry success

In this case, only concurrency is enabled for AM Create. AM Service acquires a single key lock using what is configured in RESOURCEID.SUFFIXLIST as a default is SUPI.

1. AM Service receives an AM Create request from AMF.
2. AM Service sends a lock request to Bulwark Service based on the configuration of RESOURCEID.SUFFIXLIST.
3. AM Service acquires a lock from Bulwark Service.
4. AM Service fetches the session details from the database and sends the create request to PDS.
5. AM service sends a request to PRE for policy evaluation. PRE, in turn replies with the Policy Decision.
6. AM policy association is saved in the database.
7. After the successful completion of the create, AM Service sends a unlock release request to Bulwark Service to release the lock.

Two AM-Create requests for same Subscriber and retry failure (retry =1)

Figure 4-168 Two AM-Create requests for same Subscriber and retry failure (retry =1)

Concurrency is enabled for AM Create. AM Service acquires a single key lock using what is configured in RESOURCEID.SUFFIXLIST as a default is SUPI.

1. AM Service receives the first AM Create request from AMF.
2. AM Service sends a lock request to Bulwark Service based on what is configured in RESOURCEID.SUFFIXLIST.
3. AM Service acquires a lock for first request from Bulwark Service.
4. AM Service receives second AM Create request from AMF for the same subscriber.
5. AM Service sends a lock request to Bulwark Service for the second AM Create request.
6. Bulwark Service responds to AM Service for the second request with a 423 already locked message.
7. AM Service fetches the session details from the database for the first create request and sends the create request to PDS.
8. AM service sends a request to PRE for policy evaluation. PRE, in turn replies with the Policy Decision.
9. AM policy association is saved in the database.
10. After the successful completion of the request, AM Service sends a lock release request to Bulwark Service to release the lock for the first create request.
11. AM Service retries to acquire the lock for the second create request from Bulwark Service.
12. AM Service acquires a lock for the second create request, processes the create request.
13. After completing the create for the second request, AM Service sends an unlock request to Bulwark Service to release the lock for the second request.

Two AM-Delete requests for same Subscriber and retry success

Figure 4-169 Two AM-Delete requests for same Subscriber and retry success

In this case, only concurrency is enabled for AM Delete. AM Service acquires a single key lock using what is configured in RESOURCEID.SUFFIXLIST as a default is SUPI.

1. AM Service receives an AM Delete request from AMF.
2. AM Service sends a lock request to Bulwark Service based on the configuration of RESOURCEID.SUFFIXLIST.
3. AM Service acquires a lock from Bulwark Service.
4. AM Service fetches the session details from the database and sends the delete request to PDS.
5. AM service sends a request to PRE for policy evaluation. PRE, in turn replies with the Policy Decision.
6. AM policy association is deleted in the database.
7. After the successful completion of the delete, AM Service sends a unlock release request to Bulwark Service to release the lock.

Two AM-Delete requests for same Subscriber and retry failure (retry =1)

Figure 4-170 Two AM-Delete requests for same Subscriber and retry failure (retry =1)

Two AM-Update requests for same Subscriber but different Sessions and retry success

Figure 4-171 Two AM-Update requests for same Subscriber but different Sessions and retry success

In this case, only concurrency is enabled for AM Update. AM Service acquires a single key lock using what is configured in RESOURCEID.SUFFIXLIST as a default is SUPI.

1. AM Service receives an AM Update request from AMF.
2. AM Service sends a lock request to Bulwark Service based on the configuration of RESOURCEID.SUFFIXLIST.
3. AM Service acquires a lock from Bulwark Service.
4. AM Service fetches the session details from the database and sends the update request to PDS.
5. AM service sends a request to PRE for policy evaluation. PRE, in turn replies with the Policy Decision.
6. AM policy association is update in the database.
7. After the successful completion of the update, AM Service sends a unlock release request to Bulwark Service to release the lock.

Two AM-Update requests for same Subscriber but different Sessions and retry failure (retry =1)

Figure 4-172 Two AM-Update requests for same Subscriber but different Sessions and retry failure (retry =1)

Concurrency is enabled for AM Update. AM Service acquires a single key lock using what is configured in RESOURCEID.SUFFIXLIST as a default is SUPI.

1. AM Service receives the first AM Update request from AMF.
2. AM Service sends a lock request to Bulwark Service based on what is configured in RESOURCEID.SUFFIXLIST.
3. AM Service acquires a lock for first request from Bulwark Service.
4. AM Service receives second AM Update request from AMF for the same subscriber.
5. AM Service sends a lock request to Bulwark Service for the second AM Update request.
6. Bulwark Service responds to AM Service for the second request with a 423 already locked message.
7. AM Service fetches the session details from the database for the first update request and sends the update request to PDS.
8. AM service sends a request to PRE for policy evaluation. PRE, in turn replies with the Policy Decision.
9. AM policy association is saved in the database.
10. After the successful completion of the request, AM Service sends a lock release request to Bulwark Service to release the lock for the first update request.
11. AM Service retries to acquire the lock for the second update request from Bulwark Service.
12. AM Service acquires a lock for the second update request, processes the update request.
13. After completing the update for the second request, AM Service sends an unlock request to Bulwark Service to release the lock for the second request.

Two AM-Notify requests for same Subscriber each having 1 Session

Figure 4-173 Two AM-Notify requests for same Subscriber each having 1 Session

1. Notify request will be received at AM service from PDS.
2. AM service will fetch the Sessions related to the subscriber ID
3. AM will send request to Bulwark for lock acquisition. For lock acquisition, We will get Lock on subscriber ID & Session ID iteratively for N number of sessions.
4. Once the lock is acquired, AM service will again send a request to fetch sessions, in case it got updated.
5. Once we have the lock & updated sessions, AM service will re-auth all the sessions sequentially.
6. Then AMPolicyAssociation will be saved in DB.
7. If the DB update is success, AM service will ask for Releasing lock of Bulwark Service.
8. After lock is released successfully, the update-notify request will be success.

Two AM-Notify request for same Subscriber each having n Sessions

Figure 4-174 Two AM-Notify request for same Subscriber each having n Sessions

Concurrency is enabled for AM Notify. AM Service acquires a single key lock using what is configured in RESOURCEID.SUFFIXLIST as a default is SUPI.

1. PDS sends a notify request to AM service.
2. AM service fetches the corresponding sessions from database and sends a success response to PDS.
3. A notify request tries to acquire the lock from bulwark service and gets the lock.
4. The notify request starts processing by fetching each sessions one by one.
5. AM service sends a request to PRE for policy evaluation. PRE, in turn replies with the Policy Decision.
6. AM policy association is saved in DB.
7. On successful save, a notify response is sent to AMF and the lock is released.
8. This process gets repeated for n sessions of the Notify request.

Managing Concurrency Handling for AM Service

Enable

You can enable the concurrency handling through Bulwark using the CNC Console or REST API for Policy.

• Enable using CNC Console: Set value for the following parameters under the Advanced Settings section on the PCF Access and Mobility page:

  • CONCURRENCY.BULWARK_SERVICE_ENABLED
  • CONCURRENCY.N15.CREATE.ENABLED
  • CONCURRENCY.N15.CREATE.LOCK_LEASE_DURATION
  • CONCURRENCY.N15.CREATE.LOCK_WAIT_DURATION
  • CONCURRENCY.N15.CREATE.LOCK_REQUEST_RETRY_COUNT
  • CONCURRENCY.N15.CREATE.LOCK_REQUEST_RETRY_BACKOFF
  • CONCURRENCY.N15.TERMINATE.ENABLED
  • CONCURRENCY.N15.TERMINATE.LOCK_LEASE_DURATION
  • CONCURRENCY.N15.TERMINATE.LOCK_REQUEST_RETRY_BACKOFF
  • CONCURRENCY.N15.TERMINATE.LOCK_REQUEST_RETRY_COUNT
  • CONCURRENCY.N15.TERMINATE.LOCK_WAIT_DURATION
  • CONCURRENCY.N15.UPDATE.ENABLED
  • CONCURRENCY.N15.UPDATE.LOCK_LEASE_DURATION
  • CONCURRENCY.N15.UPDATE.LOCK_REQUEST_RETRY_BACKOFF
  • CONCURRENCY.N15.UPDATE.LOCK_REQUEST_RETRY_COUNT
  • CONCURRENCY.N15.UPDATE.LOCK_WAIT_DURATION
  • CONCURRENCY.N15.UPDATE_NOTIFY.ENABLED
  • CONCURRENCY.N15.UPDATE_NOTIFY.LOCK_LEASE_DURATION
  • CONCURRENCY.N15.UPDATE_NOTIFY.LOCK_REQUEST_RETRY_BACKOFF
  • CONCURRENCY.N15.UPDATE_NOTIFY.LOCK_REQUEST_RETRY_COUNT
  • CONCURRENCY.N15.UPDATE_NOTIFY.LOCK_WAIT_DURATION
  • RESOURCEID.SUFFIXLIST

  Note:

  If you do not make these parameters as configurable, the AM service uses the default values for these parameters.

  For more information about enabling the feature through CNC Console, see PCF Access and Mobility .

• Enable using REST API: Set the Keys and Values for Advanced Settings under PCF Session Management Service. For more information about enabling the feature through REST API, see "Access and Mobility Service" in Oracle Communications Cloud Native Core, Converged Policy REST Specification Guide.

Configure

You can configure the concurrency handling through Bulwark functionality using the CNC Console or REST API for Policy.

• Configure using CNC Console: Perform the feature configurations under the Advanced Settings section on the PCF Access and Mobility page. For more information about configuring audit service, see PCF Access and Mobility.
• Configure using REST API:Set the Keys and Values for Advanced Settings under PCF Session Management Service. For more information about enabling the feature through REST API, see "Access and Mobility Service" in Oracle Communications Cloud Native Core, Converged Policy REST Specification Guide.

4.101.3 Support for Concurrency Handling using Bulwark Service in UE

The Bulwark Service integrates with the UE service to handle the concurrent requests for the UE Create, UE Update, UE Delete, and UE Update-Notify procedures. The UE service integration with Bulwark service handles the concurrent requests for the same subscriber in a concurrent and efficient manner.

In case of multiple create, update, or delete requests for the same subscriber, the UE service requests a lock for the SUPI or GPSI value from the Bulwark service. Once the lock is acquired, the UE create, UE Update, UE delete, or UE Update-Notify request is executed for the SUPI or GPSI value with which the lock is requested. After the successful completion of the requests, the UE service sends a request to release the lock to Bulwark.

As the notification is locked, pending transaction comes into picture.

When Bulwark-Service is Enabled, the following scenarios can occur between pending transaction and UE Update:

Table 4-121 Pending Transaction and Concurrency in UE Update

Pending Transaction	Concurrency in UE Update	Use-Case
Enabled	Disabled	Single Key - Session level lock will be acquired. Pending-transaction call flow would work.
Disabled	Enabled	Single Key - Subscriber level lock will be acquired. Update-Notify call flow with concurrency would work.
Enabled	Enabled	Multi-Key - Session Level & Subscriber Level locks will be acquired.

When Bulwark-Service is Enabled, the following scenarios can occur between pending transaction and update-notify:

Table 4-122 Pending Transaction and Concurrency in UE Update-Notify

Pending Transaction	Concurrency in Update-Notify	Use-Case
Enabled	Disabled	Single Key - Session level lock will be acquired. Pending-transaction call flow would work.
Disabled	Enabled	Single Key - Subscriber level lock will be acquired. UE-Update call flow would work.
Enabled	Enabled	Multi-Key - Session Level & Subscriber Level locks will be acquired.

When Bulwark-Service is Enabled, the following scenarios can occur between pending transaction and UE Update and UE update-notify:

Table 4-123 Pending Transaction and Concurrency in UE Update as well as UE Update-Notify

Pending Transaction	Concurrency in UE Update	Concurrency in UE Update-Notify	Use-Case
Enabled	Disabled	Disabled	Session Level Lock Acquired - during collision, lock acquisition fails at SessionID
Disabled	Enabled	Disabled	Subscriber Level lock acquired - during collision, lock acquisition fails at subscriberID
Disabled	Enabled	Enabled	Subscriber Level lock acquired - during collision, lock acquisition fails at subscriberID
Enabled	Enabled	Disabled	Session Level & Subscriber Level locks will be acquired - during collision, lock acquisition will fail at SessionID

Call Flow for handling concurrent requests for UE Service

Two UE-Create requests for same Subscriber and retry success.

Figure 4-175 Two UE-Create requests for same Subscriber and retry success.

In this case, only concurrency is enabled for UE Create. UE Service acquires a single key lock using what is configured in RESOURCEID.SUFFIXLIST as a default is SUPI.

1. UE Service receives an UE Create request from AMF.
2. UE Service sends a lock request to Bulwark Service based on the configuration of RESOURCEID.SUFFIXLIST.
3. UE Service acquires a lock from Bulwark Service.
4. UE Service fetches the session details from the database and sends the create request to PDS.
5. UE service sends a request to PRE for policy evaluation. PRE, in turn replies with the Policy Decision.
6. UE policy association is saved in the database.
7. After the successful completion of the create, UE Service sends a unlock release request to Bulwark Service to release the lock.

Two UE-Create requests for same Subscriber and retry failure (retry =1)

Figure 4-176 Two UE-Create requests for same Subscriber and retry failure (retry =1)

Concurrency is enabled for UE Create. UE Service acquires a single key lock using what is configured in RESOURCEID.SUFFIXLIST as a default is SUPI.

1. UE Service receives the first UE Create request from AMF.
2. UE Service sends a lock request to Bulwark Service based on what is configured in RESOURCEID.SUFFIXLIST.
3. UE Service acquires a lock for first request from Bulwark Service.
4. UE Service receives second UE Create request from AMF for the same subscriber.
5. UE Service sends a lock request to Bulwark Service for the second UE Create request.
6. Bulwark Service responds to UE Service for the second request with a 423 already locked message.
7. UE Service fetches the session details from the database for the first create request and sends the create request to PDS.
8. UE service sends a request to PRE for policy evaluation. PRE, in turn replies with the Policy Decision.
9. UE policy association is saved in the database.
10. After the successful completion of the request, UE Service sends a lock release request to Bulwark Service to release the lock for the first create request.
11. UE Service retries to acquire the lock for the second create request from Bulwark Service.
12. UE Service acquires a lock for the second create request, processes the create request.
13. After completing the create for the second request, UE Service sends an unlock request to Bulwark Service to release the lock for the second request.

Two UE-Delete requests for same Subscriber and retry success.

Figure 4-177 Two UE-Delete requests for same Subscriber and retry success.

In this case, only concurrency is enabled for UE Delete. UE Service acquires a single key lock using what is configured in RESOURCEID.SUFFIXLIST as a default is SUPI.

1. UE Service receives an UE Delete request from AMF.
2. UE Service sends a lock request to Bulwark Service based on the configuration of RESOURCEID.SUFFIXLIST.
3. UE Service acquires a lock from Bulwark Service.
4. UE Service fetches the session details from the database and sends the delete request to PDS.
5. UE service sends a request to PRE for policy evaluation. PRE, in turn replies with the Policy Decision.
6. UE policy association is deleted in the database.
7. After the successful completion of the delete, UE Service sends a unlock release request to Bulwark Service to release the lock.

Two UE-Delete requests for same Subscriber and retry failure (retry =1)

Figure 4-178 Two UE-Delete requests for same Subscriber and retry failure (retry =1)

Concurrency is enabled for UE Delete. UE Service acquires a single key lock using what is configured in RESOURCEID.SUFFIXLIST as a default is SUPI.

1. UE Service receives the first UE Delete request from AMF.
2. UE Service sends a lock request to Bulwark Service based on what is configured in RESOURCEID.SUFFIXLIST.
3. UE Service acquires a lock for first request from Bulwark Service.
4. UE Service receives second UE Delete request from AMF for the same subscriber.
5. UE Service sends a lock request to Bulwark Service for the second UE Delete request.
6. Bulwark Service responds to UE Service for the second request with a 423 already locked message.
7. UE Service fetches the session details from the database for the first delete request and sends the delete request to PDS.
8. UE service sends a request to PRE for policy evaluation. PRE, in turn replies with the Policy Decision.
9. UE policy association is saved in the database.
10. After the successful completion of the request, UE Service sends a lock release request to Bulwark Service to release the lock for the first delete request.
11. UE Service retries to acquire the lock for the second delete request from Bulwark Service.
12. UE Service acquires a lock for the second delete request, processes the delete request.
13. After completing the delete for the second request, UE Service sends an unlock request to Bulwark Service to release the lock for the second request.

Two UE-Update requests for same Subscriber but different Sessions and retry success.

Figure 4-179 Two UE-Update requests for same Subscriber but different Sessions and retry success.

In this case, only concurrency is enabled for UE Update. UE Service acquires a single key lock using what is configured in RESOURCEID.SUFFIXLIST as a default is SUPI.

1. UE Service receives an UE Update request from AMF.
2. UE Service sends a lock request to Bulwark Service based on the configuration of RESOURCEID.SUFFIXLIST.
3. UE Service acquires a lock from Bulwark Service.
4. UE Service fetches the session details from the database and sends the update request to PDS.
5. UE service sends a request to PRE for policy evaluation. PRE, in turn replies with the Policy Decision.
6. UE policy association is update in the database.
7. After the successful completion of the update, AM Service sends a unlock release request to Bulwark Service to release the lock.

Two UE-Update requests for same Subscriber but different Sessions and retry failure (retry =1)

Figure 4-180 Two UE-Update requests for same Subscriber but different Sessions and retry failure (retry =1)

Concurrency is enabled for UE Update. UE Service acquires a single key lock using what is configured in RESOURCEID.SUFFIXLIST as a default is SUPI.

1. UE Service receives the first UE Update request from AMF.
2. UE Service sends a lock request to Bulwark Service based on what is configured in RESOURCEID.SUFFIXLIST.
3. UE Service acquires a lock for first request from Bulwark Service.
4. UE Service receives second UE Update request from AMF for the same subscriber.
5. UE Service sends a lock request to Bulwark Service for the second UE Update request.
6. Bulwark Service responds to UE Service for the second request with a 423 already locked message.
7. UE Service fetches the session details from the database for the first update request and sends the update request to PDS.
8. UE service sends a request to PRE for policy evaluation. PRE, in turn replies with the Policy Decision.
9. UE policy association is saved in the database.
10. After the successful completion of the request, UE Service sends a lock release request to Bulwark Service to release the lock for the first update request.
11. UE Service retries to acquire the lock for the second update request from Bulwark Service.
12. UE Service acquires a lock for the second update request, processes the update request.
13. After completing the update for the second request, UE Service sends an unlock request to Bulwark Service to release the lock for the second request.

Two UENotify requests for same Subscriber each having 1 session

Figure 4-181 Two UENotify requests for same Subscriber each having 1 session

1. Notify request will be received at UE service from PDS.
2. UE service will fetch the Sessions related to the subscriber ID
3. UE will send request to Bulwark for lock acquisition. For lock acquisition, We will get Lock on subscriber ID & Session ID iteratively for N number of sessions.
4. Once the lock is acquired, UE service will again send a request to fetch sessions, in case it got updated.
5. Once we have the lock & updated sessions, UE service will re-auth all the sessions sequentially.
6. Then PolicyAssociation will be saved in DB.
7. If the DB update is success, UE service will ask for Releasing lock of Bulwark Service.
8. After lock is released successfully, the update-notify request will be success.

Two UENotify request for same Subscriber each having n sessions

Figure 4-182 Two UENotify request for same Subscriber each having n sessions

Concurrency is enabled for UE Notify. UE Service acquires a single key lock using what is configured in RESOURCEID.SUFFIXLIST as a default is SUPI.

1. PDS sends a notify request to UE service.
2. UE service fetches the corresponding sessions from database and sends a success response to PDS.
3. A notify request tries to acquire the lock from bulwark service and gets the lock.
4. The notify request starts processing by fetching each sessions one by one.
5. UE service sends a request to PRE for policy evaluation. PRE, in turn replies with the Policy Decision.
6. UE policy association is saved in DB.
7. On successful save, a notify response is sent to AMF and the lock is released.
8. This process gets repeated for n sessions of the Notify request.

Managing Concurrency Handling for UE Service

Enable

You can enable the concurrency handling through Bulwark using the CNC Console or REST API for Policy.

• Enable using CNC Console: Set value for the following parameters under the Advanced Settings section on the PCF UE Policy Service page:

  • CONCURRENCY.BULWARK_SERVICE_ENABLED
  • CONCURRENCY.N15.CREATE.ENABLED
  • CONCURRENCY.N15.CREATE.LOCK_LEASE_DURATION
  • CONCURRENCY.N15.CREATE.LOCK_WAIT_DURATION
  • CONCURRENCY.N15.CREATE.LOCK_REQUEST_RETRY_COUNT
  • CONCURRENCY.N15.CREATE.LOCK_REQUEST_RETRY_BACKOFF
  • CONCURRENCY.N15.TERMINATE.ENABLED
  • CONCURRENCY.N15.TERMINATE.LOCK_LEASE_DURATION
  • CONCURRENCY.N15.TERMINATE.LOCK_REQUEST_RETRY_BACKOFF
  • CONCURRENCY.N15.TERMINATE.LOCK_REQUEST_RETRY_COUNT
  • CONCURRENCY.N15.TERMINATE.LOCK_WAIT_DURATION
  • CONCURRENCY.N15.UPDATE.ENABLED
  • CONCURRENCY.N15.UPDATE.LOCK_LEASE_DURATION
  • CONCURRENCY.N15.UPDATE.LOCK_REQUEST_RETRY_BACKOFF
  • CONCURRENCY.N15.UPDATE.LOCK_REQUEST_RETRY_COUNT
  • CONCURRENCY.N15.UPDATE.LOCK_WAIT_DURATION
  • CONCURRENCY.N15.UPDATE_NOTIFY.ENABLED
  • CONCURRENCY.N15.UPDATE_NOTIFY.LOCK_LEASE_DURATION
  • CONCURRENCY.N15.UPDATE_NOTIFY.LOCK_REQUEST_RETRY_BACKOFF
  • CONCURRENCY.N15.UPDATE_NOTIFY.LOCK_REQUEST_RETRY_COUNT
  • CONCURRENCY.N15.UPDATE_NOTIFY.LOCK_WAIT_DURATION
  • RESOURCEID.SUFFIXLIST

  Note:

  If you do not make these parameters as configurable, the UE service uses the default values for these parameters.

  For more information about enabling the feature through CNC Console, see PCF UE Policy Service .

• Enable using REST API: Set the Keys and Values for Advanced Settings under PCF Session Management Service. For more information about enabling the feature through REST API, see "UE Policy" in Oracle Communications Cloud Native Core, Converged Policy REST Specification Guide.

Configure

You can configure the concurrency handling through Bulwark functionality using the CNC Console or REST API for Policy.

• Configure using CNC Console: Perform the feature configurations under the Advanced Settings section on the PCF UE Policy Service page. For more information about configuring audit service, see PCF UE Policy Service.
• Configure using REST API:Set the Keys and Values for Advanced Settings under PCF Session Management Service. For more information about enabling the feature through REST API, see "UE Policy" in Oracle Communications Cloud Native Core, Converged Policy REST Specification Guide.

4.101.4 Support for Concurrency Handling using Bulwark Service in PCRF

PCRF-core supports the Bulwark service to handle the concurrent messages on Gx interface. PCRF-core interacts with Bulwark service using of lock/unlock message exchanges acquiring and releasing the User-IDs based lock upon receiving CCR-I/U-T messages.

The PCRF-core sends the following parameters to request a lock:

• Key: The key is the identifier value with which the lock is identified. You can select either SUPI or GPSI value to be the key parameter for which the lock acquisition request must be made. By default, SUPI values are used for lock requests.
• Lease Duration: This value defines the duration for which lock is kept once the acquisition is successful. After this duration, the lock will be released automatically.
• Lock Wait Timeout: This defines the duration by which the Policy services wait for the response to get a lock. The same duration is used by Bulwark to poll for the lock in case the lock is not available. The Lock Wait timeout is also considered as the polling interval which sends the request towards Bulwark service periodically to acquire the lock for another create or delete request.
• Retry Count: This defines the count of retry attempts that are made by the Policy services if a lock request fails. In case all the retry attempts fail, the create or delete request is rejected. By default, 3 retry attempts are enabled.

Call Flow- CCR-I, CCR-U and CCR-T messages Integration with Bulwark Service

Figure 4-183 CCR-I, CCR-U and CCR-T messages Integration with Bulwark Service

Call Flow- PDS notification (RAR) Integration with Bulwark Service

Figure 4-184 Call Flow- PDS notification (RAR) Integration with Bulwark Service

Managing Concurrency Handling for PDS Service

Enable

You can enable the concurrency handling for PCRF-Core using the CNC Console or REST API for Policy.

• Enable using CNC Console: Set the keys and values of the following keys under the Advanced Settings section on the PCRF Core Settings page:

  Table 4-124 General

  Key	Value
  CONCURRENCY.ENABLED	true/false

  Table 4-125 List of Keys for Gx CCR-I

  Key	Default Value
  CONCURRENCY.GX.CREATE.LOCK_REQUEST_RETRY_COUNT	2
  CONCURRENCY.GX.CREATE.LOCK_REQUEST_RETRY_BACKOFF	1000
  CONCURRENCY.GX.CREATE.LOCK_LEASE_DURATION	2000
  CONCURRENCY.GX.CREATE.LOCK_WAIT_DURATION	3000
  CONCURRENCY.GX.CREATE.ENABLED	True
  CONCURRENCY.GX.CREATE.ALLOW_ON_SERVICE_FAILURE	True

  Table 4-126 List of Keys for Gx CCR-U

  Key	Default Value
  CONCURRENCY.GX.MODIFY.LOCK_REQUEST_RETRY_COUNT	2
  CONCURRENCY.GX.MODIFY.LOCK_REQUEST_RETRY_BACKOFF	1000
  CONCURRENCY.GX.MODIFY.LOCK_LEASE_DURATION	2000
  CONCURRENCY.GX.MODIFY.LOCK_WAIT_DURATION	3000
  CONCURRENCY.GX.MODIFY.ENABLED	True
  CONCURRENCY.GX.MODIFY.ALLOW_ON_SERVICE_FAILURE	True

  Table 4-127 List of Keys for Gx CCR-T

  Key	Default Value
  CONCURRENCY.GX.DELETE.LOCK_REQUEST_RETRY_COUNT	2
  CONCURRENCY.GX.DELETE.LOCK_REQUEST_RETRY_BACKOFF	1000
  CONCURRENCY.GX.DELETE.LOCK_LEASE_DURATION	2000
  CONCURRENCY.GX.DELETE.LOCK_WAIT_DURATION	3000
  CONCURRENCY.GX.DELETE.ENABLED	True
  CONCURRENCY.GX.DELETE.ALLOW_ON_SERVICE_FAILURE	True

  Table 4-128 List of Keys for Gx RAR

  Key	Defualt Value
  CONCURRENCY.GX.REAUTH.LOCK_REQUEST_RETRY_COUNT	2
  CONCURRENCY.GX.REAUTH.LOCK_REQUEST_RETRY_BACKOFF	1000
  CONCURRENCY.GX.REAUTH.LOCK_LEASE_DURATION	2000
  CONCURRENCY.GX.REAUTH.LOCK_WAIT_DURATION	3000
  CONCURRENCY.GX.REAUTH.ENABLED	True
  CONCURRENCY.GX.REAUTH.ALLOW_ON_SERVICE_FAILURE	True

  Table 4-129 List of Keys for SD Create

  Key	Default Value
  CONCURRENCY.SD.CREATE.LOCK_REQUEST_RETRY_COUNT	2
  CONCURRENCY.SD.CREATE.LOCK_REQUEST_RETRY_BACKOFF	1000
  CONCURRENCY.SD.CREATE.LOCK_LEASE_DURATION	2000
  CONCURRENCY.SD.CREATE.LOCK_WAIT_DURATION	3000
  CONCURRENCY.SD.CREATE.ENABLED	True
  CONCURRENCY.SD.CREATE.ALLOW_ON_SERVICE_FAILURE	True

  Table 4-130 List of Keys for Rx AAR-I

  Key	Default Value
  CONCURRENCY.RX.CREATE.LOCK_REQUEST_RETRY_COUNT	2
  CONCURRENCY.RX.CREATE.LOCK_REQUEST_RETRY_BACKOFF	1000
  CONCURRENCY.RX.CREATE.LOCK_LEASE_DURATION	2000
  CONCURRENCY.RX.CREATE.LOCK_WAIT_DURATION	3000
  CONCURRENCY.RX.CREATE.ENABLED	true
  CONCURRENCY.RX.CREATE.ALLOW_ON_SERVICE_FAILURE	true

  Table 4-131 List of Keys for Rx AAR-U

  Key	Default Value
  CONCURRENCY.RX.MODIFY.LOCK_REQUEST_RETRY_COUNT	2
  CONCURRENCY.RX.MODIFY.LOCK_REQUEST_RETRY_BACKOFF	1000
  CONCURRENCY.RX.MODIFY.LOCK_LEASE_DURATION	2000
  CONCURRENCY.RX.MODIFY.LOCK_WAIT_DURATION	3000
  CONCURRENCY.RX.MODIFY.ENABLED	true
  CONCURRENCY.RX.MODIFY.ALLOW_ON_SERVICE_FAILURE	true

  Table 4-132 List of Keys for Rx STR

  Key	Default Value
  CONCURRENCY.RX.DELETE.LOCK_REQUEST_RETRY_COUNT	2
  CONCURRENCY.RX.DELETE.LOCK_REQUEST_RETRY_BACKOFF	1000
  CONCURRENCY.RX.DELETE.LOCK_LEASE_DURATION	2000
  CONCURRENCY.RX.DELETE.LOCK_WAIT_DURATION	3000
  CONCURRENCY.RX.DELETE.ENABLED	true
  CONCURRENCY.RX.DELETE.ALLOW_ON_SERVICE_FAILURE	true

  Table 4-133 List of Keys for Additional Properties

  Key	Default Value
  bulwark.service.enabled	true
  bulwark.service.http2.enabled	true
  bulwark.service.url	http://10.75.241.7:30900/v1/locks
  bulwark.service.connector.timeout	3000

  For more information about enabling the feature through CNC Console, see Settings.

• Enable using REST API: Set the Keys and Values for Advanced Settings under PCRF Core Settings. For more information about enabling the feature through REST API, see "Core Services" section in Oracle Communications Cloud Native Core, Converged Policy REST Specification Guide.

Configure

You can configure the concurrency handling for PDS Service using the CNC Console or REST API for Policy.

• Configure using CNC Console: Perform the feature configurations under the Advanced Settings section on the PCRF Core Settings page. For more information about the configuration, see Settings.
• Configure using REST API: Set the Keys and Values for Advanced Settings under PCRF Core Settings. For more information about enabling the feature through REST API, see "Core Services" section in Oracle Communications Cloud Native Core, Converged Policy REST Specification Guide.

Observe

PCRF-Core provides the following metrics specific to concurrency handling in PCRF:

• occnp_http_bulwark_lock_request_total
• occnp_http_bulwark_lock_response_total
• occnp_http_bulwark_unlock_request_total
• occnp_http_bulwark_unlock_response_total

For more details on metrics, see PCRF Core Metrics.

4.101.5 Support for Concurrency Handling using Bulwark Service in PDS

When PDS receives concurrent notification requests for a subscriber (same SUPI or GPSI) of the same data source, processing multiple notification requests at the same time can result in inaccurate data.

To avoid this issue, PDS is integrated with Bulwark Service. Bulwark Service provides lock and unlock mechanism over a SUPI or GPSI key and allows processing of only one notification at a time.

When PDS service receives multiple notifications from UDR, CHF or OCS, PDS requests for a lock to Bulwark service by calling the lock API service. Bulwark service approves lock for one request at a time. The other services retry to get the lock..

Once the lock is acquired, PDS service processes the notification for the SUPI or GPSI value with which the lock is requested. After the message is completed, PDS service sends a release lock request to Bulwark to release the lock.

Call Flow for Handling concurrent requests for PDS service

Figure 4-185 Call Flow - Bulwark Lock Request For CHF Notification

To enable the concurrency handling for CHF notifications, set the value of CONCURRENCY.BULWARK_ENABLED_FOR_CHF_NOTIFICATION to true.

In the above example, PDS receives notification request for SUPI1 from CHF through Ingress Gateway, CHF Connector.

1. PDS queries the PDS Subscriber table to fetch the SUPI or GPSI for the given sySessionID, based on CONCURRENCY.LOCK_REQUEST_KEY_TYPE_FOR_CHF_NOTIFICATION configuration in PDS Advanced Settings page.
2. PDS sends a lock request to Bulwark Service to acquire a lock for notification request over SUPI1.
3. Bulwark Service polls for the lock.
4. If the lock acquisition is successful:
   1. Bulwark Service generates a UniqueID for the lock and updates the same in the global coherence cache.
   2. Bulwark Service responds to PDS with 200 ok message.
   3. After PDS completes processing the notification request, it sends an Unlock request to Bulwark Service with the UniqueID in request parameters.
   4. Bulwark Service removes the UniqueID from the global coherence cache and responds to PDS with a 204 no content message.
   5. PDS forwards the notification request to core services and receives a response.
   6. If the lease duration expires before the processing of the notification request is complete, Bulwark Services releases the lock.
5. If the lock acquisition fails, PDS receives an error from Bulwark Service. If the same error code is configured in BULWARK_ERROR_CODES in PDS, PDS rejects the notification and responds with a 500 message to CHF connector. If the error code is not configured in BULWARK_ERROR_CODES, PDS continues to process the notification without the lock.

Figure 4-186 Call Flow - Bulwark Lock Request For UDR Notification

To enable the concurrency handling for UDR notifications, set the value of CONCURRENCY.BULWARK_ENABLED_FOR_UDR_NOTIFICATION to true.

In the above example, PDS receives notification request for SUPI1 from UDR through Ingress Gateway, UDR Connector.

1. PDS queries the PDS Subscriber table to fetch the SUPI or GPSI for the given sySessionID, based on CONCURRENCY.LOCK_REQUEST_KEY_TYPE_FOR_UDR_NOTIFICATION configuration in PDS Advanced Settings page.
2. PDS sends a lock request to Bulwark Service to acquire a lock for notification request over SUPI1.
3. Bulwark Service polls for the lock.
4. If the lock acquisition is successful:
   1. Bulwark Service generates a UniqueID for the lock and updates the same in the global coherence cache.
   2. Bulwark Service responds to PDS with 200 ok message.
   3. After PDS completes processing the notification request, it sends an Unlock request to Bulwark Service with the UniqueID in request parameters.
   4. Bulwark Service removes the UniqueID from the global coherence cache and responds to PDS with a 204 no content message.
   5. PDS forwards the notification request to core services and receives a response.
   6. If the lease duration expires before the processing of the notification request is complete, Bulwark Services releases the lock.
5. If the lock acquisition fails, PDS receives an error from Bulwark Service. If the same error code is configured in BULWARK_ERROR_CODES in PDS, PDS rejects the notification and responds with a 500 message to UDR connector. If the error code is not configured in BULWARK_ERROR_CODES, PDS continues to process the notification without the lock.

Figure 4-187 Call Flow - Bulwark Lock Request For OCS Notification

To enable the concurrency handling for OCS notifications, set the value of CONCURRENCY.BULWARK_ENABLED_FOR_OCS_NOTIFICATION to true.

In the above example, PDS receives notification request for Sy Session from OCS through Ingress Gateway, Diameter Connector.

1. PDS queries the PDS Subscriber table to fetch the SUPI or GPSI for the given sySessionID, based on CONCURRENCY.LOCK_REQUEST_KEY_TYPE_FOR_OCS_NOTIFICATION configuration in PDS Advanced Settings page. .
2. PDS sends a lock request to Bulwark Service to acquire a lock for notification request over SUPI1.
3. Bulwark Service polls for the lock.
4. If the lock acquisition is successful:
   1. Bulwark Service generates a UniqueID for the lock and updates the same in the global coherence cache.
   2. Bulwark Service responds to PDS with 200 ok message.
   3. After PDS completes processing the notification request, it sends an Unlock request to Bulwark Service with the UniqueID in request parameters.
   4. Bulwark Service removes the UniqueID from the global coherence cache and responds to PDS with a 204 no content message.
   5. PDS forwards the notification request to core service and receives a response.
   6. If the lease duration expires before the processing of the notification request is complete, Bulwark Services releases the lock.
5. If the lock acquisition fails, PDS receives an error from Bulwark Service. If the same error code is configured in BULWARK_ERROR_CODES in PDS, PDS rejects the notification and responds with a 500 message to OCS. If the error code is not configured in BULWARK_ERROR_CODES, PDS continues to process the notification without the lock.

Managing Concurrency Handling for PDS Service

Enable

You can enable the concurrency handling for PDS Service using the CNC Console or REST API for Policy.

• Enable using CNC Console: Set value of the following keys to true under the Advanced Settings section on the PDS Settings page:

  • CONCURRENCY.BULWARK_ENABLED_FOR_CHF_NOTIFICATION
  • CONCURRENCY.BULWARK_ENABLED_FOR_OCS_NOTIFICATION
  • CONCURRENCY.BULWARK_ENABLED_FOR_UDR_NOTIFICATION

  Configuration of CONCURRENCY.BULWARK_ENABLED_FOR_CHF_NOTIFICATION, CONCURRENCY.BULWARK_ENABLED_FOR_OCS_NOTIFICATION and CONCURRENCY.BULWARK_ENABLED_FOR_UDR_NOTIFICATION are considered only if CONCURRENCY.BULWARK_ENABLED is set to true.

  CONCURRENCY.BULWARK_ENABLED is configured at the time of deployment.

  For more information about enabling the feature through CNC Console, see PDS Settings.

• Enable using REST API: Set the Keys and Values for Advanced Settings under PDS Settings. For more information about enabling the feature through REST API, see "PDS Settings" in Oracle Communications Cloud Native Core, Converged Policy REST Specification Guide.

Configure

You can configure the concurrency handling for PDS Service using the CNC Console or REST API for Policy.

• Configure using CNC Console: Perform the feature configurations under the Advanced Settings section on the PDS Settings page. For more information about configuring audit service, see PDS Settings.
• Configure using REST API: Set the Keys and Values for Advanced Settings under PDS Settings. For more information about enabling the feature through REST API, see "PDS Settings" in Oracle Communications Cloud Native Core, Converged Policy REST Specification Guide.

Observe

Policy provides the following metrics specific to concurrency handling for PDS call flows:

• server_request_total
• server_response_total

For more details on metrics, see Policy DS Metrics.

4.102 Support for Sd Interface in PCRF

Policy supports the Sd interface that enables it to communicate with the Traffic Detection Function (TDF). The Sd interface allows provisioning of the Application Detection and Control (ADC) rules from Policy for traffic detection and enforcement at the TDF through Solicited Application Reporting.

The Sd reference point exists between Policy and Charging Rules Function (PCRF) and a standalone TDF. Policy performs the following functionality for traffic detection through Sd interface:

• Establishment of session with TDF over Sd interface
• Termination of an existing TDF session
• Provisioning of ADC rules or decisions from for the purpose of traffic detection and enforcement at the TDF
• Reporting of the start and stop of detected applications and transfer of service data flow descriptions for detected applications, if available, from the TDF

The feature is supported for the Policy, PCRF, and the Converged Policy mode. It also supports the georedundant deployments of Policy.

The following diagram describes the session establishment between Policy and TDF:

Figure 4-188 TDF Session Establishment over Sd Interface

1. Policy acts as a diameter server for CER/CEA connection exchange. It accepts the diameter CER from TDF clients.

   Note:

   Policy supports the diameter CER only from the configured TDF clients.

   This establishes an Sd session as a result of IP-CAN (Gx) session establishment based on Policy action.

2. Policy sends a TDF-Session-Request (TSR) to the identified TDF in order to establish the session and provide the application detection information in the ADC rules. For more information, see 3GPP Technical specification, Release 16.4, Policy and Charging Control (PCC).

Call Flow

Call Flow for TDF Session

The following diagram shows a call flow between Policy and TDF through the asynchronous mode of communication between Gx and Sd interface:

Figure 4-189 Call Flow for TDF Session

Note:

Policy supports one Sd session per IPCAN Gx session to a RD. In case of multiple IPCAN, the new Sd Session is established to the same TDF for which the IPCAN session already exists. Multiple Sd sessions for the same Gx IPCAN session are not supported.

Managing Traffic Handling using Sd Interface

Enable

To enable the traffic handling through Sd interface functionality, Policy communicates with the OCS service. Therefore, it is required to enable the OCS Spending limit feature in PCRF-Core settings. You can enable OCS Spending limit using the CNC Console or REST API for Policy.

• Enable using CNC Console: Enable the OCS Spending limit functionality using the OCS Spending Limit Attributes on the Settings page for the PCRF Core service configurations. For more information about enabling the feature through CNC Console, see PCRF Core Service Configurations.

• Enable using REST API: Set values for the ocsSpendingLimit.enable parameter in the Core Service configuration API. For more information about enabling the feature through REST API, see "Core Service" in Oracle Communications Cloud Native Core, Converged Policy REST Specification Guide.

Configure

You can configure the traffic handling through Sd interface functionality using the CNC Console or REST API for Policy.

• Configure using CNC Console: Perform the following feature configurations using the CNC Console:

  • Set value for the TDF FQDN in the Diameter Identity parameter under the PGW section on the Network Element page. For more information about enabling the feature through CNC Console, see PGW.

  • Set the TDF service connection using the Identity parameter on the Peer Nodes page. For more information about enabling the feature through CNC Console, see Peer Nodes.

  • Set the TDF service connection using the type parameter on the Peer Node Sets page. For more information about enabling the feature through CNC Console, see Peer Node Sets.

• Configure using REST API: Policy provides the following REST API for traffic handling through Sd interface configuration:

  • Set values for the neDiameterId parameter in the Network for PGW configuration API. For more information about configuring the parameter through REST API, see "Network for PGW" in Oracle Communications Cloud Native Core, Converged Policy REST Specification Guide.

  • Set values for the identity parameter in the Peer Nodes configuration API. For more information about configuring the parameter through REST API, see "Peer Nodes" in Oracle Communications Cloud Native Core, Converged Policy REST Specification Guide.

  • Set values for the type parameter in the Peer Node Sets configuration API. For more information about configuring the parameter through REST API, see "Peer Node Sets" in Oracle Communications Cloud Native Core, Converged Policy REST Specification Guide.

After the configurations, you can use the following blockly rules to establish traffic detection sessions with selected network element identity.

Policy supports the following blockly rules to create dynamic PCC Rules for the Sd interface:

• Establish traffic detection session with selected network element identity.
  The following screen capture shows a sample for the blockly:

  Figure 4-190 Traffic Detection for Peer Node

  
  

  

  
  
• Establish traffic detection session with selected Peer Node Set.
  The following screen capture shows a sample for the blockly:

  Figure 4-191 Traffic Detection for Peer Node Sets

  
• Installation: To provision an ADC rule that has not been already provisioned. This blockly is used to install specified ADC rule(s) for selected scope active between the given start time and end time.
  The following screen capture shows a sample for the blockly:

  Figure 4-192 Install with specified ADC Rules

  
  

  

  
  

  Note:

  The Sd interface allows multiple rules to be installed with one ADC Charging Rule Install rule.
• Modification: To modify an installed ADC rule
• Removal: To remove an installed ADC rule
  The following screen captures show samples for the blockly:

  • To remove all ADC Rules

    Figure 4-193 Remove all ADC Rules

    
    

    

    
    
  • To remove specified ADC Rules

    Figure 4-194 Remove specified ADC Rules

    
    

    

    
    

  For more information, see "PCRF-Core Actions" in Oracle Communications Cloud Native Core, Converged Policy Design Guide.

• Set Session Revalidation Time

  Figure 4-195 Set Session Revalidation Time

  

Observe

Policy provides metrics specific to determine the successful TSR and RAR messages sent to TDF.

Policy provides TDF_CONNECTION_DOWN alert for this feature.

4.103 Support for Retrying Binding Registration on BSF and generating Alarm to Operator

The Retry Binding Registration on BSF feature enhances the binding registration functionality between SM Service and BSF. SM Service sends the binding registration requests to BSF through the Binding service. To manage the registration failure scenarios, Policy provides the Session Retry functionality. The Policy Binding service handles the Session Retry functionality and returns any of the following responses to the SM service:

• Created without BSF Metadata: The binding creation is successful in BSF
• Failed with BSF Metadata: The binding creation on BSF failed and the BSF metadata contains the problemDetails of the failure. If the error code in the BsfMeatadata does not match with the configured error code, it sends the termination notification in case the Abort or Terminate switch is enabled in SM configurations.
• 500 Internal Server Error: An error occurred at the Binding service. It sends a termination notification if the Abort or Terminate flag is enabled in SM configurations

Starting with release 22.3.0, the Retry Binding Registration on BSF feature enhances the existing session retry mechanism by supporting multiple cycles of retry binding creation until a maximum number of attempts are reached or the response error code does not match with any of the configured error codes.

The following steps describes how PCF reattempts a binding request after receiving the failure response from BSF:

1. PCF sends a binding request to BSF and the initial request get failed.

   Note:

   When binding request to BSF fails, the binding service saves the binding context in its database and SM service is configured to reattempt after some time. During reattempt, SM service sends an update request so that a new request is sent to BSF instead of creating a new binding context.
2. PCF uses the Alternate Route Retry (ARR) functionality and sends the BSF registration requests to alternate BSFs.
3. In case all the session retry attempts configured in Policy fails, then Binding service returns to the SM service with the status code of the last binding request. The SM service evaluates if a recreate attempt must be triggered based on the following configurations:
   1. Recreate attempt feature is enabled
   2. Status code returned by Binding service matches with one of the error codes configured in the retry profile for BSF.

      Note:

      If no error codes have been configured in the retry profile for BSF, no recreate attempt is triggered.
   3. The maximum number of recreate attempts has not been reached. Based on the configurations, the SM service triggers the binding request after the duration configured through the BOT configuration is over.

      Note:

      The binding operation must be in asynchronous mode. For more information about configuration, see Managing Retrying Binding Registration on BSF .
4. If all the configurations are matched, then the SM service initiates a recreate attempt.
5. In case of the failure of the recreate attempt, the SM service reattempts the requests for the number of times configured in the Maximum Number of Attempts parameter in the Reattempts Profile.
6. If all the recreate attempts get failed and the Abort or Terminate Session on Binding Error parameter value under the PCF Session Management configuration is set to True, then PCF sends the termination notification to the SMF. In case the parameter value is set to False, PCF does not terminate the SM session. For more information about configuration, see Managing Retrying Binding Registration on BSF .

Handling of Pending Operations by SM Service

The SM service maintains a record of the pending binding requests in the Pending Operations database table. For any binding create request failure, if the error response matches with the configured error codes, then SM service creates a record in the Pending Operations database table with the key details. The Pending Operations table can be configured using the Audit configurations of the PCF Session Management configurations.

Handling of Pending Operations by Audit Service

The Policy Audit service controls the notification flow for binding registrations. If enabled, the Audit service records the pending operation details in the Policy database and reports it to the SM Service in case of BSF registration failure reaches the threshold value configured by the operator.

In case of registration failure with multiple BSF instances, the database entries increases and causes congestion in the SM service while trying to process all of the pending binding requests. To handle such scenarios, SM service continuously calls the Audit Service API to check on the number of records in the table and validate if it has crossed the threshold value. On receiving the notification, the SM service rejects all the SM Create requests with a DNN for which binding has to be setup. The rejection of requests is stopped once the PendingOperation table records reaches below the set threshold.

For more information on configuring the PendingOperation settings, see Audit Service Configurations in the Managing Retrying Binding Registration on BSF .

Site Takeover

The PendingOperation table contains the details of the site that is used to process the failed SM Create requests for PCF Binding. Each site processes the entries that belong to its site. In case a site goes down and the operator wants another site to process the pending operations, the Site Takeover functionality can be enabled. For this it is necessary to create a site takeover profile specifying the site id of the site that is failing. For more information on configuring the alternate site for takeover, use the Site Takeover Configurations on the CNC Console for Policy.

Managing Retrying Binding Registration on BSF

Enable and Configure

You can enable and configure Retrying Binding Registration on BSF using the CNC Console or REST API for Policy.

• Configure using CNC Console: Perform the following feature configurations using the CNC Console:
  • Configure the Reattempt profile for BSF retry registration requests using the Reattempts Profile page. For more information, see Reattempts Profile.
  • Configure the error codes for which the reattempt must be initiated using the Attempt Alternate Route for Following Requests under the Alternate Routing Settings of the Retry Profile page. For more information, see Retry Profiles.
  • Enable the Retry BSF Registration functionality using the Binding Configuration section on the PCF Session Management page. For more information, see PCF Session Management.
  • Configure the Pending Operation table using the Audit section on the PCF Session Management page. For more information, see PCF Session Management.
  • Configure an alternate site that can take over the current site to manage the pending binding records in case of failure using the Site Takeover page. For more information, see Site Takeover.
  • You can use the Set Binding Registration to blockly rule to indicate if Binding Registration is required for managing the pending operation table of the Audit service.
  • To configure the frequency with which SM service calls the Audit service API for checking the Pending Operation table threshold, use the Advance Settings section on PCF Session Management page. For more information, see PCF Session Management.
• Configure using REST API: Perform the following feature configurations using the REST API Interface for Policy:
  • Configure the Reattempt profile for BSF retry registration requests using the Reattempts Profile configuration API.
  • Configure the error codes for which the reattempt must be initiated using the alternateRoutingSettings.errorCodesList parameter in the Retry Profile configuration API.
  • Enable the Retry BSF Registration functionality using the BindingConfiguration parameters of the Session Management Service configuration API.
  • Configure the Pending Operation table using the Audit parameters of the Session Management Service configuration API.
  • Configure an alternate site that can take over the current site to manage the pending binding records in case of failure using the siteTakeover configuration API.

    For more information about configuring the parameters through REST API, see Oracle Communications Cloud Native Core, Converged Policy REST Specification Guide.

Observe

Policy uses the following metrics to observe the Retrying Binding Registration on BSF functionality:

• occnp_pending_binding_reattempts_total
• occnp_pending_binding_terminate_all_attempts_failed_total
• occnp_pending_binding_reattempt_fail_total
• occnp_pending_operation_threshold_reached_total
• occnp_reject_sm_create_threshold_reached_total
• occnp_audit_db_records_count_belonging_to_site

Policy uses the following alerts to monitor the pending operations:

• pcf_pending_binding_records_count
• pcf_pending_binding_site_takeover
• pcf_pending_binding_threshold_limit_reached

4.104 Controlled Shutdown of an Instance

Policy supports controlled shutdown feature to provide the partial or complete isolation of the site from the network so that the operator can perform necessary recovery procedures when required. It helps the operator to perform the recovery procedures as per the requirement.

The site isolation is achieved by shutting down the load at gateways (Ingress Gateway, Egress Gateway, and Diameter Gateway) and updating the NF status as SUSPENDED at NRF.

Note:

Ingress Gateway Service must be enabled for the working of this feature.

Operational State

The site can be in one of the three possible operational states NORMAL, PARTIAL SHUTDOWN, or COMPLETE SHUTDOWN. The operational state can move to any of the states from the current state, there is no definitive order of state change. Currently, the operational state is stored in the common config server of the Ingress Gateway. It is read by Ingress Gateway, Egress Gateway, Diameter Gateway, and App-info periodically and action is triggered based on the current state.

Note:

Since the operational state is stored in config server, the service instances will detect the state change after the config refresh is done. If the config refresh interval is set as 5 seconds, then the pods may recognize the operational state change after 5 seconds.

The operational state can be modified through CNC Console or REST API. Operation state configuration stored in the common config server will be read by the following services:

• Ingress Gateway
• Egress Gateway
• Diameter Gateway
• App-info

Note:

If the Disaster Recovery procedure is performed when the config backup was taken when the system was in PARTIAL or COMPLETE SHUTDOWN state, then manual intervention may be required to change the operational state back to NORMAL state.

Load Control

Gateways enforce load control when the system is in a PARTIAL or COMPLETE SHUTDOWN state. The level of load control varies based on the shutdown state. When in a PARTIAL SHUTDOWN state, no new session establishments are allowed so session creation messages will be rejected (with configured error code) in this state. When in complete shutdown, no messages are allowed.

Note:

When the system is in COMPLETE SHUTDOWN state, audit service triggered notification or diameter messages will be rejected at respective gateways.

Call Flow for Diameter Gateway

NORMAL State: If the Controlled shutdown operational state is NORMAL, then the Diameter Gateway processes the message as normal.

PARTIAL SHUTDOWN: If the controlled shutdown operational state is PARTIAL SHUTDOWN, then the Diameter Gateway accepts only in-session messages and rejects all CCR-I and AAR-I messages.

Figure 4-196 Call Flow for Diameter Gateway PARTIAL SHUTDOWN

When the operational mode is NORMAL, CCR-I is success. When operational mode is changed to PARTIAL SHUTDOWN, CCR-U is success but CCR-I is rejected.

COMPLETE SHUTDOWN: If the controlled shutdown operational state is COMPLETE SHUTDOWN, then the Diameter Gateway accepts only in-session messages and rejects all messages.

Figure 4-197 Call Flow for Diameter Gateway COMPLETE SHUTDOWN

When the operational mode is COMPLETE SHUTDOWN, CER is rejected when coming from external NF, but is successful when coming from backend.

Call Flow for Egress Gateway

NORMAL State: If the Controlled shutdown operational state is NORMAL, then the Egress Gateway processes the message as normal.

PARTIAL SHUTDOWN: If the controlled shutdown operational state is PARTIAL SHUTDOWN, then the Egress Gateway processes the message as normal.

COMPLETE SHUTDOWN: If the controlled shutdown operational state is COMPLETE SHUTDOWN, then the Egress Gateway processes the request as follows:

• Forward all requests received from NRF Client.
• Reject all requests received from any other services like UDR Connector, SM Service, AM Service, UE Service, and CHF Connector.

Figure 4-198 Call Flow for Egress Gateway COMPLETE SHUTDOWN

SM-Policy data request from UDR connector towards Egress Gateway will not be processed in case of COMPLETE SHUTDOWN.

Call Flow for Ingress Gateway

NORMAL State: If the Controlled shutdown operational state is NORMAL, then the Ingress Gateway processes the message as normal.

PARTIAL SHUTDOWN: If the controlled shutdown operational state is PARTIAL SHUTDOWN, then the Ingress Gateway accepts only in-session messages and rejects all SM-Create requests.

Figure 4-199 Call Flow for Ingress Gateway PARTIAL SHUTDOWN

When the operational mode is NORMAL, SM-Create is success. When operational mode is changed to PARTIAL SHUTDOWN, SM-Update is success but SM-Create is rejected.

COMPLETE SHUTDOWN: If the controlled shutdown operational state is COMPLETE SHUTDOWN, then the Ingress Gateway rejects all incoming requests.

Figure 4-200 Call Flow for Ingress Gateway COMPLETE SHUTDOWN

In Ingress Gateway COMPLETE SHUTDOWN, all the requests coming from external NFs are rejected.

App-info

App-info calculates the service status of the NF periodically, and this calculation has three possible outcomes viz Running, Not Running, and Deregister. Whenever the system's operation state is changed to PARTIAL or COMPLETE SHUTDOWN and the calculated status is "Running" then the status will be overridden and changed to "Not Running".

Managing Controlled Shutdown of an instance

Enable

You can enable or disable the Controlled Shutdown feature by using the enableControlledShutdown parameter in the custom.yaml file. This parameter is set as false by default. You can enable it by setting its value as true. For more information, see Controlled Shutdown Configurations section in the Oracle Communications Cloud Native Core, Converged Policy Installation, Upgrade, Fault Recovery Guide.

Configure

Diameter Gateway and Ingress Gateway can be configured through CNC Console. For more information, see Controlled Shutdown Configurations.

For SBI, it is mandatory to configure SBI Ingress Error Mapping for each route that needs to be rejected during a complete shutdown. These routes must be explicitly mapped to the intended error code through CNC Console configuration.

For diameter, in the event of a complete shutdown, if there are no configurations for diameter error mapping, any new connection attempt is rejected using the default result code DIAMETER_UNABLE_TO_COMPLY (5012).

Egress Gateway routes configuration for controlled shutdown is done through Helm. For more information, see the Controlled Shutdown Configurations section in the Oracle Communications Cloud Native Core, Converged Policy Installation, Upgrade, Fault Recovery Guide.

Observe

Metrics

Policy provides the following metrics specific to controlled shutdown feature:

• system_operational_state

  For more information, see CM Service Metrics.

• diam_controlled_shutdown_message_reject_total

  For more information, see Diameter Gateway Metrics.

Alerts

Policy provides the following alerts for controlled shutdown feature:

• SYSTEM_IMPAIRMENT_MAJOR
• SYSTEM_IMPAIRMENT_CRITICAL
• SYSTEM_OPERATIONAL_STATE_NORMAL
• SYSTEM_OPERATIONAL_STATE_PARTIAL_SHUTDOWN
• SYSTEM_OPERATIONAL_STATE_COMPLETE_SHUTDOWN

For more information, see Common Alerts.

4.105 Enhancement to use Cached NRF Discovery Responses

Policy communicates with different Network Functions (NFs) through the NRF-Client discovery service. As a Consumer NF, Policy registers with NRF and discovers the required Producer NF through the NRF Client discovery feature.

PCF is enabled to maintain a cache of the NF Profiles discovered autonomously through the NRF Client management. The cache stores the NF Profiles with the NF Type and locality details of the discovered NFs.

Note:

Policy supports the enhancement to use Cached NRF discovery responses in case of failure and unusable producers for autonomous discovery only.

PCF is enabled to cache the discovered NF Profiles from NRF for autonomous discovery for producer NFs, such as CHF and BSF. It uses the cache to perform the following functions:

• Rediscovers the NF Profiles for which the validity time is expired
• Rediscovers the NF Profiles when all the discovered profiles for a particular query parameter are in the Suspended state, irrespective of their validity time. Note: PCF does not use the NFs in the suspended state.
• Uses the expired discovered profiles, which are in the Registered state in case the NRF is unreachable during rediscovery

NF Discovery and Rediscovery Based using PCF Cache

The following call flow describes an example of PCF performing the NF discovery through NRF Client and maintaining a cache:

The call flow is described as follows:

Figure 4-201 Call Flow - NRF Rediscovery

1. During PCF deployment, operators provide a list of NFTypes, which must be automatically subscribed by the NRF Client. NRF triggers the NRF discovery operation for the set of NfTypes provided for auto-subscription.
2. NRF sends the discovery response to the PCF with the query parameters. At runtime, when there is any change in the profiles, the NRF notifies PCF about the changed profiles.

3. PCF stores the producer NF details and their query parameters in a cache. It uses the validity period parameter to calculate the expiry time the producer NF profile. Once the validity period is over, the NF profile is considered Expired and PCF rediscovers the NF profiles. The expiry duration can be any of the following values:

   • The validity period included in the discovery response from the NRF Client
   • The value configured in the validityTime parameter through the Policy Custom Values YAML file.

   Whichever is the minimum value for the validity period is considered the expiry duration.

   Example:

   During PCF deployment, the nrf-client.profile.validityTime parameter value is configured as 60 seconds. And the validityPeriod provided by NRF during discovery is as follows:

   • For UDR: 30 seconds
   • For CHF: 150 seconds
   • For BSF: 90 seconds
   Then, the expiry duration for the respective producer NFs is as follows:

   • For UDR: 30 seconds
   • For CHF: 60seconds
   • For BSF: 60 seconds
4. In case, the validity period for a producer NF expires, then PCF sends the rediscovery request to the NRF and updates the cache with the latest response.

   Note:

   In case of an empty response from NRF, PCF considers it as valid response and stores in the cache for both for initial discovery and rediscovery. It sends a rediscovery request once the empty response expires.

NF Discovery Error Scenario

The call flow is described as follows:

Figure 4-202 Call Flow - NF Discovery Error Scenario

1. In the case of an Expired NF producer, PCF sends a rediscovery request to NRF.
2. PCF may attempt to send an NRF discovery request to another NRF. If another NRF still responds with an error or still timeout, PCF continues using the cache for the expired producer and after the validity time, it sends another NRF discovery request.
3. If the NRF rediscovery fails and NRF sends an error response to PCF, then the PCF keeps on using the expired records available in the cache.
4. PCF continues sending the rediscovery requests to NRF based on the expiry duration for the producer NF.

   Note:

   If all the NF producers available in the PCF cache are suspended, then PCF rejects the NRF discovery request. When the cache is not yet expired, and there is no available NFs in the cache due to all of the cached NFs having gone into suspend status, ignore the TTL & trigger a discovery request to the NRF.

Managing the Enhancement to use Cached NRF Discovery Responses

Enable

To enable the PCF cache for NRF Discovery results set value of the nrf-client.profile.cacheDiscoveryResults parameter to true using the Custom Values YAML file for Policy.

Configure

You need to configure the Cahe of NRF Discovery Result functionality while deploying the PCF. The following parameters must be updated in the Custom Values YAML file for Policy:

Table 4-134 NRF Rediscovery Paramaters

Parameter	Description
discoveryRefreshInterval	This attribute defines the maximum ValidityPeriod at which the discovery results shall be refreshed. The ValidityPeriod received in the discovery response shall be capped at this value. If ValidityPeriod received in discovery results is 60s. The validityPeriod shall be capped to 10s as per configuration. If ValidityPeriodn received in discovery results is 5s. No capping shall be applied and valdiityPeriod shall be considered as 5s. Default: 10
discoveryDurationBeforeExpiry	This attributes defines the rate at which the NF shall resend discovery requests to NRF. The value shall be configured in terms of percentage(1-100). if the discovery ValidityPeriod is 10s(after applying the capped value of discoveryRefreshInterval), then the discovery requests shall be sent at discoveryDurationBeforeExpiry * 10/100.
enableDiscoveryRefresh	Feature flag to enable Automatic Discovery Refresh. Default: false
enableRediscoveryIfNoProdNFs	Feature flag to enable automatic rediscovery in case no producer NF is available. Default: false
offStatesForRediscoveryIfNoProdNFs	The NF producer status for which discovery request must be sent to NRF. It indicates the nfStatus to be considered for unavailability of all profiles and performing Rediscovery: Provide comma separated value for desired states. Possible values: SUSPENDED UNDISCOVERABLE DEREGISTERED
discoveryRetryInterval	The Retry Interval after a failed autonomous discovery request.

4.106 Limiting the Number of Sessions

Limiting the Number of Sessions feature is implemented to manage and control the usage of resources. When this feature is enabled, Policy allows you to configure the maximum number of active sessions. It avoids multiple policy association table entries for a subscriber, in the respective policy service database tables (such as SMPolicyAssociations, AMPolicyAssociations, and UEPolicyAssociations)

Limiting the number of sessions for AM service and UE Policy service

The following are the parameters used to enable maximum sessions limit for each of the services:

• Enable Max Session Limit parameter for AM Service
• Enable Max Session Limit parameter for UE Policy Service

When the Policy service receives request for a new session and if the maximum sessions limit for the subscriber is enabled, it checks if there are existing sessions for the same subscriber (SUPI).

If the number of sessions for the same subscriber (SUPI) exceeds the Max Session Limit Per User configured, it creates a policy association for the new session in its respective database and deletes the oldest session based on the session created timestamp. The policy service initiates a local delete request.

Note:

In Kubernetes deployment resource AM Service and UE Policy Service, the LIMITING_SESSION_DELETE_DELAY_MILLIS environment variable is configured to set a delay for initiating the local delete of the older session when the number of sessions for a subscriber (SUPI) exceeds the Max Session Limit Per User. The default value of LIMITING_SESSION_DELETE_DELAY_MILLIS is 3000 milliseconds.

For example, if the Max Session Limit Per User configured for UE Policy Service is 2. When a third session is created for a subscriber with two existing sessions, the UE Policy Service creates a UEPolicyAssociation for the new session and deletes the oldest session from UE Policy database. The policy service initiates a local delete request.

Note:

The oldest session is deleted only from the local policy service and PolicyDS databases if the number of sessions exceeds the Max Session Limit Per User.

Figure 4-203 Limiting the number of sessions for UE Policy Service

Limiting the number of sessions per subscriber and DNN+SNSSAI for SM service and PCRF Core service

Whenever there is a CREATE request for a new SM session or PCRF Core session, Policy queries the database using SUPI or GPSI or using both SUPI and GPSI. If this feature is enabled, there are two levels at which the number of sessions are limited:

Limiting the maximum number of bindings at DNN + SNSSAI level

This is the first level of limiting the bindings at Binding service.

When limiting the maximum number of bindings at DNN + SNSSAI, Binding service limits the bindings based on the context owner (SM service/ PCRF Core service).

Note:

SNSSAI is considered depending on the Binding configuration in CNC Console.

You can enable and configure limiting the number of bindings at DNN + SNSSAI level by configuring Max Session Limit By APN field in Binding Service page under Service Configurations in CNC Console.

The default limit is 2 per DNN+SNSSAI+IP domain combination.

Limiting the maximum number of bindings at user level

This is the second level of limiting the bindings at Binding service.

On top of the first level limit, user level limiting is applied. Based on the timestamp, sessions older than the configured limit, (irrespective of the DNN+SNSSAI limit) are marked as stale and are cleanedup.

You can enable limiting the number of bindings at user level using Session Limit By User field in Binding Service page under Service Configurations in CNC Console.

You can configure the number of bindings at user level by configuring Max Session Limit By User field in Binding Service page under Service Configurations in CNC Console.

The default limit is 10 per user level.

Note:

Binding service identifies the sessions as stale and it notifies SM service or PCRF Core service based on the context owner to perform the clean up.

Example 1: If Binding session Limit at DNN+SNSSAI level is configured as 2 for internet sessions, after the first two sessions are created for the user, if Binding service receives request for the creation of 3rd session, it creates the 3rd session and marks the 1st session as stale.

Table 4-135 Binding Session Limit at DNN+SNSSAI level -2

Session ID	Context Owner	DNN+SNSSAI	Timestamp	isStale	Comments
Session1	PCF-SM	Internet	'2021-05-05 01:00:00'	0	First session creation for internet session
Session2	PCF-SM	Internet	'2021-05-05 02:00:00'	0	Second session creation for internet session
Session3	PCF-SM	Internet	'2021-05-05 03:00:00'	0	Third session creation for internet session At this point DNN+SNSSAI limit exceeds. Binding service marks Session1 as stale by changing the value of isStale to 1. It indicates SM service to cleanup Session1.

Example 2: If the Binding session limit for the user is configured at level 5, after creating the first five sessions for the user, if Binding service receives request for 6th session, it creates the 6th session and marks the 1st session as stale.

Table 4-136 Binding Session Limit at User level - 5

Session ID	Context Owner	DNN+SNSSAI	Timestamp	isStale	Comments
Session1	PCF-SM	Internet	'2021-05-05 01:00:00'	0	First session creation for internet session
Session2	PCF-SM	Internet	'2021-05-05 02:00:00'	0	Second session creation for internet session
Session3	PCF-SM	ims	'2021-05-05 03:00:00'	0	First session creation for IMS session
Session4	PCF-SM	ims	'2021-05-05 04:00:00'	0	Second session creation for IMS session
Session5	PCF-SM	gaming	'2021-05-05 05:00:00'	0	First session creation for gaming session
Session6	PCF-SM	gaming	'2021-05-05 04:00:00'	0	Second session creation for gaming session At this point user limit exceeds. Binding service marks Session1 as stale by changing the value of isStale to 1. It indicates SM service to cleanup Session1.

Managing Limiting the Number of Sessions

Enable

By default, this feature is disabled for AM Service and UE Policy Service and enabled for SM service and PCRF Core service on the Policy deployment.

You can enable the Limiting the Number of Sessions functionality using the CNC Console or REST API for Policy.

• Enable using CNC Console:
  • To enable the feature for AM Service, set the value of Enable Max Session Limit flag to true under Access and Mobility page.

    For more details on enabling the flag for AM Service, see PCF Access and Mobility.

  • To enable the feature for UE Policy Service, set the value of Enable Max Session Limit flag to true under UE Policy Service page.

    For more details on enabling the flag for UE Policy Service, see PCF UE Policy Service.

  • To enable limiting the number of sessions at user level (for SM service and PCRF Core), set the value of Session Limit By User flag to true under Binding Service page.

    For more details on enabling the Session Limit By User flag, see Binding Service.

  • To enable limiting the number of sessions at DNN + SNSSAI level, configure Max Session Limit By APN field under Binding Service page.

    For more details on enabling and configuring limiting number of sessions at DNN + SNSSAI level using Max Session Limit By APN field , see Binding Service.

• Enable using REST API:
  • To enable the feature for AM Service, set the value as true for enableLimitingSessionByPerUser parameter under the System group in the {apiRoot}/oc-cnpolicy-configuration/v1/services/pcfam REST API.
  • To enable the feature for UE Policy Service, set the value as true for enableLimitingSessionByPerUser parameter under the System group in the {apiRoot}/oc-cnpolicy-configuration/v1/services/pcfue REST API.
  • To enable limiting the number of sessions at user level (for SM service and PCRF Core), set the value of enableSessionLimitByUser parameter to true in {apiRoot}/oc-cnpolicy-configuration/v1/services/binding REST API.
  • To enable limiting the number of sessions at DNN + SNSSAI level, configure maxSessionLimitByApn parameter in {apiRoot}/oc-cnpolicy-configuration/v1/services/binding REST API.

  For more details on enabling the flag using REST API, see Converged Policy REST Specifications section in Oracle Communications Cloud Native Core, Converged Policy REST Specification Guide.

Configure

You can configure the Limiting the Number of Sessions functionality using the CNC Console or REST API for Policy.

• Configure using CNC Console:
  To configure Limiting Number of Sessions feature for AM Service and UE Policy Service, perform the feature configurations under the System group on the respective service configurations page. For more information, see the following sections:

  • PCF Access and Mobility
  • PCF UE Policy Service

  To configure limiting the number of sessions per subscriber and DNN+SNSSAI for SM service and PCRF Core service, configure Session Limit By User, Max Session Limit By User, and Max Session Limit By APN fields under Binding Service page. For more information, see Binding Service.

• Configure using REST API: Policy provides the following REST API to configure the Limiting the Number of Sessions functionality:
  • AM service: {apiRoot}/oc-cnpolicy-configuration/v1/services/pcfam
  • UE Policy service: ​{apiRoot}/oc-cnpolicy-configuration/v1/services/pcfue
  • Limiting the number of sessions per subscriber and DNN+SNSSAI for SM service and PCRF Core service: ​{apiRoot}/oc-cnpolicy-configuration/v1/services/binding

Observe

The following metrics are added to AM Service metrics:

• session_info_request_total
• session_info_response_total

The following metrics are added to UE Policy Service metrics:

• session_info_request_total
• session_info_response_total

For more details on these metrics, see the following sections:

• AM Service Metrics
• UE Service Metrics

Logging

Below is the sample log that can be seen in pcf-am once the Max Session limit is hit, and the older session will be deleted.

{"instant":{"epochSecond":1669193988,"nanoOfSecond":609281261},"thread":"pool-4-thread-15","level":"DEBUG","loggerName":"ocpm.pcf.service.am.core.LimitingSessionManager","message":"Limiting Number of Sessions Feature is enabled : true","endOfBatch":false,"loggerFqcn":"org.apache.logging.slf4j.Log4jLogger","threadId":1181,"threadPriority":5,"messageTimestamp":"2022-11-23T08:59:48.609+0000"}
 
 
{"instant":{"epochSecond":1669193988,"nanoOfSecond":614094447},"thread":"pool-4-thread-15","level":"DEBUG","loggerName":"ocpm.pcf.service.am.core.LimitingSessionManager","message":"Existing Session count :3 exceed max session count limit: 2","endOfBatch":false,"loggerFqcn":"org.apache.logging.slf4j.Log4jLogger","threadId":1181,"threadPriority":5,"messageTimestamp":"2022-11-23T08:59:48.614+0000"}
{"instant":{"epochSecond":1669193988,"nanoOfSecond":614431105},"thread":"pool-4-thread-15","level":"DEBUG","loggerName":"ocpm.pcf.service.am.core.LimitingSessionManager","message":"The stale association Ids to be deleted are [5d0ff3a0-0b47-42ab-8fe2-829934465619]","endOfBatch":false,"loggerFqcn":"org.apache.logging.slf4j.Log4jLogger","threadId":1181,"threadPriority":5,"messageTimestamp":"2022-11-23T08:59:48.614+0000"}
 
 
{"instant":{"epochSecond":1669193991,"nanoOfSecond":624093788},"thread":"pool-4-thread-16","level":"INFO","loggerName":"ocpm.cne.common.logging.http.HttpLogger","marker":{"name":"SUBSCRIBER"},"message":"HttpLog: {type: 'CLIENT_REQUEST', requestId: 'supi;imsi-450081000000002-894f996b-5f94-43f8-9f49-de2753b8c02e', uri: 'http://10.233.74.200:8000/pds/v2/user-data?reqParam=%7B%22amPolicyDataReq%22%3A%7B%22subscription%22%3Atrue%2C%22resetContext%22%3Afalse%2C%22processEtag%22%3Afalse%7D%2C%22ssvEnabled%22%3Afalse%2C%22resetContextSSV%22%3Afalse%7D&param=%7B%22user%22%3A%7B%22userIds%22%3A%7B%22gpsiSet%22%3A%5B%22msisdn-12345678901234%22%5D%2C%22supiSet%22%3A%5B%22imsi-450081000000002%22%5D%7D%7D%2C%22request%22%3A%7B%22requestType%22%3A%22DELETE%22%2C%22operationType%22%3A%22DELETE%22%2C%22contextOwner%22%3A%22PCF_AM%22%2C%22contextId%22%3A%225d0ff3a0-0b47-42ab-8fe2-829934465619%22%2C%22notificationInfo%22%3Anull%7D%2C%22dnn%22%3A%22NA%22%2C%22gpsi%22%3A%22msisdn-12345678901234%22%2C%22sliceinfo%22%3A%7B%22sst%22%3A%22NA%22%2C%22sd%22%3A%22NA%22%7D%2C%22supi%22%3A%22imsi-450081000000002%22%7D', method: 'DELETE', headers: '{subscriber-logging=[supi;imsi-450081000000002, supi;imsi-450081000000002], Accept=[*/*], User-Agent=[Jetty/9.4.49.v20220914], Host=[10.233.74.200:8000], Accept-Encoding=[gzip]}', body: ''}","endOfBatch":false,"loggerFqcn":"org.apache.logging.slf4j.Log4jLogger","threadId":1184,"threadPriority":5,"messageTimestamp":"2022-11-23T08:59:51.624+0000"}
 
 
{"instant":{"epochSecond":1669193991,"nanoOfSecond":647017328},"thread":"pool-4-thread-17","level":"INFO","loggerName":"ocpm.pcf.service.am.serviceconnector.PolicyConnector","message":"Policy Request sent to : http://ross-helm-occnp-pre:8000/v1/policy/engine/pcf-am httpHeader:{subscriber-logging=[supi;imsi-450081000000002, supi;imsi-450081000000002]} {\"request\":{\"requestType\":\"AMF\",\"operationType\":\"DELETE\"},\"policyAssociation\":{\"associationId\":\"5d0ff3a0-0b47-42ab-8fe2-829934465619\",\"createdTimestamp\":\"2022-11-23T08:59:22.073387212Z\",\"user\":{\"lastModificationTimestamp\":1669193988612,\"cid\":0,\"userIds\":{\"LASTACCESSTIME\":\"2022-11-23 08:59:22\",\"PEI\":\"imei-100120010030110\",\"SUPI\":\"imsi-450081000000002\",\"SITEID\":\"fe7d992b-0541-4c7d-ab84-c6d70b1b0123\",\"GPSI\":\"msisdn-12345678901234\"},\"amPolicyData\":{\"lastErrorcode\":null,\"subscCats\":[\"Sliver\"]}},\"policyAssociation\":{\"request\":{\"notificationUri\":\"http://10.233.14.139:8080/amf/notify\",\"supi\":\"imsi-450081000000002\",\"gpsi\":\"msisdn-12345678901234\",\"accessType\":\"3GPP_ACCESS\",\"pei\":\"imei-100120010030110\",\"userLoc\":{\"nrLocation\":{\"tai\":{\"plmnId\":{\"mcc\":\"460\",\"mnc\":\"30\"},\"tac\":\"000C27\"},\"ncgi\":{\"plmnId\":{\"mcc\":\"460\",\"mnc\":\"30\"},\"nrCellId\":\"187900000\"},\"ueLocationTimestamp\":\"2019-03-20T14:32:22.222Z\"}},\"servingPlmn\":{\"mnc\":\"30\",\"mcc\":\"460\"},\"ratType\":\"NR\",\"servAreaRes\":{\"restrictionType\":\"ALLOWED_AREAS\",\"areas\":[{\"tacs\":[\"t015\"],\"areaCodes\":\"a014\"}],\"maxNumOfTAs\":1},\"rfsp\":10,\"suppFeat\":\"0000000000000000\"},\"triggers\":[\"LOC_CH\",\"PRA_CH\"],\"servAreaRes\":{\"restrictionType\":\"ALLOWED_AREAS\",\"areas\":[{\"tacs\":[\"12\"],\"areaCodes\":\"123\"}],\"maxNumOfTAs\":1},\"rfsp\":1,\"pras\":{\"1\":{\"praId\":\"1\",\"trackingAreaList\":[{\"plmnId\":{\"mcc\":\"111\",\"mnc\":\"11\"},\"tac\":\"1111\"}]}},\"suppFeat\":\"0\"},\"policyAssociationRequest\":{\"notificationUri\":\"http://10.233.14.139:8080/amf/notify\",\"supi\":\"imsi-450081000000002\",\"gpsi\":\"msisdn-12345678901234\",\"accessType\":\"3GPP_ACCESS\",\"pei\":\"imei-100120010030110\",\"userLoc\":{\"nrLocation\":{\"tai\":{\"plmnId\":{\"mcc\":\"460\",\"mnc\":\"30\"},\"tac\":\"000C27\"},\"ncgi\":{\"plmnId\":{\"mcc\":\"460\",\"mnc\":\"30\"},\"nrCellId\":\"187900000\"},\"ueLocationTimestamp\":\"2019-03-20T14:32:22.222Z\"}},\"servingPlmn\":{\"mnc\":\"30\",\"mcc\":\"460\"},\"ratType\":\"NR\",\"servAreaRes\":{\"restrictionType\":\"ALLOWED_AREAS\",\"areas\":[{\"tacs\":[\"t015\"],\"areaCodes\":\"a014\"}],\"maxNumOfTAs\":1},\"rfsp\":10,\"suppFeat\":\"0000000000000000\"},\"userSubscription\":true,\"sbiBinding\":{},\"modelObjectId\":\"5d0ff3a0-0b47-42ab-8fe2-829934465619\"},\"user\":{\"isVisiting\":null,\"userIds\":{\"LASTACCESSTIME\":\"2022-11-23 08:59:22\",\"PEI\":\"imei-100120010030110\",\"SUPI\":\"imsi-450081000000002\",\"SITEID\":\"fe7d992b-0541-4c7d-ab84-c6d70b1b0123\",\"GPSI\":\"msisdn-12345678901234\"},\"smPolicyData\":null,\"amPolicyData\":{\"lastErrorcode\":null,\"subscCats\":[\"Sliver\"]},\"uePolicySet\":null,\"spendingLimitStatus\":null,\"operatorSpecificData\":null,\"shUserData\":null,\"ldapUserData\":null,\"ocsSpendingLimitStatus\":null,\"custom\":null}}","endOfBatch":false,"loggerFqcn":"org.apache.logging.slf4j.Log4jLogger","threadId":1185,"threadPriority":5,"messageTimestamp":"2022-11-23T08:59:51.647+0000"}
 
 
{"instant":{"epochSecond":1669193991,"nanoOfSecond":679435548},"thread":"pool-4-thread-18","level":"DEBUG","loggerName":"ocpm.cne.common.db.JdbcTable","message":"trying to execute sql : delete from AmPolicyAssociation where k = ?","endOfBatch":false,"loggerFqcn":"org.apache.logging.slf4j.Log4jLogger","threadId":1190,"threadPriority":5,"messageTimestamp":"2022-11-23T08:59:51.679+0000"}
{"instant":{"epochSecond":1669193991,"nanoOfSecond":683701171},"thread":"pool-4-thread-18","level":"DEBUG","loggerName":"ocpm.cne.common.db.JdbcTable","message":"deleted 1 records from table AmPolicyAssociation with key 5d0ff3a0-0b47-42ab-8fe2-829934465619","endOfBatch":false,"loggerFqcn":"org.apache.logging.slf4j.Log4jLogger","threadId":1190,"threadPriority":5,"messageTimestamp":"2022-11-23T08:59:51.683+0000"}

Below is the sample log that can be seen in pcf-ue once the Max Session limit is hit, and the older session will be deleted.

{"instant":{"epochSecond":1669195257,"nanoOfSecond":357845539},"thread":"pool-3-thread-9","level":"DEBUG","loggerName":"ocpm.pcf.service.uepolicy.core.LimitingSessionCountManager","message":"The limiting no of sessions feature is enabled","endOfBatch":false,"loggerFqcn":"org.apache.logging.slf4j.Log4jLogger","threadId":1342,"threadPriority":5,"messageTimestamp":"2022-11-23T09:20:57.357+0000"}
 
{"instant":{"epochSecond":1669195257,"nanoOfSecond":363242218},"thread":"pool-3-thread-9","level":"DEBUG","loggerName":"ocpm.pcf.service.uepolicy.core.LimitingSessionCountManager","message":"Checking if limit of association Ids is exceeded","endOfBatch":false,"loggerFqcn":"org.apache.logging.slf4j.Log4jLogger","threadId":1342,"threadPriority":5,"messageTimestamp":"2022-11-23T09:20:57.363+0000"}
{"instant":{"epochSecond":1669195257,"nanoOfSecond":363456742},"thread":"pool-3-thread-9","level":"DEBUG","loggerName":"ocpm.pcf.service.uepolicy.core.LimitingSessionCountManager","message":"The association ids to be deleted are [ocpm.pcf.service.uepolicy.model.UePolicyAssociationImpl@3f172e31]","endOfBatch":false,"loggerFqcn":"org.apache.logging.slf4j.Log4jLogger","threadId":1342,"threadPriority":5,"messageTimestamp":"2022-11-23T09:20:57.363+0000"}
 
{"instant":{"epochSecond":1669195260,"nanoOfSecond":377243552},"thread":"pool-3-thread-10","level":"INFO","loggerName":"ocpm.pcf.service.uepolicy.serviceconnector.UserServiceConnector","message":"Sent DELETE Request: http://ross-helm-occnp-policy-ds:8000/pds/v2/user-data?param=%7B%0A%20%20%22user%22%20%3A%20%7B%0A%20%20%20%20%22userIds%22%20%3A%20%7B%0A%20%20%20%20%20%20%22gpsiSet%22%20%3A%20%5B%20%22msisdn-10000000018%22%20%5D%2C%0A%20%20%20%20%20%20%22supiSet%22%20%3A%20%5B%20%22imsi-450081000000018%22%20%5D%0A%20%20%20%20%7D%0A%20%20%7D%2C%0A%20%20%22request%22%20%3A%20%7B%0A%20%20%20%20%22requestType%22%20%3A%20%22DELETE%22%2C%0A%20%20%20%20%22operationType%22%20%3A%20%22DELETE%22%2C%0A%20%20%20%20%22contextOwner%22%20%3A%20%22PCF_UE%22%2C%0A%20%20%20%20%22contextId%22%20%3A%20%22e5c1d501-7761-409a-895c-ed17d224ba99%22%2C%0A%20%20%20%20%22notificationInfo%22%20%3A%20null%0A%20%20%7D%2C%0A%20%20%22dnn%22%20%3A%20%22NA%22%2C%0A%20%20%22sliceinfo%22%20%3A%20%7B%0A%20%20%20%20%22sd%22%20%3A%20%22NA%22%2C%0A%20%20%20%20%22sst%22%20%3A%20%22NA%22%0A%20%20%7D%2C%0A%20%20%22supi%22%20%3A%20%22imsi-450081000000018%22%2C%0A%20%20%22gpsi%22%20%3A%20%22msisdn-10000000018%22%0A%7D&reqParam=%7B%0A%20%20%22ssvEnabled%22%20%3A%20false%2C%0A%20%20%22resetContextSSV%22%20%3A%20false%0A%7D","endOfBatch":false,"loggerFqcn":"org.apache.logging.slf4j.Log4jLogger","threadId":1349,"threadPriority":5,"messageTimestamp":"2022-11-23T09:21:00.377+0000"}
 
{"instant":{"epochSecond":1669195260,"nanoOfSecond":378500887},"thread":"SimpleAsyncTaskExecutor-57289","level":"DEBUG","loggerName":"ocpm.pcf.service.uepolicy.client.LoggingInterceptor","message":"Sending http request: Request2f16511d\n[\n\tDELETE http://ross-helm-occnp-egress-gateway:8000/namf-comm/v1/ue-contexts/imsi-450081000000018/n1-n2-messages/subscriptions/1234\n\t3gpp-sbi-target-apiroot: http://nf1stub.ross-ns.svc:8080\n\toc-access-token-request-info: {\"targetNfType\":\"AMF\",\"scope\":\"namf-comm\"}\n\t3gpp-Sbi-Max-Rsp-Time: 3000\n\t3gpp-Sbi-Sender-Timestamp: Wed, 23 Nov 2022 09:21:00.377 GMT\n\tContent-Length: 0\n\tHost: ross-helm-occnp-egress-gateway:8000\n\tConnection: Keep-Alive\n\tAccept-Encoding: gzip\n\tUser-Agent: okhttp/4.9.3\n]","endOfBatch":false,"loggerFqcn":"org.apache.logging.slf4j.Log4jLogger","threadId":68288,"threadPriority":5,"messageTimestamp":"2022-11-23T09:21:00.378+0000"}
 
{"instant":{"epochSecond":1669195260,"nanoOfSecond":425336983},"thread":"pool-3-thread-11","level":"INFO","loggerName":"ocpm.pcf.service.uepolicy.serviceconnector.PolicyServiceConnector","message":"Ready to send Policy Request to Policy Engine Service: http://ross-helm-occnp-pre:8000/v1/policy/engine/pcf-ue, {\"requestType\":\"AMF\",\"operationType\":\"TERMINATE\",\"policyAssociationRequest\":{\"notificationUri\":\"http://10.233.14.139:8080/amcs/v1/uepc-status\",\"supi\":\"imsi-450081000000018\",\"gpsi\":\"msisdn-10000000018\",\"accessType\":\"3GPP_ACCESS\",\"pei\":\"imeisv-9902267900440101\",\"userLoc\":{\"nrLocation\":{\"tai\":{\"plmnId\":{\"mcc\":\"450\",\"mnc\":\"05\"},\"tac\":\"004743\"},\"ncgi\":{\"plmnId\":{\"mcc\":\"450\",\"mnc\":\"05\"},\"nrCellId\":\"000000000\"}}},\"servingPlmn\":{\"mnc\":\"05\",\"mcc\":\"450\"},\"ratType\":\"NR\",\"guami\":{\"plmnId\":{\"mcc\":\"450\",\"mnc\":\"05\"},\"amfId\":\"010041\"},\"suppFeat\":\"def\"},\"policyAssociation\":{\"request\":{\"notificationUri\":\"http://10.233.14.139:8080/amcs/v1/uepc-status\",\"supi\":\"imsi-450081000000018\",\"gpsi\":\"msisdn-10000000018\",\"accessType\":\"3GPP_ACCESS\",\"pei\":\"imeisv-9902267900440101\",\"userLoc\":{\"nrLocation\":{\"tai\":{\"plmnId\":{\"mcc\":\"450\",\"mnc\":\"05\"},\"tac\":\"004743\"},\"ncgi\":{\"plmnId\":{\"mcc\":\"450\",\"mnc\":\"05\"},\"nrCellId\":\"000000000\"}}},\"servingPlmn\":{\"mnc\":\"05\",\"mcc\":\"450\"},\"ratType\":\"NR\",\"guami\":{\"plmnId\":{\"mcc\":\"450\",\"mnc\":\"05\"},\"amfId\":\"010041\"},\"suppFeat\":\"def\"},\"triggers\":[],\"suppFeat\":\"0\"},\"user\":{\"subscription\":false}}","endOfBatch":false,"loggerFqcn":"org.apache.logging.slf4j.Log4jLogger","threadId":1353,"threadPriority":5,"messageTimestamp":"2022-11-23T09:21:00.425+0000"}
 
{"instant":{"epochSecond":1669195260,"nanoOfSecond":520217022},"thread":"pool-3-thread-12","level":"DEBUG","loggerName":"ocpm.cne.common.db.JdbcTable","message":"trying to execute sql : delete from UePolicyAssociation where k = ?","endOfBatch":false,"loggerFqcn":"org.apache.logging.slf4j.Log4jLogger","threadId":1356,"threadPriority":5,"messageTimestamp":"2022-11-23T09:21:00.520+0000"}
{"instant":{"epochSecond":1669195260,"nanoOfSecond":525313719},"thread":"pool-3-thread-12","level":"DEBUG","loggerName":"ocpm.cne.common.db.JdbcTable","message":"deleted 1 records from table UePolicyAssociation with key e5c1d501-7761-409a-895c-ed17d224ba99","endOfBatch":false,"loggerFqcn":"org.apache.logging.slf4j.Log4jLogger","threadId":1356,"threadPriority":5,"messageTimestamp":"2022-11-23T09:21:00.525+0000"}

4.107 Handling Stale Data in PDS

Policy supports handling the stale PDS subscriber data for the following services:

• SM Service
• AM Service
• UE Policy Service

When there is no existing session for the subscriber

When a policy service receives request for a new session from an external NF, it sends a GET request to PDS to fetch the user or the subscriber data.

If resetContextAmPolicyData or resetContextUePolicySetData flag set to true

If it is a new session for the subscriber, there will be no session information for the subscriber in the respective policy service database. While sending the GET request to PDS, the policy service sets the value of the resetContextAmPolicyData or resetContextUePolicySetData flag to true.

PDS sends a GET request to UDR Connector to fetch the user or the subscription data for the subscriber. According to the response, PDS updates the subscriber data in PolicyDS database.

Also, as there is no existing session information in PolicyDS database, PDS sends a POST subscription request to UDR Connector to create a subscription. After it receives a response from the UDR Connector, PDS inserts the subscription details to its database and returns the same to the policy service.

Figure 4-204 resetContextUePolicySetData set to true when there are no existing sessions for UE Policy service

When there are existing sessions for the subscriber

When a policy service receives request for a new session from an external NF, it sends a GET request to PDS to fetch the SSV and the subscription data.

If resetContextAmPolicyData or resetContextUePolicySetData flag set to false

If there are existing sessions for the subscriber, while sending the GET request to PDS, the policy service sets the value of the resetContextAmPolicyData or resetContextUePolicySetData flag to false.

As resetContextAmPolicyData or resetContextUePolicySetData flag is set to false, PDS does not attempt to get the data from UDR Connector.

PDS updates the PolicyDS database as per the request received from the policy service. It responds to the policy service with the data present in PolicyDS database.

If CONCURRENT_REQUEST_GUARD_TIME is configured, PDS removes the sessions which are older than the guard time.

Figure 4-205 resetContextUePolicySetData set to false when there are existing sessions for UE Policy service

Revalidation of the subscriber data in PDS

If the revalidation configuration is enabled for PDS, that is, if Enable Fetch and Resubscribe is set to true, and there is already existing information for the subscriber in its database, if the number of sessions exceeds the Max Sessions Count, PDS sends a GET request to re-fetch the subscription data from UDR Connector.

PDS sends a PUT subscription request to UDR Connector with the stored subscription details from its PolicyDS database. If the subscription details are validated successfully, UDR Connector responds with a 200 ok message.

If the validation fails, UDR Connector responds with a 404 response. PDS sends a POST subscription request to UDR Connector to create a subscription. UDR Connector forwards the POST subscription request to UDR Server. After UDR Server responds to UDR Connector, UDR Connector responds to PDS with the subscription details received from UDR Server. PDS inserts the subscription details to the PolicyDS database and returns the same to the policy service.

Example:

Here is an example call flow for revalidation of the subscription data for UE Policy Service sessions.

Figure 4-206 Revalidation of the subscription data for UE Policy Sessions

Managing Handling PDS Stale Sessions

Enable

You can enable resetContextAmPolicyData and resetContextUePolicySetData flags in custom-values.yaml file.

For more information about the resetContext flags for AM Service and UE Policy Service, see Customizing Policy chapter Oracle Communications Cloud Native Core, Converged Policy Installation, Upgrade and Fault Recovery Guide.

To enable the PDS revalidation functionality:

You can enable the PDS revalidation functionality using the CNC Console or REST API for Policy.

• Enable using CNC Console:

  To enable the PDS revalidation functionality using the CNC Console, set the value of Enable Fetch and Resubscribe flag to true in the PDS page.

  For more details about Enable Fetch and Resubscribe flag, see PDS.

• Enable using REST API:

  To enable the PDS revalidation functionality, set the value as true for enableFetchAndResubscribe parameter under the Common group in the {apiRoot}​/oc-cnpolicy-configuration​/v1​/services​/pds​/pdsSettings REST API.

  For more details on enabling the flag using REST API, see Policy REST Specifications section in Oracle Communications Cloud Native Core, Converged Policy REST Specification Guide.

Configure

You can configure resetContextAmPolicyData and resetContextUePolicySetData flags in custom-values.yaml file.

For more information about the resetContext flags for AM Service and UE Policy Service, see Customizing Policy chapter Oracle Communications Cloud Native Core, Converged Policy Installation, Upgrade and Fault Recovery Guide.

To enable the PDS revalidation functionality:

You can configure the PDS revalidation functionality to handle the stale PDS data using the CNC Console or REST API for Policy.

• Configure using CNC Console:

  To configure PDS revalidation functionality in PDS, perform the feature configurations on PDS page. For more details, see PDS.

• Configure using REST API: Policy provides {apiRoot}​/oc-cnpolicy-configuration​/v1​/services​/pds​/pdsSettings REST API to configure the PDS revalidation functionality.

Note:

In case of PDS subscriber data revalidation for UE and AM policy services, the value of DNN, SD and SST parameters must be NA.

Observe

The following metrics are used to support the PDS revalidation functionality:

• remove_contextInfo_total
• revalidation_request
• revalidation_response

For details on the metrics, see Policy DS Metrics.

Logging

Below is the sample log from Policy-ds when MaxSessionLimit is hit for revalidation.

{"instant":{"epochSecond":1669192175,"nanoOfSecond":908706032},"thread":"boundedElastic-29","level":"DEBUG","loggerName":"ocpm.uds.policyds.workflow.flowtask.dbtask.AbstractDBFlowTask","message":"Comparing Existing Dnn Slice count Map :{NA:NA:NA=1} with Configured Max Dnn Slice Count
        Map : {NA:NA:NA=1} ","endOfBatch":false,"loggerFqcn":"org.apache.logging.slf4j.Log4jLogger","threadId":7491,"threadPriority":5,"messageTimestamp":"2022-11-23T08:29:35.908+0000"}{"instant":{"epochSecond":1669192175,"nanoOfSecond":909143676},"thread":"boundedElastic-29","level":"INFO","loggerName":"ocpm.uds.policyds.workflow.flowtask.dbtask.AbstractDBFlowTask","message":"Revalidation is required so going to fetch updated data for source type:
        SpendingLimitData","endOfBatch":false,"loggerFqcn":"org.apache.logging.slf4j.Log4jLogger","threadId":7491,"threadPriority":5,"messageTimestamp":"2022-11-23T08:29:35.909+0000"}  {"instant":{"epochSecond":1669192175,"nanoOfSecond":910933620},"thread":"boundedElastic-29","level":"DEBUG","loggerName":"ocpm.uds.policyds.workflow.flowtask.dbtask.AbstractDBFlowTask","message":"Comparing Existing Dnn Slice count Map :{NA:NA:NA=1} with Configured Max Dnn Slice Count
        Map : {NA:NA:NA=1} ","endOfBatch":false,"loggerFqcn":"org.apache.logging.slf4j.Log4jLogger","threadId":7491,"threadPriority":5,"messageTimestamp":"2022-11-23T08:29:35.910+0000"}{"instant":{"epochSecond":1669192175,"nanoOfSecond":911364865},"thread":"boundedElastic-29","level":"INFO","loggerName":"ocpm.uds.policyds.workflow.flowtask.dbtask.AbstractDBFlowTask","message":"Revalidation is required so going to fetch updated data for source type:
        AmPolicyData","endOfBatch":false,"loggerFqcn":"org.apache.logging.slf4j.Log4jLogger","threadId":7491,"threadPriority":5,"messageTimestamp":"2022-11-23T08:29:35.911+0000"} {"instant":{"epochSecond":1669192175,"nanoOfSecond":915496199},"thread":"boundedElastic-29","level":"INFO","loggerName":"ocpm.uds.policyds.rest.client.WebClientServiceImpl","message":"Req
        body{\"amPolicyDataReq\":{\"subscription\":false,\"params\":null,\"resetContext\":false,\"processEtag\":false},\"ssvEnabled\":false,\"resetContextSSV\":false}
        sent to URL http://ross-helm-occnp-udr-connector:8000/userservice/user-data/imsi-450081000000024,msisdn-12345678901234 with
        header {uber-trace-id=[a398635f494761ab:a398635f494761ab:0:0,
        37b688bf4531ac85:37b688bf4531ac85:0:0],
          oc-data-source-route-info=[{\"amPolicyData\":{\"dataSourceInfo\":{\"dataSourceId\":\"fe7d992b-0541-4c7d-ab84-555552222222:94d8d19a-b0d9-4d6d-994f-39a49ed5c111\",\"host\":\"nf1stub.ross-ns.svc\",\"port\":8080},\"subscriptionResourceInfo\":{\"subscriptionId\":\"http://nf1stub.ross-ns.svc:8080/nudr-dr/v1/policy-data/subs-to-notify/1\",\"host\":\"nf1stub.ross-ns.svc\",\"port\":8080,\"subscriptionData\":\"{\\\"policyDataSubscription\\\":{\\\"notificationUri\\\":\\\"https://ross-helm-occnp-ingress-gateway:443/udrservice/notification/imsi-450081000000024\\\",\\\"monitoredResourceUris\\\":[\\\"http://nf1stub.ross-ns.svc:8080/nudr-dr/v1/policy-data/ues/imsi-450081000000024/am-data\\\"],\\\"supportedFeatures\\\":\\\"f\\\"}}\"},\"nfBindingInfo\":{},\"otherAttr\":{\"processETag\":false}}}]}
        ","endOfBatch":false,"loggerFqcn":"org.apache.logging.slf4j.Log4jLogger","threadId":7491,"threadPriority":5,"messageTimestamp":"2022-11-23T08:29:35.915+0000"} {"instant":{"epochSecond":1669192175,"nanoOfSecond":922192005},"thread":"boundedElastic-29","level":"INFO","loggerName":"ocpm.uds.policyds.rest.client.WebClientServiceImpl","message":"Req bodynull sent to URL http://ross-helm-occnp-chf-connector:8000/chfservice/spending-limit/imsi-450081000000024?gpsi=msisdn-12345678901234&plmn.mcc=460&plmn.mnc=30&asyncQuery=false&resetContext=false with
        header {uber-trace-id=[a398635f494761ab:a398635f494761ab:0:0,
        37b688bf4531ac85:37b688bf4531ac85:0:0, bc38f03768302c41:bc38f03768302c41:0:0],
        3gpp-Sbi-Max-Rsp-Time=[2700],
          oc-data-source-route-info=[{\"spendingLimitStatus\":{\"dataSourceInfo\":{\"dataSourceId\":\"fe7d992b-0541-4c7d-ab84-666666666666:chf1\",\"host\":\"nf1stub.ross-ns.svc\",\"port\":8080},\"subscriptionResourceInfo\":{\"subscriptionId\":\"http://nf1stub.ross-ns.svc/nchf-spendinglimitcontrol/v1/subscriptions/1\",\"host\":\"nf1stub.ross-ns.svc\",\"port\":8080},\"nfBindingInfo\":{},\"otherAttr\":{}}}]}
        ","endOfBatch":false,"loggerFqcn":"org.apache.logging.slf4j.Log4jLogger","threadId":7491,"threadPriority":5,"messageTimestamp":"2022-11-23T08:29:35.922+0000"}

4.108 Support for User-Agent Header

User-Agent header helps the producer Network Function (NF) to identify the consumer NF that has sent the request. To implement this, 3GPP introduced the use of User-Agent header for consumers to include the same in service requests. Additionally, producers may require to support the validation of the User-Agent headers to complete the request identification process in the network.

With the integration of this feature, User-Agent header helps the producer Network Function (NF) to identify the consumer NF that has sent the request.

The following format is used to generate User-Agent header:

<NF Type>-<Instance-Id> <FQDN>

where, <NF Type> is the type of the Network Function.

<Instance-Id is the instance ID of the NF.

<FQDN> is the FQDN of the NF.

Example: PCF-54804518-4191-46b3-955c-ac631f953ed8 pcf1.east.5gc.mnc012.mcc234.3gppnetwork.org

There is no configuration required at PCF for incoming user-agent header. By default, PCF validates the format of the user-agent header and updates the ingress metrics.

When the User-Agent header is missing in the incoming requests sent to PCF then the corresponding metric will not be able to retrieve information from whom it is requesting the service. Nonetheless, the request will be fulfilled without any issues.

For the generation of the User-Agent header when it is enabled through Helm configurations and header information is missing, then it will be picked from the OAuthClient module to generate the header.

If the User-Agent header is present in the request towards Policy, then the value present in the header is overwritten or forwarded based on the overwriteHeader flag. If the flag is set to true, then the header is overwritten.

Note:

nfInstanceId and nfType are picked from userAgentHeader configuration, if available. Otherwise, they are picked from oauthClient configuration. This does not require oauthClient to be enabled but mandates oauth client configuration to be present. If nfInstanceId and nfType are not available in both oauth client configurations and in User-Agent configuration, then the startup probe fails.

The header is applied to every outgoing message generated from Egress Gateway that includes the SMF, UE, and AM interfaces.

Managing Support for User-Agent Header

Enable

You can enable the User-Agent Header feature using REST or Helm configuration.

• Helm: Set the value of the parameter userAgentHeaderValidationConfigMode to Helm in the custom-values.yaml file. For more information, see the Oracle Communications Cloud Native Core, Converged Policy Installation, Upgrade and Fault Recovery Guide.
• REST API: Set the value of the parameter userAgentHeaderValidationConfigMode to REST in the custom-values.yaml file. REST configuration from the JSON bodies sent to path: "/pcf/nf-common-component/v1/egw/useragentheader" is stored in a database under the common_config table. For more information, see the Oracle Communications Cloud Native Core, Converged Policy REST Specifications Guide.

Configure

You can configure the User-Agent Header using REST or Helm.

Following is a sample configuration for User-Agent Header in custom-values.yaml.file:

userAgentHeaderConfigMode: HELM
userAgentHeader:
  enabled: false # flag to enable or disable the feature
  nfType: "PCF" # NF type of consumer NF
  nfInstanceId: "2d8e8e68-24ad-11ed-861d-0242ac120002" # NF type of consumer NF
  addFqdnToHeader: true # Flag to add fqdn. If enabled then user-agent header will be 
generated along with the fqdn configured otherwise fqdn will not be added
  nfFqdn: "oracle1.pcf.pacific.org" #fqdn of NF. This is not the fqdn of gateway
  overwriteHeader: true

To configure the User-Agent header at Egress Gateway using REST API, see user-Agent Header in Oracle Communications Cloud Native Core, Converged Policy REST Specifications Guide.

Observe

Policy provides the following metric specific to User-Agent Header feature:

• oc.ingressgateway.http.requests

For more information, see User-Agent Header Metricssection.

4.109 Support for Spending Limit Status Reporting

Policy provides an option to enable spending limit status in each of the create, update, and delete requests from the Policy Services (SM Service, AM Service, and UE Policy Service).

The Spending Limit control service enables the Policy services to retrieve policy counter status information per subscriber from CHF.

That is, by subscribing to spending limit reporting (CHF Data), Policy services can receive notifications on Policy Counters from CHF.

PolicyDS handles the cases when multiple services subscribe to spending limit reporting as follows:

When one service subscribes to a given policy counter, another service subscribes for another policy counter, then PDS takes the policy counters from the last request and both services are subscribed to receive notifications for those policy counters.

For example:

If UE Policy Service subscribes for PC1 and PC2 and AM Service subscribes for PC3, both UE Policy Service and AM Service will receive notification only for PC3.

Whenever there is create, update, and delete requests from the Policy Services (SM Service, AM Service, and UE Policy Service), Policy checks if CHF Data flag is enabled. If the CHF Data flag is enabled, it allows interaction between PDS and CHF through CHF Connector to retrieve the CHF data,

Policy allows subscription to Spending Limit Control service (Nchf_SpendingLimitControl_Subscribe), which provides notification of changes in the status of the policy counters available and to retrieve the status of the policy counters for which the subscription is accepted.

That is, it provides:

• initial spending limit retrieval
• intermediate spending limit report retrieval

Also, Policy allows asynchronous interaction between PDS and CHF when Async CHF Query Enabled flag is set to true in the respective service configuration for SM service, AM service, or UE Policy service.

Note:

For AM and UE Policy service, this feature supports only asynchronous flow.

Call Flow

Below is an example for retrieving CHF Data for AM Service:

Figure 4-207 Spending limit status report for AM Service

Subscription create:

1. AM Service receives request for a new session from AMF.
2. AM Service checks if CHF Data flag is enabled.
3. AM Service sends a GET request to PDS to fetch the user data. If Async CHF Query Enabled flag is also enabled, it sets AsyncQuery to true in the request parameters.
4. If the user data is present in PolicyDS database, PDS responds to AM Service with 200 OK message.
5. If the requested data is not present in PolicyDS, PDS responds to AM Service with a 404 NOT FOUND message. PDS sends a request to UDR through UDR Connector to fetch the UserData.
6. AM Service, sends a POST request to PRE. Using the fetch policy counter blockly AM identifies the policy counters for which the information is requested.
7. After receiving a 200 OK response from PRE, AM Service sends a 201 created message to AMF.
8. AM sends another request to PDS of type REQUEST-PC. Since this REQUEST-PC flow is asynchronous, PDS responds immediately with a 204 OK message to AM.
9. In asynchronous way, PDS contacts CHF through CHF Connector to subscribe for the policy counters that PRE returned to AM Service.
10. After receiving the information from CHF, PDS sends a notification to AM Service with the SpendingLimit data.
11. AM Service processes this information and if needed it sends an update notify to AMF Service.

Notification call flow from CHF to SM service, AM service, and UE Policy service

Figure 4-208 Update notification to SM service, AM service, and UE Policy service

Whenever CHF detects that the status of a policy counter(s) has changed, it sends a notification to PDS.

1. The change notification can be generated for any of the following reasons.
   1. Change in status of Policy counters.
   2. Future change in status of policy counters along with time at which it will change.
   3. Policy counter identifier is no longer applicable to subscriber.
2. The update notification can include:
   • SUPI
   • GPSI
   • Policy counter status as event information
   • Pending policy counter statuses and their activation times as event information
3. PDS updates its database and sends a POST request to SM Service, AM Service or UE Service.
4. SM Service, AM Service or UE Policy Service processes the notification and if required it sends an update notify to SMF or AMF respectively.
5. SM Service, AM Service and UE Policy Services accept the message and respond with a 204 No content message back to CHF through PDS and CHF connector.

Intermediate spending limit report transaction from the CHF

CHF provides an intermediate spending limit report transaction containing pending policy counter statuses and their activation times for a previously provided policy counter.

1. PDS forwards the details to SM Service, AM Service and UE Policy Service. The Policy services replaces the existing pending policy counter statuses and their activation times if any in their respective databases.
2. If the intermediate spending limit report transaction from the CHF includes no pending policy counter statuses and their activation times are included for a policy counter, the Policy services cancels all the previously provided pending policy counter statuses and their activation times for that particular policy counter.

Below is an example for retrieving intermediate spending limit with specific policy counter Id by SM service.

Figure 4-209 Intermediate Spending Limit with Specific Policy Counter ID for SM Service

1. SM service receives a CREATE request from SMF and it sends a request to PDS to fetch the subscriber profile.
2. PDS interacts with PRE to fetch the corresponding actions and then sends a request to UDR through nUDR Connector to get the subscriber profile as requested by SM service.
3. UDR queries the UDR database and responds to PDS with User Profile data through nUDR Connector.
4. As this is for a CREATE request, PDS sends a POST request to UDR through nUDR to create a subscription. UDR responds with the subscription details.
5. PDS saves the subscription details in PolicyDS database and responds to SM service with the subscription information.
6. SM service interacts with PRE to fetch the Policy Counters with specific IDs.
7. SM service sends a POST request to Binding service to create session binding. Binding service responds to SM service with the session binding details.
8. SM service sends a request to PDS to get the spending limit data for the Policy Counters specifying the IDs.
9. PDS sends a request to CHF through nCHF Connector to subscribe for the spending limit data for the given Policy Counter IDs and receives a successful response.
10. PDS saves the details received from CHF in PolicyDS database and also responds to SM service with the spending limit data.
11. SM service responds to SMF with the received details for the CREATE request.
12. Whenever SM service receives an UPDATE request from SMF with a specific Policy Counter ID, SM service interacts with PRE to retrieve the corresponding actions from PRE.
13. SM service sends a GET request to PDS to update the spending limit data for the Policy Counter ID.
14. PDS sends a PUT request to CHF through nCHF Connector to update the spending limit data for the given Policy Counter ID and receives a successful response.
15. PDS saves the updated details in PolicyDS database and responds to SM service.
16. In turn, SM service responds to SMF.

Managing Support for Spending Limit Status Reporting

Enable

By default, Spending Limit Status Report feature is not enabled on the Policy deployment.You can enable this functionality using the CNC Console.

To enable this feature for SM Service, enable CHF Data flag under User group on the PCF Session Management page.

To enable this feature for AM Service, enable CHF Data flag under User group on the PCF Access and Mobility page.

To enable this feature for UE Policy Service, enable CHF Data flag under User group on the PCF UE Policy page.

For more details on enabling the flag for SM Service, see PCF Session Management.

For more details on enabling the flag for AM Service, see PCF Access and Mobility.

For more details on enabling the flag for UE Policy Service, see PCF UE Policy Service.

Configure

You can configure the Spending Limit Status Report feature using the CNC Console.

To configure the feature for SM, AM and UE services, perform the feature configurations under the User group on the respective service configurations page. For more information, see the following sections:

• PCF Session Management
• PCF Access and Mobility
• PCF UE Policy Service

Observe

The following metrics are added to PDS Service metrics:

• server_request_total
• server_response_total

For more details on these metrics, see Policy DS Metrics.

4.110 NF Scoring for a Site

The NF Scoring feature calculates the score for a site based on Network Function (NF) specific factors such as metrics, alerts, etc. The NF Scoring feature helps the operator to determine the health of a site as compared to other sites. Comparing the NF scores within or across the sites helps the customers to choose the site.

One of the use cases is the Controlled Shutdown feature that allows the operator to partially or completely isolate the site. The NF Scoring feature helps the operators to choose which site to partially or completely isolate based on NF scoring.

App-Info service queries and calculates NF-Score as it has the site information.

App Info Scoring Mechanism:

App Info reads the configurations from the common config server to check if NF Scoring functionality is enabled or not. It works in the following ways:

• Continuous NF Score Calculation: When the NF Scoring feature is enabled, app info periodically reads the configurations to calculate the score.
• On-Demand NF Score Calculation: When the NF Scoring feature is enabled, app info fetches all the factors or criteria to calculate the NF Score. It is real-time fetching of factors and then the NF score is calculated on demand.

Note:

NF score will calculate the alerts that contains namespace in the labels and expression.

Table 4-137 NF Scoring Criteria

Factors	Default Score	Formula to calculate Factor Score	Details
TPS	20	min(Current-TPS / Max-TPS * Max- TPS-Score, Max- TPS-Score)	Current-TPS = IGW + EGW + Diameter Ingress + Diameter Egress Max-TPS specifies the maximum TPS. Max- TPS-Score Specifies the maximum score of the TPS.
Service	30	A / N * Max-SVC-Score	A = Number of available services N = Number of configured services Max-SVC-Score Specifies the maximum score of the Service Health.
Connection	20	min(Conn-Current / Conn-Total * Conn-Score, Conn-Score)	Conn-current specifies the number of connections from network to Policy. Conn-Total specifies the total number of connections expected from network to Policy. Conn-Score specifies the score for the connection.
Replication-health	30	min(Site-Current / Site-Total * Site-Score, Site-Score)	Site-Total specifies the total number of possible replication links. Site-Current specifies the available active healthy links. Replication-health Score specifies the score for the replication-health.
Locality-Preference	5	NA	The value of Locality-Preference is added for NF score calculation.
Critical-Alerts	2	CrN * Configured-Score	CrN is the Number of active critical alarms. Configured-Score-Critical-Alerts specifies the score configured by the user.
Major-Alerts	1	MaN * Configured-Score	MaN is the Number of active Major alarms. Configured-Score-Major-Alerts specifies the score configured by the user.
Minor-Alerts	0	MiN * Configured-Score	MiN is the Number of active Minor alarms. Configured-Score-Minor-Alerts specifies the score configured by the user.

Formula for NF scoring of a site: Sum of TPS-Score, SVC-Score, Conn-Score, Replication-health, and Locality-Preference score subtracted by Alerts scores.

Call Flows

This section describes examples of the call flows for the NF Scoring feature:

Figure 4-210 Call flow to Save Configuration Data

The operator sends a request to save the configuration is sent to the CM service. It saves the configuration data to the common config database. App-Info reads the configuration data and returns the acknowledgment.

Figure 4-211 Call flow to Get the NF Score

The operator sends a request to CM service to get the score. CM service requests it to App-Info. App-Info queries and calculates NF-Score.

Managing NF Scoring for a Site

Enable

You can enable this feature by selecting the Enable NF Scoring field in the Settings page of NF Scoring.

Note:

Enabling the NF Scoring feature for the first time, requires configuring prometheusUrl and alertmanagerUrl under the appinfo and perfinfo sections in the custom-yaml. These Urls get reflected in the config-map of AppInfo and Perf-Info services. For AppInfo and PerfInfo pods to pick up these changes, they need to be restarted.

For more information about enabling the feature through CNC Console, see NF Scoring Configurations .

Configure

Configuring using CNC Console: The NF Scoring feature can be configured through CNC Console. For more information, see NF Scoring Configurations.

Note:

You can configure the env variable, NF_SCORING_INTERVAL, in deployment of app-info. Default value is 30 seconds (changing the env variable would result into restart of app-info pod).

Configuring using REST API: Policy provides the following REST API for configuration: /oc-cnpolicy-configuration/v1/ nfscore.

You can perform the GET operation to get NF score. For more information about REST API configuration, see "NF Scoring for a Site" in Oracle Communications Cloud Native Core, Converged Policy REST Specification Guide.

Observe

Metrics

Policy provides the following metrics specific to NF Scoring feature:

• nfscore
• nfScoringFactorActualValue

For more information, see AppInfo Metrics.

4.111 Consistent UDR Updates Using ETag

When two different Policies are connected to UDR in a georedundant setup and both are updating the UsageMonData for the same subscriber simultaneously, there is the possibility of data loss as the update can overwrite each other. ETag (Entity Tag) support helps to make sure that the update is successful only when the consumer has the latest set of data.

For more information on how to configure this feature using CNC Console, see the Configuring Usage Monitoring.

4.112 Support for Resource Allocation for PCC Rules

When Successful Resource Allocation (SRA) is enabled, Policy provides the status of the Policy and Charging Control Rules (PCC Rules) that are successfully installed and validated by Session Management Function (SMF).

Policy writer can make the appropriate action based on the successful activation of a rule.

For example, a Policy writer can hold updating the installed PCC rule unless SRA is applied at SMF.

Note:

This feature is applicable to the PCC Rules that are installed by Policy and not through Applicaiton Function (AF).

To apply the SRA functionality, PCC Rule must include policyCtrlReqTriggers and lastReqRuleData.

For example:

"policyCtrlReqTriggers":[
   "PLMN_CH",
   "UE_IP_CH",
   "DEF_QOS_CH",
   "AC_TY_CH",
   "SUCC_RES_ALLO"
],
"lastReqRuleData":[
   {
      "refPccRuleIds":[
         "0_2",
         "0_3"
      ],
      "reqData":[
         "SUCC_RES_ALLO"
      ]
   }
]

In the above example, SUCC_RES_ALLO under policyCtrlReqTriggers triggers the application of SRA. lastReqRuleData includes the last requested rule data and SUCC_RES_ALLO under reqData is the requested data.

Note:

Policy does not have to send any policyCtrlReqTriggers to receive failed-to-install PCC rules from SMF.

Call Flow for SRA

Figure 4-212 PCC Rule for SM Create and SM Update requests

1. SMF receives an SM Create request with the PCC Rule installation information to create a new PCC Rule p1 with requested data as SUCC_RES_ALLO indicating SRA.
2. SMF sends the SM Create request to SM Service via Ingress Gateway.
3. SM Service forwards the SM Create request to PRE for evaluation.
4. PRE evaluates the details and responds to SM Service.
5. SM Service creates the session details in the session database, sends a 201 created message to SMF via the Ingress Gateway.

   Note:

   The SM Create contains different media components. If any media component that contains a flow status set as 'removed', the notification towards SMF will not be sent.
6. SMF installs and validates PCC Rule p1. It includes SUCC_RES_ALLO under PolicyctrlReqTrigger indicating the application of SRA, along with the details of the last requested rule data and requested data containing SUCC_RES_ALLO.
7. After the session creation, SMF receives an SM Update request that includes PCC rule report for p1 with ruleStatus as ACTIVE.
8. SMF sends the SM Update request to SM Service via Ingress Gateway.
9. SM Service forwards the SM Create request to PRE for evaluation.
10. SM Service forwards the 200 ok response that it receives from PRE to SMF via the Ingress Gateway.
11. SMF validates the details and responds with a 200 ok message.

Figure 4-213 PCC Rule in SM-UPDATE-NOTIFY request (Re-authorization)

1. Policy receives an SM Update-Notify from one of the data sources such as UDR via the ingress gateway.
2. Policy sends the update notification request to SM Service.
3. SM Service acknowledges the update by returning a 200 ok message to Policy.
4. Policy in-turn responds to the data source with a 200 ok message via the ingress gateway.
5. SM Service shares the SM Update Notify details to PRE for evaluation. The update-notify information includes an update to the PCC Rule p1 with overriddenAttr containing the updates to the PCC Rule.
6. PRE evaluates the update and returns a 200 ok message to SM Service.
7. SM Service sends the SM Update Notify request to SMF via the Ingress Gateway.
8. SMF modifies and validates the PCC Rule p1 as per the given details and returns a 400/200 message to SM Service via the Ingress Gateway.
9. SM Service updates the session database accordingly.
10. After the successful processing of the SM Update-Notify request, SMF receives a SM Update request containing PCC rule report for P1 with ruleStatus as ACTIVE.
11. SMF forwards the SM Update request to SM Service via the Ingress Gateway.
12. SM Service shares the SM Update with PRE for evaluation and receives a 200 ok response.
13. SM Service sends the 200 ok response to SMF via the Ingress Gateway.

Managing Support for Successful Resource Allocation for PCC Rules

Enable

By default, the SRA support for PCC Rules is disabled. You can enable this functionality using the CNC Console.

To enable this feature, under Rule section in PCF Session Management page in CNC Console, set the value of Default PCC Rule Requested Rule Data parameter to SUCC_RES_ALLO.

For more details on enabling the SRA support for PCC Rules, see Settings.

Configure

You can use blockly action to configure Install/Update/Remove PCC Rules with Override Attributes. For more information, see PCF-SM Category in Oracle Communications Cloud Native Core, Converged Policy Design Guide.

Observe

Added rule_action metric to support Successful Resource Allocation.

For more information on metrics, see SM Service Metrics.

4.113 Subscriber State Variables in Policy

State variables hold the intermediate state of the policy evaluation. The state variables are defined by the policy writer that can be set within a policy action to be used at a later time during policy rule execution (in either conditions or actions). The names of these variables are not predefined and are determined by the policy writer.

State variables have scope which determines how long the value is persisted after it is set.

Depending on the scope, the following state variables are defined in Policy:

• Policy Evaluation State Variables: Used during Policy evaluation. These variables exist only for the lifetime of a policy evaluation cycle (the process of evaluating all the policies for a single request/context).
• Session State Variables: Contains a value that is saved as long as the session they are associated with is valid. These variables are stored in the session database in the respective core services (SM Service, AM Service, UE Policy Service, and PCRF Core). On the subsequent operation of the session, the values are extracted and reused. Once the session is terminated, these variables will no longer have a value and will no longer be available for use in policies.
• Subscriber Local Policy Evaluation State Variables: Created for a subscriber and remains until at least one session for the subscriber exists. When there are multiple sessions associated with a subscriber across services (SM Service, AM Service, UE Policy Service, or PCRF Core), these subscriber state variables are used across sessions based on the subscriber ID. The subscriber state variables are stored in subscriber database on PDS where other subscriber details are available. These variables hold a value as long as the associated subscriber has at least one active session. Once the last session for the subscriber is terminated, these variables will no longer have a value and will no longer be viable for use in policies.

• Subscriber Remote State Variables: Persist remotely in a Subscriber Profile Repository (SPR) as long as the subscriber exists in the SPR. Using these variables requires that an SPR/HSS be configured that is capable of storing these variables.

4.113.1 Local Subscriber State Variable

The Policy blockly for each of the services (SM Service, AM Service, UE Policy Service, and PCRF Core) includes State Variable section under Public Category.

Figure 4-214 State Variables in Policy

• Save: saves a variable
• Load: load a variable
• Remove: Remove a variable
• Remove All: Applicable only for JSON type of variable. This function removes all the variables from the specified context.

You can select the required action for each context.

For example, you can select the context as Policy and select Save to save the specified state variable var and the value assigned to it.

Note:

• The context list includes the Remote option to create Subscriber Remote State Variables only for SM Service and UE Policy Service. This option is not available for AM Service.

• Remove SSV is not revalidated when Query on Update or Query on Delete is enabled in the core service (SM Service or UE Policy Service).

For more information on configuring state variables using blockly, see State Variables section in Oracle Communications Cloud Native Core, Converged Policy Design Guide.

Configurations

The service configurations for both SM and AM in CNC console supports, the boolean parameter Enable Subscriber State Variables to enable the SSV query. And also the following deployment variable are added to AM and UE services to support SSV reset context.

Table 4-138 SSV Reset Context Deployment Variable

Variable Name	Values	Description
USER.RESET_CONTEXT_SSV_ON_AM_CREATE	true/false	If this flag is true, then PDS SSV context information will be updated for AM context owner. If any AM context information associated to SSV has exceeded the guard time then those context will be deleted. Default Value: false
USER.RESET_CONTEXT_SSV_ON_UE_CREATE	true/false	If this flag is true, then PDS SSV context information will be updated for UE context owner. If any UE context information associated to SSV has exceeded the guard time then those context will be deleted. Default Value: false

Call Flow

Figure 4-215 State variables in create session call flow

1. Core service (AM Service /UE Policy Service) receives a session create request.
2. If ssvEnabled is set to true, the core service sends a request to PDS to fetch the Subscriber State Variable (SSV) and the user data.
3. PDS creates a new entry for the SSV in its database. It searches for the user data in PolicyDS database. If it is not present in PolicyDS, it sends a request to the data source such as UDR or CHF through UDR Connector or CHF Connector to get the required details. PDS then responds to the core service with the required information.
4. Core service sends a request to PRE to evaluate the data. PRE creates the Policy state variables as required. PRE does not share these variables with the core service.
5. PRE responds to the core service along with the details of the action to be taken.

6. The core service identifies the session state variables and saves them in the respective session database. Then, it sends the subscriber state variables to PDS to save in the subscriber database.

   Note:

   The core service sends the subscriber state variables to PDS only when there is an update to the variables.

7. After the core service receives a response from PDS and also the core service saves the Session State variables in session database, it replies to SMF/AMF.

Figure 4-216 State variables in update session call flow

1. Core service (AM Service /UE Policy Service) receives a session update request.
2. If ssvEnabled is set to true, the core service sends a request to PDS to fetch the Subscriber state Variable (SSV).
3. PDS responds to the core service with the required information.
4. Core service sends a request to PRE to evaluate the data.
5. PRE responds to the core service along with the details of the action to be taken.

6. The core service identifies the session state variables and saves them in the respective session database. Then, it sends the subscriber state variables to PDS to save in the subscriber database.

   Note: The core service sends the subscriber state variables to PDS only when there is an update to the variables.

7. After the core service receives a response from PDS, and also saves the State Session Variables in its session database, it replies to SMF/AMF.

Note:

In case of error, session retry is not yet supported.

Figure 4-217 State variables in delete session call flow

1. Core service (AM Service /UE Policy Service) receives a session delete request.
2. If ssvEnabled is set to true, the core service sends a request to PDS to fetch the Subscriber state Variable (SSV).
3. PDS responds to the core service with the required information.
4. Core service sends a request to PRE to evaluate the data.
5. PRE responds to the core service along with the details of the action to be taken.

6. The core service identifies the session state variables and saves them in the respective session database. Then, it sends the subscriber state variables to PDS to save in the subscriber database.

   Note: The core service sends the subscriber state variables to PDS only when there is an update to the variables.

7. After the core service receives a response from PDS, and also saves the State Session Variables in its session database
8. Core service sends the subscriber delete request to PDS to delete the subscriber delete for the association.
9. After the core service receives a response from PDS, it deletes the session details from its session database and responds to AMF/SMF.

Figure 4-218 State variables in concurrent flows

1. Core service (AM Service /UE Policy Service) receives multiple create session requests simultaneously.
2. If ssvEnabled is set to true, the core service sends two separate requests to PDS to fetch the Subscriber state Variable (SSV) for both the requests.
3. PDS creates the entries for SSVs and profiles for both the requests and responds to the core service with the required information.
4. When PDS identifies the concurrency either during UDR subscription call flow or during the subsequent create request, PDS deletes the Subscriber State Variable for the first request and merges the rows in PDS database. When PDS receives the update session for the same SSVID as the first create request, the update request includes the SSVID of the first request along with the PDS SSVID.
5. PDS returns the update to the core service indicating that it is a new SSV ID and the previous one is deleted.
6. The core service updates the same SSVID in its database.

Managing Subscriber Variables in Policy

Enable

You can enable the Subscriber Variables for SM Service, AM Service, UE Policy Service, and PCRF Core using CNC Console.

• To enable the Subscriber Variables for SM Service, configure Disable Subscriber Variables parameter under User section in PCF Session Management page. For more details, see PCF Session Management.

• To enable the Subscriber Variables for AM Service, configure Enable Subscriber State Variables parameter under User section in PCF Access and Mobility page. For more details, see PCF Access and Mobility.
• To enable the Subscriber Variables for UE Policy Service, configure Enable Subscriber State Variables parameter under User section in PCF UE Policy page. For more details, see PCF UE Policy Service.
• To enable the Subscriber Variables for PCRF Core Service, configure Enable Subscriber Variables parameter under User section in Settings page in PCRF Core. For more details, see PCRF Core Service Configurations.

Configure

You can configure the updates to PDS SSV entry's context information for AM context owner and UE context owner using the following flags in values.yaml file.

• resetContextSsvOnAMCreate
• resetContextSSVOnUECreate
• enableSsvIdForReqParam

For more information, see Enabling/Disabling Services Configurations section in Oracle Communications Cloud Native Core, Converged Policy Installation, Upgrade and Fault Recovery Guide.

Configure using CNC Console

You can configure the state variables for Policy using CNC Console.

• For details on configuring state variables for SM Service, see PCF Session Management.

• For details on configuring state variables for AM Service, see PCF Access and Mobility.

• For details on configuring state variables for UE Policy Service, see PCF UE Policy Service.

• For details on configuring state variables for PCRF Core Service, see PCRF Core Service Configurations.

Observe

The following PolicyDS metrics provide information about state variables:

• client_request_total
• client_response_total

For more information, see Policy DS Metrics.

4.113.2 Remote Subscriber State Variable

Policy provides UE Policies, via the AMF transparently to the UE. The UE Policy is divided into Policy sections. Such Policy sections are predefined in PCF. PCF either retrieves from UDR, or dynamically generates them. The PCF interfaces with User Data Repository (UDR) to receive subscriber-related Policies for User Equipment (UE). UDR stores the subscriber attributes. PCF communicates with UDR to receive these attributes which are used in the evaluation of Policies.

PCF support for dynamic data for UE Policies:

Subscriber State Variable (SSV) comprises of local and remote section. The remote SSV section is formed by extracting the data from UDR response as per the UEPolicySet datasource path, configured at PDS Settings in the CNC Console. SSV section is sent back to UE service as part of create request processing. UE service forwards the SSV to Policy Runtime Engine(PRE) for:

• Evaluation of Policies, and
• Update the changes in the state variable and send it to UDR.

Revalidation of dynamic data for UE Policies:

UE service supports 'ResetContext' and 'Revalidation' feature. On enabling this feature, an updated SSV remote Policy section is formed with revalidated UE data. This section is updated in the database and sent to UE service.

Write Remote Subscriber State Variable in UDR as a PATCH request:

UE service sends SSV to PRE service for evaluation of Policies. The policy evaluation results in addition or modification or deletion in the SSV. The PRE sends back the updated SSV to UE service. UE service sends the updated SSV to Policy Data Service (PDS). PDS service sends the remote SSV section toward UDR as PATCH request through UDR Connector. The PATCH request that PDS sends to UDR Connector will also include the data source information. UDR Connector uses this data source information to forward the PATCH to appropriate UDR. If the data source information is not included in the PATCH, it will be determined by the UDR-Connector.

Note:

PCF supports dynamic data for UE policies in independent deployment only. It does not work if SM and UE services are running in the same PCF instance with SSV enabled.

4.114 AMF Selection for Namf-comm Subscription

Policy supports discovering AMF as a producer based on AMF SetID and AMF Region ID, which are extracted from Globally Unique AMF Identifier (GUAMI). This aids in transfering the UE Policy to UE through AMF and sending initial subscription request to AMF during UE Policy Transfer request. For more details, see UE Policy Enhancements.

4.115 Support for MCPTT Features

Oracle Communications Cloud Native Core, Policy (Policy) supports Mission Critical Push-to-Talk (MCPTT) and other mission-critical data and video over cellular networks. There are many MCPTT applications that are available through cellular Long Term Evolution (LTE), with mobile broadband meeting many emergency responders’ needs for reliable coverage, secure communication and real-time video sharing.

This feature enables PCRF support for MCPTT related QoS Class Identifier (QCI)s, and MCPTT specific features such as Priority sharing and Preemption.

PCRF enables MCPTT for a session based on the supported features exchanged between the Policy and Charging Enforcement Function (PCEF)/Application Function (AF) and PCRF (dynamic discovery of supported features).

Policy suports the following MCPTT features:

• Allocation Retentions Priority (ARP) Selection: ARPs determine the priority level, the pre-emption capability and the pre-emption vulnerability of each QoS flow according to the operators’ policy. PCRF uses ARPs to determine the relative importance of a resource request and decides whether a new QoS Flow can be accepted or rejected in the case of resource limitations.

• QoS Class Identifier (QCI) selection: QCIs are used to ensure carrier traffic is allocated appropriate Quality of Service (QoS). Different carrier traffic requires different QoS and therefore different QCI values.

  The following are the MCPTT related QCIs:

  • QCI-65 - MCPTT Audio service flow.
  • QCI-66 - Non-MCPTT Audio service flow.
  • QCI-67 (for MC Video)
  • QCI-69 - MCPTT signaling flow.
  • QCI-70 - MCPTT Data service flow.
  • QCI-7 - Voice, video (live streaming )
  • QCI_128-254 - Operator specific

• Priority Sharing: For all the Policy and Charging Control Rules (PCC rules) with the same QCI assigned and having an associated priority sharing indicator, PCRF assigns the same Allocation and Retention Priority (ARP) settings. Having the same setting for the ARP enables the usage of the same bearer.

  PCRF decides the ARP for the PCC rules (same QCI and Priority Sharing indicated by AF) as follows:

  • ARP Priority is set as highest of the priority among all the PCC rules
  • ARP pre-emption capability is set if any of the original PCC rules have the ARP pre-emption capability set
  • ARP pre-emption vulnerability is set if all the original PCC rules have the ARP pre-emption vulnerability set

• Preemption control: If PCEF informs the PCRF that a PCC rule provisioning or modification failed (due to resource reservation failure), PCRF can apply pre-emption and remove the active PCC rules from PCEF and retry the PCC rule provisioning or modification procedure.

  If PCRF does not apply pre-emption, AF is notified that the resource reservation for the new media flow failed.

Feature enablement is controlled by the supported feature negotiation done between the PCRF and the PCEF/AF. By default, all MCPTT related feature bits are enabled and applied to session (when supported by PCEF and AF).

Table 4-139 MCPTT related features in Gx

Feature Name	Feature bit	M/O	Feature list Id	Vendor Id
MissionCriticalQCIs	25	O	1	10415
MCVideoQCI	9	O	2	10415
MCVideo	22	O	1	10415

Table 4-140 MCPTT related features in Rx

Feature Name	Feature bit	M/O	Feature list Id	Vendor Id
MCPTT	17	O	1	10415
PrioritySharing	18	O	1	10415
MCPTT-Preemption	21	O	1	10415

You must mention the supported features separated by comma as values in these keys.

This is not limited to MCPTT feature bits. You can disable any of the existing optional features using this option.

Mandatory features such as Rel8, Rel9 and Rel10 are enabled by default for negotiation.

Selecting QCIs

You can select the required QCIs using the existing Policy actions.

You must assign these QCIs to the PCC rules using Policy and PCC rule configurations. When there is no decision received from Policy suggesting QCI for MCPTT session, QCIs are chosen based on the media type.

For example:

Table 4-141 QCI based on Media Type

Media Type	QCI
Audio	QCI_65
Data	QCI_70
*Anything else	QCI_69

Selecting ARPs

You can configure the ARP parameters such as priority, Preemption capability and preemption vulnerability for default EPS bearer and PCC rules generated for the AF flows.

When there is no ARP set from Policy, the ARP settings for MCPTT session is created under PCRF core service configuration.

Note:

ARP assigned based on Policy is considered as final. This can be overridden by priority sharing feature (when enabled). But the original ARP decision is stored for future use.

Priority Sharing

When priority sharing feature is enabled, the ARP assigned by policy or configuration canbe overridden (when conditions are met). The original ARP assigned for the PCC Rule is stored along with the overridden ARP as part of the session data stored in the database. The original ARP information is required when there is a need to apply the priority sharing again on these PCC rules in the future.

Table 4-142 Sample priority sharing scenario

PCC Rule 1 original ARP			PCC Rule 2 original ARP	Shared ARP
Priority	Preemption Capability	Preemption Vulnerability	Priority	Preemption Capability	Preemption Vulnerability	Priority	Preemption Capability	Preemption Vulnerability
1	Disabled	Disabled	2	Enabled	Enabled	1 PCC Rule 1 - unchanged PCC Rule 2 - changed	Enabled PCC Rule 1 - changed PCC Rule 2 - unchanged	Disabled PCC Rule 1 - unchanged PCC Rule 2 - changed

In this case, both the PCC rules belong to the same IPCAN session, same QCI and having priority sharing indicator.

Following are the scenarios when Priority sharing rederive ARP is triggered:

• At least one of the PCC Rules (sharing same ARP) is removed
• A new PCC Rule (with same QCI, Priority sharing indicator) is created
• The original derived ARP of at least one of the PCC rule changes

Whenever the ARP of an already installed PCC rule changes, that rule will also be added as part of the Charging-Rule-Install Avp. For the rules to be modified, the charging-Rule-Definition will have the new ARP values.

Since priority sharing is applied at different scenarios, the original ARP and the priority sharing indication (received from AF) becomes necessary, These are mentioned as values of PCRFDiameterEnfAppFlow paremeter stored in the Gx Session (in the database).

Preemption

Whenever a PCC rule (with priority sharing enabled) installation or modification fails due to resource reservation issue, any other preemptable PCC Rule(s) is removed and the failed PCC Rule will be retried.

Preemption is triggered only when the following conditions are met

• When PCC rules (with priority sharing) provisioning or modification fails (Charging-Rule-Report with rule failure code RESOURCE_ALLOCATION_FAILURE)
• Failed PCC Rule(s) preemption capability (original - before Priority sharing) is ENABLED
• At least one PCC rule with priority equal or lower (than the failed PCC rule) and having preemption vulnerability ENABLED
• MCPTT-Preemption is enabled (supported features)

Preemption is not triggered if any of the above mentioned conditions are not met. Instead, a Re-Authorization Request (RAR) is triggered towards AF (if requested by AF) with the Specific-Action AVP set to INDICATION_OF_FAILED_RESOURCES_ALLOCATION to report the resource allocation failure.

When there are more than one potential PCC rule candidate for preemption, the PCC rule to be preempted is selected based on the Pre-emption-Control-Info AVP received from Authorization Authentication Request (AAR) or the local configuration (in PCRF-core service configuration).

The control information has the following three options.

• Most recent added flow - Newest flow among the potential preemptable rules to be preempted
• Least recent added flow - Oldest flow among the potential preemptable rules to be preempted
• Highest bandwidth flow - Having highest bandwidth among the potential preemptable rules

The rule to be preempted is selected based on the information received from AF or local configuration.

The rule creation time stored in the PCC rule information (part of session object) is used to compare the oldest and the newest rule,

After the Preemption, Priority sharing is triggered again to rederive the ARP for the affected PCC Rules (sharing the same QCI of the preempted PCC Rule).

Note:

Currently, Policy does not support preemption using Policy. Preemption is performed as per the procedure defined by 3GPP only.

For the preempted PCC rules a Rx-RAR will be sent to AF to notify about pre-emption of the flow (with specific action set to INDICATION_OF_RELEASE_OF_BEARER)

Call Flow

Figure 4-219 MCPTT APN Handling

1. The PCEF sends a Credit Control Request-Initial (CCR-I) message to the PCRF with MCPTT APN details.
2. PCRF checks the Access Point Name (APN) and assigns the MCPTT QCI and ARP for the default Evolved Packet System (EPS) Bearer.
3. PCRF sends a Credit Control Answer-initial (CCA-I) message to PCEF and provisions the MCPTT QCI and the ARP settings.

Figure 4-220 MCPTT QCI & ARP settings for MCPTT AF flows

1. The PCEF sends a Cedit Control \Rrequest initial (CCR-I) message to the PCRF with MCPTT APN details.
2. PCRF checks the APN and assigns the MCPTT QCI and ARP for the default EPS Bearer.
3. PCRF sends a credit Control Answer initial (CCA-I) message to PCEF and provisions the MCPTT QCI and the ARP settings.
4. PCRF receives an AAR message from AF with the session information, which includes MCPTT-ID, Reservation Priority, and the AF-Application-identifier associated with the session.
5. PCRF decides the QCI and the ARP based on the parameters received from AF.
6. The PCRF sends a Diameter Authentication, Authorization, and Accounting (AAA) to the AF with ResultCode=DIAMETER_SUCCESS.
7. PCRF sends a Reauthorization Request (RAR) message to PCEF to provision the QCI and the ARP. The PCC Rules generated for the AF flows contains the QCI and ARP set by Policy/default configuration.
8. PCEF responds to PCRF with a Reauthorization answer (RAA) message with ResultCode=DIAMETER_SUCCESS).

Figure 4-221 Priority Sharing

1. The PCEF sends a credit control request initial (CCR-I) message to the PCRF with MCPTT APN details.
2. PCRF sends a credit control answer initial (CCA-I) success message to PCEF.
3. PCRF receives an AA-Request Initial (AAR-I) messages from AF for Rx Session 1 with priority sharing enabled.
4. PCRF decides the QCI and the ARP based on the parameters received from AF.
5. The PCRF sends a Diameter AAA to the AF with ResultCode=DIAMETER_SUCCESS.
6. PCRF applies Priority sharing.
7. PCRF sends a Reauthorization Request (RAR) message to PCEF to provision the QCI and the ARP. The PCC Rules for session 1 generated for the AF flows contains the QCI and ARP set by Policy/default configuration.
8. PCEF responds to PCRF with a Reauthorization answer (RAA) message with ResultCode=DIAMETER_SUCCESS).
9. PCRF receives an AA-Request (AAR) messages from AF for Rx Session 2 with priority sharing enabled.
10. PCRF decides the QCI and the ARP based on the parameters received from AF.
11. The PCRF sends a Diameter AAA to the AF with ResultCode=DIAMETER_SUCCESS.
12. PCRF applies priority sharing.
13. PCRF sends a Reauthorization Request (RAR) message to PCEF to provision the QCI and the ARP. The PCC Rules for session 2 as well as session 1 generated for the AF flows contains the QCI and ARP set by Policy/default configuration.
14. PCEF responds to PCRF with a Reauthorization answer (RAA) message with ResultCode=DIAMETER_SUCCESS).
15. PCRF receives a Session-Termination-Request (STR) from AF.
16. AF responds to PCRF with a Session-Termination-Answer (STA).
17. PCRF applies priority sharing.
18. PCRF sends an RAR to remove and update the PCC rules. The RAR message contains the PCC rules removed for Session 2 flows as well as session 1 (if modified by priority sharing).
19. PCEF responds to PCRF with a Reauthorization answer (RAA) message with ResultCode=DIAMETER_SUCCESS).

Figure 4-222 Preemption Control - CCRU- CharginRuleReport scenario

1. The PCEF sends a credit control request initial (CCR-I) message to the PCRF with MCPTT APN details.
2. PCRF sends a credit control answer initial (CCA-I) success message to PCEF.
3. PCRF receives an AA-Request initial (AAR-I) messages from AF for Rx Session 1 with priority sharing and preemption enabled.
4. PCRF decides the QCI and the ARP based on the parameters received from AF.
5. The PCRF sends a Authentication, Authorization, Accounting (AAA) message to the AF with ResultCode=DIAMETER_SUCCESS.
6. PCRF applies Priority sharing.
7. PCRF sends a Reauthorization Request (RAR) message to PCEF to provision the QCI and the ARP. The PCC Rules for session 1 generated for the AF flows contains the QCI and ARP set by Policy/default configuration.
8. PCEF responds to PCRF with a Reauthorization answer (RAA) message with ResultCode=DIAMETER_SUCCESS).
9. PCRF receives an AA-Request (AAR) messages from AF for Rx Session 2 with priority sharing and preemption enabled.
10. PCRF decides the QCI and the ARP based on the parameters received from AF.
11. The PCRF sends a Diameter AAA to the AF with ResultCode=DIAMETER_SUCCESS.
12. PCRF applies priority sharing.
13. PCRF sends a Reauthorization Request (RAR) message to PCEF to provision the QCI and the ARP. The PCC Rules for session 2 as well as session 1 generated for the AF flows contains the QCI and ARP set by Policy/default configuration.
14. PCEF responds to PCRF with a Reauthorization answer (RAA) message with Charging rule report - failed resource allocation.
15. Also, PCEF sends a Credit Control Request - Update (CCR-U) with charging rule report indicating failed resource allocation.
16. PCRF evaluates the details, and applies priority control and tries the preemption once again to remove eligible rules and retry failed PCC rules.
17. PCRF applies priority sharing again due to removed PCC rules.
18. PCRF sends a Credit Control Answer-Update (CCA-U) to PCEF to remove and update the PCC Rules.
19. PCRF sends an RAR or ASR to AF informing the failed resource allocation for the preempted flow.
20. AF responds to PCRF with a Reauthorization answer (RAA) message.

Figure 4-223 Preemption - No Preemptable Rule found

1. The PCEF sends a credit control request initial (CCR-I) message to the PCRF with MCPTT APN details.
2. PCRF sends a credit control answer initial (CCA-I) success message to PCEF.
3. PCRF receives an AA-Request initial (AAR-I) messages from AF for Rx Session 1 with priority sharing enabled.
4. PCRF decides the QCI and the ARP based on the parameters received from AF.
5. The PCRF sends a Authentication, Authorization, Accounting (AAA) message to the AF with ResultCode=DIAMETER_SUCCESS.
6. PCRF applies Priority sharing.
7. PCRF sends a Reauthorization Request (RAR) message to PCEF to provision the QCI and the ARP. The PCC Rules for session 1 generated for the AF flows contains the QCI and ARP set by Policy/default configuration.
8. PCEF responds to PCRF with a Reauthorization answer (RAA) message with ResultCode=DIAMETER_SUCCESS).
9. PCRF receives an AA-Request (AAR) messages from AF for Rx Session 2 with priority sharing enabled.
10. PCRF decides the QCI and the ARP based on the parameters received from AF.
11. The PCRF sends a Diameter AAA to the AF with ResultCode=DIAMETER_SUCCESS.
12. PCRF applies priority sharing.
13. PCRF sends a Reauthorization Request (RAR) message to PCEF to provision the QCI and the ARP. The PCC Rules for session 2 as well as session 1 generated for the AF flows contains the QCI and ARP set by Policy/default configuration.
14. PCEF responds to PCRF with a Reauthorization answer (RAA) success message.
15. Also, PCEF sends a Credit Control Request - Update (CCR-U) with charging rule report indicating failed resource allocation.
16. PCRF evaluates the details, and applies priority control and tries the preemption once again to remove eligible rules and retry failed PCC rules.
17. PCRF sends a RAR message to AF informing the failed resource allocation for the preempted flow.
18. PCRF sends a Credit Control Answer-Update (CCA-U) to PCEF indicating no change in the PCC Rules.
19. AF responds to PCRF with a Reauthorization answer (RAA) message.

Managing Support for MCPTT features

Enable

By default, the MCPTT features are enabled.

You can disable the required MCPTT related feature bits using the following two keys under Advance Settings in Settings page for PCRF Core on Oracle Communications Cloud Native Core, Cloud Native Configuration Console (CNC Console):

• Gx.DisableSupportedFeatures (for Gx)
• Rx.DisableSupportedFeatures (for Rx)

For more details on enabling/disabling the MCPTT features using CNC Console, see Settings.

Configure

You can configure the support for MCPTT features using CNC Console and REST API.

Configure using CNC Console

• You can configure the default ARP and default preemption control by applying the configurations under MCPTT section in Settings page for PCRF Core on Oracle Communications Cloud Native Core, Cloud Native Configuration Console (CNC Console). For more details, see Settings.

• To assign the QCIs, apply the configurations for Use Custom QoS Class Identifier and QoS Class Identifier parameters while creating the PCC rule on Create PCC Rule page. For more information, see PCC Rule.
• To configure PCC profile, apply the configurations for Use Custom QoS Class Identifier and QoS Class Identifier parameters while creating the PCC rule profile on Create PCC Rule Profile page. For more information, see PCC Rule.

• You can use the blockly conditions and actions to set QCI and ARP default EPS bearer. For more information, see Priority/Emergency section in Oracle Communications Cloud Native Core, Converged Policy Design Guide.

Configure using REST API

You can configure PCC Rule, PCC Profile, PCRF-core using the following REST APIs:

• Core Service
• Traffic for PCC Rule
• Traffic for PCC Rule Profile

For more information on configuring using REST API, see Policy REST Specifications section in Oracle Communications Cloud Native Core, Converged Policy REST Specification Guide.

4.116 Support for Listing and Comparing UPSIs Received from UDR

Converged Policy provides blocks, conditions and actions to support finding the delta between the UPSI's id list:

• currently configured in PCF
• UPSI's that are send on UE Policy Registration
• UPSIs that are on UDR

It allows the user to install/remove this delta or a subset of delta.

Also, it allows to access the attributes of the UPSI object (UPSC, MCC and MNC) and can be able to check the URSPs that are configured to be installed under a specific UPSI.

For details on the UE Policy blocks, actions, and conditions used for this functionality, see UE Policy Bloaks section in Oracle Communications Cloud Native Core, Converged Policy Design Guide.

4.117 Roaming Support in Policy

PCRF supports S8 Home Routing scenario for LTE and VoLTE networks in 4G deployment.

S8 Home Routing allows the home operator to control the services and policies applied to the roaming subscriber. S8 interface connects the visited network’s Serving Gateway (SGW) to the home network’s PGW.

Since the data is routed through the home network's PGW, the home network's PCRF applies the subscriber’s policy and charging rules such as QoS and PCC Rules.

The PCRF at home network interfaces the home network PGW and applies the policies on Gx interface, such as identifying a roaming subscriber from 3GPP-SGSN-MCC-MNC AVP and applying differentiated QoS parameters for the roaming subscribers.

For details on how to write a policy based on MCC and MNC, see Creating Policies section in Cloud Native Core, Converged Policy Design Guide.

Note:

Currently, Policy do not support:

• Roaming in 5G deployment (using PCF).
• Local Breakout (LBO)

4.118 Wi-Fi Support using RAT-Type AVPs

To support Wi-Fi (WLAN) and voice over Wi-Fi, RAT-type Attribute-Value Pair (AVP)s are included in Credit-Control-Request (CCR) messages to inform the CnPCRF about the access technology through which the UE is connected. RAT-Type is usually included as an enumerated AVP, where each type of RAT is represented by a predefined integer value.

The following are some of the values allowed for RAT-Type AVPs:

• EUTRAN (LTE)
• WLAN (Wi-Fi)
• UTRAN (3G)

Based on the RAT-Type, the CnPCRF can apply different Policy rules.

For example, different quality of service (QoS) and charging rules can be applied for a user connected using Wi-Fi (WLAN) compared to a user connected through LTE (EUTRAN).

When a UE moves from one RAT to another (for example, from LTE to Wi-Fi), the network triggers a CCR-U message with the updated RAT-Type AVP. This allows the PCRF to dynamically adjust policies in real-time.

RAT type in conjunction with other parameters in the CCR, such as user location information, subscriber profile from data sources enables operators to create dynamic, and user-centric policies in CnPCRF.

Enable

This feature is enabled automatically at the time of Policy installation.

4.119 Support for Database Slicing

Whenever Policy services (SM service, PCRF Core, or Usage Monitoring service) receives a Create, Retrieve, Update, or Delete request from any of the microservices, the request is processed by the main database (SMPolicyAssociation database, UMContext, GxSession).

With the use of MySQL NDB software, there is a limitation on having a single replication channel for a given database. When the commit rate for a database is very high, the replication of the database impacts the replication performance depending upon the number of commits as well as the commit (record) size.

In order to overcome the replication limitations of the database, especially in a multisite environment, the database can be sliced based on a particular slicing criteria. The database tables are divided into different slices based on the Helm configuration (such as SM_POLICY_ASSOCIATION_TABLE_SLICING_COUNT for SMPolicyAssociaion, UM_CONTEXT_TABLE_SLICING_COUNT for UMContext and GX_SESSION_TABLE_SLICING_COUNT for GxSession). After the slices are created, the database records are distributed across all the slices.

With this database slicing, instead of the main database processing all the requests, some of the database operations are processed using sliced tables.

The number of slices can be configured depending upon the replication requirements.

For example, if a single slice is able to replicate up to ~40K TPS and the immediate TPS need is ~75K, two slices can support the immediate required load. If the estimated projected growth YoY is 25%, the TPS need after 5 years reaches around ~200K TPS. Thus a table slice count of 8 can be used to manage the database load for the next 5 years.

Note:

This calculation takes into consideration only replication channel and not any other challenges that may come up for 200K TPS.

By default, there is no separate replication channel for each of these slices. Replication channels can be configured. For example, two replication channels can be configured, each replicating 4 slices. This configuration can change depending on the increase in TPS and available bandwidth across the replicating sites.

Managing the Support for Database Slicing

Slicing SMPolicyAssociation for SM service

While upgrading from an older version of Policy to a later version, you can configure the Database Slicing feature for SM service database (SMPolicyAssociation table) as follows:

1. In CNC Console, under Service Configurations on PCF Session Management page, set the value of ENABLE_SM_POLICY_ASSOCIATION_TABLE_SLICING advanced settings key to true. This will enable the database slicing on SMPolicyAssociation. By default, the value of this key is set to false. Once the database slicing is enabled, the database operations are processed on the sliced tables.

   When ENABLE_SM_POLICY_ASSOCIATION_TABLE_SLICING is enabled, the Audit Service audits the SmPolicyAssociation sliced tables as well.

2. Configure the number of slices using SM_POLICY_ASSOCIATION_TABLE_SLICING_COUNT Helm parameter.

   By default, the slicing count is set to 1.

   During the upgrade, add the Helm configuration in custom.yaml file to configure SM_POLICY_ASSOCIATION_TABLE_SLICING_COUNT parameter.

   The slicing table feature is backward compatible, so that the older Create, Retrieve, Update, and Delete operations work as expected. Data is populated in new tables after a successful upgrade and when ENABLE_SM_POLICY_ASSOCIATION_TABLE_SLICING is set true using CNC Console.

   Note:

   After enabling the feature, make sure that it is not disabled again because data can not be fetched from sliced tables.

Slicing for UMContext database for Usage Monitoring service

While upgrading from an older version of Policy to a later version, you can use the following Helm parameters to configure the table slicing feature for Usage Monitoring database (umContext table):

• ENABLE_TABLE_SLICING: to enable the database slicing feature. By default, this parameter is disabled.
• UM_CONTEXT_TABLE_SLICING_COUNT: to configure the number of slices created. By default, the slicing count is set to 1.

The ENABLE_UM_CONTEXT_TABLE_SLICING key under Advanced Settings in Usage Monitoring page for Service Configurations in CNC Console is used to enable/disable the database operations on sliced tables. That is, whenever ENABLE_UM_CONTEXT_TABLE_SLICING key is set to true, the create/retrieve/update/delete operations are performed on the database slices instead of the main database.

By default, ENABLE_UM_CONTEXT_TABLE_SLICING key is disabled.

For example, when PCRF Core sends a create request to Usage Monitoring service and ENABLE_UM_CONTEXT_TABLE_SLICING flag is enabled, the Usage Monitoring service responds to PCRF Core with x-oc-slicing-info, which contains the slicing information of Usage Monitoring database (UmContext table). PCRF Core stores this information in its Gx session database. In subsequent update or terminate requests, PCRF Core uses this in the header.

In case of any change in UM_CONTEXT_TABLE_SLICING_COUNT parameter, existing sessions in the UmContext table will not be impacted. Data can still be retrieved from the older slices.

Note:

After enabling the ENABLE_UM_CONTEXT_TABLE_SLICING flag, make sure not to disable it again. Otherwise, data cannot be fetched from sliced tables.

Also, in case of rollback, data saved on sliced tables cannot accessed. Data saved on the sliced tables must be manually ported to the main database.

In case of a change in UM_CONTEXT_TABLE_SLICING_COUNT parameter:

The PREVIOUS_UM_CONTEXT_TABLE_SLICING_COUNT key under Advanced Settings in Usage Monitoring page for Service Configurations in CNC Console is used to store the previous slicing count.

If UM_CONTEXT_TABLE_SLICING_COUNT is changed and the service cannot find the data with the current slicing count, it uses PREVIOUS_UM_CONTEXT_TABLE_SLICING_COUNT to search for the data.

If there are multiple values for PREVIOUS_UM_CONTEXT_TABLE_SLICING_COUNT, the Usage Monitoring service uses the latest previous count and if the data is still not found, it uses the next previous count. That is, if PREVIOUS_UM_CONTEXT_TABLE_SLICING_COUNT contains two values such as 0 and 5, the Usage Monitoring service first uses the previous count as 5 to search for the data. If it is still not found, the service uses the previous count as 0 to search for the data.

To reduce latency, you can alter the number of slices one at a time. After migrating from the previous table count to the newly completed one, switch to the new count.

After all the data from the previous slicing count is moved to the new slicing count, make sure to remove the previous count from PREVIOUS_UM_CONTEXT_TABLE_SLICING_COUNT.

If PREVIOUS_UM_CONTEXT_TABLE_SLICING_COUNT does not contain 0, and ENABLE TABLE SLICING parameter is set to true, the data cannot be searched on the primary table.

Slicing in GxSession database for PCRF Core service

While upgrading from an older version of Policy to a later version, you can configure the Database Slicing feature for GxSession database as follows:

1. Enable the table slicing for GxSession database using GX_SESSION_TABLE_SLICING_ENABLED Helm parameter. This enables the database slicing on GxSession database. By default, the value of this key is set to false. Once the database slicing is enabled, the database operations are processed on the sliced tables.
2. When DISTRIBUTE_GX_TRAFFIC_USING_TABLE_SLICING advanced settings key is enabled, the Audit Service audits the GxSession sliced tables as well.
3. Configure the number of slices using GX_SESSION_TABLE_SLICING_COUNT Helm parameter. By default, the value of this parameter is set to 1.
4. In CNC Console, under PCRF Core Settings page in Service Configurations, set the value of DISTRIBUTE_GX_TRAFFIC_USING_TABLE_SLICING advanced settings key to true. By default, the value of this key is set to false. When this key is enabled and if the new slices for Gx are created, traffic for GxSessions are distributed across all the new tables. PCRF Core service will register the new tables with Audit service and also distributes the new sessions to the new slices.

   Note:

   DISTRIBUTE_GX_TRAFFIC_USING_TABLE_SLICING advanced setting key must be enabled after upgrade or install with table slicing processes are done.

Identifying the slice for database operation:

• When PCRF Core service receives a CCR-I message, the primary key is hashed to find the slice. To save the GxSession in the database, use the primary key in the slicing function. The slicing function provides the slice number where the association can be saved.
• When PCRF Core service receives a CCR-U message, the slice number is obtained using the slicing function. Note that the Session-Id must never be changed. To update the database, the Session-Id is used with the slicing function to obtain the slice number where the association is saved.
• When PCRF Core service receives a CCR-T message, the slice number is calculated using the slicing function. The Session-Id is passed to the slicing function to obtain the slice number where the association to be deleted can be found.

Note:

PCRF Core does not support mismatch of versions in multi-site configurations. Due to the limitations from changing the table name from GxSession to GxSession_n, multi-site configurations with different versions of PCRF installed is not supported.

Note:

• You can start with a fixed number of slices that is estimated to cater to the replication needs of the near future (for example, next 5 years).
• All table slices may not have their own replication channels to start with. For example, to enable 75K TPS, only 2 replications channels can be configured, each replicating 4 slices. This configuration can change depending on the increase in TPS and available bandwidth across the replicating sites.
• Records are distributed across all the slices. This helps in reconfiguring the slice to replication channel mapping. No migration is required as long as the table slice count does not change.
• The hashing function selected is Consistent Hash.
• The hashed slice number is provided to the consumer service accessing the database as part of the resource-id to avoid the requirement of migration if and when the table slices need to be increased.
• For secondary key lookup, a parallel search is performed across all the table slices.

Note:

Currently, Policy does not support mismatch of versions in multi-site configurations.

Also, when Policy is upgraded from one version to the same version, the upgrade procedure will not trigger creation of database slices. Creation of slices must be enabled and configured using Helm. For more information, see Preupgrade Tasks section in Oracle Communications Cloud Native Core, Converged Policy Installation, Upgrade, and Fault Recovery Guide.

The following are some of the scenarios of database slicing during a Policy software upgrade in a geo-redundant setup:

• If all the sites are using an older version of Policy and the first site is upgraded to a release that supports table slicing, but slicing is disabled. In this case, there is no need to change anything in the slicing configuration. To activate the distribution on the new slices DISTRIBUTE_GX_TRAFFIC_USING_TABLE_SLICING Advanced Setting key must be enabled.
• If all the sites are upgraded to a newer version of Policy that supports table slicing, but slicing is enabled only on site1, only on the site 1, the sessions will be distributed across the slices.
• When a new site is added to existing cluster where slicing is disabled, whereas slicing is enabled in other sites, only the cluster with table slicing enabled will have the distribution of sessions across all the slices. The other clusters will have only one table for the database.
• When a new site is added to existing cluster with slicing enabled, whereas slicing is still disabled on existing sites, only on the new site the sessions are distributed across all the slices.

Observability

Metrics

Slicing SMPolicyAssociation for SM service

occnp_db_overall_processing_time. getBySecondaryKeyV4 metric is used to calculate total response time for secondary key serial search when table slicing on SMPolicyAssociation database is enabled.

Slicing UMContext for Usage Monitoring service

usage_mon_context_found metric is used to count the session lookup on the main table or the sliced tables for old sessions of the subscribers when table slicing is enabled.

4.120 Support for Interworking Between Evolved Packet Core (EPC) and CNC

This section describes how Converged Policy supports interworking between Evolved Packet Core (EPC) and 5G Cloud Native Core (CNC).

EPC provides converged voice and data services on a 4G LTE network to enable advanced services, such as VoIP.

EPC comprises:

• Serving Gateway (SGW)
• PDN Gateway (PGW)
• Mobility Management Entity (MME)
• Home Subscriber Server (HSS)

Converged Policy deployment to support both EPC/5G Core network element

Figure 4-224 Converged Policy Architecture to Support EPC and 5GC

3GPP recommends the following deployment Options with both LTE,NR and EPC,5GC co-exist. The Interfaces on which the UE attach lands for each of these options is shown.

Table 4-143 Deployment Options

3GPP Deployment Options	CnPolicy (PCRF+PCF)
Option 1: Standalone LTE under EPC	UE attaches to CnPolicy over Diameter Gx Interface.
Option 2: Standalone NR under 5GC	UE attaches to CnPolicy over Nsmf/N7 Interface.
Option 3: NonStandalone LTE and NR under EPC	UE attaches to CnPolicy over Diameter Gx Interface.
Option 4: NonStandalone NR and LTE under 5GC	UE attaches to CnPolicy over Diameter Gx Interface.
Option 7: Non Standalone LTE and NR under 5GC	UE attaches to CnPolicy over Nsmf/N7 Interface.

Typical Migration strategy from 4G LTE to 5GC SA is as follows:

4G LTE -> NSA Option 3 -> NSA Option 7: NSA Option 4 -> SA Option 2