17 Connecting ECE to a 5G Client

You can set up 5G network integration for online and offline charging by using the Oracle Communications Elastic Charging Engine (ECE) HTTP Gateway.

Caution:

Deploying charging for 5G with HTTP Gateway (5G CHF) requires a cloud native deployment of ECE and BRM components. The HTTP Gateway can be used only on an ECE cloud native system.

Topics in this document:

About the HTTP Gateway

You integrate 5G clients with ECE by using the HTTP Gateway. The HTTP Gateway sends usage requests to ECE for online and offline charging and then sends responses to the 5G network.

The HTTP Gateway supports the 5G service-based architecture and does the following:

  • Receives ECE REST API requests from 5G clients and then translates them into batch request server (BRS) requests.

  • Determines whether a usage request requires online or offline charging. See "About Determining the Charging Type" for details.

  • Submits BRS requests to the ECE server.

  • Receives responses from the ECE server and then translates them into REST API responses.

  • Responds to the 5G clients.

  • Consumes notifications from the ECE notification topic and then notifies the 5G clients by making a REST call to the URL stored in the system.

  • Publishes details about ECE REST API requests that failed to the ECE failure Kafka topic.

When configured to do so, the HTTP Gateway can also send ECE REST API requests from 5G clients to the CDR Gateway for generating CDRs. For more information, see "Generating CDRs for External Systems".

About Determining the Charging Type

HTTP Gateway determines whether a usage request requires online charging or offline charging as follows:

  • For INITIATE requests, based on the multipleUnitUsage block. If the block is present, the request needs online charging. If the block is missing, the request needs offline charging.

  • For UPDATE requests, based on the value of the quotaManagementIndicator field in the request. If the value is set to ONLINE_CHARGING, the request needs online charging. If the field is missing or the value is set to OFFLINE_CHARGING, the request needs offline charging.

  • For TERMINATE requests, based on the value of the quotaManagementIndicator field in the request. If the value is set to ONLINE_CHARGING, the request needs online charging. If the field is missing or the value is set to OFFLINE_CHARGING, the request needs offline charging.

For more information about these properties, see the Nchf Converged Charging endpoints and Nchf Offline-Only Charging endpoints in REST API for Elastic Charging Engine.

About Sending Notifications to HTTP Gateway

You can configure ECE to send the following notifications to the ECE Notification topic, where they are retrieved by the HTTP Gateway:

  • Spending Limit Notification (SNR): Specifies that a subscriber has reached a spending threshold or limit.

  • Reauthorization Request (RAR): Specifies that a reauthorization request is needed.

Configure HTTP Gateway to consume SNR and RAR notifications from the ECE Notification topic. When configured to do so, HTTP Gateway listens on the ECE Notification topic and filters notifications based on the notification type in the header. Depending on the notification type, HTTP Gateway does the following:

  • Retrieves SNR notifications from the Kafka topic and makes a REST API call to notifUri to post the notification.

  • Retrieves RAR notifications from the Kafka topic and makes a REST API call to post the notification to notifUri in the usage request.

Integrating HTTP Gateway with 5G Networks

To integrate HTTP Gateway with your 5G network:

  1. When you install ECE, do this:

    • Specify to use Apache Kafka topics and enter the details for your ECE notification topic, Suspense topic, ECE failure topic, and ECE overage topic.

    • Enable Network Repository Function (NRF) registration in one of your HTTP Gateway servers.

    • Specify the details for connecting to the BRM Gateway.

    For more information, see "Installing Elastic Charging Engine" in ECE Installation Guide.

  2. During the ECE post-installation process, do this:

    • Run the kafka_post_install.sh script to create your ECE notification topic, Suspense topic, ECE failure topic, and ECE overage topic. See "Creating Kafka Topics for ECE" in ECE Installation Guide.

    • Run the post_Install.sh script and choose to create only the Acknowledgment queue. See "Creating WebLogic JMS Queues for BRM" in ECE Installation Guide.

  3. Configure the NRF registration details for each HTTP Gateway server in your system. See "Configuring Registration Details for the HTTP Gateway Server".

  4. Configure one or more NF services. See "Configuring NF Services".

  5. Configure the HTTP Gateway to send usage requests to ECE Server for convergent charging. See "Configuring HTTP Gateway for Convergent Charging".

  6. Define any custom service-event mappings in Pricing Design Center. See "Enabling Charging for Custom Events" in PDC Creating Product Offerings.

  7. Edit your mediation specification file and load it into ECE. The mediation specification enables the HTTP Gateway to associate each HTTP request with its respective usage-request builder. See "Editing the HTTP Gateway Mediation Specification File".

  8. Connect ECE to your Kafka Server topics. See "Connecting ECE to Kafka Topics".

  9. Configure ECE to send notifications to HTTP Gateway through the ECE notification topic. See "Configuring ECE to Send Notifications to HTTP Gateway".

  10. (Optional) Configure ECE to send information about failed usage requests to the ECE failure topic. See "Recording Failed ECE Usage Requests".

  11. (Optional) Configure ECE to generate CDRs for any prepaid usage overage and send them to the ECE overage topic. See "Configuring ECE to Support Prepaid Usage Overage".

  12. (Optional) Configure your charging function (CHF) operations to route communication through a Services Communication Proxy (SCP). See "Configuring Communication through SCP".

  13. Start your HTTP Gateway. See "Starting the HTTP Gateway".

