4 Policy Features

This 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 Support for DNN Exclusion

The communication between SM service, Binding service, Bulwark service, and PDS can be skipped based on the DNN using the following advanced settings configurations in SM service.
  • USER.allDataTypes.excludeDnns
  • BINDING.excludeDnns
  • BULWARK.excludeDnns

These advanced settings receive a comma separated list of DNNs. For any request that matches one of the DNNs in the corresponding list, the communication to that specific service will be blocked or excluded.

Regular expressions (regex) are applied as supported by regex from java Pattern class with the following special cases:
  • All whitespaces should be removed before processing any values in the arrays.
  • Every dnn should contain regex characters '^' at the start and '$' at the end. The dnn can not be an empty string.
  • dnn exclude settings are case insensitive
  • For security reasons '\' (backslash) is not supported, to interpret regex conditions like '\d' it will need to be written as '/d',. Internally all '/' will be translated to '' for java to handle backslash regex conditions.
  • { n, m } repetitions are not supported as ',' will be used to separate each dnn.

Note:

BINDING.excludeDnns configuration from advanced settings in SM service will always take precedence. In other words, if the DNN is configured in BINDING.excludeDnns, binding service will not be contacted for creating local binding or BSF registration. It will not be affected by the PRE response.

Binding service is responsible for limiting number of sessions. Hence, as the communication with binding service is skipped for the DNNs configured in excludeDNNs, the limiting number of sessions for that DNN will not work.

For more information on the advanced settings, see PCF Session Management.

4.2 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-1 SMF Notification for SM Policy (NFSetid based discovery for retry on Notification Request failure)


Non-SUPI based on-demand discovery caching for SM Service

  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-2 AMF Notification for AM Policy (NFSetid based discovery for retry on Notification Request failure)


Non-SUPI based on-demand discovery caching for AM Service

  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-3 AMF Notification for UE Policy (NFSetid based discovery for retry on Notification Request failure)


Non-SUPI based on-demand discovery caching for UE Policy Service

  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-4 AMF Discovery/ Re-Discovery


Non-SUPI based on-demand discovery caching for AMF rediscovery

  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-5 Non-SUPI based on-demand discovery caching for User Service


Non-SUPI based on-demand discovery caching of UDR Profiles

  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:
  • nrfclient.discovery.cache.support.force.discovery
  • nrfclient.discovery.cache.support.cache.hit
  • nrfclient.discovery.cache.support.about.to.expire
  • nrfclient.discovery.cache.support.expired
  • nrfclient.discovery.cache.support.failover
  • nrfclient.discovery.cache.support.non.cache
  • nrfclient.discovery.cache.support.empty.response
  • nrfclient.discovery.cache.support.cache.lookup
  • nrfclient.discovery.cache.support.backend.response
  • nrfclient.discovery.cache.support.backend.response
  • discovery.cache.support.profiles.per.response

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.3 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-6 SLA Returns Success


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-7 SLA Returns 5002, Get New Sy Session, PDS Update Sy Session


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-8 First Gx Session


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-9 Second Gx Session


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-10 Second Gx Session: SLA Returns 5002, Get New Sy Session, PDS Update Sy Session


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.4 Support of 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 policy triggers are sent to PCF 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, the Policy Runtime Engine (PRE) evaluates the Policies and makes the requested policy decision. The PCF may decide to send an update or terminate request toward AMF/SMF. If PCF decides to terminate, it invokes Npcf_AMPolicyControl_UpdateNotify service operation toward AMF or Npcf_SMPolicyControl_UpdateNotify toward SMF requesting for termination of the policy association.

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-11 PCF Triggering AM UpdateNotify Terminate


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.

If PCF requests the termination of AM 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-12 Deletion of Policy Association


Deletion of a policy association

PCF termination request is made with TerminationNotification data type.

Table 4-1 Definition of Type TerminationNotification

Attribute Name Data Type Description
resourceUri Uri The resource URI of each AM/UE/SM policy association related to the notification.
cause PolicyAssociationReleaseCause The cause for PCF requesting for Policy association termination.

Table 4-2 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.

This enumeration value is exclusive to SmPolicyAssociationReleaseCause only.

REACTIVATION_REQUESTED 		This value indicates that policy association needs to be terminated, since PCF is not able to maintain the existing PDU session. PCF requests for PDU session reactivation.

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.

AMF 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 invokes Npcf_AMPolicyControl_Delete service operation to terminate the policy association. 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, the Policy association is not deleted in Policy and thus its associated resources with the external NFs are not deleted.

AM Service Call Flow

Figure 4-13 Call Flow for AM Terminate for UDR updateNotify with delResources


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-14 Call Flow for AM Terminate for CHF updateNotify or TerminateNotify


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 Service Call Flow

Figure 4-15 Call Flow for UE Terminate for UDR updateNotify with delResources


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-16 Call Flow for UE Terminate for CHF updateNotify or updateNotifyTerminate


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.

SM Service Call Flow

Figure 4-17 Call Flow for SM Terminate for UDR updateNotify with delResources


Call Flow for SM Terminate for UDR updateNotify with delResources

  1. The UDR triggers the PolicyDataChangeNotification with the attribute "delResources" to the PCF.
  2. The UDR Connector forwards the received PolicyDataChangeNotification to the PDS.
  3. After receiving the UDR notification PDS updates the database
  4. PDS triggers the user data change notification request to SM service.
  5. The SM service updates the Policy association.
  6. The SM service sends policy request to PRE.
  7. If PRE decides to terminate SM policy association, SM service triggers session termination notification to the SMF.
  8. The SMF triggers session termination request to the PCF

Figure 4-18 Call Flow for AM Terminate for CHF updateNotify or TerminateNotify


Call Flow for AM Terminate for CHF updateNotify or TerminateNotify

  1. SMF sends a SM session established message to SM Policy service.
  2. When the Policy Counters for a subscriber is deleted in CHF, CHF sends an updateNotify or updateNotify Terminate request to SM Policy service.
  3. SM 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 SM Policy service.
  5. SM Policy service sends a notifyTerminate request to SMF.
  6. SMF sends a 204 No Content response to SM Policy service indicating that the request was successful.
  7. SM Policy service forwards the 204 No Content message to CHF.
  8. SMF triggers a delete session request and sends a SMPolicy delete request to SM Policy service.
  9. SM Policy service deletes the SMPolicyAssociation from the database, sends an unsubscribe request to UDR, if subscribed and deregisteration request to BSF.
  10. UDR removes the subscription and responds to SM Policy service with 204 No Content message.
  11. BSF deregisters the subscriber and responds to SM Policy service with 204 No Content message.

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 updates of an 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.

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 UE service 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.5 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.

Determining Pod Congestion State

Bulwark pod exists in any of the following three states at any given time:
  1. Normal
  2. DOC (Danger of Congestion)
  3. Congested

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

Figure 4-19 Different Pod Congestion States

Congestion states
The pod state gets determined by considering the following points.
  1. Calculate the congestion state for the following resources:
    1. Queue: For the DOC and CONGESTED pod states, compare the number of pending messages in the queue with the configured pending messages threshold.

      Figure 4-20 Congestion States


      Congestion State

    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. The following formula calculates the CPU usage:CPU usage
    3. Memory - In order to phase out memory-based congestion control in the future, the threshold for memory consumption for the congestion state is set at 100%.
  2. The congestion state for pod gets assigned a maximum congested state based on the congestion state of the resources. For Example, the calculated congestion state of the pod becomes CONGESTED when its CPU becomes NORMAL and Queue becomes CONGESTED.

    The following table provides the evaluated pod states for different CPU and Queue states:

    Table 4-3 Published Pod Congestion State

    Pod CPU Queue
    CONGESTED NORMAL CONGESTED
    DOC DOC NORMAL
    DOC DOC DOC
  3. The current congestion state of the pod holds the published state of the pod congestion state. This changes to the calculated congestion state only when the calculated state remains same for all the configured number of continuous sample counts. By doing so, the pod avoids events like short bust of traffic triggering a change in the congestion state and load shedding. However, in the following scenario, the current congestion state changes to DOC whenever:
    • the current state is NORMAL and calculated state is CONGESTED, or
    • the current state is CONGESTED and calculated state is NORMAL

Triggering Congestion Control

Every time Bulwark receives request to its lock and unlock service, the system checks for the current congestion state of the pod. The current congestion state on being Congested or DOC the congestion control mechanism gets triggered.

The lock and unlock requests have 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.

The consumer services such as SM, AM, UE, and PDS services shall support priority header functionality to their lock and unlock requests based on message types and use cases.

Below figure illustrates this process.

Figure 4-21 Process Flow for Triggering Congestion Control


Process flow for triggering congestion control

If the consumer services requests are without priority value set, then the bulwark service considers the default priority values. The Bulwark service default lock and unlock request priorities are:
  • DEFAULT_LOCK_REQUEST_PRIORITY: 25
  • DEFAULT_UNLOCK_REQUEST_PRIORITY: 15

Priority-Based Load Shedding

The congestion load rule configurations for current congestion state of the pod are applied to perform priority-based load shedding. It determines if the message with the assigned priority should be rejected or accepted.

These rules get configured per congestion state. If there are no rule configured for a congestion state, then bulwark accepts the request as a default behavior. The user can customize the result codes for the rejected requests when configuring the load rules. Customized the default result code is 503 Service Unavilable.

The default load shedding rules for bulwark service: 

- state: DANGER_OF_CONGESTION        
      discardPriority: 20      
- state: CONGESTED
      discardPriority: 10

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. The default priority values for the following requests are:
  • CREATE - 24
  • UPDATE - 18
  • UPDATE_NOTIFY - 18
  • DELETE - 16
  • CLEANUP - 18
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:
  • REQUEST_PRIORITY_FOR_SM_CREATE
  • REQUEST_PRIORITY_FOR_SM_UPDATE
  • REQUEST_PRIORITY_FOR_SM_UPDATE_NOTIFY
  • REQUEST_PRIORITY_FOR_SM_DELETE
  • REQUEST_PRIORITY_FOR_SM_CLEANUP

Moreover, if the user does not want to consider the 3gpp-Sbi-Message-Priority value for oc-message-priority then the Advanced setting field USE_TGPP_SBI_MSG_PRIORITY should be set to false in the SM service configurations.

Below diagram shows the call flow for SM service supporting the priority header functionality.

Figure 4-22 Call Flow Diagram for Bulwark Congestion Control


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.

Managing Bulwark Pod Congestion Control

Enable

