| Oracle® Communications Service Broker Policy Controller Implementation Guide Release 6.1 Part Number E29455-01 |
|
|
PDF · Mobi · ePub |
| Oracle® Communications Service Broker Policy Controller Implementation Guide Release 6.1 Part Number E29455-01 |
|
|
PDF · Mobi · ePub |
This chapter explains how to configure Oracle Communications Service Broker Policy Controller (Policy Controller) to use Subscriber Profile Repository (SPR) and online charging system (OCS) repositories to supply subscriber information for your Policy Controller rules to use.
Policy Controller is designed to use individual subscriber data to decide which services and QoS limits a subscriber is entitled to. This can be as simple as probing for the level of service a subscriber has purchased and applying the correct QoS limits. However, you can use any combination of SPR/OCS information in your rules as criteria to select services, applications, and QoS limits for a subscriber. More importantly, you can take advantage of the dynamic nature of the supported SPRs/OCSs and have Policy Controller reinterpret rules and change QoS limits and/or redirect service data flow based on updated information.
Policy Controller does not provision or maintain SPR/OCS data; the SPR/OCS you choose is responsible for doing that. Policy Controller only reads and uses it, and then deletes the local copy the session ends. Policy Controller obtains information from SPRs/OCSs in two ways. First it requests subscriber profile information from the SPR/OCS as soon as a subscriber opens a session. Second, Policy Controller also accepts notifications from your OCS/SPR updating the subscriber's profile during the session, and act on it if necessary. The local Subscriber store is the only SPR/OCS that does not support notifications. Your SPR/OCS product documentation explains how to configure and provision it with subscriber information, and set information on how to set up, provision, and use notifications to send subscriber data to Policy Controller.
Policy Controller can connect to and use subscriber data from any one of these combination SPR/OCSs. Select one and configure it using the instructions in the section listed:
The Local Subscriber Store provided with Policy Controller. Use this option if you do not already have an SPR/OCS, and your implementation does not require one of the other options. See "Using the Local Subscriber Store as an SPR/OCS" for details.
The local Subscriber Store contains both SPR and OCS data, and is available for Policy Controller information requests. However, the way it causes Policy Controller to reinterpret rules is different. The other SPR/OCSs use a notification mechanism. The local Subscriber Store reinterprets rules each time you use the updateSubscriber API operation to update a subscriber profile.
The Oracle Communications Billing and Revenue Management (BRM) SPR/OCS features. See "Using Oracle Billing and Revenue Management as an SPR/OCS" for details.
A third-party SPR/OCS that uses Diameter-based communication. See "Using a Third-Party SPR with Diameter Connectivity" for details.
A third-party SPR/OCS that uses Web-based (SOAP) communication. See "Using a Third-Party SPR/OCS with Web-Based Connectivity" for details.
The instructions for configuring your SPR/OCS to connect to and work with Policy Controller are in this chapter. Once configured, Policy Controller automatically probes for subscriber profile information from your SPR/OCS when a session is started. Once the session is started Policy Controller can accept notifications of new subscriber information from the SPR and reinterpret Policy Controller rules as needed. Once connected with a Policy Controller SSU, your SPR/OCS and Policy Controller can pass information back and forth freely. using the Diameter Sy/Sp reference points.
Note:
Policy Controller uses the Diameter SP specification to communicate with your SPR. However details of an Sp implementation is left to the implementor. Policy Controller uses a modified form of the Diameter Sh commands and AVPs for its Sp implementation. The supported Sh specification is Policy and Charging Control: Spending Limit Reporting over Sy reference point 3GPP TS 29.219 V11.0.0 (2012-03).See Oracle Communications Service Broker Policy Controller Protocol Implementation Conformance Statement for details on the commands and AVPs supported.
All of the SPR/OCSs that Policy Controller supports use the data model explained in "Subscriber Profile Data Model". The local subscriber store uses this data model, so no further mapping is required. BRM uses the mapping shown in "PCP Profile Provider Data Mapping" to use this data model with its database. The Diameter and Web-based SPR/OCSs also require mapping to their internal structures which are defined by the WSDL files provided with Policy Controller. You connect to them during the configuration procedures for these SPR/OCSs.
The local Policy Controller SPR is ready to configure after Policy Controller is installed. See Service Broker Subscriber Store User's Guide for instructions on how to configure the local Subscriber Store, provision it with data for the Policy Controller to use, and configure an Sp reference point to communicate with.
The Service Broker Subscriber Store User's Guide also includes information on the Subscriber Store provisioning API that you use to provision the load SPR.
You can extend subscriber profiles with any number of key-value pairs that your Policy Controller implementation requires. For details on using the Subscriber Store API to add key/value pairs, see Service Broker Subscriber Store User's Guide.
Once configured, the local Subscriber Store causes Policy Controller to reinterpret its rules each time you use the updateScriber API operation to change a subscriber profile.
If you implement both Policy Controller and BRM you will probably also use BRM as your SPR/OCS.
You provision and maintain accurate subscriber profiles using the BRM tools, and configure BRM to send subscriber updates Policy Controller as necessary.
Subscriber profiles in the SPR/OCS include:
The service profile.
An extensible subscriber lifecycle that you use to define subscriber states and state transitions.
Usage counter and thresholds information.
The Policy Controller PCP Profile Provider reads BRM subscriber data by using the PCP Signaling Server Unit (SSU) and populates the Subscriber Store with this information. 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 Policy 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.
See "Subscriber Profile Data Model", for additional information on the attributes retrieved and mapped from BRM into the Subscriber Store.
Note:
BRM only supports the active and inactive subscriber account lifecycles. If you use BRM as an SPR/OCS, you should only use those values.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 Policy 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 Service Broker Installation Guide for more information on setting up the BRM JDBC connection.
Configure the Signal Server Unit (SSU) connection to BRM. See the chapter on configuring a PCP Signaling Service Unit in 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.
To configure the Subscriber Store to use the PCP Profile Provider:
Remove the existing local Subscriber Store persistence bundle from the domain. By default, it is:
oracle.ocsb.app.rcc.service.subscriber_store.providers.store.provider
Install and start the PCP Profile Provider bundle with a level of 260:
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_console/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 the Data Store node 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 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 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.
Start the Administration Console.
For details see Service Broker System Administrator's Guide
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 the OCSB node and then Domain Management.
Expand the Subscriber Store node.
Click the Providers node.
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 to save the configuration.
The new provider instance appears in the list of Notifications.
Click the Commit icon.
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-1 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-1, 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. 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, 19910128.
Groups: Group identifier for the subscriber.
Language: The language to use for the subscriber. AFs 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 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 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 3GPP specifications: TS 29.060, TS 29.061, and TS 29.274.
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 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, and 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 "About 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.
deactivationDate: The date on which the region will become inactive.
usage: The currently used amount for the region if supported by the underlying billing system. A value of -1 indicates that the usage for this region is not available.
quota: The available quota for the region if this region has a quota. A null value indicates an unlimited quota. A value of -1 indicates that the quota for this region is not available
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 the Subscriber Store uses counter regions are used.
In this example, counter regions model 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-2.
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.
Policy Controller 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.
Policy Controller and AFs use the ProfileDataExtension element to store custom data elements in the profile. For example, the Policy Controller itself can make policy decisions based on dynamically defined subscriber attributes.
The ExtensionId value identifies the component using 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 component that uses it.
The UserIdentifier element contains the unique identifier for an end user on a particular network. An end user 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 Policy Controller to identify subscribers internally. Policy 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.
Policy 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 to Subscriber Store mapping, see the chapter on using the Subscriber Provisioning API in 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-0 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 PcrfProfileData field mapping between the Subscriber Store and BRM database.
Table 3-2 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-3 describes the CounterProfileData field mapping between the Subscriber Store and BRM database
Table 3-3 CounterProfileDat 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-4 describes the ProfileDataExtension field mapping between the Subscriber Store and BRM database
Table 3-4 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 |
If your implementation requires it, you can use a third-party SPR/OCS that uses Diameter-based connectivity and populate it with subscriber data for Policy Controller to use. The Sy/Sp Profile Provider reads subscriber data by using the Diameter Server Signaling Unit (SSU). The Diameter-based SPR/OCS remains the system of record for subscriber data when using the Sy/SP Profile Adapter.
Configuring a Diameter-based SPR/OCS requires a basic knowledge of the Diameter protocol and its connection and routing requirements. It will be helpful to you to read through the configuring a Diameter signaling server unit section in Service Broker Signaling Server Units Configuration Guide first.
To configure an OCS using Diameter-based connectivity:
Start the Administration Console.
For details see Service Broker System Administrator's Guide
Click Lock and Edit.
Navigate to OCSB, Domain Management, then Packages.
The Bundles tab appears.
Select existing local persistence bundle from the domain. By default, it is:
oracle.ocsb.app.rcc.service.subscriber_store.providers.store.provider
Click Uninstall.
Select the Web-based Sy Profile Provider bundle:
oracle.ocsb.app.rcc.service.subscriber_store.providers.spy.common.jar
Select Start Level and set the start level to 190.
Click Start
Select the Web-based Sy Profile Provider bundle:
oracle.ocsb.app.rcc.service.subscriber_store.providers.spy.diameter
Select Start Level and set the start level to 190.
Click Start
Click Apply.
Navigate to Platform, OCSB, Signaling Tier, SSU Web Services, then SSU Diameter.
Select the SSU Diameter. node
The SSU Diameter window appears. See configuring a Diameter signaling server unit section of Service Broker Signaling Server Units Configuration Guide for details on configuring the Diameter SSU. You must configure at least these items in the Diameter SSU:
An incoming routing rule from the SSU Diameter, Routing, Incoming Routing Rules window.
Diameter nodes from the Diameter, Diameter Configuration, General window.
A Diameter default route from the Diameter, Diameter Configuration, Default Route window.
Set the OCS as a Diameter peer from the Diameter, Diameter Configuration, Default Route window.
Set the other Diameter routes from the Diameter, Diameter Configuration, Routes window
Navigate to Platform, OCSB, Processing Tier, Subscriber Store, then Provider.
The Diameter Sp/Sy window appears.
Enter the URL of your Diameter-based SPR/OCS server in the Sp DestinationRealm field.
Enter the host name of your Diameter-based SPR/OCS server in the Sp DestinationHost field.
Enter the URL of your Diameter-based SPR/OCS server in the Sy DestinationRealm field
Enter the host name of your Diameter-based SPR/OCS server in the Sy DestinationHost field.
Click Apply.
Navigate to Platform, Domain Management, Data Store, then Persistent Store.
The Persistent Stores widow appears.
Create a new Persistent Store to cache SPR/OCS information. Create either a JDBC Store, or Berkeley DB Store, depending on the database you chose during installation.
Navigate to PCRF, OCSB, Execution Blocks, then System Parameters, PCRF System Parameters.
In the Global Parameters window, fill in these items:
Primary Online Charging System address. Enter the URL of your primary OCS.
Secondary Online Charging System address. The URL of an OCS to use if the primary OCS is offline.
Default Online Charging Method. Set this to True if online charging is your default charging method. Use False otherwise.
Click Commit.
Configure the Diameter-based SPR/OCS to send notifications. See your SPR/OCS product documentation for details.
If your implementation requires it, you can use a third-party SPR/OCS that uses Web-based connectivity and populate it with subscriber data for Policy Controller to use. The Sy/Sp Profile Provider reads subscriber data by using the Web Services Signaling Unit (SSU) and populates the SPR/OCS with this information. The Web-based SPR/OCS remains the system of record for subscriber data when using the Sy/SP Profile Adapter.
To configure an OCS using Web-based connectivity:
Start the Administration Console.
For details see Service Broker System Administrator's Guide
Click Lock and Edit.
Navigate to OCSB, Domain Management, then Packages.
The Bundles tab appears.
Select the existing local persistence bundle from the domain. By default, it is:
oracle.ocsb.app.rcc.service.subscriber_store.providers.store.provider
Click Uninstall.
Select this Web-based Sy Profile Provider bundle:
oracle.ocsb.app.rcc.service.subscriber_store.providers.spy.soap.provider
Select Start Level and set the start level to 190.
Click Start
Select this Web-based Sy Profile Provider bundle: oracle.ocsb.app.rcc.service.subscriber_store.providers.spy.soap.ws
Select Start Level and set the start level to 190.
Click Start
Click Apply.
Expand to Platform, OCSB, Signaling Tier, then SSU Web Services,.
The SSU Web Services window appears. See configuring the Web services signaling server unit section of Service Broker Signaling Server Units Configuration Guide for details on configuring the Web Services SSU. You must configure at least these items in the Diameter SSU:
Incoming routing rules from the General, Incoming Routing Rules tab.
An outgoing routing rule from the General, Outgoing Routing Rules tab
HTTP server settings from the HTTP tab.
HTTP server access settings from the HTTP, Network Access tab.
HTTP client settings from the HTTP, Client tab.
SOAP access settings from the SOAP tab.
The SOAP URI path from the Subscriber Provisioning or Balance Manager tab.
The SOAP client parameters from the Client tab.
Navigate to Platform, OCSB, Signaling Tier, Subscriber Store, then Provider.
The Web Service Provider window appears.
In the Configuration tab edit the Sy Service Endpoint URL field
Enter the URL of the Web server serving the OCS.
Click Apply.
Click Commit.
Configure the Web-based SPR/OCS to send notifications. See your SPR/OCS product documentation for details.
|
 Copyright © 2011, 2013, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|
