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:
-
Create an override-values.yaml file for the Network Bridge Helm chart.
-
Configure the mandatory values for 5G-to-5G payload conversion.
See "Configuring Mandatory Values for 5G-to-5G Payload Conversion".
-
Configure the Mediation component for 5G-to-5G payload conversion.
See "Configuring the Mediation Component for 5G-to-5G Payload Conversion".
-
Define how to mutate message payloads.
-
(Optional) Define any business rules for modifying messages.
-
(Optional) Configure the Mediation component to support autoscaling.
-
(Optional) Configure your Mediation component for tracing using Jaeger.
-
(Optional) Configure Prometheus to scrape metric data from your Mediation component for display in Grafana Dashboards.
-
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:
|
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:
|
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:
The default is ClusterIP. |
type |
network-bridge-restproxy.rest-proxy.mediation.adminService |
Specifies how the admin service is exposed:
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:
-
KIE processor. See "Configuring a KIE Processor".
-
Mutation processor. See "Configuring a Mutation Processor".
-
REST processor. See "Configuring a REST Processor".
-
gRPC processor. See "Configuring a GRPC Processor".
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:
-
Listen for REST messages from a 5G SBI path.
-
Call kie_processor to convert incoming REST messages according to the DRL files in the /app/config/rules file path.
-
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.
-
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.
-
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:
-
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.
-
Add a rule name and a brief description. For example:
ruleName: "addChargingInfo" ruleDescription: "My new rule adds a field to the JSON body."
-
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".
-
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".
-
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.
-
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.
-
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:
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 |
|
|
JSON Body |
|
|
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:
-
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.
-
In your file, add rules for converting HTTP message payloads based on your business logic.
-
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.
-
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: