1. Network Bridge Cloud Native Installation and Administration Guide
  2. Installing Network Bridge
  3. Configuring Network Bridge for 5G-to-5G Payload Conversion

5 Configuring Network Bridge for 5G-to-5G Payload Conversion

You can configure Oracle Communications Network Bridge to mediate payloads between two 5G Network Functions (NFs). To do so, you create a mutation rules file, configure an override-values.yaml file, and then deploy Network Bridge on a cloud native environment.

Topics in this document:

About Configuring Network Bridge for 5G-to-5G Payload Mediation

You can use Network Bridge to interconnect two 5G NFs that support different payload formats. In this case, Network Bridge acts as an N40 proxy, dynamically transforming HTTP message payloads according to your defined rules.

To configure Network Bridge to mediate payloads between 5G NFs:

  1. Create an override-values.yaml file for the Network Bridge Helm chart.

  2. Configure the mandatory values for 5G-to-5G payload conversion.

    See "Configuring Mandatory Values for 5G-to-5G Payload Conversion".

  3. Configure the Mediation component for 5G-to-5G payload conversion.

    See "Configuring the Mediation Component for 5G-to-5G Payload Conversion".

  4. Define how to mutate message payloads.

    See "Defining Mutation Rules for Payload Conversion".

  5. (Optional) Define any business rules for modifying messages.

    See "Defining Business Rules in DRL Files".

  6. (Optional) Configure the Mediation component to support autoscaling.

    See "Setting up Autoscaling of Network Bridge Pods".

  7. (Optional) Configure your Mediation component for tracing using Jaeger.

    See "Tracing the Flow of API Calls".

  8. (Optional) Configure Prometheus to scrape metric data from your Mediation component for display in Grafana Dashboards.

    See "Monitoring Network Bridge Processes".

  9. Deploy Network Bridge on your cloud native environment.

    See "Deploying Network Bridge".

Configuring Mandatory Values for 5G-to-5G Payload Conversion

To configure Network Bridge for 5G NF to 5G NF payload conversion, set the following keys in your override-values.yaml file for oc-ccs-helm-chart-version. These keys are required to create a simple or demonstration version of Network Bridge that you can use immediately.

These keys apply to all Network Bridge components, but you can override a key's value for a specific component. For example, to use a different pull policy for the Mediation component, set the network-bridge-restproxy.rest-proxy.imagePullPolicy key to another value.

Note:

The &keyName and *keyName values are Helm references. If a key in the values.yaml file includes one of these references, you must also include the reference in your override-values.yaml file. 

imageRepository: &imageRepository "repository.example.com:7840"
imagePullSecrets: &imagePullSecrets regcred
imagePullPolicy: &imagePullPolicy IfNotPresent
protocolTranslationFilePath: &protocolTranslationFilePath "config/protocolTranslation"
nodeSelector: &nodeSelector

partOfLabel: &partOfLabel oc-ccs

loggingPattern: &loggingPattern "%d{ISO8601_OFFSET_DATE_TIME_HHCMM} | %5p | %X{traceId} | %-20.20thread | %-25.25logger{25} | %m%n"

tracingEnabled: &tracingEnabled true
tracingHost: &tracingHost jaeger-all-in-one.jaeger.svc.cluster.local
tracingPort: &tracingPort 14268
serviceMonitorEnabled: &serviceMonitorEnabled true

grafanaDashboardsEnabled: &grafanaDashboardsEnabled true
grafanaNamespace: &grafanaNamespace kube-logging

grafanaDashboards:
  enabled: *grafanaDashboardsEnabled
  grafanaNamespace: *grafanaNamespace
  labels:
    grafana_dashboard: "1"
    release: prometheus
  annotations:
    k8s-sidecar-target-directory: "/tmp/dashboards/ccs"
serviceMonitor:
  enabled: *serviceMonitorEnabled
  namespace:

Table 5-1 describes each key.

Table 5-1 Mandatory Keys for 5G-to-5G Payload Conversion

Key Description

imageRepository

Specifies the registry server where you pushed images, typically in this format: RepoHost:RepoPort.

This value is added as a prefix to all image names when you install or upgrade Helm charts.

imagePullSecrets

Specifies the name of the Secret that contains credentials for accessing images from your private image server. The default is regcred.

The Secret is added to each pod to permit it to pull the image from your private registry server. See "Creating Secrets for Container Registry Authorization" for more information.

imagePullPolicy

Specifies when Kubernetes pulls images:

  • Always: It always pulls an image from the repository.

  • IfNotPresent: It pulls an image only when one does not exist on a node. This is the default.

  • Never: It never pulls the image from the repository.

partOfLabel

Specifies the value to assign to the component's app.kubernetes.io/part-of label. This label identifies the application that the resource belongs to.

nodeSelector

Specifies the nodes on which to deploy Network Bridge components. Labels appear underneath nodeSelector in a set of key-value pairs.

loggingPattern

 Specifies the format and syntax of logs.

tracingEnabled

Specifies whether tracing through Jaeger is enabled.

The default is false.

tracingHost

Specifies the host name for the Jaeger server. The default is jaeger-all-in-one.jaeger.svc.cluster.local.

