4 Common PRM Use Scenarios

This section outlines common use patterns using PRM.

Registering a new Service Provider Account

1. The Service Provider applies for a Service Provider Account using Service Provider Login::registerSPAccountReq(...) providing basic information such as desired account name, contact details, and so forth as part of the application.

2. The Operator lists new requests using Operator::listSpAccounts(...). The list can be filtered to display only service provider accounts in the REGISTERED state.

3. The request is inspected by the Operator, and can be changed using Operator::updateSpAccount(...).

4. If the request is approved by the Operator, the Service Provider Account is first associated with a Service Provider Group and SLA and then approved using Operator::registerSpAccountRes(...). For information on setting up a Service Provider Group, see "Operator: Creating a Service Provider Group".

   Note:

   The Service Provider Group that the Service Provider Account belongs to can be changed at any time using Operator::moveSpToGroup(...).

5. Finally, the Service Provider is notified that the request has been approved via any of the contact channels that were detailed when the request was submitted. The CRM/PRM application implementor must set up a mechanism for this communication, or for the communication of any other account changes that may occur.

Registering a new Application Account

1. The Service Provider applies for an application account via Service Provider::registerAppAccountReq(...).

2. The Operator lists new request using Operator::listAppAccounts(...) The list can be filtered to display only REGISTERED applications belonging to a specific service provider account.

3. The request is inspected by the Operator, and can be changed using Operator::updateAppAccount(...).

4. If the request is approved by the Operator, the Application Account is first associated with an Application Account Group and SLA and then approved using Operator::registerSpAccountRes(...). For information on setting up an Application Account Group, see "Operator: Creating an Application Account Group".

   Note:

   The Application Account Group that the Application Account belongs to can be changed at any time using Operator::moveAppAccountToGroup(...).

5. Finally, the Service Provider is notified that the request has been approved via any of the contact channels that were supplied with the original request for a Service Provider Account. The CRM/PRM application implementor must set up a mechanism for this communication, or for the communication of any other account changes that may occur.

At this point the Application Account is in ACTIVE state. To actually begin sending traffic to Oracle Communications Services Gatekeeper, however, the application must now apply for an Application Instance ID to be used to authenticate the account. For information on Application Instances, see "Application Instances"; for information on how to register an Application Instances, see "Registering a new Application Instance".

Registering a new Application Instance

1. The Service Provider applies for an Application Instance via Service Provider::registerAppInstGroupReq(...). . The request include desired properties to be associated with the instance.

2. The Operator lists new requests using Operator::listAppInstGroups(...) The list can be filtered to display only requests from specific SP Accounts and App Accounts for instances in the REGISTERED state.

3. The request is inspected by the Operator, and can be changed using Operator::updateAppInstGroup(...).

4. If the request is approved by the Operator, it is approved using Operator::registerAppInstGroupRes(...).

5. Finally, the Service Provider is notified that the request has been approved via any of the contact channels that was detailed when applying for a Service provider Account. The CRM/PRM application implementor must set up a mechanism for this communication, or for the communication of any other account changes that may occur.

Once the Service Provider has a Service Provider Account, an Application Account, and an Application Instance ID, traffic can be sent to Oracle Communications Services Gatekeeper.

Operator: Creating a Service Provider Group

1. The Operator defines the use privileges for a particular Service Provider Group.

2. These use privileges are formalized in a Service Provider Service Level Agreement XML file.

3. The Operator creates the Service Provider Group using Operator::createSpGroupByType(...) and assigns the newly created Service Provider SLA to it. An ID for the group is also defined.

Operator: Creating an Application Account Group

1. The Operator defines the use privileges for a particular Application Account Group.

2. These use privileges are formalized in an Application Service Level Agreement XML file.

3. The Operator creates the Application Account Group using Operator::createAppGroupByType(...) and assigns the newly created Application SLA to it. An ID for the group is also defined.

Service Provider Requests an Account Update

The Service Provider can request an update to any of its account entities. The request might cover SLA data or user defined properties. The Operator is responsible for approving or disapproving the request.

1. To request an update for a Service Provider account, the Service Provider uses Service Provider::update<SpAccount|AppAccount|AccountAppInstGroup>Req(...) as appropriate.

2. Once the Service Provider has requested an update, the state of the account is changed to UPDATE_PENDING until the Operator has inspected the update request and either approved it or disapproved it using Operator::update<SpAccount|AppAccount|AccountAppInstGroup>Res(...).

   Note:

   When an account is in the UPDATE_PENDING state, no further requests to update the account are allowed until the initial request has been approved or disapproved.

Service Provider Deactivates an Account

The Service Provider can deactivate any of its account entities. The deactivation takes affect immediately. No traffic is allowed through an account that is deactivated. The impact of a deactivation is cascaded through the Service Providers system:

• When a Service Provider Account is deactivated, none of the applications run by the service provider are able to send traffic through Oracle Communications Services Gatekeeper.

• When an Application Account is deactivated, none of the applications that are associated with that Application Account are able to send traffic through Oracle Communications Services Gatekeeper.

• When an Application Instance is deactivated, only that Application Instance is unable to send traffic through Oracle Communications Services Gatekeeper. Other applications are not affected.

An account must always be deactivated before it can be deleted.

1. To deactivate an account the Service Provider can use either Service Provider::deactivate<SpAccount|AppAccount|AccountAppInstGroup>Req(...), depending on the type of account.

2. To deactivate an account the Operator can use either Operator::deactivate<SpAccount|AppAccount|AccountAppInstGroup>Req(...), depending on the type of account.

Service Provider Requests an Account Deletion

The Service Provider can request to have any of its account entities deleted. The deletion does not take effect until after the request has been approved by the Operator.

An account must always be in state INACTIVE before it can be deleted.

1. To request to delete an account, either Service Provider::delete<SpAccount|AppAccount|AppInstGroup>Req(...) is used.

2. When the Service Provider has requested an account deletion, the state of the account is changed to DELETE_PENDING until the Operator has inspected the request and either approved it or disapproved it using Operator::delete<SpAccount|AppAccount|AppInstGroup>Res(...).

   Note:

   When the request to delete an account is approved the account is deleted from the database. It is the Operator's responsibility to make sure that outstanding charging data records are processed before the deletion takes place.

   If the request to delete the account is disapproved, the state of the account becomes INACTIVE.

Communicating General Information Between Service Provider and Operator

The Service Provider can communicate desired updates to the Operator using the update methods, as described in "Service Provider Requests an Account Update". Each update request can contain a set of properties in the form of name-value pairs, which are defined by the implementors of the CRM/PRM application.

Retrieving Charging Data Records

Both the Service Provider and the Operator can retrieve Charging Data Records using <Operator| Service Provider>::listCdrs(...). The operator can retrieve CDRs for all Service Providers, while the Service Provider only has access to Charging Data Records generated by its own applications. Results can be filtered.

Retrieving Statistics

Both the Service Provider and the Operator can retrieve statistics using <Operator| Service Provider>::getStatistics(...). The operator can retrieve statistics for all Service Providers, while the Service Provider only has access to its own applications. A set of filters can be used, including Application Account IDs and time intervals.

Retrieving Alarms

The Operator can retrieve alarms using Operator::listAlarms(...). The operator can retrieve alarms generated by all Service Providers, as well as platform related alarms. A set of filters can be used, including timestamps and severity levels.