| Oracle® Communications Service Broker Online Mediation Controller Implementation Guide Release 6.1 E29452-02 |
|
|
PDF · Mobi · ePub |
| Oracle® Communications Service Broker Online Mediation Controller Implementation Guide Release 6.1 E29452-02 |
|
|
PDF · Mobi · ePub |
This chapter describes how to use subscriber store information with Oracle Communications Online Mediation Controller.
To deliver subscriber-specific services, Online Mediation Controller maintains a subscriber profile for each subscriber in the Subscriber Store. The Subscriber Store uses either data populated from the Subscriber Provisioning API (Local Subscriber Store) or data sourced from an Oracle Communications Billing and Revenue Manager (BRM) database. You use only one of these options.
This chapter primarily describes the BRM-based Subscriber Store. See Oracle Communications Service Broker Subscriber Store User's Guide, for more information on using the Local Subscriber Store.
A subscriber profile contains subscriber-specific information used by Online Mediation Controller's built-in applications. For example, the Balance Manager application must know a subscriber's default language to compose SMS messages sent to a subscriber. Online Mediation Controller uses subscriber profiles in determining subscriber state and offline charging eligibility.
Subscriber profiles in the Subscriber Store include:
The service profile.
An orchestration logic that defines how to route subscriber sessions through applications.
An extensible subscriber lifecycle that you use to define subscriber states and state transitions.
Usage counter and threshold information.
Orchestration logic in the subscriber profile is stored in iFC format. Oracle recommends that you use the Online Mediation Controller Orchestration Studio to graphically create orchestration logic.
While conditions in the orchestration logic are mostly based on session information, they can also depend on the following subscriber data available in the Subscriber Store:
Degraded Mode state. See "Using Degraded Mode".
Offline Mode eligibility. See "Offloading Subscriber Usage".
For example, you can configure the orchestration logic to route a session to the OCS only if the subscriber state is Active. You can also determine whether a subscriber's session can be routed to an offline mode local OCS based on the remaining prepaid minutes in their BRM-sourced resource counter balance.
In Online Mediation Controller, you must configure the Orchestration Engine (OE) to use the Subscriber Store as the source for subscriber profiles.
Service providers implementing both Online Mediation Controller and BRM can use BRM subscriber data as the Subscriber Store. The PCP Profile Provider reads BRM subscriber data using the PCP Signaling Server Unit (SSU) and caches the information for Online Mediation Controller use. BRM remains the system of record for subscriber data when using the PCP Profile Adapter.
The Subscriber Store updates BRM subscriber data by listening for Oracle Advanced Queuing (AQ) notification messages generated by the BRM database. When Online Mediation Controller receives a message it checks if any of the changes apply to users with active sessions. If any such users are found the PCP Profile Provider initiates a refresh of their Subscriber Store data for affected users.
Figure 3-1 shows the flow of data read by the PCP Profile Provider from the BRM database to the Subscriber Store.
See "Subscriber Profile Data Model", for additional information on the attributes retrieved and mapped from BRM into the Subscriber Store.
See "Configuring the BRM Subscriber Store", for information on configuring the BRM Subscriber Store.
See "PCP Profile Provider Data Mapping", for information on field mapping between BRM and the Subscriber Store.
To configure Online Mediation Controller to use the BRM database as the Subscriber Store source:
Verify that the PCP persistence bundle is installed and active. See "Configuring the PCP Profile Provider", for more information.
Create a connection pool for the BRM database. See the information on creating database connections in the Oracle Communications Service Broker Installation Guide for more information on setting up the BRM JDBC connection.
Configure the SSU connection to BRM. See the chapter on configuring a PCP Signaling Service Unit in Oracle Communications Service Broker Signaling Server Units Configuration Guide, for more information.
Configure the Subscriber Store Provider containing the queue from where BRM-generated notifications for updates to subscriber profile data are published. See "Configuring a Subscriber Store Provider", for more information.
Populate and maintain the Subscriber Store with user information.
Configure the OE to use the Subscriber Store as a source of subscriber profiles.
Configure the OE as described in "Configuring the Orchestration Engine" in Oracle Communications Service Broker Orchestration User's Configuration Guide. Use the following configuration data, specifically:
In the General tab, in the Subscriber Profile Receiver list, select OlpCustomInfoReceiver.
In the Custom OLP tab, in the Custom OPR Name field, enter UP OPR.
To configure the Subscriber Store to use PCP Profile Provider in the Administration Console:
Expand Domain Management.
Click Packages.
Remove the existing local Subscriber Store persistence bundle from the domain using the Uninstall button. By default, it is:
oracle.ocsb.app.rcc.service.subscriber_store.providers.store.provider
Install and start the PCP Profile Provider with a level of 260 by clicking Install after selecting this bundle:
oracle.ocsb.app.rcc.service.subscriber_store.providers.pcp.jar
Make sure the run level for the package matches that of the following package:
oracle.ocsb.app.rcc.service.subscriber_store.core
Configure the database schema for the Subscriber Store using the following SQL script:
Oracle_home/ocsb/admin_server/scripts/database/subscriber_store.sql
To use the script to configure your database schema, run the script using a SQL client tool, such as sqlplus, or interface provided by your database management system.
If the managed servers in the domain are not already configured to connect to the database, configure the connections in Data Store under Domain Management.
For the Subscriber Store database, the connection pool name value in the JDBC configuration should be the name of your BRM database that you set in the "Configuring a Subscriber Store Provider" section. For example, oracle_driver.
See Oracle Communications Service Broker Installation Guide for more information about configuring data storage.
Configure the PCP signaling server units (SSU) to connect to BRM.
See the chapter on configuring PCP signal server units in Oracle Communications Service Broker Signaling Server Units Configuration Guide.
Configure the Subscriber Store Provider indicating the connection pool and queue on which to listen for BRM generated Oracle AQ notifications.
If the Administration Console is not already in offline mode, click the Switch to OFFLINE mode icon at the top of the page.
Click Lock & Edit.
Expand OCSB and then Domain Management.
Expand Subscriber Store.
Click Providers.
In the BRM tab, add the Subscriber Store Provider information as a new Notifications entry by clicking New and providing the following information:
Enter a unique Name for the provider.
In the Connection Pool Reference field, enter the name of the JDBC connection pool created for the BRM database. This value must be identical to the connection pool value.
In the Queue Owner field enter the BRM database user with access to the notification queue.
In the Queue Name field, enter the name of the notification queue as defined in the BRM database.
In the Number of Sessions field, enter the number of connections to open to the Provider. This value cannot be larger than the connection pool size.
Click OK.
The new provider instance appears in the list of Notifications.
Click Commit.
The subscriber profile data model defines the elements of a subscriber profile. The model includes general information for the subscriber along with feature-specific information, such as Policy Controller data. Figure 3-2 illustrates the subscriber profile data model.
The subscriber profile data model is defined by an XML Schema file. You can access the schema at the following default location:
http://host:port/soap/SubscriberProvisioning?xsd=1
where host is the host name or IP address and port is the server port number you specified as the server address.
As shown in Figure 3-2, the top-level data elements that compose the subscriber profile are:
The following sections provide information on the data elements of the subscriber profile.
The globalProfileData element defines general properties for a subscriber. Multiple Online Mediation Controller applications use this data. This element contains the following elements:
AccountState: The account lifecycle state that indicates the status of the account, such as active or inactive.
AccountType: The account type from the options prepaid, postpaid, or hybrid. Hybrid accounts can use both prepaid and postpaid charging methods.
DateOfBirth: The birth date of the subscriber. The date is in YYYYMMDD format. For example, 19910128.
Groups: Group identifier for the subscriber.
Language: The language to use for the subscriber. Online Mediation Controller applications that interact with subscribers can use this attribute to select a response or adapt a message for the subscriber.
NotificationChannel: The notification channel used to send notifications to the user.
SubscriberActivationDate: The date, in YYYYMMDD format, when the subscriber account was first activated, such as 20111231.
The ifcProfileData element contains the iFC logic for the subscriber. The iFC defines the service chain for a particular subscriber, which services are invoked and the order in which they are invoked.
The PcrfProfileData element contains subscriber data used by the Policy Controller. PcrfProfileData includes the following elements:
AllowUnknownServices: Whether the subscriber is permitted to access services that are not specifically allocated to that subscriber, as indicated by the services field.
HomeZone: The home, non-roaming network zone for the subscriber. Policy Controller administrators can apply charging rates or service access decisions based on whether the subscriber is using the network from their home zone.
The HomeZone element is made up of a LocationType, which identifies the protocol type in which the location information is represented, such as IEEE-802.11a or 3GPP-GERAN. Depending on the location type, it also includes elements that identify the location as specified for that type.
Possible values for LocationType can be: CGI, SAI, RAI, TAI, ECGI, TAI_ECGI. Depending on the value of LocationType, the following additional elements may also be present:
CI
ECI
LAC
MCC
MNC
RAC
SAC
TAC
For example, if the location type is CGI, then the location-type specific parameters that should be set are: CI, LAC, MCC, and MNC.
For more information on the location identification protocol, see the following 3GPP specifications:
Services contains one or more Service elements. The Service defines the services this subscriber can access. Each service has the following fields:
description: A description of the service.
endDate: The date, in YYYYMMDD format, on which the service availability ends for an individual subscriber. Along with the startDate value, this value enables you to make services available to subscribers within a specific date range.
id: The identity of the Policy Controller application described by this service element. See Oracle Communications Service Broker Policy Controller Implementation Guide for more information.
startDate: The date, in YYYYMMDD format, on which service availability begins. Along with the endDate value, this value enables you to make services available to subscribers within a specific date range.
SubscriberCategory: An application-defined service level for a given subscriber, such as gold, silver, or bronze. The Policy Controller rules determine how a category dictates the level of service access for the subscriber.
The counterProfileData element contains subscriber usage data represented as one or more counterData elements. Each counterData element identifies a resource or usage balance and its associated regions defined by a set of consecutive value ranges. See "Understanding Counter Regions", for an example of how regions can be used in the Subscriber Store.
CounterData contains the following:
Id: A unique string identifier for the counter.
Region(s): One or more consecutive CounterRegion resource balance value ranges used to categorize a subscriber's usage status. The value of a subscriber's resource counter determines the region that the subscriber is currently in.
The CounterRegion element consists of the following:
regionID: A unique string identifier for the region.
activationDate: The date on which the region became active. For example, 20120712.
deactivationDate: The date on which the region will become inactive. For example, 20120815.
quota: The available quota for the region if this region has a quota.
usage: The currently used resource amount for the region.
MeteringMethod: Indicates a how counter tracks subscriber usage. The following methods are supported:
VOLUME: The amount of resource usage. For example, bytes.
DURATION: The length of time a resource is used. For example, seconds or minutes.
CounterType: Indicates the type of metric used to track subscriber usage. The following types are supported:
SECONDS
MINUTES
BYTES
RegionTotal:
totalQuota: The total amount of resource quota available in a region.
totalUsage: A subscriber's total resource usage within a region.
The following sample scenario provides an example of how counter regions are used in the Subscriber Store.
In this example, counter regions represent a fair usage scenario for a data subscriber. The subscriber's service provider implements a data plan including reduced (throttled) data speeds triggered by the subscriber's total data usage across the thresholds as shown in Figure 3-3.
As the subscriber's usage accumulates in the fair usage counter, he moves through the Monthly, Throttled, and Restricted counter regions. The subscriber exists in only one region at a time.
Online Mediation Controller applications can use the subscriber's current region to enforce the correct data throttling and access limitations. The bandwidth and access values in the example are not part of the counter data model, but rather part of the rules enforced based on the data model.
The redirectionProfileData element defines subscriber redirection behavior. The Service Broker Redirection Application uses this data to redirect sessions requiring subscriber attention, such as a low balance, to an alternative destination application. Redirection data stored in a subscriber's profile overrides the default redirection behavior configured in the charging IM.
See the chapter on the Redirection Application in Oracle Communications Service Broker Online Mediation Controller Implementation Guide for more information.
The following fields are included in the redirectionProfileData element:
criteria: Indicates the type of message triggering redirection supplied by the online charging system. Supported values are FUI, NO_MONEY_NOTIFICATION, and LOW_CREDIT_NOTIFICATION.
redirectAddressType: Defines the address type of the address specified in the element. Supported values are IPV4, IPV6, URL, and SIP_URI.
redirectAddressAddress: The address of the redirection server.
validityTime: The allowed time, in seconds, remaining for a redirected subscriber to access network resources.
immediately: Indicates whether redirection should happen IMMEDIATELY or NON_IMMEDIATELY (after the value specified in Validity Time). When the type is set to NO_MONEY, this value must be set to IMMEDIATELY.
The ProfileDataExtension element stores custom data elements in the profile. For example, the Policy Controller rule engine can make policy decisions based on dynamically defined subscriber attributes.
The ExtensionId value identifies the Online Mediation Controller component that uses the data extension. For the Policy Controller, for example, the ExtensionId value is pcrf. Each data extension entry consists of one or more name-value pairs, as specified by the Online Mediation Controller component that uses it.
The UserIdentifier element contains the unique identifier for a subscriber on a particular network. A subscriber can belong to multiple networks, for instance, if they own multiple devices used to access different networks. Therefore, a subscriber can have multiple UserIdentifier elements.
Each UserIdentifier element consists of the identifier value and the type of the identifier. The type represents the system in which the ID belongs. It may have one of the following values:
END_USER_E164: The subscriber's identity in ITU-T E.164 format, as defined in recommendations E164 and CE164.
END_USER_IMSI: The subscriber's identity in International Mobile Subscriber Identity format, as defined in ITU-T recommendations E212 and CE212.
END_USER_SIP_URI: The subscriber's identity in a SIP network.
END_USER_NAI: The subscriber's identity in a mobile IP Network Address Identifier format.
END_USER_PRIVATE: The subscriber's private identity in a credit-control server.
END_USER_GLOBAL_UID: A unique global user ID generated by Online Mediation Controller to identify subscribers internally. Online Mediation Controller generates this ID automatically when you create a subscriber profile.
The value for each identifier type varies by the network type. For example, the identifier for the URI type should be in the form of a SIP URL, such as sip:username@example.
Online Mediation Controller maps BRM subscriber profile data to Subscriber Store attributes used in determining a subscriber's state or service usage eligibility. For more information about BRM data to Subscriber Store mapping, see the chapter on using the Subscriber Provisioning API in Oracle Communications Service Broker Subscriber Store User's Guide.
The following tables describe the mapping of Subscriber Store profile data fields to the BRM Flist fields used in the BRM database.
Table 3-1 describes the GlobalProfileData fields mapping between the Subscriber Store and BRM database.
Table 3-1 GlobalProfileData Fields Mapping
| GlobalProfileData Field | Type | Flist Field Name | Flist Field Type |
|---|---|---|---|
|
AccountState |
String |
globalProfileData.accountState |
String |
|
NotificationChannel |
String |
globalProfileData.notificationChannel |
String |
|
Groups |
List |
globalProfileData.groups.[n] |
N/A |
|
AccountType |
String |
globalProfileData.accountType |
String |
|
SubscriberActivationDate |
String |
globalProfileData.subscriberActivationDate |
String |
|
DateOfBirth |
String |
globalProfileData.dateOfBirth |
String |
Table 3-2 describes the IfcProfileData field mapping between the Subscriber Store and BRM database.
Table 3-2 IfcProfileData Field Mapping
| IfcProfileData Field | Type | Flist Field Name | Flist Field Type |
|---|---|---|---|
|
Ifc |
String |
ifcProfileData.ifc |
String |
Table 3-3 describes the PcrfProfileData field mapping between the Subscriber Store and BRM database.
Table 3-3 PcrfProfileData Fields Mapping
| PcrfProfileData Field | Type | Flist Field Name | Flist Field Type |
|---|---|---|---|
|
SubscriberCategory |
String |
pcrfProfileData.subscriberCategory |
String |
|
HomeZones |
List |
pcrfProfileData.homeZone.[n] |
N/A |
|
Home.GeographicLocationType |
Enum |
pcrfProfileData.homeZone.[n].geographicalLocationType |
String |
|
Home.LocationData |
Map |
pcrfProfileData.homeZone.[n].locationData |
String |
|
Home.LocationField |
Enum |
pcrfProfileData.homeZone.[n].locationField |
String |
|
Services |
List |
pcrfProfileData.services.[n] |
N/A |
|
Service.id |
String |
pcrfProfileData.services.[n].id |
String |
|
Service.description |
String |
pcrfProfileData.services.[n].description |
String |
|
Service.startDate |
String |
pcrfProfileData.services.[n].startDate |
String |
|
Service.endDate |
String |
pcrfProfileData.services.[n].endDate |
String |
|
AllowUnknownServices |
Boolean |
pcrfProfileData.allowUnknownServices |
String |
Table 3-4 describes the CounterProfileData field mapping between the Subscriber Store and BRM database
Table 3-4 CounterProfileData Fields Mapping
| CounterProfileData Field | Type | Flist Field Name | Flist Field Type |
|---|---|---|---|
|
Id |
String |
counterProfileData.id |
String |
|
CounterType |
Enum |
Mapped from FldGroupInfo |
FldRumName |
|
MeteringMethod |
Enum |
Derived from CounterType |
FldRumName |
|
Regions |
List |
counterProfileData.region.[n] |
N/A |
|
CounterRegion.regiodId |
String |
counterProfileData.region.[n].regionId |
String |
|
CounterRegion.value |
Long |
counterProfileData.region.[n].value |
String |
|
CounterRegion.activationDate |
String |
counterProfileData.region.[n].activationDate |
String |
|
CounterRegion.deactivationDate |
String |
counterProfileData.region.[n].deactivationDate |
String |
Table 3-5 describes the ProfileDataExtension field mapping between the Subscriber Store and BRM database
Table 3-5 ProfileDataExtension Fields Mapping
| ProfileData Extension Field | Type | Flist Field Name | Flist Field Type |
|---|---|---|---|
|
Id |
String |
profileDataExtension.[n].id |
String |
|
Data |
Map |
profileDataExtension.[n].data.[n] |
N/A |
|
Data.key |
String |
profileDataExtension.[n].data.[n].key |
String |
|
Data.value |
String |
profileDataExtension.[n].data.[n].value |
String |
|
 Copyright © 2010, 2014, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|