This key only applies if tracing is enabled.

tracingPort

Specifies the port number for Jaeger. The default is 14268.

This key only applies if tracing is enabled.

serviceMonitorEnabled

Specifies whether to enable a Kubernetes Service Monitor, which can monitor a group of services.

The default is false.

grafanaDashboardsEnabled

Specifies whether to enable Grafana Dashboards for Grafana Operator.

The default is false.

grafanaNamespace

Specifies the namespace on which Grafana is deployed. The default is kube-logging.

This key only applies if Grafana Dashboards are enabled.

grafanaDashboards.labels.grafana_dashboard

Specifies the labels to add to Grafana CRDs. Labels help Grafana discover dashboards. The default is 1.

This key applies only if Grafana Dashboards are enabled.

grafanaDashboards.labels.release

Specifies the release name on which Grafana Operator is deployed. The default is prometheus.

This key only applies if Grafana Dashboards are enabled.

grafanaDashboards.annotations.k8s-sidecar-target-directory

Specifies the directory in which the Grafana Dashboards are deployed. The default is /tmp/dashboards/ccs.

This key only applies if Grafana Dashboards are enabled.

serviceMonitor.namespace

Specifies the namespace in which the Service Monitor is deployed.

This key only applies if Service Monitor is enabled.

Configuring the Mediation Component for 5G-to-5G Payload Conversion

To configure the Mediation component for 5G-to-5G payload conversion, set the following keys in your override-values.yaml file: 

network-bridge-restproxy:
  enabled: true
  # Network Bridge Top Level
  name: network-bridge
  fullname: "network-bridge-restproxy"

  rest-proxy:
    enabled: true
    imageRepository: *imageRepository
    imagePullSecrets: *imagePullSecrets
    imagePullPolicy: *imagePullPolicy
    partOfLabel: *partOfLabel
    mediation:
      name: rest-proxy
      fullname: "rest-proxy"
      additionalLabels: { }
      annotations: { }
      nodeSelector: *nodeSelector
      client:
        connect-timeout-millis: 2000
        read-timeout-millis: 2000
        follow-redirects: true
        max-redirects: 5
        additionalAttributes: { }
      kieRulesConfigMapOverride: MyKieRules
      mutatorRulesConfigMapOverride: MyMutationRules

      restServices:
        - name: "all_sbi"
          config:
            path: "/{:npcf-smpolicycontrol\/v1\/sm-policies($|\/[^/]+\/(update|delete)($|\/$))|nchf-convergedcharging\/v3\/chargingdata($|\/[^/]+\/(update|release)($|\/$))|nchf-convergedcharging\/v3\/notify($|\?notifyUri=.*)}"
          processors:
            - name: "kie_processor"
              type: KIE_PROCESSOR
              config:
                rulesPath: "/app/config/rules"
      grpcServices: [ ]
      container:
        image: *restProxyImage
      terminationGracePeriodSeconds: 60
      resources:
        memoryRequest: "256Mi"
        cpuRequest: "250m"
        memoryLimit: "2048Mi"
        cpuLimit: "500m"
      replicas: 1
      jvmOpts: "-XX:+UseG1GC -XX:MaxGCPauseMillis=50 -XX:InitialRAMPercentage=80 -XX:MaxRAMPercentage=80 -XX:MinRAMPercentage=80 -Dlog4j.configurationFile=config/log4j2.yaml"
      restartCount: 0
      hpa:
        enabled: true
        minReplicas: 1
        maxReplicas: 8
        metrics:
          cpuAverageUtilization: 65
        scaleDown:
          selectPolicy: Max
          stabilizationWindowSeconds: 300
          periodSeconds: 180
        scaleUp:
          selectPolicy: Max
          stabilizationWindowSeconds: 5
          periodSeconds: 20
      service:
        type: ClusterIP
        additionalLabels: { }
        additionalAnnotations: { }
      adminService:
        type: ClusterIP
        additionalLabels: { }
        additionalAnnotations: { }
      logging:
        format:
          type: TEXT
          pattern: *loggingPattern
        rootLevel: INFO
        packageLogging:
          - name: com.oracle.cagbu
            level: INFO
          - name: io.helidon
            level: INFO
          - name: org.jboss
            level: INFO
          - name: io.jaegertracing.internal.reporters
            level: WARN
      tracing:
        enabled: *tracingEnabled
        service: mediation
        maxQueueSize: 42
        flushIntervalMs: 10001
        host: *tracingHost
        port: *tracingPort
        samplerType: ratio
        samplerParam: 0.01
        samplerManager:
        logSpans: true
        webServer:
          spans:
            httpRequest:
              contentWrite: false
              contentRead: false

    grafanaDashboards: *grafanaDashboards
    serviceMonitor: *grafanaDashboards

    ingress:
      ingressClassName:

Table 5-2 describes each key.

Note:

You can also view key descriptions by opening the oc-ccs/charts/oc-network-bridge-0.2.0.tgz/charts/oc-nb-mediation/values.schema.json file in a Markdown viewer.

Table 5-2 Mediation Component Keys

Key Path in values.yaml Description

enabled

network-bridge-restproxy

