3 Data Director Configuration
This chapter lists the Data Director Configuration requirements on Oracle Communications Cloud Native Environment.
Requirements
Before you begin with the procedure for setting up Data Director in Cloud Native Core, ensure that the following requirements are met:
- The metadata from NFs
- The third-party target that receives the packets
- Optional TLS config
- The HTTP standards require a response for every message sent. Oracle will provide a configuration option to ignore the response.
- The message acquisition point is configurable (ingress or egreess, or both) at the NF level
Note:
With the HTTP2 ignore the response option enabled the OCNADD considers message transfer as successful as soon as data is sent to 3rd party monitoring consumers. OCNADD does not wait for 200 OK response to consider the message transfer as successful. Message retransmission is not attempted. However, for maintaining the connection status to 3rd party monitoring App endpoints, OCNADD still expects response for each post request sent to 3rd party monitoring App.
Outbound Protocols
The protocol stack for the message feed is shown in the following figure:
Figure 3-1 Message Feed Protocol Stack
The message feed for monitoring uses HTTP/2 protocol with JSON as the application layer serialization protocol. TLS will be used for the security protection at the transport layer.
Metadata
The following table lists the components that are part of the available metadata from SCP:
Note:
For more information on each metadata component, see Data Stream Contents.Table 3-1 Format based on 3GPP
| Metadata | Information |
|---|---|
| correlation-id |
This is a unique identifier in the message for correlation within a single transaction.
|
| consumer-id |
This is a 5G NF Instance ID of the NF originating the received message.
|
| producer-id |
This is a 5G NF Instance ID of the destination NF.
|
| consumer-fqdn |
This is a FQDN of the network function originating the received message.
|
| producer-fqdn | This is an FQDN of the destination NF. It depends on the presence of FQDN in the authority of service request. |
| hop-by-hop-id | Oracle NFs can add Hop-by-Hop id to identify a request and response pair to the next node. This is required in addition to correlation-id for uniquely identifying the request-response pair in case of re-routing. |
| reroute-cause | Indicate the re-route cause. Contains one of the following:
|
| timestamp | This is a timestamp (in nanoseconds) at the traffic feed trigger point when the message is received or forwarded by the SCP. It is an epoch time. |
| message-direction |
This is a parameter to indicate whether a message is ingress to or egress from NF. It can be indicated by putting the traffic feed trigger point name.
|
| feed-source |
Source of this traffic feed. This contains the key-value of different identity of the node sending the traffic feed.
|
Data Director Message
The 5G SBI message that is received or forwarded contains the following components:
- HTTP2: HTTP2 Headers - All received HTTP2 standard and 3gpp defined headers.
- Received Data Director Message Payload
Data Director Message Format
Figure 3-2 Data Director Message Format
In release 22.0.0, Data Director supports HTTP2 feed for forwarding from Data Director to 3rd party monitoring consumer applications. 5G monitoring data is forwarded to 3rd party monitoring consumer using HTTP2 POST requests. The following components are delivered as JSON payload in the HTTP2 data frames:
- Original received 5G SBI message headers as a header-list.
- Original received 5g sbi data as 5g-sbi-message
- Metadata-list added by NF
The 5g-sbi-message is forwarded to 3rd party consumer application is Base64 encoded if:
- The content-type header in the received 5G SBI message header list is multipart
Or
- The content-encoding in the received 5G SBI message header list indicates compression
If content-type header in the received 5G SBI message header list is multipart, 3rd party consumer application to first apply base64 decode, and then process message further as multipart.
If content-encoding header in the received 5G SBI message header list indicates compression, 3rd party consumer application to first apply base64 decode, and then process the message further based on the content-encoding and content-type in the header-list
Third-Party Feed Format
A third-party feed contains the following components:
Figure 3-3 Third-Party Feed Format
Following TLS options are supported:
- TLSv1.2 (minimum) with oracle approved TLS Ciphers
- TLSv1.2 with Static Key Cipher support (TLS_RSA_WITH_AES_128_GCM_SHA256)
- No TLS (H2C)
Example for the JSON Data
Note:
For more information on the metadata list, see Metadata.Following is an example for the JSON data:
{
"version":"Major.Minor.Patch",
"metadata-list":{},
"header-list":{
":authority":"10.75.224.64:30065",
":method":"PUT",
":path":"/USEast/nudm-uecm/v1/imsi-556670000000000/registrations/amf-3gpp-access",
":scheme":"http",
"content-type":"application/json",
"3gpp-sbi-target-apiroot":"http://udm1svc.default.svc.cluster.local:8080/USEast",
"3gpp-sbi-message-priority":"5",
"content-length":"501",
"accept-encoding":"gzip",
"user-agent":"Go-http-client/2.0"
},
"5g-sbi-message":{
"guami":{
"plmnId":{
"mcc":"233",
"mnc":"23"
},
"amfId":"100000"
},
"pei":"imei-456565651000000",
"attrib1":"abcdefghijklmnopqurestuvwxqweoeqwowertyo123445678",
"attrib2":"abcdefghijklmnopqurestuvwxqweoeqwowertyo123445678",
"attrib3":"abcdefghijklmnopqurestuvwxqweoeqwowertyo123445678",
"attrib4":"abcdefghijklmnopqurestuvwxqweoeqwowertyo432123445678",
"attrib5":"abcdefghijklmnopqurestuvwxqweoeqwowert234yo123445678",
"pcscfRestorationCallbackUri":"http://pcf1.pcf1svc.svc.cluster.local/notification/udmtest"
}
}