PCF supports congestion control for Bulwork pods as a core functionality. You do not need to enable or disable this feature.

Note:

For disabling this feature ensure to set thresholds for CPU & QUEUE to 0.

Configure Using CNC Console

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

Configure Using REST API

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

Observability

Metrics:

Following metrics were updated in the Pod Congestion Metrics section.
  • occnp_pod_congestion_state
  • occnp_pod_resource_state
  • occnp_pod_resource_congestion_state

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:

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.6 Supports 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-23 UDR Discovery with oc-policy-udr-group-id-list Header to NRF


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-4 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-24 SMF sends SM Policy Association Request with oc-policy-udr-group-id


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-25 AMF sends AM Policy Association Request with oc-policy-udr-group-id


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-26 AMF sends UE Policy Association Request with oc-policy-udr-group-id


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-5 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-27 UDR Discovery with 3gpp-Sbi-Discovery-group-Id-list Header to SCP


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-6 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-28 Model D, AMF sends UE Policy Association Request with oc-policy-udr-group-id-list


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 supi and group-id-list parametes. Model D Communication profile supports group-id-listparameter. 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.7 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-7 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.8 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-29 UDR GET Discovery Result Reused in UDR POST

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-30 Reuse of UDR profile for amPolicyData GET in uePolicySet GET

UDR GET for AM and UE Create
  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.9 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 unresolvable-reference.html#GUID-7FADC315-1B9B-46FB-8169-D042328F7F32.

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.10 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. Dual IPs support is currently not available.

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-8 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.11 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-31 Rx Stale Session Detection and Deletion Based on TTL and Authorization-Lifetime


Rx Stale Session Detection 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-32 Rx session cleanup when Audit service detects a stale session


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.12 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, PDS, and PCRF-core services support this feature only with Zlib_Compressed scheme. SM service supports this feature with both MySQL_Compressed and Zlib_Compressed schemes.

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.13 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:

  • Daily
  • Weekly
  • Monthly
  • X-days
  • 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:

  • Daily
  • Weekly
  • Monthly
  • X-days
  • Forever (Lifetime)

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.

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 Configuring 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:

    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.13.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.
Quota migration architecture

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.

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.14 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-33 Scenario when user profile is not avaiable in UDR


Scenario when user profile 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-34 Scenario when the subscriber profile is provisioned at UDR, but the umData is not provisioned


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.15 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-35 Call flow for sending messages using SMPP protocol


This diagram depicts the 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.16 Support for Query on Update and Subscription to UDR

PCF uses the Query data procedure to retreive 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 an 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 failed (could be in the Create request or a previous Update request).
  • Policy should not query UDR once GET is successful and subscription is successful.

Call Flow

Figure 4-36 Retrieving user data from UDR upon a GET or Update request to a Policy Service


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 sends 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 revalidation 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-9 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:
  • 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.17 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 nreceives 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-37 PRA Support for SM Service

PRA Call flow
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-38 UE Policy Association create scenario:


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-39 UE Policy Association update scenario


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.18 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-40 Example of Policy with Conflicts in a Session Rule

Sample policy to show conflicts in same 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.19 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-41 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 retries.

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-42 Call Flow Rx RAR or Rx ASR one time message retry - Success Case:


Call Flow Rx RAR or Rx ASR 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-43 Call Flow RX RAR or RX ASR Timeout Retry - Success Case:


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 configures the number of retries to be performed for Rx RAR and Rx ASR diameter messages and this retry attempt happens only when the alternate peers are available. If alternate peers are not available, 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

PCF cycle back to retry alternate peers if the number of retries configured is more than the number of alternate peers available for both Rx RAR and RX ASR message retries. 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.

For example: Number of configured retries is 2 and only 2 BSF/DRA are configured as alternate peers in PCF.

If Rx RAR message sent via (PCF-1) - (BSF1/DRA1) - (PCSCF-1) and the response has error code such as 5012/timeout/3002/3004:
  • Then the failed message is resent via (PCF-1) - (BSF2/DRA2) - (PCSCF-1) and even if its response has failed error code such as 5012/timeout/3002/3004.
  • Then during the second retry the message is resent via (PCF-1) - (BSF1/DRA1) - (PCSCF-1) and thus the peer cycle back retry mechanism is used.
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-44 RX RAR/RX ASR Retry - Peer Cycle Back When Retry Count > Alternate Peers


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 resends 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-45 RX RAR/RX ASR Retry - Error Originated by Intermediate Peer


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-46 RX RAR/RX ASR Retry - Error Originated by Destination Peer (Not Intermediate Peer)


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:
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.20 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-47 New SCP selection mechanism


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
  • oc_egressgateway_peer_health_ping_response
  • oc_egressgateway_peer_health_status_transitions
  • oc_egressgateway_peer_count
  • oc_egressgateway_peer_available_count

Alert

Following alerts are added in the Alert section:

4.21 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-10 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-11 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.22 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. 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_exec_total
  • error_handler_out_total

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-48 Reject Session with Error Code and Error Cause

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.23 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.24 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.25 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-49 Support for Multiple Instance Deployment

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-50 Support for Multicluster Deployment

Support for Multicluster Deployment

4.26 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

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.27 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-51 Notification of the AF Signaling Transmission in 5G

Notification of the AF Signaling Transmission in 5G