Specifies whether Network Bridge as a REST proxy is enabled.

The default is true.

name

network-bridge-restproxy

Sets the name of the application. This is used to identify the application in the cluster.

The default is network-bridge.

fullname

network-bridge-restproxy

Sets the full name of the application.

The default is network-bridge-restproxy.

enabled

network-bridge-restproxy.rest-proxy

Enables the Mediation component as a REST Proxy.

The default is true.

imageRepository

network-bridge-restproxy.rest-proxy

Specifies the registry server where you pushed images, typically in this format: RepoHost:RepoPort.

Note: The component uses the global imageRepository setting by default. Set this key only if you want to use a different registry server.

imagePullSecrets

network-bridge-restproxy.rest-proxy

Specifies the name of the Secret that contains credentials for accessing images from your private image server.

Note: The component uses the global imagePullSecrets setting by default. Set this key only if you want to use a different Secret.

imagePullPolicy

network-bridge-restproxy.rest-proxy

Sets when Kubernetes pulls images: Always, IfNotPresent, or Never.

Note: The component uses the global imagePullPolicy setting by default. Set this key only if you want to use a different setting.

partOfLabel

network-bridge-restproxy.rest-proxy

Sets the value to assign to the component's app.kubernetes.io/part-of label. This label identifies the application that the resource belongs to.

Note: The component uses the global partOfLabel setting by default. Set this key only if you want to use a different setting.

name

network-bridge-restproxy.rest-proxy.mediation

Sets the name of the component. This is used to identify the component in the cluster.

The default is rest-proxy.

fullname

network-bridge-restproxy.rest-proxy.mediation

Sets the full name of the component. This name will be used in place of the ReleaseName-Name pattern.

The default is rest-proxy.

additionalLabels

network-bridge-restproxy.rest-proxy.mediation

Specifies the additional labels to add to a Kubernetes custom resource definition (CRD).

annotations

network-bridge-restproxy.rest-proxy.mediation

Specifies the additional annotations to add to a Kubernetes CRD.

nodeSelector

 network-bridge-restproxy.rest-proxy.mediation

Specifies the nodes on which to deploy the mediation component.

Note: The component uses the global nodeSelector setting by default. Set this key only if you want to use a different setting.

client.*

network-bridge-restproxy.rest-proxy.mediation

The details for configuring the client:

  • connect-timeout-millis: Sets the time to wait in milliseconds for a connection to be established with the service. The default is 2000.
  • read-timeout-millis: Sets the time to wait in milliseconds to read a response from the service. The default is 2000.

  • follow-redirects: Enables GET methods to follow redirects provided in the response. The default is true.

  • max-redirects: Sets the maximum number of chained redirects that are allowed. The default is 5.

  • additionalAttributes: Specifies the additional attributes for configuring the web client.

kieRulesConfigMapOverride

 network-bridge-restproxy.rest-proxy.mediation

Specifies the name of the ConfigMap that contains your KIE rule file. If not specified, Network Bridge uses the rules defined in the default KIE rule file. This value applies to KIE_PROCESSOR type processors only.

See "Defining Business Rules in DRL Files" for more information.

mutatorRulesConfigMapOverride

 network-bridge-restproxy.rest-proxy.mediation

Specifies the name of the ConfigMap that contains your mutation rule file. If not specified, Network Bridge uses the rules defined in the default mutation rule file. This value applies to MUTATOR_PROCESSOR type processors only.

See "Defining Mutation Rules for Payload Conversion" for more information.

restServices.*

network-bridge-restproxy.rest-proxy.mediation

Specifies how to process REST service messages.

See "REST Services Configuration for 5G-to-5G Payload Conversion" for more information.

grpcServices.*

network-bridge-restproxy.rest-proxy.mediation

Specifies how to process gRPC service messages.

image

network-bridge-restproxy.rest-proxy.mediation.container

Specifies the name of the REST Proxy image.

Note: The component uses the global restProxyImage setting by default. Set this key only if you want to use a different setting.

terminationGracePeriodSeconds

 network-bridge-restproxy.rest-proxy.mediation

Specifies the amount of time, in seconds, the Mediation pod needs to shut down gracefully.

The value must be a non-negative integer. A value of 0 specifies to terminate immediately, and a nil value specifies to use the default grace period.

The grace period is the duration in seconds after which the processes running in the pod are sent a termination signal. The processes are forcibly halted with a kill signal. Set this value longer than the expected cleanup time for your process.

The default is 60.

resources.*

network-bridge-restproxy.rest-proxy.mediation

Specifies the minimum and maximum amount of memory and CPU that can be used.

See "Setting up Autoscaling of Network Bridge Pods" for more information.

replicas

 network-bridge-restproxy.rest-proxy.mediation

Specifies the desired number of pod replicas.

The default is 1.

This key is ignored if HPA is enabled.

jvmOpts

 network-bridge-restproxy.rest-proxy.mediation

Specifies the JVM options to use when starting the Mediation component.

restartCount

network-bridge-restproxy.rest-proxy.mediation

Specifies the number of times the service has been restarted. Increment this value by 1 and run the Helm upgrade command to force a rolling restart of the Mediation pods.

