![]() ![]() ![]() ![]() ![]() ![]() |
This section outlines common use patterns using PRM.
Service Provider Login::registerSPAccountReq(...)
providing basic information such as desired account name, contact details, and so forth as part of the application.Operator::listSpAccounts(...)
. The list can be filtered to display only service provider accounts in the REGISTERED
state.Operator::updateSpAccount(...)
.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(...) . |
Service Provider::registerAppAccountReq(...)
.Operator::listAppAccounts(...)
The list can be filtered to display only REGISTERED
applications belonging to a specific service provider account.Operator::updateAppAccount(...)
.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(...) . |
At this point the Application Account is in ACTIVE state. To actually begin sending traffic to Network 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.
Service Provider::registerAppInstGroupReq(...)
. . The request include desired properties to be associated with the instance.Operator::listAppInstGroups(...)
The list can be filtered to display only requests from specific SP Accounts and App Accounts for instances in the REGISTERED
state.Operator::updateAppInstGroup(...)
.Operator::registerAppInstGroupRes(...)
. Once the Service Provider has a Service Provider Account, an Application Account, and an Application Instance ID, traffic can be sent to Network Gatekeeper.
Operator::createSpGroup(...)
and assigns the newly created Service Provider SLA to it. An ID for the group is also defined.
Operator::createAppGroup(...)
and assigns the newly created Application SLA to it. An ID for the group is also defined.
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.
Service Provider::update<SpAccount|AppAccount|AccountAppInstGroup>Req(...)
as appropriate. 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. |
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:
An account must always be deactivated before it can be deleted.
Service Provider::deactivate<SpAccount|AppAccount|AccountAppInstGroup>Req(...)
, depending on the type of account.Operator::deactivate<SpAccount|AppAccount|AccountAppInstGroup>Req(...)
, depending on the type of account.
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.
Service Provider::delete<SpAccount|AppAccount|AppInstGroup>Req(...)
is used. 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. |
Note: | If the request to delete the account is disapproved, the state of the account becomes INACTIVE . |
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.
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.
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.
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.
![]() ![]() ![]() |