Figure 4-52 Notification of the AF Signaling Transmission in 4G

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-53 Subscription to notification of the AF Signaling Transmission in 5G

Subscription

Figure 4-54 Subscription to notification of the AF Signaling Transmission in 4G

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-55 Cancellation of subscription to notification of the AF Signaling Transmission in 5G

Cancellation

Figure 4-56 Cancellation of subscription to notification of the AF Signaling Transmission in 4G

Cancellation of subscription to notification of the AF Signaling Transmission in 4G

4.28 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.29 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-57 3GPP-User-Location-Info Call Flow

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-12 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-13 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.30 Support for Server Header

With this feature, server header is included in the response message when an error is generated either at the backend microservices or the Ingress Gateway itself. If the error occurs at any backend service and the error response contains server header, then Ingress Gateway forwards the response without making any changes.

The following format is used to generate server header:

<NF_Type>-<NF_Instance_Id>

Example: SCP-scp1.operator.com

Note:

If <NF_Instance_Id> is unavailable, server header is created using only <NF_Type>.

Managing Server Header

Enable

You can enable the Server Header feature using Helm or REST API configurations as follows:
  • Helm: Set the value for parameter serverHeaderConfigMode to REST in the custom-values.yaml file. Then, set the value for parameter serverHeaderEnabled to true under routesConfig for egress-gateway. For more information, see the Oracle Communications Cloud Native Core, Converged Policy Installation, Upgrade and Fault Recovery Guide.

  • REST API: By default, this feature is disabled. To enable the server header feature using REST API, set the enabled parameter to true in the following resource URI:

    Define server header at global level: {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: Policy provides the following REST API:

    Define error code series list: {apiRoot}/PCF/nf-common-component/v1/igw/errorcodeserieslist

    Define server header at route level: {apiRoot}/PCF/nf-common-component/v1/igw/routesconfiguration

    Note:

    If you define server header configuration at both global and route levels, the route level configuration takes precedence over the global level configuration.

    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 API Specification Guide.

  • Configure using helm: To configure server header at Egress Gateway, you need to perform the helm configurations:
    withServerHeaderSupport:
        retries: 3
        methods: GET, POST, PUT, DELETE, PATCH
         This is an HttpStatus (ENUM). 
         NOTE: Re-route will be applicable if response contains the following status codes
        statuses:
        - status: BAD_REQUEST
        - status: INTERNAL_SERVER_ERROR
        - status: BAD_GATEWAY
        - status: NOT_FOUND
        exceptions:
        - exception: java.util.concurrent.TimeoutException
        - exception: java.net.UnknownHostException

  serverHeader:
     
    autoBlackListProxy:
      enabled: false  Only true/false allowed
      
      errorCodeList:
      - errorSetId: 4XX
        errorCodes: 401, 402, 403, 404
      - errorSetId: 5XX
        errorCodes: -1
      blacklistingPeriod: 60000
  • 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.31 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.32 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.

Managing Late Arrival requests and Collision Detection

Enable

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 Late Arrival Handling Configuration 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.32.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.33 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-58 PCF Microservice Initiates Egress Request

retry

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-59 Egress Gateway get Error Response

alternate routing

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 recieves 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 sent to 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-60 Session Retry at Egress Gateway

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 bythe 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 following diagram depicts an example call flow for retry notification from UDR to SMF:

Figure 4-61 On demand NF Discovery is enabled (NF Set Resolution is set to NRF Discovery)


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 recieves 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 Natvie 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.34 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-62 Initial CallS for Producer FQDNs

Initial Call to Producer
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-63 Subsequent Calls for Producer FQDN

Subsequent Call for Producer
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.35 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

Feature Design

The following diagram provides a high level design for stale session handling through session state Audit service:

Figure 4-64 High Level Design for Stale Session Handling using Audit Service


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-65 Timeline view of Audit Service


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-66 Example call flow for Stale Session Detection and Handling in SM Service


Example call flow for Stale Session 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..

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-67 Example call flow for Stale Session Detection and Handling in UE Service


The following figure shows an example call flow for handling stale session notification by the 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-68 Example call flow for Stale Session Detection and Handling in AM Service:


The following figure shows an example call flow of handling of stale session notification by the Policy 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-69 Example call flow for Stale Session Detection and Handling in PCRF Core Service


The following figure shows an example call flow of handling of stale session notification by the Policy 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.
    • If the maxTTL flag is FALSE, Rx sessions in DB are cleaned with ASR message to AF/PCSCF.
  • 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-70 Example call flow for Stale Session Detection and Handling in Binding Service


The following figure shows an example call flow for detection and handling of stale session notification by the 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 60 minutes.

Enhancements to Audit service and related configurations

Reasons for enhancements:

Unavailability of Audit service, or any of the PCF services, or external NF affects the stale session detection and removal process. Later, when Audit service and conditions are back to normal, the audit process would clean up the suspected stale sessions, whose Max TTL has expired.

Exmple scenario:

Site 1 is stuck in some state where it is not able to detect/iterate through all records OR site 1 is not able to audit the record successfully with external NF.

Site 2 runs its maxTTL/forceTTL logic to purge the record in a non-graceful way.

This allows local/mated sites to directly process max/force TTL logic on records, which may be healthy but never got audited/updated in previous cycles.

Also, it is possible that more than one sites is auditing the same record at the same time. This is waste of network resource and processing capacity of policy services and other NFs.

Enhancements made:

In Policy 23.1.7, enhancements are made to Audit service and related configurations to address such issues. The enhancement includes counting the minimum audit attempts for maxTTL/forceTTL to consider initial attempts. This minimum audit attempts is configured using CNC Console. For more details, see Audit Service.

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: .
  • 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.

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.36 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-14 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-71 Example of NF Set and Binding Header based Indirect Communication

Indirect Communication between PCF and other NF

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


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.


rerouting a notification message from UDR to an alternate PCF using service name in 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.


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:
  • 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:

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.37 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-72 Two-Site Georedundancy Deployment

Two-site georedundancy

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-73 Three-Site Georedundancy Deployment

Three-site georedundancy

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-74 Four-Site Georedundancy Deployment

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-15 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.38 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, higher CPU usage, and higher memory utilization. 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.

Diagram to show how loadbalancer routes diameter gateway request

Determining Pod Congestion State

At any given point of time, a pod can be in any one of the following states:
  1. Normal
  2. DOC (Danger of Congestion)
  3. Congested

Figure 4-75 Congestion states

Congestion states
To decide the state of a pod, the following points are taken into consideration:
  1. Calculate the congestion state for the following resources:
    1. Queue: Compare the count of pending messages (in the queue) against the configured pending messages threshold for each congestion state (DOC, CONGESTED).
    2. CPU - 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 nano seconds) with the configured threshold. The following formula is used to calculate CPU usage:CPU usage
    3. Memory - Memory usage for congestion state is calculated by comparing the memory usage of the container with the configured threshold. The following formula is used to calculate memory usage:
      Memory usage

      where memory limit is monitored using memory.limit_in_bytes cgroup parameter and current memory usage is monitored using memory.usage_in_bytes cgroup parameter.

  2. Based on the congestion state of resources, the congestion state for the pod is set to the maximum of congested states. The following table describes how the state of the pod is evaluated for various scenarios:

    Table 4-16 Published Pod Congestion State

    Queue CPU Memory Pod
    CONGESTED NORMAL DOC CONGESTED
    NORMAL DOC NORMAL DOC
    DOC DOC Normal DOC
  3. The current published congestion state of the pod is changed to calculated congestion state only when the calculated state remains same for the configured number of continuous sample counts (100 ms by default). By doing so, events like short bust of traffic triggering a change in the congestion state and load shedding can be avoided. The only exceptions to this rule is when current state is NORMAL and calculated state is CONGESTED, and current state is CONGESTED and calculated state is NORMAL.

Triggering Congestion Control

Every time a message is fetched from the ring buffer for processing, the system checks the current congestion state of the pod. If the current state is either DOC or Congested, the congestion control mechanism is invoked. After verifying that the message type is a request, a priority is assigned to it. If the assigned priority is less than or equal to discard priority, the message is rejected.

Note:

Congestion control does not apply to response messages as they are always accepted.

Figure 4-76 Process flow for triggering congestion control

Triggering congestion control process flow

The priority value for a request can be from 0 to 15 where 0 is the highest priority and 15 is the lowest priority.

For priority based load shedding to happen, load rule configured for current congestion state is taken into consideration. If there is no rule configured for a congestion state, the requested is accepted by default. While defining load rules, the result to reject the request can also be customized by the user. However, to reject requests from backend peers, the result code is always DIAMETER_TOO_BUSY.

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-17 Message Priority Profiles

Message Priority
Default 6
Rx RAR 7
Gx CCR-I 10
Sy SLR 11

Note:

The default message profile is only for the purpose of understanding the feature. No default message priority profiles are configured for Policy.

For this call flow, discard priority is set as 10 for DOC and Congested state. The result code for rejecting request messages is set as DIAMETER_UNABLE_TO_COMPLY (applicable only for external peers).

Figure 4-77 Call flow diagram for Diameter Congestion Control

Call flow for Diameter Congestion Control
  • When Diameter Gateway 2, currently 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 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 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.

Enable

The congestion control for diameter gateway pods is a functionality supported by Policy configurations. You do not need to enable or disable this feature.

Configure

You can customize the configurations related to this feature using the CNC Console or REST APIs for Policy.
  • 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 Diameter Configurations.
  • Configure using REST API: Policy provides the following REST API for configurating diameter gateway pod congestion control feature:

    Load Shedding Profiles: {apiRoot}/oc-cnpolicy-configuration/v1/diameter/loadsheddingprofiles

    Message Priority Profiles: {apiRoot}/oc-cnpolicy-configuration/v1/diameter/messagepriorityprofiles

    Congestion Threshold: {apiRoot}/oc-cnpolicy-configuration/v1/threshold/{serviceType}

    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

Metrics
Policy uses the pod congestion metrics for this feature. For more information, see the Pod Congestion Metrics section. Alerts are raised when the following metrics are pegged:
  • pod_congestion_state
  • pod_resource_congestion_state

Note:

Prometheus automatically injects name of the pod with label name "kubernetes_pod_name" to metric. This information is further used for alerting purposes.
Alerts
Policy uses the following congestion control alerts for this feature:
  • PodDoC
  • PodCongested
  • PodPendingRequestDoC
  • PodPendingRequestCongested
  • PodCPUDoC
  • PodCPUCongested
  • PodMemoryDoC
  • PodMemoryCongested