The default is 0.

hpa.*

network-bridge-restproxy.rest-proxy.mediation

Specifies the minimum and maximum number of pod replicas that can be deployed, the scale-up rules, and the scale-down rules.

See "Setting up Autoscaling of Network Bridge Pods" for more information.

type

 network-bridge-restproxy.rest-proxy.mediation.service

Specifies how the service is exposed:

  • NodePort: Builds on ClusterIP and allocates a port on every node that routes to ClusterIP.
  • ClusterIP: Allocates a cluster-internal IP address for load balancing to endpoints.

The default is ClusterIP.

type

 network-bridge-restproxy.rest-proxy.mediation.adminService

Specifies how the admin service is exposed:

  • NodePort: Builds on ClusterIP and allocates a port on every node that routes to ClusterIP.
  • ClusterIP: Allocates a cluster-internal IP address for load balancing to endpoints.

The default is ClusterIP.

logging.*

network-bridge-restproxy.rest-proxy.mediation

Specifies the logging levels for the Mediation component.

See "Using Network Bridge Logging" for more information.

tracing.*

network-bridge-restproxy.rest-proxy.mediation

Specifies how to set up tracing for the Mediation component.

See "Tracing the Flow of API Calls" for more information.

grafanaDashboards

 network-bridge-restproxy.rest-proxy

Specifies your Grafana Dashboard settings.

Note: The component uses the global grafanaDashboards keys and settings by default. Set this key only if you want to use different settings.

serviceMonitor

 network-bridge-restproxy.rest-proxy

Note: The component uses the global serviceMonitor keys and settings by default. Set this key only if you want to use different settings.

ingressClassName

network-bridge-restproxy.rest-proxy.ingress

Specifies the Class Name for the Ingress Controller.

REST Services Configuration for 5G-to-5G Payload Conversion

You can configure the Mediation component to listen for REST services from a specific URL and then call one or more processors. To do so, add a restServices section under network-bridge-restproxy.rest-proxy.mediation. The restServices section uses this syntax: 

restServices:
  - name: "Example Name"
    config:
      path: "*"
    processors:
      - ProcessorN
      - ProcessorN
      - ProcessorN
      ...

Replace ProcessorN with the keys for one or more of these processor types:

For an example of how to configure this section, see "Example Processor Configuration for REST Services".

Configuring a KIE Processor

You use a KIE processor to convert REST messages according to the rules defined in a DRL file. You configure the KIE processor by using these keys in the restServices.processors section of your override-values.yaml file: 

- name: "kie_processor"
  type: KIE_PROCESSOR
  config:
    rulesPath:"/app/config/rules"

where:

  • name: Specifies the name of the KIE processor instance.

  • config.rulesPath: Specifies the system path to your DRL business rule files.

Configuring a Mutation Processor

You use a Mutation processor to transform REST request and response messages according to the rules defined in a mutation rule file. You configure the processor by using these keys in the restServices.processors section of your override-values.yaml file: 

- name: mutation-response
  type: MUTATOR_PROCESSOR
  config:
    rulesPath: "src/test/resources/mutation/rules"
    ruleNames:
     - reWriteResponse

where:

  • name: Specifies the name of the mutation processor instance.

  • config.rulesPath: Specifies the file system path that contains your mutation rule file.

  • config.ruleNames: Specifies the names of one or more rules to run against incoming REST messages. The listed names must match the rule names in your mutation rule file.

Configuring a REST Processor

You use a REST processor to optionally add a header to REST messages before sending them to a specified URI.

You can also add fault tolerance to the REST processor, which is achieved through a combination of retries and a circuit breaker. Retries automatically attempt to run the processor multiple times if it fails to respond. For example, if a REST processor request fails due to a temporary error, the processor can retry the call after a specified interval to check if the error has been resolved. Retries can increase the chances of successfully calling the service and reduce the overall impact of temporary errors.

The circuit breaker prevents cascading processor failures by automatically failing fast when a processor fails too often. The circuit breaker monitors the health of a processor by tracking the number of failures the processor encounters. If the number of failures exceeds a threshold, the circuit breaker trips, and all subsequent calls to the processor fail automatically without actually trying to run the processor. This prevents further failures and allows the system to recover more quickly. After a specified period of time, the circuit breaker is reset, and processor calls are allowed to go through.

You define the REST processor by using these keys in the restServices.processors section of your override-values.yaml file: 

- name: sample-rest-processor
  type: REST_PROCESSOR        
  config:           
    uri: "http://sample.example.com"     
    destUriHeader: dest_uri   
  faultTolerance:     
    retry: 
      delay: 5       
      calls: 3
      delayFactor: 1.0
    circuitBreaker: 
      delay: 500
      errorRatio: 20       
      successThreshold: 10
      volume: 2