After the HTTP Gateway is set up, your 5G clients can start:

  • Submitting ECE REST API requests to HTTP Gateway for online or offline charging by ECE. See "Using the ECE REST API".

  • Sending unrated 5G usage events to HTTP Gateway so they can be converted into CDRs and sent to roaming partners, data warehousing system, and legacy billing systems. See "Generating CDRs for External Systems".

Configuring Registration Details for the HTTP Gateway Server

You register the HTTP Gateway server with an NRF by configuring the registration details in JConsole and then starting the HTTP Gateway instance. When it is started, HTTP Gateway automatically sends the registration request to the NRF.

Note:

  • In ECE 12.0 Patch Set 5 and earlier, you can register only one HTTP Gateway server with an NRF. If you try to register multiple servers, HTTP Gateway will throw an error and not start.

  • In ECE 12.0 Patch Set 6 and later, you can register multiple HTTP Gateway servers with an NRF. An HTTP Gateway server can also be registered with multiple NRFs.

To build an NRF registration request for your HTTP Gateway server:

  1. Access the ECE configuration MBeans in a JMX editor, such as JConsole. See "Accessing ECE Configuration MBeans".

  2. Expand the ECE Configuration node.

  3. Expand charging.nfProfileConfigurations.

  4. Expand Attributes.

  5. Specify the registration values for the fields in Table 17-1.

    Table 17-1 Fields for Configuring NRF Registration

    Attribute Name Mandatory Description

    name

    Yes

    The name of the HTTP Gateway instance.

    clusterName

    Yes

    The name of the cluster that the HTTP Gateway belongs to.

    allowedNfDomains No

    The network function (NF) domains that are allowed to access the HTTP Gateway server. Enter a regular expression for the domains according to the ECMA-262 dialect [8].

    If not provided, any NF domain is allowed to access the HTTP Gateway server.

    allowedNfTypes No

    The type of NFs that are allowed to access the HTTP Gateway server, such as AMF or SMF.

    If not provided, any NF type is allowed to access the HTTP Gateway server.

    allowedNssaisSd No

    The S-NSSAI Slice Differentiator (SD) ID of the network slices that are allowed to access the HTTP Gateway server.

    If not provided, any slice is allowed to access the HTTP Gateway server.

    allowedNssaisSst

    No

    The S-NSSAI Slice/Service Type (SST) ID of the network slices that are allowed to access the HTTP Gateway server.

    If not provided, any slice is allowed to access the HTTP Gateway server.

    allowedPlmnsMcc No

    The Mobile Country Code (MCC) of the PLMNs that are allowed to access the HTTP Gateway server.

    If not provided, any PLMN is allowed to access the HTTP Gateway server.

    allowedPlmnsMnc

    No

    The Mobile Network Code (MNC) of the PLMNs that are allowed to access the HTTP Gateway server.

    If not provided, any PLMN is allowed to access the HTTP Gateway server.

    capacity No

    The static capacity information in the range of 0-65535, expressed as a weight relative to other NF instances of the same type. The default is 0.

    If the capacity is also present in the nfServiceList parameters, those will have precedence over this value.

    customInfo No

    The specific data for custom NFs.

    defaultNotificationSubscriptionsCallbackUri No

    The callback URI for the default notification type.

    defaultNotificationSubscriptionsN1MessageClass

    No

    The information element (IE) that is used to identify the class of the N1 message type.

    defaultNotificationSubscriptionsN2InformationClass

    No

    The information element (IE) that is used to identify the class of the N2 message type.

    defaultNotificationSubscriptionsNotificationType

    No

    The type of notification for the corresponding callback URI.

    fqdn Yes

    The FQDN of the HTTP Gateway server.

    For AMF, the FQDN registered with the NRF is the AMF name. For example: chf-demo.novalocal.

    gpsiRangeListEnd No

    The ending range for the list of GPSIs that can be served by the CHF instance. The default is 100008.

    If not provided, the CHF can serve any GPSI.

    gpsiRangeListPattern No

    The pattern for the list of GPSI ranges that can be served by the CHF instance. The default is ^extid-.+@oracle1.com$.

    If not provided, the CHF can serve any GPSI.

    gpsiRangeListStart No

    The starting range for the list of GPSIs that can be served by the CHF instance. The default is 10000.

    If not provided, the CHF can serve any GPSI.

    heartBeatTimer No

    The time, in seconds, between two consecutive heartbeat messages from an NF Instance to the NRF.

    httpGatewayName

    Yes

    The name of the HTTP Gateway that this property configuration belongs to.

    interPlmnFqdn No

    The FQDN that is used for inter-PLMN routing as specified in 3GPP 23.003 [12]. This is required if the HTTP Gateway needs to be discoverable by other NFs in a different PLMN.

    ipv4Addresses No

    The IPv4 addresses of the HTTP Gateway.

    ipv6Addresses No

    The IPv6 addresses of the HTTP Gateway.

    load No

    The current load percentage of the HTTP Gateway, ranging from 0 to 100.

    locality No

    Operator-defined information about the location of the HTTP Gateway instance, such as the geographic location.

    nfProfileChangesInd No

    Whether the IE is absent in the request to the NRF and may be included by the NRF in the NFRegister or NFUpdate response:

    • true: The NF Profile contains changes.

    • false: The complete NF Profile. This is the default.

    nfProfileChangesSupportInd No

    Whether the IE may be present in the NFRegister or NFUpdate request and will be absent in the response:

    • true: The NF Service Consumer supports receiving NF Profile Changes in the response.

    • false: The NF Service Consumer does not support receiving NF Profile Changes in the response. This is the default.

    nfServicePersistence No

    If present, and set to true, it indicates that the different instances of an NF Service in this NF instance, supporting the same API version, can persist their resource state in shared storage. Thus, these resources are available after a new NF service instance supporting the same API version is selected by a NF Service Consumer (see 3GPP 23.527 [27]).

    Otherwise, it indicates that the NF Service Instances of a same NF Service cannot share a resource state inside the NF Instance.

    Possible values are true or false.

    nfStatus Yes

    The status of the HTTP Gateway server:

    • REGISTERED

    • SUSPENDED

    • UNDISCOVERABLE

    The default is REGISTERED.

    nfType Yes

    The type of NF. Set this to CHF.

    Note: ECE supports only CHF.

    nrfHttp2Enable

    No

    Whether the endpoint URL of the NRF registration server (nrfRestEndPointUrl) uses the HTTP/2 protocol:

    • true: The HTTP/2 protocol is used. This is the default.
    • false: The HTTP/1 protocol is used.
    nrfRestEndPointUrl Yes

    The endpoint URL of the NRF registration server. For multiple NRF registration servers, list the endpoint URLs separated by a comma. For example: http://localhost:8080,http://localhost:8081.

    If not provided, NRF URL registration will not occur.

    nsiList No

    The list of Network Slice Instances (NSIs) of the HTTP Gatewy.

    If not provided, the HTTP Gateway can serve any NSI.

    perPlmnSnssaiListPlmnIdMcc

    No

    The Mobile Country Code (MCC) value for plmnSnssai.

    perPlmnSnssaiListPlmnIdMnc

    No

    The Mobile Network Code (MNC) value for plmnSnssai.

    perPlmnSnssaiListSd

    No

    The Slice Differentiator (SD) value for plmnSnssai.

    perPlmnSnssaiListSst

    No

    The Slice/Service Type (SST) value for plmnSnssai.

    plmnListMcc

    No

    The MCC value for plmnList.

    plmnListMnc

    No

    The MNC value for plmnList.

    plmnRangeListEnd

    No

    The ending range for the list of PLMNs (including the PLMN IDs of the CHF instance) that can be served by the CHF instance. The default is 333333.

    If not provided, the CHF can serve any PLMN.

    plmnRangeListPattern

    No

    The pattern for the list of PLMNs (including the PLMN IDs of the CHF instance) that can be served by the CHF instance.

    If not provided, the CHF can serve any PLMN.

    plmnRangeListStart

    No

    The starting range for the list of PLMNs that can be served by the CHF instance. The default is 100000.

    priority

    No

    The priority of this NF service relative to other services of the same type, where lower values indicate higher priority. The value must be in the range of 0-65535. The default is 1.

    Note: The NRF may overwrite the received priority value when exposing an NFProfile.

    recoveryTime

    No

    The timestamp for when the NF was started or restarted, in DateTime format.

    snssaisSdl

    No

    The S-NSSAIs of the NF. When present, this IE represents the list of S-NSSAIs supported in all the PLMNs listed in the plmnList IE.

    If not provided, the NF can serve any S-NSSAI.

    snssaisSst No

    The S-NSSAIs of the NF. When present, this IE represents the list of S-NSSAIs supported in all the PLMNs listed in the plmnList IE.

    If not provided, the CHF can serve any S-NSSAI.

    supiRangeListEnd No

    The end of a list of GPSI ranges that can be served by the CHF instance, such as 1009. The default is 10008.

    If not provided, the CHF can serve any GPSI.

    supiRangeListPattern No

    The pattern for a list of GPSI ranges that can be served by the CHF instance. The default is ^nai-450081.+@.+org$.

    If not provided, the CHF can serve any GPSI.

    supiRangeListStart No

    The start of a list of GPSI ranges that can be served by the CHF instance. The default is 10000.

    If not provided, the CHF can serve any GPSI.

