|
|
The usage cost model for Oracle Communications Services Gatekeeper is based on the idea of the transaction unit. This book describes how transaction categories are monitored and how transaction units are calculated.
Usage costs for Oracle Communications Services Gatekeeper are based on the rate (measured in transaction units per second or TUPS) during a specific time period per 24-hour interval. As Oracle Communications Services Gatekeeper runs, it continuously counts the number of transactions it processes. Every 5 minutes that count is stored. After 24 hours of use, the busiest 60 minute window (the busy hour) is identified and the total number of transaction units processed in that period is divided by 3600. This computed busy hour forms the basis of the cost of using Oracle Communications Services Gatekeeper.
| Note: | Transaction units are based on statistics collected by the statistics service. By default, the system simply keeps track of usage for auditing purposes, but if an operator wishes to monitor usage more closely, it is possible to use OAM to set thresholds to raise alarms if certain usage levels are reached. For more information on setting alarms, see “Managing and Configuring Transaction Licenses” in System Administrator’s Guide, another document in this set. |
What specifically constitutes a transaction unit is based on the type of functionality being measured. Sending an SMS is not the same as setting up a call between two parties. In general, the Oracle Communications Services Gatekeeper model is arranged in a tiered manner, using two large transaction categories, Base Platform and Oracle Module. Usage monitoring is based on the TUPS rates associated with these two transaction categories. For more information, see Transactions - Categories and Units.
| Note: | In application-initiated scenarios, transaction units are logged only if Oracle Communications Services Gatekeeper returns an OK to the application. If there is an exception, no transaction unit is recorded. In network-triggered scenarios, transaction units are logged only if Oracle Communications Services Gatekeeper returns an OK to the network. If there is an exception, no transaction unit is recorded. |
Oracle Communications Services Gatekeeper keeps track of transaction units at two basic levels:
The larger and more general rate category is Base Platform TUPS. The Base Platform TUPS rate is the sum of the TUPS limits for Platform Services and Custom Modules plus that for Oracle Modules.
Platform Services covers general services that can be used by multiple capabilities.
A Subscriber Profile transaction unit is recorded in the following situations:
A Callable Policy transaction unit is recorded in the following situation:
These services support application-initiated requests only.
Network-triggered scenarios are not applicable for subscriber profile or callable policy.
Custom Modules covers communication services or custom modules created using Oracle Communications Services Gatekeeper’s Platform Development Toolkit.
In general there are two main types of custom module transactions:
A transaction unit for a custom module application-initiated scenario:
Oracle Communications Services Gatekeeper processes a request that is submitted by the application and passes it to the underlying network node and then Oracle Communications Services Gatekeeper processes the response that is submitted by the underlying network node and passes it to the application.
| Note: | The exact sequence of request and response is defined during the custom module development process. |
Figure 1 illustrates when a generic custom module application-initiated transaction unit is logged. The illustrated operations are generic and abstract and would depend on which application-facing interface and/or network protocol the communication service is using.
A transaction unit for a custom module network-triggered scenario:
Oracle Communications Services Gatekeeper processes a request that is submitted by the telecom network node and passes it on to the application, which processes it and returns a response to Oracle Communications Services Gatekeeper, which passes it on to the telecom network node.
Figure 2 illustrates when a generic custom module network-triggered transaction unit is logged. The illustrated operations are generic and abstract and would depend on which application-facing interface and/or network protocol the communication service is using.
The second rate category is Oracle Module TUPS. The Oracle Module TUPS rate measures the total transaction rate for communication services delivered as a part of Oracle Communications Services Gatekeeper.
| Note: |
For definitional purposes, Oracle Module-based communication services are divided into the following transaction groups:
The Messaging transaction group covers transactions for the following Parlay X 2.1 and RESTful communication services:
It also covers transactions for all Extended Web Services and RESTful WAP Push communication services, the Binary SMS communication service, and the native MM7 communication service.
There are two main types of transaction units in the Messaging group:
In an application-initiated scenario, a transaction unit consists of the following sequence:
Oracle Communications Services Gatekeeper receives a request from an application and passes it on to the underlying network node. If notifications have been set up, Oracle Communications Services Gatekeeper also receives the delivery notification from the network and passes it back to the application. Even if the message is distributed to a group of destination addresses, only one transaction unit is logged per message.
| Note: | If the application is not registered for delivery notifications, the transaction unit is not affected. |
In a network-triggered scenario, a transaction unit consists of one of the following two sequences:
The Mobility transaction group covers transactions for the following Parlay X 2.1 and RESTful communication services:
There are two main types of transaction units in the Mobility group:
In an application-initiated scenario, a transaction unit consists of one of the two following sequences:
| Note: | An immediate check followed by a status notification is considered two transaction units. |
A transaction unit is not recorded in the following situation:
In a network-triggered scenario, a transaction unit consists of the following sequence:
Oracle Communications Services Gatekeeper receives a notification request that is submitted by the network node and then passes it on to the application.
| Note: | For the purposes of logging transaction units, all notification triggers are equivalent: periodic, geographical, or state-change based are logged in the same manner. |
The Call Control transaction group includes transactions for the following Parlay X 2.1/3.0 and RESTful communication services:
There are two main types of transaction units in the Call Control group:
In an application-initiated scenario, a transaction unit consists of one of the following:
In a network-triggered scenario, a transaction unit consists of one of the two following sequences:
The Presence transaction group covers transactions for the following Parlay X 2.1 and RESTful communication services:
There are three main types of transaction units in the Presence group:
In an application-initiated scenario, a transaction unit consists of the following:
Oracle Communications Services Gatekeeper receives a polling request for user presence information from an application and passes it to the underlying network node. Oracle Communications Services Gatekeeper then receives the immediate response that the underlying network node returns and passes it back to the application.
In a network-triggered scenario, a transaction unit consists of the following:
Oracle Communications Services Gatekeeper receives a status change notification request from the network node and passes it on to the application.
In an application-initiated scenario, a transaction unit consists of the following:
A presentity publishes its presence information to Oracle Communications Services Gatekeeper, which passes it on to the Presence Server.
The Payment transaction group covers transactions for the following Parlay X 3. 0 and RESTful communication services:
The Payment transaction group includes only application-initiated requests.
A Payment transaction unit is recorded in the following situations:
A payment transaction unit is not recorded in the following situation:
|