where:

  • name: Specifies the name of the REST processor instance.

  • config.uri: Specifies the URI to send messages to.

  • config.destUriHeader: Sets the metadata parameter that indicates the host to send REST requests to.

  • faultTolerance.retry.delay: Sets the duration, in milliseconds, to wait before retrying the process in case of failure.

  • faultTolerance.retry.calls: Sets the maximum number of times to retry the process in case of failure.

  • faultTolerance.retry.delayFactor: Sets the multiplication factor of delay between two consecutive retries.

  • faultTolerance.circuitBreaker.delay: Sets the duration, in milliseconds, to wait before retrying the process in case of failure.

  • faultTolerance.circuitBreaker.errorRatio: Specifies the percentage of failures that will open the circuit breaker.

  • faultTolerance.circuitBreaker.successThreshold: Specifies the number of successful calls that will close a half-open breaker.

  • faultTolerance.circuitBreaker.volume: Specifies the size of the processing window.

Configuring a GRPC Processor

You use a gRPC processor to convert REST messages into an internal gRPC format for intercomponent communication.

Note:

This processor is not typically needed for 5G-to-5G payload conversion.

You configure the gRPC processor by using these keys in the restServices.processors section of your override-values.yaml file: 

- name: "grpc"
  type: GRPC_PROCESSOR
  config:
    host: "egress"
    port: 1408

where:

  • name: Specifies the name of the gRPC processor instance.

  • config.host: Specifies the host name of the server to send messages to.

  • config.port: Specifies the port to send messages to.

Example Processor Configuration for REST Services

The following example processor configuration for REST services specifies to do the following:

  1. Listen for REST messages from a 5G SBI path.

  2. Call kie_processor to convert incoming REST messages according to the DRL files in the /app/config/rules file path.

  3. Call mutation-request to mutate incoming REST messages by applying the addChargingInfo and addHeaders rules from the mutation rule file stored in src/test/resources/mutation/rules.

  4. Call sample-rest-processor to add the destination:dest_uri header to messages before sending them to the http://sample.example.com server. If a call to the server fails, sample-rest-processor will retry the call up to three times, five milliseconds apart.

  5. When processing response messages from the 5G NF, call mutation-response to mutate REST messages by applying the reWriteResponse rule from the mutation rule file stored in src/test/resources/mutation/rules. 

restServices:
  - name: "all_sbi"
    config:
      path: "/{:npcf-smpolicycontrol\/v1\/sm-policies($|\/[^/]+\/(update|delete)($|\/$))|nchf-convergedcharging\/v3\/chargingdata($|\/[^/]+\/(update|release)($|\/$))|nchf-convergedcharging\/v3\/notify($|\?notifyUri=.*)}"
    processors:
      - name: "kie_processor"
        type: KIE_PROCESSOR
        config:
          rulesPath:"/app/config/rules"  
     - name: mutation-request
       type: MUTATOR_PROCESSOR
       config:
          rulesPath: "src/test/resources/mutation/rules"
          ruleNames:
           - addChargingInfo
           - addHeaders
      - name: sample-rest-processor
        type: REST_PROCESSOR        
        config:           
          uri: "http://sample.example.com"           
          destUriHeader: dest_uri         
        faultTolerance:           
          retry:             
            delay: 5             
            calls: 3
            delayFactor: 1.0
      - name: mutation-response
        type: MUTATOR_PROCESSOR
        config:
          rulesPath: "src/test/resources/mutation/rules"
          ruleNames:
           - reWriteResponse

Defining Mutation Rules for Payload Conversion

For 5G-to-5G payload conversion, you create a mutation rule file that defines:

  • The criteria that the HTTP message must meet to be transformed. If you include multiple requirements, the message must meet them all to be transformed.

  • The transformation to perform on the HTTP message, such as changing a field in the request header or JSON body.

Note:

To configure Network Bridge as an N40 proxy, you must add three rules with the following names to the file: addChargingInfo, addHeaders, and reWriteResponse.

To define the rules for 5G payload conversion:

  1. Create a mutation rule file in YAML format and open it in a text editor.

    Alternatively, you can start with the example oc-ccs/charts/oc-network-bridge-0.2.0.tgz/charts/oc-nb-mediation/data/mutation-rules/exampleRule.yaml file.

  2. Add a rule name and a brief description. For example:

    ruleName: "addChargingInfo"
ruleDescription: "My new rule adds a field to the JSON body."

  3. Add a criterion section that defines one or more criteria that an HTTP message must meet. To specify that all HTTP messages meet the requirements, leave the criterion section empty.

    For example, this shows a simple criterion section that requires a message to contain a POST HTTP method: 

    criterion:
   value:      
      method:        
         criteriaType: EQUAL        
         value: POST

    For more information, see "Configuring the Criterion Section".

  4. Add a mutation section that specifies how to transform the HTTP message.

    For example, this shows a simple mutation section that modifies the JSON body by changing the ratingGroup value to 15. 

    mutation:
  json:    
    body:      
    - mutationType: JSON_PATCH 
      jsonPatch:          
      - op: replace 
        path: /multipleUnitUsage/ratingGroup 
        value: "15"

    For more information, see "Configuring the Mutation Section".

  5. Save and close the file.

    For more information about configuring the mutation rule file, see "Example Mutation Rule File".

    You can also view descriptions of each key in the mutation rule file by opening the oc-ccs/charts/oc-network-bridge-0.2.0.tgz/charts/oc-nb-mediation/mutator.rules.schema.json file in a Markdown viewer.

  6. Create a ConfigMap from your mutation rule file by running this command:

    kubectl create configmap ConfigMapName --from-file=Path

    where ConfigMapName is your desired name for the ConfigMap, and Path is the directory that contains the mutation rule file.

  7. Configure Network Bridge to use your mutation rule file by doing the following in your override-values.yaml file:

    • Set the network-bridge-restproxy.rest-proxy.mediation.mutatorRulesConfigMapOverride key to ConfigMapName.

      This configures Network Bridge to use your mutation rule file for all MUTATOR_PROCESSOR type processors.

    • Ensure you add a section to your override-values.yaml file for calling a MUTATOR_PROCESSOR type processor when processing REST services. For more information, see "Configuring a Mutation Processor".

