| Oracle® Communications Service Broker Online Mediation Controller Implementation Guide Release 6.0 Part Number E23527-02 |
|
|
View PDF |
| Oracle® Communications Service Broker Online Mediation Controller Implementation Guide Release 6.0 Part Number E23527-02 |
|
|
View PDF |
This chapter describes how to enable and use degraded mode operation in the Oracle Communications Service Broker.
In an Online Mediation Controller deployment, Service Broker relies on an external online charging system (OCS) to make service authorization decisions and apply activity charges to subscriber accounts.
As network-connected components, Service Broker and the OCS depend upon the proper functioning of the network between them. Network disruption or a hardware failure may affect the ability of users to access network services.
Degraded mode is a Service Broker operating mode that ensures service continuity for end users if the OCS becomes unavailable. When degraded mode is enabled, Service Broker monitors the health of the external OCS. If the OCS becomes unavailable for any reason, Service Broker temporarily assumes the functions of the external OCS.
While acting on behalf of the external OCS, Service Broker applies a default authorization decision to incoming service requests. It also records user activity information, which it stores locally in the form of charging data records (CDRs).
Service Broker uses the CDRs to replay the charging requests to the OCS later, when it is available again. From the point-of-view of the external OCS, degraded mode operation is transparent. The external OCS is unaware whether a particular accounting or charging request reflects current activity or is the result of CDR replay. Accordingly, the OCS requires no special configuration to support degraded mode.
When degraded mode is enabled, Service Broker monitors the availability of the external OCS and automatically assumes the functions of the OCS in response to these events:
The OCS fails to acknowledge or reply to a request during an active session.
The OCS does not reply to a heartbeat check.
When degraded mode is triggered by a failure during an active session, only the affected session is transferred to degraded mode. The active session is processed in degraded mode until completed. Other active sessions and new sessions (except those associated with the same user that is being handled in degraded mode) continue to be handled by the external OCS.
If in-order CDR replay is enabled, any new sessions associated with a user who is already in degraded mode are handled in degraded mode as well. This ensures that the activities recorded in all CDRs for that user are replayed in the order in which they occurred, even if that user is accessing the network from different devices.
If degraded mode is triggered by a heartbeat check failure, Service Broker moves all active sessions to degraded mode and handles new sessions in degraded mode. Meanwhile, Service Broker continues to monitor the availability of the external OCS. When the OCS becomes available again, Service Broker resumes using it for new sessions. Existing sessions continue to be processed in degraded mode until completed.
You can also trigger degraded mode manually. This is useful when you know in advance of system downtime, for example, for planned maintenance.
By default, degraded mode is disabled. That is, Service Broker does not monitor the availability of a remote OCS or automatically assume the OCS role if it becomes unavailable.
To enable degraded mode, you need to configure degraded mode operation settings, along with the settings related to degraded mode in the SSU and IMs that interact with the external OCS, as described in this chapter.
Degraded mode operation relies upon the Subscriber Store (the Service Broker repository of end user information) for certain capabilities. For example, the Subscriber Store enables Service Broker to correlate multiple sessions initiated on different devices to a single actual end user. This allows Service Broker to replay all CDRs associated with a given end user in order, even for sessions that were originated on different devices.
Also, for degraded mode to work properly with orchestrated mediation, Service Broker must be configured to retrieve iFCs from the Subscriber Store. Degraded mode does not work if Service Broker retrieves iFCs using the LSS mechanism. See Oracle Communications Service Broker Subscriber Data User's Guide for information on how to set up the Subscriber Store.
Degraded mode can be used with orchestrated or non-orchestrated charging mediation deployments. In non-orchestrated (passthrough) mediation, incoming Diameter Ro requests bypass orchestration and other mediation processing steps normally applied in the Processing Tier.
The general steps for configuring degraded mode for passthrough mediation are:
Configure CDR persistence.
Configure an outbound route to the local OCS in the Diameter SSU of the Signaling Domain.
Configure local OCS properties, the settings applicable to the internal Service Broker component that performs the function of the external OCS.
Configure the default client authentication decision when Service Broker is acting on behalf of the external OCS.
Configure CDR replay settings.
Configure external OCS monitoring.
Configure service unit counters.
The following sections provide more information on the steps. See "Configuring Degraded Mode for Orchestrated Mediation" for specific information about configuring degraded mode for orchestrated mediation.
You can use either Oracle Berkeley DB or Oracle Database 11g for CDR storage.
The default persistence mechanism is Oracle Berkeley DB storage. To enable Berkeley DB storage, you only need to configure the file storage location. To use Oracle Database 11g, you need to change the persistence package installed in the domain and then configure the database connection settings.
The following steps provide an overview of how to configure CDR persistence. For more information on data storage, see the information on configuring data storage in the Oracle Communications Service Broker Installation Guide.
To use Oracle Database for CDR storage, follow these steps:
Prepare the database for CDR storage by running the following SQL script: degraded_mode_cdr_store.sql.
The script is located in the following directory:
Oracle_home/ocsb60/admin_console/scripts/database
Remove the existing persistence package from the domain. By default, it is the Berkeley DB persistence package:
oracle.ocsb.app.rcc.service.degraded_mode.persistence.bdb
Install the database package in the domain using the following file from the module directory in the Administration Console home:
oracle.ocsb.app.rcc.service.degraded_mode.persistence.database-6.0.0-ver.jar
Ensure that the start level for the package matches that of the following package:
oracle.ocsb.app.rcc.service.degraded_mode.core
Configure the database connection for each Managed Server, as described in the Oracle Communications Service Broker Installation Guide.
For more information on how to perform these steps, see the Oracle Communications Service Broker Installation Guide.
The default persistence package in the domain used for CDR storage is the Berkeley DB file-based persistence package. Therefore, to implement Berkeley DB for CDR storage, you only need to configure the storage location settings for the managed servers in your domain.
See Oracle Communications Service Broker Installation Guide for information on configuring Berkeley DB settings.
To use degraded mode, you need to configure a route to the local OCS. The local OCS is the internal Service Broker component that acts as the proxy for the unavailable OCS when operating in active degraded mode. When degraded mode is active, the SSU directs requests to the local OCS rather than the external OCS.
To configure routing to the local OCS:
In the navigation tree, expand OCSB.
Expand Signaling Tier.
Click the SSU Diameter node.
In the SSU Diameter tab, click the Outbound Destinations subtab.
Click the New button.
In the dialog box, enter values for the following fields:
Name: A name for the local OCS definition in the configuration.
Alias: An alias for the local OCS destination, such as localocs.
Destination Host: The host name of the machine on which the local OCS runs. This should generally be the hostname used to address the Processing Servers in your deployment. For example, us.example.com.
Destination Realm: The destination realm for the local OCS. This should be the destination realm for the Processing Servers in your deployment. For example, ro.server.example.com.
Note:
The destination host and realm you specify in this tab needs to match the value you specify for the local OCS in the Processing Tier configuration (as described in "Configuring Local OCS Properties").Click OK.
The new local OCS configuration appears in the outbound destinations list.
Now configure the peer and route configuration in the SSU, as follows:
In the navigation tree, expand OCSB.
Expand Signaling Tier.
Click the SSU Diameter node.
Click the DIAMETER tab.
With the default node selected, configure the following settings of the General tab:
Realm: The destination realm for the local OCS. This should be the same value as you configured for the Destination Realm for the local OCS, such as ro.server.example.com.
Host: The host name of the machine on which the local OCS runs. This should be the same value as you configured for the Destination Host for the local OCS, such as us.example.com.
Configure other general settings for the route as needed. For more information, see Oracle Communications Service Broker Signaling Domain Configuration Guide.
Click the Routes tab.
Click the Create a new route icon.
Specify the following settings of the new route:
Name: A name for the route configuration.
Action: The routing action to perform for the local OCS. Set to relay.
Realm: The destination realm for the local OCS. This should be the same value as you configured for the destination realm for the local OCS, such as ro.server.example.com.
Application ID: The application ID of the Diameter application. Retain the default, 4, which represents Diameter Ro.
Server: Click the add icon under Server and, in the Server field, specify the host name of the machine on which the local OCS runs. This should be the same value as you configured for the destination host for the local OCS, such as us.example.com.
Click the Peers tab.
Select the Allow Dynamic Peers check box.
Click the Create a new row icon to add a peer definition.
The peer represents the local OCS.
Specify the peer settings as follows:
Address: This should be the local host address, 127.0.0.1.
Host: The host name of the machine on which the local OCS runs. This should be the same value as you configured for the destination host for the local OCS, such as us.example.com.
Port: The number on which the local OCS listens for Diameter traffic, 3588.
Protocol: The network protocol to use for the local OCS, tcp.
The Watchdog check box can remain disabled.
Click OK.
The Signaling Tier is now configured to route Diameter traffic to the local OCS.
The local OCS settings define properties for the Service Broker component that performs the functions of the external OCS when it is unavailable.
This section applies to non-orchestrated, passthrough mediation of charging-related traffic. See "Configuring Degraded Mode for Orchestrated Mediation" for information on orchestrated mediation.
To configure local OCS properties:
In the navigation tree, expand OCSB.
Expand Processing Tier.
Expand Passthrough Mediation.
Click the Degraded Mode node.
In the General tab, specify the following settings:
Local OCS realm: The destination realm for the local OCS, such as ro.server.example.com. This value should reflect the realm for the Processing Servers in the Service Broker deployment.
Local OCS host: The host name of the machine on which the local OCS runs, such as us.example.com. This value should reflect the host name used to address the Processing Servers in the Service Broker deployment.
UserProfile timeout: The time-out value, in milliseconds, for Service Broker access attempts to the Subscriber Store database. This timeout applies only when the Use Global Id in degraded mode value is set to true.
Use Global Id in degraded mode: If true, Service Broker attempts to correlate the network IDs in incoming requests to subscriber global IDs retrieved from the Subscriber Store. This gives Service Broker the ability to perform in-order CDR playback for a given subscriber across different devices.
Click Apply.
Under the Passthrough Mediation node in the navigation tree, click the Routing node.
The routing information enables Service Broker to route Diameter messages by mapping an origin realm to a destination address, the local OCS in this case.
In the Routing tab, configure the following settings:
Local Host: The host name of the machine on which the local OCS runs, such as us.example.com. This value should reflect the host name used to address the Processing Servers in the Service Broker deployment.
Origin Realm: The realm value that identifies requests to be handled in passthrough mode. The default value is aa.origin.realm. A request with any other Origin-Realm value is handled as orchestrated mediation traffic by Service Broker.
Click Apply.
In an Online Mediation Controller implementation, Service Broker can perform the role of a RADIUS server, applying service authorization and authentication decisions to incoming requests. In this role, Service Broker acts as the access enforcement point for network services.
When it receives a user request for a service, Service Broker retrieves the service authorization information for a given user from the external OCS. If the user is authorized to access the service, Service Broker also gets the credentials for that user from the OCS. It uses the credentials to validate those in the incoming request. Service Broker permits or denies access to a service for the user based on the results.
You can configure a default RADIUS authentication decision for Service Broker to apply when it is in active degraded mode, when the external OCS is unavailable.
To configure the default credit authorization decision:
In the navigation tree, expand OCSB.
Expand Processing Tier.
Click RADIUS Mediation.
In the degraded-mode-behavior field, enter one of the following values:
reject: Blocks all requests.
allow: Permits all requests.
discard: Silently discards all requests, which the client typically perceives as a server unavailable error.
Click Apply.
The CDR replay configuration settings determine how Service Broker replays CDRs when an OCS becomes available again after triggering degraded mode has been configured.
This section describes how to configure properties associated with CDR replay. See "Replaying Charging Data Records Manually" for information about how to perform manual CDR replay.
To configure CDR replay behavior:
In the navigation tree, expand OCSB.
Expand Processing Tier.
Expand Applications.
Expand Degraded Mode.
Click the Replay node.
In the Control tab, set the Enable Manual Replay field to either of the following values:
true: Disables automatic CDR replay. In this case, a Service Broker administrator must manually initiate the CDR replay process when an OCS resumes availability.
false: Enables automatic CDR replay. In this case, Service Broker triggers CDR replay when it detects that an OCS has resumed availability.
Click the Replay tab.
In the Replay pane, configure these settings:
Enable In-Order replay: If true, Service Broker ensures that outstanding requests are replayed to the external OCS in the order in which they occurred. With in-order replay, Service Broker takes into account requests in new sessions for the same subscriber. That is, while there are any pending CDRs for a given subscriber, all new sessions for that subscriber are handled in degraded mode to ensure in-order processing of CDRs across devices.
Replay rate: To avoid over-burdening the OCS when it restarts, you can control the rate at which Service Broker submits CDRs to the external OCS using this attribute. This value determines the number of CDRs replayed per second after the OCS resumes operation.
Replay Trigger Interval: The minimum amount of time, in milliseconds, between replay trigger events. You can use this value to pace the replay of CDRs to ensure that the external OCS is not overwhelmed with requests when its service is resumed.
Replay Failure Threshold: The number of timeout events during CDR replay after which Service Broker pauses CDR replay. It resumes CDR replay after the configured interval.
Max number of CDRs to fetch: The maximum number of CDRs retrieved from the data store at one time.
Should delete CDR: Whether Service Broker should delete the CDRs from the CDR store after they have been successfully replayed.
Click Apply to save your changes.
Service Broker monitors an external OCS to determine its availability. You can configure the following aspects of how Service Broker monitors the OCS:
Heartbeat check interval
Error code mappings
The heartbeat interval determines how frequently Service Broker sends a health check message to the external OCS.
To configure the heartbeat check interval, follow these steps:
In the navigation tree, expand the OCSB node.
Expand Processing Tier.
Expand Applications.
Expand Degraded Mode.
Click the Replay node.
In the configuration pane, click the Heartbeat tab.
In the Heartbeat Interval field, enter how frequently, in milliseconds, the degraded mode application checks the health of the external OCS. The default is 10000 milliseconds.
The error code mappings tell Service Broker what type of error response to consider an OCS failure. An OCS can generate various types of error responses. While some types of errors indicate that the OCS is unavailable, others may indicate a client error or other type of error which should not trigger degraded mode operation by Service Broker.
Since error code mappings may be different by back end system, you configure the mapping individually in the configuration of each IM instance that interacts with an external OCS.
To configure error code mappings:
In the navigation tree, expand the OCSB node.
Expand Processing Tier.
Expand Passthrough Mediation.
Click the Ro PCP Mediation node.
Click the Degraded mode tab.
In the BRM error codes field, enter the numeric error response codes that should trigger degraded mode operation by Service Broker.
Use commas to separate the error codes, such as: 27,108.
Verify the Result code value: 90001. This is the value to which the BRM errors identified in BRM error codes are mapped.
Click Apply.
Counters in the Service Broker configuration comprise the network service units that you can adapt to your Diameter application requirements.
By default, the predefined counters are based upon the requested service in the Diameter request. Specifically, they are based on the content of the REQUESTED-SERVICE-UNITS AVP, which can be:
CC-Time is mapped to code 420
CC-Total-Octets is mapped to code 421
CC-Input-Octets is mapped to code 412
CC-Output-Octets is mapped to code 414
CC-Service-Specific-Units is mapped to code 417
To modify the default unit counter configuration:
In the navigation tree, expand OCSB.
Expand Processing Tier.
Expand Applications.
Expand Degraded Mode.
Select LocalOCF.
In the General tab, verify the implementation class that performs service unit calculations. The default is unitCalculatorObjectName. You should modify this value only if you have implemented a custom unit calculator.
Click the Counters tab.
In the Counters pane, modify the default counter configuration by selecting a counter from the list and clicking the Update button.
In the Update dialog box, enter values for these fields:
type: The AVP code number that represents the counter type.
value: The initial unit value for this counter type.
Click OK to save your configuration changes.
Sections "Configuring the Signaling Tier for Degraded Mode" and "Configuring Local OCS Properties" describe how to configure degraded mode for passthrough charging mediation. Alternatively, you can configure degraded mode for orchestrated mediation, in which charging-related traffic is handled by the Orchestration Engine and applicable IMs.
Service Broker supports degraded mode for external systems through the following IM types:
IM-OCF
IM-OCF PCP
IM-OFCF PCP
Configuring degraded mode for orchestrated OCS mediation involves the following general steps:
Add degraded mode settings to the IM that connects to the external OCS
Create an IM-OCF instance for the local OCS
Add a branching condition in the orchestration logic for the IMs that routes messages to one or the other IM based on the degraded mode status of the session.
In addition, you need to configure Diameter connectivity settings in the Signaling Tier domain, along with the orchestration rules for routing traffic to the IMs that interact with the external OCS. See "Setting Up Orchestrated Charging Mediation" for more information. For information on creating and configure IMs, see Oracle Communications Service Broker Processing Domain Configuration Guide.
The following procedure provides an overview of the degraded mode configuration in orchestrated mediation.
To configure degraded mode for orchestrated mediation:
Configure Signaling Tier settings for the local OCS (as described in "Configuring the Signaling Tier for Degraded Mode") and for the external OCS. For more information, see Oracle Communications Service Broker Signaling Domain Configuration Guide.
In the Processing Tier, add degraded mode settings to the IM instance of the external OCS for which you want to configure degraded mode monitoring and failover.
You need to specify settings for each IM you want to enable degraded mode.
To access the degraded mode settings in the IM:
In the Processing Tier tree, expand the Interworking Modules node.
Click the IM instance of the external OCS for which you want to enable degraded mode.
Click the Degraded Mode tab.
Configure the degraded mode settings shown in "Common IM Degraded Mode Settings" as appropriate for the external OCS. For information on the IM configuration, see Oracle Communications Service Broker Processing Domain Configuration Guide.
Create an IM-OCF instance for the local OCS.
In the Degraded Mode tab of the IM-OCF for the local OCS, specify the following settings:
CDR Mode: Set to ALWAYS.
Local-OCF Alias: Set to the alias of the local OCF.
Optionally, configure other degraded mode settings for the IM (as described in "Common IM Degraded Mode Settings").
Add a branching condition to the orchestration logic for the IMs that routes messages to one or the other IM based on the degraded mode status of the session. The status is indicated in degraded mode header of the message.
If the value of this header is true, the iFC should route the message to the IM of the local OCS. If false, it should route the message to the IM of the external OCS.
The IMs that support degraded mode have common configuration settings related to degraded mode operation. This section provides an overview of the common settings. For more information about a particular type of IM, see Oracle Communications Service Broker Processing Domain Configuration Guide.
The common degraded mode IM settings are:
CDR Mode: The mode in which Service Broker writes CDRs to local storage, from these options:
Normal: Service Broker writes CDRs only after it assumes the functions of the external OCS.
History: After it assumes the functions of the external OCS, Service Broker writes CDRs that reflect the history of each active session, including for requests received prior to assuming the active OCS role.
Always: Service Broker writes CDRs always.
CDR Writer Impl: The internal class that performs CDR writing. This can be one of the following values:
oracle.ocsb.app.rcc.ocfproxy.cdrwriter.CDRWriterImpl: Writes CDRs to the degraded mode service. This is the standard implementation to use for degraded mode processing.
com.convergin.common.diameter.ocfproxy.CDRWriterLogImpl: Writes information to the log only. This is useful for testing.
CDR Writer Service The CDR writer service that Service Broker uses, if not the default. This field should remain blank, as it is by default.
Degraded Mode Timer: The period of time, in milliseconds, that Service Broker waits for a response from the online charging server. If the online charging server does not respond within the specified period of time, the user session is switched to degraded mode.
Local-OCF Alias: Specifies the alias of the local OCS. This alias is mapped to the destination host and destination realm of the local online charging server as defined in the configuration of Diameter SSU outbound routing rules. See the discussion of Diameter SSU in Oracle Communications Service Broker Signaling Domain Configuration Guide for more information.
Local-OCF External Protocol: Specifies the protocol that Service Broker uses to communicate with the local online charging server. Default value: Ro
Degraded Mode Error Codes: The error response code from the external OCS that indicates a failure for which degraded mode should be activated. Specify as comma-separated integers.
For example:
5012,5023
To place Service Broker in active degraded mode manually, you need to enable manual triggering of degraded mode operation.
To enable manual triggering of degraded mode, perform the following steps:
In the navigation tree, expand OCSB.
Expand Processing Tier.
Expand Applications.
Expand DegradedMode.
Select Replay.
In the Control tab, set the Enable Manual Degraded Mode value to true.
This enables degraded mode to be activated manually.
If false, degraded mode can only be activated automatically, that is, in response to network events.
Click the Apply button.
After enabling manual degraded mode triggering, you can trigger degraded mode by invoking the markSystemStatusAsDegraded operation in the following runtime MBean:
oracle.ocsb.app.rcc.service.dmode.mbeanDegradedModeMBean
To access the runtime MBean, connect to the managed server JMX process using any JMX client software.
In most deployments, Service Broker will be configured to replay CDRs to the external OCS automatically, when it detects that the OCS has resumed service. Alternatively, you can disable automatic CDR replays, and instead invoke CDR replay manually when needed.
To enable manual replay of CDRs, perform the following steps:
In the navigation tree, expand OCSB.
Expand Processing Tier.
Expand Applications.
Expand DegradedMode.
Select Replay.
In the Control tab, set the Enable Manual Replay value to true.
This disables automatic CDR replay and enables manual replay.
Click the Apply button.
After enabling manual CDR replay, you can trigger CDR replay using the startManualReplay operation in the following runtime MBean:
oracle.ocsb.app.rcc.service.dmode.mbeanDegradedModeMBean
Note that the operation does not replay all outstanding CDRs. It only replays the number of CDRs configured as the maximum number of CDRs to fetch in the replay configuration (1000, by default). To automatically replay all outstanding CDRs, you must create an MBean script that repeatedly invokes the startManualReplay operation.
See "Configuring CDR Replay Behavior" for information on the maximum number of CDRs to fetch setting.
|
 Copyright © 2010, 2012, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|
