About Services Framework Manager Provisioning

2 About Services Framework Manager Provisioning

This document describes how Oracle Communications Billing and Revenue Management (BRM) Services Framework provisioning works.

Topics in this document:

About Provisioning Services

Service provisioning enables you to assign and change network resources on external networks when the status of a prepaid service or device changes; for example, when a service is activated or deactivated.

When the status changes, service provisioning does the following:

Creates a service order, which provides information about the service and the provisioning action required.
Sends the service order to the external network through the Provisioning Data Manager (DM), dm_prov_telco.
Updates the service order's status.
Updates the status of the service and device associated with the service order.

Provisioning occurs whenever customer data on the network must be changed. For example:

Activating, changing, and inactivating GSM services and supplementary services. (During service activation and inactivation, phone numbers and SIM cards can also be provisioned or unprovisioned.)
Pre-provisioning SIM cards.
Changing SIM cards, phone numbers, and other service attributes, such as call forwarding.

BRM can provision both telco services and non-telco services.

All telco services (/service/telco/* objects) are automatically recognized and provisioned.
Non-telco services are provisioned only if they are listed in the /config/service_framework/permitted_service_types object. You specify the non-telco services that Services Framework supports by using the "load_pin_service_framework_permitted_service_types" utility. See "Specifying the Non-Telco Services Supported by Services Framework".

About Service Orders

Services Framework provisioning uses service orders to alert external provisioning agents about account and service changes. The service order includes details about what changed, including the following:

POID of the device, service, or profile object that changed.
The current status of the service order. See "About Service Order Status".
The provisioning action to perform: activation, deactivation, suspension, reactivation, change, or ignore.
Specified fields from the /service or /device object. See "About Adding Details to the Service Order".

The service order is sent to the external provisioning agent and stored in the BRM database in an /event/provisioning/service_order/telco/service_name object.

About Creating Service Orders for Supplementary Services

Supplementary services are added to or removed from service objects (/service/telco/service_name) when charge offers and bundles are purchased or canceled. Services Framework service management initially sets the service status to NEW. If supplementary services are not included with the service, Services Framework provisioning adds them to the service order.

Note:

Some features may be part of two or more charge offers purchased separately. In this case, the one added later takes the status of the existing one and is not included in the service order.

You can localize the status flags for the service and the status for the supplementary service by using the load_localized_strings utility, which updates the /strings storable class based on localized configuration file. See "Creating a Localized Version of BRM" in BRM Developer's Guide.

About Creating Service Orders for Devices

Device service order creation is controlled by the device status stored in the configuration object (/config/device_state). If the device status is listed in the configuration object, a service order is created. The action associated with this service order is the one specified in the configuration for this device status entry.

The /event/device/associate and /event/device/disassociate events occur during an update services action. These events get device information needed to create the service order from the device objects. Only events for device types listed in the /config/telco/provisioning object are processed. The fields read from the device objects are specified in the /config/telco/provisioning object for this type of device.

When a device is changed, the /event/device/state event is generated as part of the device state change. PCM_OP_TCF_CREATE_SVC_ORDER reads the configuration object (/config/telco/provisioning) to determine if the device state requires that a service order be created. If so, this opcode creates it as part of the service order event (/event/provisioning/service_order/telco/service_name).

PCM_OP_TCF_PROV_POL_CREATE_SVC_ORDER is called as part of the state transition and can be customized to change some value in the service order. This opcode calls the opcodes that update the service order.

About Service Order Status

Like services, service orders have different statuses in their lifetimes. Table 2–1 shows the default values for service order status:

Table 2-1 Service Order Status Default Values

Service Order Status	Description
NEW	This is the initial service order state.
READY	A READY service order is ready to be sent to the provisioning agent. The provisioning FMs have all the necessary data to completely fill in the service order and send it to the network provisioning interface.
PROCESSING	After the service order is received by the network provisioning interface, the state is changed to PROCESSING.
COMPLETED	If the service order is successfully processed and the devices are provisioned, the service order state changes to COMPLETED.
FAILED	If there are errors during device provisioning or in the network, the status of the service order is set to FAILED.

About the Provisioning Process

BRM uses event notification to alert Services Framework provisioning that one of the following occurred:

A service was created or modified.
A device was associated with or disassociated from a service.
A device was replaced with a new device.
A device's state changed.
A profile was modified.

Note:

To configure event notification to alert Services Framework provisioning that other events occurred, see "Setting Up Event Notification for Provisioning".

Services Framework provisioning then performs the following main functions:

Generates a service order and adds specified details to it. See "About Adding Details to the Service Order".
Retrieves the service order state transitions for the specified service or device type. See "About Valid Service Order State Transitions".
Optionally tests the provisioning process by using the Network Simulator. See "Testing Provisioning Using BRM Network Simulator".
Publishes the service order and, depending on the provisioning mode, either finishes processing or waits for a response from the network provisioning agent. See "About Provisioning Modes".

About Adding Details to the Service Order

Service orders contain information about the service, device, or profile that changed as well as the provisioning action to perform. You can also have other details about the service, device, or profile added to the service order before it is sent to the external provisioning agent. For example, you can add the quality of service (QoS) values and APN names to GSM service orders.

You specify the service, device, or profile object fields to add to the service order in the BRM_home/sys/data/config/pin_telco_provisioning configuration file. You then load the file into the provisioning configuration object (/config/telco/provisioning and /config/telco/provisioning/fieldlist) by using the "load_pin_telco_provisioning" utility.

During the provisioning process, Services Framework determines the object fields to include in the service order by reading the provisioning configuration object:

For telco services, the provisioning configuration object is /config/telco/provisioning/ServiceType, where ServiceType is the service passed in the input flist. For example, if the service is /service/telco/gprs/telephony, the provisioning configuration object is /config/telco/provisioning/gprs/telephony.
For non-telco services, the /config/service_framework/permitted_service_types object lists the provisioning configuration object to use.

To configure the service, device, and profile object fields to add to the service order, see "Specifying the Details to Add to the Service Order".

About Valid Service Order State Transitions

Service orders can be set to a NEW, READY, PROCESSING, COMPLETED, or FAILED state. When a service order is first created, it is set to the NEW state by default. The service order can then transition from the NEW state to a list of permitted states that you specify.

For each service order state, you define the valid states to which it can transition. For example, you specify whether service orders can transition from a NEW state to only a READY state or from a NEW state to either a READY state or a PROCESSING state.

You specify the valid state transitions for each service in the BRM_home/sys/data/pin_telco_service_order_state configuration file. You then load the file into the /config/telco/service_order_state/* database object by using the load_pin_telco_service_order_state utility.

Note:

You can also configure BRM to call an opcode when a service order transitions from one state to another.

To specify the valid state transitions, see "Specifying the Available States for Each Service Order".

About Provisioning Modes

After service orders are published, the provisioning process cannot continue until the network provisioning agent returns a response. You can configure whether Services Framework provisioning sends the service order directly to the agent and waits for a response or publishes the service order to a queue by setting the provisioning mode:

Queued provisioning mode. Services Framework provisions service orders in two separate transactions. In the first transaction, Services Framework generates a service order and queues it for the external provisioning agent. In the second transaction, the external provisioning agent responds that provisioning failed or was successful and then Services Framework updates the service in the BRM database. This is the default provisioning mode.
Confirmed provisioning mode. Services Framework publishes the service order immediately to the external provisioning agent, waits for a response, and updates the service in the BRM database in one transaction. Specifically, Services Framework:
- Processes the request and converts the service order information into a provisioning payload object in XML format.
- Sends the service order to the network provisioning agent through a TCP/IP connection.
- Waits for a response from the network provisioning agent.
  
  If the wait exceeds the timeout value, the transaction is rolled back. See "Setting a Timeout Value for Requests Sent in Confirmed Mode".

You specify the provisioning mode on a service-by-service basis by using the pin_service_framework_permitted_service_types.xml configuration file. You then load the XML file into the BRM database's /config/service_framework/permitted_service_types object by using the "load_pin_service_framework_permitted_service_types" utility. See "Specifying the Non-Telco Services Supported by Services Framework".

You can also customize the PCM_OP_TCF_POL_PROV_HANDLE_SVC_ORDER policy opcode to set an event's provisioning mode based on service order attributes. The policy opcode overrides the provisioning mode set in the /config/service_framework/permitted_service_types object.

Note:

The /config/service_framework/permitted_service_types object and the PCM_OP_TCF_POL_PROV_HANDLE_SVC_ORDER policy opcode are used primarily to configure non-telco services. However, they can be used to specify the provisioning mode for telco services.

About Delayed Provisioning

GSM service provisioning is triggered according to the charge offer or bundle purchase date or end date:

If the purchase or end date is not specified, the date is by default the current date. This means that the service is provisioned or unprovisioned as soon as the charge offer or bundle is purchased or canceled.
If the purchase or end date is in the future, the service is provisioned at the future date. This is known as delayed provisioning.

You should use delayed provisioning whenever possible. For example, instead of performing a charge offer upgrade on the same day it is requested, schedule the upgrade for the following day.

The advantage of using delayed provisioning is that provisioning is triggered for only the net difference between the existing supplementary services and the new supplementary services. For example, an account might own a charge offer that includes these supplementary services:

Voice mail
Call forwarding

Using delayed activation, you cancel the existing charge offer and add a charge offer that includes these supplementary services:

Voice mail
Call blocking

In this case, BRM unprovisions call forwarding, and provisions call blocking. The customer's voice mail configuration, including any existing messages, is unchanged.