Configuring NF Services

You must configure at least one NF service for HTTP Gateway. By default, HTTP Gateway includes one, but you can add more.

To add or remove an NF service configuration, do this:

  1. Access the ECE configuration MBeans in a JMX editor, such as JConsole.

  2. Expand the ECE Configuration node.

  3. Expand charging.nfServiceConfigurations.

  4. Expand Operations.

  5. Do one of the following:

    • To add an NF service configuration, enter its name and then click addNfServiceConfiguration.

    • To remove an NF service configuration, enter its name and then click removeNfServiceConfiguration.

To configure an NF service, do this:

  1. Access the ECE configuration MBeans.

  2. Expand the ECE Configuration node.

  3. Expand charging.nfServiceConfigurations.Instance_Name.

  4. Expand Attributes.

  5. Specify the NF service configuration values for the attributes in Table 17-2.

    Table 17-2 NF Service Configuration Attributes

    Attribute Name Mandatory Description
    allowedNfDomains No

    The network function (NF) domains that are allowed to access the service instance. Enter a regular expression for the domains according to the ECMA-262 dialect.

    If not provided, any NF domain is allowed to access the service instance.

    allowedNfTypes No

    The type of NFs that are allowed to access the service instance.

    If not provided, any NF type can access the service instance.

    allowedNssaisSd No

    The S-NSSAI Slice Differentiator (SD) ID of the network slices that are allowed to access the service instance.

    If not provided, any slice can access the service instance.

    allowedNssaisSst No

    The S-NSSAI Slice/Service Type (SST) ID of the network slices that are allowed to access the service instance.

    If not provided, any slice can access the service instance.

    allowedPlmnsMcc No

    The Mobile Country Code (MCC) of the PLMNs that are allowed to access the service instance.

    If not provided, any PLMN can access the service instance.

    When included, the allowedPlmns attribute does not need to include the PLMN IDs registered in the plmnList attribute of the NF Profile.

    allowedPlmnsMnc No The Mobile Network Code (MNC) of the PLMNs that are allowed to access the service instance.
    apiFullVersion Yes The full version number of the API as specified in 3GPP 29.501. The default is 1.R15.1.0.
    apiPrefix No The optional path segments used to construct the {apiRoot} variable of the different API URIs.
    apiVersionInUri Yes The version of the service instance to be used in the URI for accessing the API. The default is v1.
    capacity No

    The static capacity information in the range of 0-65535, expressed as a weight relative to other services of the same type. The default is 50.

    The capacity and priority parameters, if present, are used for NF selection and load balancing.

    defaultNotificationSubscriptionsCallbackUri No The callback URI for the default notification type.
    defaultNotificationSubscriptionsN1MessageClass No The information element (IE) that is used to identify the class of the N1 message type.
    defaultNotificationSubscriptionsN2InformationClass No The information element (IE) that is used to identify the class of the N2 message type.
    defaultNotificationSubscriptionsNotificationType No The type of notification for the corresponding callback URI.
    expiry No The expiration date and time of the NF service. The default is 2020-12-01T18:55:08.871Z.
    fqdn No The FQDN of the NF service instance.
    interPlmnFqdn No The FQDN that is used for inter-PLMN routing as specified in 3GPP 23.003. This is required if the service instance needs to be discoverable by other NFs in a different PLMN.
    ipv4Address No

    The IPv4 address.

    ipv6Address No

    The IPv6 address.

    load No

    The current load percentage of the NF service, ranging from 1 through 100. The default is 5.

    name Yes

    The name of the NF service.

    nfServiceStatus Yes

    The status of the NF service instance:

    • REGISTERED

    • SUSPENDED

    • UNDISCOVERABLE

    The default is REGISTERED.

    port No The port number. The default is 0.

    primaryChfServiceInstance

    No

    The specific data for a CHF service instance.

    Include this IE if the CHF service instance serves as a secondary CHF instance of another primary CHF. When present, set it to the serviceInstanceId of the primary CHF service instance.

    priority No

    The priority used for service selection (relative to other services of the same type), ranging from 0 through 65535. Lower values indicate a higher priority. The default is 1.

    The NRF may overwrite the received priority value when exposing an NFProfile with the Nnrf_NFDiscovery service.

    recoveryTime No The timestamp when the NF service was started or restarted. For example, 2019-08-03T18:55:08.871Z.

    The format should be of type DateTime.

    scheme Yes The URI scheme, such as http or https. The default is http.

    secondaryChfServiceInstance

    No

    Include this IE if the CHF service instance serves as a primary CHF instance of another secondary CHF.

    When present, set it to the serviceInstanceId of the secondary CHF service instance.

    Do not set this IE when primaryChfServiceInstance is present.

    serviceInstanceId Yes The unique ID of the service instance within a given NF instance. The default is chf1.
    serviceName Yes

    The name of the service instance:

    • nnrf-nfm

    • nnrf-disc

    • nudm-sdm

    • nudm-uecm

    • nudm-ueau

    • nudm-ee

    • nudm-pp

    • namf-comm

    • namf-evts

    • namf-mt

    • namf-loc

    • nsmf-pdusession

    • nsmf-event-exposure

    • nausf-auth

    • nausf-sorprotection

    • nausf-upuprotection

    • nnef-pfdmanagement

    • npcf-am-policy-control

    • npcf-smpolicycontrol

    • npcf-policyauthorization

    • npcf-bdtpolicycontrol

    • npcf-eventexposure

    • npcf-ue-policy-control

    • nsmsf-sms

    • nnssf-nsselection

    • nnssf-nssaiavailability

    • nudr-dr

    • nlmf-loc

    • n5g-eir-eic

    • nbsf-management

    • nchf-spendinglimitcontrol

    • nchf-convergedcharging

    • nnwdaf-eventssubscription

    • nnwdaf-analyticsinfo

    The default is nchf-convergedcharging.

    supportedFeatures No The supported features of the NF Service instance.
    transport No The transport protocol. The default is TCP.

    httpGatewayName

    Yes

    The name of the HTTP Gateway that this property configuration belongs to.

    clusterName

    Yes

    The name of the cluster that the HTTP Gateway belongs to.

