3 Service Communication Proxy Features

This chapter describes the features of Oracle Communications Cloud Native Core, Service Communication Proxy (SCP).

Note:

The performance and capacity of the SCP system may vary based on the call model, feature or interface configuration, network conditions, and underlying CNE and hardware environment.

3.1 Traffic Segregation

In SCP 24.3.x and earlier releases, SCP did not have an end-to-end network segregation mechanism based on traffic types. SCP was using the Load Balancer Virtual Machine (LBVM) and MetalLB features of Oracle Communications Cloud Native Core, Cloud Native Environment (CNE) to load balance the traffic received from consumer NFs and other components of Cloud Native Core (CNC).

From SCP 25.1.100, SCP uses Cloud Native Load Balancer (CNLB) of CNE to load balance traffic by segregating different traffic types, such as Operations, Administration, and Maintenance (OAM) traffic from CNC Console and Service Based Interface (SBI) signaling traffic from consumer NFs. CNE provides the CNLB functionality to manage load balancing as an alternative to the existing LBVM or MetalLB solutions. SCP continues to use LBVM or MetalLB and cannot enable CNLB if the CNE setup does not have CNLB enabled. Use of CNLB requires fresh installation of SCP if prior deployment is not using CNLB.

Note:

CNLB is supported for both vCNE and BareMetal deployments of CNE.

For more information about CNLB, see Oracle Communications Cloud Native Core, Cloud Native Environment User Guide.

This feature enables SCP to:

• use dedicated subnetwork for different traffic types that improves security, reduces latency, and reduces congestion.
• address the challenge of logically separating different traffic types, which are typically handled through a single network (Kubernetes overlay).

The feature requires configuration of Network Attachment Definitions (NADs) and CNLB to facilitate traffic segregation and optimize load distribution in SCP.

CNLB uses Multus Container Network Interface (CNI), which creates different interfaces for the same or different traffic types. CNLB exposes its IP addresses and ports to consumer NFs to establish communication with SCP-Worker using the Network Attachment Definition (NAD) configuration. SCP registers with NRF using these IP addresses to enable other NFs to discover SCP in the network and notify their profile events to SCP through NRF. For more information about Multus and NAD, see Support for Multus Container Network Interface.

Managing Traffic Segregation

Enable

By default, this feature is disabled at the time of SCP deployment. To enable this feature, perform the following procedure:

Note:

If CNE is installed with CNLB, this feature should be enabled in SCP.

1. Open the ocscp_values.yaml file and set the cnlbInfo.cnlbEnable Helm parameter to true.
2. Configure the exposed external IPv4 and IPv6 addresses of CNLB using cnlbInfo.cnlbIPv4 and cnlbInfo.cnlbIPv6 parameters to enable other NFs to establish communication with SCP.

   Note:

   You can configure either IPv4 or IPv6 or both.

   For more information about cnlbInfo.cnlbEnable, cnlbInfo.cnlbIPv4, and cnlbInfo.cnlbIPv6, see Oracle Communications Cloud Native Core, Service Communication Proxy Installation, Upgrade, and Fault Recovery Guide.

   Sample configuration:

   cnlbInfo:
      # Enable/Disable cnlb, possible values are true or false. Default value is false.
      cnlbEnable: true
      # CNLB IPv4 addresses
      cnlbIPv4:
      - 10.123.0.0
      - 10.123.0.1
      - 10.123.0.2
      # CNLB IPv6 addresses
      cnlbIPv6:
      - d678:f81d:a355:6794:658a:7e50:c208:7f0d
      - 0b3e:a0da:6c7f:ec79:75e7:40b2:3411:392e
      - 0d68:4f2b:649b:f97d:52e4:2036:d96c:8bad

3. Configure the 'network attachment' and 'cnlb' annotations in the scp-worker.deployment.customExtension.annotations Helm parameter.

   For more information about annotation values, see Oracle Communications Cloud Native Core, Cloud Native Environment Installation, Upgrade, and Fault Recovery Guide.

   Sample single network annotation:

   scp-worker:
   ...
   .
        
     deployment:
     ..
       # Labels and Annotations that are specific to deployment are added here.
       customExtension:
         labels: {}
         annotations:
           k8s.v1.cni.cncf.io/networks: default/nf-sig-ie3@nf-sig-ie3
           oracle.com.cnc/cnlb: '[{"backendPortName": "http2-5gsig", "cnlbIp": "10.75.181.55", "cnlbPort": "8000"},
                                  {"backendPortName": "https-5gsig", "cnlbIp": "10.75.181.55", "cnlbPort": "9443"}]'

4. Save the ocscp_values.yaml file.
5. Run the following command to install SCP using charts from the Helm repository:

   helm install <release name> -f <custom_values.yaml> --namespace
   <namespace> <helm-repo>/chart_name --version <helm_version>

   In case charts are extracted:

   helm install <release name> -f <custom_values.yaml> --namespace
   <namespace> <chartpath>

Configure

You can configure this feature using the following Helm parameters:

• containerPortNames.scp-worker.http
• containerPortNames.scp-worker.https
• containerPortNames.scp-cache.coherence
• containerPortNames.scp-config.http
• cnlbInfo.cnlbEnable
• cnlbInfo.cnlbIPv4
• cnlbInfo.cnlbIPv6
• scpc-configuration.deployment.customExtension.annotations
• scp-cache.deployment.customExtension.annotations
• scp-worker.deployment.customExtension.annotations

For information about the above mentioned Helm parameters, see Oracle Communications Cloud Native Core, Service Communication Proxy Installation, Upgrade, and Fault Recovery Guide.

Observe

There are no specific metrics and alerts required for this feature.

Maintain

If you encounter alerts at system level, see the Alerts section for resolution steps.

In case the alerts persist, perform the following tasks:

1. Collect the logs: For information about how to collect logs, see Oracle Communications Cloud Native Core, Service Communication Proxy Troubleshooting Guide.
2. Raise a service request: For information about how to raise a service request, see My Oracle Support.

3.2 Support for 3GPP Defined NFs, Custom NFs, and Custom NF Services

In SCP 24.3.0 and earlier releases, SCP supported only 3GPP defined NFs and NF services (a set of 3GPP defined NFs supported by SCP). To add any new NF or NF services, SCP required a software update.

From SCP 25.1.100, SCP enhances its capability to support the addition of new 3GPP defined NFs, custom NFs, and custom NF services at runtime using REST APIs. Any NF type or NF service that is not configured in SCP remains UNKNOWN. SCP creates routing rules for the newly added NF types and NF services without any software update. These routing rules are created to route any service message request or notification from consumer NFs to producer NFs.

Routing Options Selection

Any new 3GPP defined NFs, custom NF types, or custom NF services can be configured using the NFTypes-NFServices REST API. The apiName parameter is also configured with NFType and NFService REST API parameters to uniquely identify NFType and NFService pair. The apiName parameter is obtained from the service message request URI. For more information about the NFTypes-NFServices REST API, see "Configuring NFTypes-NFServices" in Oracle Communications Cloud Native Core, Service Communication Proxy REST Specification Guide.

SCP-Worker identifies the NF type and NF service of the request using the apiName REST API parameter from the received path URI [Request URI structure: {apiRoot}/<apiName>/<apiVersion>/<apiSpecificResourceUriPart>].

Sample NFTypes-NFServices REST API configuration

{
    "configName": "config1",
    "nfServiceData": {
        "nfType": "UDM",
        "serviceName": "nudm-uecm",
        "apiName": "apiName1",
        "serviceType": ["notification-message-service", "request-message-service"]
    },
    "createdTimestamp": "2024-04-24 14:50:56.0",
    "updatedTimestamp": "2024-04-24 14:50:56.0"
}

The existing Routing Options REST API has been enhanced to include the following REST API parameters, along with nfServiceName, to provide match criteria for selecting a routing option:

• messageType
• notificationType
• nfType
• method
• apiSpecificResourceUri
• consumerNfType

SCP-Worker extracts the above mentioned parameters from ingress message requests and matches them with the parameters of the Routing Options Config REST API configured at SCP to determine the best matched routing options. From the selected routing options, the routingConfigSetName parameter is obtained which points to the routing related parameters, such as maxRoutingAttempts, responseTimeout, and so on, to route message requests to producer NFs with the configured values obtained from routingConfigSetName. For more information about routing options and routing related parameters, see "Configuring Routing Options Config" and "Configuring Routing Config Set" in Oracle Communications Cloud Native Core, Service Communication Proxy REST Specification Guide.

Matching Routing Options Config Parameters of Ingress Message Request with Routing Options Config Parameters Configured at SCP

This subsection describes how the Routing Options Config parameters of ingress message requests are matched with Routing Options Config parameters configured at SCP to determine the best match. The following table provides a sample Routing Options Config parameter configuration received from the ingress message request:

Table 3-1 Routing Options Config Parameters in the Ingress Message Request

Parameter	Value
messageType	svc-request-message
notificationType	NA
nfType	PCF
nfServiceName	npcf-am-policy-control
method	POST
apiSpecificResourceUri	npcf-am-policy-control/v1/policies
consumerNfType	AMF

The following table provides a sample Routing Options Config configuration at SCP:

Table 3-2 Routing Options Config Parameters Configured at SCP

Parameter	Rule1	Rule2	Rule3	Rule4
messageType	svc-request-message	svc-request-message, notification-message	notification-message	svc-request-message
notificationType	*	*	NA	*
nfType	PCF	*	PCF	PCF
nfServiceName	npcf-am-policy-control	npcf-am-policy-control	*	npcf-smpolicycontrol
method	POST	*	POST	POST
apiSpecificResourceUri	*	npcf-am-policy-control/v1/policies	*	*
consumerNfType	*	*	*	*

The inference drawn from the above mentioned tables is as follows:

• All the parameters of Routing Options Config received from the message request are matched with the parameters configured for Rule1, Rule2, Rule3, and Rule4 at SCP.
• Rule1 is the best match because all its parameters match with the message request.
• Rule2 is the second best match due to mismatch of the values of nfType and consumerNfType parameters.
• Rule3 and Rule4 are not the best matches because values of messageType and nfServiceName parameters did not match.

Service Level Features Configuration

NF Service level features, such as Outlier Detection, Circuit Breaking, Canary Release, Next Hop SCP, Overload Control Information, and so on, can be configured, and rule names can be defined by matching NFType and nfServiceName parameters of ingress message requests with the parameters of the NF Service Feature Config REST API configured at SCP. From the matched records, the nfServiceConfigSetName parameter is obtained, which points to cbEnabled, odEnabled, cbRuleName, odRuleName, and so on, to configure service level features. For information about NF Service Feature Config and NF Service Feature Config Set REST APIs, see "Configuring NF Service Feature Config" and "Configuring NF Service Feature Config Set" in Oracle Communications Cloud Native Core, Service Communication Proxy REST Specification Guide.

The following is a sample NF Service Feature Config Set REST API configuration:

{
    "configName": "udm_nudm_uecm_config1",
    "nfServiceConfigSetData": {
      "defaultPriority": 1,
      "defaultCapacity": 65535,
      "altRoutingDnsSrvModeSupported": false,
      "loadBasedCongestionControlEnabled": true,
      "nfServiceLoadBasedCongestionControlCfg": "defaultRule",
      "cbEnabled": false,
      "cbRuleName": "defaultRule",
      "odEnabled": false,
      "odRuleName": "defaultRule",
      "ociEnabled": false,
      "ociRuleName": "defaultOciConfigRule",
      "canaryReleaseEnabled": false,
      "canaryReleaseConfigName": "default",
      "nextHopSCP": {
        "loadBasedCongestionControlEnabled": true,
        "nfServiceLoadBasedCongestionControlCfg": "defaultRuleForNextHopScp"
      },
      "nextHopSEPP": {
        "loadBasedCongestionControlEnabled": true,
        "nfServiceLoadBasedCongestionControlCfg": "defaultRuleForNextHopSepp"
      }
    },
 
    "createdTimestamp": "2024-05-02 02:26:30.0",
    "updatedTimestamp": "2024-05-02 02:26:30.0"
  }

Matching NF Service Feature Config Parameters of Ingress Message Request with NF Service Feature Config Parameters Configured at SCP

This subsection describes how NF Service Feature Config parameters of ingress message requests are matched with NF Service Feature Config parameters configured at SCP to determine the best match. The following table provides a sample NF Service Feature Config parameter configuration received from the ingress message request:

Table 3-3 NF Service Feature Config Parameters in the Ingress Message Request

Parameter	Value
NFType	PCF
nfServiceName	npcf-am-policy-control

The following table provides a sample NF Service Feature Config parameters configuration at SCP:

Table 3-4 NF Service Feature Config Parameters Configured at SCP

Parameter	RuleA	RuleB	RuleC	RuleD
NFType	PCF	*	PCF	PCF
nfServiceName	npcf-am-policy-control	npcf-am-policy-control	*	npcf-smpolicycontrol

The inference drawn from the above mentioned tables is as follows:

• All the parameters of NF Service Feature Config received from the message request are matched with the parameters configured for RuleA, RuleB, RuleC, and RuleD at SCP.
• RuleA is the best match because all its parameters match with the message request.
• RuleC is the second best match due to mismatch of the nfServiceName parameter value.
• RuleB and RuleD are not the best matches because the nfServiceName parameter value did not match.

Behavior of SCP when ignore_unknown_nfservice is Modified

The following scenarios describes behavior of SCP when NfType-NfService is added or removed and the ignore_unknown_nfservice parameter is enabled or disabled:

• ignore_unknown_nfservice is enabled and NfType-NfService is added: The existing NFProfiles are checked to detect the newly added NfType-NfService combinations. If any match is found, those NFProfiles are processed as reconfigured candidates, and routing rules are created. An on-demand audit is triggered for the new NFType from SCPC-Configuration.
• ignore_unknown_nfservice is enabled and NfType-NfService is removed: The existing NFProfiles are checked to detect the removed NfType-NfService. If any match is found, those NFProfiles are processed as reconfigured candidates, and the matching rule is removed only for the removed NfType-NfService.

  When the last NfService under NfType is removed and if NFType is also removed from SCP's configuration, then the matching NFProfiles are deregistered. When the profile level FQDN is present, the rule is updated to have only the default service (profile level rule). When the profile level FQDN is absent, deregister the instance for any such profile.

• ignore_unknown_nfservice is disabled and NfType-NfService is added: The rule is added through an on-demand audit for added NfType-NfService.
• ignore_unknown_nfservice is disabled and NfType-NfService is removed: Deregister NFInstances for any matching NFProfile containing the removed NfType-NfService.

Managing Support for 3GPP Defined NFs, Custom NFs, and Custom NF Services

Enable

By default, this feature is enabled at the time of SCP deployment.

Configure

You can configure this feature using REST APIs and CNC Console.

The following table describes the sequence of REST API and CNC Console configurations:

Table 3-5 Configuration Sequence

Configuration Sequence	Description	Sample Configuration
1	Configure new 3GPP defined NFs, custom NF types, or custom NF services in SCP. For more information, see: the "Configuring NFTypes-NFServices" REST API section in Oracle Communications Cloud Native Core, Service Communication Proxy REST Specification Guide. the Configuring NFTypes-NFServices section.	{ "configName": "udm_nudm-uecm", "nfServiceData": { "nfType": "UDM", "serviceName": "nudm-uecm", "apiName": "nudm-uecm", "serviceType": [ "notification-message-service", "request-message-service" ] } }
2	Define the topology source of the NFType by adding a new entry for this NFType or continue using the default entry if the Topology source is identical. For more information, see: the "Configuring NF Topology Groups" REST API section in Oracle Communications Cloud Native Core, Service Communication Proxy REST Specification Guide. the Configuring Topology Source Info section.	{ "nftype": "*", "topologysource": "NRF" }
3	Feature configuration for both NFType and nfServiceName is done in the following sequence: Configure feature set, such as Circuit Breaking, Outlier Detection, Egress Congestion Control, and Canary Release. Bind the feature configuration set with NFType and nfServiceName. Note: The above mentioned configurations were part of the RoutingOptions table in 24.3.0 and earlier releases.
3.1	Define Canary Release configuration as described in: the "Configuring CanaryRelease Options" REST API section in Oracle Communications Cloud Native Core, Service Communication Proxy REST Specification Guide. the Configuring Canary Release section.	{ "configName": "udm-uecm-cr-config", "canaryData": { "apiFullVersion": "1.0.0", "canaryTraffic": 100 } }
3.1.1	Define NF Service Feature Config Set for newly configured NFType and nfServiceName configurations as described in: the "Configuring NF Service Feature Config Set" REST API section in Oracle Communications Cloud Native Core, Service Communication Proxy REST Specification Guide. the Configuring NF Service Feature Config Set section.	{ "configName": "udm-uecm-feature-config-set", "nfServiceConfigSetData": { "defaultPriority": 1, "defaultCapacity": 65535, "altRoutingDnsSrvModeSupported": false, "loadBasedCongestionControlEnabled": false, "nfServiceLoadBasedCongestionControlCfg": "ss", "cbEnabled": false, "cbRuleName": "defaultRule", "odEnabled": false, "odRuleName": "defaultRule", "ociEnabled": false, "ociRuleName": "defaultOciConfigRule", "canaryReleaseEnabled": true, "canaryReleaseConfigName": "udm-uecm-cr-config", "nextHopSCP": { "loadBasedCongestionControlEnabled": true, "nfServiceLoadBasedCongestionControlCfg": "defaultRuleForNextHopScp" }, "nextHopSEPP": { "loadBasedCongestionControlEnabled": true, "nfServiceLoadBasedCongestionControlCfg": "defaultRuleForNextHopSepp" } } }
3.2	Bind the above mentioned NF Service Feature Config Set with newly configured NFType and nfServiceName as described in: the "Configuring NF Service Feature Config" REST API section in Oracle Communications Cloud Native Core, Service Communication Proxy REST Specification Guide. the Configuring NF Service Feature Config section.	{ "configName": "udm-uecm-feature-config", "nfServiceConfig": { "nfType": "udm", "nfServiceName": "nudm-uecm", "nfServiceConfigSetName": "udm-uecm-feature-config-set" } }
4	Routing Options REST API configuration is done in the following sequence to add new NF types and NF services: Configure Routing Options REST API parameters for different features in SCP. Bind the Routing Options Config Set with the match criteria. Note: The above mentioned configurations were part of the RoutingOptions table in 24.3.0 and earlier releases.
4.1	Define Routing Options Config Set as described in: the "Configuring Routing Config Set" REST API section in Oracle Communications Cloud Native Core, Service Communication Proxy REST Specification Guide. the Configuring Routing Config Set section.	{ "routingConfigSetName": "defaultRoutingConfigSet", "configureRoutingOptions": { "pod": { "maxRoutingAttempts": 1, "alternateRouting": true }, "alternateNFGroupRoutingOptions": { "mode": "NF_SET" }, "srv": { "name": "5g-sbi-notification", "maxRoutingAttempts": 3, "alternateRouting": true }, "totalTransactionLifetime": "6s", "reRouteConditionList": [ { "statusCode": "307" }, { "statusCode": "308" }, { "statusCode": "429" }, { "statusCode": "5xx" }, { "statusCode": "connectionError" }, { "statusCode": "timeout" } ], "responseTimeout": "1s", "exceptionErrorResponses": [ { "name": "Destination_Exhausted", "action": "Send_Answer", "error_code": 504, "error_response": "Gateway Timeout", "error_profile": "default_exception_error_destination_exhausted" }, { "name": "No_Response", "action": "Send_Answer", "error_code": 504, "error_response": "Gateway Timeout", "error_profile": "default_exception_error_no_response" }, { "name": "Connect_Failure", "action": "Send_Answer", "error_code": 504, "error_response": "Gateway Timeout", "error_profile": "default_exception_error_connect_failure" }, { "name": "No_Host", "action": "Send_Answer", "error_code": 400, "error_response": "Bad Request", "error_profile": "default_exception_error_no_host" }, { "name": "Insufficient_Time", "action": "Send_Answer", "error_code": 504, "error_response": "Gateway Timeout", "error_profile": "timeHdrInsufficientTimeErrorProfile" } ], "deploymentModel": "SITE_WIDE", "name": "5g-sbi-notification", "assignPreferredLocality": false, "overridePreferredLocality": false, "forwardRevisedPreferredLocality": false, "nextHopSEPP": { "totalTransactionLifetime": "7s", "responseTimeout": "4s", "service": { "maxRoutingAttempts": 2 }, "serviceEndpoint": { "maxRoutingAttempts": 1 }, "loadBasedCongestionControlEnabled": true, "nfServiceLoadBasedCongestionControlCfg": "defaultRuleForNextHopSepp", "reRouteConditionList": [ { "statusCode": "307" }, { "statusCode": "308" }, { "statusCode": "429" }, { "statusCode": "5xx" }, { "statusCode": "connectionError" }, { "statusCode": "timeout" } ], "exceptions": [ { "name": "No_Host", "action": "Send_Answer", "error_code": 400, "error_response": "Bad Request", "error_profile": "default_exception_error_no_host" }, { "name": "Destination_Exhausted", "action": "Send_Answer", "error_code": 504, "error_response": "Gateway Timeout", "error_profile": "default_exception_error_destination_exhausted" } ] }, "nextHopScp": { "totalTransactionLifetime": "7s", "responseTimeout": "4s", "reRouteConditionList": [{ "statusCode": "connectionError" } ], "service": { "maxRoutingAttempts": 2 }, "serviceEndpoint": { "maxRoutingAttempts": 1 }, "loadBasedCongestionControlEnabled": true, "nfServiceLoadBasedCongestionControlCfg": "defaultRuleForNextHopScp", "exceptions": [ { "name": "Destination_Exhausted", "action": "Send_Answer", "error_code": 504, "error_response": "Gateway Timeout", "error_profile": "default_exception_error_destination_exhausted" } ] } } }
4.2	Bind the Routing Options Config Set with match criteria: Config_One: This Routing Options is applied for any message request from UDM/numd-uecm. If there is any notification message from UDM/numd-uecm, the default Routing Option preconfigured for the notification message ("defaultSvcNotificationConfig") is applied. Config_Two: This Routing Option is applied for any service request message from UDM/numd-uecm with HTTP Method as PUT. Create Routing Options Config Set "ro_config_set_two" as mentioned in sequence 4.1. Config_Three: This Routing Option is applied for service message requests from UDM/numd-uecm with HTTP Method as PATCH. Create Routing Options Config Set "ro_config_set_three" as mentioned in Sequence 4.1 or any existing Routing Config Set if that satisfies the routing parameter configuration values. For more information about this configuration, see: the "Configuring Routing Options Config" REST API section in Oracle Communications Cloud Native Core, Service Communication Proxy REST Specification Guide. the Configuring Routing Options section.	Config_One { "configName": "ro_config_one", "routingOptionsConfigData": { "messageType": [ "svc-request-message" ], "notificationType": [], "nfType": "UDM", "nfServiceName": "nudm-uecm", "method": [ "*" ], "apiSpecificResourceUri": ".*", "consumerNFType": "*", "routingConfigSetName": "ro_config_set_one" } } Config_Two { "configName": "ro_config_two", "routingOptionsConfigData": { "messageType": [ "svc-request-message" ], "notificationType": [], "nfType": "UDM", "nfServiceName": "nudm-uecm", "method": [ "PUT" ], "apiSpecificResourceUri": ".*", "consumerNFType": "*", "routingConfigSetName": "ro_config_set_two" } } Config_Three { "configName": "ro_config_three", "routingOptionsConfigData": { "messageType": [ "svc-request-message" ], "notificationType": [], "nfType": "UDM", "nfServiceName": "nudm-uecm", "method": [ "PATCH" ], "apiSpecificResourceUri": ".*", "consumerNFType": "*", "routingConfigSetName": "ro_config_set_three" } }

Note:

To remove NFTypes-NFServices and related configurations from SCP, follow the steps mentioned in the above table in reverse order.

Observe

The ocscp_worker_routing_options_selected_total metric is added in the Metrics section.

Maintain

If you encounter alerts at system level, see the Alerts section for resolution steps.

In case the alerts persist, perform the following tasks:

1. Collect the logs: For information about how to collect logs, see Oracle Communications Cloud Native Core, Service Communication Proxy Troubleshooting Guide.
2. Raise a service request: For information about how to raise a service request, see My Oracle Support.

3.3 Error Response Enhancement

SCP used to send error responses to consumer NFs while processing message requests from or to consumer NFs. SCP used to generate these error responses in conditions, such as connection failure, timeout, an unknown host at SCP, and so on. The error responses generated by SCP comprised the error description in the detail parameter of ProblemDetails, which was inadequate to troubleshoot an error.

The following sample ProblemDetails displays various parameters:

{
"title":"Service Unavailable",
"status": "503",
"detail":"Currently Congested. Could not process request.",
"cause":"NF_CONGESTION"
}

With the enhanced error response mechanism, SCP sends additional information, such as server FQDN, NF service name, vendor name, and error ID, in the detail parameter of ProblemDetails to find the specific cause of the error. This helps in error identification and reduces troubleshooting time.

SCP has enhanced ProblemDetails for all the SCP generated 5G SBI message responses to identify the cause of the errors and troubleshoot them in the production environment.

The detail parameter in ProblemDetails includes information about problem details and error IDs in the following format, which is applicable only for SCP generated error responses:

<SCP FQDN>: <SCP specific problem detail>: <OSCP-scp error Id>

Where,

• <SCP FQDN> is the FQDN of SCP.
• <SCP specific problem detail> is the problem details.
• <OSCP-scp error Id> is the error ID with respect to SCP. It follows this format:

  OSCP-<Service code>-<Category>-<3 digit error code>

  .
• <Service code> is the microservice code that generates the error.
• <Category> is the error type for a particular microservice.
• <3 digit error code> is the error code prefixed by the alphabet E.

  For more information about supported error IDs, see SCP Error IDs.

Example of a sample error response:

ProblemDetails
 {
   "title": “Access Token Denied",
   "status": 403,
   "detail": "scp1.e.com: OAuth token denied for Server1-FQDN: OSCP-OAU-TKNRSP-E001",
   "cause": ACCESS_TOKEN_DENIED
}

SCP combines all the error responses from both internal and external sources, such as error responses generated by SCP and error responses received from producer NFs while performing alternate routing. SCP uses the enhanced_error_rsp attribute to combine all the error responses from both internal and external sources. For more information about enhanced_error_rsp, see Configuring Error Response Enhancement.

Note:

• When the enhanced_error_rsp parameter is disabled, ProblemDetails includes information about the last routing attempt made by SCP.
• When the enhanced_error_rsp parameter is enabled, ProblemDetails includes information about all the routing attempts made by SCP.

When SCP receives a message request from a consumer NF, SCP routes the request to the target producer NF. If the target producer NF is unavailable, SCP performs alternate routing to the next available producer NF. If SCP does not receive a success response from any producer NF after performing all the routing attempts, SCP generates an error response by updating the detail parameter with all the routing attempts made in the following format:

Latest attempt error string ; Status Code of previous attempt; Previous attempt error string

Sample detail format:

“detail” : “<Server-NF FQDN>: <NF Service>: <Application specific problem description>: <VendorNF-error-ID>; StatusCode; <SCP FQDN>: <Problem Description>: <OSCP-scp error Id>"

Where,

• <Server-NF FQDN> is the FQDN of the NF that sends this error response. For example, NRF-d5g.oracle.com.
• <NF Service> is the NF service name applicable for 3GPP service operation. For example, nnrf-disc.
• <Application specific problem description> is a short description of the error. For example, requesterNfType should be present.
• <VendorNF-error-ID> is the error code generated by any vendor NF. For example, ONRF-DIS-DISC-E0006.
• StatusCode is the HTTP status code for the previous routing attempt made by SCP. For example, 403.
• <SCP FQDN> is the FQDN of SCP. For example, ocscp-scp-worker.scpsvc.svc.cluster.local.
• <Problem Description> is the problem details. For example, Request cannot be routed due to rejection of access token request by NRF.
• <OSCP-scp error Id> is the ID of SCP. For example, OSCP-OAU-TKNRSP-E001.

The following sample ProblemDetails is based on the scenario when SCP has made two retry attempts to two different Producer NFs and both resulted in error responses (first attempt: 503 and second attempt: 400) returned by producer NFs. SCP returns the last error response (400) to the consumer NF:

ProblemDetails
 {
   "title": “Bad Request",
   "status": 400,
   "detail": "Server2-FQDN: [NF Service]:Application specific problem detail: VendorNF-App-Error ID ; 503; Server1-FQDN: Application specific problem detail: VendorNF-App-Error ID",
   "cause": INVALID_API
 }

The title, status, and cause parameters in ProblemDetails provide information about the last routing attempt made. The detail parameter provides information about all the routing attempts in the reverse order.

Note:

The error response sent by producer NFs is forwarded as it is to the consumer NF.

The detail parameter in ProblemDetails has a length restriction managed by the Error Detail Max Size field as described in Configuring Error Response Enhancement. The extra length leads to truncation of data in the detail parameter from the end.

The following sample ProblemDetails is based on the scenario when a timeout has occurred at SCP during inter SCP communication:

{
"title":"Timeout at SCP","status":504,
"detail":"ocscp-scp-worker.scpsvc.svc.cluster.local:Service Unavailable for pcf6svc.scpsvc.svc.cluster.local via scp61svc.scpsvc.svc.cluster.local:OSCP-WRK-ROUTE-E001;504;ocscp-scp-worker.scpsvc.svc.cluster.local:Service Unavailable for pcf6svc.scpsvc.svc.cluster.local via scp51svcxyz.scpsvc.svc.cluster.local due to UnknownHostException:OSCP-WRK-ROUTE-E002",
"cause":"TIMED_OUT_REQUEST"}

The cause parameter of ProblemDetails provides a reason for the occurrence of the error, such as overload, access token denied, timeout, and so on. The cause parameter in ProblemDetails is managed as defined in Section 5.2.7 of 3GPP TS 29.500 v16.6.0. If this section does not mention the cause value for any specific error condition, SCP leaves the value of this parameter empty.

The following sample ProblemDetails does not specify the cause of the error:

ProblemDetails
{
   "title": “Unauthorized",
   "status": 401,
   "detail": "SCP-FQDN: Application specific problem detail: SCP-App-Error ID",
   "cause": <empty>
 }

Managing Error Response Enhancement

Enable

This feature is enabled automatically at the time of SCP deployment. You can enable or disable this feature using the CNC Console as described in Configuring Error Response Enhancement.

Configure

You can configure this feature using REST APIs, CNC Console, and Helm.

• Configure using CNC Console: For information about CNC Console configurations, see Configuring Error Response Enhancement.
• Configure using REST APIs: For information about configuring REST APIs, see "Configuring SCP Features" in Oracle Communications Cloud Native Core, Service Communication Proxy REST Specification Guide.
• Configure using Helm: For information about configuring the SCP-Mediation microservice, see "SCP-Mediation Parameters" in Oracle Communications Cloud Native Core, Service Communication Proxy Installation, Upgrade, and Fault Recovery Guide.

Observe

The ocscp_worker_problemdetails_details_maxlengthexceeded_total metric is added in the Metrics section.

Maintain

If you encounter alerts at system level, see the Alerts section for resolution steps.

In case the alerts persist, perform the following tasks:

1. Collect the logs: For information about how to collect logs, see Oracle Communications Cloud Native Core, Service Communication Proxy Troubleshooting Guide.
2. Raise a service request: For information about how to raise a service request, see My Oracle Support.

3.3.1 SCP Error IDs

The following table describes error IDs supported by SCP while generating error responses:

Table 3-6 SCP-Worker Microservice Error IDs

Error Details	Description	Possible Causes and Corrective Actions
Issue: Header Validation Error ID: OSCP-WRK-HDRVLD-E001 HTTP Response Code: The HTTP status code is populated based on the configured value in the ErrorProfileConfiguration REST API OR 403	This ID indicates that the received CCA header failed validation.	The Cause field is set based on the configured value in the ErrorProfileConfiguration REST API (such as, errorProfile.getCause()). OR CCA_VERIFICATION_FAILURE Corrective Actions The Consumer NF should send a valid CCA header.
Issue: Header Validation Error ID: OSCP-WRK-HDRVLD-E002 HTTP Response Code: 400	This ID indicates that the received SBI request does not contain all mandatory discovery headers required for Delegated NF Discovery.	Mandatory discovery headers were not received, resulting in missing required headers. MANDATORY_QUERY_PARAM_MISSING Corrective Actions The Consumer NF must send all mandatory discovery headers in Model-D SBI messages.
Issue: Header Validation Error ID: OSCP-WRK-HDRVLD-E003 HTTP Response Code: 400	This ID indicates that the SBI request received has a malformed 3gpp-sbi-routing-binding header.	A malformed Routing Binding header was received: <malformed-hdr>. MANDATORY_IE_INCORRECT Corrective Actions The Consumer NF should send a valid 3gpp-sbi-routing-binding header.
Issue: Header Validation Error ID: OSCP-WRK-HDRVLD-E004 HTTP Response Code: 400	This ID indicates that the received SBI request has imperfectly formed target PLMN.	A malformed Target PLMN was received. MANDATORY_IE_INCORRECT Corrective Actions The Consumer NF should send a valid value for the target PLMN in the Inter-PLMN SBI message.
Issue: Header Validation Error ID: OSCP-WRK-HDRVLD-E005 HTTP Response Code: 400	This ID indicates that the received SBI request has a malformed default notification request.	A malformed default notification request was received. MANDATORY_IE_INCORRECT Corrective Actions Consumer NF should send a valid header and URI for the default notification request.
Issue: Header Validation Error ID: OSCP-WRK-HDRVLD-E006 HTTP Response Code: 400	This ID indicates that the message could not be routed due to the absence of expected headers required to select a producer for routing.	Insufficient routing details were received in the request. MANDATORY_IE_MISSING Corrective Actions Consumer NF should send the appropriate headers for the 5G SBI message to be routed. For a Model-C request, either the 3gpp-sbi-target-apiroot or 3gpp-sbi-routing-binding header should be present. For a Model-D request, the 3gpp-sbi-discovery-* headers should be present.
Issue: Header Validation Error ID: OSCP-WRK-HDRVLD-E007 HTTP Response Code: 400	This ID indicates that the message could not be routed due to an invalid host value received in the 3gpp-sbi-target-apiroot header.	An invalid host value was received in the 3gpp-sbi-target-apiroot header. MANDATORY_IE_INCORRECT Corrective Actions Consumer NF should send a valid value for the host in the 3gpp-sbi-target-apiroot header.
Issue: NF Selection Error ID: OSCP-WRK-NFSEL-E001 HTTP Response Code: 404	This ID indicates that the message could not be routed due to the absence of a learnt producer for the received 3gpp-sbi-routing-binding header and the absence of the 3gpp-sbi-target-apiroot header.	No routing rule was found for the received SBI request. Corrective Actions The Consumer NF should either send the 3gpp-sbi-target-apiroot header or a different binding value for the 3gpp-sbi-routing-binding header to route the SBI message.
Issue: NF Selection Error ID: OSCP-WRK-NFSEL-E002 HTTP Response Code: 400	This ID indicates that the message could not be routed due to the presence of an API version in the incoming SBI request that is not supported by the NF producer, as per the learned NF profile available at the SCP.	NF selection failed due to an API version mismatch. INVALID_API Corrective Actions The Consumer NF should send the correct API version in the SBI message URI that is supported by the Producer NF providing the NF service.
Issue: NF Selection Error ID: OSCP-WRK-NFSEL-E003 HTTP Response Code: 400	This error ID indicates that the message could not be routed due to unavailability of producer NFs with valid mcc-mnc host (found after Delegated NF Discovery). Therefore, it could not fetch SEPP details.	Next hop SEPP details were not found after NF discovery for <targetPlmn>. UNSPECIFIED_MSG_FAILURE Corrective Actions The Consumer NF should send a different value for the 3gpp-sbi-discovery-* headers to enable Inter-PLMN routing.
Issue: NF Selection Error ID: OSCP-WRK-NFSEL-E004 HttpStatusCode is populated based on the configured value for ocscp.http.routing_failure.no_host in RoutingOptions.	This ID indicates that the message could not be routed due to unavailability of serving SEPP for the inter-plmn. This is applicable for both Model-C and Model-D request routing models.	The Detail field is set based on the configured value in RoutingOptions against ocscp.http.routing_failure.no_host (for example, eer.getError_response()) Corrective Actions The Consumer NF should send a different value for the 3gpp-sbi-target-apiroot header to enable Inter-PLMN routing.
Issue: NF Selection Error ID: OSCP-WRK-NFSEL-E005 HttpStatusCode is populated based on the configured value in the ErrorProfileConfiguration REST API	This ID indicates that the message could not be routed because the selected producer is congested and there is no other eligible producer available for routing.	The Cause field is set based on the configured value in the ErrorProfileConfiguration REST API (for example, NFSvcLoadBasedErrorProfileConfiguration.getErrorCause()) Corrective Actions The Consumer NF should either send a different value for the headers to enable routing, or resend the request with the same header value once the load on the producer NF returns to a normal level.
Issue: NF Selection Error ID: OSCP-WRK-NFSEL-E006 HttpStatusCode is populated based on the configured value for ocscp.http.routing_failure.resource_exhausted in RoutingOptions, or it defaults to 500.	This ID indicates that the message could not be routed because eligible producers were proactively filtered out due to circuit breaking, outlier detection, egress rate limiting, and so on.	The Detail field is populated based on the configured value for ocscp.http.routing_failure.resource_exhausted in RoutingOptions or Destination unreachable due to exhausted destination search. Corrective Actions Consumer NF should either send a different value for the headers to enable routing, or resend the request with the same header value once the producer NF becomes healthy.
Issue: OCI Error ID: OSCP-WRK-OCI-E001 The HttpStatusCode is populated based on the configured value in the ErrorProfile Configuration, if available, or, from the value of ocscp.http.routing_failure.resource_exhausted in the RoutingOptions.	This ID indicates that the message could not be routed because the eligible producer was filtered out for OCI.	The Detail field is populated based on the configured value in the ErrorProfile Configuration, if available. Alternatively, it is populated using the value for ocscp.http.routing_failure.resource_exhausted in RoutingOptions. Corrective Actions The consumer NF should either send different header values to facilitate routing or resend the request with the same header values once the OCI reduction criteria are removed from the producer NF.
Issue: SCP-W Mediation Interface Errors Error ID: OSCP-WRK-MEDITN-E001 The HttpStatusCode is populated based on the value configured in the ErrorProfile, or 500.	This ID indicates that an error response was received by the SCP-Worker client from the Mediation service.	The Cause field is populated based on the value configured in AppRoutingOptionsConfig (for example, errorProfileConfig.getErrorCause()), or continue_processing. or Mediation client errors. Corrective Actions Ensure that the Mediation service is running and accessible.
Issue: SCP-W Mediation Interface Errors Error ID: OSCP-WRK-MEDITN-E005 HTTP Response Code: 500	This ID indicates that a decode failure occurred when processing the response received from the mediation.	Failure to decode the mediation message. or UNSPECIFIED_NF_FAILURE Corrective Actions Ensure that the appropriate rules are correctly configured in the Mediation.
Issue: Oauth Request Error ID: OSCP-WRK-OAUTH-E001 HTTP Response Code: 400	This ID indicates that the message could not be routed because the discovery headers, required to obtain the OAuth2 access token, are missing from the received request.	The request cannot be routed due to missing required OAuth2 access token information in the received request. MISSING_ACCESS_TOKEN_INFO Corrective Actions The consumer NF must include all mandatory headers required for the OAuth token request.
Issue: Oauth Request Error ID: OSCP-WRK-OAUTH-E002 HTTP Response Code: 400	This ID indicates that the request could not be routed because OAuth2 access token was not received from consumer NF.	The request cannot be routed because the OAuth2 access token was not received from the consumer NF. ACCESS_TOKEN_NOT_RECEIVED Corrective Actions The consumer NF must include the OAuth token when sending an SBI message.
Issue: Oauth Request Error ID: OSCP-WRK-OAUTH-E003 HTTP Response Code: 400	This ID indicates that the message could not be routed due to an invalid OAuth2 access token.	The request cannot be routed because the OAuth2 access token is invalid. INVALID_ACCESS_TOKEN Corrective Actions Ensure that the mandatory headers required to obtain the access token from the NRF are valid.
Issue: Oauth Request Error ID: OSCP-WRK-OAUTH-E004 HTTP Response Code: 403	This ID indicates that the message could not be routed due to OAuth2 access token being denied.	The request cannot be routed because the OAuth2 access token has been denied. ACCESS_TOKEN_DENIED Corrective Actions The consumer NF should send the SBI message with updated header values in order to request the access token.
Issue: Oauth Request Error ID: OSCP-WRK-OAUTH-E005 HTTP Response Code: 500	This ID indicates that the message could not be routed because the access token request from the SCP-worker to the SCP-NrfProxy-Oauth service timed out.	The access token request timed out from SCP-worker to the SCP-NrfProxy-OAuth service. UNSPECIFIED_NF_FAILURE Corrective Actions Ensure that the scp-nrfproxy-oauth service responds within the specified timeout limit.
Issue: Oauth Request Error ID: OSCP-WRK-OAUTH-E006 HTTP Response Code: 500	This ID indicates that the message could not be routed because the access token request from the SCP-worker to the SCP-NrfProxy-Oauth service encountered a transport error.	The access token request could not be processed due to a transport error between SCP-worker and the SCP-NrfProxy-OAuth service. UNSPECIFIED_NF_FAILURE Corrective Actions Ensure that the scp-nrfproxy-oauth service is running and accessible.
Issue: Oauth Request Error ID: OSCP-WRK-OAUTH-E008 HTTP Response Code: 500	This ID indicates that the message could not be routed because the access token request from SCP-worker to SCP-NrfProxy-Oauth encountered an exception other than TimeoutException, ConnectException, or UnknownHostException.	The access token request could not be processed due to unknown errors when connecting SCP-worker to the SCP-NrfProxy-OAuth service. UNSPECIFIED_NF_FAILURE Corrective Actions Ensure that the scp-nrfproxy-oauth service is running and accessible.
Issue: Oauth Request Error ID: OSCP-WRK-OAUTH-E009 HTTP Response Code: 500	This ID indicates that the message could not be routed because the access token request from SCP-Worker to SCP-NrfProxy-Oauth failed due to decoding exception in the access token error response body to the ProblemDetails instance.	A failure in decoding the response body into a ProblemDetails instance for the access token request. UNSPECIFIED_NF_FAILURE Corrective Actions Ensure that the scp-nrfproxy-oauth service returns an error response with the ProblemDetails information element (IE) in the response body.
Issue: Ingress Rate Limiting Error ID: OSCP-WRK-IRTLMT-E001 The HttpStatusCode is populated based on the configured value in the IngressRateLimiter REST API.	This ID indicates that the message could not be routed because the ingress rate was more than the allowed rate configured for the consumer as specified by the rules configured in the Ingress Rate Limiter REST API.	The Detail field is populated based on the configured value in the IngressRateLimiter REST API (for example, configData.getErrorResponse().getErrorResponse()).NF_CONGESTION_RISK Corrective Actions To address the issue, either reduce the ingress rate or increase the allowed rate in the Ingress Rate Limiter REST API configuration.
Issue: Egress Rate Limiting Error ID: OSCP-WRK-ERTLMT-E001 The HttpStatusCode is populated based on the configured value in the EgressRateLimiter REST API.	This ID indicates that the message could not be routed because the ingress rate was more than the allowed rate configured for the consumer as specified by the rules configured in the Egress Rate Limiter REST API.	The Detail field is populated based on the configured value in the EgressRateLimiter REST API (for example, streamInfo.getEgressRateLimitconfigData().getErrorResponse().getErrorResponse()). NF_CONGESTION_RISK Corrective Actions To address the issue, either reduce the ingress rate or increase the allowed rate in the Egress Rate Limiter REST API configuration.
Issue: Routing Error ID: OSCP-WRK-ROUTE-E001 The HttpStatusCode is populated based on the value configured in RoutingOptions.	This ID indicates that the message could not be routed because a TimeoutException was encountered at the Worker Client while reaching the upstream producer.	The Detail field is populated based on the configured value in RoutingOptions, along with the attempted NF FQDN or IP. TIMED_OUT_REQUEST Corrective Actions Ensure that the producer NF responds within the timeout limit at SCP, or increase the response timeout limit at SCP.
Issue: Routing Error ID: OSCP-WRK-ROUTE-E002 The HttpStatusCode is populated based on the value configured in RoutingOptions.	This ID indicates that the message could not be routed because WebClientRequestException was encountered at the Worker Client while reaching upstream the producer NF. The WebClient exception could be a timeout, a connection failure, or any other error from WebClient.	The Detail field is populated based on the configured value in RoutingOptions, including the attempted NF FQDN or IP address. TARGET_NF_NOT_REACHABLE Corrective Actions Ensure that the producer NF is running and accessible.
Issue: Routing Error ID: OSCP-WRK-ROUTE-E003 The HttpStatusCode is populated based on the value configured in RoutingOptions.	This ID indicates that the message could not be routed due to an exception other than WebClientResponseException, WebClientRequestException, or TimeoutException encountered at the Worker Client while reaching upstream the producer NF.	The Detail field is populated using the configured value in RoutingOptions, along with the attempted NF FQDN or IP address. TARGET_NF_NOT_REACHABLE Corrective Actions Ensure that the producer NF is running and accessible.
Issue: Routing Error ID: OSCP-WRK-ROUTE-E004 HTTP Response Code: 508	This ID indicates that the message could not be routed due to the presence of the SCP's self FQDN in the incoming SBI request's Via header. It also suggests that required headers or information, such as target-apiroot, binding headers, discovery headers, or any other necessary routing information, are missing from the request header.	A message loop has been detected. Corrective Actions Ensure that the SBI message does not contain the self FQDN in the "Via" header.
Issue: Routing Error ID: OSCP-WRK-ROUTE-E005 HTTP Response Code: 307 or 308 (as received from upstream NF)	This ID indicates that the SBI message has been redirected	A 3xx redirection was received from the upstream producer at `<producer fqdn or IP>`.
Issue: Routing Error ID: OSCP-WRK-ROUTE-E006 The HttpStatusCode is populated based on the error response received from the platform service mesh.	This ID indicates that the message could not be routed due to an error response received from the platform service mesh.	An error response was received from the platform service mesh at <service mesh fqdn or IP>. TARGET_NF_NOT_REACHABLE Corrective Actions Ensure that the producer NF is online and accessible, and confirm that the platform's service mesh is configured properly.
Issue: Routing Error ID: OSCP-WRK-ROUTE-E007 The HttpStatusCode is set based on the value configured in the RoutingOptions.	This ID indicates that the message could not be routed because the total transaction timeout for the service was reached.	The Detail field is populated based on the configured value in RoutingOptions, along with the attempted NF FQDN or IP address. TIMED_OUT_REQUEST Corrective Actions Ensure that the total transaction timeout is configured correctly and ensure there are no exceptions in the worker logs.
Issue: Routing Error ID: OSCP-WRK-ROUTE-E008 HTTP Response Code: HttpStatusCode is populated based on 'Insufficient_Time' exceptionErrorResponse configured in relevant Routing Config Set	This ID indicates that the message could not be routed due to a request timeout at SCP based on the timeout value received in the 3GPP-sbi-max-rsp-time header.	The request timed out at SCP based on the 3GPP-sbi-max-rsp-time header. TIMED_OUT_REQUEST Corrective Actions Ensure that the 3gpp-sbi-max-rsp-time value in the ingress SBI request is correct. Verify that the configured responseTimeout value is accurate. Confirm that SCP and NFs are properly time synchronized. Check if the producer NF responds within the time specified in the 3gpp-sbi-max-rsp-time header of the egress request.
Issue: Routing Error ID: OSCP-WRK-ROUTE-E009 HTTP Response Code: 500	This error indicates that SCP has received a nonstandard HTTP status code from a producer NF.	Unknown Status Code UNKNOWN_STATUS_CODE Corrective Actions No corrective actions available.
Issue: Delegated Discovery Error ID: OSCP-WRK-DELDISC-E001 HTTP Response Code: 500	This ID indicates that the delegated discovery request from SCP-Worker to SCP-NrfProxy failed due to TimeoutException.	The delegated discovery request timed out from SCP-worker to the SCP-NrfProxy service. UNSPECIFIED_NF_FAILURE Corrective Actions Ensure the scp-nrf-proxy service responds within the specified timeout limit.
Issue: Delegated Discovery Error ID: OSCP-WRK-DELDISC-E002 HTTP Response Code: 500	This ID indicates that the delegated discovery request from the SCP-worker to the SCP-NrfProxy service failed due to a WebClientRequestException.	Delegated discovery from SCP-worker to the SCP-NrfProxy service failed due to a transport error. UNSPECIFIED_NF_FAILURE Corrective Actions Ensure the scp-nrf-proxy service is running and accessible.
Issue: Delegated Discovery Error ID: OSCP-WRK-DELDISC-E004 HTTP Response Code: 500	This ID indicates that the delegated discovery request from SCP-Worker to SCP-NrfProxy failed due to an exception other than TimeoutException, ConnectException, or UnknownHostException.	Delegated discovery from SCP-worker to the SCP-NrfProxy service failed due to an unknown error. UNSPECIFIED_NF_FAILURE Corrective Actions Ensure the scp-nrf-proxy service is operational and reachable.
Issue: Delegated Discovery Error ID: OSCP-WRK-DELDISC-E005 HTTP Response Code: 500	This ID indicates that the delegated discovery request from SCP-Worker to SCP-NrfProxy failed due to decoding exception in the delegated NF discovery error response body to the ProblemDetails instance.	Failure in decoding the response body into a ProblemDetails instance for delegated discovery. UNSPECIFIED_NF_FAILURE Corrective Actions Ensures that the scp-nrf-proxy service returns an error response with a problemdetails information element in the response body.
Issue: Pod Overload Error ID: OSCP-WRK-OVERLD-E001 The HttpStatusCode is populated based on the configured value in the ErrorProfile REST API.	This ID indicates that the SCP-worker pod is overloaded due to CPU overload or pending transactions.	The Cause field is populated based on the configured value in the ErrorProfile REST API, using the method errorProfileConfiguration.getErrorCause(). Corrective Actions The Consumer NF should send an SBI message to the SCP once it has recovered from the overload situation (either due to CPU usage or pending transactions). This recovery can be verified by monitoring the relevant SCP alerts.
Issue: Internal Server Errors Error ID: OSCP-WRK-INTRNL-E001 HTTP Response Code: 500	This ID indicates that the message could not be routed due to downstream task queue being full.	The downstream task queue is full. UNSPECIFIED_NF_FAILURE Corrective Actions The Consumer NF may send the request after some time, once the SCP is able to process the message.
Issue: Internal Server Errors Error ID: OSCP-WRK-INTRNL-E002 HTTP Response Code: 500	This ID indicates that message could not be routed due to an exception caused failure of downstream asynchronous call.	The downstream asynchronous call failed. UNSPECIFIED_NF_FAILURE Corrective Actions Ensure that the request contains valid data to prevent any exceptions from occurring.
Issue: Internal Server Errors Error ID: OSCP-WRK-INTRNL-E003 HTTP Response Code: 500	This ID indicates that the message could not be routed due to an exception encountered on the request processing path.	An uncaught exception occurred on the request path, resulting in an internal server error. UNSPECIFIED_NF_FAILURE Corrective Actions Ensure that the request contains valid data to prevent any exceptions from occurring.
Issue: Internal Server Errors Error ID: OSCP-WRK-INTRNL-E004 HTTP Response Code: 500	This ID indicates that the message could not be routed due to an exception encountered on the response processing path.	An uncaught exception occurred on the response path, leading to an internal server error. UNSPECIFIED_NF_FAILURE Corrective Actions Ensure that the response contains valid data to prevent any exceptions from occurring.
Issue: Internal Server Errors Error ID: OSCP-WRK-INTRNL-E005 HTTP Response Code: 500	This ID indicates that the message could not be routed due to an exception encountered during SBI message processing.	Unable to process the message due to an unknown error. UNSPECIFIED_NF_FAILURE Corrective Actions Ensure that both the request and response contain valid data to prevent any exceptions from occurring.
Issue: Internal Server Errors Error ID: OSCP-WRK-INTRNL-E006 HTTP Response Code: The status code from the producer.	This ID indicates that error rsp(4xx or 5xx) is received from upstream, and the content-type is problem-json but the response body is not in problemdetails format.	Failure in decoding the response body into a ProblemDetails instance. Corrective Actions Ensure that the producer NF sends a valid ProblemDetails information element in the error response body when the Content-Type is application/problem+json.
Issue: Internal Server Errors Error ID: OSCP-WRK-INTRNL-E007 HTTP Response Code: The status code from the producer.	This ID indicates that error rsp(4xx or 5xx) is received from upstream, but the content-type is not problem-json, application/json, or any other allowed format.	The Content-Type of the error response is not application/problem+json. Corrective Actions Ensure that the producer NF sends a valid ProblemDetails information element in the error response body when the Content-Type is application/problem+json.
Issue: Internal Server Errors Error ID: OSCP-WRK-INTRNL-E008 HTTP Response Code: 500	This ID indicates that Live Object pool is exhausted.	The live object pool is exhausted. Corrective Actions Ensure the object pool can adjust to instance creation and reclamation requests, or increase the pool size as needed.

Table 3-7 SCP OAUTH MICROSERVICE

Error Details	Description	Possible Causes and Corrective Actions
Issue: Access Token Request Error ID: OSCP-OAU-TKNREQ-E001 HTTP Response Code: 500	This ID indicates that NrfProxy-OAuth timed out while attempting to connect to the Worker to initiate the OAuth request towards NRF.	The access token request timed out at the NrfProxy-OAuth service. UNSPECIFIED_NF_FAILURE Corrective Actions Ensure that the worker sends a response within the response timeout limit at the NrfProxy-OAuth service.
Issue: Access Token Request Error ID: OSCP-OAU-TKNREQ-E002 HTTP Response Code: 500	This ID indicates that NrfProxy-OAuth failed to connect to the Worker to initiate the OAuth request towards NRF due to a WebClientRequestException.	The access token request failed due to a transport error at the NrfProxy-OAuth service. UNSPECIFIED_NF_FAILURE Corrective Actions Ensure that the worker is up and reachable for successful communication.
Issue: Access Token Request Error ID: OSCP-OAU-TKNREQ-E004 HTTP Response Code: 500	This ID indicates that NrfProxy-OAuth failed to connect to the Worker to initiate the OAuth request towards NRF due to an exception other than TimeoutException, ConnectException, or UnknownHostException.	The access token request failed due to an unknown error at the NrfProxy-OAuth service. UNSPECIFIED_NF_FAILURE Corrective Actions Ensure that the worker is up and reachable.
Issue: Access Token Response Error ID: OSCP-OAU-TKNRSP-E001 HTTP Response Code: 403	This ID indicates that the NrfProxy-OAuth service received a 400 Bad Request with an AccessTokenError payload from NRF for the access token request, and SCP converts it to a 403 with a ProblemDetails information element.	The request cannot be routed due to the rejection of the access token request by the NRF. ACCESS_TOKEN_DENIED Corrective Actions Ensure that the Consumer NF sends the access token request with valid headers and parameters.
Issue: Access Token Response Error ID: OSCP-OAU-TKNRSP-E002 HTTP Response Code: 403	This ID indicates that the NrfProxy-OAuth service received a 200 response from NRF with an access token payload that is expired, and SCP converts it to a 403 with a ProblemDetails information element.	An expired access token was received from the NRF, with an expiration time of <exp-time>. ACCESS_TOKEN_DENIED Corrective Actions Ensure that valid request and response data is received by the NrfProxy-OAuth service for proper processing.
Issue: Access Token Response Error ID: OSCP-OAU-TKNRSP-E003 HTTP Response Code: 504	This ID indicates that the NrfProxy-OAuth service received a 307 response from NRF via the worker. SCP converts it to a 504, NRF_NOT_REACHABLE with `ProblemDetails` information element.	The SCP could not obtain access from the NRF. The access token request failed because NRFs were not reachable. NRF_NOT_REACHABLE Corrective Actions Ensure that the NRFs configured for the access token procedure are reachable.
Issue: Internal Server Errors Error ID: OSCP-OAU-INTRNL-E001 HTTP Response Code: 500	This ID indicates that an exception was encountered while processing the access token request.	An uncaught exception occurred on the server, leading to an internal server error. UNSPECIFIED_NF_FAILURE Corrective Actions Ensure that valid request and response data is received by the NrfProxy-OAuth service for correct processing.
Issue: Internal Server Errors Error ID: OSCP-OAU-INTRNL-E002 HTTP Response Code: 500	This ID indicates that a downstream thread in the NrfProxy-OAuth service is stuck while processing the access token request.	The downstream thread for the Nrf-Proxy-OAuth service experienced a timeout. UNSPECIFIED_NF_FAILURE Corrective Actions Ensure that the NrfProxy-OAuth service receives valid request and response data for proper processing.
Issue: Internal Server Errors Error ID: OSCP-OAU-INTRNL-E003 HTTP Response Code: 500	This ID indicates that an exception was encountered while processing the access token request or response.	The message could not be processed due to an unknown error. UNSPECIFIED_NF_FAILURE Corrective Actions Ensure that the NrfProxy-OAuth service receives valid request and response data to ensure correct processing and avoid errors.

Table 3-8 SCP NRF-PROXY MICROSERVICE

Error Details	Description	Possible Causes and Corrective Actions
Issue: Delegated Discovery Request Error ID: OSCP-NPY-DISREQ-E001 HTTP Response Code: 500	This ID indicates that the NrfProxy timed out while attempting to connect to the Worker to initiate the delegated discovery request towards NRF.	The delegated NF discovery request timed out at the NrfProxy service. UNSPECIFIED_NF_FAILURE Corrective Actions Ensure the worker sends a response within the specified response timeout limit.
Issue: Delegated Discovery Request Error ID: OSCP-NPY-DISREQ-E002 HTTP Response Code: 500	This ID indicates that the NrfProxy failed to connect to the Worker to initiate the delegated discovery request towards NRF due to a WebClientRequestException.	The delegated NF discovery request failed due to a transport error at the NrfProxy service. UNSPECIFIED_NF_FAILURE Corrective Actions Ensure that the worker is up and reachable.
Issue: Delegated Discovery Request Error ID: OSCP-NPY-DISREQ-E004 HTTP Response Code: 500	This ID indicates that the NrfProxy failed to connect to the Worker to initiate the delegated discovery request towards NRF due to an exception other than TimeoutException, ConnectException, or UnknownHostException.	The delegated NF discovery request failed due to an unknown error at the NrfProxy service. UNSPECIFIED_NF_FAILURE Corrective Actions Ensure that the worker is up and reachable.
Issue: Delegated Discovery Request Error ID: OSCP-NPY-DISREQ-E005 HTTP Response Code: 500	This ID indicates that the NrfProxy could not find the cache key, and as a result, was unable to process the delegated discovery request.	The cache key was not received from the SCP-Worker. UNSPECIFIED_NF_FAILURE Corrective Actions Ensure that the cache key is generated at the scp-worker and sent to the scp-nrfproxy service.
Issue: Delegated Discovery Request Error ID: OSCP-NPY-DISREQ-E006 HTTP Response Code: 500	This ID indicates that the NrfProxy could not find the cache for the delegated discovery response due to an exception encountered during JSON parsing.	An exception occurred while parsing the delegated NF discovery cached response into a JSON array. UNSPECIFIED_NF_FAILURE Corrective Actions Ensure that valid response data is cached in the scp- nrfproxy service.
Issue: Delegated Discovery Response Error ID: OSCP-NPY-DISRSP-E001 HTTP Response Code: 400	This ID indicates that an empty list of NF profiles was received in the delegated NF discovery response.	An empty list of NF profiles was received in the delegated NF discovery response. NF_DISCOVERY_FAILURE Corrective Actions The Consumer NF should send different values for the 3gpp-sbi-discovery-* headers to ensure that the delegated discovery returns a non-empty response.
Issue: Delegated Discovery Response Error ID: OSCP-NPY-DISRSP-E002 HTTP Response Code: 500	This ID indicates that no response was received for the delegated NF discovery.	No response was received for the delegated NF discovery. UNSPECIFIED_NF_FAILURE Corrective Actions Ensure that valid response data is received by the scp-nrfproxy service.
Error ID: OSCP-NPY-DISRSP-E003 HTTP Response Code: 500	This ID indicates that the NrfProxy failed to build the delegated NF discovery response.	Failed to build the delegated NF discovery response. UNSPECIFIED_NF_FAILURE Corrective Actions Ensure that valid response data is received by the scp-nrfproxy service for processing.
Issue: Delegated Discovery Response Error ID: OSCP-NPY-DISRSP-E004 HTTP Response Code: 500	This ID indicates that validation failed for the NF profiles received in the delegated NF discovery response.	Validation of the NF profiles received in the delegated NF discovery response failed. UNSPECIFIED_NF_FAILURE Corrective Actions Ensure that a response with valid NF profiles data is received by the scp-nrfproxy service.
Issue: Delegated Discovery Response Error ID: OSCP-NPY-DISRSP-E005 HTTP Response Code: 500	This ID indicates that there was a failure in deserializing the delegated NF discovery response.	Failed to deserialize the delegated NF discovery response. UNSPECIFIED_NF_FAILURE Corrective Actions Ensure that valid response data is properly cached in the scp-nrfproxy service.
Issue: Internal Server Errors Error ID: OSCP-NPY-INTRNL-E001 HTTP Response Code: 500	This ID indicates that the asynchronous call failed in the NrfProxy service for the delegated NF discovery request.	The asynchronous call for the delegated NF discovery request failed. UNSPECIFIED_NF_FAILURE Corrective Actions Ensure that valid response data is successfully received by the scp-nrfproxy service for processing.
Issue: Internal Server Errors Error ID: OSCP-NPY-INTRNL-E002 HTTP Response Code: 500	This ID indicates that the NrfProxy service failed to process the delegated NF discovery request due to an exception.	The NrfProxy service failed to process the delegated NF discovery request. UNSPECIFIED_NF_FAILURE Corrective Actions Ensure that valid response data is received by the scp-nrfproxy service and processed correctly.

Table 3-9 SCP NOTIFICATION MICROSERVICE

Error Details	Description	Possible Causes and Corrective Actions
Issue: Profile Validations Error ID: OSCP-NTF-PRFVLD-E001 HTTP Response Code: 400	This ID indicates that NF profile received from NRF is invalid as it contains both nfProfile and profileChange elements for NF_PROFILE_CHANGED event.	Problem Cause: The NF profile received from the NRF is invalid because it contains both nfProfile and profileChange for the NF_PROFILE_CHANGED event. INVALID_REQUEST_BODY Corrective Actions NRF should send only the profileChange attribute for the NF_PROFILE_CHANGED event.
Issue: Profile Validations Error ID: OSCP-NTF-PRFVLD-E002 HTTP Response Code: 400	This ID indicates that NF profile received from NRF is missing some mandatory parameters amongst event, nfType, nfStatus, and nfInstanceid.	The NF profile received from the NRF is missing some mandatory parameters, including event, nfType, nfStatus, and nfInstanceid. MANDATORY_IE_MISSING Corrective Actions NF profiles sent by NRF must include all mandatory fields.
Issue: Profile Validations Error ID: OSCP-NTF-PRFVLD-E003 HTTP Response Code: 400	This ID indicates that the NF profile received from NRF has an invalid JSON format.	The NF profile received from the NRF has an invalid JSON format. INVALID_MSG_FORMAT Corrective Actions NF profiles sent by NRF must contain valid JSON content.

3.4 Log Enhancement for 5G SBI Error Responses Generated by SCP

SCP generates error responses for all the routing attempts made on the producer NFs when SCP does not receive any response after performing alternate routing on all the available producer NFs. The ProblemDetails parameter of the error response contains the required pieces of information to find the cause of the error. For more information about error response enhancement, see Error Response Enhancement.

With the introduction of the Log Enhancement for 5G SBI Error Responses Generated by SCP feature, error response logs have been enhanced to include information, such as sender of the response and the User Equipment (UE) identifier received from the 3gpp-Sbi-Correlation-Info header, in the error logs. These details, along with the problem details, identify the cause of the error responses generated by SCP.

SCP generates error responses, and SCP-Worker generates error logs by adding additional attributes to the logs during the following scenarios:

• When there is no eligible producer NF available to route the message request.
• When all the routing attempts lead to request timeouts.
• When connection between SCP and producer NFs fails.
• When SCP disqualifies producer NFs because the Overload-Reduction-Metric value is less than 100.
• When SCP returns bad requests to consumer NFs due to discovery failure.
• When SCP returns error responses to consumer NF due to Access Token denial by NRF for a producer NF.

SCP-Worker adds additional log attributes, such as errorStatus, errorTitle, errorDetails, errorCause, and sender, to error logs to identify the cause of the error responses generated by SCP for WARN level logs. These attributes can be used to refine the search option to identify the cause of an error by analyzing any log on Kibana and Opensearch. These attributes are managed by the additional_logging REST API parameter as described in "Configuring SCP Features" in Oracle Communications Cloud Native Core, Service Communication Proxy REST Specification Guide. By default, additional_logging is disabled. For more information about additional log attributes, see Table 3-10.

Note:

• This feature is not applicable if the log level is updated from the default WARN level to ERROR.
• The additional log attributes are added only to SCP-Worker logs.
• When CPU usage of SCP reaches Critical state, additional logging is not performed.
• The errorDetails attribute provides a summary of all the routing attempts made by SCP, whether the Error Response Enhancement feature is enabled or disabled.
• When additional_logging is enabled, SCP logs might spillover because repeated errors could be logged, leading to spillover and loss of other log information from other transactions. It is recommended to use log rate control or enable this feature only when required.

The following sample log contains additional attributes present in the error logs generated by SCP:

{"errorStatus":"504",
 
  "errorTitle":"Transport failure at SCP",
 
  "errorDetails":"ocscp-scp-worker.scpsvc.svc.cluster.local:Gateway Timeout for smf12svc.scpsvc.svc.cluster.local due to UnknownHostException:OSCP-WRK-ROUTE-E002",
 
  "errorCause":"TARGET_NF_NOT_REACHABLE",
 
  "sender":"SCP-ocscp-scp-worker.scpsvc.svc.cluster.local"}

Subscriber ID (UE identifier) is added to all logs, irrespective of the log generated by SCP or any other component. It is derived from the subscriberId attribute of the log. The value of subscriberId is obtained from the 3gpp-Sbi-Correlation-Info header if it is present in the message request received from the consumer NF. Otherwise, subscriberId is automatically removed from the logs. For more information about 3gpp-Sbi-Correlation-Info, see 3GPP TS 29.500 v17.12.0.

The subscriberId attribute is managed by the log_subscriber_info REST API parameter as described in "Configuring SCP Features" in Oracle Communications Cloud Native Core, Service Communication Proxy REST Specification Guide. subscriberId is appended to all the SCP logs for that particular transaction if the 3gpp-Sbi-Correlation-Info header is present in the message request and log_subscriber_info is enabled.

Note:

• subscriberId is applicable only for SCP-Worker, SCP-nrfProxy, and SCP-nrfproxy-oauth logs.
• Any sensitive information in the form of a UE identifier (ex. SUPI) is published when log_subscriber_info is enabled. It is not recommended to enable this feature. You can secure the logs accordingly in the deployment environment when this feature is enabled.

Sample Logs

When both log_subscriber_info and additional_logging parameters are enabled:

{"instant":{"epochSecond":1716451983,"nanoOfSecond":70825540},
 "thread":"scp-wk-nrfproxy-downstream-19",
 "level":"WARN",
 "loggerName":"com.oracle.cgbu.cne.scp.router.common.logging.WorkerLogBuilder",
 "message":"Category: ROUTING, Event: ROUTING_MISCELLANEOUS, Details: SCP Generated Error Details in Final Response to Consumer NF",
 "endOfBatch":false,"loggerFqcn":"org.apache.logging.log4j.spi.AbstractLogger","threadId":927,"threadPriority":5,
 "messageId":"a5322c9c-f110-4b77-8665-ec54ee76dee4","scpFqdn":"ocscp-scp-worker.scpsvc.svc.cluster.local","scpAuthority":"",
 "messageTimestamp":"2024-05-23T08:13:03.070+0000","application":"ocscp","microservice":"scp-worker","engVersion":"24.2.0-OCSPF-23002-elog-240522144106-181a1bc6",
 "mktgVersion":"24.2.0.0.0","vendor":"oracle","namespace":"scpsvc","node":"100.77.4.253",
 "pod":"ocscp-scp-worker-6c5b88b795-xlqgj","subsystem":"router","instanceType":"prod","processId":"1",
 "subscriberId": "imsi-345012123123123",
 "errorStatus":"500",
 "errorTitle":"Internal Server Error",
 "errorDetails":"ocscp-scp-worker.scpsvc.svc.cluster.local:Access Token request failed due to transport error at NrfProxy-Oauth service:OSCP-OAU-TKNREQ-E002",
 "errorCause":"UNSPECIFIED_NF_FAILURE",
 "sender":"SCP-ocscp-scp-worker.scpsvc.svc.cluster.local"}

When log_subscriber_info is disabled, but additional_logging is enabled:

{"instant":{"epochSecond":1716451983,"nanoOfSecond":70825540},
 "thread":"scp-wk-nrfproxy-downstream-19",
 "level":"WARN",
 "loggerName":"com.oracle.cgbu.cne.scp.router.common.logging.WorkerLogBuilder",
 "message":"Category: ROUTING, Event: ROUTING_MISCELLANEOUS, Details: SCP Generated Error Details in Final Response to Consumer NF",
 "endOfBatch":false,"loggerFqcn":"org.apache.logging.log4j.spi.AbstractLogger","threadId":927,"threadPriority":5,
 "messageId":"a5322c9c-f110-4b77-8665-ec54ee76dee4","scpFqdn":"ocscp-scp-worker.scpsvc.svc.cluster.local","scpAuthority":"",
 "messageTimestamp":"2024-05-23T08:13:03.070+0000","application":"ocscp","microservice":"scp-worker","engVersion":"24.2.0-OCSPF-23002-elog-240522144106-181a1bc6",
 "mktgVersion":"24.2.0.0.0","vendor":"oracle","namespace":"scpsvc","node":"100.77.4.253",
 "pod":"ocscp-scp-worker-6c5b88b795-xlqgj","subsystem":"router","instanceType":"prod","processId":"1",
 "errorStatus":"500",
 "errorTitle":"Internal Server Error",
 "errorDetails":"ocscp-scp-worker.scpsvc.svc.cluster.local:Access Token request failed due to transport error at NrfProxy-Oauth service:OSCP-OAU-TKNREQ-E002",
 "errorCause":"UNSPECIFIED_NF_FAILURE",
 "sender":"SCP-ocscp-scp-worker.scpsvc.svc.cluster.local"}

Additional Log Attributes

The following table describes additional log attributes that are appended to the error logs:

Table 3-10 Additional Log Attributes

Attribute	Description
subscriberId	Indicates the User Equipment (UE) identifier and the value of this parameter is determined from the 3gpp-Sbi-Correlation-Info header in the message request. Example: "subscriberId": "imsi-345012123123123" Note: The value of subscriberId cannot be modified by SCP.
sender	This is SCP FQDN. Example: "sender":"SCP-ocscp-scp-worker.scpsvc.svc.cluster.local"
errorStatus	Indicates the status code of the error response. Example: "errorStatus":"500"
errorTitle	Indicates the error title of the error response. Example: "errorTitle":"Internal Server Error"
errorDetails	Indicates the error details of the error response. Example: "errorDetails":"ocscp-scp-worker.scpsvc.svc.cluster.local:Access Token request failed due to transport error at NrfProxy-Oauth service:OSCP-OAU-TKNREQ-E002"
errorCause	Indicates the error cause of the error response. Example: "errorCause":"UNSPECIFIED_NF_FAILURE"

Managing Log Enhancements

Enable

This feature is disabled at the time of SCP deployment. You can enable or disable this feature using the CNC Console as described in Configuring the Log Enhancement Feature.

Configure

You can configure this feature using CNC Console and REST APIs.

• Configure using CNC Console: For information about CNC Console configurations, see Configuring the Log Enhancement Feature.
• Configure using REST APIs: For information about configuring additional_logging and log_subscriber_info REST API parameters, see "Configuring SCP Features" in Oracle Communications Cloud Native Core, Service Communication Proxy REST Specification Guide.

Observe

There are no specific metrics and alerts required for this feature.

Maintain

If you encounter alerts at system level, see the Alerts section for resolution steps.

In case the alerts persist, perform the following tasks:

1. Collect the logs: For information about how to collect logs, see Oracle Communications Cloud Native Core, Service Communication Proxy Troubleshooting Guide.
2. Raise a service request: For information about how to raise a service request, see My Oracle Support.

3.5 NFProfile Processing Enhancements

In the previous releases, SCP did not support custom NF services. When SCP receives a notification from NRF about an NF profile that has 3GPP-defined supported NF services along with custom, unknown, or unsupported NF services, it will reject the whole NF profile. Therefore, routing rules were not generated for 3GPP-defined supported NF services when a custom, unknown, or unsupported NF service was present in the NF profile.

With this enhancement, whenever SCP receives a notification regarding an NF profile that includes 3GPP-defined supported NF services, custom, unknown, or unsupported NF services, SCP ignores the presence of custom, unknown, or unsupported NF services within the NF profile. Routing rules are generated by SCP for 3GPP-defined SCP supported NF services that are present in the NF profile. Consequently, SCP enhanced the process of handling NF profiles by streamlining the routing process and ensuring efficient and reliable communication between NFs.

SCP can receive custom, unknown, or unsupported NF services in the NF profile for 3GPP-defined NF types in the following cases:

• Notification from NRF: This is within the scope of this feature.
• Audit functionality using NRF management or discovery service: This is within the scope of this feature.
• Response for delegated discovery from NRF: This is outside the scope of this feature.

Figure 3-1 Call Flow of NFProfile Processing

1. SCP receives a notification with an NF profile including 3GPP-defined supported NF services, custom, unknown, or unsupported NF services.
2. If the feature is enabled, then SCP creates routing rules for the 3GPP-defined supported NF services and ignores the custom, unknown, or unsupported NF services present in the NF profile.
3. SCP stores the NF profile in the database.
4. If the feature is disabled, then SCP does not process that NF profile and no routing rules will be created for that NF profile.

   This call flow ensures that SCP appropriately handles notifications and routing rules procedures with supported NF services while disregarding unsupported services.

Managing NFProfile Processing Enhancements

Enable

You can enable this feature by setting the ignore_unknown_nfservice parameter to true. For more information, see Configuring Enhanced NFProfile Processing

Configure

You can enable this feature using using the CNC Console or REST API.

• Configure using CNC Console: For more information about CNC Console configurations, see Configuring Enhanced NFProfile Processing.
• Configure using REST API: For information about REST API configurations, see "Configuring SCP Features" in Oracle Communications Cloud Native Core, Service Communication Proxy REST Specification Guide.

Observe

• Added the ocscp_ignore_unknown_service_total metric in the SCP Metrics section.
• Added the SCPIgnoreUnknownService in the Alerts section.

Maintain

If you encounter alerts at system level, see the Alerts section for resolution steps.

In case the alerts persist, perform the following tasks:

1. Collect the logs: For information about how to collect logs, see Oracle Communications Cloud Native Core, Service Communication Proxy Troubleshooting Guide.
2. Raise a service request: For information about how to raise a service request, see My Oracle Support.

3.6 Support for cnDBTier APIs in CNC Console

With the implementation of this feature, cnDBTier APIs are integrated into the CNC Console, and SCP users can view specific cnDBTier APIs, such as checking the cnDBTier version, status of cnDBTier clusters, and georeplication status on the CNC Console.

The following cnDBTier APIs are read only and can be viewed in CNC Console:

• Backup List: This API displays the details of stored backups, such as the ID and size of the backup.
• cnDBTier version: This API displays the cnDBTier version.
• Database Statistics Report: This API displays the number of available database.
• Georeplication Recovery: This API provides the recovery status of georeplication for the cnDBTier cluster:
  • Update Cluster As Failed: This API is used to mark a disrupted cluster as failed.
  • Start Georeplication Recovery: This API is used to start the georeplication recovery process.
  • Georeplication Recovery Status: This API is used to monitor the recovery status of georeplication for both FAILED and ACTIVE cnDBTier sites.
• Georeplication Status:
  • Real Time Overall Replication Status: This API displays the overall replication status in multisite deployments. For example, in a four-site deployment, it provides the replication status between the following sites: site1-site2, site1-site3, site1-site4, site2-site3, site2-site4, and site2-site1. This is applicable for all other sites.
  • Site Specific Real Time Replication Status: This API displays the site-specific replication status.
• HeartBeat Status: This API displays the connectivity status between the local site and the remote site name to which SCP is connected.
• Local Cluster Status: This API displays the status of the local cluster.
• On-Demand Backup: This API displays the status of initiated on-demand backups.
• cnDBTier Health: This API displays the health status of the following services:
  • Replication Health Status: This API displays the health status of the replication service. It checks the following:
    • if the replication service is up or not
    • if the replication service can connect to database or not
  • Monitor Health Status: This API displays the health status of the monitor service. It checks the following:
    • if the monitor service is up or not
    • if the service can connect to database or not
    • if the metrics are fetched or not (the metrics are fetched when the service is up and vice versa)
  • NDB Health Status: This API displays the health status of the NDB service pods like (data pods, sql pods, app-my-sql pods, mgmt pods). It checks the following:
    • if the pod is connected to PVC or not
    • if the pods status is up or not

    Note:

    PVC Health Status attribute is set to NA when some of the database pods are not connected to the PVC.
  • Backup Manager Health Status: This API displays the health status of the backup manager service. It checks the following:
    • if the backup manager service is up or not
    • if the service can connect to database or not

Managing cnDBTier APIs at CNC Console

Enable

This feature is enabled automatically when cnDBTier is configured as an instance during the CNC Console deployment. For more information about integrating cnDBTier APIs in CNC Console, see Oracle Communications Cloud Native Core, cnDBTier User Guide.

Configure

You can view cnDBTier APIs at CNC Console in the Viewing cnDBTier APIs in CNC Console section.

Maintain

If you encounter alerts at the system level, see the Alerts section for resolution steps.

In case the alerts persist, perform the following tasks:

1. Collect the logs: For information about how to collect logs, see Oracle Communications Cloud Native Core, Service Communication Proxy Troubleshooting Guide.
2. Raise a service request: For information about how to raise a service request, see My Oracle Support.

3.7 NRF Configuration Using DNS SRV Resolution

Currently, SCP supports the static configuration (helm configuration) of NRF profiles from the custom-values.yaml file and uses them for registration, subscription, discovery, and audit.

With the introduction of this feature, SCP supports the configuration (RESTful) of NRF Service (SRV) FQDN at SCP. SCP uses this Domain Name System Service (DNS) SRV Resource record, known as Service Proto Name (SPN), to query the DNS server to locate the actual target NRF FQDNS (DNS SRV NRF FQDN). Thus, the user can configure primary (mandatory), secondary, and tertiary NRFs based on their priority and weights from different regions in the DNS server against a NRF SRV FQDN.

During migration, SCP deregisters and unsubscribes from static NRFs to update the NRF details stored statically at SCP with DNS SRV NRFs. Hence, it creates new rules for DNS SRV NRFs and deletes old static NRF rules. SCP instructs Audit microservice to perform an on-demand audit. The user can configure the DNS SRV and update all the data in the database for subscription, registration, discovery, and audit services. Configuration of different NRF SRV FQDN's with duplicate nfsetIds is not allowed. SCP allows users to configure multiple nfsetIDs, provided they are unique, but SCP will support only the 0th nfsetID.

To use the same NFInstance ID from the static NRF config, the following conditions must be met:

• The NF set ID should match
• NF service counts should match, and NF service FQDNs should also match

Hence, if the LCI comes from NRF against a different nfinstanceID, SCP will ignore the received LCI header as unknown.

NRFs are configured on the DNS server or stub against the NRF SRV FQDN. These NRFs should have PLMN IDs in the FQDN value matching the serving PLMN IDs of SCP. Setting the isInterPLMNfqdn to true will enable InterPLMN request routing coming from a foreign PLMN to SUT SCP. SCP will be able to perform intra-PLMN routing to local NRFs based on the interplmnFQDN. If isInterPLMNfqdn is set to false, the above-mentioned routing will not be performed if the Inter-PLMN request for Intra-PLMN routing is received with only 3gpp-Sbi-Target-apiRoot and no additional information, such as a routing binding header.

Note:

SCP never performs InterPLMN routing through SEPP for NRF as a destination, which is learned through DNSSRV.

Note:

To avoid the loss of service, it is recommended that the user configure the same static target FQDN and NFSetID in the DNS SRV configuration, which are configured for Support forModel D and Support for OAuth2.0 Feature.

If the same target NRF FQDN is detected against different NRF SRV FQDNs, the ocscp_configuration_dnssrv_nrf_duplicate_target_detected metric is pegged, where the value of nrfSrvFqdn indicates the NRF SRV FQDN against which a duplicate target NRF is detected.

Managing NRF Configuration using DNS SRV Resolution

Enable

During deployment:

Set the enableDnsBasedNrfBootStrapInfoFeature to true and provide the NRF SRV Config under the nrfSrvConfiguration field of the deployment file to enable the DNS SRV NRF feature during fresh deployment.

Sample of changes in deployment file:

#------------NRF Bootstrapping based on DNS SRV------------#
#Enable/Disable nrf_bootstrap_info feature
  enableDnsBasedNrfBootStrapInfoFeature : false
  deRegisterScpDuringMigration: false

#Preferred DNSSRV NrfSetId to be used for on demand discovery when nrf_bootstrap_info feature is enabled during deployment
  preferredDNSSRVNrfSetIdForOnDemandDiscovery: ["setnrfl1.nrfset.5gc.mnc012.mcc345"]

#Configure NRF Configuration using DNS SRV Resolution when the nrf_bootstrap_info feature is enabled.
  nrfSrvConfiguration:
  - nrfSrvFqdn: nrf1svc.scpsvc.svc.cluster.local
    data:
      "v1":
          nfSetIdList:
          - "setnrfl1.nrfset.5gc.mnc012.mcc345"
          #plmnList:
          # - mcc: 330
          #   mnc: 143
          performSubscription: true
          performAudit: true
          registerScp: true
          scheme: http
          #apiPrefix: USEast
          versions:
           - apiVersionInUri: v1
             apiFullVersion: 1.0.0
          serviceNames:
          - nnrf-nfm
          - nnrf-disc
          - nnrf-oauth2
          isInterPlmnFqdn: false

For more information, refer Oracle Communications Cloud Native Core, Service Communication Proxy Installation, Upgrade, and Fault Recovery Guide.

By default, this feature is disabled. You can use the nrf_bootstrap_info option to enable or disable NRF configuration using the DNS SRV resolution feature and its configurations as described in Configuring NRF SRV.

Note:

DNS SRV alternate routing feature should be enabled to enable NRF Configuration using DNS SRV Resolution feature.

Configure

You can configure this feature using REST API and the CNC Console.

• Configure using CNC Console: For information about configuring this feature, see the Configuring NRF SRV and Mapping NFInstanceId and ServiceInstanceId sections. To view the runtime status of NRF migration task, see the Viewing SCP Feature Status Status section.
• Configure using REST API:

  You can configure this feature using REST APIs as described in "Configuring SCP Features", "SCP NRF SRV Configuration", and "SCP NRF FQDN InstanceId Mapping". You can view the runtime status of NRF migration task in the "Viewing SCP Feature Status" section in Oracle Communications Cloud Native Core, Service Communication Proxy REST Specification Guide.

Observe

The following metrics are added in the Metrics section:

• ocscp_configuration_dnssrv_nrf_non_migration_task_failure_count_total
• ocscp_configuration_dnssrv_nrf_non_migration_task_success_count_total
• ocscp_configuration_dnssrv_nrf_non_migration_task_failure
• ocscp_configuration_dnssrv_nrf_migration_task_failure
• ocscp_configuration_dnssrv_nrf_duplicate_target_detected

The following alerts are added in the Alerts section:

• SCPDNSSRVNRFMigrationTaskFailure
• SCPDNSSRVNRFNonMigrationTaskFailure
• SCPDNSSRVNRFDuplicateTargetDetected

Maintain

If you encounter alerts at the system level, see the Alerts section for resolution steps.

In case the alerts persist, perform the following tasks:

1. Collect the logs: For information about how to collect logs, see Oracle Communications Cloud Native Core, Service Communication Proxy Troubleshooting Guide.
2. Raise a service request: For information about how to raise a service request, see My Oracle Support.

3.8 Support for Kubernetes Resources

This section provides you with information about the Network Policies feature and the Pod Disruption Budget feature.

3.8.1 Dual Stack Support

Using the dual stack mechanism, applications or NFs can establish connections with pods and services in a Kubernetes cluster using IPv4 or IPv6 or both simultaneously. Dual stack provides:

• coexistence strategy that allows hosts to reach IPv4 and IPv6 simultaneously.
• IPv4 and IPv6 allocation to the Kubernetes clusters during cluster creation. This allocation is applicable for all the Kubernetes resources unless explicitly specified during the cluster creation.

SCP can be deployed on CNE that supports dual stack networking. In case both IPv4 and IPv6 addresses are present in the IPADDRESS route group REST API configuration or NFService's IPEndpoint, the load balancing mechanism is used to route the traffic between IPv4 and IPv6. For more information about IPADDRESS, see "Configuring Route Groups" in Oracle Communications Cloud Native Core, Service Communication Proxy REST Specification Guide.

Managing Dual Stack Support

Configuring IpFamilyPolicy and IpFamilies

1. To configure IpFamilyPolicy and IpFamilies, the following Helm parameters can be configured:
   • serviceIpFamilyPolicy.scpcAudit
   • serviceIpFamilyPolicy.scpcConfiguration
   • serviceIpFamilyPolicy.scpcSubscription
   • serviceIpFamilyPolicy.scpcNotification
   • serviceIpFamilyPolicy.scpcAlternateResolution
   • serviceIpFamilyPolicy.scpCache
   • serviceIpFamilyPolicy.scpNrfProxyOauth
   • serviceIpFamilyPolicy.scpNrfproxy
   • serviceIpFamilyPolicy.scpWorker
   • serviceIpFamilyPolicy.scpMediation
   • serviceIpFamilyPolicy.scpMediationTest
   • serviceIpFamilyPolicy.scpcLoadManager
   • serviceIpFamilies.scpcAudit
   • serviceIpFamilies.scpcConfiguration
   • serviceIpFamilies.scpcSubscription
   • serviceIpFamilies.scpcNotification
   • serviceIpFamilies.scpcAlternateResolution
   • serviceIpFamilies.scpCache
   • serviceIpFamilies.scpNrfProxyOauth
   • serviceIpFamilies.scpNrfproxy
   • serviceIpFamilies.scpWorker
   • serviceIpFamilies.scpMediation
   • serviceIpFamilies.scpMediationTest
   • serviceIpFamilies.scpcLoadManager
   • serviceSpecifications.workerServices.ipFamilyPolicy
   • serviceSpecifications.workerServices.ipFamilies
   • serviceSpecifications.workerServices.publicSignalingIPv6
   • serviceSpecifications.workerServices.publicSignalingIPv6Specified
   • scpPreferEgressTrafficOnIPv6
2. To configure IPv4 or IPv6 used for constructing callback URI for NF profile notification from NRF, use the following parameter:

   serviceSpecifications.scpSubscriptionInfo.ip

3. To configure NRF profiles with ipEndpoints having either IPv4 or IPv6 or both IPv4 and IPv6, use the following parameter:

   nrfProfiles.nfServices.ipEndPoints

For more information about above mentioned Helm parameters, see Oracle Communications Cloud Native Core, Service Communication Proxy Installation, Upgrade, and Fault Recovery Guide.

Observe

The ocscp_worker_5gsbi_upstream_connect_failure_total metric is added in the Metrics section.

Maintain

If you encounter alerts at the system level, see the Alerts section for resolution steps.

In case the alerts persist, perform the following tasks:

1. Collect the logs: For information about how to collect logs, see Oracle Communications Cloud Native Core, Service Communication Proxy Troubleshooting Guide.
2. Raise a service request: For information about how to raise a service request, see My Oracle Support.

3.8.2 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 deployment can be contacted by any other pods in the Kubernetes cluster without any restrictions. Now, Network Policy provides namespace-level isolation, which allows secured communications to and from SCP 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, SCP internal microservices cannot be contacted directly by any other pods; The scp-workers in the data plane have special privileges to communicate with other NFs. Pods in the control plane can communicate with other pods only within their namespace.

Managing Support for Network Policies

Enable

To use this feature, network policies need to be applied to the namespace wherein SCP is applied.

Configure

You can configure this feature using Helm. For information about Configuring Network Policies for SCP Deployment, see Oracle Communications Cloud Native Core, Cloud Native Environment Installation, Upgrade, and Fault Recovery Guide.

Observe

There are no specific metrics and alerts required for the Network Policy feature.

3.8.3 Pod Disruption Budget

PodDisruptionBudget (PDB) is a Kubernetes resource that helps to achieve the high availability of scalable application services in voluntary disruptions performed by cluster administrators to manage the cluster nodes. It is defined for highly available and scalable SCP services such as scp-worker, scp-cache, and scp-nrfproxy microservices. PDB restricts the number of pods of a highly available application that are down simultaneously from voluntary disruptions, and allows safe eviction of pods when a node is drained of pods to perform maintenance. The maxPdbUnavailable parameter is specified in the Helm chart to determine the maximum number of pods that can remain unavailable during a voluntary disruption.

Managing Pod Disruption Budget

Enable

This feature is enabled automatically if you're deploying SCP with release 16.

Configure

You can configure this feature using Helm. For information about configuring PDB, see Oracle Communications Cloud Native Core, Cloud Native Environment Installation, Upgrade, and Fault Recovery Guide.

Observe

There is no specific metrics and alerts required for the Support of PDB functionality.

3.8.4 SCP Microservices and Probes

SCP microservices uses Kubernetes probes to monitor and manage the SCP application's initialization, health, and status. These are HTTP probes that provide a mechanism to identify the health status of the application. This probing occurs on a regular basis at a fixed interval, and appropriate action is taken if the probes fail.

The Kubernetes probes are as follows:

• Liveness probes: These probes allow you to evaluate whether an application that is running in a container is in a healthy state. If not, Kubernetes terminates the container, and the container is subjected to its restart policy.

  If a container doesn't provide a liveness probe, the default state is success.

• Readiness probes: These probes continuously verify whether a container is ready to serve requests. If the probe returns a failed state, Kubernetes removes the IP address for the pod from the endpoints of all services.

  The default state of readiness before the initial delay is failure. If a container doesn't provide a readiness probe, the default state is success.

  A pod is deemed ready when all of its containers have reached a state of readiness. The use of the signal is to regulate the selection of pods that serve as backends for services. When a pod is in an unready state, it's removed from the load balancer service. The stable support of the readiness probe has been available since the release of Kubernetes 1.0.

• Startup probes: These probes verify whether an application within a container has started. All other probes are disabled if a startup probe is provided until it succeeds, and if a container fails this probe, the container is terminated and follows the restart policy for the pod.

  This can be used to adopt liveness checks on slow-starting containers, avoiding them getting killed by the kubelet before they're up and running. The stable support of the startup probe has been available since the release of Kubernetes 1.0.

The following table describes the probes used by SCP microservices and their details.

Table 3-11 SCP Microservices and Startup Probes

SCP Microservice	Startup Probe Support	Startup Probe Condition	Startup Probe Configuration	Action on Failure
SCP-Worker	Yes	If all of the conditions listed below are met, the starting probe succeeds; otherwise, the probe fails: Routing rules received from the Notification microservice. Routing options received from Configurations The following data objects are received from the Configuration microservice: WORKER_POD_OVERLOAD_ACTION_POLICY WORKER_POD_OVERLOAD_CTRL_POLICY WORKER_POD_OVERLOAD_DISCARD_POLICY SERVICE_SPECIFICATIONS SCP_NF_PROFILES SCP_FEATURES LOCAL_NF_OAUTH2_REQUIRED ACCESS_TOKEN_GRANULARITY_CONFIG The scp-worker is able to access the scp-cache if rate limiting is enabled.	Initial delay: 35s Probe interval: 2s Failure threshold: 5	Pod Restart

Note:

Startup probes are only implemented for SCP_worker as of the current release.

Table 3-12 SCP Microservices and Readiness Probes

SCP Microservice	Readiness Probe Support	Readiness Probe Condition	Readiness Probe Configuration	Action on Failure
SCP-Worker	Yes	The scp-worker service is marked as ready if all the below conditions are met; otherwise, it is marked as not ready: Routing rules received from the Notification microservice. Routing options received from Configurations The following data objects are received from the Configuration microservice: WORKER_POD_OVERLOAD_ACTION_POLICY WORKER_POD_OVERLOAD_CTRL_POLICY WORKER_POD_OVERLOAD_DISCARD_POLICY SERVICE_SPECIFICATIONS SCP_NF_PROFILES SCP_FEATURES LOCAL_NF_OAUTH2_REQUIRED ACCESS_TOKEN_GRANULARITY_CONFIG The scp-worker is able to access the scp-cache if rate limiting is enabled.	The readiness probe starts after the startup probe is successful. Initial delay: 1s Probe interval: 2s Failure threshold: 5	Pod is marked as not ready, and hence its endpoint will not be created. As a result, the pods become inaccessible. For more information see, Readiness probes
SCP-nrfproxy	Yes	The SCP-nrfproxy service is marked as ready if all the below conditions are met; otherwise, it is marked as not ready. Check if the NRF configuration is available and can be read from the NRF Profiles table in the cnDBtier service. Check if the list of prioritized NRFs is available as per preference.	Initial delay: 30s Probe interval: 10s Failure threshold: 5	Pod is marked as not ready, and hence its endpoint will not be created. As a result, the pods become inaccessible. For more information see, Readiness probes
SCP-loadManager	Yes	The readiness probe for the SCP-loadManager service returns false during application initialization, and after the application is initialized, it starts returning the true value.	Initial delay: 5s Probe interval: 2s Failure threshold: 5	Pod is marked as not ready, and hence its endpoint will not be created. As a result, the pods become inaccessible. For more information see, Readiness probes
SCP-nrfProxy-Oauth	Yes	The readiness probe for the scp-nrfproxy-oauth service returns false during application initialization, and after the application is initialized, it starts returning the true value.	Initial delay: 5s Probe interval: 2s Failure threshold: 5	Pod is marked as not ready, and hence its endpoint will not be created. As a result, the pods become inaccessible. For more information see, Readiness probes
SCP-Cache	Yes	The scp-cache service is marked as ready if the below conditions are met; otherwise, it is marked as not ready. Check if application maps in scp-cache service are initialized.	Initial delay: 5s Probe interval: 2s Failure threshold: 5	Pod is marked as not ready, and hence its endpoint will not be created. As a result, the pods become inaccessible. For more information see, Readiness probes
SCPC-Notification	Yes	The scpc-notification service is marked as ready if the below conditions are met; otherwise, it is marked as not ready. Check whether the following tables have been created and populated: SCP_NF_PROFILES NRF_NF_DETAILS CANARY_RELEASES ROUTING_OPTIONS SYSTEM_OPTIONS VIRTUAL_SERVICES SERVICE_ENTRIES	Initial delay: 30s Probe interval: 10s Failure threshold: 5	Pod is marked as not ready, and hence its endpoint will not be created. As a result, the pods become inaccessible. For more information see, Readiness probes
SCPC-Audit	Yes	The scp-audit service is marked as ready if the below condition is met; otherwise, it is marked as not ready. Check if the NRF configuration is available and can be read from the NRF Profiles table in the cnDBtier service.	Initial delay: 30s Probe interval: 10s Failure threshold: 5	Pod is marked as not ready, and hence its endpoint will not be created. As a result, the pods become inaccessible. For more information see, Readiness probes
SCPC-Configuration	Yes	The scpc-configuration service is marked as ready if the below conditions are met; otherwise, it is marked as not ready. Check if the cnDBtier service is accessible and the required DB tables are available or created.	Initial delay: 30s Probe interval: 10s Failure threshold: 5	Pod is marked as not ready, and hence its endpoint will not be created. As a result, the pods become inaccessible. For more information see, Readiness probes
SCPC-Subscription	Yes	The scpc-subscription service is marked as ready if all the below conditions are met; otherwise, it is marked as not ready. Check if the cnDBteir service is accessible and if NRF and SCP profiles are available or created in the cnDBteir service.	Initial delay: 30s Probe interval: 10s Failure threshold: 5	Pod is marked as not ready, and hence its endpoint will not be created. As a result, the pods become inaccessible. For more information see, Readiness probes
SCPC-Alternate-resolution	Yes	The scpc-alternate resolution service is marked as ready if all the below conditions are met; otherwise, it is marked as not ready. Check if the cnDBtier service is accessible and if DNS SRV configuration for alternate route groups is available or created in the cnDBtier service. Validate if system options are synced from the scpc-configuration service.	Initial delay: 30s Probe interval: 10s Failure threshold: 5	Pod is marked as not ready, and hence its endpoint will not be created. As a result, the pods become inaccessible. For more information see, Readiness probes

Table 3-13 SCP Microservices and Liveness Probes

SCP Microservice	Liveness Probe Support	Liveness Probe Condition	Liveness Probe Configuration	Liveness Action on Failure
SCP-Worker	Yes	Threadwatchdog controls the Liveness probe. ThreadWatchDog monitors all the threads running in the pod at a fixed interval. If threadwatchdog identifies that a thread is stuck, then the liveness probe is marked as failed.	The liveness probe starts after the startup probe is successful. Initial delay: 1s Probe interval: 2s Failure threshold: 5	Pod restart
SCP-nrfproxy	Yes	Threadwatchdog controls the Liveness probe. ThreadWatchDog monitors all the threads running in the pod at a fixed interval. If threadwatchdog identifies that a thread is stuck, then the liveness probe is marked as failed.	Initial delay: 180s Probe interval: 2s Failure threshold: 5	Pod restart
SCP-loadManager	Yes	Threadwatchdog controls the Liveness probe. ThreadWatchDog monitors all the threads running in the pod at a fixed interval. If threadwatchdog identifies that a thread is stuck, then the liveness probe is marked as failed.	Initial delay: 180s Probe interval: 2s Failure threshold: 5	Pod restart
SCP-nrfProxy-Oauth	Yes	Threadwatchdog controls the Liveness probe. ThreadWatchDog monitors all the threads running in the pod at a fixed interval. If threadwatchdog identifies that a thread is stuck, then the liveness probe is marked as failed.	Initial delay: 180s Probe interval: 2s Failure threshold: 5	Pod restart
SCP-Cache	Yes	The liveness probe for scp-cache always returns true.	Initial delay: 180s Probe interval: 2s Failure threshold: 5	N/A
SCPC-Notification	Yes	Threadwatchdog controls the Liveness probe. ThreadWatchDog monitors all the threads running in the pod at a fixed interval. If threadwatchdog identifies that a thread is stuck, then the liveness probe is marked as failed.	Initial delay: 180s Probe interval: 2s Failure threshold: 5	Pod restart
SCPC-Audit	Yes	Threadwatchdog controls the Liveness probe. ThreadWatchDog monitors all the threads running in the pod at a fixed interval. If threadwatchdog identifies that a thread is stuck, then the liveness probe is marked as failed.	N/A	Pod restart
SCPC-Configuration	Yes	Threadwatchdog controls the Liveness probe. ThreadWatchDog monitors all the threads running in the pod at a fixed interval. If threadwatchdog identifies that a thread is stuck, then the liveness probe is marked as failed.	N/A	Pod restart
SCPC-Subscription	Yes	Threadwatchdog controls the Liveness probe. ThreadWatchDog monitors all the threads running in the pod at a fixed interval. If threadwatchdog identifies that a thread is stuck, then the liveness probe is marked as failed.	N/A	Pod restart
SCPC-Alternate-resolution	Yes	Threadwatchdog controls the Liveness probe. ThreadWatchDog monitors all the threads running in the pod at a fixed interval. If threadwatchdog identifies that a thread is stuck, then the liveness probe is marked as failed.	N/A	Pod restart

3.8.5 Horizontal Pod Autoscaler

You can use the Kubernetes Horizontal Pod Autoscaler to automatically scale the number of pods in a deployment, replication controller, replica set, or stateful set, based on that resource's CPU or memory utilization or on other metrics. Using Horizontal Pod Autoscaler, applications can be scaled out to meet increased demands or scaled in when resources are no longer required. You can set a target metric percentage for Horizontal Pod Autoscaler to meet when scaling applications. For more information about Horizontal Pod Autoscaler, see https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/.

A new service pod accepts new HTTP2 connection requests when the pod status is "Ready". Otherwise, the new HTTP2 connection requests are distributed among service pods with the status "Ready". After an HTTP2 connection is established, the 5G SBI messages are routed on the same established HTTP2 connection with a particular service pod. So, when a service pod is restarted or a new pod is spawned due to an upgrade or scaling, the newly created service pod starts accepting new HTTP2 connection requests from the consumer NFs, and the existing HTTP2 connections will continue to manage traffic. If any existing connection is terminated due to idle timeout or any other reason, and when the consumer NF initiates a new connection attempt, this connection can be established with any existing or new service pod with the status "Ready". To avoid scaling in and scaling out of the SCP service pods, it is recommended to have minimum and maximum replica count for the rated capacity of the SCP deployment. For more information about replica count, see "Resource Requirements" in Oracle Communications Cloud Native Core, Service Communication Proxy Installation, Upgrade, and Fault Recovery Guide.

Managing Horizontal Pod Autoscaler

Enable

This feature is automatically enabled in SCP at the time of deployment.

Configure

There are no specific configurations required for this feature.

Observe

There are no specific metrics and alerts required for this feature.

Maintain

If you encounter alerts at system level, see the Alerts section for resolution steps.

In case the alerts persist, perform the following tasks:

1. Collect the logs: For information about how to collect logs, see Oracle Communications Cloud Native Core, Service Communication Proxy Troubleshooting Guide.
2. Raise a service request: For information about how to raise a service request, see My Oracle Support.

3.9 SCP Response Timeout Extension

Previously, users could configure a response timeout interval of up to 15 seconds for receiving a response from SCP.

The SCP Response Timeout Extension feature enhances the SCP's capability to manage network requests more effectively, ensuring consistent service even when Producer NFs require additional processing time.

The enhanced feature allows users to extend the maximum response timeout to 50 seconds. This improvement provides configuration options to handle response timeouts for NFs that require more time to serve a request.

The SCP allows users to configure a maximum timeout of up to 50 seconds for receiving responses from the Producer NF. If the response is not received within this timeframe, the SCP will automatically initiate rerouting to an available alternate NF or pod.

The SCP monitors the total forwarded request rate, specifically targeting requests with response times exceeding 50 seconds. The SCP supports up to 200 messages per second (MPS) for all NF Service-Based Interface (SBI) traffic through the Namf interface. An alert is raised when the traffic exceeds 200 MPS and the response delay from the Producer NF takes more than 50 seconds.

Call Flow

The following call flow diagram illustrates the scenario:

Figure 3-2 Call Flow for SCP Response Timeout Extension

1. The user sets the response timeout with a maximum limit of up to 50 seconds for a service.
2. SCP receives the ingress service request for the same service and starts the countdown for the response timeout before sending the request out.
3. SCP checks if the response is received within the timeout period:
   1. If the response is received within the timeout, SCP will process the response and send it back to the Consumer NF.
   2. If not, SCP will generate its own error response and send it back to the Consumer NF.
4. If SCP receives more than 200 responses with a response time of 50 seconds or greater from the Producer NF, SCP will generate an alert.

Managing SCP Response Timeout in Routing Option Configuration

Enable

This feature is enabled automatically at the time of SCP deployment.

Configure

You can configure this feature using REST APIs as described in "Configuring Routing Options" in Oracle Communications Cloud Native Core, Service Communication Proxy REST Specification Guide.

Observe

• The ocscp_metric_upstream_service_time_total metric is updated with new buckets for response timeout in the Metrics section.
• Added SCPHighResponseTimeFromProducer alert in the Alerts section.

Maintain

If you encounter alerts at the system level, see the Alerts section for resolution steps.

In case the alerts persist, perform the following tasks:

1. Collect the logs: For information about how to collect logs, see Oracle Communications Cloud Native Core, Service Communication Proxy Troubleshooting Guide.
2. Raise a service request: For information about how to raise a service request, see My Oracle Support.

3.10 Overload Control Based on the Overload Control Information Header

SCP, SEPP, producer NFs, and consumer NFs get overloaded when they operate beyond their signaling capacity. An enhancement is required to include Overload Control Information (OCI) in 5G Service Based Interface (SBI) messages to convey the overload capacity of NFs to their peers.

Using the Overload Control Based on the Overload Control Information Header feature, SCP, SEPP, consumer NFs, and producer NFs can gracefully reduce their incoming signaling traffic by conveying consumer NFs to reduce sending service requests or by conveying producer NFs to reduce sending notification requests, respectively, so that these entities or peer NFs can process the traffic according to their configured capacities. After receiving the 3gpp-Sbi-Oci header from consumer NFs, producer NFs perform the signaling reduction toward the consumer NF only for the notifications or callback requests according to the overload scope and not for any NF services that may be produced by the same NF.

Depending on SCP's configuration, SCP can:

• send its load information in the OCI header with reduction metrics based on the REST API configuration.
• reduce traffic toward the peer based on the OCI received from a peer.

OCI is conveyed within the 3gpp-Sbi-Oci header. When SCP, SEPP, consumer NF, or producer NF experiences overload conditions, it sends overload condition information through the 3gpp-Sbi-Oci header, which is tagged along with the messages to peers.

OCI contains Overload Timestamp, Overload-Reduction-Metric, Period-of-Validity, and Scope attributes in the 3gpp-Sbi-Oci header.

A sample format of the 3gpp-Sbi-Oci header for an NF instance is as follows:

Timestamp: "Mon, 04 Dec 2023 08:49:37 GMT"; Period-of-Validity: 75s; Overload-Reduction-Metric: 50%; NF-Instance: 54804518-4191-46b3-955c-ac631f953ed8

The following table describes attributes of the 3gpp-Sbi-Oci header format:

Table 3-14 3gpp-Sbi-Oci Header Attributes

Attribute	Description
Timestamp	Indicates the time when the OCI was generated. This attribute is used by the OCI recipient such as peers or SCP, to decide whether the newly received OCI is the same as the previously received OCI or different. The OCI recipient can overwrite any stored OCI for a peer NF, NF set, NF service, NF service set, Callback URI, SCP, or SEPP with the newly received OCI if the new OCI is more recent than the previously stored OCI. Example: Timestamp: "Mon, 04 Dec 2023 08:49:37 GMT".
Period-of-Validity	Indicates the duration during which the overload condition specified by the 3gpp-Sbi-Oci header is considered valid until overridden by subsequent new OCIs. Example: Period-of-Validity: 75s.
Overload-Reduction-Metric	Indicates the percentage of traffic reduction requested by the OCI sender to the OCI recipient. This value can range from 0 to 100. Example: Overload-Reduction-Metric: 50%.
Scope	Indicates the message requests or notification requests to which the OCI is applicable. It identifies the traffic that the OCI sender requests the receiver to process in accordance with the OCI. Example: NF-Instance: 54804518-4191-46b3-955c-ac631f953ed8. List of supported olcScope in the OCI header at SCP: nfProducerScope NF-Instance NF-Service-Instance nfConsumerScope Callback-Uri NF-Instance NF-Service-Instance NF-Instance and Service-Name scpScope SCP-FQDN seppScope SEPP-FQDN

Conveyance of OCI

The following scenarios explain the conveyance of OCI:

Peer OCI Enforcement

SCP performs OCI enforcement based on the OCI header received from the peer and the REST API configuration.

When a peer NF is overloaded, it sends OCI to SCP so that SCP can throttle the traffic destined for that peer NF. Based on the ociEnforcementAction REST API parameter configuration, SCP can perform alternate routing to another equivalent peer NF or directly send an error response to the peer consumer NF. SCP relays the OCI received from the peer NF to other peer NFs based on the relayPeerOci REST API parameter configuration as described in Oracle Communications Cloud Native Core, Service Communication Proxy REST Specification Guide. For example, if the Overload-Reduction-Metric attribute of the OCI header is 10%, the producer NF conveys SCP to reduce the message rate by 10%. If SCP has 100 messages to be routed to that producer NF, SCP will route 90 messages to the target producer NF. To process the pending 10 messages, SCP can reroute the messages to another equivalent NF or send an error response to the consumer NF based on the ociEnforcementAction REST API parameter.

After the expiry of peer OCI Period-of-Validity attribute, SCP can continue sending traffic toward the peer immediately or incrementally based on the ociTrafficRecoveryPolicy REST API parameter.

Self-OCI Generation and Conveyance

SCP conveys its overload control information, which is known as self-OCI, with its peer NFs when SCP is overloaded.

The overload condition of SCP is determined by the CPU utilization of all SCP-Worker pods. SCP is overloaded when the average CPU utilization of all the pods exceeds the configured OCI threshold levels.

When SCP is overloaded, SCP generates OCI based on the threshold levels such as WARN, MINOR, MAJOR, and CRITICAL, configured using the OciThresholdConfig REST API parameter as described in Oracle Communications Cloud Native Core, Service Communication Proxy REST Specification Guide. SCP sends the self-generated OCI only when there is any message to be routed to the peer NF.

SCP starts conveying OCI to peers when it gets overloaded based on the configured threshold level. OCI is conveyed for the following scenarios:

• When OCI threshold changes: Whenever SCP's traffic load changes resulting in OCI threshold changes, SCP creates a new OCI based on the current threshold level configuration values and current timestamp.
• When the Period-of-Validity attribute expires: When the Period-of-Validity attribute of the last sent OCI expires, SCP creates a new OCI based on the current threshold level configuration values and current timestamp.
• Periodically: After every scpOciConveyanceInterval interval, SCP sends the same OCI that was sent last time to the peer NF.

Managing Overload Control Information

Enable

By default, this feature is disabled. You can use the oci option to enable or disable this feature as described in Configuring SCP Features.

Configure

You can configure this feature using REST API and the CNC Console.

• Configure using CNC Console: For information about CNC Console configurations, see
  • Configuring OCI
  • Configuring OCI Threshold Levels
• Configure using REST API: For information about configuring REST APIs, see "Configuring SCP Features", "Configuring Overload Configuration Information Threshold" and "Configuring Overload Configuration Information" in Oracle Communications Cloud Native Core, Service Communication Proxy REST Specification Guide.

Observe

The following metrics are added in the Metrics section:

• ocscp_worker_peer_oci_conveyance_total
• ocscp_worker_oci_conveyance_total
• ocscp_worker_oci_enforced_total
• ocscp_worker_rx_unsupported_oci_scope_total
• ocscp_metric_nf_oci_rx_total

The following metrics are added in the Alerts section:

• ScpSelfOCIThresholdAboveWarn
• ScpSelfOCIThresholdAboveMinor
• ScpSelfOCIThresholdAboveMajor
• ScpSelfOCIThresholdAboveCritical

Maintain

If you encounter alerts at system level, see the Alerts section for resolution steps.

In case the alerts persist, perform the following tasks:

1. Collect the logs: For information about how to collect logs, see Oracle Communications Cloud Native Core, Service Communication Proxy Troubleshooting Guide.
2. Raise a service request: For information about how to raise a service request, see My Oracle Support.

3.11 Support for HTTPS

Hypertext Transfer Protocol Secure (HTTPS) is an extension of Hypertext Transfer Protocol (HTTP). HTTPS establishes a secure connection between Network Functions (NFs) in a 5G network and uses Transport Layer Security (TLS) to encrypt the communication protocols.

With the support of HTTPS connections, SCP accepts secured ingress connection requests from a consumer NF and establishes a secured egress connection with a producer NF. HTTPS provides confidentiality and integrity protection to 5G Service Based Interface (SBI) messages.

SCP processes 5G SBI messages over HTTPS connection based on the sbiProxySslConfigurations parameter configuration as specified in the custom-values.yaml file. For more information, see Oracle Communications Cloud Native Core, Service Communication Proxy Installation, Upgrade, and Fault Recovery Guide. The sbiProxySslConfigurations configuration authorizes both ingress and egress connections from consumer NFs and producer NFs, respectively with SCP.

SCP supports a single and multiple TLS certificates to enable HTTPS as described in TLS Certificate Configuration Enhancement. SCP supports two-way TLS authentication for HTTPS connections and accesses Certificate Authority (CA) from Kubernetes secret.

Note:

• This feature supports HTTPS for inter-NF communication but not intra-NF communication, that is, communication between two microservices within SCP.
• SCP supports both HTTP and HTTPS concurrently. You can select to expose service IP for HTTP, HTTPS, or both.
• This feature supports TLSv1.2 and TLSv1.3.

Managing Support for HTTPS

Enable

This feature is enabled by setting the following Helm parameters in the custom-values.yaml file:

• Enabling HTTPS for ingress connections:
  • For Release 16 deployment: The scpProfileInfo.scpInfo.scpPorts.https parameter enables SCP to establish ingress connection with consumer NFs. You must set the https port to the same value as the publicSignallingPortHttps parameter.

    Example of NF Service for HTTPS:

    #    - serviceInstanceId: f86b54b7-aef9-4c78-b346-3bfb7f380813
    #      serviceName: nscp-5g-sbi-proxy
    #      fqdn: <scprel>-scp-worker.scpsvc.svc.cluster.local
    #      scheme: https
    #      priority: 0 # Default value is 0
    #      capacity: 100 # Default value is 100
    #      load: 0
    #      nfServiceStatus: REGISTERED
    #      ipEndPoints:
    #      - ipv4Address: 10.104.121.240 # this IP should be same as "publicSignalingIPHttps" of SCP mentioned above.
    #        port: '9443'  # this port should be same as "publicSignalingPortHttps" of SCP mentioned above.
    #      apiPrefix: # Ignored in SCP processing
    #      versions:   # Ignored in SCP processing, but kept for registering with NRF
    #      - apiFullVersion: 1.0.0
    #        apiVersionInUri: v1

• Enabling HTTPS for egress connections: The nativeEgressHttpsSupport parameter must be set to true to enable SCP to establish a connection with producer NFs over HTTPS. By default, this value is set to false. If this value is set to false, then all the connections with producer NFs are established through HTTP.

  For more information about above mentioned parameters, see Oracle Communications Cloud Native Core, Service Communication Proxy Installation, Upgrade, and Fault Recovery Guide.

  Note:

  You can configure the required Helm parameters for this feature if you have performed a fresh installation of SCP or upgraded SCP within the same release version, for example, 25.1.100 to 25.1.100.

Configure

sbiProxySslConfigurations and ddSslConfiguration Helm parameters are introduced as part of this feature. To use this feature, complete the configuration as described in "Global Parameters" in Oracle Communications Cloud Native Core, Service Communication Proxy Installation, Upgrade, and Fault Recovery Guide.

Observe

The ocscp_metric_ssl_certificate_expire_total metric is updated in the Metrics section.

Maintain

If you encounter alerts at the system level, see the Alerts section for resolution steps.

In case the alerts persist, perform the following tasks:

1. Collect the logs: For information about how to collect logs, see Oracle Communications Cloud Native Core, Service Communication Proxy Troubleshooting Guide.
2. Raise a service request: For information about how to raise a service request, see My Oracle Support.

3.11.1 TLS Certificate Configuration Enhancement

SCP uses Hypertext Transfer Protocol Secure (HTTPS) to establish secured ingress and egress connections with consumer NFs and producer NFs, respectively. These communication protocols are encrypted using Transport Layer Security (TLS).

In SCP 23.2.0, SCP used to support a single TLS certificate configuration to enable HTTPS.

From 23.3.0, this enhancement enables SCP to configure different Transport Layer Security (TLS) certificates on ingress and egress interfaces. It also allows users to provide primary and secondary certificates for each interface.

Multiple TLS certificates can be configured across the following communication interfaces:

• Egress connections on 5G Service Based Architecture (SBA): SCP acts as a client while sending message requests to producer NFs, producer SCP-P, or NRF. For example:
  • A consumer 'SCP-C' sends health check request to a producer 'SCP-P'.
  • SCP forwards notifications to consumer NFs.
  • SCP forwards Service, Discovery, or Access Token requests to NRF or producer NFs.
• Ingress connections on 5G SBA: SCP acts as a server to process message requests received from consumer NFs, SCP-C, or NRF. For example:
  • SCP-P receives health check request from SCP-C.
  • SCP receives notifications from NRF or NF producer.
  • SCP receives service or health check requests from consumer NFs.
• Oracle Communications Network Analytics Data Director (OCNADD) connection on message feed: SCP acts as a client toward OCNADD on message feed interfaces, for example, SCP sends message feed data to OCNADD.

Note:

You can use a single or multiple TLS certificates to enable HTTPS.

If the primary TLS certificate expires or is about to expire, SCP switches to an alternate or secondary TLS certificate. If there is no alternate TLS certificate configured, SCP uses a single certificate to enable HTTPS. At each communication interface such as ingress, egress, and OCNADD, you can configure the caBundle Helm parameter to manage the Certificate Authority (CA) bundle. The CA can be the same or different at these interfaces. For example, CA signing the TLS certificate at the ingress communication interface can be the same or different from the CA at the egress communication interface.

Note:

It is recommended to maintain multiple TLS certificates with overlapping expiry time to avoid service interruption during certificate expiry. For example, if the primary certificate validity is changed from T0 and T1, then the validity of the secondary certificate must be changed from T0 to T2 so that when the primary certificate expires, the secondary certificate gets activated within the expiry period of the primary certificate, where, T0 < T1 < T2.

By default, SCP uses a single TLS certificate to enable HTTPS. To enable support for multiple TLS certificates, you can modify the sbiProxySslConfigurations Helm parameter configurations for ingress and egress connections and the ddSslConfiguration Helm parameter for OCNADD connections.

SCP uses the Helm parameters sslCertExpiryMinorThreshold, sslCertExpiryMajorThreshold, and sslCertExpiryCriticalThreshold to set up minor, major, and critical alerts for TLS certificate expiration. These alerts are triggered at the specified times to signal the impending expiry of the certificates.

SCP provides the terminateTLSConnsOnCertExpiry Helm configuration at the egress communication interface to determine whether to terminate or maintain the existing HTTPS connections when the configured TLS certificate is updated or renewed. When the TLS certificate expires, then SCP:

• maintains the existing HTTPS connections that were using the expired certificates.
• creates new HTTPS connections which uses the updated or renewed TLS certificate.

For more information about configuring Helm parameters for multiple TLS certificates, see "Global Parameters" in Oracle Communications Cloud Native Core, Service Communication Proxy Installation, Upgrade, and Fault Recovery Guide.

3.11.2 Support for TLS

SCP uses Hypertext Transfer Protocol Secure (HTTPS) to establish secure connections with consumer NFs and producer NFs, respectively. These communication protocols are encrypted using Transport Layer Security (TLS).

TLS comprises the following components:

• Handshake Protocol: Exchanges the security parameters of a connection. Handshake messages are supplied to the TLS record layer.
• Record Protocol: Receives the messages to be transmitted, fragments the data into multiple blocks, secures the records, and then transmits the result. Received data is delivered to consumer NFs and producer NFs.

This feature enables the support for TLS 1.3 to all consumer NFs, producer NFs, the Data Director, SBI Interfaces, and any interfaces previously supporting TLS 1.2. Support for TLS 1.2 will remain available.

TLS 1.2 and TLS 1.3 Handshake

This section describes the differences between TLS 1.3 and TLS 1.2, as well as the advantages of TLS 1.3 over TLS 1.2 and earlier versions.

Figure 3-3 TLS 1.2 and TLS 1.3 Handshake

TLS 1.2

Step 1: The connection or handshake starts when the client sends a "client hello" message to the server. This message consists of cryptographic information such as supported protocols and cipher suites. It also contains a random value or random byte string.

Step 2: To respond to the "client hello" message, the server sends a 'server hello' message. This message contains the CipherSuite that the server has selected from the options provided by the client. The server also sends its certificate, along with the session ID and another random value.

Step 3: The client verifies the certificate sent by the server. When the verification is complete, it sends a byte string encrypted using the public key of the server's certificate.

Step 4: When the server receives the secret, both the client and server generate a master key along with session keys (ephemeral keys). These session keys are used for symmetrically encrypting the data.

Step 5: The client sends an "HTTP Request" message to the server to enable the server to transition to symmetric encryption using the session keys.

Step 6: To respond to the client’s "HTTP Request" message, the server does the same and switches its security state to symmetric encryption. The server concludes the handshake by sending an HTTP response.

Step 7: The client-server handshake is completed in two round trips.

TLS 1.3

Step 1: The connection or handshake begins when the client sends a "client hello" message to the server, which includes the list of supported cipher suites and the client's key share for the specific key agreement protocol.

Step 2: To respond to the "client hello" message, the server sends the key agreement protocol that it has chosen. The "Server Hello" message includes the server key share, server certificate, and the "Server Finished" message.

Step 3: The client verifies the server certificate, generates keys since it has the server's key share, and then sends the "Client Finished" message along with an HTTP request.

Step 4: The server completes the handshake by sending an HTTP response.

Comparison Between TLS 1.3 and TLS 1.2

The following table provides the comparison of TLS 1.3 and TLS 1.2:

Table 3-15 Comparison of TLS 1.3 and TLS 1.2

Feature	TLS 1.3	TLS 1.2
TLS Handshake	The initial handshake involves the exchange of key shares, ensuring cryptographic security. A typical handshake in TLS 1.3 involves the exchange of up to 3 packets, thereby facilitating quicker and more responsive connections.	The initial handshake occurs in clear text. A typical handshake in TLS 1.2 involves a more extended process, typically requiring 5-7 packets for completion, resulting in slower connection establishment times.
Cipher Suites and Privacy	Improving security by narrowing the selection of cipher suites, which streamlines configuration and reduces errors. Supported algorithms are free from known vulnerabilities, thus making the cipher suites more secure. TLS_AES_128_GCM_SHA256 TLS_AES_256_GCM_SHA384 TLS_CHACHA20_POLY1305_SHA256	Supporting a wide range of cipher suites that are vulnerable to attacks results in less secure cipher suites. TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256
Round-Trip Time	Efficient session resumption modes, such as Zero Round Trip Time (0-RTT), enable clients to resume sessions without additional round trips. Data can be transmitted in the initial message using Pre-Shared Keys (PSK), further enhancing the efficiency of the communication process.	TLS 1.2 does not support a 0-RTT mode for resuming sessions with reduced round-trip time.
Perfect Forward Secrecy (PFS)	TLS 1.3 supports Provide Forward Secrecy (PFS). PFS ensures that each session key is entirely independent of long-term private keys, which are used over an extended period for decrypting encrypted data.	TLS 1.2 does not provide PFS.
Performance	The handshake process is optimized to reduce latency by minimizing the number of required round trips, resulting in a more responsive connection.	The handshake process involves multiple round trips between the client and server, may result in increased latency and a less responsive connection.

TLS 1.3 handshake offers the following improvements over earlier versions:

• The symmetric encryption algorithms are removed and Authenticated Encryption with Associated Data (AEAD) algorithms are supported.
• In TLS 1.3, all handshake messages after the ServerHello are encrypted.
• A zero round-trip time (0-RTT) mode is added in the handshake process, enabling fewer round trips compared to TLS 1.2. Additionally, it utilizes cryptographic algorithms that are faster.
• Static Rivest-Shamir-Adleman (RSA) and Diffie-Hellman cipher suites are removed, ensuring that all public-key-based key exchange mechanisms now Provide Forward Secrecy (PFS).
• TLS 1.3 has better security than TLS 1.2, addressing known vulnerabilities in the handshake process.
• TLS 1.3 eliminates data compression.
• Version Downgrade Protection in TLS 1.3 is a security mechanism that prevents attackers from using an older, potentially less secure version of the TLS protocol. This protection is achieved through the exchange of a "Finished" message between the client and server, which includes a Message Authentication Code (MAC) covering all preceding handshake messages. This mutual verification process ensures that negotiated parameters remain unaltered by potential attackers. This helps ensure that connections are established using the latest, most secure version of TLS available, reducing the risk of vulnerabilities associated with older protocol versions.

Managing Support for TLS

Enable

If you want to use TLS 1.3, perform the following procedure:

1. In the custom_values.yaml file, configure the following Helm parameters:
   • sbiProxySslConfigurations.server to TLSV1_3
   • sbiProxySslConfigurations.client[0] to TLSV1_3

     Note:

     By default, the helm parameter is set to TLS 1.3,TLS 1.2.
2. Add the following ciphers to the cipherSuitesTlsV1_3 parameter:
   • TLS_AES_128_GCM_SHA256
   • TLS_AES_256_GCM_SHA384
   • TLS_CHACHA20_POLY1305_SHA256

Using TLS for OCNADD

By default, SCP uses a single TLS certificate to enable HTTPS. To enable support for multiple TLS certificates, you can modify the sbiProxySslConfigurations Helm parameter configurations for ingress and egress connections and the ddSslConfiguration Helm parameter for OCNADD connections.

Using TLS 1.2

If you want to use only TLS 1.2, perform the following procedure:

1. In the custom_values.yaml file, configure the following Helm parameter:
   • sslEnabledProtocol to TLSv1.2

     Note:

     By default, the helm parameter is set to TLS 1.3
2. Add the following ciphers to the cipherSuitesTlsV1_2 parameter:
   • TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
   • TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
   • TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256
   • TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
   • TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
   • TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256

Configure

You can configure this feature using Helm. For information about Helm configurations, see "Global Parameters" in Oracle Communications Cloud Native Core, Service Communication Proxy Installation, Upgrade, and Fault Recovery Guide.

Observe

The following metrics are added in the Metrics section:

• ocscp_worker_https_ingress_connection_success_total
• ocscp_worker_https_ingress_connection_failure_total
• ocscp_worker_https_egress_connection_success_total
• ocscp_worker_https_egress_connection_failure_total
• ocscp_metric_ssl_certificate_expire_total

The following alerts are added in the Alerts section:

• SCPWorkerSSLCertificateOnCriticalExpiry
• SCPWorkerSSLCertificateOnMajorExpiry
• SCPWorkerSSLCertificateOnMinorExpiry
• SCPIngressConnectionEstablishmentFailure
• SCPEgressConnectionEstablishmentFailure

Maintain

If you encounter alerts at system level, see the Alerts section for resolution steps.

In case the alerts persist, perform the following tasks:

1. Collect the logs: For information about how to collect logs, see Oracle Communications Cloud Native Core, Service Communication Proxy Troubleshooting Guide.
2. Raise a service request: For information about how to raise a service request, see My Oracle Support.

3.11.3 Support for Automated Certificate Lifecycle Management

In SCP 23.3.x and earlier releases, X.509 and Transport Layer Security (TLS) certificates were managed manually. When multiple instances of SCP were deployed in a 5G network, certificate management, such as certificate creation, renewal, removal, and so on, was tedious and error-prone.

Using the Support for Automated Certificate Lifecycle Management feature, you can integrate SCP with OCCM to support automation of certificate lifecycle management. OCCM manages TLS certificates stored in Kubernetes secrets by integrating with Certificate Authority (CA) using the Certificate Management Protocol Version 2 (CMPv2) protocol. OCCM obtains and signs TLS certificates and stores them in Kubernetes secrets of SCP namespace. For more information about OCCM, see Oracle Communications Cloud Native Core, Certificate Management User Guide.

Using this feature, you can monitor, create, recreate, and renew TLS certificates based on their validity. For information about creating Kubernetes secrets, see "Configuring SSL or TLS Certificates to Enable HTTPS" in Oracle Communications Cloud Native Core, Service Communication Proxy Installation, Upgrade, and Fault Recovery Guide.

3.12 Support for HTTP2 Header

To improve efficiency across converged networks and optimize 5G core traffic, 3GPP-defined headers at the SCP have been introduced.

3.12.1 Support for 3GPP Timestamp Related Headers

The 3GPP TS 29.500 and TS 29.502 specifications define several headers that are used by 5G Core Network Functions (NFs) to manage timeouts, delays, and responses in 5G Core NFs. These headers provide critical information about the timing of requests and the expected responses.

Prerequisite: Time synchronization between NFs and the SCP, as well as among SCP services, is required for this feature to function properly.

The following are the three types of headers and their functionality:

• 3gpp-Sbi-Sender-Timestamp: This header indicates the exact time, with millisecond granularity, at which an HTTP request or response was initiated by the sender. This timestamp is crucial for tracking when the request was sent, enabling the measurement of signaling delays between different NF service instances within the network.

  For example: 3gpp-Sbi-Sender-Timestamp: Sun, 04 Aug 2019 08:49:37.845 GMT

• 3gpp-Sbi-Origination-Timestamp: This header captures the exact time, with millisecond granularity, when the originating entity (such as initial NF) initiated the HTTP request.

  For example: 3gpp-Sbi-Origination-Timestamp: Sun, 04 Aug 2019 08:49:37.845 GMT

• 3gpp-Sbi-Max-Rsp-Time: This header specifies the maximum duration, in milliseconds, that the sender is willing to wait for a response after sending the request.

  For example: 3gpp-Sbi-Max-Rsp-Time: 10000

This feature allows SCP to calculate the response timeout and total transaction lifetime by using the 3GPP-defined SBI Timestamp headers included in the SBI request messages.

When the Timestamp Header Support and Dynamic Response Timeout features are enabled, the SCP will consistently add or modify the 3gpp-Sbi-Sender-Timestamp and 3gpp-Sbi-Max-Rsp-Time headers. However, it will not modify the 3gpp-Sbi-Origination-Timestamp, as this header represents the original sender’s timestamp. The SCP updates the 3gpp-Sbi-Sender-Timestamp to the current time before forwarding the request and adjusts the 3gpp-Sbi-Max-Rsp-Time to reflect the remaining time that the SCP will wait for a response.

Upon receiving a request with both the 3gpp-Sbi-Sender-Timestamp and 3gpp-Sbi-Max-Rsp-Time headers, SCP checks whether the request has already timed out.

For the first routing attempt, the ResponseTimeout is determined by taking the minimum value between the ConfiguredResponseTimeout and the RemainingTimeBudget.

• Configured Timeout: The maximum timeout value configured for the service request. This refers to the 'responseTimeout' value configured in the Routing Config Set. For more information, see the "Routing Config Set" in the Oracle Communications Cloud Native Core, Service Communication Proxy REST Specification Guide.
• RemainingTimeBudget: The amount of time left for the request to be processed is based on the maximum allowable response time (3gpp-Sbi-Max-Rsp-Time) minus the time that has already passed and the downstream response transit time.

ResponseTimeout = minimum(
        ConfiguredResponseTimeout, RemainingTimeBudget )

The calculation of the timeout value for the 3GPP-defined SBI Timestamp headers also considers the network transit time required to send the SBI response back to the downstream NF, SCP or SEPP in roaming scenarios. This network transit time is configurable. If the user does not wish to include downstream transit time in the above calculations, they can set the relevant value to 0. For information about configuring REST APIs, see "Configuring SCP Features" in Oracle Communications Cloud Native Core, Service Communication Proxy REST Specification Guide.

Note:

In an inter-SCP case (when an SCP routes a request to another SCP), no alternate routing occurs in the consumer SCP, except in the case of a connection failure. Therefore, use Consumer SCP to allocate the full RemainingTimeBudget as the ResponseTimeout to the next-hop SCP, even if a secondary SCP is available.

SCP will allocate the entire remaining time budget for the last routing attempt:

ResponseTimeout = RemainingTimeBudget

Timestamp Header Combinations and SCP Behavior

For this feature to function correctly, it is expected to receive the 3gpp-Sbi-Max-Rsp-Time header and the 3gpp-Sbi-Sender-Timestamp and/or 3gpp-Sbi-Origination-Timestamp headers in the request. However, if the expected headers are not received, SCP will forward the routing request and apply the existing routing behavior.

The following table summarizes the various combinations of the 3GPP SBI Timestamp headers and the corresponding behavior of the SCP when forwarding or processing SBI requests:

Table 3-16 Timestamp Header Combinations and SCP Behavior

3gpp-Sbi-Max-Rsp-Time	3gpp-Sbi-Sender-Timestamp	3gpp-Sbi-Origination-Timestamp	Feature Enabled and Dynamic Response Timeout = True	Feature Enabled and Dynamic Response Timeout =False and Update Timestamp Headers = True
Yes	Yes	Yes	Applies the feature as outlined above.	Updates 3gpp-Sbi-Max-Rsp-Time and 3gpp-Sbi-Sender-Timestamp headers
Yes	Yes	No	Applies the feature as outlined above.	Updates 3gpp-Sbi-Max-Rsp-Time and 3gpp-Sbi-Sender-Timestamp headers
Yes	No	Yes	Applies the feature as outlined above.	Adds or Updates 3gpp-Sbi-Max-Rsp-Time and 3gpp-Sbi-Sender-Timestamp headers
Yes	No	No	Applies the feature with the assumption that the 3gpp-Sbi-Sender-Timestamp reflects the timestamp at which SCP receives the request at the ingress.	Adds or Updates 3gpp-Sbi-Max-Rsp-Time and 3gpp-Sbi-Sender-Timestamp headers
No	Yes	Yes	Applies the existing routing behavior, SCP will use the configured values to set the total transaction timeout and response timeouts, and adds or updates the 3gpp-Sbi-Max-Rsp-Time and 3gpp-Sbi-Sender-Timestamp headers.	Adds or Updates 3gpp-Sbi-Max-Rsp-Time and 3gpp-Sbi-Sender-Timestamp headers
No	Yes	No	Applies the existing routing behavior, SCP will use the configured values to set the total transaction timeout and response timeouts, and adds or updates the 3gpp-Sbi-Max-Rsp-Time and 3gpp-Sbi-Sender-Timestamp headers.	Adds or Updates 3gpp-Sbi-Max-Rsp-Time and 3gpp-Sbi-Sender-Timestamp headers
No	No	Yes	Applies the existing routing behavior, SCP will use the configured values to set the total transaction timeout and response timeouts, and adds or updates the 3gpp-Sbi-Max-Rsp-Time and 3gpp-Sbi-Sender-Timestamp headers.	Applies existing behavior. SCP does not add the 3gpp-Sbi-Max-Rsp-Time and 3gpp-Sbi-Sender-Timestamp headers.
No	No	No	Applies the existing routing behavior, SCP will use the configured values to set the total transaction timeout and response timeouts, and adds or updates the 3gpp-Sbi-Max-Rsp-Time and 3gpp-Sbi-Sender-Timestamp headers.	Applies existing behavior. SCP does not add the 3gpp-Sbi-Max-Rsp-Time and 3gpp-Sbi-Sender-Timestamp headers.

Note:

If any of the expected headers is malformed, the SCP will not reject the request and will instead fall back to the existing routing behavior.

Managing 3GPP Timestamp Related Headers

Enable

To enable this feature, you must set the Timestamp Header Support option to true as described in Configuring SCP Features.

Configure

You can configure this feature using REST API and the CNC Console.

• Configure using CNC Console: For information about CNC Console configurations, see Configuring 3GPP Timestamp Headers Support.
• Configure using REST API: For information about configuring REST APIs, see "Configuring SCP Features" in Oracle Communications Cloud Native Core, Service Communication Proxy REST Specification Guide.

Observe

The following metrics are added in the Metrics section:

• ocscp_worker_transaction_time_exhausted_total
• ocscp_worker_timestamp_headers_validation_fail_total
• ocscp_nrfproxy_transaction_time_exhausted_total
• ocscp_oauth_transaction_time_exhausted_total

This feature depends on accurate time synchronization between network functions (NFs) and the SCP. If the time between them is not synchronized, it can result in request routing failures due to incorrect calculations of timeout values.

Maintain

If you encounter alerts at system level, see the Alerts section for resolution steps.

In case the alerts persist, perform the following tasks:

1. Collect the logs: For information about how to collect logs, see Oracle Communications Cloud Native Core, Service Communication Proxy Troubleshooting Guide.
2. Raise a service request: For information about how to raise a service request, see My Oracle Support.

3.12.2 Support for Multiple 3gpp-Sbi-Binding Headers

SCP enhanced its capabilities to support multiple 3GPP-SBI-binding headers within a single Service-Based Interface (SBI) message. In accordance with the support for additional standard HTTP2 headers specified in 3GPP TS 29.500, the SCP routes SBI request and response messages that contain multiple 3GPP-SBI-binding headers. It ensures the headers in the messages are forwarded to the producer exactly as received, without any additional processing or interpretation of the headers. The request and response messages includes:

• Notification messages
• Service messages

The feature supports the following header formats:

• Simple key-value pairs: k=v1, k=v2
• Array format: k=[v1,v2]

This feature is applicable to both Model C and Model D call flows and is implemented for the R16 deployment only.

Managing Support for Multiple 3gpp-Sbi-Binding Headers

Enable

Not applicable

Configure

Not applicable

Observe

There are no specific metrics and alerts required for the Multiple 3gpp-Sbi-Binding Headers.

Maintain

If you encounter alerts at system level, see the Alerts section for resolution steps.

In case the alerts persist, perform the following tasks:

1. Collect the logs: For information about how to collect logs, see Oracle Communications Cloud Native Core, Service Communication Proxy Troubleshooting Guide.
2. Raise a service request: For information about how to raise a service request, see My Oracle Support.

3.12.3 Support for 3gpp-Sbi-Custom-UDR-Nf-Group-Id

When an NF sends a SBI message request or response with the custom header, 3gpp-Sbi-Custom-UDR-Nf-Group-Id, SCP sends the message request or response, including the custom header, to the target NF.

Managing 3gpp-Sbi-Custom-UDR-Nf-Group-Id Header Support at SCP

Enable

This feature doesn't require a flag to be enabled or disabled and is enabled by default.

Configure

There's no specific configuration required for this feature.

Maintain

If you encounter alerts at the system level, see the Alerts section for resolution steps.

In case the alerts persist, perform the following tasks:

1. Collect the logs: For information about how to collect logs, see Oracle Communications Cloud Native Core, Service Communication Proxy Troubleshooting Guide.
2. Raise a service request: For information about how to raise a service request, see My Oracle Support.

3.13 Routing Options Enhancement to Control SCP Routing Features

At SCP, there are a number of routing features such as Circuit Breaking, Outlier Detection and so on that proactively track the producer NF to determine the load conditions and health status of the producer NF and perform alternate routing of incoming SBI messages that are targeted towards the degraded producer NFs.

With this enhancement, SCP supports proactive rerouting, in which a user can control the applicability of routing features at the NF service level by providing options to enable or disable rerouting.

The following routing features at the NF service level can be enabled or disabled:

• Congestion control based on Producer load
  • Using producer load from NRF
  • Using producer load in the LCI header
• Circuit Breaking
• Outlier Detection

Note:

Alternate routing based on the following conditions are not impacted by this enhancement:

• Error received from the producer
• Request a timeout at the SCP
• Transport error at SCP during connection creation

Managing Routing Options Enhancements

Enable

You can enable this feature by setting odEnabled, loadBasedCongestionControlEnabled, cbEnabled parameters to true. For more information, see Configuring Global Options, Configuring Routing Options, and Configuring Routing Config Set respectively.

Configure

You can configure this feature using REST APIs as described in "Routing Option Configuration", "Congestion Control Configuration", "Routing Config Set", "Circuit Breaking Configuration", "Configuring Routing Option", and "Configuring System Option" in Oracle Communications Cloud Native Core, Service Communication Proxy REST Specification Guide.

Maintain

If you encounter alerts at the system level, see the Alerts section for resolution steps.

In case the alerts persist, perform the following tasks:

1. Collect the logs: For information about how to collect logs, see Oracle Communications Cloud Native Core, Service Communication Proxy Troubleshooting Guide.
2. Raise a service request: For information about how to raise a service request, see My Oracle Support.

3.13.1 Alternate Routing Configuration Based on Received Status Code 504, Expired Response Timeout and Connection Error

SCP enhances the routing of Service-Based Interface (SBI) requests by allowing configurable error code-based rerouting. This improvement allows users to configure retries based on timeouts received from upstream producers, locally detected timeouts, or both.

Previously, SCP rerouted requests based on HTTP response codes from upstream NF, SCP, or SEPP. If a request timed out and no response was received, SCP automatically rerouted the request when retries were enabled, using the configured error code of 504.

The following enhancements allow better error handling capabilities:

• Customizing Configuration for Rerouting on Timeout: It allows you to enable or disable rerouting of requests that encounter a local timeout, such as response timeouts detected by SCP, providing flexibility to manage routing based on operational requirements.
• Timeout Differentiation Functionality: It distinguishes between local timeouts (indicated by a local 504 response) and 504 responses received from upstream components.
• Support for Error Conditions for Alternate Routing: If SCP faces other errors such as connectionError or timeout, while routing to the upstream server, and if these errors are configured, SCP tries rerouting based on the configured alternate routing mechanism. The following error condition parameters can be used in rerouteConditionList:
  • connectionError: When SCP tries to send requests but fails due to any connection error, SCP relies on lower layers for getting exceptions on any connection error.
  • timeout: When SCP sends requests but does not receive any response from upstream, SCP timeout occurs locally waiting for a response.
  For more information about connectionError and timeout, see "Configuring Routing Config Set" in Oracle Communications Cloud Native Core, Service Communication Proxy REST Specification Guide.

Managing Alternate Routing Configuration

Enable

This feature is integrated with the alternate routing functionality.

Configure

You can configure this feature using REST API and the CNC Console.

• Configure using CNC Console: For information about CNC Console configurations, see Configuring Routing Config Set.
• Configure using REST API: For information about configuring REST APIs, see "Routing Config Set" in Oracle Communications Cloud Native Core, Service Communication Proxy REST Specification Guide

Maintain

If you encounter alerts at the system level, see the Alerts section for resolution steps.

In case the alerts persist, perform the following tasks:

1. Collect the logs: For information about how to collect logs, see Oracle Communications Cloud Native Core, Service Communication Proxy Troubleshooting Guide.
2. Raise a service request: For information about how to raise a service request, see My Oracle Support.

3.14 Enhanced NF Status Processing

In older SCP releases, SCP removes routing rules when SCP receives an NFProfile with the SUSPENDED status.

With the enhanced NF Status Processing feature, Service Communication Proxy (SCP) provides the following 5G Service Based Interface (SBI) message request routing modes when an NFProfile is in the SUSPENDED state:

• Mode 1: SCP does not route message requests to producer NFs that are in the SUSPENDED state.
• Mode 2: SCP routes the message request to the target producer NF even if it is in the SUSPENDED state.
• Mode 3: SCP routes the message request to producer NFs that are in the SUSPENDED state only if alternate REGISTERED producer NFs are unavailable.

Note:

When an NFProfile is SUSPENDED, it remains in the SUSPENDED state for an infinite duration unless NRF marks it as REGISTERED, or it gets DE-REGISTERED.

In case of Mode 2 routing, when SCP receives a 5G SBI message request from a consumer NF, SCP considers all NFs that are configured using the suspendedStateRouting REST API parameter to route the message request.

In case of Mode 3 routing, when SCP receives a 5G SBI message request from a consumer NF, if the target producer NF is SUSPENDED, SCP routes the message to the first alternate producer NF, which is in the REGISTERED state. If the alternate REGISTERED producer NF is unavailable or responds with an error response, SCP routes the message request to the next available producer NF, which is in the REGISTERED state.

After exhausting all the routing attempts on REGISTERED producer NFs, if alternate routing attempts are available, SCP routes the message request to the SUSPENDED producer NFs if the enhanced_nf_status_processing.enhancedSuspendedStateRouting REST API parameter is set for a particular NF type. Otherwise, SCP returns the same error response to the consumer NF that it received due to the routing attempted on the last producer NF. SCP determines the target producer NF using the "3gpp-Sbi-Target-apiRoot" header and NF Set ID in the message request.

Note:

You must not configure the same NF type for enhancedSuspendedStateRouting and suspendedStateRouting for both Mode 2 and Mode 3.

Managing Enhanced NF Status Processing

Enable

You can enable this feature using the CNC Console as described in Configuring SCP Features.

Configure

You can enable and configure one of the following routing modes of this feature:

• Mode 1: Set enhanced_nf_status_processing to false.
• Mode 2: Set enhanced_nf_status_processing to true and configure suspendedStateRouting.
• Mode 3: Set enhanced_nf_status_processing to true and enhancedSuspendedStateRouting must be present.

For more information about the above mentioned REST API parameters, see "Configuring SCP Features" in Oracle Communications Cloud Native Core, Service Communication Proxy REST Specification Guide.

Observe

For information about metrics, see Metrics.

Maintain

If you encounter alerts at the system level, see the Alerts section for resolution steps.

In case the alerts persist, perform the following tasks:

1. Collect the logs: For information about how to collect logs, see Oracle Communications Cloud Native Core, Service Communication Proxy Troubleshooting Guide.
2. Raise a service request: For information about how to raise a service request, see My Oracle Support.

3.15 Support for Default Notification Message Routing

During NF profile registration or update, NF has the ability to publish the Notification URI for default notifications. This is crucial due to the expected default Subscriptions in NF profiles. SCP plays a vital role in this process by creating routing rules for the purpose of routing 5G SBI messages. SCP achieves this by obtaining knowledge of the 5G topology from the NRF through NF status notifications. Previously, the SCP's topology learning did not include the default notification callback URI information published in the defaultNotificationSubscription attribute of the NF profile. Consequently, SCP remained unaware of these default notification callback URIs and was unable to do alternate routing of received default notification messages.

SCP has now significantly improved its topology learning process by incorporating the default notification URI and endpoint from both the NF profile and NF service level. As a result, SCP is now fully informed about these default notification callback URIs and possesses the capability to efficiently do routing and alternate routing of received default notification messages.

Managing Default Notification Message Routing

Enable

This feature is enabled by default in SCP at the time of deployment.

Configure

You can view or edit the default notification message subscription feature using the CNC Console. For information about this feature, see "Viewing or Editing the Default Notification Subscriptions section" in Configuring NF Rule Profile to view the default notification message subscriptions that are present under NF service level or NF profile level.

Maintain

If you encounter alerts at system level, see the Alerts section for resolution steps.

In case the alerts persist, perform the following tasks:

1. Collect the logs: For information about how to collect logs, see Oracle Communications Cloud Native Core, Service Communication Proxy Troubleshooting Guide.
2. Raise a service request: For information about how to raise a service request, see My Oracle Support.

3.15.1 Default Notification Routing Behavior at SCP

The expected behavior at SCP based on the presence of various headers is as follows:

Table 3-17 Default Notification Routing Behavior

Pseudo Header	3GPP 5G SBI Custom Header									Expected Behavior at SCP
":path"	3gpp-sbi-target-apiRoot Header	3gpp-Sbi-Callback Header	3gpp-Sbi-Discovery-notification-type(Mandatory) Header	3gpp-Sbi-Discovery-target-nf-type Header	3gpp-Sbi-Discovery-requester-nf-type Header	3gpp-Sbi-Discovery-n1-msg-class Header	3gpp-Sbi-Discovery-n2-info-class Header	3gpp-Sbi-Discovery-* Header	3gpp-sbi-Routing-binding Header	-
"/scp-default-sub-notify-uri"	Absent	Present	Present	Present	Present	Optional (don't care)	Optional (don't care)	Optional (don't care)	NA	SCP performs the discovery and gets the callback URI from the selected producer's profile for the given notification type. Note: Only apiversion is considered from 3gpp-Sbi-Callback.
"/scp-default-sub-notify-uri"	Absent	Present	Absent	Present	Present	Optional (don't care)	Optional (don't care)	Optional (don't care)	NA	400 Bad request cause: query parameter missing (TS29.500)
"/scp-default-sub-notify-uri"	Absent	Absent	Present	Present	Present	Optional (don't care)	Optional (don't care)	Optional (don't care)	NA	SCP performs the discovery and gets the callback URI from the selected producer's profile for the given notification type at the NF profile level defaultnotifcation/subscription parameters. This is the default notification due to the presence of the 3gpp-Sbi-Discovery-notification-type header. apiversion=1 Note: Only apiversion is considered from 3gpp-Sbi-Callback. If not, the apiversion will be assumed to be 1.
"/scp-default-sub-notify-uri"	Absent	Absent	Absent	Present	Present	Optional (don't care)	Optional (don't care)	Optional (don't care)	NA	400 Bad request cause: query parameter is missing (TS29.500)
non "/scp-default-sub-notify-uri"	Absent	Present	Present	Present	Present	Optional (don't care)	Optional (don't care)	Optional (don't care)	Absent	SCP performs the discovery and gets the callback URI from the selected producer's profile for the given notification type. SCP modifies the :path header as per the selected notification endpoint.
non "/scp-default-sub-notify-uri"	Absent	Present	Absent	Present	Present	Optional (don't care)	Optional (don't care)	Optional (don't care)	Absent	Selection of NF is dependent on the discovery response. The path will remain the same as it was when the consumer made their original request. Furthermore, the notification processing is non-default. For example, explicit notification since 3gpp-Sbi-Callbackheader is present. Note: The callbackUri from defaultNotificationSubscriptions section is not considered. It goes with the typical rule match. For more information, see Note at the bottom of this table if the notification message is without a service name.
non "/scp-default-sub-notify-uri"	Absent	Absent	Present	Present	Present	Optional (don't care)	Optional (don't care)	Optional (don't care)	Absent	SCP performs the discovery and gets the callback URI from the selected producer's profile for the given notification type at the NF profile level defaultnotifcation/subscription parameters. This is the default notification due to the presence of the 3gpp-Sbi-Discovery-notification-type header. apiversion=1
non "/scp-default-sub-notify-uri"	Absent	Absent	Absent	Present	Present	Optional (don't care)	Optional (don't care)	Optional (don't care)	Absent	Selection of NF is dependent on the discovery response. The path will remain the same as it was when the consumer made their original request. Moreover, non-default notification processing, normal discovery, and NF selection processing is applied. Note: The callbackUri from defaultNotificationSubscriptions section is not considered. It goes with the typical rule match. For more information, see Note at the bottom of this table if the notification message is without a service name.
non "/scp-default-sub-notify-uri"	Absent	Present	Present	Present	Present	Optional (don't care)	Optional (don't care)	Optional (don't care)	Present	SCP does callback URI selection based on 3gpp-Sbi-Routing-Binding header information along with other received header information.
non "/scp-default-sub-notify-uri"	Absent	Present	Absent	Present	Present	Optional (don't care)	Optional (don't care)	Optional (don't care)	Present	NF selection is based on 3gpp-Sbi-Routing-Binding header information along with other received header information.
non "/scp-default-sub-notify-uri"	Absent	Absent	Present	Present	Present	Optional (don't care)	Optional (don't care)	Optional (don't care)	Present	SCP does callback URI selection based on 3gpp-Sbi-Routing-Binding header information along with other received header information.
non "/scp-default-sub-notify-uri"	Absent	Absent	Absent	Present	Present	Optional (don't care)	Optional (don't care)	Optional (don't care)	Present	NF selection is based on 3gpp-Sbi-Routing-Binding header information along with other received header information.
"/scp-default-sub-notify-uri"	Present	Present	Present	Present	Present	Optional (don't care)	Optional (don't care)	Optional (don't care)	NA	First Attempt: Normal route to the selected producer with the received :path header. Alternate Attempt: SCP performs the discovery and gets the callback URI from the selected producer's profile for the given notification type. SCP modifies the :path header as per the selected notification endpoint.
"/scp-default-sub-notify-uri"	Present	Present	Absent	Present	Present	Optional (don't care)	Optional (don't care)	Optional (don't care)	NA	First Attempt: Normal route to the selected producer with the received :path header. Alternate Attempt: Non-default notification processing, normal discovery, and NF selection processing Note: The callbackUri from defaultNotificationSubscriptions section is not considered. It goes with the typical rule match. For more information, see Note at the bottom of this table if the notification message is without a service name
"/scp-default-sub-notify-uri"	Present	Absent	Present	Present	Present	Optional (don't care)	Optional (don't care)	Optional (don't care)	NA	First Attempt: Normal route to the selected producer with the received :path header. Alternate Attempt: SCP performs the discovery and gets the callback URI from the selected producer's profile for the given notification type. SCP modifies the :path header as per the selected notification endpoint
"/scp-default-sub-notify-uri"	Present	Absent	Absent	Present	Present	Optional (don't care)	Optional (don't care)	Optional (don't care)	NA	First Attempt: Normal route to the selected producer with the received :path header. Alternate Attempt: Non-default notification processing, normal discovery, and NF selection processing Note: The callbackUri from defaultNotificationSubscriptions section is not considered. It goes with the typical rule match. For more information, see Note at the bottom of this table if the notification message is without a service name.
non "/scp-default-sub-notify-uri"i.e., notification/callback URI	Present	Present	Present	Present	Present	Optional (don't care)	Optional (don't care)	Optional (don't care)	Absent	Model C Default notification processing with selected notification endpoint. First Attempt: Normal route to the selected producer with the received :path header.Alternate route: SCP performs the discovery and gets the callback URI from the selected consumer’s profile for the given notification type and apiversion in the callback header. SCP modifies the :path header as per the selected notification endpoint.
non "/scp-default-sub-notify-uri"i.e., notification/callback URI	Present	Present	Absent	Present	Present	Optional (don't care)	Optional (don't care)	Optional (don't care)	Absent	Explicit notification processing The first routing is based on the 3gpp-target-apiRoot header. Alternate routing is based on normal discovery and NF selection processing, as applicable. Note: The callbackUri from defaultNotificationSubscriptions section is not considered. It goes with the typical rule match. For more information, see Note at the bottom of this table if the notification message is without a service name.
non "/scp-default-sub-notify-uri"i.e., notification/callback URI	Present	Absent	Present	Present	Present	Optional (don't care)	Optional (don't care)	Optional (don't care)	Absent	Model C Default notification processing with selected notification endpoint. First Attempt: Normal route to the selected producer with the received :path header. Alternate route: SCP performs the discovery and gets the callback URI from the selected producer's profile for the given notification type at the NF profile level defaultnotifcation/subscription parameters. In the absence of a callback header, apiversion=1 is considered. This is the default notification due to the presence of the 3gpp-Sbi-Discovery-notification-type header. apiversion=1
non "/scp-default-sub-notify-uri"i.e., notification/callback UR	Present	Absent	Absent	Present	Present	Optional (don't care)	Optional (don't care)	Optional (don't care)	Absent	Non Default notification processing The first routing is based on the 3gpp-target-apiRoot header. Alternate routing is based on normal discovery and NF selection processing, as applicable. Note: The callbackUri from defaultNotificationSubscriptions section is not considered. It goes with the typical rule match. For more information, see Note at the bottom of this table if the notification message is without a service name.
non "/scp-default-sub-notify-uri” i.e., notification/callback URI	Present	Present	Present	Present	Present	Optional (don't care)	Optional (don't care)	Optional (don't care)	Present	Model C Default notification processing with selected notification endpoint. First Attempt: Normal route to the selected producer with the received :path header. Alternate route: SCP does callback uri selection based on 3gpp-Sbi-Routing-Binding header information along with other received header information. SCP gets the callback URI from the selected consumer’s profile for the given notification type and apiversion in the callback header. SCP modifies the :path header as per the selected notification endpoint. Note: 1. If servName is present in the 3gpp-sbi-Routing-binding header, then SCP gets the callback URI from the selected consumer’s profile for the given notification type for that service name. 2. If servName is absent in the 3gpp-sbi-Routing-binding header, then SCP gets the callback URI from the selected consumer’s profile for the given notification type from service level. If it is not found at the service level, it gets the callbackURI from the profile level.
non "/scp-default-sub-notify-uri” i.e., notification/callback URI	Present	Present	Absent	Present	Present	Optional (don't care)	Optional (don't care)	Optional (don't care)	Present	Explicit notification processing The first routing is based on the 3gpp-target-apiRoot header. Alternate routing is based on 3gpp-Sbi-Routing-Binding header information along with other received header information and NF selection processing as applicable. Note: The callbackUri from defaultNotificationSubscriptions section is not considered. It goes with the typical rule match. For more information, see Note at the bottom of this table if the notification message is without a service name. Note: Alternate routing is only performed when servName is present in the 3gpp-sbi-Routing-binding header.
non "/scp-default-sub-notify-uri” i.e., notification/callback URI	Present	Absent	Present	Present	Present	Optional (don't care)	Optional (don't care)	Optional (don't care)	Present	Model C Default notification processing with selected notification endpoint. First Attempt: Normal route to the selected producer with the received :path header. Alternate route: SCP does callback uri selection based on 3gpp-Sbi-Routing-Binding header info along with other received header info. SCP gets the callback URI from the selected producer's profile for the given notification type at the NF profile level defaultnotifcation/subscription parameters. In the absence of a callback header, apiversion=1 will be considered. This is the default notification due to the presence of the 3gpp-Sbi-Discovery-notification-type header. apiversion=1 Note: If servName is absent in the 3gpp-sbi-Routing-binding header, then SCP gets the callback URI from the selected consumer’s profile for the given notification type from service level. If it is not found at the service level, it gets the callbackURI from the profile level.
non "/scp-default-sub-notify-uri” i.e., notification/callback URI	Present	Absent	Absent	Present	Present	Optional (don't care)	Optional (don't care)	Optional (don't care)	Present	Non-default notification processing The first routing is based on the 3GPP-target-apiRoot header. Alternate routing is based on 3gpp-Sbi-Routing-Binding header information along with other received header information and NF selection processing as applicable. Note: The callbackUri from defaultNotificationSubscriptions section is not considered. It goes with the typical rule match. For more information, see Note at the bottom of this table if the notification message is without a service name. Note: Alternate Routing is only performed in case when servName is present in 3gpp-sbi-Routing-binding header.

Note:

SCP behavior for Notification message without service name is as follows:

• SCP does the rule match or delegated discovery based on available information from the service request.
• SCP selects profile level FQDN for routing.
• SCP uses 80 as the default port for routing.
• SCP uses "http" as the default port for routing.

3.16 Location Header for Host Mismatch

According to 3GPP, a consumer NF is expected to use the received "Location" header content while sending subsequent message requests. After receiving a subsequent request, consumer SCP extracts the producer NF details from the API prefix in the "3gpp-Sbi-Target-Apiroot" header and selects an appropriate inter-SCP path to route the request.

SCP matches the authority (FQDN or IP) in "Location" header of the "201 Created" response with the producer's authority (FQDN or IP) where the message request was sent. If the FQDN or IP in the response is different, producer SCP provides the producer's NF details as an API prefix in the "Location" header of the "201 Created" response. If the FQDN or IP is the same, the "Location" header does not perform any modification.

This feature has been introduced to correct inter-SCP routing in the above scenario.

Figure 3-4 Initial and Subsequent Request Routing Supported at SCP

Managing Location Header for Host Mismatch

Enable

By default, this feature is disabled. To enable this feature, you must set the location_hdr_update_for_host_mismatch option to true as described in Configuring SCP Features.

Configure

You can configure this feature using REST API and the CNC Console.

• Configure using CNC Console: For information about configuring this feature, see Configuring SCP Features to enable the location header update for host mismatch feature.
• Configure using REST API:

  Previously, SCP used to support the above scenario through a Helm configuration in values.yaml using the fqdnAliasingEnabled field. Now a REST API parameter, location_hdr_update_for_host_mismatch, is introduced to enable this feature.

  For information about configuring REST APIs, see "Configuring SCP Features" in Oracle Communications Cloud Native Core, Service Communication Proxy REST Specification Guide.

Maintain

If you encounter alerts at system level, see the Alerts section for resolution steps.

In case the alerts persist, perform the following tasks:

1. Collect the logs: For information about how to collect logs, see Oracle Communications Cloud Native Core, Service Communication Proxy Troubleshooting Guide.
2. Raise a service request: For information about how to raise a service request, see My Oracle Support.

3.17 Support for the Client Credentials Assertion Header

The 3GPP introduced Client Credentials Assertion (CCA) enables the NRF or the producer NF to authenticate the consumer NF when using indirect communication through SCP. The CCAs are JSON web tokens and are secured with digital signatures based on JSON Web Signature (JWS). The consumer NF adds the 3gpp-Sbi-Client-Credentials header containing the CCA. The CCA contains the following:

• The NF instance ID of the consumer NF (subject)
• A timestamp (iat) and an expiration time (exp)
• The NF type of the expected audience, such as the NRF type or the NF type of the producer NF

The consumer NF digitally signs the generated CCA based on its private key. The signed CCA contains one of the following fields:

• The X.509 URL (x5u) to refer to a resource for the X.509 public key certificate or certificate chain used for signing the client authentication assertion
• The X.509 Certificate Chain (x5c) includes the X.509 public key certificate or certificate chain used for signing the client authentication assertion

Note:

SCP supports the 3gpp-Sbi-Client-Credentials header with x5c - X.509 URL, not x5u - X.509 URL.

Table 3-18 CCA Contents

Claim	Description
audience (aud)	NF type of the producer NF whose services are requested and/or NRF
expiration time (exp)	Timestamp of CCA expirarion
subject (sub)	NF instance ID of consumer NF
timestamp (iat)	Timestamp of CCA generation
Security details used for signing CCA	x5u - X.509 URL that refers to a resource for the X.509 public key certificate or certificate chain x5c - X.509 Certificate Chain includes the X.509 public key certificate or certificate chain

The NRF, or producer NF, performs the CCA verification. It verifies that the public key certificate used to sign the CCA contains the same NF instance ID as the consumer's NF instance ID in the CCA. If the verification of the CCA fails at the receiving entity, a "403" response is returned with the cause attribute set to CCA_VERIFICATION_FAILURE.

If some rouge consumer NF acquires a valid CCA from some other consumer NF and uses it as its own CCA, then the CCA validation by the NRF or producer NF creates a security gap. Therefore, additional CCA validations on SCP are needed to mitigate this security impact. The NF instance ID of the NFs in the CCA must match the NF instance ID in the certificate used in the TLS connection by the consumer NF as part of the SCP validations.

Managing Client Credentials Assertion Header

Enable

By default, this feature is disabled. To enable this feature, you must complete the configuration as described in the following configuration section.

Configure

You can configure this feature using REST API and the CNC Console.

• Configure using CNC Console: For information about configuring this feature, see:
  • Configuring SCP Features to enable the CCA Header Validation feature
  • Configuring Error Profile to edit the error profiles
• Configure using REST API: For information about configuring REST APIs, see "Configuring SCP Features" and "Configuring Error Profile" in Oracle Communications Cloud Native Core, Service Communication Proxy REST Specification Guide.

Observe

The following metrics are added in the Metrics section:

• ocscp_worker_cca_validation_failed_total
• ocscp_worker_cca_validation_feature_enabled_without_https
• ocscp_worker_cca_validation_performed_total

Added the SCPCcaFeatureEnabledWithoutHttps alert in the Alerts section.

Maintain

If you encounter alerts at system level, see the Alerts section for resolution steps.

In case the alerts persist, perform the following tasks:

1. Collect the logs: For information about how to collect logs, see Oracle Communications Cloud Native Core, Service Communication Proxy Troubleshooting Guide.
2. Raise a service request: For information about how to raise a service request, see My Oracle Support.

3.18 Support for 5G SBI Message Correlation using the 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 this header, the UE identifier used is Subscription Permanent Identifier (SUPI), and the SUPI type is an International Mobile Subscriber Identity (IMSI). For example, 3gpp-Sbi-Correlation-Info: imsi-345012123123123

SCP efficiently routes message requests, along with the 3gpp-Sbi-Correlation-Info header, to the designated producer NFs. In cases where the correlation header is absent in the response from the target producer NF, SCP forwards the response to the consumer NF while appending the same 3gpp-Sbi-Correlation-Info header received in the request message. Additionally, when the correlation header is present in the request message and SCP generates an error response, SCP includes the correlation header in the response to the consumer NF. This ensures smooth and consistent correlation of 5G SBI messages throughout the system.

SCP adds the correlation header in the following cases if the request from the consumer contains this header:

• Access token requests toward NRF received from Model-C consumer NF.
• Discovery requests or access token requests toward NRF received in service request for delegated discovery in Model-D.
• During alternate routing.
• All the transaction in SCP is forwarded with correlation header toward traffic feed server to save the data in Traffic Feed OCNADD.

Managing Support for 3gpp-Sbi-Correlation-Info Header

Enable

Not applicable

Configure

Not applicable

Observe

There is no specific metrics and alerts required for the Support for 3gpp-Sbi-Correlation-Info Header.

3.19 SCP Health Check API

In the previous release, consumer NFs used to send Service Based Interface (SBI) message requests to SCP without checking the status of SCP because there was no health check mechanism implemented at SCP.

Using the SCP Health Check Application Programming Interface (API) feature, consumer NFs can determine the health status of SCP before forwarding any SBI message request to SCP. This feature allows consumer NFs or SCP-C, which is a consumer SCP, to perform the following health check verification on SCP:

• SCP Reachable: Determines if SCP is reachable through the transport path.
• SCP Available: Determines if SCP is available to provide responses to SBI message requests.

Note:

• This feature supports HTTP/2
• Health check fails if either of the above mentioned requirements is not achieved.

SCP provides the RESTful health check service Uniform Resource Identifier (URI) (/{scpapiRoot}/{apiVersion}/status) to consumer NFs to confirm its availability to process the message requests. Consumer NFs can use the following URI to get the status of SCP:

• Method: OPTIONS
• Resource URIs:
  • <scheme>://<Scp-worker Fqdn>:<Port>/{apiVersion}/status
  • <scheme>://<Scp-worker Fqdn>:<Port>/{apiPrefix}/{apiVersion}/status

This feature facilitates consumer NFs to determine the health status of SCPs by sending the health query request to SCPs. Based on the health query response, consumer NFs decide whether to send SBI message requests to that SCP or perform alternate routing on other healthy SCP.

SCP uses the following process to provide its health status to a consumer NF:

1. When SCP receives a health query request, it calculates its overall average load by considering the load of each SCP-Worker instance present in that SCP.
2. SCP compares the overall average load with the configured values of the avgScpLoadThresholdValue REST API parameter as described in "Configuring SCP Features" in Oracle Communications Cloud Native Core, Service Communication Proxy REST Specification Guide.
3. If the overall average load value is more than the value of avgScpLoadThresholdValue, SCP is considered as unhealthy and SCP sends error responses to the consumer NF based on the healthCheckErrorProfile parameter as described in "Configuring Error Profiles" in Oracle Communications Cloud Native Core, Service Communication Proxy REST Specification Guide.
4. If the overall average load value is less than or equal to the value of avgScpLoadThresholdValue, SCP is considered as healthy and SCP sends one of the following responses to the consumer NF based on the configuration:
   • 200WithPayLoad: Sends 200 OK response code with the overall average load information of SCP.
   • 200WithEmptyPayload: Sends 200 OK response code without the overall average load information of SCP.
   • 204WithNoContent: Send only 204 response code with no other information.

Inter-SCP Health Check

In inter-SCP health check scenarios, a consumer SCP-C performs health check query on peer SCP instances before sending any SBI message request.

When a consumer SCP-C receives a health query request from a consumer NF, it checks for the availability of a healthy SCP-P to which the SBI message request can be forwarded.

The following procedure describes how a consumer SCP-C checks the status of peer producer SCP-P instances:

1. SCPC-Notification sends the InterScpList to SCPC-Audit through REST APIs if the isScpHealthCheckSvcEnabled REST API parameter is enabled. For more information about this parameter, see "Configuring SCP Features" in Oracle Communications Cloud Native Core, Service Communication Proxy REST Specification Guide.
2. SCPC-Configuration sends the configuration information, such as isScpHealthCheckSvcEnabled, time interval to trigger periodic health query polls, number of consecutive positive responses, number of negative responses, and so on, to SCPC-Audit.
3. SCPC-Audit periodically triggers health check query polls to SCP-P through SCP-Worker of SCP-C with 3gppapiroot: scp-pfqdn+ruriPath of health query if the isScpHealthCheckSvcEnabled REST API parameter is enabled.
4. SCP-Worker forward the health query request received from SCPC-Audit toward SCP-P.
5. SCP-P responds with its health query status.
6. SCPC-Audit obtains the response for the health query request from SCP-P through SCP-Worker.
7. SCPC-Configuration sends the configuration information, such as isScpHealthCheckSvcEnabled, time interval to trigger periodic health query polls, number of consecutive positive responses, number of negative responses, and so on, to SCP-Worker.
8. SCPC-Audit sends the health status of the inter-SCPs to SCP-Worker for the inter-SCP messages processing.

Managing SCP Health Check API

Enable

By default, this feature is enabled at the ingress side. However, in case of inter-SCP scenarios, this feature is disabled by default. To enable this feature, you must set the health_check option to true as described in Configuring SCP Features.

Configure

You can configure this feature using REST API and the CNC Console.

• Configure using CNC Console: For information about CNC Console configurations, see Configuring SCP Features.
• Configure using REST API: For information about configuring REST APIs, see "Configuring SCP Features" and "Configuring Error Profiles" in Oracle Communications Cloud Native Core, Service Communication Proxy REST Specification Guide.

Observe

The following metrics are added in the Metrics section:

• ocscp_worker_health_check_rx_req_total
• ocscp_worker_health_check_success_res_total
• ocscp_worker_health_check_error_res_total
• ocscp_interscp_health_check_status_success_total
• ocscp_interscp_health_check_status_failure_total
• ocscp_health_check_status_failed
• ocscp_interscp_health_check_status_failed
• ocscp_audit_interscp_health_check_tx_req_total
• ocscp_audit_interscp_health_check_rx_res_total

The following alerts are added in the Alerts section:

• SCPHealthCheckFailedForPeerSCP
• SCPHealthCheckFailed

Maintain

If you encounter alerts at system level, see the Alerts section for resolution steps.

In case the alerts persist, perform the following tasks:

1. Collect the logs: For information about how to collect logs, see Oracle Communications Cloud Native Core, Service Communication Proxy Troubleshooting Guide.
2. Raise a service request: For information about how to raise a service request, see My Oracle Support.

3.20 Verbose Logging for SCP

SCP warn and error level logs are enhanced to display more information to ease the troubleshooting process for various issues in the production environment.

The Verbose Logging for SCP feature defines a common log format to include required information to enhance debugging process for WARN and ERROR logs. Using the following log format, ERROR and WARN level logs are modified to standardize the log format, add more details, and enhance readability:

The following is the log level format for SCP-Worker and SCP-nrfproxy microservices:

• WARN: Category: <<category>>, Event: <<Event>>, Details: <<Message_Details>>
• ERROR: Category: <<category>>, Event: <<Event>>, Details: <<Message_Details>>, Exception: {Cause:<<Exception_cause>>, Message: <<Exception_Message>>, StackTrace: <<Exception_Stacktrace>>}

The following is the log level format for SCP-notification microservice:

• WARN: Category: <<category>>, Event: <<Event>>, EventID: <<App-Event-ID>>, Details: <<Message_Details>>
• ERROR: Category: <<category>>, Event: <<Event>>, EventID: <<App-Event-ID>>, Details: <<Message_Details>>, Exception:{Cause:<<Exception_cause>>, Message: <<Exception_Message>>, StackTrace: <<Exception_Stacktrace>>}

The following is the log level format for SCP-audit microservice:

• WARN: Category: <<category>>, Event: <<Event>>, EventID: <<App-Event-ID>>, Details: <<Message_Details>>
• ERROR: Category: <<category>>, Event: <<Event>>, EventID: <<App-Event-ID>>, Details: <<Message_Details>>, Exception:{Cause:<<Exception_cause>>, Message: <<Exception_Message>>, StackTrace: <<Exception_Stacktrace>>}

OR

• WARN: Category: <<category>>, Event: <<Event>>, EventID: <<App-Event-ID>>, CustomString: <<Audit-Type>>, Details: <<Message_Details>>
• ERROR: Category: <<category>>, Event: <<Event>>, EventID: <<App-Event-ID>>, CustomString: <<Audit-Type>>, Details: <<Message_Details>>, Exception:{Cause:<<Exception_cause>>, Message: <<Exception_Message>>, StackTrace: <<Exception_Stacktrace>>}

The following is the log level format for SCP-loadManager microservice:

• WARN: Category: <<category>>, Event: <<Event>>, EventID: <<App-Event-ID>>, Details: <<Message_Details>>
• ERROR: Category: <<category>>, Event: <<Event>>, EventID: <<App-Event-ID>>, Details: <<Message_Details>>, Exception:{Cause:<<Exception_cause>>, Message: <<Exception_Message>>, StackTrace: <<Exception_Stacktrace>>}

Note:

• This feature supports SCP-Worker and SCP-nrfproxy microservice with WARN and ERROR level logs.
• SCP is deployed with WARN level log in the production environment. This is applicable for SCP-Worker and SCP-nrfproxy microservice.
• SCP is deployed with INFO level log in the production environment. This is applicable for SCP-notification, SCP-audit, and SCP-loadmanager microservices.

The SCP log format is made verbose to follow a common format for WARN and ERROR log levels to determine and investigate issues in various events as described in the following table:

Table 3-19 Log Attributes

Log Attribute	Description
Category	Determines the category of log messages.
Event	Represents logged message event type.
EventID	Unique ID to identify associated category and sub category for logged message. EventID format: OSCP-XXX-YY-ZZZ, where XXX: Represents Micro service codes YY: Represents Category ZZZ: Represents Event TYPE Note: This log attribute is only applicable for SCP-notification, SCP-audit, and SCP-loadmanager microservices.
Message_Details	Represents the actual message defining the error.
Exception_cause	Returns the cause of an error.
Exception_Message	Represents actual exception message.
Exception_Stacktrace	Contains complete stack trace which is causing the error.
CustomString	Represents a custom string field with enumerated valid values. Note: This log attribute is only applicable for SCP-audit microservice. In Audit microservice, the AuditType can have specific values such as SCHEDULED or OnDemandAudit.

The new log format provides comprehensive information about an issue comprising issue category, event name, and detailed description of the issue to help you identify and resolve errors.

The following table describes log levels for various event types:

Table 3-20 Log Levels for SCP-Worker

Category	Event	Log Level	Description
Up Stream	Connection Timeout	ERROR	This event is raised when the connection fails due to connect timeout expiry.
	Request Timeout	WARN	This event is raised when message request processing fails due to the message response not being received within the configured time.
	RetryCount Exhausted	WARN	This event is raised when message request routing fails because all retry attempts are exhausted. All retry attempts lead to unsuccessful responses.
Overload	Pod OverLoad	WARN	This event specifies the transition of pod overload state from one state to another.
	Pending Transaction Overload	ERROR	This event is raised when the pending transaction count reaches the configured threshold level.
Health Check	Readiness Failure	ERROR	This event is raised when cache members or routing options are unavailable or the rule engine is down.
	Thread Status	ERROR	This event is raised when thread watchdog detects a thread is stuck.
Routing	Destination Search Exhausted	WARN	This event is raised when no further valid destination is found for routing, all eligible producer NFs are attempted.
	Rule Not Found	WARN	This event is raised when routing rules are not found for the selected producer NFs to route messages.
	Invalid API Version in Request	WARN	This event is raised when no matching rule is found for the API version received in request.
	Release16 Validation Failed	WARN	This event is raised when any Rel16 message validation fails.
	Message Loop Detected	WARN	This even t is raised when SCP detects a message loop for a request if it has a VIA header containing SCP's self FQDN.
	Destination Congested	WARN	This event is raised when SCP detects that the selected destination is congested.
	Destination Connection Failure	WARN	This event is raised when the upstream connection fails.
	Invalid or Empty Details	ERROR	This event is raised when any routing related data is empty or contains invalid data.
	Miscellaneous	WARN	This event is raised when any warning is raised due to miscellaneous reasons, such as failure in inter-plmn rule creation, handling routing failure responses, and so on.
Internal	Internal Error	ERROR	This event is raised when an internal error, such as monitoring of Kubernetes resources, failure to load or validate SSL certificates, object invocation, pegging of metrics, and so on, occur.
	Conversion Failure	ERROR	This event is raised due to unsupported formats, type cast, object formation, and parsing failures.
	Initialization Failed	ERROR	This event is raised when any class initialization fails, such as Jetty client and Kafka admin client creation.
	Miscellaneous	WARN	This event is raised when any failure in retrieval or updating of values to an object or due to unexpected event method execution.
Data Sync	SSE Failure	ERROR	This event is raised due to connectivity issue with the SCPC-Configuration or SCPC-Notification microservice that impacts data retrieval.
	Config Data Parse	ERROR	This event is raised when parsing failed for the received config data.
	Rule Engine	ERROR	This event is raised when routing rules fail to synchronize and update routing rules from the SCPC-Notification microservice.
	Keep Alive	WARN	This informational event is raised when the received Keep Alive and Config connectivity are up.
	Invalid Data	WARN	This event is raised when any incorrect configuration data is received due to missing parameters in any configuration.
	Config Update	WARN	This event is raised when any failure occurs while fetching or updating configuration values received from the SCPC-Configuration microservice.
Cache	Cache Initialization	ERROR	This event is raised when the initialization of the coherence cache fails.
	Cache Read Write Failure	WARN	This event is raised when any read or write operation fails for the cache.
	Invalid or Empty Details	WARN	This event is raised when any incorrect or empty data from the cache is received.
Message Validation	CCA Header Validation Failed	WARN	This event is raised when the validation for the CCA header fails.
Task Processing	MODELD_CACHE_UPDATE_ERROR	ERROR	This event is raised when updating the modelD cache fails upon receiving a profile notification.
	DATA_POLLING_FAILURE	ERROR	This event is raised when polling data from the Notification MS fails.

Table 3-21 Log Levels for SCP-nrfproxy

Category	Event	Log Level	Description
Up Stream	Connection Timeout	ERROR	This event is raised when the connection fails due to connect timeout expiry.
	Request Timeout	WARN	This event is raised when request processing fails due to response not received within configured time.
	Response Timeout	WARN	This event is raised when the destination client response is timeout.
	RetryCount Exhausted	WARN	This event is raised when message request routing fails because all retry attempts are exhausted. All retry attempts lead to unsuccessful responses.
Health Check	Readiness Failure	ERROR	This event is raised when cache members or routing options are unavailable or the rule engine is down.
	Thread Status	ERROR	This event is raised when thread watchdog detects a thread is stuck.
Routing	Destination Search Exhausted	WARN	This event is raised when no further valid destination is found for routing, all eligible producer NFs are attempted.
	Rule Not Found	WARN	This event is raised when routing rules are not found for the selected producer NFs to route messages.
	Destination webclient Connection Failure	WARN	This event is raised when upstream connection establishment fails.
	Invalid or Empty Details	ERROR	This event is raised when any routing related data is empty or contains invalid data.
	Miscellaneous	WARN	This event is raised when any warning is raised due to miscellaneous reasons, such as failure in inter-plmn rule creation, handling routing failure responses, and so on.
Internal	Internal Error	ERROR	This event is raised when an internal error occurs, such as a failure to read the application.properties file or a failure in the registration of NRF-specific details.
	Conversion Failure	ERROR	This event is raised due to unsupported formats, type cast, object formation, and parsing failures.
	Initialization Failed	ERROR	This event is raised when any class initialization fails, such as Jetty client and Kafka admin client creation.
	Miscellaneous	WARN	This event is raised when any failure in retrieval or updating of values to an object or due to unexpected event method execution.
Data Sync	SSE Failure	ERROR	This event is raised due to connectivity issue with the SCPC-Configuration or SCPC-Notification microservice that impacts data retrieval.
	Config Data Parse	ERROR	This event is raised when parsing failed for the received config data.
	Rule Engine	ERROR	This event is raised when routing rules fail to synchronize and update routing rules from the SCPC-Notification microservice.
	Keep Alive	WARN	This informational event is raised when the received Keep Alive and Config connectivity are up.
	Invalid Data	WARN	This event is raised when any incorrect configuration data is received due to missing parameters in any configuration.
	Config Update	WARN	This event is raised when any failure occurs while fetching or updating configuration values received from the SCPC-Configuration microservice.
Task Processing	MODELD_CACHE_UPDATE_ERROR	ERROR	This event indicates that model D cache updation is failed for a nfProfile Update
	DATA_POLLING_FAILURE	ERROR	This event is raised when polling data from the Notification MS.

Table 3-22 Log Levels for SCP-notification

Category	Event	EventID	Description	Cause	Action
READINESS_FAILURE	DB_RECORDS_NOT_AVAILABLE	OSCP-NTF-RDYNES-EV001	This event is raised when the default database records are not created.	This event is raised when default database records for the following are not created: Canary Release SCP Profile NRF Details Routing Options System Options Virtual Services Service Entries Destination Rules	Check if the database is up and running and if the connection to the database is functioning properly.
	REQUIRED_DATA_NOT_AVAILABLE	OSCP-NTF-RDYNES-EV002	This event is raised due to a readiness check failure.	This event is raised if the readiness check fails due to any of the following data being unavailable in the database: Canary Release SCP Profile NRF Details Routing Options System Options Virtual Services Service Entries Destination Rules	Check if the database is up and running, if the connection to the database is successful, and if the required data is available in the database.
LIVENESS_FAILURE	THREAD_WATCHDOG_FAILURE	OSCP-NTF-LIVNES-EV001	This event is raised whenever any threads become stuck.	This event is raised whenever the liveness check fails due to one or more threads being stuck.	Check if there are any threads stuck.
	QUEUE_FULL	OSCP-NTF-LIVNES-EV002	This event is raised whenever the liveness probe condition fails and the application restarts due to the notification queue being full.	This event is triggered whenever the liveness probing condition fails and the application restarts due to the notification queue being full.	Check whether the notification queue is full.
NF_RULE_CREATE_OR_UPDATE_FAILURE	NF_PROFILE_VALIDATION_FAILURE	OSCP-NTF-RULUPD-EV001	This event is raised when NF profile validation fails.	NF profile validation can fail due to: Missing mandatory fields such as nfType, event, nfStatus, nfInstanceId Invalid nfInstanceId Any exception occurring while checking for duplicate locality in the NF profile Load Balancer IP is enabled but missing in the NF profile Invalid HOST Invalid serviceName Invalid IPAddress Invalid NfServiceFqdn Duplicate IpEndPoints/ServiceInstanceIDs SCP receives a notification of a duplicate SCP NF profile SCP receives a notification of a duplicate NRF NF profile	Check the NF profile data.
	RULE_PROCESSING_FAILURE	OSCP-NTF-RULUPD-EV002	This event is raised when rule creation fails.	Rule creation or update can fail due to: Notification received for partial profile updates for an unknown nfInstanceId NF_PROFILE_CHANGED event contains both NFProfile and ProfileChanges Exception occurs while handling events for DNS SRV Failed to trigger GET request to NRF to retrieve the latest profile or received a null or error response Any other unknown error occurs while processing the notification	Check the logs for more detailed information
	NF_PROFILE_REFINE_ERROR	OSCP-NTF-RULUPD-EV003	This event is raised when: IOException or ApiException occurs during data refinement in NFService An exception is encountered due to incorrect configuration for the profile while creating a refined version of NFProfile.	This event is raised when: IOException or ApiException occurs during data refinement in NFService An exception is encountered due to incorrect configuration for the profile while creating a refined version of NFProfile.	Check the NF profile configuration.
	DB_UPDATE_FAILURE	OSCP-NTF-RULUPD-EV004	This event is raised when saving data to the database fails.	This event is raised when saving to the database fails during the creation or update of NF rules.	Check the database connection.
	DB_READ_FAILURE	OSCP-NTF-RULUPD-EV005	This event is raised when reading data from the database fails.	This event is raised if reading data from the database fails during the creation or update of NF rules.	Check the database connection.
	DB_DELETE_FAILURE	OSCP-NTF-RULUPD-EV006	This event is raised when a database deletion operation fails.	This event is raised when deleting from the database fails during the creation or update of NF rules.	Check the database connection.
	RULE_CREATE_OR_UPDATE_MISCELLANEOUS	OSCP-NTF-RULUPD-EV007	This event is raised when rule creation fails due to miscellaneous reasons.	This event is raised when rule creation fails due to various issues, such as a notification from the audit microservice having a timestamp earlier than the SCP processed timestamp.	Check whether the timestamp of the notification pushed from the audit microservice is behind the SCP processed timestamp.
	RULE_CREATE_OR_UPDATE_ABORTED	OSCP-NTF-RULUPD-EV008	This event is raised when rule creation is aborted due to failures.	This event is raised when rule creation is aborted due to a notification pushed from the configuration microservice, and the timestamp of the configuration notification is behind the SCP processed timestamp.	Check the timestamps and verify if the notification microservice has already processed the received notification from the configuration.
	QUEUE_FULL_WHEN_PROFILE_RECEIVED	OSCP-NTF-RULUPD-EV009	This event is raised when the notification queue is full.	This event is raised when the notification queue is full.	Check the notification queue size.
NF_RULE_DELETION_FAILURE	RULE_DELETE_PROCESSING_FAILURE	OSCP-NTF-RULDEL-EV001	This event is raised when rule deletion fails due to certain errors or failures.	This event is triggered when the deletion of the rules fails due to miscellaneous reasons.	Check the logs for the specific reasons.
	RULE_DELETE_ALREADY_DEREGISTERED	OSCP-NTF-RULDEL-EV002	This event is raised when a deregistration request is received for an NF that has already been deregistered.	This event is raised when a deregistration request is received for an NF that has already been deregistered.	Check if the received deregistration request is for an NF that has already been deregistered.
	RULE_DELETE_ABORTED	OSCP-NTF-RULDEL-EV003	This event is raised when the deletion of a rule is aborted due to miscellaneous reasons.	This event is raised when rule deletion is aborted due to miscellaneous reasons, such as receiving a deregistration notification for the last NF instance.	Verify whether the received deregistration notification is for the last NF instance.
	RULE_DELETE_DB_READ_FAILURE	OSCP-NTF-RULDEL-EV004	This event is raised when there is a failure to delete a rule while reading from the database.	This event is raised when an exception occurs while reading from the database during rule deletion.	Check the database connection.
	RULE_DELETE_DB_DELETE_FAILURE	OSCP-NTF-RULDEL-EV005	This event is raised when there is a failure to delete a rule from the database.	This event is raised when an exception occurs while reading from the database during rule deletion.	Check the database connection.
NF_RULE_PROCESSOR_FAILURE	RULE_PROCESSOR_MISCELLANEOUS	OSCP-NTF-RULPRC-EV001	This event is raised when rule processing fails due to miscellaneous reasons.	This event is raised when rule processing fails due to various reasons.	Check the logs to identify the miscellaneous reasons.
	RULE_PROC_DB_READ_FAILURE	OSCP-NTF-RULPRC-EV002	This event is raised when rule processing fails due to a database read failure.	This event is raised when an exception occurs while reading from the database during rule deletion.	Check the database connection.
	RULE_PROC_DB_DELETE_FAILURE	OSCP-NTF-RULPRC-EV003	This event is raised when rule processing fails due to a database deletion failure.	This event is raised when rule processing fails due to a database delete operation failure.	Check the database connection.
	RULE_PROC_ABORTED	OSCP-NTF-RULPRC-EV004	This event is raised when rule processing fails due to receiving a notification from NRF for an NF configured as local.	This event is raised when rule processing fails due to receiving a notification from NRF for an NF configured as local.	Verify whether the received notification from NRF is for an NF configured as local.
INTERNAL	INTERNAL_ERROR	OSCP-NTF-INTRNL-EV001	This event is raised whenever there is an internal error such as monitoring of Kubernetes resources, object invocation, or pegging of metrics.	This event is raised whenever there is an internal error, such as issues with monitoring Kubernetes resources, object invocation, or metric pegging.	Check the logs for more detailed information.
	CONVERSION_FAILURE	OSCP-NTF-INTRNL-EV002	This event is raised whenever there are failures in unsupported format/type casting, object formation, or parsing.	This event is raised whenever there are failures related to unsupported formats, type casting, object formation, or parsing.	Check the logs for more detailed information.
	INITIALIZATION_FAILURE	OSCP-NTF-INTRNL-EV003	This event is raised when there is a failure during class initialization.	This event is raised whenever there is a failure in class initialization, loading, or queue initialization	Check the logs for more detailed information.
	MISCELLANEOUS	OSCP-NTF-INTRNL-EV004	This event is raised whenever there are failures in retrieving or updating values to an object, or during unexpected method execution.	This event is raised whenever there is a failure in class initialization, loading, or queue initialization.	Check the logs for more detailed information.
	DB_READ_FAILURE_AT_STARTUP	OSCP-NTF-INTRNL-EV005	This event is raised whenever there is a database read failure during application startup.	This event is triggered whenever a database read failure occurs during application startup.	Check the database connection.
	INTERNAL_DATA_NOT_FOUND	OSCP-NTF-INTRNL-EV006	This event is raised whenever required internal data is missing.	This event is raised whenever required internal data, such as FQDN or IP addresses for the SCP profile, is missing.	Check the SCP profile to ensure that all required internal data is provided.
DATA_SYNC	CONFIG_DATA_PARSE_FAILURE	OSCP-NTF-DATSYN-EV001	This event is raised when parsing fails for received config data.	This event is raised when parsing fails for the received configuration data.	Check the logs for more detailed information.
	CONFIG_UPDATE_FAILURE	OSCP-NTF-DATSYN-EV002	This event is raised whenever there is a failure while fetching or updating configuration values received from the Config MS	This event is raised whenever SCP encounters a virtual service with empty or null host values.	Check if the virtual service has empty or null hosts.
	DATA_SYNC_DB_READ_FAILURE	OSCP-NTF-DATSYN-EV003	This event is raised when reading the data from DB fails in SSE communications.	This event is raised when reading data from the database fails during SSE communications.	Check the connection to the database.
	CONFIG_DATA_NOT_FOUND	OSCP-NTF-DATSYN-EV004	This event is raised when the configured data is not found in DB sync.	This event is raised when the configured data is not found in the database synchronization.	Check the logs to verify if the requested feature-specific configurations are present.
	INVALID_DATA	OSCP-NTF-DATSYN-EV005	This event is raised when the configured data is not found during database synchronization.	This event is raised whenever bad configuration data is received or parameters are missing in the configuration.	Check the logs for more detailed information.
DBSNAPSHOT_UPDATER	DB_SNAPSHOT_READ_FAILURE	OSCP-NTF-DBSNSH-EV001	This event is raised whenever an exception occurs while reading virtual services or serviceEntries from the database.	This event is raised whenever an exception occurs while reading Virtual Services or ServiceEntries from the database.	Check the database connection.

Table 3-23 Log Levels for SCP-audit

Category	Event	EventID	Description	Cause	Action
READINESS_FAILURE	DB_RECORDS_NOT_AVAILABLE	OSCP-AUD-RDYNES-EV001	This event is raised when the default database records are not created.	This event is raised when default database records for the following are not created: NRF Details VirtualServices for NRF	Check if the database is up and running and if the connection to the database is functioning properly.
LIVENESS_FAILURE	THREAD_WATCHDOG_FAILURE	OSCP-NTF-LIVNES-EV001	This event is raised whenever any threads become stuck.	This event is raised whenever the liveness check fails due to one or more threads being stuck.	Check if there are any threads stuck.
AUDIT_FAILURE	ERROR_RESPONSE_RECEIVED	OSCP-AUD-AUDFR-EV001	This event is triggered whenever there is a failure in: Parsing the response body from NRF Processing the NF profile Obtaining the NF profile from NRF Response processing failures from NRF	This event is triggered whenever there is a failure in: Parsing the response body from NRF Processing the NF profile Obtaining the NF profile from NRF Response processing failures from NRF	Check the connection with NRF and verify the response coming from NRF.
	AUDIT_INTERNAL_FAILURE	OSCP-AUD-AUDFR-EV002	This event is raised whenever an exception occurs due to miscellaneous reasons while handling an AUDIT request.	This event is raised whenever an exception occurs due to miscellaneous reasons while handling an AUDIT request.	Check the logs for more detailed information.
	NRF_COMMUNICATION_ERROR	OSCP-AUD-AUDFR-EV003	This event is raised whenever the connection with NRF fails while sending the AUDIT request.	This event is raised whenever the connection with NRF fails while sending the AUDIT request.	Check the connection with NRF.
	DB_READ_FAILURE	OSCP-AUD-AUDFR-EV004	This event is raised when reading data from the database fails.	This event is raised when reading data from the database fails.	Check the connection with NRF.
NRF_HEALTH_CHECK	HEALTH_CHECK_FAILED	OSCP-AUD-HLTCHK-EV001	This event is raised when the connection with NRF fails while sending the Health Check request to NRF as part of the AUDIT.	This event is raised when the connection with NRF fails while sending the Health Check request to NRF as part of the AUDIT.	Check the connection with NRF.
	AUDIT_ABORTED	OSCP-AUD-HLTCHK-EV002	This event is raised when no NF is configured to learn from NRF.	This event is raised when there are no NF configured to learn from the NRF.	Check if any NFs are configured to learn from the NRF.
	NO_REGION_FOUND	OSCP-AUD-HLTCHK-EV003	This event is raised when no NRF is found to be healthy at the moment.	This event is raised when no NRF is found to be healthy at the moment.	Check if there are any healthy NRFs available.
INTERNAL	INTERNAL_ERROR	OSCP-AUD-INTRNL-EV001	This event is raised whenever an internal error occurs, such as issues with monitoring Kubernetes resources, object invocation, pegging of metrics, and so on.	This event is raised whenever there is an internal error, such as issues with monitoring Kubernetes resources, object invocation, or pegging of metrics.	Check the logs for more detailed information.
	MISCELLANEOUS	OSCP-AUD-INTRNL-EV002	This event is raised whenever an NF Profile record for the specified Instance ID does not exist in the database table while adding it to the Missed De-Register notification list as part of the AUDIT.	This event is raised whenever an NF profile record for this instance ID does not exist in the database table while adding it to the missed de-register notification list as part of the audit.	Check the logs for more detailed information.
	NRF_SRV_EVENT_ENQUEUE_FAILURE	OSCP-AUD-INTRNL-EV003	This event is raised whenever an exception occurs while enqueuing an NRF SRV task in the event queue. .	This event is raised whenever an exception occurs while enqueuing an NRF service task in the event queue.	Check the logs for more detailed information.
	NRF_SRV_HANDLE_EVENT_FAILURE	OSCP-AUD-INTRNL-EV004	This event is triggered whenever there is a failure in handling the following NRF SRV events: HOLD_AUDIT START_ON_DEMAND_AUDIT CANCELLATION	This event is triggered whenever there is a failure in handling the following NRF SRV events: HOLD_AUDIT START_ON_DEMAND_AUDIT CANCELLATION	Check the logs for more detailed information.
	INITIALIZATION_FAILURE	OSCP-AUD-INTRNL-EV005	This event is raised whenever an exception occurs while reading the property file.	This event is raised whenever an exception occurs while reading the application properties file.	Check the logs for more detailed information about issues with the application.properties file.
	DNS_SRV_NRF_TASK_RESUMPTION_FAILURE	OSCP-AUD-INTRNL-EV006	This event is raised whenever an exception occurs while resuming an in-progress DNS SRV task.	This event is raised whenever an exception occurs while resuming an in-progress DNS SRV task.	Check the logs for more detailed information about the issue with resuming the in-progress DNS SRV task.
	PARSE_FAILURE	OSCP-AUD-INTRNL-EV007	This event is triggered whenever an exception occurs while reading the following environment variables: AUDIT_INTERVAL ALTERNATE_RESOLUTION_AUDIT_INTERVAL INITIAL_DELAY_SECONDS_READINESS	This event is triggered whenever an exception occurs while reading the following environment variables: AUDIT_INTERVAL ALTERNATE_RESOLUTION_AUDIT_INTERVAL INITIAL_DELAY_SECONDS_READINESS	Check the configuration of the environment variables.
DATA_SYNC	CONFIG_DATA_PARSE_FAILURE	OSCP-AUD-DATSYN-EV001	This event is raised whenever a failure occurs while parsing the received configuration data.	This event is raised whenever a failure occurs while parsing the received configuration data.	Check the logs for more details.
SCP_HEALTH_CHECK	SCP_HC_INTERNAL_ERROR	OSCP-AUD-HLCAPI-EV001	This event is raised whenever an exception occurs while sending the health query request to the peer SCP.	This event is raised whenever an exception occurs while sending the health query request to the peer SCP.	Check the connection between scp-worker and scpc-audit, as well as between scp-worker and nextHopScp
	SCP_HC_HANDLE_RESPONSE_FAILURE	OSCP-AUD-HLCAPI-EV002	This event is raised whenever an exception occurs while handling the health query response.	This event is raised whenever an exception occurs while handling the health query response.	Check the logs for more details.

Table 3-24 Log Levels for SCP-loadmanager

Category	Event	EventID	Description	Cause	Action
READINESS_FAILURE	HEALTH_CHECK_FAILED	OSCP-LMG-RDYNES-EV001	This event is raised when the Load-Manager readiness probe fails.	This event is raised when the coherence cache initialization check fails, indicating that the health check has failed.	Check the logs for more detailed information.
LIVENESS_FAILURE	THREAD_WATCHDOG_FAILURE	OSCP-LMG-LIVNES-EV001	This event is raised whenever any threads become stuck.	The thread remains stuck for a few seconds.	Check the logs for more detailed information and contact customer support if the issue persists.
	HEALTH_CHECK_FAILED	OSCP-LMG-LIVNES-EV002	This event is raised when the Load-Manager liveliness probe fails.	This event is raised when the coherence cache initialization check fails, indicating that the health check has failed.	Check the logs for more detailed information and contact customer support if the issue persists.
INTERNAL	INTERNAL_ERROR	OSCP-LMG-INTRNL-EV001	This event is raised whenever an internal error occurs, such as issues with monitoring Kubernetes resources, object invocation, or pegging of metrics.	This event is raised whenever an internal error occurs, such as issues with monitoring Kubernetes resources, object invocation, pegging of metrics, and similar operations.	Check the logs for more detailed information and contact customer support for further assistance.
	INITIALIZATION_FAILURE	OSCP-LMG-INTRNL-EV002	This event is raised whenever an exception occurs while reading the property file.	This event is raised whenever an exception occurs while reading the application properties file.	Check the logs for more detailed information about the issue in the application.properties file and contact customer support for assistance.
	MISCELLANEOUS	OSCP-LMG-INTRNL-EV003	This event is raised whenever an exception occurs while creating Load Manager queue configurations.	This event is raised whenever an exception occurs while enqueuing a task to the event queue.	Check the logs for more detailed information and contact customer support for assistance.
	CONVERSION_FAILURE	OSCP-LMG-INTRNL-EV004	This event is raised whenever an exception occurs while monitoring the queue size of the Load Manager queue configurations.	This event is raised whenever an exception occurs related to the queue size issue.	Check the queue size and collect the logs for more information.
DATA_SYNC	CONFIG_UPDATE	OSCP-LMG-DATSYN-EV001	This event is raised whenever SCP encounters a virtual service with empty or null hosts.	This event is raised whenever SCP encounters a virtual service with empty or null hosts.	Check the logs for more detailed information and contact customer support for further assistance.
	INVALID_DATA	OSCP-LMG-DATSYN-EV002	This event is raised whenever invalid configuration data is received or when required parameters are missing in the configuration.	This event is raised whenever invalid configuration data is received or when parameters are missing in the configuration.	Check the logs for more detailed information and contact customer support for assistance.
	CONFIG_DATA_PARSE	OSCP-LMG-DATSYN-EV003	This event is raised whenever a failure occurs while parsing the received configuration data.	This event is raised whenever a failure occurs while parsing the following received configuration data: SystemOptionsClient ScpFeatures ScpServiceConfigs OciConfig OciThresholdConfig EngConfig CongestionControlConfig	Check the database records and collect the logs for more detailed information. Contact customer support if further assistance is required.
	SSE_FAILURE	OSCP-LMG-DATSYN-EV004	This event is raised when the connection to the server cannot be established during the startup of the Load Manager.	This event is raised when the connection to the Notification service fails during application startup.	Check the connectivity for the Routing Option Client and collect the logs for more details.
CACHE	CACHE_INITIALIZATION	OSCP-LMG-CACHEF-EV001	This event is raised whenever cache initialization fails.	This event is raised whenever cache initialization fails.	Check the logs for more detailed information and contact customer support if you need further assistance.
	CACHE_READ_WRITE_FAILURE	OSCP-LMG-CACHEF-EV002	This event is raised whenever an exception occurs during a read or write operation on the cache data.	This event is raised whenever an exception occurs while reading, writing, or updating cache data.	Check the logs for more detailed information and reach out to customer support if further assistance is required.
	CACHE_INVALID_OR_EMPTY_DETAILS	OSCP-LMG-CACHEF-EV003	This event is raised when incorrect or empty data is received from the cache.	This event is raised when incorrect or empty data is received from the cache.	Check the logs for more detailed information and contact customer support if needed.
HEALTH_CHECK	THREAD_STATUS	OSCP-LMG-HLTCHK-EV001	This event is triggered when an ongoing thread operation is interrupted.	This event is triggered when an ongoing thread operation is interrupted.	Check the logs for more detailed information.

Managing Verbose Logging

Enable

This feature is enabled automatically at the time of SCP deployment.

Configure

There is no specific configuration required for this feature.

Support for the Trace log level has been introduced for the scp-notification, scp-audit, and scp-loadmanager microservices. For more information, please see the Configuring Global Options and the "Configuring Dynamic Logging" section in Oracle Communications Cloud Native Core, Service Communication Proxy REST Specification Guide.

Observe

There is no specific metrics and alerts required for this feature.

Maintain

If you encounter alerts at system level, see the Alerts section for resolution steps.

In case the alerts persist, perform the following tasks:

1. Collect the logs: For information about how to collect logs, see Oracle Communications Cloud Native Core, Service Communication Proxy Troubleshooting Guide.
2. Raise a service request: For information about how to raise a service request, see My Oracle Support.

3.21 Support for OAuth2.0

Access tokens are credentials used by consumer NFs to access protected resources provided by producer NFs. These credentials are issued by NRF. These tokens represent specific scope and duration of access. SCP supports OAuth2.0 (Open Authorization) access tokens in 5G indirect communication models such as Model C and Model D.

In the 5G SBI Model D indirect communication (with delegated discovery) mode, SCP obtains access tokens from NRF for 5G SBI message requests except notification or callback messages. SCP uses the acquired access tokens to forward SBI message requests to the selected producer NFs.

The following call flow represents how SCP obtains access tokens from NRF:

Figure 3-5 SCP Obtains Access Tokens from NRF

The above mentioned call flow describes the process to use the Discovery parameter to send a request to NRF for obtaining the access token:

1. NF Service Consumer sends a service request to SCP.
2. If SCP does not get an access token in the service request, it uses the Discovery parameter to send the access token request to NRF.
3. SCP sends Nnrf_AccessToken_Get_Request to NRF.
4. NRF validates the access token request using Client Credential Assertion (CCA).
5. NRF sends Nnrf_AccessToken_Get_Response to SCP.
6. SCP forwards the service request, along with CCA and access token, to NF Service Producer.
7. NF Service Producer validates the access token.
8. NF Service Producer sends the service response to SCP.
9. SCP relays the service response to NF Service Consumer.

In the 5G SBI Model C indirect communication (without delegated discovery) mode, consumer NFs obtain access tokens from NRF except notification or callback messages. SCP uses the access tokens received from consumer NFs and forward SBI message requests to the selected producer NFs.

The following call flow represents how NF Service Consumer obtains access tokens from NRF:

Figure 3-6 NF Consumer Obtains Access Tokens from NRF

The above mentioned call flow describes the process that NF Service Consumer uses to obtain access token from NRF and how SCP uses this access token to forward the service request.

1. When there is no mutual authentication between NF Service Consumer and NRF, NF Service Consumer sends Nnrf_AccessToken_Get_Request to NRF.
2. NRF sends Nnrf_AccessToken_Get_Response to NF Service Consumer.
3. NF Service Consumer sends Discovery service requests to NRF.
4. After receiving the discovery response with NF profiles, NF Service Consumer sends the service request to SCP.
5. SCP uses the access token received from NF Service Consumer and forwards the service request, along with CCA and access token, to NF Service Producer.
6. NF Service Producer validates the access token.
7. NF Service Producer sends the service response to SCP.
8. SCP relays the service response to NF Service Consumer.

Note:

SCP supports 5G SBI Client Credentials Assertion (CCA) custom header for Model C and Model D indirect communication routing. It is an optional header that can be sent by consumer NFs, along with the service request for enabling consumer NFs authentication. For more information about CCA header, see Support for the Client Credentials Assertion Header.

This feature enables SCP to perform the following tasks:

• SCP determines the status of OAuth2 support of producer NFs deployed in the network using the following:
  • Learnt 5G NF service topology from NRF
  • NF discovery response during delegated service request
  • Configurations at SCP
• In Model D indirect communication, SCP is responsible for access token lifecycle (initiate, maintain, and delete). SCP caches the access tokens and reuses them during initial, subsequent, or alternate routing.
• SCP validates access tokens as per the configuration.
• SCP returns the access token received from NRF to consumer NFs using the "3gpp-Sbi-Access-Token" header.
• SCP determines service level scope information in the access token from the "3gpp-Sbi-Access-Scope" header
• SCP regulates and avoids duplicate access token requests for the same consumer NF and producer NF pair.
• SCP supports OAuth2.0 in inter-SCP scenarios.
• SCP proactively attempts to refresh the access tokens when required.
• SCP supports NF type and NF instance type of access tokens.

SCP has introduced the SCP-nrfProxy-Oauth microservice to manage requests initiated to NRF for its nnrf-oauth2 service that considers various parameters as body and CCA header to provide an authentication token as response to the consumer NF. This microservice interacts with SCP-Worker when it receives request from SCP-Worker. When SCP-Worker initiates the access token request to NRF, Oauth2.0 service sends a request to SCP-Worker with NRF details in the routing binding header. Coherence cache is integrated with this service where the values of tokens are stored based on the cache configuration at SCP. To avoid duplicate requests to NRF, an internal cache is also maintained. This service is capable of handling various states of access tokens received, such as expiration, and acts accordingly.

Managing Support for OAuth2.0

Enable

By default, this feature is disabled. To enabled this feature, do the following tasks:

1. Set the nrfProxyOauthService Helm parameter to true in the ocscp_values.yaml file.
2. Set the oauth2_support option to true as described in Configuring SCP Features.

Configure

You can configure this feature using Helm, REST APIs, and the CNC Console.

• Configure using CNC Console: For information about CNC Console configurations, see Configuring SCP Features and OAuth2.0 Configurations.
• Configure using REST API: For information about configuring REST APIs, see "Configuring SCP Features", "Configuring NRF", "Configuring OAuth2.0 Access Token Granularity", and "Configuring OAuth2.0 Local PLMN Required" in Oracle Communications Cloud Native Core, Service Communication Proxy REST Specification Guide.
• Configure using Helm: For information about configuring the SCP-nrfProxy-Oauth microservice, see "SCP-nrfProxy-oauth Parameters" in Oracle Communications Cloud Native Core, Service Communication Proxy Installation, Upgrade, and Fault Recovery Guide.

Observe

The following metrics are added in the Metrics section:

• ocscp_oauth_access_token_cache_match_total
• ocscp_worker_access_token_forwarded_in_tx_res_total
• ocscp_worker_access_token_forwarded_in_tx_req_total
• ocscp_worker_access_token_cache_match_total
• ocscp_nrf_oauth_error_counts_total
• ocscp_oauth_access_token_tx_rsp_total
• ocscp_oauth_access_token_rx_res_total
• ocscp_oauth_access_token_tx_req_total
• ocscp_oauth_access_token_rx_req_total
• ocscp_worker_access_token_rx_res_total
• ocscp_worker_access_token_tx_req_total

Maintain

If you encounter alerts at system level, see the Alerts section for resolution steps.

In case the alerts persist, perform the following tasks:

1. Collect the logs: For information about how to collect logs, see Oracle Communications Cloud Native Core, Service Communication Proxy Troubleshooting Guide.
2. Raise a service request: For information about how to raise a service request, see My Oracle Support.

3.22 Pod Overload Control

SCP processes 5G Service Based Interface (SBI) messages using its microservices. To protect scp-worker pods from the overload, SCP has introduced the Pod Overload Control feature.

This feature throttles only ingress 5G SBI message requests based on:

• CPU utilization of the scp-worker microservice pods.
• Pending Transactions for which responses from producer NFs are awaited by SCP.

SCP provides the following pod overload configurations for scp-worker:

• Pod Overload Action Policy: To configure action to be taken by scp-worker pods for CPU overload.
• Pod Overload Control Policy: To configure CPU and pending transactions onset threshold, abatement threshold, and abatement time for scp-worker.
• Pod Overload Discard Policy: To configure the percentage of messages to be discarded based on the discardPercentage parameter or discard messages based on the sbiMsgPriorityDiscardFrom parameter.

For more information about the aforementioned configurations, see Oracle Communications Cloud Native Core, Service Communication Proxy REST Specification Guide.

When CPU utilization or pending transactions of the scp-worker pod exceeds the configured threshold level, SCP responds based on the configured overload Action Policy as described in Oracle Communications Cloud Native Core, Service Communication Proxy REST Specification Guide.

Message Priority

SCP assigns and updates the "3gpp-Sbi-Message-Priority" header to prioritize ingress 5G SBI messages during the overload control task. For more information about message priority, see Message Priority Assignment and Override.

Managing Pod Overload Control

Enable

This feature is enabled automatically in SCP at the time of deployment.

Configure

You can configure the Pod Overload Control feature using the CNC Console or REST API.

• Configure using CNC Console: For information about 5G SBI message priority and pod overload policies configurations, see Configuring Pod Overload Control Policies and Configuring SBI Message Priority.
• Configure using REST API: For information about 5G SBI message priority and pod overload policies configurations, see Oracle Communications Cloud Native Core, Service Communication Proxy REST Specification Guide.

Observe

For information about metrics, see Metrics.

The following alerts are added in the Alerts section:

• SCPCPUUsageFileReadFailed
• SCPCGroupVersionDetectionFailed

Maintain

If you encounter alerts at system level, see the Alerts section for resolution steps.

In case the alerts persist, perform the following tasks:

1. Collect the logs: For information about how to collect logs, see Oracle Communications Cloud Native Core, Service Communication Proxy Troubleshooting Guide.
2. Raise a service request: For information about how to raise a service request, see My Oracle Support.

3.23 Host Preference for Egress Message Requests

Although Fully Qualified Domain Name (FQDN) is present in the ingress message requests, SCP uses IP as the host in the egress message request if IP is present in the learned Network Function (NF) profile of the producer NF.

Using the Host Preference for Egress Message Requests feature, SCP can determine the host type to be included in the egress messages. SCP uses one of the host types such as FQDN or IP, in the egress message request.

The host type in the egress message request is determined by the following:

• 3gpp-Sbi-Target-apiRoot header
• hostPreference of egress_host_preference as described in the "Configuring SCP Features" section of Oracle Communications Cloud Native Core, Service Communication Proxy REST Specification Guide
• Learned NF profile from NRF

If the 3gpp-Sbi-Target-apiRoot header is present in the ingress message request, the host type is determined by the hostPreference.request.apiRootHdrPresent REST API parameter. If this parameter value is set to passThrough, which is the default value, SCP uses the same type of host in the egress message request as received through the ingress message request. For more information about the hostPreference.request.apiRootHdrPresent REST API parameter, see "Configuring SCP Features"in Oracle Communications Cloud Native Core, Service Communication Proxy REST Specification Guide.

If the 3gpp-Sbi-Target-Apiroot header is absent in the ingress message request, SCP uses the hostPreference.request.apiRootHdrNotPresent REST API configuration to determine the host type. By default, SCP uses IP as the host type.

In case of alternate routing, SCP determines the host type of another equivalent producer NF by using the same method as used for the target producer NF.

If the selected host type is FQDN, SCP provides the fqdnResolution.fqdn REST API parameter to choose whether to resolve the FQDN in the egress message request with the IPs (from IP Endpoints) present in learned NF profiles of the target producer NF or trigger a Domain Name System (DNS) query.

SCP tries to get the same host type as configured in the hostPreference REST API parameter, however, if the corresponding information such as FQDN or IP, is unavailable, then SCP uses other available information for routing.

Managing Host Preference for Egress Message Requests

Enable

By default, this feature is disabled. To enable this feature, you must complete the configuration as described in the following configuration section.

Configure

You can configure this feature using REST API and the CNC Console.

• Configure using CNC Console: For information about CNC Console configurations, see Configuring SCP Features.
• Configure using REST API: For information about configuring REST APIs, see "Configuring SCP Features" in Oracle Communications Cloud Native Core, Service Communication Proxy REST Specification Guide.

Observe

The following metrics are added in the Metrics section:

• ocscp_worker_fqdn_resolution_total
• ocscp_worker_interplmn_fqdn_resolution_total
• ocscp_worker_http_req_host_type_total

Maintain

If you encounter alerts at system level, see the Alerts section for resolution steps.

In case the alerts persist, perform the following tasks:

1. Collect the logs: For information about how to collect logs, see Oracle Communications Cloud Native Core, Service Communication Proxy Troubleshooting Guide.
2. Raise a service request: For information about how to raise a service request, see My Oracle Support.

3.24 Enhanced 5G SBI Message Failure Handling

SCP adds server header to all SCP generated error responses as defined in 3GPP TS 29.500. SCP forwards error responses received from producer NFs to consumer NFs without modifying the server header. In case of alternate routing, SCP forwards the last received error response to the consumer NF.

In SCP 1.15.0, the 5G SBI Message Failure Handling functionality is enhanced to enable SCP to send information of all the routing attempts made on producer NFs by SCP. The server header format is enhanced to include all the routing information while forwarding error responses with server header to consumer NFs.

The server header format includes information of all the attempted producer NFs in the reverse order of attempts made. For example: If NF1 and NF2 are attempted in that order, the server header formats are:

• In forwarded responses: "Server: <NF2 Type>-<NF2 instance id> <NF1 Type>-<NF1 instance id>"
• In self-generated responses: "Server: SCP-<scp-fqdn> <NF2 Type>-<NF2 instance id> <NF1 Type>-<NF1 instance id>"

In SCP 23.1.0, when SCP does not receive a server header in an error response from a producer NF, SCP adds a server header with its FQDN while forwarding the response to the consumer NF.

SCP generates error responses in the following scenarios:

Note:

The server header, using SCP's own FQDN, will apply to all error responses generated by SCP. This includes errors caused by discards due to ingress or egress rate limiting, pod overload control, destination exhausted, no host, and so on. For more information about error codes generated by SCP, see Error Codes Generated by SCP.

• Connection issue with producer NF: When the producer NF is unhealthy or SCP is unable to establish connection with the producer NF.
• Timeout at SCP: When the producer NF fails to reply to SCP within the specified time as configured in the responseTimeout REST API parameter or if the configured totalTransactionLifetime expires.
• Service unavailable: When the connection is unavailable between SCP and producer NF.

Note:

If an IP address is provided in the SCP FQDN deployment field, the same is mentioned in the server header introduced by SCP for the above mentioned scenarios.

SCP adds a server header with its FQDN in the error responses received from the service mesh sidecar. The server header format is: "Server": "SCP-<SCP FQDN>".

SCP forwards the server header received in the error response from the producer NF as it is to the consumer NF.

When SCP receives an error response from sidecar or service mesh, then SCP adds a server header with its FQDN and relays them to the consumer NF. SCP detects an error generated by sidecar or service mesh failure when the received response has server header matching one of the configured server header strings in the sideCarProxyServerHeader REST API parameter. For example, "envoy", "istio-envoy", and custom string configured in SCP, and the status code in the received error response matches the status code configured in the sideCarProxyStatusCode REST API parameter.

SCP appends its FQDN in the server header if it has received a response from at least one producer NF (also known as the last error response), and SCP could not try other NFs due to the following:

• Connection issue, unknown host exception or unknown error
• Service mesh reported errors
• Timeout at SCP
• Received error response from the producer NF without server header

The error response for the above scenarios has the server header as follows: "Server": "SCP-<SCP Fqdn> NFTYPE-<NfInstanceId>".

In SCP 23.2.0, the 5G SBI Message Failure Handling functionality is enhanced. SCP forwards the last or latest error response received from producer NFs to consumer NFs, and server header content is populated with the details of the producer NF from which the error response is received.

SCP does not append SCP FQDN in returned server header to downstream if it has received an error response from at least one producer and SCP could not try other producer NFs due to the following:

• Connection issue, unknown host exception or unknown error
• Service mesh reported errors
• Timeout at SCP
• Received error response from the producer NF without server header

The error response for the above scenarios has the server header as follows: "Server": "NFTYPE-<NfInstanceId>".

The following table describes differences between the server header behavior in SCP 23.1.0 and SCP 23.2.0:

Table 3-25 Implemented Behavior

Scenario	Server Header in SCP 23.1.0	Server Header in SCP 23.2.0
When SCP sends a message request to UDM1, UDM1 sends an error response with a server header. Then, SCP performs alternate routing on UDM2, and a timeout occurs at SCP.	"Server": "SCP-<scp-fqdn> UDM-udm1-instance-id"	"Server": "UDM-udm1-instance-id"
When SCP sends a message request to UDM1, SCP receives an error response from the service mesh or sidecar. Then, SCP performs alternate routing on UDM2 and receives an error response without a server header, and when SCP performs another alternate routing on UDM3, it receives an error response with a server header.	"Server": "SCP-<scp-fqdn> UDM-udm3-instance-id"	"Server": "UDM-udm3-instance-id"

The following table describes the server header behavior in different error scenarios between SCP and producer NFs.

Note:

In all the scenarios, SCP attempts to establish connections with producer NFs (UDM1, UDM2, and UDM3) as mentioned in the scenarios.

Example Scenario 19: UDM1 sends an error response with server header. Timeout has occurred at UDM2, and UDM3 has connection issue, and the pod is down.

In the above mentioned scenario and as specified in the note, SCP attempts to establish connection with UDM1 first followed by UDM2, and then UDM3.

Table 3-26 Server Header Behavior

Serial No.	Scenario	Server Header Behavior
1	UDM1 and UDM2 services are unavailable.	Default behavior when addServerHeaderInProducerResponse is set to: true: "Server" : "SCP-<SCP FQDN>" false: "Server" : "SCP-<SCP FQDN>" Behavior in SCP 23.1.0 (Enhancement 1): "Server" : "SCP-<SCP FQDN>" Behavior in SCP 23.2.0 (Enhancement 2): "Server" : "SCP-<SCP FQDN>"
2	Timeout has occurred at UDM1 and UDM2.	Default behavior when addServerHeaderInProducerResponse is set to: true: "Server" : "SCP-<SCP FQDN>" false: "Server" : "SCP-<SCP FQDN>" Behavior in SCP 23.1.0 (Enhancement 1): "Server" : "SCP-<SCP FQDN> UDM-udm2-instanceid UDM-udm1-instanceid" Behavior in SCP 23.2.0 (Enhancement 2): "Server" : "SCP-<SCP FQDN>"
3	UDM1 and UDM2 have generated error responses without server header.	Default behavior when addServerHeaderInProducerResponse is set to: true: "Server" : "UDM-udm2-instanceid" false: SCP won't add any server header Behavior in SCP 23.1.0 (Enhancement 1): "Server" : "UDM-udm2-instanceid UDM-udm1-instanceid" Behavior in SCP 23.2.0 (Enhancement 2): "Server" : "SCP-<SCP FQDN>"
4	UDM1 and UDM2 have generated error responses with server header.	Default behavior when addServerHeaderInProducerResponse is set to: true: "Server" : "UDM-udm2-instanceid" false: "Server" : "UDM-udm2-instanceid" Behavior in SCP 23.1.0 (Enhancement 1): "Server" : "UDM-udm2-instanceid UDM-udm1-instanceid" Behavior in SCP 23.2.0 (Enhancement 2): "Server" : "UDM-udm2-instanceid UDM-udm1-instanceid"
5	UDM1 sends an error response without server header and timeout has occurred at UDM2.	Default behavior when addServerHeaderInProducerResponse is set to: true: "Server" : "UDM-udm1-instanceid" false: SCP won't add any server header Behavior in SCP 23.1.0 (Enhancement 1): "Server" : "UDM-udm2-instanceid UDM-udm1-instanceid" Behavior in SCP 23.2.0 (Enhancement 2): "Server" : "SCP-<SCP FQDN>"
6	UDM1 sends an error response with server header and timeout has occurred at UDM2.	Default behavior when addServerHeaderInProducerResponse is set to: true: "Server" : "UDM-udm1-instanceid" false: "Server" : "UDM-udm1-instanceid" Behavior in SCP 23.1.0 (Enhancement 1): "Server" : "UDM-udm2-instanceid UDM-udm1-instanceid" Behavior in SCP 23.2.0 (Enhancement 2): "Server" : "UDM-udm1-instanceid"
7	UDM1 and UDM2 send error responses without server header.	Default behavior when addServerHeaderInProducerResponse is set to: true: "Server" : "UDM-udm2-instanceid" false: SCP won't add any server header Behavior in SCP 23.1.0 (Enhancement 1): "Server" : "UDM-udm2-instanceid UDM-udm1-instanceid" Behavior in SCP 23.2.0 (Enhancement 2): "Server" : "SCP-<SCP FQDN>"
8	UDM1 and UDM2 send error responses with server header.	Default behavior when addServerHeaderInProducerResponse is set to: true: "Server" : "UDM-udm2-instanceid" false: "Server" : "UDM-udm2-instanceid" Behavior in SCP 23.1.0 (Enhancement 1): "Server" : "UDM-udm2-instanceid UDM-udm1-instanceid" Behavior in SCP 23.2.0 (Enhancement 2): "Server" : "UDM-udm2-instanceid UDM-udm1-instanceid"
9	UDM1 sends an error response with server header and UDM2 sends an error response without server header.	Default behavior when addServerHeaderInProducerResponse is set to: true: "Server" : "UDM-udm2-instanceid" false: SCP won't add any server header Behavior in SCP 23.1.0 (Enhancement 1): "Server" : "UDM-udm2-instanceid UDM-udm1-instanceid" Behavior in SCP 23.2.0 (Enhancement 2): "Server" : "UDM-udm1-instanceid"
10	UDM1 sends an error response without server header.	Default behavior when addServerHeaderInProducerResponse is set to: true: "Server" : "UDM-udm1-instanceid" false: SCP won't add any server header Behavior in SCP 23.1.0 (Enhancement 1): "Server" : "UDM-udm1-instanceid" Behavior in SCP 23.2.0 (Enhancement 2): "Server" : "SCP-<SCP FQDN>"
11	UDM1 sends an error response with server header.	Default behavior when addServerHeaderInProducerResponse is set to: true: "Server" : "UDM-udm1-instanceid" false: "Server" : "UDM-udm1-instanceid" Behavior in SCP 23.1.0 (Enhancement 1): "Server" : "UDM-udm1-instanceid" Behavior in SCP 23.2.0 (Enhancement 2): "Server" : "UDM-udm1-instanceid"
12	UDM1 sends an error response with server header and UDM2 SCP couldn't do Alternate route due to some issue.	Default behavior when addServerHeaderInProducerResponse is set to: true: "Server" : "UDM-udm1-instanceid" false: "Server" : "UDM-udm1-instanceid" Behavior in SCP 23.1.0 (Enhancement 1): "Server" : "UDM-udm1-instanceid" Behavior in SCP 23.2.0 (Enhancement 2): "Server" : "UDM-udm1-instanceid"
13	UDM1 sends an error response without server header and UDM2 SCP couldn't do Alternate route due to some issue.	Default behavior when addServerHeaderInProducerResponse is set to: true: "Server" : "UDM-udm1-instanceid" false: SCP won't add any server header Behavior in SCP 23.1.0 (Enhancement 1): "Server" : "UDM-udm1-instanceid" Behavior in SCP 23.2.0 (Enhancement 2): "Server" : "SCP-<SCP FQDN>"
14	SCP is unable to connect with UDM1 and UDM2 due to connection issue.	Default behavior when addServerHeaderInProducerResponse is set to: true: "Server" : "SCP-<SCP FQDN>" false: "Server" : "SCP-<SCP FQDN>" Behavior in SCP 23.1.0 (Enhancement 1): "Server" : "SCP-<SCP FQDN>" Behavior in SCP 23.2.0 (Enhancement 2): "Server" : "SCP-<SCP FQDN>"
15	Timeout has occurred at UDM1.	Default behavior when addServerHeaderInProducerResponse is set to: true: "Server" : "SCP-<SCP FQDN>" false: "Server" : "SCP-<SCP FQDN>" Behavior in SCP 23.1.0 (Enhancement 1): "Server" : "SCP-<SCP FQDN> UDM-udm1-instanceid" Behavior in SCP 23.2.0 (Enhancement 2): "Server" : "SCP-<SCP FQDN>"
16	UDM1, UDM2, and UDM3 send error responses without server header.	Default behavior when addServerHeaderInProducerResponse is set to: true: "Server" : "UDM-udm3-instanceid" false: SCP won't add any server header Behavior in SCP 23.1.0 (Enhancement 1): "Server" : "UDM-udm3-instanceid UDM-udm2-instanceid UDM-udm1-instanceid" Behavior in SCP 23.2.0 (Enhancement 2): "Server" : "SCP-<SCP FQDN>"
17	UDM1, UDM2, and UDM3 send error responses with server header.	Default behavior when addServerHeaderInProducerResponse is set to: true: "Server" : "UDM-udm3-instanceid" false: "Server" : "UDM-udm3-instanceid" Behavior in SCP 23.1.0 (Enhancement 1): "Server" : "UDM-udm3-instanceid UDM-udm2-instanceid UDM-udm1-instanceid" Behavior in SCP 23.2.0 (Enhancement 2): "Server" : "UDM-udm3-instanceid UDM-udm2-instanceid UDM-udm1-instanceid"
18	UDM1 and UDM3 have connection issues and the pods are down. UDM2 sends an error response without server header.	Default behavior when addServerHeaderInProducerResponse is set to: true: "Server" : "UDM-udm2-instanceid" false: SCP won't add any server header Behavior in SCP 23.1.0 (Enhancement 1): "Server" : "UDM-udm2-instanceid" Behavior in SCP 23.2.0 (Enhancement 2): "Server" : "SCP-<SCP FQDN>"
19	UDM1 and UDM3 have connection issues and the pods are down. UDM2 sends an error response with server header.	Default behavior when addServerHeaderInProducerResponse is set to: true: "Server" : "UDM-udm2-instanceid" false: "Server" : "UDM-udm2-instanceid" Behavior in SCP 23.1.0 (Enhancement 1): "Server" : "UDM-udm2-instanceid" Behavior in SCP 23.2.0 (Enhancement 2): "Server" : "UDM-udm2-instanceid"
20	UDM1 sends an error response with server header. Timeout has occurred at UDM2, and UDM3 has connection issue and the pod is down.	Default behavior when addServerHeaderInProducerResponse is set to: true: "Server" : "UDM-udm1-instanceid" false: "Server" : "UDM-udm1-instanceid" Behavior in SCP 23.1.0 (Enhancement 1): "Server" : "UDM-udm2-instanceid UDM-udm1-instanceid" Behavior in SCP 23.2.0 (Enhancement 2): "Server" : "UDM-udm1-instanceid"
21	UDM1 sends an error response without server header. Timeout has occurred at UDM2, and UDM3 has connection issue and the pod is down.	Default behavior when addServerHeaderInProducerResponse is set to: true: "Server" : "UDM-udm1-instanceid" false: SCP won't add any server header Behavior in SCP 23.1.0 (Enhancement 1): "Server" : "UDM-udm2-instanceid UDM-udm1-instanceid" Behavior in SCP 23.2.0 (Enhancement 2): "Server" : "SCP-<SCP FQDN>"
22	Loop detection (508) occurred.	Default behavior when addServerHeaderInProducerResponse is set to: true: "Server" : "SCP-<SCP FQDN>" false: "Server" : "SCP-<SCP FQDN>" Behavior in SCP 23.1.0 (Enhancement 1): "Server" : "SCP-<SCP FQDN>" Behavior in SCP 23.2.0 (Enhancement 2): "Server" : "SCP-<SCP FQDN>"
23	UDM1 sends an error response with server header. Timeout has occurred at UDM2, and UDM3 has connection issue and the pod is down.	Default behavior when addServerHeaderInProducerResponse is set to: true: "Server" : "UDM-udm1-instanceid" false: "Server" : "UDM-udm1-instanceid" Behavior in SCP 23.1.0 (Enhancement 1): "Server" : "UDM-udm2-instanceid UDM-udm1-instanceid" Behavior in SCP 23.2.0 (Enhancement 2): "Server" : "UDM-udm1-instanceid"
24	UDM1 Sidecar returns special server headers.	Default behavior when addServerHeaderInProducerResponse is set to: true: SCP forwards the special server headers as it is to the Consumer. false: SCP forwards the special server headers as it is to the Consumer. Behavior in SCP 23.1.0 (Enhancement 1): SCP forwards the special server headers as it is to the Consumer. Behavior in SCP 23.2.0 (Enhancement 2): "Server" : "SCP-<SCP FQDN>"
25	Ingress Rate Limiting: SCP Generates an error message because the ingress rate was more than the allowed rate configured for the consumer as specified by the rules configured in the Ingress Rate Limiter REST API.	Default behavior when addServerHeaderInProducerResponse is set to: true: "Server" : "SCP-<SCP FQDN>" false: "Server" : "SCP-<SCP FQDN>" Behavior in SCP 23.1.0 (Enhancement 1): "Server" : "SCP-<SCP FQDN>" Behavior in SCP 23.2.0 (Enhancement 2): "Server" : "SCP-<SCP FQDN>"
26	Pod Overload: SCP-worker pod is overloaded due to CPU overload or pending transactions.	Default behavior when addServerHeaderInProducerResponse is set to: true: "Server" : "SCP-<SCP FQDN>" false: "Server" : "SCP-<SCP FQDN>" Behavior in SCP 23.1.0 (Enhancement 1): "Server" : "SCP-<SCP FQDN>" Behavior in SCP 23.2.0 (Enhancement 2): "Server" : "SCP-<SCP FQDN>"
27	OCI: UDM1 SCP doesn't attempt on UDM1 due to 100% OCI UDM2 SCP receives error response with server header.	Default behavior when addServerHeaderInProducerResponse is set to: true: "Server" : "UDM-udm2-instanceid UDM-udm1-instanceid" false: "Server" : "UDM-udm2-instanceid UDM-udm1-instanceid" Behavior in SCP 23.1.0 (Enhancement 1): "Server" : "UDM-udm2-instanceid UDM-udm1-instanceid" Behavior in SCP 23.2.0 (Enhancement 2): "Server" : "UDM-udm2-instanceid UDM-udm1-instanceid"
28	OCI: UDM1 SCP doesn't attempt on UDM1 due to 100% OCI. UDM2 SCP doesn't attempt on UDM2 due to 100% OCI.	Default behavior when addServerHeaderInProducerResponse is set to: true: "Server" : "SCP-<SCP FQDN> UDM-udm2-instanceid UDM-udm1-instanceid" false: "Server" : "SCP-<SCP FQDN> UDM-udm2-instanceid UDM-udm1-instanceid" Behavior in SCP 23.1.0 (Enhancement 1): "Server" : "SCP-<SCP FQDN> UDM-udm2-instanceid UDM-udm1-instanceid" Behavior in SCP 23.2.0 (Enhancement 2): "Server" : "SCP-<SCP FQDN> UDM-udm2-instanceid UDM-udm1-instanceid"

Managing Enhanced 5G SBI Message Failure Handling

Enable

This default behavior, which is specified in 3GPP TS 29.500, of this feature is enabled automatically in SCP at the time of deployment. To enable the enhanced server header behavior introduced in SCP 1.15.0, set Enable Enhance Server Header Behavior to true. To enable the enhanced server header behavior introduced in SCP 23.1.0 and later, set Enable Enhance Server Header Behavior V2 to true. For more information, see Configuring Server Header.

Note:

The enhanced server header behavior of SCP 1.15.0 and SCP 23.1.0 are mutually exclusive.

Configure

You can configure the Enhanced 5G SBI Message Failure Handling feature using the CNC Console or REST API.

• Configure using CNC Console: For information about server header parameters configuration, see Configuring Server Header.
• Configure using REST API: For information about server header configurations, see "Configuring Server Header" in Oracle Communications Cloud Native Core, Service Communication Proxy REST Specification Guide.

Observe

Updated the ocscp_metric_sidecarproxy_failures_total metric with the ocscp_server_header dimension in the Metrics section.

Added the SCPServiceMeshFailure alert in the Alerts section.

Maintain

If you encounter alerts at system level, see the Alerts section for resolution steps.

In case the alerts persist, perform the following tasks:

1. Collect the logs: For information about how to collect logs, see Oracle Communications Cloud Native Core, Service Communication Proxy Troubleshooting Guide.
2. Raise a service request: For information about how to raise a service request, see My Oracle Support.

3.25 Extension of HTTP Status Code List for Rerouting

SCP can reroute a request when a producer responds with an error code. Prior to this release, rerouting took place based on the configurable response codes. However, the list of configurable error codes was limited to a smaller set of enumerations (ENUMs), such as GATEWAY_ERROR, few other status codes and ENUMs.

With this enhancement, SCP now supports rerouting a request based on an extended list of configurable HTTP Status codes. The user-provided configurable list of error codes serves as the basis for rerouting. A wider set of numerical response codes is supported with the introduction of the new attribute "reRouteConditionList," which replaced the old attribute "reRouteOnResponseCodeList" in the Routing Options REST API. When a received error code matches a status code in the configurable list, the SCP reroutes the request based on the configured alternate routing mechanism.

Managing Configurable HTTP Status Codes for Rerouting

Enable

You can enable this feature using REST API by setting the reRouteConditionList routing option parameter. For more information about this parameter, see "Configuring Routing Options" in Oracle Communications Cloud Native Core, Service Communication Proxy REST Specification Guide.

Configure

You can configure the HTTP Status Codes for Rerouting functionality using the CNC Console or REST API.

• Configure using CNC Console: For information about how to configure HTTP Status Codes for Rerouting, see Configuring Routing Options.
• Configure using REST API: For information about how to configure HTTP Status Codes for Rerouting, see "Configuring Routing Options" in Oracle Communications Cloud Native Core, Service Communication Proxy REST Specification Guide.

Observe

There is no specific metrics and alerts required for the Extension of HTTP Status Code List for Rerouting functionality.

Maintain

If you encounter alerts at system level, see the Alerts section for resolution steps.

In case the alerts persist, perform the following tasks:

1. Collect the logs: For information about how to collect logs, see Oracle Communications Cloud Native Core, Service Communication Proxy Troubleshooting Guide.
2. Raise a service request: For information about how to raise a service request, see My Oracle Support.

3.26 Load Balancing

The 5G core network is a service-based architecture that does not lend itself to an efficient load balancing of provider NFs. By introducing Service Communication Proxy (SCP) in the midst, the load balancing across available NFs can be significantly improved. SCP has a complete view of all the messages arriving for a given NF type and supports traffic distribution patters, such as round-robin, based on its capacity and availability by enabling uniform load balancing strategy across the network.

SCP supports Load Balancing Algorithm: Priority and Capacity. Load balancing across the equivalent NF or NF Services is based on the priority and capacity.

Managing Load Balancing

Enable

The Load Balancing feature is a core functionality of SCP.

You can enable this feature using REST API by setting the routePolicy routing option parameter to Load_Balance. For more information about this parameter, see "Configuring Routing Options" in Oracle Communications Cloud Native Core, Service Communication Proxy REST Specification Guide.

Note:

This feature is enabled automatically if you are deploying SCP with Release 16 of Model C. For more information about Model C, see Support for Model C Indirect 5G SBI Communication.

Configure

You can configure the Load Balancing functionality using the CNC Console or REST API.

• Configure using CNC Console: For information about how to configure load balancing, see Configuring Routing Options.
• Configure using REST API: For information about how to configure load balancing, see "Configuring Routing Options" in Oracle Communications Cloud Native Core, Service Communication Proxy REST Specification Guide.

Observe

There is no specific metrics and alerts required for the Load Balancing functionality.

Maintain

If you encounter alerts at system level, see the Alerts section for resolution steps.

In case the alerts persist, perform the following tasks:

1. Collect the logs: For information about how to collect logs, see Oracle Communications Cloud Native Core, Service Communication Proxy Troubleshooting Guide.
2. Raise a service request: For information about how to raise a service request, see My Oracle Support.

3.27 5G SBI Message Mediation Support

SCP supports Mediation as an independent service to modify 5G Service Based Interface (SBI) message content, which includes HTTP2 header values and JSON message body, based on the user-defined mediation rule sets.

SCP uses microservice, scp-mediation, that applies user configured message mediation policy rules to ingress 5G SBI messages to perform message mediation transformation. The scp-worker microservice applies mediation invocation filter criteria according to the mediation trigger point configuration and forwards 5G SBI messages to the scp-mediation microservice.

The following parameters are configured to forward SBI messages to Mediation from the trigger points:

• nfType: It routes all message requests for this nfType to the scp-mediation microservice.
• serviceName: It routes all message requests for this serviceName to the scp-mediation microservice.
• httpMethods: It routes all messages of a particular HTTP method type, which corresponds to the methods specified in this list, to the scp-mediation microservice.
• triggerPoints: It contains the list of trigger points that must be enabled to forward message requests from SCP to the scp-mediation microservice from the enabled trigger point. It has four values, requestIngress, requestEgress, responseIngress, and responseEgress.
• match: This block specifies the criteria required to match HTTP headers or JSON body or the both to route to the scp-mediation microservice.

Note:

• Mediation is supported only in Release 16 SCP deployment.
• Mediation does not support multipart messages.

Pseudo Headers

Pseudo headers in service requests can be used in mediation rules to meet the condition, modify, or assign values to the user-defined variables.

SCP-Worker sends pseudo header values in the x-original-* headers, which can be used at mediation to modify the corresponding pseudo headers. If SCP detects any change in any of the x-original-* header value that SCP-Worker has passed to the mediation service, SCP-Worker will use the modified value of that x-original-* header to forward the message to peers.

The following sample represents pseudo header values of "x-original-path", "x-original-method", "x-scp-authority", "x-message-type", and "x-original-status" that can be used in the mediation rule to assign the values to the user-defined variables:

rule "RuleS1"
   agenda-group "groupId1-requestIngress"
when
   req : Request(headers.get("3gpp-sbi-routing-binding")  == "bl=nf-set;nfset=set1.chfset.5gc.mnc012.mcc345")
then
   req.variable.add("x-original-path",req.headers.get("x-original-path"))
   req.variable.add("x-original-scheme",req.headers.get("x-original-scheme"))
   req.variable.add("x-original-method",req.headers.get("x-original-method"))
   req.variable.add("x-scp-authority",req.headers.has("x-scp-authority"))
   req.variable.add("x-message-type","response")
   req.variable.add("authorityValue","http://chf2svc.default.svc.cluster.local:8080/USEast/nchf-convergedcharging/v1/chargingdata/"))
   req.variable.add("supi",req.body.get("$.subscriberIdentifier.supi").toString())
   req.variable.add("fqdn","http://chf1svc.default.svc.cluster.local:8080/USEast")
end

The following sample represents pseudo header values that can be updated and set based on the user-defined variables or any other conditions in the mediation rule:

rule "RuleS10_1"
   agenda-group "groupId1-requestEgress"
when
   req : Request(variable.get("x-original-path")  == "/USEast/nchf-convergedcharging/v1/chargingdata/"
   && variable.get("x-original-scheme") == "http"
   && variable.get("x-original-method") == "POST"
   && variable.get("x-scp-authority") == true
   && variable.get("supi") == "imsi-1234567814"
   && variable.get("authorityValue") == "http://chf2svc.default.svc.cluster.local:8080/USEast/nchf-convergedcharging/v1/chargingdata/"
then
   req. setUri(req.variable.get("uri").toString())
   req.headers.put(“x-original-scheme”,“https”)
end

rule "PseudoHeader3"
   agenda-group "groupId3-responseIngress"
when
    res : Response(headers.get("x-original-status") == "201")
then
    res.headers.put("x-original-status","204")
end

The following table describes different pseudo headers:

Table 3-27 Pseudo Headers

Header Name	Description
x-original-path	Carries the original path that is received in the request, that is, value of “:path” header of original message. x-original-path - “:path” header of original message. Example: /USEast/nchf-convergedcharging/v1/chargingdata/
x-original-scheme	Indicates the scheme of the received service request, that is, value of “:scheme” header of original message. x-original-scheme - “:scheme” header of original message. Example: http or https
x-original-method	Indicates the type of method for the received service request, that is, value of “:method” header of original message. Example: POST, GET, PUT
x-message-type	Indicates the value of message type, which can be "request" or "response". By default, if this header is absent, it will be treated as a "request". x-message-type - Value can be “request” or “response” Example: response or request
x-original-status	Indicates the response status in terms of status code, that is, value of “:status” header of original message. x-original-status - “:status” header of original message. Example: response status code ex:201, 200
setUri or ":authority" or "x-original-authority"	Indicates the correct target NF service in the PLMN, that is, value of “:authority” header of original message. x-original-authority- “:authority” header of original message. Example: :authority: udm1svc.scpsvc.svc.cluster.local:8080

Managing Mediation Support Feature

Enable

To enable 5G SBI Message Mediation Support feature, set the mediationService parameter to true in the global parameters section of the custom-values.yaml file. For more information about this parameter, see Oracle Communications Cloud Native Core, Service Communication Proxy Installation, Upgrade, and Fault Recovery Guide.

Note:

You can configure the required Helm parameters for this feature if you have performed a fresh installation of SCP or upgraded SCP within the same release version.

Configure

You can configure the Mediation features using REST API and the CNC Console:

• Configure using CNC Console: You can enable the 5G SBI Message Mediation Support feature by setting mediation to true. For more information, see Configuring SCP Features.

  To configure trigger points, see Configuring Mediation and to configure mediation routing options, see Configuring Routing Options for Mediation.

  To configure the mediation rules, see Configuring Mediation Rules.

  To configure mediation at the log level, see Configuring Mediation Log Levels section.

• Configure using REST API: For information about configuring trigger points, see "Configuring Mediation Trigger Point", and for configuring mediation routing options, see "Configuring App Routing Options".

  To configure mediation rules using the REST API, see "Configuring Mediation Rules".

  To configure mediation at the log level using the REST API, see "Configuring Mediation Rules" in Oracle Communications Cloud Native Core, Service Communication Proxy REST Specification Guide.

Maintain

If you encounter alerts at system level, see the Alerts section for resolution steps.

In case the alerts persist, perform the following tasks:

1. Collect the logs: For information about how to collect logs, see Oracle Communications Cloud Native Core, Service Communication Proxy Troubleshooting Guide.
2. Raise a service request: For information about how to raise a service request, see My Oracle Support.

3.27.1 Mediation Rules Configuration

Mediation rules stored in the database can be retrieved, new rules can be added, and existing rules can be modified using the CCNC GUI and RESTful API. In addition, the storage capacity has improved.

Figure 3-7 Rule Status Flow

The following table lists the state of rules and its description

Table 3-28 Types of State

State	Description
Clone	To create a new rule, the values of the rule already created and stored in the database are used. This newly created rule has a name followed by a term draft. A new name must be provided as a rule.
Compile	This state precompiles, takes the rule source, and builds an executable rule base.
Draft	This state moves a rule from APPLIED status to DRAFT status.
Apply	This state moves a rule from DRAFT status to APPLY status.
Save	This state saves the changes in database.

The table lists the modifications allowed to be configured in rule status:

Table 3-29 Rule Status

Field Name	DRAFT status	Applied status
Rule Name	Not Allowed	Not Allowed
Format	Not Allowed	Not Allowed
Status	Not Allowed	Not Allowed
Mediation Mode	Allowed	Allowed
Code	Allowed	Not Allowed
State	Allowed	Allowed

Note:

The Rule Name must be unique. The status of a rule can be DRAFT or APPLIED. Only DRAFT status can be deleted, edited, or viewed.

This section describes APIs that are used to define Mediation rules.

Header Rule APIs

The following are the header APIs used to create header rules supported in Mediation.

Table 3-30 Header Rule APIs

API Name	Return Type	Description
get(String key)	String	Returns the header value for the key specified. Example: Request(headers.get("x-number") )
has(String key)	Boolean	Returns true or false depending on whether the header specified by the key attribute is present or absent. Example: Request(headers.has("3gpp-Sbi-Producer-Id"))
has(String key, String value)	Boolean	Returns true or false depending on whether the header specified by the key attribute is present. Example: Request(headers.has("3gpp-Sbi-Producer-Id","nfinst=1faf1bbc-6e4a-3994-a507-a14ef8e1bc23"))
put( String key, String value)	Boolean	Creates the header with the specified key value pair if the key is absent. If the key is present, it updates the value of the header with the specified value. Example: req.headers.put("x-original-authority", "10.172.19.110:8080")
add( String key, String value);	Boolean	Adds the header with the provided key and value if it does not find the key. Example: req.headers.add("Content-type","application/json")
set( String key, String value);	Boolean	Updates the header with the value if the provided key is found. Example: req.headers.set("3gpp-Sbi-Producer-Id","nfinst=1faf1bbc-6e4a-3994-a507-a14ef8e1bc25")
set( String key, String oldValue, String newValue);	Boolean	Updates the header with a newValue if the existing value of the header matches with the value specified by the oldValue attribute. Example: req.headers.set("x-number", "2", "3")
del(String key)	Boolean	Removes the header specified by the key attribute. Example: req.headers.del("3gpp-Sbi-Message-Priority")
del(String key, String value)	Boolean	Removes the header if it matches with the provided key and value. Example: req.headers.del("x-forwarded-NF","NRF")
count();	Integer	Returns the total count of all the headers. Example: Request(headers.count())
count(String key);	Integer	Returns the total count of headers with the key. Example: Request(headers.count("Accept"))
count(String key, String value)	Integer	Returns the total count of headers with the key and value. Example: Request(headers.count("Accept","application/json"))

APIs for Modifying Request Body

The following table describes the rule APIs to update and delete HTTP message body that are supported in mediation:

Note:

The paths in all the parameters must be in the JSONPath format.

Table 3-31 APIs for Modifying Request Body

API Name	Return Type	Description
get(String path)	Object	Returns the value present at the specified path. Example: body.get("$.serviceName")
getAll(String path)	List<Object>	Returns the list of objects present at the specified path. Example: body.getAll("$.serviceName")
has(String path);	boolean	Checks whether the key is present at the path or not. Example: body.has("$.serviceName")
has(String path, Object value)	boolean	Checks whether the key has the value present at the path or not. Example: body.has("$.serviceName","value")
absPath(String arrayPath, String elem, Object value)	Object	Returns the whole path from the head to the element if the value is present. Example: req.body.absPath("$.payload","iePath", "/a")
indexOf(String arrayPath, String elem, Object value)	Integer	Returns the index of the value in that JSONArray. Example: req.body.indexOf("$.dataToIntegrityProtectBlock.payload","value", 100)
put(String path, String key, T value)	boolean	Adds the body with the provided key and value at the path if the key is absent. Otherwise, update the body with the value at the path. Example: req.body.put("$","key","value") Note: It is recommended to use the PUT method while trying to add a new key.
add(String path, T value)	boolean	Adds the key embedded in the path with the provided value if the element is absent. Example: req.body.add("$.ipEndPoints","value") Note: When adding a new key, the PUT method is always preferred over the ADD method.
set(String path, T value)	boolean	Updates the key embedded in the path with the provided value if the element is present. Example: rsp.body.set("$.ipEndPoints","value")
del(String path, T value)	boolean	Removes the element at that path with the value present. Not supported. Example: req.body.del("$.path","value")
del(String path)	boolean	Removes the element at that path. Example: req.body.del("$.path")

HTTP Message Common APIs

The following are the common HTTP message APIs supported by both request and response body.

Table 3-32 HTTP Message Common APIs

API Name	Return Type	Description
getUri()	String	Returns the URI of the request. Example: req.getUri()
setUri(String URI)	void	Sets the URI in the body of the request. Example: req.setUri("http://oracle.com")
getHttpStatusCode()	Integer	Returns the StatusCode from the body of the response. Example: rsp.getHttpStatusCode()
setHttpStatusCode(Integer httpStatusCode)	void	Sets the StatusCode in the body of the response. Example: rsp.setHttpStatusCode(201)
getRejectMessage()	String	Returns the Reject Message from the body of the response. Example: rsp.getRejectMessage()
setRejectMessage(String rejectMessage)	void	Sets the Reject Message in the body of the response. Example: rsp.setRejectMessage("Message")

The following User Defined Variable APIs are supported in mediation:

Table 3-33 User Defined Variable APIs

API Name	Return Type	Description
get(String key)	Object	Returns the value of a user-defined variable associated with the specified key. Example:req.variable.get("key") or rsp.variable.get("key")
getAll()	String	Returns all user-defined variables and their values that have been configured through mediation rules. Example: req.variable.getAll() or rsp.variable.getAll()
has(String key)	Boolean	Returns true or false based on the presence of the user-defined variable. Example:req.variable.has("key") or rsp.variable.has("key")
has(String key, Long value) has(String key, Boolean value) has(String key, String value)	Boolean	Returns true or false depending on whether the user-defined variable is present with the specified value. Example:req.variable.has("key",1243456789) or rsp.variable.has("key",1243456789) req.variable.has("key",true) or rsp.variable.has("key",true) req.variable.has("key","value") or rsp.variable.has("key","value") req.variable.has("key","{\"test-key\":\"test-value\",\"test-key2\":{\"test-key2-key\":\"test-val\"}}") or rsp.variable.has("key","{\"test-key\":\"test-value\",\"test-key2\":{\"test-key2-key\":\"test-val\"}}")
put(String key, long value) put(String key, Boolean value) put(String key, String value)	Boolean	Adds the user-defined variable with the specified key and value if it doesn't exist, or updates the variable's value if the key is found. Example:req.variable.put("key",1243456789) or rsp.variable.put("key",1243456789) req.variable.put("key",true) or rsp.variable.put("key",true) req.variable.put("key","value") or rsp.variable.put("key","value") req.variable.put("key","{\"test-key\":\"test-value\",\"test-key2\":{\"test-key2-key\":\"test-val\"}}") or rsp.variable.put("key","{\"test-key\":\"test-value\",\"test-key2\":{\"test-key2-key\":\"test-val\"}}")
add(String key, Long value) add(String key, Boolean value) add(String key, String value)	Boolean	Adds the user-defined variable with the specified key and value if it does not already exist. Example:req.variable.add("key",1243456789) or rsp.variable.add("key",1243456789) req.variable.add("key",true) or rsp.variable.add("key",true) req.variable.add("key","value") or rsp.variable.add("key","value") req.variable.add("key","{\"test-key\":\"test-value\",\"test-key2\":{\"test-key2-key\":\"test-val\"}}") or rsp.variable.add("key","{\"test-key\":\"test-value\",\"test-key2\":{\"test-key2-key\":\"test-val\"}}")
set(String key, Long value) set(String key, Boolean value) set(String key, String value)	Boolean	Updates the user-defined variable with the specified value if the given key is found. Example:req.variable.set("key",1243456789) or rsp.variable.set("key",1243456789) req.variable.set("key",true) or rsp.variable.set("key",true) req.variable.set("key","value") or rsp.variable.set("key","value") req.variable.set("key","{\"test-key\":\"test-value\",\"test-key2\":{\"test-key2-key\":\"test-val\"}}") or rsp.variable.set("key","{\"test-key\":\"test-value\",\"test-key2\":{\"test-key2-key\":\"test-val\"}}")
set(String key, Long oldValue, Long newValue) set(String key, Boolean oldValue, Boolean newValue) set(String key, String oldValue, String newValue)	Boolean	Updates the user-defined variable with a new value if the existing value matches the specified old value. Example: req.variable.set("header",1243456789,124345678999) or rsp.variable.set("header",1243456789,124345678999) req.variable.set("header",true,false) or rsp.variable.set("header",true,false) req.variable.set("header"," old value","new value") or rsp.variable.set("header"," old value","new value") req.variable.set("key","{\"test-key\":\"test-value\",\"test-key2\":{\"test-key2-key\":\"test-val\"}}", "{\"test-key1\":\"test-value\",\"test-key2\":{\"test-key2-key\":\"test-val\"}}") or rsp.variable.set("key","{\"test-key\":\"test-value\",\"test-key2\":{\"test-key2-key\":\"test-val\"}}", "{\"test-key1\":\"test-value\",\"test-key2\":{\"test-key2-key\":\"test-val\"}}")
del(String key)	Boolean	Deletes the user-defined variable if it matches the specified key. Example: req.variable.del("header") or rsp.variable.del("header")
del(String key, Long value) del(String key, Boolean value) del(String key, String value)	Boolean	Deletes the user-defined variable if it matches both the specified key and value. Example: req.variable.del("key",1243456789) or rsp.variable.del("key",1243456789) req.variable.del("key",true) or rsp.variable.del("key",true) req.variable.del("header","value") or rsp.variable.del("header","value") req.variable.del("key","{\"test-key\":\"test-value\",\"test-key2\":{\"test-key2-key\":\"test-val\"}}") or rsp.variable.del("key","{\"test-key\":\"test-value\",\"test-key2\":{\"test-key2-key\":\"test-val\"}}")
count();	Integer	Returns the total count of all user-defined variables. Example: req.variable.count() or rsp.variable.count()

Mediation Service Rule Configuration with Scenarios

This section captures various types of mediation rule configuration with scenarios.

Use Case 1

To update the headers for specific requests.

Scenario

The mediation rule is configured when headers get ("pduSessionId"="23476") and add the header (X-Service-Name=PCF) value to the request.

Mediation Rule

rule "Rule2_PCF"
    agenda-group "CUSTOM_ORACLE_SCP-requestEgress"
when
   req : Request(headers.get("pduSessionId") == "23476")
then
   req.headers.put("x-service-name","PCF")
end

Use Case 2

To add, update, or delete any attribute in the JSON payload in the request or response.

Scenario

Mediation rule is configured as when incoming response payload got servingNetworkName="5G:nmc310.mcc310.3gppnetwork.org" then delete the "traceData" attribute and add TP="ResIngressAusf" in json payload.

Mediation Rule

rule "Rule7_AUSF"
       agenda-group "CUSTOM_ORACLE_SCP-responseIngress"
when
      res : Response(body.get("$.servingNetworkName")=="5G:nmc310.mcc 310.3gppnetwork.org")
then
     res.body.del("$.traceData")
     res.body.put("$","TP","ResIngressAusf")
end

Use Case 3

To update URI components such as apiRoot, apiName, apiVersion, and apiSpecificResourceUriPart in the request or response.

Scenario

Mediation rule is configured as when request payload got "3gpp-sbi-target-apiroot"="http://ausf1svc.default.svc.cluster.local:8080/USEast" then update the URI to "http://ausf2svc.scpsvc.svc.cluster.local:8080/USEast/nausf-auth/v1/ue-authentications".

Mediation Rule

rule "Rule5_AUSF"
     agenda-group "CUSTOM_ORACLE_SCP-requestEgress"
when 
    req : Request(headers.get("3gpp-sbi-target-apiroot") == "http://ausf1svc.default.svc.cluster.local:8080/USEast")
then
    req.setUri("http://ausf2svc.default.svc.cluster.local:8080/USEast/nausf-auth/v1/ue-authentications")
end

Use Case 4

To update the authority in apiRoot coming in the request or response.

Scenario

Mediation rule is configured as when request header got 3gpp-Sbi-Target-apiRoot="http://pcf1svc.default.svc.cluster.local:8080/USEast" update the authority to pcf3 from pfc1.

Mediation Rule

rule "Rule6_PCF"
    agenda-group "CUSTOM_ORACLE_SCP-requestEgress"
when
    req : Request(headers.get("3gpp-sbi-target-apiroot") == "http://pcf1svc.scpsvc.svc.cluster.local:8080/USEast")
then
    req.setUri("http://pcf3svc.scpsvc.svc.cluster.local:8080/USEast/npcf-smpolicycontrol/v1/sm-policies")
end

Use Case 5

To add any vendor-specific header.

Scenario

Mediation rule is configured as when response payload got "sliceInfo"=="adfg127" then add the vendor-specific header ("$,"x-service-name","PCF").

Mediation Rule

rule "Rule2_PCF"
     agenda-group "CUSTOM_ORACLE_SCP_requestEgress"
when
     req : Request(body.get("$.sliceInfo") == "adfg127")
then
    req.headers.put("x-service-name","PCF")
end

Use Case 6

To convert the response status code that it received to any specific status code.

Scenario

The mediation rule is configured; if mediation receives an HTTP response code of 401, it should update the response code to 402.

Mediation Rule

rule "status rule_responseEgress"
    agenda-group "CUSTOM_ORACLE_SCP_responseEgress"
when
    rsp : Response(getHttpStatusCode() == "402")
then
    rsp.setHttpStatusCode(401)
end

Use Case 7

To update authority in apiRoot based on a JSON-nested object from the body.

Scenario

The mediation rule is configured to segregate NF Producer based on MSISDN.

To retrieve the nested parameter, servedGPSI, from the below structure:

"pDUSessionChargingInformation":{
   "chargingId":747941933,
   "pduSessionInformation":{},
   "uetimeZone":"+00:00+0",
   "userInformation":{
           "servedGPSI":"msisdn-447432982860",
           "servedPEI":"imeisv-3528878115855501",
           "unauthenticatedFlag":false
            },
“

Mediation Rule

rule "G_N40_odd"
        agenda-group "G_N40_odd-requestIngress"
when
        req : Request(body.get("$.pDUSessionChargingInformation.userInformation.servedGPSI")=="msisdn-447432982860")
then
        req.headers.put("3gpp-sbi-target-apiroot",http://10.251.132.183:8080)
end

3.27.1.1 Mediation Rule Migration Process

Previously, rules were used from the Kubernetes config map. Currently, the rules present in the config map are migrated to the database table (mediation_rule table).

This section describes the procedure to execute the migration of rules from the existing config-map based implementation into the new REST API.

The following are the config-map related to mediation:

• ocscp-nf-mediation-config-boot: It contains all the configuration related to the spring boot application and is used in both modes (test and active).
• ocscp-nf-mediation-config-active: It contains rule entries and is only applicable to active mode.
• ocscp-nf-mediation-config-test: It contains rule entries and is only applicable to test mode.

• The following image illustrates the migration process:

  Figure 3-8 Migration to Database table

  
  

  

  
  

Note:

To successfully migrate to database table, all the rules in the Config map must be valid.

Generate Rule Entries

1. Read ocscp-nf-mediation-config-active configuration map.
2. For each entry in key-value map structure, create entry in Rule table with the following:
   1. Rule.name: entry.key removing .drl extension
   2. Rule.code: entry.value
   3. Rule.status: APPLIED
   4. Rule.mode: MEDIATION_ACTIVE
3. Read ocscp-nf-mediation-config-test configuration map.
4. Create entry in Rule table with the following:
   1. Rule.name: entry.key removing .drl extension adding "-test" as sufix to avoid name conflicts with active configmap
   2. Rule.code: entry.value
   3. Rule.status: APPLIED
   4. Rule.mode: MEDIATION_TEST

Migration of Rule Entries

The following examples details about the rule migrated from configmap to database table.

Example of ocscp-nf-mediation-config-active configuration map:

apiVersion: v1
kind: ConfigMap
metadata:
  creationTimestamp: "2022-11-11T13:15:14Z"
  name: nf-mediation-nf-mediation-config-active
  namespace: scpsvc
data:
  rule_1.drl: |
    package com.oracle.cgbu.ocmediation.nfmediation;
 
    import com.oracle.cgbu.ocmediation.nfruleengine.NFDroolsRuleEngine;
    import com.oracle.cgbu.ocmediation.factdetails.Request;
    import com.oracle.cgbu.ocmediation.factdetails.Response;
    import java.util.Map;
    import java.util.HashMap;
 
    dialect "mvel"
 
    rule "Rule_show_add_header"
    when
       req : Request(headers.has("header-test") == true)
    then
       req.headers.add("3gpp-Sbi-Message-Priority","10")
       req.headers.del("x-test-req-header1")
    end
 
    rule "Rule_show_delete_header"
    when
       req : Request(headers.has("header-test2") == true)
    then
       req.headers.del("header-test2")
    end
 
   rule_2.drl: |
    package com.oracle.cgbu.ocmediation.nfmediation;
 
    import com.oracle.cgbu.ocmediation.nfruleengine.NFDroolsRuleEngine;
    import com.oracle.cgbu.ocmediation.factdetails.Request;
    import com.oracle.cgbu.ocmediation.factdetails.Response;
    import java.util.Map;
    import java.util.HashMap;
 
    dialect "mvel"
 
    rule "Rule_show_add_headerv2"
    when
       req : Request(headers.has("another-header") == true)
    then
       req.headers.add("new-header2","10")
    end

Example of ocscp-nf-mediation-config-test configuration map:

apiVersion: v1
kind: ConfigMap
metadata:
  creationTimestamp: "2022-11-11T13:15:14Z"
  name: nf-mediation-nf-mediation-config-test
  namespace: scpsvc
data:
  rule_1.drl: |
    package com.oracle.cgbu.ocmediation.nfmediation;
 
    import com.oracle.cgbu.ocmediation.nfruleengine.NFDroolsRuleEngine;
    import com.oracle.cgbu.ocmediation.factdetails.Request;
    import com.oracle.cgbu.ocmediation.factdetails.Response;
    import java.util.Map;
    import java.util.HashMap;
 
    dialect "mvel"
 
    rule "Rule_show_add_header"
    when
       req : Request(headers.has("header-test") == true)
    then
       req.headers.add("3gpp-Sbi-Message-Priority","10")
       req.headers.del("x-test-req-header1")
    end
 
    rule "Rule_show_delete_header"
    when
       req : Request(headers.has("header-test2") == true)
    then
       req.headers.del("header-test2")
    end

In this examples, the ocscp-nf-mediation-config-active configuration map has two different entries (rule_1.drl and rule_2.drl) and rule_1.drl has the definition of two different rules, Rule_show_add_header and Rule_show_delete_header, it is important to consider that rule_1 will have a single rule entry in the database containing all the code for its two rules.

In this case, the database entries are as follows:

Table 3-34 Database Entries

Name	Status	Mode	Code
rule_1	APPLIED	MEDIATION_ACTIVE	package com.oracle.cgbu.ocmediation.nfmediation; import com.oracle.cgbu.ocmediation.nfruleengine.NFDroolsRuleEngine; import com.oracle.cgbu.ocmediation.factdetails.Request; import com.oracle.cgbu.ocmediation.factdetails.Response; import java.util.Map; import java.util.HashMap; dialect "mvel" rule "Rule_show_add_header" when req : Request(headers.has("header-test") == true) then req.headers.add("3gpp-Sbi-Message-Priority","10") req.headers.del("x-test-req-header1") end rule "Rule_show_delete_header" when req : Request(headers.has("header-test2") == true) then req.headers.del("header-test2") end
rule_2	APPLIED	MEDIATION_ACTIVE	package com.oracle.cgbu.ocmediation.nfmediation; import com.oracle.cgbu.ocmediation.nfruleengine.NFDroolsRuleEngine; import com.oracle.cgbu.ocmediation.factdetails.Request; import com.oracle.cgbu.ocmediation.factdetails.Response; import java.util.Map; import java.util.HashMap; dialect "mvel" rule "Rule_show_add_headerv2" when req : Request(headers.has("another-header") == true) then req.headers.add("new-header2","10") end
rule_1-test	APPLIED	MEDIATION_TEST	package com.oracle.cgbu.ocmediation.nfmediation; import com.oracle.cgbu.ocmediation.nfruleengine.NFDroolsRuleEngine; import com.oracle.cgbu.ocmediation.factdetails.Request; import com.oracle.cgbu.ocmediation.factdetails.Response; import java.util.Map; import java.util.HashMap; dialect "mvel" rule "Rule_show_add_header" when req : Request(headers.has("header-test") == true) then req.headers.add("3gpp-Sbi-Message-Priority","10") req.headers.del("x-test-req-header1") end rule "Rule_show_delete_header" when req : Request(headers.has("header-test2") == true) then req.headers.del("header-test2") end

3.27.2 Mediation Log Level Configuration

The Mediation Log Level Configuration feature allows users to fetch and update the log level settings of the mediation service. Through the REST API, users can control the mediation log level, enhancing the operational efficiency of the mediation service.

Managing Log Level Configuration

Enable

To enable 5G SBI Message Mediation Support feature, set the mediationService parameter to true in the global parameters section of the custom-values.yaml file. For more information about this parameter, see Oracle Communications Cloud Native Core, Service Communication Proxy Installation, Upgrade, and Fault Recovery Guide.

Note:

You can configure the required Helm parameters for this feature if you have performed a fresh installation of SCP or upgraded SCP within the same release version.

Configure

You can configure the Mediation features using REST API and the CNC Console.

• Configure using CNC Console: You can enable the 5G SBI Message Mediation Support feature by setting mediation to true. For more information, see Configuring SCP Features.

  To configure mediation at the log level, see Configuring Mediation Log Levels section.

• Configure using REST API: To configure mediation at the log level using the REST API, see "Configuring Mediation Rules" in Oracle Communications Cloud Native Core, Service Communication Proxy REST Specification Guide.

Maintain

If you encounter alerts at system level, see the Alerts section for resolution steps.

In case the alerts persist, perform the following tasks:

1. Collect the logs: For information about how to collect logs, see Oracle Communications Cloud Native Core, Service Communication Proxy Troubleshooting Guide.
2. Raise a service request: For information about how to raise a service request, see My Oracle Support.

3.27.3 Mediation Support for User Defined Variables in Rules and Trigger Points

Mediation Support for User Defined Variables in Rules and Trigger Points functionality in SCP allows users to store information in a mediation trigger point and then pass that information to another mediation trigger point for the same transaction. This is particularly useful when dealing with complex message manipulations, such as modifying a response based on the content of the initial request.

This feature supports the storage of various types of information, including header values, values from JSON payloads, modified values based on mediation rules, or custom values derived from specific conditions. Users can store information with a custom name using User Defined Variables (UDVs) REST API, which can then be read or written within the mediation rules. Additionally, these variables and their values will be transmitted to the SCP-Worker as a mediation response header, with the header name med-user-defined-var-list.

For example:

med-user-defined-var-list=[{\"serviceName\":\"npcf-smpolicycontrol\",\"targetNfType\":\"PCF\",\"requesterNfType\":\"AMF\",\"supi\":\"imsi-1234567814\",\"pduSession\":23476}]

Use cases examples:

• Update Discovery Response Based on Requester NF Type: The discovery response does not contain details about the requester NF, making it challenging to mediate the response based on the requester NF. This feature allows users to store the requester NF information at the RxRequest trigger point and use the stored requester NF type information to mediate the discovery response at the RxResponse trigger point.
• Update Response Based on Derived Information from the Request: Users can define mediation rules to identify and store the user category as prepaid or postpaid at the RxRequest trigger point. The stored user category information can then be used to mediate the response at the RxResponse trigger point.

Usage of User Defined Variables in Mediation Rules

The user-defined variables can be used in both the conditions and actions of mediation rules, as well as in the matching configurations based on mediation trigger points at SCP to qualify messages for mediation. The stored information about UDVs at the mediation trigger points will not be included in the communication to the SCP peer.

Managing User Defined Variables in Mediation Rules and Trigger Points

Enable

To enable 5G SBI Message Mediation Support feature, set the mediation Service parameter to true in the global parameters section of the custom_values.yaml file. For more information about this parameter, see Oracle Communications Cloud Native Core, Service Communication Proxy Installation, Upgrade, and Fault Recovery Guide.

Configure

You can configure the Mediation features using REST API and the CNC Console.

• Configure using CNC Console: You can enable the Mediation Support for User Defined Variables in Rules and Trigger Points feature by setting mediation and User Defined Variable to true. For more information, see Configuring Mediation. To configure Mediation Support for User Defined Variables in Rules and Trigger Points, see Configuring Mediation Support for User Defined Variables section. For instructions on setting up trigger points, see Configuring Mediation Trigger Point. To set up mediation rules, see Configuring Mediation Rules.
• Configure using REST API:

  For information on configuring mediation, see the "Configuring SCP Features" section. For instructions on setting up trigger points, see "Configuring Mediation Trigger Points". To configure mediation routing options, see "Configuring App Routing Options". To set up mediation rules using the REST API, see "Configuring Mediation Rules". For details on configuring mediation at the log level through the REST API, see "Configuring Mediation Rules" in the Oracle Communications Cloud Native Core, Service Communication Proxy REST Specification Guide.

Observe

• Added the following metrics in the Metrics section:
  • ocscp_worker_med_udv_read_failure_total
  • ocscp_worker_med_udv_usage_count_limit_exceeded_total
• Added the following metrics in the Mediation Metrics section:
  • ocscp_med_udv_storage_failure_total
  • ocscp_med_udv_read_failure_total
  • ocscp_med_udv_used_total
  • ocscp_med_udv_size_mismatch_total
  • ocscp_med_udv_type_mismatch_total
  • ocscp_med_udv_not_configured_total
  • ocscp_med_udvs_max_size_limit_exceeded_total
• Added the following alert in the Mediation Alerts section:
  • NFMediationUserDefinedVariablesMaxSizeLimitExceeded

Maintain

If you encounter alerts at system level, see the Alerts section for resolution steps.

In case the alerts persist, perform the following tasks:

1. Collect the logs: For information about how to collect logs, see Oracle Communications Cloud Native Core, Service Communication Proxy Troubleshooting Guide.
2. Raise a service request: For information about how to raise a service request, see My Oracle Support.

3.28 5G SBI Message Routing

Service Communication Proxy (SCP) provides 5G Service Based Interface (SBI) message routing control and brings resiliency to the network. It relieves user NFs from remembering and interpreting complex routing rules associated with the next hop selection. Concurrently, it makes rerouting decisions based on the load conditions and health status of NF providers within the configured time period.

SCP acts as a proxy and forwards and routes any 5G ingress service request to the host (5G NF) present in the request's URI.

For Release 16, SCP supports:

• 5G SBI Model C indirect communication
• 5G SBI Model D indirect communication
• Learns 5G NF topology from NRF
• Static configuration of 5G NF topology
• Load Control based on the Load Control Information Header and so on.
• IPv4 IP family
• Every NF deployed in the network is expected to register with NRF as SCP learns the deployed network's NF topology from NRF.

Alternate Routing

SCP performs alternate routing by forwarding the message request to the next available producer NF if the target producer NF:

• Is unavailable
• Doesn't respond due to a timeout
• Responds with an error

An alternate routing attempt is considered when a connection is established and a message request is sent out. If the SCP fails to establish a connection, it is not counted as an attempt.

After receiving a message request, if SCP does not find any routing rules, SCP uses a default routing rule to route the request directly to the target producer NF. In such scenarios, alternate routing and load balancing functionalities are not applicable.

SCP provides circuit breaking functionality by rejecting message requests for failed or degraded NFs when alternate routing is unavailable. This process prevents consumer NFs from using their resources because they wait for responses from producer NFs. SCP attempts to get a response from producer NFs on behalf of consumer NFs by allowing the service user to focus on the application..

SCP also reroutes message requests with one of the configured HTTP status codes. For more information about the status codes, see "HTTP Status Code and Applicability for Rerouting" in Oracle Communications Cloud Native Core,Service Communication Proxy REST Specification Guide.

When one of the following nexthop SCP/SEPP routing failure conditions occurs, SCP performs alternative routing:

• Error received from nextHop SCP/SEPP
• Request timeout at the SCP
• Transport error

Types of Routing Options Supported by SCP

The types of routing options are:

• Pod Level Routing: Controls routing across the pods of selected NF
• Service Level Routing: Controls routing of selected NF services

InterSCP Routing

SCP supports Inter-SCP routing for scenarios where routing across regions is required.

The network can be divided into different geographical regions, with each region deploying redundant NF instances. Each of these regions can be deployed with their own georedundant NRFs. There are scenarios when traffic routing is required across the regions.

In such cases, SCP has to learn the network topology by interacting with NRFs in different regions. SCP also discovers other SCPs in the network. To enable routing to producer NF instances in other regions, the consumer SCP in a region is aware of the producer SCP in other regions.

SCP defines its serving Locality in the servingScope parameter in its profile registered with NRF and learns the NF topology from NRF. SCP learns other SCPs from NRF in the same way as it learns from any other producer.

When consumer NF’s SCP receives a request, it finds the locality of the selected producer NF instance.

If the producer NF locality is not served by the consumer SCP, the consumer NF’s SCP finds the SCP serving the producer NF’s locality and routes the request to that SCP. The producer’s SCP forwards the request to the producer NF within its served locality.

If the consumer SCP serves the producer locality, it is routed by the consumer SCP. If not, the request is forwarded to the producer SCP serving the NF locality for routing in its served region.

If the selected producer's locality is not served by the consumer SCP but by multiple SCPs with the same priority, the consumer SCP load balances requests to the producer SCPs with the same priority for the selected producer, using weights based on the capacity of those producer SCPs.

"User-Agent" Header Formats

SCP adds the "User-Agent" header to SCP originated message requests to NRF.

SCP uses the userAgentHeaderFormat REST API parameter to define the format of the "User-Agent" header that is added in the SCP originated message requests towards NRF. SCP supports the following formats of the "User-Agent" header:

• NFTYPE-NFINSTANCEID FQDN
• NFTYPE-NFINSTANCEID-FQDN
• NFTYPE-FQDN NFINSTANCEID
• NFTYPE-FQDN-NFINSTANCEID
• NFTYPE-NFINSTANCEID
• NFTYPE-FQDN
• NFTYPE
• NFTYPE-UNIQUEID

This enhancement enables SCP to support above mentioned "User-Agent" formats and includes consumer NFs identity as dimensions in SCP metrics, alerts, and logs. The following dimension are introduced as part of this enhancement to filter SCP metrics based on the consumer NF information: ocscp_consumer_host, ocscp_consumer_nf_instance_id, and ocscp_consumer_nf_type.

SCP uses the scp_user_agent_info REST API parameter to enable or disable the addition of the "User-Agent" header in the SCP originated messages towards NRF. For more information about the scp_user_agent_info parameter, see Oracle Communications Cloud Native Core, Service Communication Proxy REST Specification Guide.

Loop Detection

The loop detection feature is used to identify the loops in the 5G control plane network. SCP detects loops using the via header in the incoming request. SCP looks for its own FQDN presence in via header. If such a case occurs, this implies that the same SCP is invoked twice in the same request sequence, which means there is a loop. Hence, SCP rejects such a request. The loop detection feature is enabled by default.

Managing 5G SBI Message Routing

Enable

SCP determines 5G NF topology information from NRF. You can enable the 5G SBI Message Routing functionality by providing all the NRF profiles' information in the YAML file as described in the global parameters section in Oracle Communications Cloud Native Core, Service Communication Proxy Installation, Upgrade, and Fault Recovery Guide.

Note:

• This feature is enabled automatically if you are deploying SCP with Release 16 of Model C. For more information about Model C, see Support for Model C Indirect 5G SBI Communication.
• You can configure the required Helm parameters for this feature if you have performed a fresh installation of SCP or upgraded SCP within the same release version, for example, 1.15.1 to 1.15.1.

Configure

You can configure the 5G SBI Message Routing functionality using the CNC Console or REST API.

• Configure using CNC Console: For information about how to configure routing options, see Configuring Routing Options.
• Configure using REST API: For information about configuring routing options, see "Configuring Routing Options" in Oracle Communications Cloud Native Core, Service Communication Proxy REST Specification Guide..

Observe

For information about alerts and metrics, see Alerts and Metrics.

Maintain

If you encounter alerts at system level, see the Alerts section for resolution steps.

In case the alerts persist, perform the following tasks:

1. Collect the logs: For information about how to collect logs, see Oracle Communications Cloud Native Core, Service Communication Proxy Troubleshooting Guide.
2. Raise a service request: For information about how to raise a service request, see My Oracle Support.

3.28.1 5G SBI Notification Requests Processing

The following table describes ApiPrefix usage in notification messages at SCP:

Table 3-35 5G SBI Notification Requests Processing

Notification Message Received at SCP			Forwarded Notification Message to NextHop SCP (SCP-P)			Forwarded Notification Message to Target NF			Description
3gpp-sbi-target-apiRoot Header	:authority Header	:path Header	3gpp-sbi-target-apiRoot Header	:authority Header	:path HeaderIf the next hop SCP has published ApiPrefix in the SCP profile.	Routing Attempt	:authority Header	:path Header	-
scheme://NF-C1.com:port/NF-C1ApiPrefix	scp.com:port	scpApiPrefix/notificationUri	scheme://NF-C1.com:port/NF-C1ApiPrefix	nextHopScp.com:port	{nextHopscpApiPrefix}/notificationUri	Primary routing	scheme://NF-C1.com:port	NF-C1ApiPrefix/notificationUri	While registering with NRF, the notification handling service published apiPrefix in NFProfile.
						Alternate routing	scheme://NF-C2.com:port	{NF-C2ApiPrefix}/notificationUri	NF-C2ApiPrefix is used as per deployment and the apiPrefix value in the NFProfile for the service.
scheme://NF-C1.com:port/	scp.com:port	scpApiPrefix/notificationUri	scheme://NF-C1.com:port/	nextHopScp.com:port	{nextHopscpApiPrefix}/notificationUri	Primary routing	scheme://NF-C1.com:port	/notificationUri	NF-C2ApiPrefix is used as per deployment and the apiPrefix value in the NFProfile for the service.
						Alternate routing	scheme://NF-C2.com:port	{NF-C2ApiPrefix}/notificationUri	NF-C2ApiPrefix is used as per deployment and the apiPrefix value in the NFProfile for the service.
scheme://NF-C1.com:port/NF-C1ApiPrefix	scp.com:port	/notificationUri	scheme://NF-C1.com:port/	nextHopScp.com:port	{nextHopscpApiPrefix}/notificationUri	Primary routing	scheme://NF-C1.com:port	NF-C1ApiPrefix/notificationUri	SCP is deployed without apiPrefix in SCP profile.
						Alternate routing	scheme://NF-C2.com:port	{NF-C2ApiPrefix}/notificationUri	NF-C2ApiPrefix is used as per deployment and the apiPrefix value in the NFProfile for the service.
scheme://NF-C1.com:port/	scp.com:port	/notificationUri	scheme://NF-C1.com:port/	nextHopScp.com:port	{nextHopscpApiPrefix}/notificationUri	Primary routing	scheme://NF-C1.com:port	/notificationUri	SCP and the notification handling service are deployed without an apiPrefix in the NFProfile.
						Alternate routing	scheme://NF-C2.com:port	{NF-C2ApiPrefix}/notificationUri	NF-C2ApiPrefix is used as per deployment and the apiPrefix value in the NFProfile for the service.
Delegated Discovery notification request	scp.com:port	{scpApiPrefix}/ scp-default-sub-notify-uri	scheme://NF-C1.com:port/ Selected target notification URI	nextHopScp.com:port	{nextHopscpApiPrefix}/notificationUri	Primary routing	scheme://NF-C1.com:port	{NF-C1ApiPrefix}/notificationUri	Notification URI is used according to the published NFProfile based on discovery responses.
						Alternate routing	scheme://NF-C2.com:port	{NF-C2ApiPrefix}/notificationUri	Notification URI is used according to the published NFProfile based on discovery responses.
Delegated Discovery notification request	scp.com:port	/scp-default-sub-notify-uri	scheme://NF-C1.com:port/ Selected target notification URI	nextHopScp.com:port	{nextHopscpApiPrefix}/notificationUri	Primary routing	scheme://NF-C1.com:port	{NF-C1ApiPrefix}/notificationUri	Notification URI is used according to the published NFProfile based on discovery responses.
						Alternate routing	scheme://NF-C2.com:port	{NF-C2ApiPrefix}/notificationUri	Notification URI is used according to the published NFProfile based on discovery responses.

Obtaining NF Information from Notification Requests

SCP obtains the target producer NF information from nfset and nfinst attributes of the notification request even if the 3gpp-Sbi-Routing-Binding header does not contain the servname attribute. In this case, SCP pegs the exact values of the producer NF type in ocscp_nf_type and ocscp_nf_service_type dimensions of the respective metrics. The format of dimension values are as follows:

• ocscp_nf_type=<extracted_nftype>
• ocscp_nf_service_type=<extracted_nftype>-unknown

Where,

• <extracted_nftype> is the target producer NF type.
• unknown indicates that the servname attribute is absent in the 3gpp-Sbi-Routing-Binding header.

In case the servname attribute is present in the 3gpp-Sbi-Routing-Binding header, SCP pegs the exact values of the producer NF type in ocscp_nf_type and ocscp_nf_service_type dimensions of the respective metrics. The format of dimension values are as follows:

• ocscp_nf_type=<extracted_nftype_fromservname>
• ocscp_nf_service_type=<extracted_nftype_fromservname>-<service name>

Where,

• <extracted_nftype_fromservname> is the target producer NF type extracted from the servname attribute.
• <service name> is the service name present in the 3gpp-Sbi-Routing-Binding header.

3.28.2 5G SBI Service Requests Processing

The ApiPrefix usage in service request messages at SCP are as follows:

Table 3-36 5G SBI Service Requests Processing

5G SBI Request Message Received at SCP			SBI Service Request to NextHop SCP			Forwarded SBI Service Request Message to Target NF			Description
3gpp-sbi-target-apiRoot Header	:authority Header	:path Header	3gpp-sbi-target-apiRoot Header	:authority Header	:path Header	Routing Attempt	:authority Header	:path Header	-
scheme://NF-P1.com:port/NF-P1ApiPrefix	scp.com:port	scpApiPrefix/<apiName>/<apiVersion>apiSpecificResourceURI	scheme://NF-P1.com:port/NF-P1ApiPrefix	nextHopScp.com:port	{nextHopscpApiPrefix}/<apiName>/<apiVersion>/apiSpecificResourceURI If the next hop SCP has published ApiPrefix in the SCP profile.	Primary routing	scheme://NF-P1.com:port	NF-P1ApiPrefix/<apiName>/<apiVersion>/apiSpecificResourceURI	While registering with NRF, the NF service published apiPrefix in NFProfile.
						Alternate routing	scheme://NF-P2.com:port	{NF-P2ApiPrefix}/<apiName>/<apiVersion>/apiSpecificResourceURI	NF-P2ApiPrefix is used according to deployment and the apiPrefix value in the NFProfile for the service.
scheme://NF-P1.com:port/	scp.com:port	scpApiPrefix/<apiName>/<apiVersion>/apiSpecificResourceURI	scheme://NF-P1.com:port/	nextHopScp.com:port	{nextHopscpApiPrefix}/<apiName>/<apiVersion>/apiSpecificResourceURI If the next hop SCP has published ApiPrefix in the SCP profile.	Primary routing	scheme://NF-P1.com:port	/<apiName>/<apiVersion>/apiSpecificResourceURI	NF service is not supporting apiPrefix and not published in NF Profile.
						Alternate routing	scheme://NF-P2.com:port	{NF-P2ApiPrefix}/<apiName>/<apiVersion>/apiSpecificResourceURI	NF-P2ApiPrefix is used according to deployment and the apiPrefix value in the NFProfile for the service.
scheme://NF-P1.com:port/NF-P1ApiPrefix	scp.com:port	/<apiName>/<apiVersion>/apiSpecificResourceURI	scheme://NF-P1.com:port/	nextHopScp.com:port	{nextHopscpApiPrefix}/<apiName>/<apiVersion>/apiSpecificResourceURI If the next hop SCP has published ApiPrefix in the SCP profile.	Primary routing	scheme://NF-P1.com:port	NF-P1ApiPrefix/<apiName>/<apiVersion>/apiSpecificResourceURI	SCP is deployed without apiPrefix in SCP profile.
						Alternate routing	scheme://NF-P2.com:port	{NF-P2ApiPrefix}/<apiName>/<apiVersion>/apiSpecificResourceURI	NF-P2ApiPrefix is used according to deployment and the apiPrefix value in the NFProfile for the service.
scheme://NF-P1.com:port/	scp.com:port	/<apiName>/<apiVersion>/apiSpecificResourceURI	scheme://NF-P1.com:port/	nextHopScp.com:port	{nextHopscpApiPrefix}/<apiName>/<apiVersion>/apiSpecificResourceURI If the next hop SCP has published ApiPrefix in the SCP profile.	Primary routing	scheme://NF-C1.com:port	/<apiName>/<apiVersion>/apiSpecificResourceURI	SCP and NF service are deployed without an api prefix in the NFProfile.
						Alternate routing	scheme://NF-C2.com:port	{NF-P2ApiPrefix}/<apiName>/<apiVersion>/apiSpecificResourceURI	NF-P2ApiPrefix is used according to deployment and the apiPrefix value in the NFProfile for the service.
Delegated Discovery 5G SBI request (Not Present)	scp.com:port	{scpApiPrefix}//<apiName>/<apiVersion>/apiSpecificResourceURI	scheme://NF-P1.com:port/ Selected target notification URI	nextHopScp.com:port	{nextHopscpApiPrefix}/<apiName>/<apiVersion>/apiSpecificResourceURI If the next hop SCP has published ApiPrefix in the SCP profile.	Primary routing	scheme://NF-P1.com:port	{NF-P1ApiPrefix}/<apiName>/<apiVersion>/apiSpecificResourceURI	apiRoot is created according to the published NFProfile based on discovery responses.
						Alternate routing	scheme://NF-P2.com:port	{NF-P2ApiPrefix}/<apiName>/<apiVersion>/apiSpecificResourceURI	apiRoot is created according to the published NFProfile based on discovery responses.
Delegated Discovery 5G SBI request (Not Present)	scp.com:port	/scp-default-sub-notify-uri	scheme://NF-P1.com:port/ Selected target notification URI	nextHopScp.com:port	{nextHopscpApiPrefix}/<apiName>/<apiVersion>/apiSpecificResourceURI If the next hop SCP has published ApiPrefix in the SCP profile.	Primary routing	scheme://NF-P1.com:port	{NF-P1ApiPrefix}/<apiName>/<apiVersion>/apiSpecificResourceURI	apiRoot is created according to the published NFProfile based on discovery responses.
						Alternate routing	scheme://NF-P2.com:port	{NF-P2ApiPrefix}/<apiName>/<apiVersion>/apiSpecificResourceURI	apiRoot is created according to the published NFProfile based on discovery responses.

3.29 Message Priority Assignment and Override

The "3gpp-Sbi-Message-Priority" header is defined to carry the message priority of 5G messages. Service Communication Proxy (SCP) includes or modifies the header based on the configuration parameters.

The operator can assign or override the message priority of 5G messages as per their network requirements. SCP uses the message priority in prioritising the message in congestion or overload features.

Managing Message Priority Assignment and Override

Enable

Not applicable.

Configure

You can configure the Message Priority Assignment and Override functionality using the CNC Console or REST API.

• Configure using CNC Console: For information about how to configure message priority options, see Configuring SBI Message Priority.
• Configure using REST API: For information about how to configure message priority options, see "Configuring SBI Message Priority for Pod Overload Control" in Oracle Communications Cloud Native Core, Service Communication Proxy REST Specification Guide.

Observe

For information about alerts and metrics, see Alerts and Metrics.

Maintain

If you encounter alerts at system level, see the Alerts section for resolution steps.

In case the alerts persist, perform the following tasks:

1. Collect the logs: For information about how to collect logs, see Oracle Communications Cloud Native Core, Service Communication Proxy Troubleshooting Guide.
2. Raise a service request: For information about how to raise a service request, see My Oracle Support.

3.30 Outlier Detection

The Outlier Detection feature monitors the status of each endpoint of the producer NF or NF services. Upstream producer endpoints that continuously return the service responses with non-2xx status codes are removed from the routing pool for a predefined period based on the configured non-2xx status codes, counts, and ejection time.

In SCP 22.4.0, this feature is enhanced to support outlier detection for upstream NFs, which includes local producer NFs, next-hop SCP, and next-hop SEPP.

When SCP receives a message request from a consumer NF, it routes the message request to the target upstream NFs if the upstream NF is healthy. When SCP receives non-2xx status codes consecutively from the target upstream NF, SCP marks the upstream NF unhealthy after the number of error responses exceeds the preconfigured value. For example, if the consecutiveErrors parameter range is set to 5, after receiving five consecutive errors from upstream NF1, SCP marks the upstream NF1 as degraded or unhealthy. When SCP receives the sixth message request from the consumer NF, it routes the message request to upstream NF2 or any other available upstream NF without considering upstream NF1, which is marked unhealthy. SCP starts forwarding message requests to upstream NF1 after the configured time period as defined in the baseEjectionTime parameter. For more information about consecutiveErrors and baseEjectionTime parameters, see "Configuring Outlier Detection" in Oracle Communications Cloud Native Core, Service Communication Proxy REST Specification Guide.

For the next hop, SCP or SEPP, these error codes are SCP or SEPP-generated errors. These error responses contain a server header that includes the FQDN of SCP or SEPP.

Note:

SCP resets outlier detection data for producer NF profile updates.

Managing Outlier Detection

Enable

To enable the Outlier Detection feature, complete the following configurations as described in Oracle Communications Cloud Native Core, Service Communication Proxy REST Specification Guide:

• For specific NF service, set odEnabled to true, and then configure odRuleName as described in the "Configuring Routing Options" section.
• For Inter SCP scenarios, set odEnabled to true and configure odScpRuleName as described in the "Configuring System Options" section.
• For Inter PLMN routing scenarios, set odSeppEnabled to true and configure odSeppRuleName as described in the "Configuring System Options" section.

Configure

You can configure Outlier Detection feature using the CNC Console and REST API.

• Configure using CNC Console: For information about CNC Console configurations, see Configuring Global Options and Configuring Outlier Detection.
• Configure using REST API: For information about REST API configurations, see "Outlier Detection Configuration", "Configuring System Options", and "Configuring Routing Options" in Oracle Communications Cloud Native Core, Service Communication Proxy REST Specification Guide.

Observe

For information about alerts and metrics, see Alerts and Metrics.

Maintain

If you encounter alerts at system level, see the Alerts section for resolution steps.

In case the alerts persist, perform the following tasks:

1. Collect the logs: For information about how to collect logs, see Oracle Communications Cloud Native Core, Service Communication Proxy Troubleshooting Guide.
2. Raise a service request: For information about how to raise a service request, see My Oracle Support.

3.31 Circuit Breaking

The Circuit Breaking feature is triggered on a per NF service instance (including all of the service's IPEndpoints or FQDNs) when its outstanding transactions exceed a preconfigured value. If outstanding transaction exceeds the preconfigured value and alternate routing is configured, the message requests are routed to alternate NFs. When Circuit Breaking is activated, message requests are routed alternatively or rejected.

Managing Circuit Breaking

Enable

This feature is enabled using REST API parameters as per the following scenarios:

• For routing SBI messages directly to producer NFs, set cbEnabled to true in Routing Options REST APIs as described in "Configuring Routing Options" in Oracle Communications Cloud Native Core, Service Communication Proxy REST Specification Guide.
• For routing notification messages directly to producer NFs, set cbEnabled to true in Routing Config Set REST APIs as described in "Routing Config Set" in Oracle Communications Cloud Native Core, Service Communication Proxy REST Specification Guide.
• For InterPLMN and InterSCP routing, set cbScpEnabled and cbSeppEnabled to true in System Options REST APIs as described in "Configuring System Options" in Oracle Communications Cloud Native Core, Service Communication Proxy REST Specification Guide.

Configure

You can configure this feature using the CNC Console and REST APIs.

• Configure using CNC Console: For information about CNC Console configurations, see Configuring Global Options and Circuit Breaking Configurations.
• Configure using REST API: For information about REST API configurations, see "Circuit Breaking Configurations", "Configuring System Options", "Routing Config Set", and "Configuring Routing Options" in Oracle Communications Cloud Native Core, Service Communication Proxy REST Specification Guide.

Observe

For information about alerts and metrics, see Alerts and Metrics.

Maintain

If you encounter alerts at system level, see the Alerts section for resolution steps.

In case the alerts persist, perform the following tasks:

1. Collect the logs: For information about how to collect logs, see Oracle Communications Cloud Native Core, Service Communication Proxy Troubleshooting Guide.
2. Raise a service request: For information about how to raise a service request, see My Oracle Support.

3.32 Canary Release

The Canary Release feature inspects the API version attribute of the NF service profile published by the NFs during NF registration or update. In case there is a new version of the API, Service Communication Proxy (SCP) identifies the version as a canary version if the version matches the configured value.

The older version is considered as the Production version and the new version of the service instance is considered as the Canary version. SCP distributes traffic between Production version and Canary version based on the operator configuration.

When the canary version's deployment is complete, the production version is upgraded to the canary version.

Managing Canary Release

Enable

You can enable the Canary Release functionality using the CNC Console or REST API.

• Enable using CNC Console: To enable the Canary Release feature, set the Canary Release Flag switch to Enabled as described in Configuring Canary Release.
• Enable using REST API: To enable the Canary Release feature using REST API, set the canaryReleaseFlag parameter to true as described in "Configuring Canary Release Options" in Oracle Communications Cloud Native Core, Service Communication Proxy REST Specification Guide.

Note:

Canary Release must be enabled for each service.

Configure

You can configure the Canary Release functionality using the CNC Console or REST API.

• Configure using CNC Console: For information about how to configure Canary Release, see Configuring Canary Release.
• Configure using REST API: For information about how to configure Canary Release, see "Configuring Canary Release Options" in Oracle Communications Cloud Native Core, Service Communication Proxy REST Specification Guide.

Observe

For information about alerts and metrics, see Alerts and Metrics.

Maintain

If you encounter alerts at system level, see the Alerts section for resolution steps.

In case the alerts persist, perform the following tasks:

1. Collect the logs: For information about how to collect logs, see Oracle Communications Cloud Native Core, Service Communication Proxy Troubleshooting Guide.
2. Raise a service request: For information about how to raise a service request, see My Oracle Support.

3.33 Static Configuration of NF Profiles

The Static Configuration Fallback feature provides a static configuration of NF profiles when georedundant NRFs in the network fail. Under failure conditions, when NRF is not configured, or when static configurable routing is preferred, Service Communication Proxy (SCP) uses the user configured or updated NF profiles. SCP retains the 5G topology information from NRF for further operations. It allows fallback to a static mode of operation for modifying the previously discovered NF producer profiles through NRF and adds any new NF producer profile while the NRFs are unavailable.

The following configurations are used for the Static Configuration Fallback feature:

• TopologySourceInfo: This is the configuration used by SCP to determine the 5G topology source. SCP learns and creates the routing rules accordingly.
• 5G NF topology information: This information is available with SCP after learning the 5G topology from the defined source as per the previous section configuration either from NRF or a static method.
• You can create or modify the 5G NF profile information using REST APIs.

Managing Static Configuration

Enable

You can enable the Static Configuration feature by setting the scpcconfiguration.defaultTopologySource parameter to LOCAL in the scpc configuration section of the values.yaml file. For more information about this parameter, see Oracle Communications Cloud Native Core, Cloud Native Environment Installation, Upgrade, and Fault Recovery Guide.

Note:

You can configure the required Helm parameters for this feature if you have performed a fresh installation of SCP or upgraded SCP within the same release version, for example, 1.15.1 to 1.15.1.

Configure

You can configure the Static Configuration feature using the CNC Console or REST API.

• Configure using CNC Console: For information about how to configure the Static Configuration feature, see Configuring Topology Source Info.
• Configure using REST API: For information about how to configure the Static Configuration feature, see "Configuring NF Topology Groups" in Oracle Communications Cloud Native Core, Service Communication Proxy REST Specification Guide.

Observe

For information about alerts and metrics, see Alerts and Metrics.

Maintain

If you encounter alerts at system level, see the Alerts section for resolution steps.

In case the alerts persist, perform the following tasks:

1. Collect the logs: For information about how to collect logs, see Oracle Communications Cloud Native Core, Service Communication Proxy Troubleshooting Guide.
2. Raise a service request: For information about how to raise a service request, see My Oracle Support.

3.34 Preventive Audit on Last NF Instance

SCP determines the network topology from NRF by subscribing to each NF type. When a new NF instance is registered in the network, SCP receives a registration notification from the NRF and creates a routing rule based on the NF profile in the notification.

SCP removes the routing rule for an NF instance after receiving a deregistration notification from NRF.

When the primary NRF communication breaks, the producer NF registers with the configured secondary NRF. In case the primary NRF is not notified about this reregistration, then it sends a deregistration notification to SCP. This results in the removal of the routing rule at SCP. Also, it causes network failure if repeated for multiple NF instances.

With the introduction of the Preventive Audit on Last NF Instance feature, SCP can control NRF failure scenarios in the network by performing the preventive audit (discovery). This audit is performed with all the configured regional NRFs before removing the last NF instance of a particular NF type. If any NRF returns the success discovery response with NF profiles, SCP creates the routing rules based on the discovery response. SCP raises an alert to notify operators about such NRF failure scenarios.

Managing Preventive Audit on Last NF Instance

Enable

You can enable the Preventive Audit on Last NF Instance feature by setting the preventiveAuditOnLastNFInstanceDeletion parameter to true in the global parameters section of the values.yaml file. For more information about this parameter, see Oracle Communications Cloud Native Core, Service Communication Proxy Installation, Upgrade, and Fault Recovery Guide.

Note:

You can configure the required Helm parameters for this feature if you have performed a fresh installation of SCP or upgraded SCP within the same release version, for example, 1.15.1 to 1.15.1.

Configure

There is no specific configuration required for the Preventive Audit on Last NF Instance feature.

Observe

There is no specific metrics and alerts required for the Preventive Audit on Last NF Instance feature.

Maintain

If you encounter alerts at system level, see the Alerts section for resolution steps.

In case the alerts persist, perform the following tasks:

1. Collect the logs: For information about how to collect logs, see Oracle Communications Cloud Native Core, Service Communication Proxy Troubleshooting Guide.
2. Raise a service request: For information about how to raise a service request, see My Oracle Support.

3.35 Rate Limiting

Service Communication Proxy (SCP) provides the Rate Limiting feature to:

• protect the network from consumer NFs that might overload the network with service requests.
• protect the producer NF instance from getting overloaded.

3.35.1 Local Rate Limit Feature

SCP uses the token bucket algorithm in the Rate Limit feature functionality to track the allowed and consumed tokens in a given time period as per rate limit configuration.

In the following ways SCP uses the distributed cache to aggregate the token consumption across scp-worker pods of an SCP instance:

1. Over a 1 second time period, the rate limit framework divides the configured rate into smaller slots of 100milliseconds each.
2. SCP monitors the difference between the actual request message rate received and the total request messages, i.e., allowed to send in the 100 milliseconds window as calculated.
3. Each SCP worker pod also calculates its own share of the total request message sent and accordingly decides on a batch of tokens to be preconsumed.
4. If at any time the scp-worker POD is not able to get a token, the request message is treated with rate limit treatment as per rate limit configuration.

Note:

• The prediction of token batch count depends on the traffic rate detected in scp-worker PODs; hence, irregular traffic may lead to more token consumption by scp-workers. This may result in a difference between the overall message rate allowed and the configured rate.
• The rate limit framework expects a uniform traffic pattern over a second period for a configured rate.

Figure 3-9 Local Rate Limit Feature Functional View

3.35.2 Global Rate Limit Feature

The global rate limit feature aggregates traffic rate data across multiple SCP instances and applies traffic rate control based on the configured aggregated rate.

The aggregated rate is configured at each SCP instance in the following way:

1. Each SCP instance monitors its own traffic routed count against the configured NF, NFInstanceID, FQDN, and so on, and reports the same to all other SCP instances.
2. Each SCP instance aggregates the total traffic routed against the configured NF, NFInstanceID, and FQDN from all SCP instances.
3. Each SCP also calculates its own share of routed traffic in the aggregated total routed traffic count, as well as the status of the difference between total routed traffic and the configured aggregated rate.
4. Global Rate Limit Control actions such as allowing or disallowing traffic are decided based on the data collected in the steps above.

Note:

Convergence of global rate data aggregation depends on network latency among the SCP instances, and higher latency can impact rate-limiting performance.

Global Rate Working Principle

The working principle are as follows:

1. Each SCP instance has an aggregation cache, which syncs its own traffic route count with other SCP instances.
2. In this aggregation cache, a routed traffic rate count is maintained for each SCP instance.
3. Each SCP instance calculates the total traffic routed towards the configured NF, NFInstanceID, FQDN, and so on.
4. For example, the diagram depicts the aggregated routed traffic count for a FQDN, "udm.test.com," across all 3 SCP instances.
   • Sample configuration 1: A global rate limit is configured in 3 SCP instances for FQDN "udm.test.com" with a rate of 15000 per sec.
   • Sample configuration 2: A global rate limit is configured in 3 SCP instances for FQDN "udm.test.com" with a rate of 13000 per sec.
5. The global rate limit control action, such as allowing or disallowing the traffic, is decided based on the aggregated routed traffic count collected.
   • Action for configuration 1: Traffic is allowed since the total traffic routed rate is less than 15000 per sec.
   • Action for configuration 2: Traffic is throttled since the total traffic routed rate is greater than 13000 per sec.

Figure 3-10 Global Rate Limit Working Principle

SCP supports rate limiting at the ingress and egress side.

If the SCP-cache service is unavailable, then SCP-worker continues to process service requests, however, rate limiting is not applied. If any SCP-worker is unavailable, it cannot move to the Ready state until SCP-cache initializes the rate limiting.

Note:

• The Rate Limit framework depends on the ingress traffic pattern at SCP, and its variation reflects in traffic rate detection and applies throttling of messages in a distributed environment since it involves convergence of message rate for a specific rate limit configuration, for example, a configured allowed rate value for a specific FQDN of an NF service instance across multiple scp-worker service pods.
• The average allowed traffic rate with rate control may be achieved as per the configured allowed traffic rate over a few seconds. The instantaneous allowed traffic rate with rate control may have some variation with respect to the configured allowed traffic rate on a short time scale.

The following sections explain how the SCP Rate Limiting feature controls ingress and egress traffic.

3.35.3 Ingress Rate Limiting

The Ingress Rate Limiting feature protects the network from unsecured consumer NFs that might overload the network with message requests. SCP secures the network when aggregated ingress traffic from any registered NF instance exceeds the allowed traffic rate limit. If the traffic exceeds the allowed traffic rate limit, SCP does not process the traffic and responds with an error code. Operators can configure the error code. Otherwise, the default error code 429 is set.

With the enhanced Ingress Rate Limiting functionality, SCP can use the User-Agent or XFCC header in the ingress message request to identify the consumer NF and apply ingress rate limiting at the ingress side.

The traffic rate limit is set at the NF type level that is applicable for all NF instances. SCP obtains the FQDN of consumer NF from the x-forwarded-client-cert (XFCC) header in the incoming message request. SCP provides the configuration for ingress "allowed requests/sec" per NF type. This configuration is applicable for all NF instances of the NF type.

As most of the network do not provide XFCC header in the ingress message requests, SCP cannot rely on the XFCC header to fetch consumer NFs' identity. Therefore, as recommended by 3GPP, the User-Agent header can be added to service request by the consumer NF to communicate its identity. The User-Agent header is added to each ingress message request irrespective of the network type. This header contains consumer NF identity in the different formats.

SCP supports the following types of User-Agent header formats to retrieve the consumer NF identity:

• Format1: NFTYPE-NFINSTANCEID FQDN or NFTYPE-NFINSTANCEID-FQDN
• Format2: NFTYPE-FQDN NFINSTANCEID or NFTYPE-FQDN-NFINSTANCEID
• Format3: NFTYPE-NFINSTANCEID
• Format4: NFTYPE-FQDN

Where,

• NFTYPE indicates the type of consumer NF.
• NFINSTANCEID indicates the instance ID of the consumer NF.
• FQDN indicates the FQDN of the consumer NF.

Using the aforementioned parameters of User-Agent header, SCP obtains the consumer NF information and applies ingress rate limiting at the ingress side. SCP uses the ConsumerInfo REST API parameter to determine the header type such as XFCC or User-Agent, in the ingress message request. For more information about the ConsumerInfo REST API parameter, see Oracle Communications Cloud Native Core, Service Communication Proxy REST Specification Guide.

SCP determines consumer NF identity such as NFTYPE, NFINSTANCEID, or FQDN, from the User-Agent header and applies the ingress rate limiting configurations in the following sequence:

1. NFINSTANCEID
2. FQDN
3. NFTYPE

If SCP determines any one of the configurations as per the order, SCP stops searching for the remaining configurations and uses the retrieved configurations for ingress rate limiting.

Example of Ingress Rate Limiting Configuration

You can configure ingress request rate for all NF instances of an NFType so that this configuration is applicable for all NF instances. You can configure MPS for a single NF instance identified by FQDN.

There are 10 Session Management Functions (SMFs) determined by SCP. The maximum traffic limit for all SMFs except for SMF3, SMF4, and SMF7 is 1000 MPS.

1. The maximum ingress requests limit from SMF3 is 600 MPS.
2. The maximum ingress requests limit from SMF4 with instance ID 26740918-e9cd-0205-aada-71a76214d33c is 200 MPS.
3. The maximum ingress requests limit from SMF7 is 400 MPS.

Table 3-37 Example of Ingress Rate Limiting Configuration

Exception	NFType	FQDN	NF Instance ID	MPS
NA	SMF	-	-	1000 MPS
1	-	smf3.example.com	-	600 MPS
2	-	smf7.example.com	-	400 MPS
3	-	-	26740918-e9cd-0205-aada-71a76214d33c	200 MPS

Note:

The NF Instance ID parameter is used only in the User-Agent header.

Ingress Rate Limiting Process Using the User-Agent or XFCC Header Parameter

SCP uses the values of primaryHeaderName and secondaryHeaderName in the ConsumerInfo REST API parameter to identify the consumer NF in an ingress message request. When SCP receives an ingress message request, it searches for the primaryHeaderName value and follows the following methods to apply ingress rate limiting:

• If SCP finds primaryHeaderName, it considers the configured value such as XFCC header or User-Agent header, to identify the consumer NF and uses the configurations that match the consumer NF identity to apply ingress rate limiting. If SCP does not find any configurations for consumer NF, it does not apply ingress rate limiting.
• If SCP does not find primaryHeaderName, it searches for secondaryHeaderName and considers the configured value such as XFCC header or User-Agent header, to obtain the identity of the consumer NF and uses the configurations that match the consumer NF identity to apply ingress rate limiting. If SCP does not find any configurations for consumer NF, it does not apply ingress rate limiting.
• If SCP does not find secondaryHeaderName, it does not apply ingress rate limiting.

Managing Ingress Rate Limiting

Enable

The Ingress Rate Limiting feature is a core functionality of SCP. This feature is automatically enabled in SCP at the time of deployment.

Configure

You can configure the Ingress Rate Limiting feature using the CNC Console or REST API.

• Configure using CNC Console: For information about configuring the Ingress Rate Limiting feature, see Configuring Ingress Rate Limiter Consumer Info and Configuring Ingress Rate Limiting.
• Configure using REST API: For information about configuring the Ingress Rate Limiting feature, see "Configuring Ingress Rate Limiting" and "Configuring Consumer NF Info" in Oracle Communications Cloud Native Core, Service Communication Proxy REST Specification Guide.

Observe

For information about alerts and metrics, see Alerts and Metrics.

Maintain

If you encounter alerts at system level, see the Alerts section for resolution steps.

In case the alerts persist, perform the following tasks:

1. Collect the logs: For information about how to collect logs, see Oracle Communications Cloud Native Core, Service Communication Proxy Troubleshooting Guide.
2. Raise a service request: For information about how to raise a service request, see My Oracle Support.

3.35.4 Egress Rate Limiting

The Egress Rate Limiting feature protects the registered producer NF instance from getting overloaded. With this feature, SCP secures the network when aggregated egress traffic towards an NF instance exceeds the allowed traffic rate limit.

If the traffic exceeds the allowed limit, then SCP performs alternate routing by default. In case alternate routing is not configured, SCP responds with an error code.

Operators can configure the error code. Otherwise, the default error code 503 is set.

To determine the destination of the request, SCP checks the API root and authority information in the request header. SCP also checks the service name and path to identify the service type in the request header. Considering this information, SCP provides the configuration for "egress allowed requests/sec" per NF type. This configuration is applicable for all NF instances of the NF type.

Example of Egress Rate Limiting Configuration

You can configure Messages Per Second (MPS) for all NF instances of an NFType so that this configuration is applicable for all NF instances. You can configure MPS for single NF instance identified by FQDN.

There are 4 UDMs determined by SCP. The maximum traffic limit for all UDMs with the following exceptions is 400 MPS:

1. The maximum traffic limit for UDM3 is 500 MPS.
2. The maximum traffic limit for SDM service for all UDMs is 200 MPS.
3. The maximum traffic limit for UMD1 UECM service is 100 MPS.
4. The maximum traffic limit for UDM4 UEAU service is 600 MPS.

Table 3-38 Example of Egress Rate Limiting Configuration

Exception	NFType	FQDN	Service Name	MPS
NA	UDM	-	-	400
1	-	Udm3.example.com	-	500
2	-	-	Nudm_sdm	200
3	-	Udm1.example.com	Nudm_uecm	100
4	-	Udm4.example.com	Nudm_ueau	600

Managing Egress Rate Limiting

Enable

The Egress Rate Limiting feature is a core functionality of SCP. This feature is automatically enabled in SCP at the time of deployment. To allow rate limit to occur, you must enable either per NF rate limit or make entries in the Egress table using the CNC Console.

Configure

You can configure the Egress Rate Limiting feature using the CNC Console or REST API.

• Configure using CNC Console: For information about configuring the Egress Rate Limiting feature, see Configuring Egress Rate Limiting.
• Configure using REST API: For information about configuring the Egress Rate Limiting feature, see "Configuring Egress Rate Limiting" in Oracle Communications Cloud Native Core, Service Communication Proxy REST Specification Guide.

Observe

For information about alerts and metrics, see Alerts and Metrics.

Maintain

If you encounter alerts at system level, see the Alerts section for resolution steps.

In case the alerts persist, perform the following tasks:

1. Collect the logs: For information about how to collect logs, see Oracle Communications Cloud Native Core, Service Communication Proxy Troubleshooting Guide.
2. Raise a service request: For information about how to raise a service request, see My Oracle Support.

3.35.4.1 Global Egress Rate Limiting

The existing egress rate limiting functionality aggregates traffic rate for a target producer NF within one SCP instance across multiple pods of SCP-worker service. It does not aggregate the overall traffic rate towards the producer NF across multiple SCP instances. Therefore, the Global Rate Limiting feature is implemented so that a group of SCP instances coordinates among each other to ensure traffic rates for common destinations, that is, producer NFs, are aggregated and the egress rate limit is applied to the overall traffic rate.

The Global Egress Rate Limiting feature synchronizes and aggregates the egress rate data for multiple producer NFs among multiple SCP instances (up to three SCP instances). Based on the aggregated rate data, each SCP controls its traffic to ensure the global configured egress rate is achieved.

The SCP-cache microservice synchronizes egress rate data among multiple SCP instances. The participating SCP instances for the egress rate limiting aggregation details are configured using Helm as described in Oracle Communications Cloud Native Core, Service Communication Proxy Installation, Upgrade, and Fault Recovery Guide. SCP uses an Oracle product called Oracle Coherence which offers federated caching to link multiple clusters so that cache data is automatically synchronized between clusters.

Figure 3-11 Role of SCP-Cache

By default, the egress rate aggregation is disabled. After enabling the Global Egress Limiting feature using the global_egress_ratelimit parameter on the CNC Console, the egress rate aggregation uses remoteScpOneEnabled and remoteScpTwoEnabled parameters to enable rate data synchronization and aggregation with the corresponding remote instances of SCP. If the rate aggregation and synchronization are disabled or the communication fails with a remote SCP instance, the Global Egress Rate Limiting feature does not consider that remote SCP as part of the Global Federation cluster. Therefore, Global Rate Limit Algorithm does not consider any message rate related updates from that remote SCP while applying the rate limit.

Managing Global Egress Rate Limiting

Enable

You can enable this feature by setting global_egress_ratelimit to true. For more information, see Configuring SCP Features.

Configuring Participating SCP for Global Egress Rate Limit

Perform the following configuration while deploying SCP.

1. If the following Helm parameters of the participating SCP instances are available, add the required Helm parameters in case a single instance of SCP is used or add all the parameters in case both the instances of SCP are used to the custom-values.yaml file:
   • coherence.federation.remoteScpOne.fqdnOrIp
   • coherence.federation.remoteScpOne.port
   • coherence.federation.remoteScpOne.clusterName
   • coherence.federation.remoteScpOne.nfInstanceId
   • coherence.federation.remoteScpTwo.fqdnOrIp
   • coherence.federation.remoteScpTwo.port
   • coherence.federation.remoteScpTwo.clusterName
   • coherence.federation.remoteScpTwo.nfInstanceId
2. Deploy SCP as described in Oracle Communications Cloud Native Core, Service Communication Proxy Installation, Upgrade, and Fault Recovery Guide.
3. Enable global egress rate aggregation and control with the participating SCP instances using the CNC Console as described in Configuring SCP Features.

Perform the following configuration if SCP is deployed.

1. Perform the same release upgrade using the following Helm parameters for the participating SCP instances in the custom-values.yaml file. Add the required parameters if one instance of SCP is used, otherwise add all the parameters if both the instances of SCP are used.
   • coherence.federation.remoteScpOne.fqdnOrIp
   • coherence.federation.remoteScpOne.port
   • coherence.federation.remoteScpOne.clusterName
   • coherence.federation.remoteScpOne.nfInstanceId
   • coherence.federation.remoteScpTwo.fqdnOrIp
   • coherence.federation.remoteScpTwo.port
   • coherence.federation.remoteScpTwo.clusterName
   • coherence.federation.remoteScpTwo.nfInstanceId

   Only the scp-cache microservice restarts.

2. Enable global egress rate aggregation and control with the participating SCP instances using the CNC Console as described in Configuring SCP Features.

Configure

You can configure this feature using Helm and REST API.

• Configure using Helm: For information about Helm configurations, see "global Parameters" in Oracle Communications Cloud Native Core, Service Communication Proxy Installation, Upgrade, and Fault Recovery Guide.

  Note:

  You can configure the required Helm parameters for this feature if you have performed a fresh installation of SCP or upgraded SCP within the same release version, for example, 1.15.1 to 1.15.1.
• Configure using REST API: For information about REST API configurations, see "Configuring Egress Rate Limiting and Global Egress Rate Limiting" in Oracle Communications Cloud Native Core, Service Communication Proxy REST Specification Guide.

Observe

For information about alerts and metrics, see Alerts and Metrics.

Maintain

If you encounter alerts at system level, see the Alerts section for resolution steps.

In case the alerts persist, perform the following tasks:

1. Collect the logs: For information about how to collect logs, see Oracle Communications Cloud Native Core, Service Communication Proxy Troubleshooting Guide.
2. Raise a service request: For information about how to raise a service request, see My Oracle Support.

3.35.5 Egress and Ingress Key Combinations

This section provides information about different key combinations and key formats required to configure ingress and egress rate limiting entries.

Operators can use these key combinations for aggregating traffic to apply rate limit. The key format is obtained from the JSON body of the Rate Limiting configuration request.

Note:

Operators must perform the search in the same sequence as mentioned in the following tables.

Table 3-39 Egress Key Combination

Sequence	Key Combination	Key Format
1	FQDN & ServiceType	FQDN_ServiceType
2	FQDN & NFType	FQDN_NFType
3	FQDN	FQDN
4	ServiceType	NFInstanceID_serviceType Note: Look up NFInstanceID from Learnt NFProfiles using FQDN.
5	NFType	NFInstanceID Note: Look up NFInstanceID from Learnt NFProfiles using FQDN.

Table 3-40 Ingress Key Combination

Sequence	Key Combination	Key Format
1	NfInstanceId	NfInstanceId of the consumer NF.
2	FQDN	FQDN
3	NFType	NFInstanceID Note: Look up NFInstanceID from Learnt NFProfiles using FQDN.

3.36 Support for Multus Container Network Interface

Multus Container Network Interface (CNI) is a plug-in that allows you to connect multiple network interfaces to pods in Kubernetes.

Each Kubernetes pod contains only one network interface. After integrating Multus CNI with SCP, you can create multiple interfaces in a pod and perform the following tasks:

• Create multiple signaling interfaces for routing the signaling traffic
• Create different interfaces for Operations, Administration, and Maintenance (OAM) and Signaling (SIG) traffic to enable traffic segregation

This feature configures the pods to use different network interfaces for different types of traffic. These interface IPs and routing information, such as range of IPs and gateways, are provided by Network Attachment Definition (NAD) Kubernetes custom resource. Multus CNI configures the IP routing rules based on this routing information.

For more information about Multus CNI, see https://github.com/k8snetworkplumbingwg/multus-cni.

Note:

Default Pod IPs assigned by Kubernetes are used for establishing pod-to-pod and egress communication. When Multus CNI adds other network interfaces to pods, these interface IPs can be used for egress communication.

Figure 3-12 Networking-Multus Support

The diagram shows how support for Multus helps SCP to support multiple interfaces on egress traffic from the scp-worker pod.

Note:

The Multus requirement is not applicable for SCP Control Pods.

The scp-worker pod is handling the following types of traffic:

• 5G SBI traffic
• Inter-pod communication traffic
• OAM traffic is communication traffic between observability components and scp-worker

The directions of this traffic are to and fro via SCP, and hence they are present in ingress and egress directions. There is no segregated ingress traffic. Only egress traffic is separated over multiple interfaces by dedicating Virtual network interface controllers (vNICs) to manage each type of traffic:

• Eth0 vNIC manages Egress (inter-pod communication traffic).
• Eth1 vNIC manages Egress 5G SBI traffic.

It is not required to separate OAM traffic from signaling traffic.

Managing Multus Container Network Interface

Enable

The Multus CNI plug-in can be integrated with Service Communication Proxy (SCP) at the time of SCP installation.

Configure

To use this feature, complete the configuration as described in "Configuring Multus Container Network Interface" in Oracle Communications Cloud Native Core, Service Communication Proxy Installation, Upgrade, and Fault Recovery Guide.

Note:

You can configure the required Helm parameters for this feature if you have performed a fresh installation of SCP or upgraded SCP within the same release version, for example, 1.15.1 to 1.15.1.

Observe

There is no specific metrics and alerts required for Multus Container Network Interface.

Maintain

If you encounter alerts at system level, see the Alerts section for resolution steps.

In case the alerts persist, perform the following tasks:

1. Collect the logs: For information about how to collect logs, see Oracle Communications Cloud Native Core, Service Communication Proxy Troubleshooting Guide.
2. Raise a service request: For information about how to raise a service request, see My Oracle Support.

3.37 Support for Model C Indirect 5G SBI Communication

5G Service Based Interface (SBI) communication models are used to establish connections among NFs and NF services. These communication models facilitate consumer NFs to route service requests to producer NFs either directly or indirectly through Service Communication Proxy (SCP). For more information about different communication models, such as Model A, Model B, Model C, and Model D, see 3GPP TS 23.501 version 16.6.0 Release 16.

With the introduction of the Model C Indirect 5G SBI Communication format in SCP, the consumer NF sends NF discovery service requests to NRF. After receiving the discovery response with NF profiles, the consumer NF does the following:

• Selects an NF Set or a specific NF instance from the NF Set
• Sends a service request to SCP with the address of the selected service producer NF
• Creates multiple network interfaces for different subnet IPs

Where,

• NF Set is a group of interchangeable NF instances of the same type that supports the same services and the same Network Slices. NF instances in the same NF Set may be geographically distributed but have access to the same context data.
• NF instance is an instance of the NF that can be identified.
• NF Set Identifier (NF Set ID) is a globally unique identifier of a set of equivalent and interchangeable CP NFs from a given network that provides distribution, redundancy, and scalability.

Then, SCP selects an NF service instance and routes the service requests to the selected producer NF. In case of failure if reselection is required, SCP selects the producer NF instance based on the NF Set. The reselection is based on the binding header, if available.

Support for Binding Headers in Model C Indirect 5G SBI Communication

SCP supports the following 5G SBI custom headers in Model C Indirect 5G SBI Communication:

• 3gpp-Sbi-Binding: 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-Routing-Binding: This header contains a Routing Binding Indication to direct service request to an HTTP server which has the targeted NF service resource context.

SCP does not update the value of the "3gpp-Sbi-Binding" header in the HTTP/2 request or response. It supports reading value of the "3gpp-Sbi-Routing-Binding" header in the service request and uses the binding level in the "3gpp-Sbi-Routing-Binding" header to perform routing.

Note:

Binding level NF service Set and NF service instance are not supported.

Support for Load Balancing and Alternate Routing in Model C Indirect 5G SBI Communication

When the target producer NF is unavailable, then SCP determines the NF Set ID of the target producer NF and performs alternate routing on the NF ID set instances in a sequence until SCP completes all the configured routing attempts.

SCP uses the NF set or NF instance for load balancing and alternate routing.

Support for Reverse Lookup in Model C Indirect 5G SBI Communication

When forward routing fails due to unavailability of the producer NF or the message does not have the NF Set ID, SCP performs reverse lookup in learned NF profiles. It performs alternate routing by obtaining destination information from the Set IDs. Reverse Lookup occurs when "3gpp-Sbi-Discovery-Target-Nfset" and "3gpp-Sbi-Routing-Binding" headers are absent in the message.

Model C Indirect 5G SBI Communication Response Headers

Additional response headers supported by Model C Indirect 5G SBI Communication in case of alternate routing are as follows:

• "3gpp-Sbi-Producer-Id"
• Either "3gpp-Sbi-Target-apiRoot" or Location header

Note:

Load Balancing or Forward Routing from routing options can not be configured with Release 16 of Model C Indirect 5G SBI Communication because forward routing occurs based on the "3gpp-Sbi-Target-apiRoot" header. If the "3gpp-Sbi-Target-apiRoot" header is unavailable, then only load balancing occurs based on NF Set ID in the binding header.

Managing Model C Indirect 5G SBI Communication

Enable

You can enable the Model C feature by adding - rel16 under releaseVersion in the ocscp-custom-values-<scp realse number>.yaml file. For more information about enabling this feature, see Oracle Communications Cloud Native Core, Service Communication Proxy Installation, Upgrade, and Fault Recovery Guide.

Note:

You can configure the required Helm parameters for this feature if you have performed a fresh installation of SCP or upgraded SCP within the same release version, for example, 1.15.1 to 1.15.1.

Configure

You must complete the fetching routing information configuration as described in "Fetching Release 16 Routing Rules" in Oracle Communications Cloud Native Core, Service Communication Proxy REST Specification Guide.

Observe

For information about alerts and metrics, see Alerts and Metrics.

Maintain

If you encounter alerts at system level, see the Alerts section for resolution steps.

In case the alerts persist, perform the following tasks:

1. Collect the logs: For information about how to collect logs, see Oracle Communications Cloud Native Core, Service Communication Proxy Troubleshooting Guide.
2. Raise a service request: For information about how to raise a service request, see My Oracle Support.

3.38 Multiple SCP Deployment in the Same Kubernetes Cluster

This feature allows operators to deploy multiple SCP instances in the same Kubernetes cluster. Each SCP instance is deployed in a different namespace and is independent of each other. These SCP instances can use the same cnDBTier with a unique database name or a dedicated cnDBTier during the installation. scpFqdn is included as part of the SCP logs, metrics, and alerts to identify and filter logs, metrics, and alerts at Grafana or Kibana when multiple SCP instances are deployed in the same Kubernetes cluster.

Managing Multiple SCP Deployment in the Same Kubernetes Cluster

Enable

Not applicable.

Configure

There is no specific configuration required for this feature. The following new dimensions are added to the respective metrics in the Metrics section:

• scpFqdn (for data plane)
• scp_fqdn (for control plane)

Observe

There is no specific metrics and alerts required for this feature.

Maintain

If you encounter alerts at system level, see the Alerts section for resolution steps.

In case the alerts persist, perform the following tasks:

1. Collect the logs: For information about how to collect logs, see Oracle Communications Cloud Native Core, Service Communication Proxy Troubleshooting Guide.
2. Raise a service request: For information about how to raise a service request, see My Oracle Support.

3.39 Support for SCP Triplet Deployment

Using the Service Communication Proxy (SCP) Triplet Deployment model, operators can configure three SCP instances as mates for georedundancy. Each SCP instance in a triplet is configured to manage the overall traffic expected for the triplet so that when two SCP instances are unavailable, the single SCP instance can manage the overall traffic. For example, if the first and the second SCP instances are unavailable, then the third instance is dimensioned to manage the load of the first two instances.

With this feature, SCP can:

• configure two mated SCP.
• support forward routing, load balancing, and alternate routing to producers in its serving localities and serving localities of its mates.
• route the service request directly to any producer in its serving localities and serving localities of its mates.
• support inter-SCP routing to producers which are not in its serving localities and serving localities of its mates.
  • When SCP serving a particular locality is unavailable, then service requests are routed to mated SCPs based on priority.
  • When multiple SCPs with the same priority are serving the producer's locality, SCP supports load balancing.

Managing SCP Triplet Deployment

Enable

Not applicable.

Configure

To use this feature, complete the configuration as described in "global Parameters" in Oracle Communications Cloud Native Core, Cloud Native Environment Installation, Upgrade, and Fault Recovery Guide.

Note:

You can configure the required Helm parameters for this feature if you have performed a fresh installation of SCP or upgraded SCP within the same release version, for example, 1.15.1 to 1.15.1.

Observe

For information about metrics, see Metrics.

Maintain

If you encounter alerts at system level, see the Alerts section for resolution steps.

In case the alerts persist, perform the following tasks:

1. Collect the logs: For information about how to collect logs, see Oracle Communications Cloud Native Core, Service Communication Proxy Troubleshooting Guide.
2. Raise a service request: For information about how to raise a service request, see My Oracle Support.

3.40 Alternate Routing based on the DNS SRV Records

Using the Alternate Routing based on the Domain Name System (DNS) Service (SRV) Records feature, SCP performs alternate routing by querying SRV records with the DNS server to find an alternate producer NF and route the service request.

Note:

• SCP uses either NF Set or DNS SRV Records to perform alternate routing.
• This feature is supported only in SCP Release 16 deployment with Model C Indirect 5G SBI Communication. For more information about Release 16, see 3GPP TS 23.501.

SCP performs the DNS SRV query for the FQDNs determined from NF profiles to find an alternate NF instance and route the services requests to the newly discovered alternate producer NF. These FQDNs are sourced from Network Repository Function (NRF) notifications received at SCP and from operator's configuration, which is statically configured through scpc-configuration as described in Oracle Communications Cloud Native Core, Service Communication Proxy REST Specification Guide.

The DNS SRV Resource record known as Service Proto Name (SPN) is used to identify the target NF type. If there are multiple instances of the same alternate NF profiles in a DNS resolution response for handling the same service request, then the appropriate target producer NF is selected using priority and weight attributes provided in the DNSSRVRecord data model as described in Oracle Communications Cloud Native Core, Service Communication Proxy REST Specification Guide.

This feature introduces the scpc-alternate-resolution microservice to perform the following tasks:

• Find alternate NF services by sending DNS SRV queries to the DNS server and receive the DNS SRV responses.
• Refresh DNS SRV records to get update in DNS SRV records.
• Provide DNS SRV records to scp-worker when required.

DNS SRV Default Scheme

SCP obtains FQDNs from the NF profiles and creates alternate routing records for each FQDN. Alternate routes are obtained by querying the configured DNS server. To query the DNS server, SCP creates an SPN entry for each FQDN by determining the scheme, such as http or https, for each FQDN.

Example of an SPN entry is as follows:

_http._tcp.udm1svc.scpsvc.svc.cluster.local

In an NF profile, FQDNs are available at the profile level and service level. For service level FQDNs, the scheme is defined at the service level. However, for profile level FQDNs, the scheme is not defined in the profile. Earlier, SCP used "http" as the default scheme for profile level FQDNs when creating SPNs. However, for operators who use "https", this results in not getting alternate routes for the profile level FQDN from the DNS server.

Therefore, the following Helm configuration is introduced to determine the scheme to be used for SPN creation for profile level FQDNs:

  dnsSrvSchemeConfig:
    defaultScheme: "https"
    exceptionList: [""]

defaultScheme is the default scheme used for creating Domain Name System (DNS) Service (SRV) Service Proto Name (SPN) from NF profile level FQDN. SCP also supports per NF type scheme selection. This is achieved by exceptionList, which defines the NF types that use a non-default scheme. For example, if defaultScheme is "https" and exceptionList has ["UDM", "AUSF"], then SPNs created from profile level FQDNs of UDM and AUSF will have "http" as the scheme, and all other NF types will have "https" as the scheme. For more information about defaultScheme and exceptionList, see "Global Parameters " in Oracle Communications Cloud Native Core, Service Communication Proxy Installation, Upgrade, and Fault Recovery Guide.

Note:

The default value in the Helm configuration indicates that the previously used value of "http" has been changed to "https".

Managing Alternate Routing based on the DNS SRV Records

Enable

This feature is enabled by setting the dnsSRVAlternateRouting parameter to true in the custom-values.yaml file. For more information, see Oracle Communications Cloud Native Core, Service Communication Proxy Installation, Upgrade, and Fault Recovery Guide.

Note:

You can configure the required Helm parameters for this feature if you have performed a fresh installation of SCP or upgraded SCP within the same release version, for example, 1.15.1 to 1.15.1.

Configure

You can configure the Alternate Routing based on the DNS SRV Records feature using Helm, REST API, and the CNC Console.

• Configure using Helm:
  • For information about configuring defaultScheme and exceptionList, see "Global Parameters" in Oracle Communications Cloud Native Core, Service Communication Proxy Installation, Upgrade, and Fault Recovery Guide.
  • For information about configuring the scpc-alternate-resolution microservice parameters, see "scpc-alternate-resolution Parameter" in Oracle Communications Cloud Native Core, Service Communication Proxy Installation, Upgrade, and Fault Recovery Guide.
• Configure using CNC Console: For information about the Routing Options tab to enable alternate routing configuration and set alternate route modes, see Configuring DNS SRV based Alternate Routing.
• Configure using REST API: For information about the alternatenfgroup parameter to manage the alternate NF group configuration data that is configured for the corresponding query parameters, see "Configuring Alternate NF Group" in Oracle Communications Cloud Native Core, Service Communication Proxy REST Specification Guide.

Observe

For information about alerts and metrics, see Alerts and Metrics.

Maintain

If you encounter alerts at system level, see the Alerts section for resolution steps.

In case the alerts persist, perform the following tasks:

1. Collect the logs: For information about how to collect logs, see Oracle Communications Cloud Native Core, Service Communication Proxy Troubleshooting Guide.
2. Raise a service request: For information about how to raise a service request, see My Oracle Support.

3.41 Support for Multiple Signaling Service IPs

In the previous release, SCP supported only one signaling IP from a given network. This IP was exposed to all NFs to establish 5G Service Based Interface (SBI) communications.

With the support for multiple signaling IPs, SCP can expose multiple signaling service IPs from the same or a different network to all NFs to accept 5G SBI signaling traffic (ingress connections).

Note:

SCP supports 8 signaling IPs.

This feature provides the flexibility to achieve maximum redundancy in the IP path. 5G NFs can have more than one SCP’s destination IPs for the transport network to select different paths for each of the IPs. Therefore, a single SCP instance is available through more than one IP path if one of the transport network paths fails.

Using this feature, you can do the following:

• Improve resiliency in 5G core network during transport failure by enabling multiple signaling paths.
• Create dedicated signaling service paths by configuring multiple service signaling IPs.

Managing Multiple Signaling IPs

Enable

This feature is enabled automatically in SCP at the time of deployment.

Configure

The serviceSpecifications Helm parameter is introduced as part of this feature. To use this feature, complete the configuration as described in "Configuration Parameters" in Oracle Communications Cloud Native Core, Service Communication Proxy Installation, Upgrade, and Fault Recovery Guide.

Note:

You can configure the required Helm parameters for this feature if you have performed a fresh installation of SCP or upgraded SCP within the same release version, for example, 1.15.1 to 1.15.1.

To add or remove signaling services, see Oracle Communications Cloud Native Core, Service Communication Proxy Installation, Upgrade, and Fault Recovery Guide.

Observe

For information about metrics, see Metrics.

Maintain

If you encounter alerts at system level, see the Alerts section for resolution steps.

In case the alerts persist, perform the following tasks:

1. Collect the logs: For information about how to collect logs, see Oracle Communications Cloud Native Core, Service Communication Proxy Troubleshooting Guide.
2. Raise a service request: For information about how to raise a service request, see My Oracle Support.

3.42 Egress Congestion Control Support at SCP

When Service Communication Proxy (SCP) receives a 5G Service Based Interface (SBI) message request from a consumer NF, SCP forwards the message request to a target producer NF. If the producer NF is overloaded, then SCP performs alternate routing to find another equivalent producer NF. In case no equivalent producer NF is available, then SCP sends an error response to the consumer NF with the configured error code. For more information about configuring error codes, see Configuring SBI Message Priority and Error Profiles for Egress Congestion Control.

Support for 3GPP SBI Message Priority

With the introduction of this feature, SCP uses the SBI message priority value present in the "3gpp-Sbi-Message-Priority" header to categorize a 5G SBI message request as high or low priority. The message request is prioritized based on the value of the "3gpp-Sbi-Message-Priority" header. By default, SCP considers 24 as the priority for the ingress message request if the message does not have the "3gpp-Sbi-Message-Priority" header. If the priority of the ingress message request is less than the value of the SBI Message Priority Discard From parameter, which is defined in Configuring SBI Message Priority and Error Profiles for Egress Congestion Control, then these messages are considered as high priority messages.

When SCP receives a high priority message request and the target producer NF is overloaded, SCP performs alternate routing to find an equivalent producer NF. If no equivalent producer NF is available, then SCP forwards the high priority message to the same target producer NF that is overloaded.

When SCP receives a low priority message request, SCP forwards the message request to a target producer NF. If the producer NF is overloaded, then SCP performs alternate routing to find another equivalent producer NF. In case no equivalent producer NF is available, then SCP sends an error response to the consumer NF with the configured error code.

Egress Congestion Control for Producer NF

The following subsections describe the egress congestion control for producer NFs.

Egress Congestion Control based on Busy Producer NF

SCP, based on the response status codes 503, 429, and 307 with the Retry-After header in the response, removes the producer NF from its routing list for a period specified in the Retry-After header. This behavior is applicable if the Retry-After header is present in the response.

Egress Congestion Control based on Reported Producer NF Service Load

The NRF reports the load of a producer NF through a notification. After detecting that the producer NF load is at or above the alternate routing onset threshold but below the throttle onset threshold, SCP attempts to alternate route message requests designated for the producer NFs to other NFs wherever possible.

If message requests cannot be alternate routed, they are routed to the producer NF. The behavior continues until the producer NF load reported decreases below the abatement threshold. If the load reported by the NF exceeds the throttle onset threshold, all requests are alternate routed wherever possible and if requests cannot be alternate routed, they are rejected with a configurable error response code. SCP supports a configurable error response code that is to be sent when requests are being throttled and cannot be alternate routed. The default code is 500. For more information on utilizing LCI for obtaining producer load, see Load Control based on the Load Control Information Header.

Note:

Currently, if load is not present at service level, it is not picked from the NF profile level.

Egress Congestion Control for Reported Load of NextHop SCP or SEPP

SCP protects the next-hop SCP or SEPP from congestion. SCP monitors the load reported by nexthop SCP or SEPP in the LCI header. When the load exceeds the threshold, congestion control steps are taken. Alternate routes or traffic throttling are utilized based on the request's priority.

Managing Egress Congestion Control Support at SCP

Enable

This feature is enabled automatically in SCP at the time of deployment.

Configure

You can configure this feature using the CNC Console or REST API.

• Configure using CNC Console: For information about SBI message priority and error profile configurations, see Configuring SBI Message Priority and Error Profiles for Egress Congestion Control.
• Configure using REST API: For information about message priority discard threshold and error code configurations in the nfServiceLoadBasedCongestionControl parameter, see "Configuring Routing Options" in Oracle Communications Cloud Native Core, Service Communication Proxy REST Specification Guide.

Observe

For information about alerts and metrics, see Alerts and Metrics.

Maintain

If you encounter alerts at the system level, see the Alerts section for resolution steps.

In case the alerts persist, perform the following tasks:

1. Collect the logs: For information about how to collect logs, see Oracle Communications Cloud Native Core, Service Communication Proxy Troubleshooting Guide.
2. Raise a service request: For information about how to raise a service request, see My Oracle Support.

3.43 Support for Model D Indirect 5G SBI Communication with Delegated Discovery

5G Service Based Interface (SBI) communication models are used to establish connections among NFs and NF services. These communication models facilitate consumer NFs to route service requests to producer NFs either directly or indirectly through Service Communication Proxy (SCP). For more information about different communication models, such as Model A, Model B, Model C, and Model D, see 3GPP TS 23.501 version 16.6.0 Release 16.

Using the Model D Indirect 5G SBI Communication with Delegated Discovery feature, consumer NFs delegate the producer NF discovery procedure to SCP by adding discovery parameters to the service requests.

SCP performs NF discovery with NRF using the received discovery parameters. The NRF indicated in the preferredNrfForOnDemandDiscovery parameter is used for the discovery procedure, which specifies the NRF preferred by scp-nrfproxy for delegated discovery. When the indicated NRF is not available, SCP does alternate routing to the NRFSet, which has the preferredNrfForOnDemandDiscovery parameter.

When SCP receives service requests with NF discovery parameters by including "3gpp-Sbi-Discovery" headers for the target producer NF selection, then SCP:

• extracts "3gpp-Sbi-Discovery" headers from the ingress service requests and initiates the discovery procedure based on these headers. For more information about the "3gpp-Sbi-Discovery" header, see 3GPP TS 29.500 version 16.6.0.
• selects the producer NF instance from the discovery response based on priority and capacity.
• stores NF discovery responses using the cache-control directives from NRF in NF discovery response messages.
• removes all "3gpp-Sbi-Discovery" headers from the service requests and forwards the service requests to the selected target producer NF. In case of inter-SCP routing, SCP forwards all the "3gpp-Sbi-Discovery" headers to the next hop SCP.
• reselects with the use of the discovery headers and results from delegated discovery responses are used to do initial selection and reselection.

Service Specific Discovery Request in Model D

The Model D discovery request that SCP sends to NRF has the 3gpp-sbi-discovery-service-names header. The path URI of the ingress message is used to extract the service name, such as nudm_uecm. As a result, the rule creating takes less time since SCP just needs to parse a smaller NF profile. The NF profile returned by NRF contains the requested NF service-specific information only.

NF Selection based on Preferred Locality

A consumer NF selects the target producer NF closest to it by setting the preferred locality to the value of the locality of the producer NF. When the preferred locality query parameter is present in the NF discovery service request, NRF prefers NF profiles with a locality attribute that matches the preferred locality. NRF returns additional NFs in the response that does not match the preferred target NF location. NRF sets a lower priority for any additional NFs on the response that does not match the preferred target NF location than those matching the preferred target NF location.

SCP configures preferred locality query parameters based on the received "3gpp-Sbi-Discovery-preferred-locality" header in the service request. SCP assigns its own locality as a preferred-locality for NF discovery if the assignPreferredLocality parameter is enabled and the "3gpp-Sbi-Discovery-preferred-locality" header is absent in ingress service requests. SCP overrides the "3gpp-Sbi-Discovery-preferred-locality" header received in the service request and uses its own locality as preferred locality for NF discovery if the overridePreferredLocality parameter is enabled and the "3gpp-Sbi-Discovery-preferred-locality" header is present in ingress service requests. SCP controls the forwarding of assigned or overridden value of "3gpp-Sbi-Discovery-preferred-locality" headers to next hop SCP.

Model D Indirect 5G SBI Communication supports the following routing functionalities as described in Support for Model C Indirect 5G SBI Communication:

• Binding Headers
• Load Balancing and Alternate Routing
• Reverse Lookup

Load Balancing Support for Delegated Discovery

Users can change the preferred NRF instance ID or NRF Set ID for delegated discovery at runtime using the REST API. If only NRF nfSetId is configured, then SCP does load balancing for the matching NRFs selected by nfSetId. For more information, see Oracle Communications Cloud Native Core, Service Communication Proxy REST Specification Guide.

Managing Model D Indirect 5G SBI Communication

Enable

You can enable the Model D feature by setting modeld_routing to true. For more information, see Configuring SCP Features.

Note:

You can enable this feature if SCP is deployed with Release 16.

Configure

You can configure this feature using Helm, REST API, and the CNC Console.

• Configure using Helm: For information about configuring the scp-nrfproxy microservice parameters, nrfProxyService, and nrfProfiles.customInfo.preferredNrfForOnDemandDiscovery, see Oracle Communications Cloud Native Core, Service Communication Proxy Installation, Upgrade, and Fault Recovery Guide.

  Note:

  You can configure the required Helm parameters for this feature if you have performed a fresh installation of SCP or upgraded SCP within the same release version, for example, 1.15.1 to 1.15.1.
• Configure using CNC Console: For information about configuring this feature, see:
  • Configuring SCP Features to enable the feature and cache discovery responses.
  • Configuring Global Options to verify the Forward Nf Discovery Headers status.
  • Configuring Routing Options to manage the "3gpp-Sbi-Discovery-preferred-locality" header.
• Configure using REST API: For information about the REST API configurations, see "Configuring System Options" and "Configuring Routing Options" in Oracle Communications Cloud Native Core, Service Communication Proxy REST Specification Guide.

Observe

For information about metrics, see Metrics.

Maintain

If you encounter alerts at the system level, see the Alerts section for resolution steps.

In case the alerts persist, perform the following tasks:

1. Collect the logs: For information about how to collect logs, see Oracle Communications Cloud Native Core, Service Communication Proxy Troubleshooting Guide.
2. Raise a service request: For information about how to raise a service request, see My Oracle Support.

3.43.1 Managing Delegated Discovery Response Caching Based on Discovery Query Parameters

In Model D, the responsibility of NF discovery has been delegated to the Service Communication Proxy (SCP). When Model D cache is enabled at SCP, SCP caches all the NF discovery responses received from NRF. These cached responses are then used for further Model D delegated discovery service requests, where applicable.

Currently, when caching is enabled at SCP, all NF discovery responses received from NRF are cached by SCP. The service request often contains query parameters that change frequently, such as subscriber IDs, for example, Subscription Permanent Identifier (SUPI), Global Permanent Subscriber Identity (GPSI), and so on. This dynamic nature of query parameters may prevent the reuse of cached responses at SCP. Since SCP maintains a defined cache size, frequent cache filling could lead to inefficient utilization of the discovery response cache.

With this feature enhancement, SCP can do selective caching of the discovery responses based on the user-configurable discovery query parameter list, which will be avoided or ignored for discovery response caching at SCP. Thus, the selective caching control helps the user reduce the risk of cache overflow. This caching mechanism helps to optimize the performance while reducing latency.

Managing Delegated Discovery Response Caching

Prerequisite

This feature will be enabled if Model D feature and caching in Model D are both enabled.

Enable

You can enable the Managing Delegated Discovery Response Caching Based on Query Parameters feature by setting modeld_routing to true and Caching is set to true to enable caching to store discovery responses. For more information, see Support for Model D Indirect 5G SBI Communication with Delegated Discovery.

Configure

You can configure this feature using REST API and the CNC Console.

• Configure using CNC Console: For information about CNC Console configurations, see
  • Get NF Discovery Response Cache Configuration Data
  • Configuring NF Delegated Discovery Response Cache
  .
• Configure using REST API: For information about configuring REST APIs, see the "Discovery Cache Response Configuration" in Oracle Communications Cloud Native Core, Service Communication Proxy REST Specification Guide.

Observe

The following metrics are added in the Metrics section:

• ocscp_worker_ondemand_discovery_response_cache_skipped_total
• ocscp_worker_ondemand_discovery_response_cache_added_total
• ocscp_worker_ondemand_discovery_response_cache_removed_total
• ocscp_nrfproxy_ondemand_discovery_response_cache_skipped_total
• ocscp_nrfproxy_ondemand_discovery_response_cache_added_total
• ocscp_nrfproxy_ondemand_discovery_response_cache_removed_total

Maintain

If you encounter alerts at system level, see the Alerts section for resolution steps.

In case the alerts persist, perform the following tasks:

1. Collect the logs: For information about how to collect logs, see Oracle Communications Cloud Native Core, Service Communication Proxy Troubleshooting Guide.
2. Raise a service request: For information about how to raise a service request, see My Oracle Support.

3.43.2 NF Discovery Response Cache Update Based on the Received Notifications

The current SCP Model D discovery response cache functionality helps reduce latency, network bandwidth usage, and overall load on the NRF. However, the refresh of these cache records depends on the validity time value received in the discovery response. A Notification update or Deregister event for an NF may cause records containing the same NF to become outdated. Without timely cache updates, SCP may rely on outdated information, potentially leading to incorrect or inefficient routing decisions.

The NF Discovery Response Cache Update enhancement allows SCP to automatically update its Model D discovery response cache or invalidate the relevant cache based on real-time notifications from the NRF whenever there are changes or updates to NF profile information. In the case of record invalidation, SCP will initiate a discovery request to the NRF upon receiving a new request with the same query parameters.This ensures that SCP always works with the most current data, preventing issues related to outdated cache entries.

The following benefits highlight how this feature enhances system performance:

• Reduced Latency and Network Bandwidth: By ensuring the discovery cache is always up-to-date, this feature minimizes the need for redundant discovery operations, resulting in faster communication responses.
• Reduced NRF Discovery Traffic: With the cache being frequently updated based on NRF notifications, unnecessary discovery requests to the NRF are minimized, leading to lower overall traffic.
• Improved Processing Time at SCP: Real-time updates to the discovery response cache prevent delays caused by outdated information, allowing for faster processing within SCP.
• Prevent Improper SBI Routing: This feature ensures that the correct and most current NF profile data is always used, avoiding errors in Service-Based Interface (SBI) routing decisions.

Attributes for Cache Refresh and Invalidation

The following table lists the NF profile parameters that trigger cache refresh and those that trigger cache invalidation:

Table 3-41 NF Profile Attributes for Cache Management

Attribute Name (as per 3GPP 29.510)	Impact on NF Profile and SCP Routing Consideration	Impact on NF Discovery Response and NRF Refresh
nfInstanceId	NA	NA
nfType	NA	NA
nfStatus	Yes	No
nfInstanceName	NA	NA
heartBeatTimer	NA	NA
plmnList	No	Yes
snpnList	No	Yes
sNssais	No	Yes
perPlmnSnssaiList	No	Yes
nsiList	No	Yes
fqdn	Yes	No If the discovery header, 3gpp-sbi-discovery-target-nf-fqdn, is present in the request, it will be invalidated.
interPlmnFqdn	Yes	No
ipv4Addresses	Yes	No
ipv6Addresses	Yes	No
allowedPlmns	No	Yes
allowedSnpns	No	Yes
allowedNfTypes	No	Yes
allowedNfDomains	No	Yes
allowedNssais	No	Yes
priority	No	Yes SCP must contact NRF to obtain the updated prioritized list of NFs.
capacity	Yes	No
load	Yes	No
loadTimeStamp	Yes	No
locality	No	Yes
udrInfo	No	Yes
udrInfoList	No	Yes
udmInfo	No	Yes
udmInfoList	No	Yes
ausfInfo	No	Yes
ausfInfoList	No	Yes
amfInfo	No	Yes
amfInfoList	No	Yes
smfInfo	No	Yes
smfInfoList	No	Yes
upfInfo	No	Yes
upfInfoList	No	Yes
pcfInfo	No	Yes
pcfInfoList	No	Yes
bsfInfo	No	Yes
bsfInfoList	No	Yes
chfInfo	No	Yes
chfInfoList	No	Yes
nefInfo	No	Yes
nrfInfo	No	Yes
udsfInfo	No	Yes
udsfInfoList	No	Yes
nwdafInfo	No	Yes
pcscfInfoList	No	Yes
hssInfoList	No	Yes
customInfo	NA	NA
recoveryTime	NA	NA
nfServicePersistence	NA	NA
nfServices	Refer Table 3-42	Refer Table 3-42
nfServiceList	Refer Table 3-42	Refer Table 3-42
nfProfile Changes Support Ind	NA	NA
nfProfile Changes Ind	NA	NA
default Notification Subscriptions	No	Yes
lmfInfo	No	Yes
gmlcInfo	No	Yes
nfSetIdList	No	Yes
servingScope	No	Yes
lcHSupportInd	Yes	No
olcHSupportInd	Yes	No
NF Set Recovery Time List	NA	NA
Service Set Recovery Time List	NA	NA
scpDomains	Not supported in ocscp	Not supported in ocscp
scpInfo	Yes Update the inter-SCP routing rules	No

Table 3-42 NF Service Attributes for Cache Management

Attribute Name (as per 3GPP 29.510)	Impact on NF Profile and SCP Routing Consideration	Impact on NF Discovery Response and NRF Refresh
serviceInstanceId	NA	Yes
serviceName	NA	NA
versions	No	Yes
scheme	Yes	No
nfServiceStatus	Yes	No
fqdn	Yes	No If the discovery header, 3gpp-sbi-discovery-target-nf-fqdn, is present in the request, it will be invalidated.
interPlmnFqdn	Yes	No
ipEndPoints	Yes	No
apiPrefix	Yes	No
default Notification Subscriptions	No	Yes
allowedPlmns	No	Yes
allowedSnpns	No	Yes
allowedNfTypes	No	Yes
allowedNfDomains	No	Yes
allowedNssais	No	Yes
allowed Operations Per NfType	No	Yes
allowed Operations Per NfInstance	No	Yes
priority	No	Yes
capacity	Yes	No
load	Yes	No
loadTimeStamp	Yes	No
recoveryTime	NA	NA
supportedFeatures	No	Yes
nfServiceSetIdList	No	Yes
sNssais	No	Yes
perPlmnSnssaiList	No	Yes
vendorId	NA	NA
supported Vendor Specific Features	NA	NA
oauth2Required	Yes	No

Note:

SCP performs NRF refresh when any service is added or removed from a profile.

Managing NF Discovery Response Cache Update

Enable

You can enable the NF Discovery Response Cache Update Based on the Received Notifications feature by setting both modeld_routing and Caching to true, and updating the cacheUpdateMode parameter. For more information, see Configuring SCP Features.

Configure

You can configure this feature using REST API and the CNC Console.

• Configure using CNC Console: For information about CNC Console configurations, see the Configuring Model D Indirect 5G SBI Communication feature section.
• Configure using REST API: For information about configuring REST APIs, see the "Configuring SCP Features" in Oracle Communications Cloud Native Core, Service Communication Proxy REST Specification Guide.

Observe

The following metrics are added in the Metrics section:

• ocscp_nrfproxy_ondemand_discovery_cache_notif_local_refresh_total
• ocscp_nrfproxy_ondemand_discovery_cache_invalid_notif_nrf_refresh_total
• ocscp_worker_ondemand_discovery_cache_notif_local_refresh_total
• ocscp_worker_ondemand_discovery_cache_invalid_notif_nrf_refresh_total
• ocscp_nrfproxy_ondemand_discovery_cache_nrf_refreshed_status_total
• ocscp_worker_ondemand_discovery_cache_nrf_refreshed_status_total

Maintain

If you encounter alerts at system level, see the Alerts section for resolution steps.

In case the alerts persist, perform the following tasks:

1. Collect the logs: For information about how to collect logs, see Oracle Communications Cloud Native Core, Service Communication Proxy Troubleshooting Guide.
2. Raise a service request: For information about how to raise a service request, see My Oracle Support.

3.44 Support for 5G SBI Roaming

3GPP specifies Local Breakout (LBO) and Home Routing (HR) roaming architectures. SCP can be used for indirect communications such as Model C or Model D between NFs within Visited Public Land Mobile Network (VPLMN) or Home Public Land Mobile Network (HPLMN) or within both VPLMN and HPLMN.

The following image depicts the 5G system roaming architecture in the case of a home routed scenario with service-based interfaces within the Control Plane. For more information, see 3GPP TS 23.501 v16.6.0.

Figure 3-13 Local and Remote Routing

Local PLMN consumer NFs can be V-SMF, V-AMF, or V-PCF, and so on. Remote PLMN producer NFs can be H-SMF, H-UDM, or H-PCF, and so on.

This feature enables 5G SBI indirect communication for 5G SBI roaming signaling traffic, which includes roaming ingress traffic to local operator's network and egress traffic to remote operator’s network.

The PLMN network ID for a mobile network identifies the roaming location uniquely. The ID contains Mobile Country Code (MCC) and Mobile Network Code (MNC) to identify a mobile network operator.

If an NF wants to be discovered by other NFs in a different PLMN, it registers inter PLMN FQDN in NRF. The format of inter PLMN FQDN is as follows:

<labels separated by dots>.5gc.mnc<MNC>.mcc<MCC>.3gppnetwork.org

Example of of Inter PLMN FQDN UDM belonging to PLMN MNC 12 and MCC 345:

udm.5gc.mnc012.mcc345.3gppnetwork.org

Note:

Telescopic FQDN is not supported in this release.

Intra-PLMN (non-roaming) traffic is routed based on 5G NF topology determined from NRF using FQDN (local) present in NFs. 5G SBI roaming traffic received from SEPP, that is, ingress to local operator network site and with inter-PLMN or self constructed FQDN, is routed using inter-PLMN FQDN present in NFs.

If SCP receives a "3gpp-Sbi-Target-apiRoot" HTTP header in the ingress service request, it determines the target PLMN from the inter PLMN FQDN specified in this header. If the "3gpp-Sbi-Target-apiRoot" HTTP header is not present, SCP performs delegated discovery for NF selection based on the received "3gpp-Sbi-Discovery" headers.

To support the 5G SBI roaming subscriber inter-PLMN traffic routing for different remote PLMNs, SCP identifies whether the ingress 5G SBI service request is for local PLMN IDs or remote PLMN IDs. To differentiate between intra-PLMN and inter-PLMN service requests, SCP uses local supported PLMN IDs.

For a network, local supported PLMN IDs include SCP supported PLMN IDs. Other than locally supported PLMN IDs, all PLMN IDs are considered as remote PLMN IDs by SCP. A network consists of multiple PLMN IDs, and network deployment is based on PLMN IDs.

SCP determines the SEPP topology from NRF or locally configured SEPP profile at SCP. SCP selects a SEPP instance based on PLMN serving the target NF. SCP performs load balancing and alternate routing between SEPP instances based on priority and capacity available in the SEPP profile.

To use InterPLMN routing with Oracle NRF, you must enable the scp_user_agent_info REST API parameter to add the "User-Agent" header in the format starting with the keyword "SCP-" so that SCP originated messages towards NRF include the "User-Agent" header required by Oracle NRF.

Managing Support for 5G SBI Roaming

Enable

You can enable this feature by setting interplmn_routing to true. For more information, see Configuring SCP Features.

Configure

You can configure this feature using Helm, REST API, and the CNC Console.

• Configure using Helm: For information about Helm configurations, see Oracle Communications Cloud Native Core, Service Communication Proxy Installation, Upgrade, and Fault Recovery Guide.

  Note:

  You can configure the required Helm parameters for this feature if you have performed a fresh installation of SCP or upgraded SCP within the same release version, for example, 1.15.1 to 1.15.1.
• Configure using CNC Console: For information about configuring NF instance IDs, see Configuring SEPP Inter PLMN Routing.
• Configure using REST API: For information about the REST API configurations, see "Configuring SCP Features" and "Configuring SEPP InterPlmn Info" in Oracle Communications Cloud Native Core, Service Communication Proxy REST Specification Guide.

Observe

For information about alerts and metrics, see Alerts and Metrics.

Maintain

If you encounter alerts at system level, see the Alerts section for resolution steps.

In case the alerts persist, perform the following tasks:

1. Collect the logs: For information about how to collect logs, see Oracle Communications Cloud Native Core, Service Communication Proxy Troubleshooting Guide.
2. Raise a service request: For information about how to raise a service request, see My Oracle Support.

3.45 Routing Options Enhancements for Next Hop SCP and Notification or Callback Messages

The existing configuration of routing options supports 3GPP defined 5G NF services types, such as nudm-uecm, nudm-sdm, nsmsf-sms, and so on. However, there is no routing option defined for the following:

• 5G SBI notification or callback requests
• Inter-SCP or next hop SCP routing

With the introduction of this feature, the existing 5G SBI message routing option is enhanced to support:

• 5G SBI notification or callback message requests: SCP uses the "3gpp-sbi-callback" header to identify whether a 5G SBI request is a notification or callback.
• Inter-SCP or next hop SCP routing: When a consumer SCP routes a 5G SBI service request to the next hop SCP, the consumer SCP must have configurable routing options for SCP to SCP interface for each 3GPP defined 5G NF Service types, such as nudm-uecm, nudm-sdm, nsmsf-sms, and so on, if more than one SCP instance is involved in routing the 5G SBI service request. A new parameter known as nextHopSCP is introduced to the existing routing configurations to support this functionality.

This feature provides flexibility to configure inter-SCP or next hop SCP routing options for all services.

SCP derives an incoming message type from both "3gpp-sbi-callback" header and servicename in path to identify if it is a notification or callback request, or service request.

SCP uses the nextHopSCP routing configuration when routing messages towards the next hop SCP. The nextHopSCP routing parameters are set in SCP to define the message processing time to get a response from the producer NF instance in the same network or from another SCP instance in a different region.

Identification of 5G SBI Notification or Callback Messages

SCP identifies whether the ingress message request is a notification or callback, or service specific request based on the "3gpp-sbi-callback" header and the servicename in path present in the Uniform Resource Identifier (URI).

The following table describes different scenarios to identify a message request based on the availability of the "3gpp-sbi-callback" header and servicename in path.

Table 3-43 Identifying a Message Request

3gpp-sbi-callback	servicename in path	Description	Expected Routing at SCP
Present	Absent	The message request is considered as a 5G SBI notification or callback. Routing option configured for "5g-sbi-notification" is applicable. For more information about "5g-sbi-notification", see 3GPP TS 29.500 v16.6.0.	The expected notification message routing is as follows: If the 3gpp-Sbi-Routing-Binding header is present, then the alternate routing as per Model C, Model D, and interPLMN traffic routing feature support at SCP. If an alternate routing configuration is configured at SCP, then the alternate routing as per DNSSRV or route group configuration is supported at SCP. If both alternate notification endpoint selection information is unavailable, SCP cannot perform notification message alternate routing.
Present	Present	The message request is considered as a 5G SBI notification or callback. Routing option configured for "5g-sbi-notification" is applicable.	The expected notification message routing is as follows: If the 3gpp-Sbi-Routing-Binding header is present, then the alternate routing as per Model C, Model D, and interPLMN traffic routing feature support at SCP. If an alternate routing configuration is configured at SCP, then the alternate routing as per DNSSRV or route group configuration is supported at SCP. If both alternate notification endpoint selection information is unavailable, SCP cannot perform notification message alternate routing.
Absent	Absent	The message request is considered as a 5G SBI notification or callback. Routing option configured for "5g-sbi-notification" is applicable.	The expected notification message routing is as follows: If the 3gpp-Sbi-Routing-Binding header is present, then the alternate routing as per Model C, Model D, and interPLMN traffic routing feature support at SCP. If an alternate routing configuration is configured at SCP, then the alternate routing as per DNSSRV or route group configuration is supported at SCP. If both alternate notification endpoint selection information is unavailable, SCP cannot perform notification message alternate routing.
Absent	Present	The message request is considered as a 5G SBI service specific request. Routing option configured to specific 5G NF service is applicable.	The expected service request message routing is as follows: If the 3gpp-Sbi-Routing-Binding header is present, then the alternate routing as per Model C, Model D, and interPLMN traffic routing feature support at SCP. If an alternate routing configuration is configured at SCP, then the alternate routing feature as per DNSSRV or route group configuration is supported at SCP. If both alternate notification endpoint selection information is unavailable, SCP will be unable to perform alternate routing based on reverse lookup feature support at SCP.

Managing Routing Options Enhancements for Next Hop SCP and Notification or Callback Messages

Enable

This feature is enabled automatically at the time of SCP deployment.

Configure

You can configure this feature using REST API and the CNC Console.

• Configure using REST API: For information about the REST API configurations, see "Configuring Routing Options" in Oracle Communications Cloud Native Core, Service Communication Proxy REST Specification Guide.
• Configure using CNC Console: For information about configuring NF instance IDs, see Configuring the nextHopSCP Routing Option.

Observe

For information about metrics, see Metrics.

Maintain

If you encounter alerts at the system level, see the Alerts section for resolution steps.

In case the alerts persist, perform the following tasks:

1. Collect the logs: For information about how to collect logs, see Oracle Communications Cloud Native Core, Service Communication Proxy Troubleshooting Guide.
2. Raise a service request: For information about how to raise a service request, see My Oracle Support.

3.46 Support for Alternate Routing Using Static Configuration

5G Service Based Interface (SBI) communication models establish connections among NFs and NF services. These communication models facilitate consumer NFs to route service requests to producer NFs directly or indirectly through Service Communication Proxy (SCP).

If the target producer NF is unavailable, SCP determines the NF Set ID of the target producer NF and performs alternate routing on the NF Set ID instances in a sequence until SCP completes all the configured routing attempts. In the absence of NF Set, SCP allows operators to configure FQDNs and use the Domain Name System (DNS) Service (SRV) method to find the equivalent NFs. In case the DNS SRV method is not availed by operators, then static configuration is used for alternate routing.

With the introduction of the static configuration, SCP allows operators to configure a pair or combination of primary NFs and their alternate NFs to define alternate producer NFs, which can be used in alternate NF selection when routing attempt to the primary NF fails.

The static alternate route feature prioritizes the settings in the static routing configuration over any NF profile for the alternate destination.

Managing Support for Alternate Routing Using Static Configuration

Enable

By default, this feature is disabled. To enable alternate routing using static configuration, you must complete the configuration as described in the following configuration section.

Configure

You can configure this feature using REST API and the CNC Console.

• Configure using CNC Console: For information about CNC Console configurations, see Configuring Routing Options and Configuring Route Groups.
• Configure using REST API: For information about configuring REST APIs, see "Configuring Route Groups" in Oracle Communications Cloud Native Core, Service Communication Proxy REST Specification Guide.

Observe

For information about alerts and metrics, see Alerts and Metrics.

Maintain

If you encounter alerts at system level, see the Alerts section for resolution steps.

In case the alerts persist, perform the following tasks:

1. Collect the logs: For information about how to collect logs, see Oracle Communications Cloud Native Core, Service Communication Proxy Troubleshooting Guide.
2. Raise a service request: For information about how to raise a service request, see My Oracle Support.

3.47 Support for Thread Watchdog

The Thread Watchdog feature enables SCP to monitor whether any SCP microservice threads are stuck or nonresponsive at regular intervals. If the thread watchdog reports any thread as nonresponsive or stuck, then the pod's liveness fails. If the pod's liveness failure count exceeds the failure threshold value, then the pod is restarted. If a thread doesn't respond within a specified duration, it is marked as nonresponsive or stuck. This time interval is configurable.

The failure threshold for the thread watchdog is also configurable. It determines how often the watchdog attempts to retry in case the watchdog detects a thread stuck or nonresponsiveness before declaring whether a thread is stuck or nonresponsive. Pod liveness fails when the watchdog failure count exceeds the configured threshold. These values are tuned and are not recommended to be changed.

Managing Support for Thread Watchdog

Enable

This feature is enabled automatically in SCP at the time of deployment. To disable this feature, set the enableThreadWatchDog parameter to false as described in "Configuring SCP Services" in Oracle Communications Cloud Native Core, Service Communication Proxy REST Specification Guide.

Configure

You can configure this feature using REST API parameters as described in "Configuring SCP Services" in Oracle Communications Cloud Native Core, Service Communication Proxy REST Specification Guide. To view thread watchdog configurations on the CNC Console, see Configuring SCP Services.

Observe

There is no specific metric and alert required for this feature.

Maintain

If you encounter alerts at system level, see the Alerts section for resolution steps.

In case the alerts persist, perform the following tasks:

1. Collect the logs: For information about how to collect logs, see Oracle Communications Cloud Native Core, Service Communication Proxy Troubleshooting Guide.
2. Raise a service request: For information about how to raise a service request, see My Oracle Support.

3.48 Message Feed Enhancements

The Message Feed feature allows copying of both request and response messages routed through SCP toward Oracle Communications Network Analytics Data Director (OCNADD) based on the configuration at SCP. Along with request and response messages, metadata, as described in Table 3-44, is also sent to OCNADD.

The Message Copy feature provides SSL and SASL as a security mechanism for encryption and authentication. SSL can be configured for encryption, and it also serves as two way authentication between the scp-worker and the Kafka broker. SASL can be configured to achieve authentication of connections to brokers from scp-worker. Configuration of both SSL and SASL can be done on SCP with secret creation and specifying them under the ddSslConfiguration and ddSaslConfiguration sections of the SCP deployment file.

From SCP 23.4.1, SCP is enhanced to select Kafka partitions based on the kafkaPartitionSelectionLogic REST API configuration that provides the following methods to distribute the messages:

• RoundRobin: All the messages are distributed across all the available partitions in a round-robin order.
• KeyBased: Messages with the same correlation-id are routed to the same partition. This ensures the same transaction messages are routed to the same partition.

  For more information about kafkaPartitionSelectionLogic, see Oracle Communications Cloud Native Core, Service Communication Proxy REST Specification Guide.

OCNADD aggregates the data for monitoring and analytical purposes. For more information about OCNADD, see Oracle Communications Network Analytics Data Director User Guide.

The following table describes metadata sent to OCNADD:

Table 3-44 Metadata Table

Metadata	Description
correlation-id	Identifies transactions such as ingress downstream request, all corresponding upstream requests and responses, and downstream response.
consumer-id	Indicates the 5G NF instance ID of the originator NF, which is retrieved from the User-Agent header in the received request message. Conditions: For SCP initiated request and response messages, for example, delegated Discovery and OAuth access token requests, consumer-id metadata must be present, and the value should be the same as the feed-source-> nf-instance-id metadata value. Note: As this is an SCP instance-id, there should not be any dependency on the User-Agent header to retrieve the nf-instance-id information. For consumer NF initiated messages, consumer-id metadata depends on the presence of the User-Agent header in the received service request. The recommended User-Agent header format is <NF Type>-<NF Instance ID> <NF FQDN>.
producer-id	Indicates the 5G NF instance ID of the destination NF.
consumer-fqdn	Indicates FQDN of the originator NF, which is retrieved from the User-Agent header in the received request message. Conditions: For SCP initiated request and response messages, for example, delegated Discovery and OAuth access token requests, consumer-fqdn metadata must be present, and the value should be the same as the feed-source->nf-fqdn metadata value. Note: As this is an SCP FQDN, there should not be any dependency on the User-Agent header to retrieve the FDQN information. For consumer NF initiated messages, consumer-id metadata depends on the presence of the User-Agent header in the received service request. The recommended User-Agent header format is <NF Type>-<NF Instance ID> <NF FQDN>.
producer-fqdn	Indicates FQDN of the destination NF.
hop-by-hop-id	Uniquely identifies a request-response pairs within a transaction. The hop-by-hop-id uses a maximum substring length of 30 characters for the following fields as part of the identifier: producerFqdn: Use the first 30 characters consumerFqdn: Use the first 30 characters podInstanceID: Use the last 30 characters The hop-by-hop-id uses the following format to identify request-response pairs: Consumer NF to SCP or SCP to Consumer NF (RxRequest/TxResponse) When the consumer NF is specified in the request: Format: <First 30 characters of consumerFqdn>_<Last 30 characters of worker-pod-instance-Id> Example: udm12.oracle.com_cp-scp-worker-56df9944b6-kxthp When the consumer NF is not specified: Format: NA_<Last 30 characters of worker-pod-instanceId> Where, NA indicates the absence of a consumer NF FQDN in the request. Example: NA_cp-scp-worker-56df9944b6-kxthp SCP to Producer NF or Producer NF to SCP (TxRequest/RxResponse): Format: <Last 30 characters of worker-pod-instance-Id>_<First 30 characters of producerFqdn>_Suffix Where, Suffix indicates an incrementing integer that increases with each hop. Example: cp-scp-worker-56df9944b6-kxthp_udm1svc.scpsvc.svc.cluster.loc_2
reroute-cause	Indicates the reroute cause. It contains one of the following parameters: Circuit breaking: Indicates that a message is an alternate attempt due to circuit breaking functionality at SCP. Outlier detection: Indicates that a message is an alternate attempt due to outlier detection functionality at SCP. Egress-rate-limit: Indicates that a message is an alternate attempt due to egress rate limiting functionality at SCP producer-nf-congestion: Indicates that a message is an alternate attempt due to producer NF congestion Error received Timeout Not Applicable
timestamp	Indicates timestamp (in nanoseconds) when message is received or forwarded by SCP.
message-direction	Indicates whether a message is an ingress message sent to SCP or an egress message forwarded by SCP. It can be indicated by putting the following traffic feed trigger point name: RxRequest TxRequest RxResponse TxResponse
feed-source	Indicates the source of this traffic feed. This contains the key-value of different identity of the node sending the traffic feed. Feed-source nf-type = SCP nf-fqdn = SCP's FQDN nf-instance-id = SCP's NF instance id pod-instance-id = SCP-worker's pod instance id

Sample traffic feed generated by SCP:

{
  "version": "1.0.0",
  "metadata-list": {
    "correlation-id": "19645510-4698-4303-84f9-41c5414822e0",
    "consumer-id": "26740918-e9cd-0205-aada-71a76214d33c",
    "consumer-fqdn": "udm121.oracle.com",
    "producer-fqdn": "udm1svc.default.svc.cluster.local",
    "hop-by-hop-id": "1",
    "reroute-cause": "ErrorReceived",
    "timestamp": "1659959278583551367",
    "message-direction": "RESPONSE_EGRESS",
    "feed-source": {
      "nf-type": "SCP",
      "nf-fqdn": "ocscp-scp-worker.scpsvc.svc.cluster.local",
      "nf-instance-id": "6faf1bbc-6e4a-4454-a507-a14ef8e1bc5e",
      "pod-instance-id": "ocscp-scp-worker-65df786b4d-qv7hs"
    }
  },
  "header-list": {
    "server": [
      "SCP-ocscp-scp-worker.scpsvc.svc.cluster.local"
    ],
    "content-type": [
      "application/problem+json"
    ]
  },
  "5g-sbi-message": "{\"title\":\"Service Unavailable\",\"status\":\"503\",\"detail\":\"Service Unavailable:: Service Unavailable\"}"
}

Managing Message Copy

Enable

By default, this feature is disabled. To enable this feature, you must complete the configuration as described in the following configuration section.

Configure

You can configure this feature using REST API and the CNC Console.

• Configure using CNC Console: For information about CNC Console configurations, see Configuring SCP Features and Configuring Traffic Feed.
• Configure using REST API: For information about configuring REST APIs, see "Configuring SCP Features", "Configuring Traffic Feed Data Director", and "Configuring Traffic Feed Trigger Point Config" in Oracle Communications Cloud Native Core, Service Communication Proxy REST Specification Guide.

Observe

The following metrics are added in the Metrics section:

• ocscp_metric_trafficfeed_attempted_total
• ocscp_metric_trafficfeed_failed_total
• ocscp_metric_trafficfeed_not_attempted_total
• ocscp_metric_trafficfeed_partition_unhealthy
• ocscp_metric_trafficfeed_success_total
• ocscp_metric_trafficfeed_cluster_unhealthy

The following alerts are added in the Alerts section:

• SCPTrafficFeedSendFailed
• SCPTrafficFeedPartitionUnhealthy
• SCPTrafficFeedKafkaClusterUnhealthy

Maintain

If you encounter alerts at system level, see the Alerts section for resolution steps.

In case the alerts persist, perform the following tasks:

1. Collect the logs: For information about how to collect logs, see Oracle Communications Cloud Native Core, Service Communication Proxy Troubleshooting Guide.
2. Raise a service request: For information about how to raise a service request, see My Oracle Support.

3.49 Observability Enhancements for SCP Inter-microservice Connectivity

In the previous releases, SCP microservices communicated with each other to perform various tasks, however, there was no mechanism to determine communication failures between any two SCP microservices.

This enhancement enables SCP to improve the SCP observability by introducing observability parameters to monitor inter-microservices communication failures.

SCP microservices communicate with each other through Hypertext Transfer Protocol (HTTP). To monitor any communication failure between SCP microservices, SCP observability services are enhanced with a new metric and an alert. This observability enhancement checks inter-microservice connectivity at regular intervals. If there is any communication failure, it raises an alert based on the threshold configurations. The alert is automatically cleared when the connection is restored.

Managing Observability Enhancements for SCP Inter-microservice Connectivity

Enable

This enhancement is automatically enabled in SCP at the time of deployment.

Configure

You can configure this feature using REST API and the CNC Console.

• Configure using CNC Console: For information about CNC Console configurations, see Configuring SCP Services.
• Configure using REST API: For information about configuring using REST APIs, see "Configuring SCP Services" in Oracle Communications Cloud Native Core, Service Communication Proxy REST Specification Guide.

Observe

For information about alerts and metrics, see Alerts and Metrics.

Maintain

If you encounter alerts at system level, see the Alerts section for resolution steps.

In case the alerts persist, perform the following tasks:

1. Collect the logs: For information about how to collect logs, see Oracle Communications Cloud Native Core, Service Communication Proxy Troubleshooting Guide.
2. Raise a service request: For information about how to raise a service request, see My Oracle Support.

3.50 Load Control based on the Load Control Information Header

In the previous release, SCP was only relying on the producer NF's load information obtained from Network Repository Function (NRF) through NF status notifications, as SCP has subscribed for load status with NRF. This process might delay the availability of the instantaneous load information value at SCP.

With the introduction of Load Control based on the Load Control Information (LCI) Header feature, SCP has enhanced the existing load control functionality by enabling a direct exchange of the load information between 5G NFs and SCP using the "3gpp-Sbi-Lci" HTTP header.

When Service Communication Proxy (SCP) receives a "3gpp-Sbi-Lci" HTTP header, SCP calculates the effective available capacity based on the load reported by the peer NFs in LCI header or NF status notification from NRF. When SCP receives a 5G Service Based Interface (SBI) message request from a consumer NF, SCP forwards the message request to a selected target NF based on the priority and effective available capacity. If the load of the producer NF is equal to or above the throttle onset threshold percent, SCP doesn't consider that producer NF for routing; instead, it goes for alternate routing options to other equivalent producer NFs.

SCP can also convey its own load control information to its peers so that the 5G NFs can take appropriate action based on its implementation. Thus, Load Control Information assists the receiver 5G NF in target NF reselection and load balancing.

Managing Load Control based on the Load Control Information Header

Enable

To enable the Load Control based on the Load Control Information Header feature, set the lci option to true on the CNC Console. For more information, see Configuring SCP Features.

Configure

You can configure this feature using REST API and the CNC Console.

• Configure using REST API: For information about the REST API configurations, see "Configuring Load Control Information" in Oracle Communications Cloud Native Core, Service Communication Proxy REST Specification Guide.
• Configure using CNC Console: For information about configuring NF instance IDs, see Configuring SCP Features.

Observe

For information about metrics, see Metrics.

Maintain

If you encounter alerts at the system level, see the Alerts section for resolution steps.

In case the alerts persist, perform the following tasks:

1. Collect the logs: For information about how to collect logs, see Oracle Communications Cloud Native Core, Service Communication Proxy Troubleshooting Guide.
2. Raise a service request: For information about how to raise a service request, see My Oracle Support.

3.51 Support for Three-site Georedundancy

Geographical Redundant (Georedundant) deployments ensure high availability and redundancy of NFs. SCP supports a three-site georedundancy deployment of cnDBTier to ensure service availability when one of the SCP sites is down.

When the primary SCP is available, NFs send service requests to the primary SCP. When SCP at the primary site is unavailable, NFs redirect service requests to the secondary SCP or tertiary SCP until the primary SCP’s active status is restored.

The SCP database consists of the following:

• Configuration Data: The configuration data is exclusive for a given SCP instance. Therefore, an exclusive logical database is created and used by an SCP instance to store its configuration data. You can configure SCP instance specific configurations using RESTful config API exposed by SCPC-Configuration microservice through the CNC Console.
• Routing Data: This is the routing rules data that SCP determines from NRF in 5G Core network topology.
• Status Data: This data provides the status of upgrade or rollback.

In a three-site deployment, each SCP instance uses its database. The data gets replicated to all other sites of the cnDBTier cluster so that the data is available on all the cnDBTier cluster sites in case of a cnDBTier instance failure. SCP data gets replicated between the georedundant sites by using cnDBtier replication services. cnDBtier can be supported in the following modes:

• Two-site cnDBtier georeplication mode: The database backup from one of the sites can be used for fault recovery of SCP.
• Three-site cnDBTier georeplication mode: The database backup from one of the sites can be used for fault recovery of SCP.
• One-site cnDBTier deployment mode: The georeplication is unavailable.

For more information about database replication in a georedundant environment, see Oracle Communications Cloud Native Core cnDBTier User Guide.

3.52 Automated Test Suite Support

SCP provides Automated Test Suite (ATS) for validating the functionalities. ATS allows you to execute SCP 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. For more information about installing and configuring ATS, see Oracle Communications Cloud Native Core, Automated Testing Suite Guide.