For more information, see the PCF Alerts section.

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.39 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 Overload Level Threshold ProfileS sections 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 requrest 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-18 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-19 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-19 table, you can calculate the onset and abatement values for load levels - L1, L2, and L3, as shown in the Table 4-20 table.

Note:

The values shown in Table 4-19 table are the default values and can be changed depending on the deployment model used.

Table 4-20 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-21 table.

T denotes the maximum incoming TPS of a given service listed in Table 4-21 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-21 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

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-22 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-23 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-24 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-25 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-26 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.39.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 pecentage 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.39.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 Natvie Core, Converged Policy REST Specification Guide.

The following are the recommended configurations for default message priority values for overload control:

Table 4-27 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.40 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-28 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.41 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.42 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.43 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.44 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.45 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 multiple LDAP servers

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 different LDAP data sources, more entries can be added in above format only the key of the entry should be the ldap name specified 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.46 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-78 Fetching subscriber data


This diagram depicts Policy interaction with LDAP server and SOAP client to fetch the 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.47 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.48 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.49 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-79 Communicating STR messages


Adding Subscription-ID AVPs in 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.50 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.51 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.52 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

policy sample

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.53 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 statitcally 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-80 Call Flow Validating single XFCC Header

Single XFCC Header call flow

Table 4-29 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.   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-81 Call Flow Validating Multiple XFCC Headers

img/multiple-xfss-headers.png

Table 4-30 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.   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.   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.54 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.55 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.56 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.57 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-82 Call Flow - IMS Emergency

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.58 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.59 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.60 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-83 Call flow for notification handling from PDS for PCRF-Core

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.61 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.62 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.63 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
  • http_bulwark_unlock_request
  • http_bulwark_lock_response
  • http_bulwark_lock_request_retry
  • http_bulwark_unlock_request_retry
  • 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.64 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 proceed.

Note:

Note: 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.

Note:

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.65 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 Status.

4.66 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-84 BSF and PCF Interaction for Stale Binding Detection

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.67 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.

To configure pod protection on Ingress Gateway, you can define threshold limit for DoC and Congested state through REST:
Level Resource
DoC CPU
Memory
Pending Message
Congested CPU
Memory
Pending Message

Configure

You need to perform the following configurations for pod protection feature:
  • Configure using REST API: Policy provides the following REST API:

    {apiRoot}/PCF/nf-common-component/v1/igw/podprotection

    You can perform the GET, PATCH, or PUT operation to configure the feature. For more information about REST API configuration, see Oracle Communications Cloud Native Core, Converged Policy REST Specification Guide.

4.68 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 (SM and PDS service) 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.

4.68.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-31 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-32 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-33 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-85 Call Flow - Bulwark Lock Request SM Create Procedure

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-86 Call Flow for SM Update-Notify Request (One Notification and One Session)

Call Flow for SM Update-Notify Request
  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-87 Call Flow for SM Update-Notify Request (One Notification and n Sessions)

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-88 Call Flow for SM Update-Notify Request (Two Notifications and 1 Session)

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-89 Call Flow for SM Update-Notify Request (Two Notifications from Same Subsriber and n Sessions Each)