Configuring HTTP Gateway for Convergent Charging

Configure the HTTP Gateway to send usage requests to ECE Server for convergent charging, and to consume SNR and RAR notifications from the ECE notification topic.

To configure the HTTP Gateway for convergent charging:

  1. Access the ECE configuration MBeans in a JMX editor, such as JConsole.

  2. Expand the ECE Configuration node.

  3. Expand charging.httpGatewayConfigurations.

  4. Expand Attributes.

  5. Specify values for the fields in Table 17-3.

    Table 17-3 Fields for Converged Charging

    Name Default Description
    serverSslKeyStore

    "httpGatewayServer.jks"

    The name of the KeyStore file for ECE server.

    serverSslKeyStoreType

    "@ECE_HTTPGATEWAY_KEYSTORE_TYPE@"

    The SSL KeyStore type for ECE server, such as JKS or pkcs12.
    serverSslKeyStoreAlias

    "@ECE_HTTPGATEWAY_KEYSTORE_ALIAS@"

    The alias name for the ECE server SSL KeyStore.
    walletLocation

    "@ECE_WALLET_LOCATION@"

    The path to the ECE wallet.

    snrHttp2Enable

    "true"

    Whether HTTP Gateway uses the HTTP/2 protocol:

    • true: The HTTP/2 protocol is used.
    • false: The HTTP/1 protocol is used.

    retryIntervalInMillis

    "5000"

    The amount of time, in milliseconds, between reconnection attempts to ECE server.

    notificationListenerConnectionPoolSize

    "10"

    The number of threads used by the HTTP Gateway instance for retrieving notifications from the ECE Notification topic.

  6. Expand charging.HttpGatewayConfigurations.name, where name is the name of the HTTP Gateway instance.

  7. Expand Attributes.

  8. Specify values for the fields in Table 17-4.

    Table 17-4 Fields for an HTTP Gateway Instance

    Name Default Description
    name

    "@HTTPGATEWAY_NAME@"

    The name of the HTTP Gateway instance.

    clusterName

    "@CLUSTER_NAME@"

    The name of the cluster that the HTTP Gateway belongs to.

    serverHttp2Enabled

    "@HTTPGATEWAY_HTTP2_ENABLED@"

    Whether ECE Server uses the HTTP/2 protocol:

    • true: The HTTP/2 protocol is used.
    • false: The HTTP/1 protocol is used.
    serverPort

    "@HTTPGATEWAY_SERVER_PORT@"

    The HTTPS port number of the server on which HTTP Gateway resides.

    serverHttpPort

    "@HTTPGATEWAY_SERVER_HTTP_PORT@"

    The HTTP port number of the server on which HTTP Gateway resides.

    serverSslEnabled

    "@HTTPGATEWAY_SERVER_SSL_ENABLED@"

    Whether SSL communication is enabled between your HTTP client and the HTTP Server (true) or not (false).

    processingThreadPoolSize

    "200"

    The number of threads used by the HTTP Gateway instance to process a set of incoming usage requests.

    processingQueueSize

    "32768"

    The number of incoming usage requests that can be processed simultaneously by the HTTP Gateway.

    kafkaBatchSize

    "10"

    The size of the Kafka batch.

    externalTrafficInfo

    ""

    The location of the header URL information.

