| 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 provides information that is useful for planning and creating Oracle Communications Service Broker Policy Controller (Policy Controller) Policy Designer rules. These rules are the if-then statements that you use to determine which Policy Plans (bandwidth limits or requirements) individual subscribers are entitled to.
See "About Rules" for an overview of rules, and "Creating and Deleting Rules" for instructions on how to create rules.
You use Policy Controller rules to select which PCC and ADC profiles to apply to a subscriber in a specific context. This chapter contains conceptual information on, and examples of how to create rules that take advantage of the flexibility that Policy Controller offers. For example, this chapter explains how Policy Controller implicitly removes profiles if their condition tests no longer apply.
See "Creating Rules and Rulesets" for the step-by-step tasks that you perform to create rules, lists of values, and rulesets.
Within a session, Policy Controller makes both PCC and ADC profiles take effect when the conditions that activate them are true, and removes them implicitly when the condition no longer exists. For example, within a session assume you have a rule that states: if condition A exists, then make profile 1 take effect. In this case profile 1 remains in effect if condition A exits within that session. If during the next event processing condition A no longer exists, Policy Controller automatically stops profile 1 from taking effect. There is no need to explicitly remove profiles if the conditions that make them take effect are removed.
Note:
Rules created in Policy Controller release 6.0 are incompatible with this release.You can however, create rules that (like the release 6.0 rules) do not use the default implicit profile removal strategy. To create and use rules that explicitly remove profiles, you must first use the instructions in "(Optional) Supporting Explicit Rule Removal" to configure Policy Controller to do so. Once configured, you use the Remove_PCCProfile action in rules to explicitly remove PCC or ADC profiles.
By default, Policy Controller applies any rule actions to the current active Gx session. This section explains how to use a different criteria to select a target session for the action.
Typically subscribers only have a single session running at a time, which makes specifying an output fact (action) for that session straightforward. In cases where a subscriber has multiple simultaneous sessions running, and you want to perform comparisons and actions across sessions, you can select one as the target for the Policy Controller action using the Properties window.
The Properties window is available once you select the Show Gx/Rx Session Assignment from the Advanced menu. Each Properties window is automatically populated with choices based on the individual rule's actions and output facts.
Figure 10-1 shows an example Properties window. This figure shows that this rule uses the name, Gx, and Rx properties. The only criteria entered is the “Gold Profile” value in the name property. So if the subscriber has multiple sessions open, the rule action is applied to the one associated with the “Gold Profile” PCC rule.
To select among multiple subscriber sessions:
Start the Policy Designer.
Select the Rules tab
Select a rule.
Select Show Gx/Rx Session Assignment from the Advanced menu on the upper left of the Rules tab.
Select the xyz properties icon in the rule.
The Properties menu appears, populated with the properties options available based on the rule attributes.
For each row, select values to filter the session selection.
Use the magnifying glass icons to display the available values for each property.
Use the Constant check boxes to limit the display to constant values only.
Click OK to confirm your choices and return to the Rule tab.
Rules that use a subscriber's quota or usage-based counters are among the most flexible and popular types that you can create with the Policy Designer. These rules are generally designed to cause Policy Controller to switch a subscriber to a different PCC profile when that subscriber reaches a specific numeric threshold. For example, when they exhaust a data quota, or reach a credit limit.
One important thing to remember when using these metrics is that Policy Controller will probably not be alerted the instant a subscriber counter reaches a certain threshold. Your OCS must update Policy Controller before it can reinterpret the rules and decide whether to apply a different profile. Consequently, you should design rules that assess the threshold levels in question as their first action, and at each significant action thereafter. For example first check whether a subscriber has an active status, or sufficient account balance before allowing them access to a service.
You generally use the Sy reference point facts available in the Policy Designer Rules tab to create these threshold rules. These AVPs from the Sy specification are available to you as rule facts:
Policy-Counter-Identifier
Policy-Counter-Status
Policy controller also offers you these facts that are not in the Sy specification:
status
remainingQuota
usageCounter
total
remainingQuota
usageCounter
Here is a subscriber threshold example:
Assume that a subscriber is allowed 6 Gb of data transfer per month. You probably want to write rules that perform some action when the subscriber reaches that 6 Gb limit. Typically you would charge the subscriber an additional fee for the over-limit data. However, to avoid bill shock let's assume that you also want to warn the subscriber when they have used 80% of their quota and that they will be charged more when they reach 101%. You can implements this example using this rule framework:
IF Sy.policyCounterStatus == "WITHIN_QUOTA" THEN install a PCC profile that allows data tranfer IF Sy.policyCounterStatus == "80_PERCENT_QUOTA" THEN send the subscriber an SMS warning them of the impending fee increase IF Sy.policyCounterStatus == "OVER_QUOTA" THEN install a PCC profile that charges more for OVER_QUOTA data transfer than WITHIN_QUOTA data transfer.
This example assumes that you:
Configured your OCS to update your SPR with quota usage data.
Set up your OCS to use WITHIN_QUOTA, 80_PERCENT_QUOTA, and OVER_QUOTA, and map them to the SPR statuses.
Directed your SPR to update Policy Controller when the data usage reached 80% and 101% of quota.
It necessarily follows then that in order create rules like the ones in this example, you must know what the OCS data model is so you can map them to these Sy facts.
The chapter on using the PCP profile provider in Service Broker Subscriber Store User's Guide describes the Service Broker SPR data model and the mapping between the SPR and Oracle Communications Billing and Revenue Management. The information in that chapter helps you configure the Service Broker SPR, and the Oracle Communications Billing and Revenue Management if you are using it for an SPR. If you use a 3rd-party SPR as explained in "Configuring Subscriber Profile and Charging Information", see the third-party documentation for the data map of that SPR.
You use the Redirect condition from the Condition Browser in the THEN portion of a rule to redirect subscribers to a URL of any kind. Click Edit Properties to start a Properties window. Add the URL to redirect subscribers to in the Value field of the Properties window.
Policy Controller supports the Gx Event-Trigger AVP that you use to specify IP-CAN session modifications or other specific events that cause Policy Controller to reinterpret rules. Policy Controller supports all the events specified in the 3GPP 29.212 Gx Specification. You may either use the default specified values for the Event-Trigger AVP, or you may add custom values to this list as required by your implementation. You must first populate the Policy Controller with a complete list of events to use, or your own custom events to use.
You specify event triggers in rules by selecting Gx.Event-Trigger left value of an IF statement, using the containsEventTrigger condition, and then selecting an event trigger from list in the right value of the rule. See "Using an Event Trigger to Change a PCC Profile" for an example.
See "Supported Gx Event-Trigger Event Values" for a list of the default Gx event triggers supported by Policy Controller.
See "Add any Vendor-specific Values for Event-Trigger to Use as Event Triggers" for details on how to add your own event triggers to the default list, and see Oracle Communications Policy Controller PICS for a list of the supported Gx Event-Trigger AVP values.
Session redirection enables you to redirect Gx service data flow to a URL or other Web address. Redirection is implemented using the Gx CCR and RAR messages. The redirected session is not terminated, so the subscriber can return to using services after visiting the address. The address can be any Web address, such as a simple informational note, an offer for a different service such as topping-up accounts or authorizing a faster bandwidth, or anything else your implementation requires.
You have these options for redirecting sessions:
Global redirection that you use to redirect all traffic for a session to a single Web address using the Redirect rule action.
Service level redirection that you use to redirect individual services within a session to a Web address to which a PCC profile applies, using the RedirectPCCProfile rule action.
Note:
To redirect all traffic for a specific application, use an ADC profile. See "Creating Application Detection and Control Profiles" for details on creating ADC profiles.The redirected sessions are protected by the default revalidation timers. See "Configuring the Policy Controller Session Guard Timers" for details on setting the revalidation timers.
Both types of session redirection support these addresses types:
URL
IPv4
IPv6
SIP URI
You can enter individual redirection addresses in the rules, or create aliases for the addresses you use frequently. See "Creating Aliases for Redirection Target Addresses" for details on setting up address aliases.
The following sections explain how to set up and use session redirection.
Global redirection redirects all service data flows for a session to an address that you specify.
To globally redirect a session, specify a Gx session type in the conditions section of a rule, and then assert a Redirect action and select values for these parameters in the Properties window that appears:
address (string) - A Web address to redirect the session to. You can enter an address or an alias from a list of values that you set up beforehand. See "Creating Aliases for Redirection Target Addresses" details on setting up URL aliases.
addressType (Enum) - The Web address type. One of URL, SIP_URI, IPv4, or IPv6.
Global redirection example:
IF Gx.IPcantype == IPCanType._3GPP_GPRS THEN assert Redirect (address:www.yourco.com/topup1, addressType:RedirectAddressType.URL)
Service-based redirection redirects a single service data flow within a Gx session to a Web address and applies a new PCC profile. This redirection requires that you have a PCC profile to apply to the service, so create it before you create the redirection rule.
To redirect a single service data flow, specify a Gx session type in the conditions part of the rule, then assert a RedirectProfile action, and enter values for these parameters in the Properties window that appears:
policyProfileName (String) - A PCC profile to apply to the service.
address (string) - A URL to redirect the session to. You can enter an address or an alias from a list of values that you set up beforehand. See "Creating Aliases for Redirection Target Addresses" details on setting up URL aliases.
addressType (Enum) - The URL address type. One of URL, SIP_URI, IPv4, or IPv6.
Service-based redirection example:
IF Gx.IPcantype == IPCanType.WIMAX THEN assert Redirect (profileName:"Silver Profile", address:www.myco.com, addressType:RedirectAddressType.URL, Gx:Gx)
If your list of redirection addresses is relatively static, use the Policy Designer List of Values feature to create a list of address aliases to use as redirection targets in rules. Figure 10-2 shows the List of Values window that you use to create a list of addresses. In this example the www.yourCo.com website has the topup1, topup2, and topup3 pages that are available to redirect subscribers to. The idea is to use different topup pages depending on which tiered service the subscriber is using.
To create a specific list of URLs for redirection:
Start Policy Designer interface
Navigate to Rules tab
Click List of Values.
The List of Values screen appears.
Click RedirectionAddresses from the list and then the Edit List of Values (pencil) icon.
The List of Values Editor window appears.
Click the Add Values (green cross) icon.
A row for the new value appears in the table.
Value - enter the new URL.
Alias - Enter a string to use in your rules. The name should be short but meaningful to those creating the rules.
Allowed in Actions - Checking this box allows the value to be used in the actions (THEN) portions of a rule. If unchecked, your values are only allowed in the conditions (IF) section of a rule.
Description - Enter an informal description of the new URL.
Repeat step 6 for each address that you want to use in your rules.
Click OK.
Policy Designer enables you to send an SMS message as part of the action of a rule. You do this by first setting up a test for any fact available in the IF portion of the rule, and then using the SendSMS action in the THEN portion of the rule. The test is performed each time a subscriber creates a session and thereafter any time your rules are reinterpreted.
Policy Controller adheres to the Interface protocols for the connection of Short Message Service Centres (SMSCs) to Short Message Entities (SMEs) (Release 5) 3GPP TR 23.039 V5.0.0 (2002-06) specification for SMS messages.
You can create rules that send SMS messages based on any changed fact that causes rules to be reinterpreted, such as:
Simply wishing the subscriber a happy birthday.
Alerting a subscriber that they have changed location and are about to incur roaming charges.
Warning a subscriber that they have reached a monetary threshold and offering to top-up their account.
Alerting a subscriber that they have reached their monthly bandwidth usage limit and are being charged at a higher rate for the remainder of the period.
Alerting a subscriber that they have exceeded their download usage threshold and their service is being throttled back.
Alerting your security personnel of suspicious activity on behalf of a subscriber.
Note:
The rule test for sending an SMS (or any other action) is performed each time a subscriber starts a session and perhaps more often. So for example a subscriber would receive a birthday greeting every time they log in on their birthday.The test is performed each time the subscriber logs in. So each time they log in on their birthday they receive the birthday greeting SMS.
The SMS can be a simple text message or it can be a part of a rule that automatically changes a subscriber's PCC profile. The SMS can contain a URL that directs the subscriber to a website for more information, or to a Web portal they use to change their account details. You can also probe for additional facts and send different SMS messages within a single session.
You can send the SMS to one, or any number of MSIDN numbers. The SMS can alert an entire group that its bandwidth is used up.
The SMS messages are sent in “fire and forget” mode. That is, Policy Controller does not wait for or record any response from the MSISDN receiving the SMS.
See "(Optional) Configuring Policy Controller to Send SMS Messages" for details on configuring this feature.
Before you can add SMS messages to rules you must first configure Policy Controller as an External Short Messaging Entity (ESME). You do this by configuring a Short Message Service Center (SMSC) in the SSU SMPP. See the discussion on configuring an SMPP signaling server unit in Service Broker Signaling Server Units Configuration Guide for details.
You use the SendSMS function in the THEN portion of your rule to create an SMS message. Select Assert New then SendSMS, and then click the Properties icon. The Properties screen appears with fields for:
Source Number - The number of the SSU SMPP SMSC you have configured to send SMS messages. The number sending the SMS, for example “11111”
Destination Number - A comma-separated list of one or more MSISDN numbers that specify the SMS recipients. For example “11111,22222,44444” sends this message to the numbers 11111, 22222, and 44444.
Message - The text of the message. The SMS supports only Latin-based characters. Enter text, or select the search icon to include Sp and Sy facts, and use Redirect.Address to include a URL. For example “Your license has expired. Please add resources to your account.”
You can fill in these fields with text and click the Constant check box, or select the search icon to use dynamic data (rule facts) in the SMS.
After filling in these text fields, click OK to save your changes. The text of the SMS is displayed in the Rule Editor window next to the Edit Properties icon.
The Service Broker Diameter stack supports the Diameter AVPs listed in the Oracle Communications Service Broker Policy Controller Protocol Implementation Conformance Statement. However, many Policy Controller nodes such as Policy Controller Enforcement Functions (PCEFs), Application Functions (AFs), and so on, use AVPs from protocols that Policy Controller does not support. Service Broker includes the ability to add these custom AVPs to its Diameter stack. This allows Policy Controller to accept these AVPs in messages, but it does not do anything with their contents by default.
After adding custom AVPs to Service Broker, you must create rules that use their content. Before adding a custom AVP, you first need to plan the kinds of IF-THEN rule tests required for using the new AVP.
See "Adding Custom Diameter AVPs" for details on adding custom AVPs to Service Broker for Policy Controller to use, and also the data types available and the supported functions for the new AVPs.
Because of the flexibility and extensibility of the Policy Controller rules engine, you can create any number of rules and rule strategies. The following examples show a few of the most common scenarios.
A common rule task is to install a PCC profile based on a change in subscriber data.
For example, the Policy Controller can regularly compare the current date to the month and date of the subscriber's birthday and install a special PCC profile on the subscriber's birthday:
IF Sp.dateOfBirth.month is SystemVariables.currentTime.month AND Sp.dateOfBirth.dayOfMonth is SystemVariables.currentTime.dayOfMonth THEN InstallPCCProfile (name: "BirthDay")
This rule specifies that subscribers using Prepaid PCC profile services from a 69.63.189.* IP address also receive the Prepaid_SocialVoice_Plan PCC profile:
IF Sp.accountType is "PREPAID AND Gx.TFT-Packet-Filter-Information matchToAddress "69.63.189.*") THEN InstallPCCProfile (name: "Prepaid_SocialVoice_Plan")
This example creates a "happy hour" rule that applies a PCC profile when the current time is between 18:00 and 20:00 each day:
IF Gx.MS-TimeZone_3GPP.hourOfDay is less than 18 THEN setAbsoluteRevalidatonTime.date to (date:getCalendarAtHour(18)) IF Gx.MS-TimeZone_3GPP.hourOfDay is same or more than 18 AND Gx.MS-TimeZone_3GPP.hourOfDay is less than 20 THEN InstallPCCProfile HAPPYHOUR AND setAbsoluteRevalidationTime.date to (date:GetCalendarATHour(20)) If Gx.MS-TimeZone_3GPP.hourOfDay is greater than or equal to 20 THEN setAbsoluteRevalidationTime.date to (date:GetCalendarAtHour(18))
This ruleset first checks whether the current time is earlier than 18:00, and if so it directs Policy Controller to revalidate its rules at 18:00.
If the ruleset finds that the current time is between 18:00 and 20:00, it applies a PCC profile called HAPPYHOUR, and directs Policy Controller to reapply its rules when the current time reaches 20:00. Once the rules are reapplied and the time is not between 18:00 and 20:00, the HAPPYHOUR profile is no longer applied.
If the current time is later than 20:00, it directs Policy Controller to revalidate its rules when the current time reaches 18:00 the next day.
This ruleset requires the use of the GetCalendarAtHour function. See "Using the Expression Builder" for details on using the Expression Builder to select a function.
Receipt of a trigger from the PCEF can initiate a change in a PCC profile.
For example, upon receiving the OUT_OF_CREDIT trigger, Policy Controller can remove a subscriber's installed PCC profile and install another one:
IF GxEventTrigger containsEventTrigger EventTrigger.OUT_OF_CREDIT) AND Sp.subscriberCategory in "GOLD" , "BRONCE" , "SILVER" THEN InstallPCCProfile (name: "LEAD")
This example shows two rules that would work to throttle back service for a subscriber that has run out of credit. These rules specify that when the Policy Controller receives a Gx-based OUT_OF_CREDIT event, a NoCredit_Plan PCC profile is applied which contains throttled back service.
This rule applies a NoCredit_Plan PCC profile when an OUT_OF_CREDIT event is received:
IF Gx.Event-Trigger containsEventTrigger EventTrigger.OUT_OF_CREDIT AND Gx.RAT-Type is RATType.HSPA_EVOLUTION THEN InstallPCCProfile (name: "NoCredit_Plan") AddEventTriger(eventTrigger:EventTrigger.REALLOCATION_OF_CREDIT )
This rule removes the NoCredit_Plan PCC profile when a REALLOCATION_OF_CREDIT event is received indicating that the subscriber has.
Gx.Eevent-Trigger containsEventTrigger EventTrigger.REALLOCATION_OF_CREDIT AND Gx.RaTType is RATType.HSPA_EVOLUTION THEN RemovePCCProfile (name:"NoCreditPlan") AddEventTrigger(eventTrigger:EventTrigger.OUT_OF_CREDIT)
You can create a local fact for special custom values.
Local facts are especially useful for complex scenarios involving multiple rules. For example, suppose there are three different rules:
RULE_1 applies to subscribers over age 25.
RULE_2 applies to members of the SILVER subscriber category.
RULE_3 applies to subscribers using WIFI.
You want to install a particular profile named SPECIAL_RULE if any two of these three rules apply.
You could create a local fact named numberOfRules with an integer value initialized to 0 and increment that value every time a rule is added. When the local fact's value reaches 2, the SPECIAL_RULE PCC Profile is applied. The following rules accommodate this scenario:
IF Gx isn't null THEN LocalFact (integerValue:0; stringValue:"numberOfRules") IF Sp.dateOfBirth.year more than System Variables.currentTime.year - 25, AND LocalFact.name is "numberOfRules" THEN InstallPCCProfile (name:"RULE_1) Modify LocalFact (integerValue:localFact.integerValue +1) IF SP.subscriberCategory is "SILVER" and LocalFact.name is "numberOfRules" THEN InstallPCCProfile (name:"Reule_2") Modify LocalFact (IntegerValue:LocalFact.integerValue+1) IF Gx.IP-CAN-Type is IPCanType.WIMAX and LocalFact.name is 'numberOfRules' THEN InstallPCCProfile (name:"Rule_3" Modify LocalFact (integerValue:LocalFact.integerValue+1) IF LocalFact.integerValue is 2 THEN InstallPCCProfile (name:"SPECIAL_RULE")
|
 Copyright © 2011, 2013, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|