Configuring the Criterion Section

The criterion section specifies the fields and values the HTTP message must contain to qualify for transformation. The criteria can include a required value for a single field, a required key-value pair for a field, or a value for a JSON field.

The criterion section uses the following syntax: 

criterion:
   GroupType
   GroupType
   ...

Replace GroupType with one or more of the following group types:

  • value: Requires a URI, method, or status code to match a single string value. For example, requiring a message to contain a URI of https://hostname:httpsPort/nchf-convergedcharging/v3/chargingdata. The value group type uses this syntax: 

    value:      
   ValueObject:        
      criteriaType: CriteriaType        
      value: Value

    where:

    • ValueObject is one of these: uri, method, or statusCode.

    • CriteriaType specifies the criteria type. Supported values are EQUALS, EQUALS_IGNORE_CASE, NOT_EQUALS, NOT_EQUALS_IGNORE_CASE, IS_NOT_NULL, IS_NULL, and REGEX.

    • Value specifies the required value.

  • keyValue: Requires a header or query parameter to contain a specified key-value pair, such as a message must include Accept-Language:en-US in its header. The keyValue group type uses this syntax: 

    keyValue:      
   MapName:        
   - criteriaType: CriteriaType          
     key: KeyName          
     value: Value

    where:

    • MapName is either headers or queryParams.

    • CriteriaType specifies the criteria type. Supported values are EQUALS, EQUALS_IGNORE_CASE, NOT_EQUALS, NOT_EQUALS_IGNORE_CASE, IS_NOT_NULL, IS_NULL, and REGEX.

    • KeyName specifies the required key.

    • Value specifies the required value.

  • json: Requires a JSON path to match a string value, such as the message body must contain a JSON path of $.SequenceNumber. The json group type uses this syntax: 

    json:      
   body:        
   - criteriaType: CriteriaType          
     value: MatchValue

    where:

    • CriteriaType specifies the criteria type. Supported values are REGEX and JSON_PATH.

    • Value specifies the required JSON string value.

Table 5-3 describes each criteria type.

Table 5-3 Criteria Types

Criteria Type Description Supported Group Types

EQUALS

The value must match, and the value is case-sensitive.

value

keyValue

EQUALS_IGNORE_CASE

The value must match, and the value is not case-sensitive.

value

keyValue

NOT_EQUALS

The value must not match, and the value is case-sensitive.

value

keyValue

NOT_EQUALS_IGNORE_CASE

The value must not match, and the value is not case-sensitive.

value

keyValue

IS_NOT_NULL

The value is not null.

value

keyValue

IS_NULL

The value is null.

value

keyValue

REGEX

The value must match the specified regular expression.

value

keyValue

json

JSON_PATH

The JSON string must contain the specified JSON_PATH.

json

Configuring the Mutation Section

The mutation section specifies how to transform an HTTP message, such as by adding, replacing, or removing fields in the request URL and body. It uses the following syntax: 

mutation:
   GroupType
   GroupType
   ...

Replace GroupType with one or more of the following:

  • value: Modifies a single string value in a URI, method, or status code. For example, by changing the HTTP method to PUT. The value group type uses this syntax: 

    value:
  ValueObject:
    mutationType: MutationType
    value: Value

    where:

    • ValueObject is one of these: uri, method, or statusCode.

    • MutationType specifies the transformation to make. Supported values are REPLACE and REGEX_REPLACE.

    • Value specifies the new value.

  • keyValue: Modifies a key-value pair in a header or query parameter, such as by adding Authority: example.com:1534 to the header. The keyValue group type uses this syntax: 

    keyValue:      
   MapName:        
   - mutationType: MutationType
     key: KeyName
     value: Value

    where:

    • MapName is either headers or queryParams.

    • MutationType specifies the transformation to make. Supported values are REPLACE, ADD, COPY, and DELETE.

    • KeyName specifies the key on which to act.

    • Value specifies a new or modified value.

  • json: Modifies a specified string in the JSON body, such as by adding or changing a field. 

    json:
   body:
   - mutationType: MutationType
     MutationSpecificParameters

    where:

    • MutationType specifies the transformation to make. Supported values are REGEX_REPLACE, DELETE, JSON_PATCH, JSON_PATH, and REPLACE_JSON.

    • MutationSpecificParameters specifies more information about the transformation. The fields in this section are dependent on the mutation type.

Table 5-4 describes each mutation type.

Table 5-4 Mutation Types