Editing the HTTP Gateway Mediation Specification File

The mediation specification file enables HTTP Gateway to associate each ECE REST API request with its respective usage-request builder. HTTP Gateway uses the mediation specification to determine which service and event combination applies to an incoming ECE REST API request, enabling it to select the event definition that applies to the event to be rated.

You configure HTTP Gateway to base its selection of event definitions on any combination of the following in the request:

  • Service-Context-Id

  • Service-Identifier

  • Rating-Group

  • Event-Timestamp

From the preceding values, HTTP Gateway derives the following fields, which uniquely identify the event definition to use for building the BRS request for ECE:

  • ProductType (service)

  • EventType

  • Version

To edit the mediation specification:

  1. Create a mediation specification file or edit an existing one.

    A sample mediation specification file is available at ECE_home/sample_data/config_data/specifications/ece_end2end/http_mediation.spec.

    It is recommended to create only one mediation specification file. You can have only one mediation specification loaded in the ECE cluster and the last one loaded takes precedence.

  2. In the mediation specification file, add a row (in the table) for each event to be rated that specifies the following information:

    • Service-Identifier: The Service-Identifier is a place holder.

    • Rating-Group: The Rating-Group value sent in the ECE REST API request.

    • ProductType: The service you have defined for the event.

    • EventType: The event definition you have defined for the event.

    • Version: The version number of the event definition object that you want to apply to the event.

    Define this information for each event definition object defined in the mediation table.

    For each received request, HTTP Gateway correlates the Rating-Group, and Event-Timestamp values (that you defined in the mediation specification) to the usage-request builder that applies to the event to be rated (for the applicable version, service, and event).

  3. (Optional) In the ValidFrom field of the table, set a future date and time when you want HTTP Gateway to recognize a newly deployed event definition object.

    For example, to have requests processed according to a new specification on December 16, 2020, you would enter:

    |   ValidFrom
     | "2020-12-16T12:01:01"

    You can also specify a time zone. For example,

    |   ValidFrom
     | "2020-12-16T12:01:01 PST"

    If a time zone is not sent, the ValidFrom field is set to UTC.

  4. Save the http_mediation.spec file in the directory where you save your configuration data.

  5. Verify that the directory specified in the ECE_home/config/management/migration-configuration.xml file is the directory where you save your configuration data.

  6. Run the configLoader utility:

    start configLoader

    The utility deploys your mediation specification to the ECE cluster. Any earlier mediation specification that was in the ECE cluster is overwritten.

    Any time you deploy a new version of a mediation specification into the repository, HTTP Gateway re-creates its in-memory usage-request builder map and begins using the mapping definitions (to send requests that adhere to the specifications) provided that the validFrom date is reached.

  7. Restart the HTTP Gateway.

  8. Load the mediation specification file into the ECE server by using the configLoader utility.

Connecting ECE to Kafka Topics

You can connect ECE to the following ECE Kafka topics so that ECE can publish notifications, failed usage requests, and CDRs with usage overage information to them:

  • ECE notification topic: Stores notifications from ECE.

  • Suspense topic: Stores failed notifications from ECE.

  • ECE failure topic: Stores details about failed ECE usage requests, such as the user ID and request payload. See "Recording Failed ECE Usage Requests" for more information.

  • ECE overage topic: Stores overage records, which contain details about usage overage amounts for prepaid customers. See "Configuring ECE to Support Prepaid Usage Overage" for more information.

To connect ECE to your Kafka topics:

  1. Access the ECE configuration MBeans in a JMX editor, such as JConsole. See "Accessing ECE Configuration MBeans".

  2. Expand the ECE Configuration node.

  3. Expand charging.kafkaConfigurations.

  4. Expand Attributes.

  5. Specify the Kafka configuration values for the attributes in Table 17-5.

    Table 17-5 kafkaConfiguration Properties

    Property Name Description

    name

    The name of your ECE cluster.

    hostname

    The host name and port number of the machine in which Apache Kafka is installed.

    If it contains multiple Kafka brokers, create a comma-separated list.

    topicName

    The name of the Kafka topic where ECE will publish notifications.

    suspenseTopicName

    The name of the Kafka topic where failed notifications are published.

    failureTopicName

    The name of the Kafka topic where ECE will publish details about failed usage requests.

    overageTopicName

    The name of the Kafka topic where ECE will publish overage records with information about your prepaid customer's usage overage during online sessions.

    partitions

    The number of Kafka partitions in your topics.

    The recommended number to create is calculated as follows:

    [(Max HTTP Gateway Nodes) + (Max Diameter Gateway Nodes * Max Diameter Clients) + (1 for BRM Gateway) + (1 for Internal Notifications)]

    For example, if you have 2 HTTP Gateway nodes, 4 Diameter Gateway nodes, 10 Diameter Gateway clients, and a BRM Gateway, you would need [(2 + (4 * 10) + 1 + 1) = 44 Kafka partitions.

    Arbitrarily, you can set this to a maximum value.

    failurePartitions

    The number of Kafka partitions in your ECE failure topic.

    kafkaProducerReconnectionInterval

    The amount of time, in milliseconds, the Notification Publisher waits before attempting to reconnect to the Kafka topic.

    kafkaProducerReconnectionMax

    The maximum amount of time, in milliseconds, the Notification Publisher waits before attempting to reconnect to a broker that has repeatedly failed to connect.

    The kafkaProducerReconnectionInterval will increase exponentially for each consecutive connection failure, up to this maximum.

    kafkaDGWReconnectionInterval

    The amount of time, in milliseconds, Diameter Gateway waits before attempting to reconnect to the Kafka topic.

    kafkaDGWReconnectionMax

    The maximum amount of time, in milliseconds, Diameter Gateway waits before attempting to reconnect to a broker that has repeatedly failed to connect.

    The kafkaDGWReconnectionInterval will increase exponentially for each consecutive connection failure, up to this maximum.

    kafkaBRMReconnectionInterval

    The amount of time, in milliseconds, BRM Gateway waits before attempting to reconnect to the Kafka topic.

    kafkaBRMReconnectionMax

    The maximum amount of time, in milliseconds, BRM Gateway waits before attempting to reconnect to a broker that has repeatedly failed to connect.

    The kafkaBRMReconnectionInterval will increase exponentially for each consecutive connection failure, up to this maximum.

    kafkaHTTPReconnectionInterval

    The amount of time, in milliseconds, HTTP Gateway waits before attempting to reconnect to the Kafka topic.

    kafkaHTTPReconnectionMax

    The maximum amount of time, in milliseconds, HTTP Gateway waits before attempting to reconnect to a broker that has repeatedly failed to connect.

    The kafkaHTTPReconnectionInterval will increase exponentially for each consecutive connection failure, up to this maximum.

Configuring ECE to Send Notifications to HTTP Gateway

You can enable ECE to send SNR and RAR notifications to the ECE Notification topic, where they will be retrieved by the HTTP Gateway.

To configure

  1. Access the ECE configuration MBeans in a JMX editor, such as JConsole. See "Accessing ECE Configuration MBeans".

  2. Expand the ECE Configuration node.

  3. Expand charging.server.

  4. Expand Attributes.

  5. Set the kafkaEnabledForNotifications property to true.

  6. Expand charging.notification.

  7. Expand Attributes.

  8. Set the rarNotificationMode and spendingLimitNotificationMode properties to one of the following:

    • NONE: ECE does not send this notification type.

    • ASYNCHRONOUS: ECE sends an asynchronous notification to the ECE Notification topic.

      If configured to do so, the HTTP Gateway will consume the notification from the Kafka topic and dispatch it through a REST API call.

Recording Failed ECE Usage Requests

ECE may occasionally fail to process usage requests. For example, a data usage request could fail because a customer has insufficient funds. You can configure ECE to publish details about failed usage requests, such as the user ID and request payload, to the ECE failure topic in your Kafka server. Later on, you can reprocess the usage requests or view the failure details for analysis and reporting.

To enable the recording of failed ECE usage requests:

  1. Access the ECE configuration MBeans in a JMX editor, such as JConsole.

  2. Expand the ECE Configuration node.

  3. Expand charging.kafkaConfigurations.

  4. Expand Attributes.

  5. Set the persistFailedRequestsToKafkaTopic property to true.

Note:

You can also examine the HTTP Gateway log files to determine why a usage request failed. See "Troubleshooting Failed Usage Requests" in BRM System Administrator's Guide for more information.

Configuring Communication through SCP

HTTP Gateway supports the communications models shown in Figure 17-1 for the charging function (CHF) operations.

Figure 17-1 Supported Communication Models for CHF Operations



If your system routes communication between the charging functions (CHF) and other network functions through an Oracle Services Communications Proxy (SCP), perform these steps:

  1. Access the ECE configuration MBeans in a JMX editor, such as JConsole.

  2. Expand the ECE Configuration node.

  3. Expand charging.HttpGatewayConfigurations.

  4. Expand Attributes.

  5. Select scpAuthorities and enter the URL of the primary and secondary SCP authority, delimited by commas. For example: scpAuthorities="scp1.example.com,scp2.example.com".

  6. Expand charging.HttpGatewayConfigurations.name, where name is the name of the HTTP Gateway instance.

  7. Expand Attributes.

  8. Select nrfHeartBeatRetryCount and enter the number of times the heartbeat retries if it fails during registration.

Starting the HTTP Gateway

When the HTTP Gateway starts, it automatically joins the Coherence cluster and gains access to ECE caches and invocation services that it uses to send requests to ECE. At start up, the HTTP Gateway checks for notifications in the ECE Notification topic.

To start the HTTP Gateway:

  1. Ensure that the HTTP Gateway server and other components are started.

  2. Start ECC:

    ./ecc
  3. Start the HTTP Gateway:

    ecc:000> start httpGateway

Using the ECE REST API

After the HTTP Gateway is set up on your system, your 5G clients can start submitting requests to the ECE REST API.

The ECE REST API supports the following CHF operation types:

  • Creating an initial quota reservation for a converged charging session. For example, initially reserving 500 MBytes for a data session.

  • Updating the quota reservation for a converged charging session. For example, reserving an additional 100 MBytes for a data session that is in progress.

  • Releasing the quota reservation when the converged charging session ends.

  • Creating an initial request for an offline-only charging session.

  • Updating a request for an offline-only charging session.

  • Ending an offline-only charging session.

  • Subscribing a customer to spending limit notifications.

  • Updating a customer's spending limit subscription.

  • Unsubscribing a customer from spending limit notifications.

  • Creating a usage consumption resource.

  • Deleting a usage consumption resource.

  • Retrieving a subscriber's current usage consumption.

  • Retrieving the current usage consumption for all subscribers.

For more information about these operation types, see REST API for Elastic Charging Engine.

You make calls to the ECE REST API through Swagger at this URL:

  • For ECE 12.0 Patch Set 4 and later releases:

    https://hostname:serverhttpsPort/openapi-ui/index.html
  • For ECE 12.0 Patch Set 3 and earlier releases:

    https://hostname:serverhttpsPort/swagger-ui.html

where hostname is the host name of the machine on which HTTP Gateway is running, and serverhttpsPort is the port number on the HTTP Gateway server.

Note:

If your system's communication model includes an SCP, include the Authority header in all HTTP requests to the CHF operations. Set the Authority header to the host name and port number of the SCP Authority Server. For example:

Authority: example.com:1534