Call Flow for SM Update-Notify Request (Two Notifications from Same Subsriber 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-90 Concurrency enabled for SM Update for a single session


The following diagram shows a scenario when 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-91 Concurrency Enabled for SM-Update and multiple updates for the same subscriber


The following diagram shows a scenario when concurrency enabled for SM Update and 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. 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-92 Retrial failure when there are multiple updates for same subscriber in different sessions


The following diagram shows a scenario when concurrency enabled for SM Update and lock request for one of the requests fail 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-93 Pending transaction and Concurrent SM-Update for same session - Success scenario


The following diagram shows a scenario when Pending Transaction enabled for Update-notify and Concurrency is enabled for SM-Update and the SM Update and SM Update-Notify are successful

  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-94 Pending transaction and Concurrent SM-Update for same session - Retry failure scenario


The following diagram shows a scenario when Pending Transaction enabled for Update-notify Concurrency is enabled for SM-Update and retrying to acquire the lock for SM Update fails

  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-95 Concurrent SM-Update-Notify and Concurrent SM-Update - Success scenario


The following diagram shows a scenario with concurrency enabled for SM-Update and concurrency enabled for SM-Update-Notify

  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-96 Concurrent SM-Update-Notify and Concurrent SM-Update - Failure scenario


The following diagram shows a scenario for concurrency enabled for SM-Update, concurrency enabled for SM-Update-Notify and retrial for acquiring the lock fails

  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-97 Call Flow - Bulwark Lock Request SM Delete Procedure

Call Flow - Bulwark Lock Request SM Delete Procedure

Call Flow for SM Cleanup (Session Viewer Delete)

Figure 4-98 Requests for SM Clean


SM Service receives request for SM cleanup when you query SM Policy Association from Session Viewer and click Delete. The request comes from the CM GUI (Session Viewer) to Query Service and to SM Service.

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-99 Local delete


This call flow depicts how SM service handles SM cleanup requests locally.

  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-100 Remote delete


This call flow depicts how SM service handles SM cleanup requests remotely.

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 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.68.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-34 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-35 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-36 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-101 Call flow for two AM-Create requests for same subscriber and retry success

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-102 Two AM-Create requests for same Subscriber and retry failure (retry =1)

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-103 Two AM-Delete requests for same Subscriber and retry success

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-104 Two AM-Delete requests for same Subscriber and retry failure (retry =1)

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-105 Two AM-Update requests for same Subscriber but different Sessions and retry success

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-106 Two AM-Update requests for same Subscriber but different Sessions and retry failure (retry =1)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-107 Two AM-Notify requests for same Subscriber each having 1 Session

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 AMPolicyAssoaciation 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-108 Two AM-Notify request for same Subscriber each having n Sessions

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 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.68.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-37 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-38 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-39 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-109 Two UE-Create requests for same Subscriber and retry success.

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-110 Two UE-Create requests for same Subscriber and retry failure (retry =1)

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-111 Two UE-Delete requests for same Subscriber and retry success.

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 AM-Delete requests for same Subscriber and retry failure (retry =1)

Figure 4-112 Two AM-Delete requests for same Subscriber and retry failure (retry =1)

Two AM-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-113 Two UE-Update requests for same Subscriber but different Sessions and retry success.

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-114 Two UE-Update requests for same Subscriber but different Sessions and retry failure (retry =1)

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-115 Two UENotify requests for same Subscriber each having 1 session

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 PolicyAssoaciation 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-116 Two UENotify request for same Subscriber each having n sessions

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 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.68.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-117 CCR-I, CCR-U and CCR-T messages Integration with Bulwark Service

CCR-I, CCR-U and CCR-T messages Integration with Bulwark Service

Call Flow- PDS notification (RAR) Integration with Bulwark Service

Figure 4-118 Call Flow- PDS notification (RAR) Integration with Bulwark Service

Call Flow- PDS notification (RAR) Integration with Bulwark Service

Managing Concurrency Handling for PDS Service

Observe

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-40 General

    Key
    CONCURRENCY.ENABLED

    Table 4-41 List of Keys for Gx CCR-I

    Key
    CONCURRENCY.GX.CREATE.LOCK_REQUEST_RETRY_COUNT
    CONCURRENCY.GX.CREATE.LOCK_REQUEST_RETRY_BACKOFF
    CONCURRENCY.GX.CREATE.LOCK_LEASE_DURATION
    CONCURRENCY.GX.CREATE.LOCK_WAIT_DURATION
    CONCURRENCY.GX.CREATE.ENABLED
    CONCURRENCY.GX.CREATE.ALLOW_ON_SERVICE_FAILURE

    Table 4-42 List of Keys for Gx CCR-U

    Key
    CONCURRENCY.GX.MODIFY.LOCK_REQUEST_RETRY_COUNT
    CONCURRENCY.GX.MODIFY.LOCK_REQUEST_RETRY_BACKOFF
    CONCURRENCY.GX.MODIFY.LOCK_LEASE_DURATION
    CONCURRENCY.GX.MODIFY.LOCK_WAIT_DURATION
    CONCURRENCY.GX.MODIFY.ENABLED
    CONCURRENCY.GX.MODIFY.ALLOW_ON_SERVICE_FAILURE

    Table 4-43 List of Keys for Gx CCR-T

    Key
    CONCURRENCY.GX.DELETE.LOCK_REQUEST_RETRY_COUNT
    CONCURRENCY.GX.DELETE.LOCK_REQUEST_RETRY_BACKOFF
    CONCURRENCY.GX.DELETE.LOCK_LEASE_DURATION
    CONCURRENCY.GX.DELETE.LOCK_WAIT_DURATION
    CONCURRENCY.GX.DELETE.ENABLED
    CONCURRENCY.GX.DELETE.ALLOW_ON_SERVICE_FAILURE

    Table 4-44 List of Keys for for Gx RAR

    Key
    CONCURRENCY.GX.REAUTH.LOCK_REQUEST_RETRY_COUNT
    CONCURRENCY.GX.REAUTH.LOCK_REQUEST_RETRY_BACKOFF
    CONCURRENCY.GX.REAUTH.LOCK_LEASE_DURATION
    CONCURRENCY.GX.REAUTH.LOCK_WAIT_DURATION
    CONCURRENCY.GX.REAUTH.ENABLED
    CONCURRENCY.GX.REAUTH.ALLOW_ON_SERVICE_FAILURE

    Table 4-45 List of Keys for for SD Create

    Key
    CONCURRENCY.SD.CREATE.LOCK_REQUEST_RETRY_COUNT
    CONCURRENCY.SD.CREATE.LOCK_REQUEST_RETRY_BACKOFF
    CONCURRENCY.SD.CREATE.LOCK_LEASE_DURATION
    CONCURRENCY.SD.CREATE.LOCK_WAIT_DURATION
    CONCURRENCY.SD.CREATE.ENABLED
    CONCURRENCY.SD.CREATE.ALLOW_ON_SERVICE_FAILURE

    Table 4-46 List of Keys for for Additional Properties

    Key
    bulwark.service.enabled
    bulwark.service.http2.enabled
    bulwark.service.url
    bulwark.service.connector.timeout

    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.
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.68.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-119 Call Flow - Bulwark Lock Request For CHF Notification


The following diagram shows a scenario for Bulwark lock request from PDS Service for CHF update 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 aquire 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-120 Call Flow - Bulwark Lock Request For UDR Notification


The following diagram shows a scenario for Bulwark lock request from PDS Service for UDR update 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 aquire 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-121 Call Flow - Bulwark Lock Request For OCS Notification


The following diagram shows a scenario for Bulwark lock request from PDS Service for OCS update 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 aquire 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.69 Support for Sd Interface

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 estblishment between Policy and TDF:

Figure 4-122 TDF Session Establishment over Sd Interface


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-123 Call Flow for TDF Session


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-124 Traffic Detection for Peer Node


    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-125 Traffic Detection for Peer Node Sets

    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-126 Install with specified ADC Rules


    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-127 Remove all ADC Rules


      Remove all ADC Rules

    • To remove specified ADC Rules

      Figure 4-128 Remove specified ADC Rules


      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-129 Set Session Revalidation Time

    Set Session Revalidation Time

Observe

Policy provides metrics specific to determine the successful TSR and RAR messages sent to TDF.

Policy provides following alert for this feature.
  • TDF_CONNECTION_DOWN

For more information, see TDF_CONNECTION_DOWN.

4.70 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.
  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 Reattemts 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.71 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-130 Call Flow for Diameter Gateway PARTIAL SHUTDOWN

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-131 Call Flow for Diameter Gateway COMPLETE SHUTDOWN

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-132 Call Flow for Egress Gateway COMPLETE SHUTDOWN

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-133 Call Flow for Ingress Gateway PARTIAL SHUTDOWN

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-134 Call Flow for Ingress Gateway COMPLETE SHUTDOWN

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.

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:

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.72 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-135 Call Flow - NRF Rediscovery


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.valityTime 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-136 Call Flow - NF Discovery Error Scenario


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-47 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.73 Limiting the Number of Sessions

Until Policy Release 22.3.2, there was no process for policy services to identify whether it has received multiple create requests for the same subscriber (SUPI).

This feature allows you to configure the maximum number of sessions for a subscriber when Limiting the Number of Sessions functionality is enabled. It avoids multiple policy association table entries for a subscriber in the respective policy service database tables (such as AMPolicyAssociations, and UEPolicyAssociations).

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).

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

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-137 Limiting the number of sessions for UE Policy Service


A sample call flow for limiting the UEPolicyAssociations is as shown.

Managing Limiting the Number of Sessions

Enable

By default, this feature is disabled for AM Service and UE Policy 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.
    • 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 AM Service, see PCF Access and Mobility.

    For more details on enabling the flag for UE Policy Service, see PCF UE Policy 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.

    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:
  • 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

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:

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.74 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-138 resetContextUePolicySetData set to true when there are no existing sessions for UE Policy service


This call flow depicts resetContextUePolicySetData flag 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-139 resetContextUePolicySetData set to false when there are existing sessions for UE Policy service


This call flow depicts resetContextUePolicySetData flag set to true 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-140 Revalidation of the subscription data for UE Policy Sessions


This call flow depicts revalidation of the subscription data for UE Policy Service 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.75 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.76 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 will take the policy counters from the last request and both services will be 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.

Note:

As of Policy 22.4.0 Release, only Asynchronous flow is supported.

Call Flow

Below is an example for retrieving CHF Data for AM Service:

Figure 4-141 Spending limit status report for AM Service


Example for retrieving CHF Data 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 AM and UE

Figure 4-142 Update notification to AM Service and UE Policy Service


This call flow depicts notification to AM service and UE Policy service in case of updates to policy counters.

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 AM Service or UE Service.
  4. AM Service or UE Policy Service processes the notification and if required it sends an update notify to AMF.
  5. AM Service and UE Policy Services accepts the message and responds 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 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.

Managing Handling PDS Stale Sessions

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 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 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 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:

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.77 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.

Table 4-48 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-143 Call flow to Save Configuration Data


This section describes examples of the call flows for the NF Scoring feature:

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-144 Call flow to Get the NF Score


CM Requests to App-Info

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.

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.78 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.79 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-145 PCC Rule for SM Create and SM Update requests


This diagram depicts the call flow for 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-146 PCC Rule in SM-UPDATE-NOTIFY request (Re-authorization)


This diagram depicts call flow for 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.80 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.80.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-147 State Variables in Policy


The State Variable section lists the functions (Save, Load, Remove, Remove All) for each of the contexts (Policy, Session, Subscriber).

  • 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.

Call Flow

Figure 4-148 State variables in create session call flow


This diagram depicts 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-149 State variables in update session call flow


This diagram depicts 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-150 State variables in delete session call flow


This diagram depicts 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-151 State variables in concurrent flows


This diagram depitcs 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. PDSreturns 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 paramter 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 paramter 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 paramter 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 paramter 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.

Observe

The following PolicyDS metrics provide information about state variables:
  • client_request_total
  • client_response_total

For more information, see Policy DS Metrics.

4.80.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.81 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.82 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-49 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

Table 4-50 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:

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-51 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-152 MCPTT APN Handling


This diagram depicts the call flow for 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-153 MCPTT QCI & ARP settings for MCPTT AF flows


This diagram depicts the call flow for MCPTT QCI and 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-154 Priority Sharing


This diagram depicts the call flor for 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-155 Preemption Control - CCRU- CharginRuleReport scenario


This diagram depicts the call flow for 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-156 Preemption - No Preemptable Rule found


This diagram depicts the call flow for Preemption - No Preemptable Rule found 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 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.83 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.84 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.85 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.