Mutation Type Description Supported Group Types

REPLACE

Replaces an existing key's value with a new value.

value

keyValue

REGEX_REPLACE

Replaces a value based on the specified regular expression.

value

json

ADD

Adds a key-value pair to the header or query parameter.

keyValue

COPY

Copies one key to another key with the same value.

keyValue

DELETE

Removes a key-value pair or JSON parameter.

keyValue

json

JSON_PATCH

Performs the specified operation on the JSON body. It includes these parameters:

  • op: The operation to perform on the JSON field: add, copy, test, remove, replace, or move.
  • path: Specifies the location in the JSON body to change.
  • value: Specifies the value.

For more information, see RFC 6902.

json

JSON_PATH

Performs a JSON path mutation.

For more information, see JsonPath on the GitHub website: https://github.com/json-path/JsonPath.

json

REPLACE_JSON

Replaces the entire JSON body with the new values.

json

Example Mutation Rule File

The following shows a sample mutation rule file for updating the request header and JSON body in an incoming HTTP message:

ruleName: "Sample Rule"
ruleDescription: "This sample rule updates the request header and adds a field to the JSON body"
criterion:
  json:
    body:
      - criteriaType: "JSON_PATH"
        value: "$.invocationSequenceNumber"
mutation:
  keyValue:
    headerMap:
      - mutationType: REPLACE
        key: location
        value: https://new.example.com
      - mutationType: ADD
        key: HTTP2-Settings
        value: token64
  json:
    body:
      - mutationType: JSON_PATCH
        jsonPatch:
          - op: add
            path: /multipleUnitInformation/ratingStamp
            value: "Gold"

In this example, Network Bridge would check if an incoming HTTP message includes an invocationSequenceNumber field or array in its JSON body. If an HTTP message meets the criteria, Network Bridge would do the following:

  • Replace the value of the location header field with https://new.example.com.

  • Add the HTTP2-Settings header field with the value set to token64.

  • In the JSON body, add the ratingStamp field set to Gold in the multipleUnitInformation array. If the body doesn't contain the multipleUnitInformation array, it would be added.

Table 5-5 shows a sample HTTP message before and after it has been mutated by Network Bridge using the sample rules. The fields that have been changed or added are shown in bold.

Table 5-5 Sample HTTP Message Mutation

HTTP Message Part Before Mutation After Mutation

Header

 
connection: keep-alive
content-length: 154
content-type: application/json
location: https://original.example.com
date: Tue, 12 Jul 2024 08:21:13 +0530
 
connection: keep-alive
content-length: 154
content-type: application/json
location: https://new.example.com
HTTP2-Settings: token64
date: Tue, 12 Jul 2024 08:21:13 +0530

JSON Body

 
{
   "invocationTimeStamp": "2024-7-11T13:00:33.882+05:30",
   "invocationSequenceNumber": 1,
   "multipleUnitInformation": [
      {
         "resultCode": "SUCCESS",
         "ratingGroup": 10,
         "grantedUnit": {},
         "validityTime": 3600
      }
   ]
}
 
{
   "invocationTimeStamp": "2024-7-11T13:00:33.882+05:30",
   "invocationSequenceNumber": 1,
   "multipleUnitInformation": [
      {
         "resultCode": "SUCCESS",
         "ratingGroup": 10,
         "grantedUnit": {},
         "validityTime": 3600,
         "ratingStamp": "Gold"
      }
   ]
}

Defining Business Rules in DRL Files

Creating DRL files allows you to customize how Network Bridge transforms 5G message payloads.

To define business rules for 5G payload conversion:

  1. Create a DRL file that applies rules on HTTP messages.

    For information about creating DRL files, see the Drools documentation at: https://docs.drools.org/8.44.0.Final/drools-docs/drools/introduction/index.html.

  2. In your file, add rules for converting HTTP message payloads based on your business logic.

  3. Create a ConfigMap from your DRL file by running this command:

    kubectl create configmap ConfigMapName --from-file=Path

    where ConfigMapName is your desired name for the ConfigMap, and FilePath is the directory that contains the DRL file.

  4. In your override-values.yaml file, set the network-bridge-restproxy.rest-proxy.mediation.kieRulesConfigMapOverride key to ConfigMapName.

    This configures Network Bridge to use your DRL file for all KIE_PROCESSOR type processors.

Sample N40 Proxy Configuration

The following shows sample override-values.yaml entries for configuring Network Bridge as an N40 proxy, with tracing, autoscaling, and monitoring through Prometheus and Grafana all enabled.

Note:

The &keyName and *keyName values are Helm references. If a key in the values.yaml file includes one of these references, you must also include it in your override-values.yaml file. 

imageRepository: &imageRepository repository.example.com:7840
imagePullSecrets: &imagePullSecrets regcred
imagePullPolicy: &imagePullPolicy IfNotPresent

partOfLabel: &partOfLabel network-bridge-restproxy
nodeSelector: &nodeSelector
#Sample:
#   key: value

loggingPattern: &loggingPattern "%d{ISO8601_OFFSET_DATE_TIME_HHCMM} | %5p | %X{traceId} | %-20.20thread | %-25.25logger{25} | %m%n"

tracingEnabled: &tracingEnabled true
tracingHost: &tracingHost jaeger-all-in-one.jaeger.svc.cluster.local
tracingPort: &tracingPort 14268
serviceMonitorEnabled: &serviceMonitorEnabled true

grafanaDashboardsEnabled: &grafanaDashboardsEnabled true
grafanaNamespace: &grafanaNamespace kube-logging

grafanaDashboards:
  enabled: *grafanaDashboardsEnabled
  grafanaNamespace: *grafanaNamespace
  labels:
    grafana_dashboard: "1"
    release: prometheus
  annotations:
    k8s-sidecar-target-directory: "/tmp/dashboards/ccs"
serviceMonitor:
  enabled: *serviceMonitorEnabled
  namespace: SmNameSpace

network-bridge-restproxy:
  enabled: false
  restProxyImage: &restProxyImage "ccs/network-bridge/mediation:2.0.0"
  # Network Bridge Top Level
  name: network-bridge
  fullname: "network-bridge-restproxy"

  rest-proxy:
    enabled: true
    imageRepository: *imageRepository
    imagePullSecrets: *imagePullSecrets
    imagePullPolicy: *imagePullPolicy
    partOfLabel: *partOfLabel
    mediation:
      name: rest-proxy
      fullname: "rest-proxy"
      additionalLabels: { }
      annotations: { }
      nodeSelector: *nodeSelector
      client:
        connect-timeout-millis: 2000
        read-timeout-millis: 2000
        follow-redirects: true
        max-redirects: 5
        additionalAttributes: { }
      kieRulesConfigMapOverride: MyKieRules
      mutatorRulesConfigMapOverride: MyMutationRules
      restServices:
        - name: "all_sbi"
          config:
            path: "/{:npcf-smpolicycontrol\/v1\/sm-policies($|\/[^/]+\/(update|delete)($|\/$))|nchf-convergedcharging\/v3\/chargingdata($|\/[^/]+\/(update|release)($|\/$))|nchf-convergedcharging\/v3\/notify($|\?notifyUri=.*)}"
          processors:
            - name: "kie_processor"
              type: KIE_PROCESSOR
              config:
                rulesPath:"/app/config/rules"  
            - name: mutation-request
              type: MUTATOR_PROCESSOR
              config:
                rulesPath: "src/test/resources/mutation/rules"
                ruleNames:
                  - addChargingInfo
                  - addHeaders
            - name: sample-rest-processor
              type: REST_PROCESSOR        
              config:           
                uri: "http://sample.example.com"           
                destUriHeader: dest_uri         
              faultTolerance:           
                retry:             
                delay: 5             
                calls: 3
                delayFactor: 1.0
            - name: mutation-response
              type: MUTATOR_PROCESSOR
              config:
                rulesPath: "src/test/resources/mutation/rules"
                ruleNames:
                  - reWriteResponse
      grpcServices: [ ]
      container:
        image: *restProxyImage
      terminationGracePeriodSeconds: 60
      resources:
        memoryRequest: "256Mi"
        cpuRequest: "250m"
        memoryLimit: "2048Mi"
        cpuLimit: "500m"
      replicas: 1
      jvmOpts: "-XX:+UseG1GC -XX:MaxGCPauseMillis=50 -XX:InitialRAMPercentage=80 -XX:MaxRAMPercentage=80 -XX:MinRAMPercentage=80 -Dlog4j.configurationFile=config/log4j2.yaml"
      restartCount: 0
      hpa:
        enabled: true
        minReplicas: 1
        maxReplicas: 8
        metrics:
          cpuAverageUtilization: 65
        scaleDown:
          selectPolicy: Max
          stabilizationWindowSeconds: 300
          periodSeconds: 180
        scaleUp:
          selectPolicy: Max
          stabilizationWindowSeconds: 5
          periodSeconds: 20
      service:
        type: ClusterIP
        additionalLabels: { }
        additionalAnnotations: { }
      adminService:
        type: ClusterIP
        additionalLabels: { }
        additionalAnnotations: { }
      logging:
        format:
          type: TEXT
          pattern: *loggingPattern
        rootLevel: INFO
        packageLogging:
          - name: com.oracle.cagbu
            level: INFO
          - name: io.helidon
            level: INFO
          - name: org.jboss
            level: INFO
          - name: io.jaegertracing.internal.reporters
            level: WARN
      tracing:
        enabled: *tracingEnabled
        service: mediation
        maxQueueSize: 42
        flushIntervalMs: 10001
        host: *tracingHost
        port: *tracingPort
        samplerType: ratelimiting
        samplerParam: 1
        samplerManager:
        logSpans: true
        webServer:
          spans:
            httpRequest:
              contentWrite: false
              contentRead: false

    grafanaDashboards:
      enabled: *grafanaDashboardsEnabled
      grafanaNamespace: *grafanaNamespace
      labels:
        grafana_dashboard: '1'
        release: prometheus
      annotations:
        k8s-sidecar-target-directory: "/tmp/dashboards/ccs"

    serviceMonitor:
      enabled: *serviceMonitorEnabled
      namespace:

    ingress:
      ingressClassName: