CRE 2.6.2 Reference Guide Ver1.6

REFERENCE GUIDE
Version 1.6
Alcatel-Lucent 8618
CONVERGENT RATING ENGINE | RELEASE 2.6.2
11 September 2009
3CL-02660-BAHA-PCZZA
Convergent Rating Engine 2.6.2
Reference Guide | version 1.6
Table of Contents
Table of Contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
Part I.
1.
1.1. 1.2. 1.3. 1.4. 1.5. 1.6. 1.7. 1.8.
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Context . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Purpose and Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Intended Audience . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Related Documents. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . General Abbreviations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Technical Abbreviations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Technical Terms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Data Type of the GUI Entry Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 23 23 23 24 24 26 35
2.
2.1. 2.2. 2.3.
Whats New in Alcatel-Lucents OSP 2.4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

An Application Running on Your PC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Logging in to the OSP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2.1. Working Offline Vs. Online . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2.2. Log-in Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Graphical User Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3.1. In the Views Panel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3.2. In the Windows Frame . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3.3. In the Menu Bar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3.4. In the Tool Bar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3.5. In the Message Area . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3.6. In the Status Bar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Managing LiteSCE Flexibility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Finding More Information About OSP 2.4. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 39 39 41 43 45 46 47 49 49 49 49 50
2.4. 2.5.
Part II.
3.
3.1.
Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
OSP Level Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

Creating a Custom Profile for Your CRE Provider Operators . . . . . . . . . . . . . . . . . . . . . . . . 3.1.1. What You Need to Take Care Of . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.1.2. Investigating Dependencies Between Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.1.3. Troubleshooting Profiles that You Have Set up . . . . . . . . . . . . . . . . . . . . . . . . . . . . Creating an Operator Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . CRE Objects Access Rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.3.1. The Access Rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.3.2. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.3.3. Whats a Provider Group? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Creating a CRE Provider Operator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Creating a Service retailer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 54 55 57 57 57 57 58 59 60 65
3.2. 3.3.
3.4. 3.5.
4.
4.1.
Mandatory Convergent Rating Engine Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

RE Configuration Object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 4.1.1. Object Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 4.1.2. General Tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 4.1.2.1. Parameter Description. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .69
11 September 2009
Page 3 of 968
4.1.2.2. Setting Up Your Account Partitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74 4.1.3. Levels, Modules and Connectors Tabs Parameter Description . . . . . . . . . . . . . . . . . . . 74 4.1.3.1. Reminder About Flexibility Points. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74 4.1.3.2. Purpose of the Tabs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74 4.1.3.3. Levels Tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
4.1.3.3.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74 4.1.3.3.2. Parameter Description. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75 4.1.3.3.3. The Levels (Object Classes Priorities). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
4.1.3.4. Modules Tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

4.1.3.4.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76 4.1.3.4.2. Whats a Module. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76 4.1.3.4.3. Parameter Description. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
4.1.3.5. Connectors Tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

4.1.3.5.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78 4.1.3.5.2. Whats a Connector. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78 4.1.3.5.3. Parameter Description. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
4.1.4. Statistics Tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81 4.1.4.1. When Does the CRE Use these Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81 4.1.4.2. Parameter Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82 4.1.4.3. Tips. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
4.1.4.3.1. Basic Recommendation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.1.4.3.2. To Always Send a Full (i.e. RE + CE) EDR to the RTx . . . . . . . . . . . . . . . . . . . . . . . . 4.1.4.3.3. To Never Send an EDR to the RTx . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.1.4.3.4. To Always Send a Full (i.e. RE + CE) EDR to a Given External Module . . . . . . . . . . . . . 4.1.4.3.5. To Never Send a Full (i.e. RE + CE) EDR to a Given External Module . . . . . . . . . . . . . 83 84 84 84 84
4.2.
4.3.
4.1.5. SEP Groups Tab Parameter Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85 4.1.6. Fees Tab Parameter Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87 4.1.7. ARENA Tab Parameter Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89 4.1.7.1. Global Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89 4.1.8. Partition Range Tab Parameter Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90 4.1.9. Advanced Tab Parameter Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93 CE Configuration Object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96 4.2.1. Object Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96 4.2.2. General Parameters and Forwarding of Statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . 97 4.2.2.1. Parameter Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97 4.2.2.2. Tips. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100 4.2.3. Communication Tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101 4.2.4. Context Tab. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103 4.2.4.1. Purpose of the Tab. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103 4.2.4.2. Parameter Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104 4.2.4.3. Sizing a Contexts Table. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108 4.2.5. LiteSCE Tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109 4.2.5.1. Modules Sub-Tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109 4.2.5.2. Connectors Sub-Tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110 4.2.5.3. Level Sub-Tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112 4.2.6. ARENA Tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113 Scheduling Engine (SE) Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114 4.3.1. The SE Service Runs per SMF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114 4.3.2. Using the CRE Main Menu to Configure the SE Services . . . . . . . . . . . . . . . . . . . . . . . 115 4.3.3. SE Configuration Object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118 4.3.3.1. Object Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118 4.3.3.2. Services Tab Parameter Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118 4.3.3.3. General Tab Parameter Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119 4.3.3.4. CRE Load Thresholds Tab Parameter Description . . . . . . . . . . . . . . . . . . . . . . . . . 122
4.3.3.4.1. Computing the CRE CPU Load . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123 4.3.3.4.2. Determining the Size of the Packets: Rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
4.3.3.5. Errors Handling Tab Parameter description . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125 4.3.4. SE Partition Object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129 4.3.4.1. Object Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
Page 4 of 968
11 September 2009
4.3.4.2. How many Partitions do I have to create? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129 4.3.4.3. Partition Name Parameter Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129 4.3.4.4. General Tab Parameter Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
4.3.4.4.1. How to manually launch a Scheduled Event . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
4.3.4.5. 4.3.4.6. 4.3.4.7. 4.3.4.8.
Service Tab Parameter Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134 SEP Groups Tab Parameter Description. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135 Thresholds Tab Parameter Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136 Statistics Tab Parameter Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
4.4. 4.5. 4.6.
4.7. 4.8.
Service Retailer Object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139 4.4.1. Object Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139 4.4.2. Parameter Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139 Language Object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149 4.5.1. Object Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149 4.5.2. Parameter Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150 Calendar Object. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150 4.6.1. Object Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150 4.6.2. Parameter Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151 4.6.3. Calendar GUI Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152 4.6.3.1. Modifying the Name of a Day Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152 4.6.3.2. Assigning a Day to a Given Day Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152 4.6.3.3. Removing a Day from a Given Day Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152 Result Code Object. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152 4.7.1. Object Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152 4.7.2. Parameter Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153 Partition Ranges Object. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153 4.8.1. Object Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153 4.8.2. Parameter Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155 4.8.3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158 4.8.3.1. Example for None Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158 4.8.3.2. Example for External Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158 4.8.3.3. Example for Range Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159
5.
5.1.
Optional Convergent Rating Engine Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161

Notification Feature Table Object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161 5.1.1. Object Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161 5.1.1.1. Whats a Notification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161 5.1.1.2. Whats a Notification Feature. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161 5.1.1.3. Whats the Index ID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162 5.1.1.4. Whats a Rating Engine Number? Whats a Feature Id?. . . . . . . . . . . . . . . . . . . . . . 162
5.1.1.4.1. How the CRE Identifies its Notification Features: The Rating Engine Number . . . . . 162 5.1.1.4.2. How the UNS Identifies its Notification Features: The Feature Id . . . . . . . . . . . . . 163
5.1.1.5. Notification Feature Table Object Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163

5.1.1.5.1. Converting a Rating Engine Number into a Feature Id . . . . . . . . . . . . . . . . . . . . 164 5.1.1.5.2. Enabling/Disabling a Given Notification Feature in the CRE . . . . . . . . . . . . . . . . . . 164
5.2.
5.1.2. Parameter Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164 5.1.3. Notification Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166 5.1.4. Tips . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174 5.1.4.1. Enabling a Notification Feature in the CRE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174 5.1.4.2. Initial Set Up of the Notification Feature Table . . . . . . . . . . . . . . . . . . . . . . . . . 176 5.1.5. Enabling a Given Notification Type on a Given Account. . . . . . . . . . . . . . . . . . . . . . 176 5.1.5.1. Enabling Reload on Main Account Notification Type on a Given Account . . . . . . . . . 176 5.1.5.2. Enabling a Given Notification Type on a Given Account . . . . . . . . . . . . . . . . . . . . . 178 5.1.6. Specifying the MSISDN and/or the E-Mail Address of the Notifications . . . . . . . . . . . . 182 5.1.7. Indicating Whether a Notification Is to Be Sent by SMS or by E-mail. . . . . . . . . . . . . . 183 5.1.8. What Does When a Notification Feature Sees that... Means . . . . . . . . . . . . . . . . . . 184 Out of Call Processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187 5.2.1. What It Is About . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187 5.2.2. What It Does . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187
11 September 2009
Page 5 of 968
5.2.2.1. OOC Macros 1-7 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188 5.2.2.2. Macro 0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192
5.3. 5.4.
5.2.3. Configuring the Out Of Call Processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192 5.2.3.1. Setting Up the Macros Timebands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192 5.2.3.2. Preventing OOC Processing to Work When CPU Load Is Too High . . . . . . . . . . . . . . . 192 5.2.3.3. Sizing the Macro Runs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192 5.2.4. Out of Call Object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194 5.2.4.1. Object Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194 5.2.4.2. Main Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194 5.2.4.3. OOC Tab. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195 5.2.4.4. Postpaid OOC Tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196 5.2.4.5. Prepaid OOC Tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197 5.2.4.6. Session OOC Tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198 5.2.5. Out of Call TimeBand Object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198 5.2.5.1. Object Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198 5.2.5.2. Parameter Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199 Tariff Tester Object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199 5.3.1. Object Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199 5.3.2. Parameter Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201 Statistic Cycle Object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215 5.4.1. Object Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215 5.4.2. Parameter Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215
Part III.
6.
6.1. 6.2.
Product Catalog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .218

Service Identification. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219

Network Event Type object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219 6.1.1. Object Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219 6.1.2. Parameter Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220 Service Rule object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224 6.2.1. Object Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224 6.2.1.1. Why Service Rules?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224 6.2.1.2. Typical Service Rules Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224 6.2.2. Parameter Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226 6.2.3. Making Up a Service Rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227 6.2.3.1. The criteria . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227 6.2.3.2. The Leaves . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227
7.
7.1.
Types of Service Offers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228

Service Types based on the Events Characteristics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229 7.1.1. Usage Events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229 7.1.2. Non-usage Events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229 7.1.2.1. Discrete non-usage events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 230 7.1.2.2. Recurring non-usage events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 230 7.1.3. Top-up Events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 230 Usage Rating Rule object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232 7.2.1. Object Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232 7.2.2. Parameter Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233 7.2.3. Making Up a Usage Rating Rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234 7.2.3.1. The criteria . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234 7.2.3.2. The Leaves . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234 Service Offer Definition object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235 7.3.1. Object Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235 7.3.2. Parameter Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235 Top-up Rule object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252 7.4.1. Object Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252
7.2.
7.3. 7.4.
Page 6 of 968
11 September 2009
7.4.2. Parameter Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252 7.4.3. Making Up a Top-Up Rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253 7.4.3.1. The criteria . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253 7.4.3.2. The Leaves . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253
8.
8.1. 8.2. 8.3.
Guiding Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254 Commercial Offer Application Order . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254 Charging Rule object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255 8.3.1. Object Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255 8.3.2. Parameter Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255 8.3.3. Making Up a Charging Rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 256 8.3.3.1. The criteria . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 256 8.3.3.2. The Leaves . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 256 Rating Plan Rule object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257 8.4.1. Object Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257 8.4.2. Parameter Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257 8.4.3. Making Up a Rating Plan Rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 258 8.4.3.1. The criteria . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 258 8.4.3.2. The Leaves . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 258
8.4.
9.
9.1. 9.2. 9.3.
Catalog Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259

Catalog Creation Logic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259 9.1.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259 9.1.2. Object Provisioning Order . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259 Service Object. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 260 9.2.1. Object Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 260 9.2.2. Parameter Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 260 Commercial Offer Object. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261 9.3.1. Object Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261 9.3.1.1. Important Limitation on Commercial Offers . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261
9.3.1.1.1. For baring service offer groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261 9.3.1.1.2. Not supporting the swaping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262
9.4. 9.5. 9.6.
9.7. 9.8.
9.9.
9.3.2. Parameter Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262 Package Object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263 9.4.1. Object Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263 9.4.2. Parameter Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264 Service Offer Object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 265 9.5.1. Object Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 265 9.5.2. Parameter Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266 Service Offer Group Object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 270 9.6.1. Object Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 270 9.6.1.1. Add-On Service Offer Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 270 9.6.1.2. Barring Service Offer Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271 9.6.2. Parameter Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273 Service Offer Link Object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274 9.7.1. Object Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274 9.7.2. Parameter Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275 Service Offer Group Link Object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 276 9.8.1. Object Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 276 9.8.1.1. Default and Optional Service Offer Groups of a Commercial Offer . . . . . . . . . . . . . 276 9.8.1.2. Active Service Offer Groups of a Commercial Offer . . . . . . . . . . . . . . . . . . . . . . . 276 9.8.2. Parameter Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 277 Package Link Object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 278 9.9.1. Object Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 278 9.9.2. Parameter Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 279
11 September 2009
Page 7 of 968
9.10. Bundle/Counter Usage Label Object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 280 9.10.1.Object Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 280 9.10.2.Parameter Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 280 9.11. Product Catalog Performance Improvement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284
10.
Users Portfolio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 285
10.4.4.2.1.Conditions for automatically activating a Subscription . . . . . . . . . . . . . . . . . . . . . . 300 10.4.4.2.2.Implementation and Call Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 301
10.4.4.3. 10.4.4.4. 10.4.4.5. 10.4.4.6.
State and Dates: troubleshooting discrepancies. . . . . . . . . . . . . . . . . . . . . . . . . . Subscription States Transitions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Removing a Subscription . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Subscription History . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
302 303 304 304
10.5. Scheduled Event Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 305 10.5.1.Object Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 305 10.5.1.1. Standard Mode: Display Functionality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 305 10.5.1.2. Advanced Mode: Provisioning Functionality . . . . . . . . . . . . . . . . . . . . . . . . . . . . 306
10.5.1.2.1.Why Manually Creating a Scheduled Event?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 306 10.5.1.2.2.Priority of Manually Created Scheduled Events . . . . . . . . . . . . . . . . . . . . . . . . . . . 306
10.5.1.3. Customer or Account? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 307 10.5.2.Scheduled Customer Event Object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 307 10.5.2.1. Parameter Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 307 10.5.3.Scheduled Account Event Object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313 10.5.3.1. Parameter Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313 10.5.4.Scheduled Events Statuses. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 314 10.5.4.1. Status List Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 314 10.5.4.2. Scheduled Events Status Transitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 316
10.5.4.2.1.In case of successful execution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 317 10.5.4.2.2.In case of unsuccessful execution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 317
10.5.4.3. Termination Vs. Cancellation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 318 10.6. Subscription Times . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 318 10.6.1.Activation Fees . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 318 10.6.2.Cancellation Fees . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 320 10.6.3.Cancelling a Suspended Subscription . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 320
11.
Versioning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 324
11.1. Functionality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 324
Page 8 of 968
11 September 2009
10.1. What defines a Users Portfolio?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 285 10.1.1.First and main link to the Product Catalog: link to a Commercial Offer . . . . . . . . . . . 286 10.1.2.Second type of link to the Product Catalog: Subscriptions . . . . . . . . . . . . . . . . . . . . 286 10.1.3.Third type of link to the Product Catalog: Scheduled Events . . . . . . . . . . . . . . . . . . 287 10.2. Visualizing what binds a user to the Product Catalog . . . . . . . . . . . . . . . . . . . . . . . . . . . . 287 10.3. Commercial Offer Link Object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 288 10.3.1.Object Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 288 10.3.1.1. Important corollaries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 288 10.3.1.2. One or more Commercial Offer(s) per Customer?. . . . . . . . . . . . . . . . . . . . . . . . . 288 10.3.2.Parameter Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 289 10.4. Subscription Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 290 10.4.1.Object Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 290 10.4.1.1. Customer or Account? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 290 10.4.2.Customer Subscription Object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 291 10.4.2.1. Parameter Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 291 10.4.2.2. Automatic Customer Subscription Activation . . . . . . . . . . . . . . . . . . . . . . . . . . . 295 10.4.3.Account Subscription Object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 295 10.4.3.1. Parameter Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 295 10.4.4.Subscriptions Life Cycle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 296 10.4.4.1. Subscription States . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 296 10.4.4.2. Automatic Subscription Activation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 299
11.2. Versioned Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 324 11.3. Versioning Life Cycle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 325 11.3.1.Concurrent Versions Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 326 11.3.2.Impact of the Life Cycle on the Event Processing . . . . . . . . . . . . . . . . . . . . . . . . . 327 11.3.2.1. Object Identification Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 327 11.3.2.2. Versioning Consistency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 328 11.3.3.Impact on the Product Catalog Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . 328
12.
Decision Trees . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 329
12.1. Criteria and Leaves. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 329 12.1.1.Whats a Criterion? Whats a Leaf? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 329 12.1.2.The Kinds of Criteria - The Criteria Palette . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 331 12.1.3.The Kinds of Leaves - The Leaves Palette . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 331 12.2. Managing a Decision Tree . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 332 12.2.1.Creating a Decision Tree . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 333 12.2.2.Consulting or Modifying a Decision Tree . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 349 12.2.3.Removing a Decision Tree . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 355 12.2.4.Moving a Decision Tree from One CRE Platform to the Other . . . . . . . . . . . . . . . . . 356 12.2.4.1. Exporting a Decision Tree . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 356 12.2.4.2. Importing a Decision Tree . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 360 12.2.5.Duplicating a Decision Tree . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 366 12.2.5.1. Exporting a Decision Tree Under a Different Name . . . . . . . . . . . . . . . . . . . . . . . . 366 12.2.5.2. Importing a Decision Tree that Was Exported Under a Different Name . . . . . . . . . . . 375 12.2.6.Nodes versus Branches. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 376 12.3. The Criteria . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 378 12.3.1.Generalities. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 379 12.3.1.1. Used Network Event Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 379 12.3.1.2. Intermediate Commit and Final Commit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 380 12.3.1.3. Order of Use of the Criteria . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 381 12.3.1.4. Design Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 381 12.3.1.5. Switching of Tariff, of Customer Account, of Service Offer, of Service . . . . . . . . . . 382
12.3.1.5.1.Whats a Switching? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 382 12.3.1.5.2.Why Would a Rule Return Another Leaf?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 382 12.3.1.5.3.What Switching Does the CRE Support?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 382
12.3.1.6. Which Criterion Is Available in Which Kind of Rule . . . . . . . . . . . . . . . . . . . . . . . . 383 12.3.2.Association Type Criterion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 384 12.3.2.1. Criterion Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 384 12.3.2.2. Understanding the Association Type Criterion . . . . . . . . . . . . . . . . . . . . . . . . . . 384
12.3.2.2.1.Whats a Community? Why a Community? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12.3.2.2.2.The Current Customer of a Rule Is Not Necessarily the Calling Customer. . . . . . . . . 12.3.2.2.3.Whats an Association Type?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12.3.2.2.4.Typical Example. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 384 384 385 385
12.3.2.3. Criterion Parameter Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 386 12.3.2.4. Criterion Availability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 386 12.3.2.5. Criterion Context . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 386
12.3.3.Bundle Criterion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 387 12.3.3.1. Criterion Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 387 12.3.3.2. Understanding the Bundle Criterion. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 387 12.3.3.3. What Constraints Apply to a Bundle Criterion?. . . . . . . . . . . . . . . . . . . . . . . . . . . 389 12.3.3.4. Using a Bundle/Counter Usage Label as the Name of a Bundle . . . . . . . . . . . . . . . . 389 12.3.3.5. Criterion Parameter Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 390 12.3.3.6. Criterion Parameter Description for Advance Bundle Criteria. . . . . . . . . . . . . . . . . 391 12.3.3.7. Tip: Creating and Exploiting a Bundle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 392 12.3.3.8. Criterion Availability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 393 12.3.3.9. Correlation supported by Advance Bundle Criteria . . . . . . . . . . . . . . . . . . . . . . . . 393 12.3.3.10.Criterion Context. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 395 12.3.4.Bundle Threshold Criterion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 396 12.3.4.1. Criterion Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 396
11 September 2009
Page 9 of 968
12.3.4.2. Criterion Parameter Description. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 397 12.3.4.3. Criterion Availability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 398 12.3.4.4. Criterion Context . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 398
12.3.5.Closed User Group Criterion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 399 12.3.5.1. Criterion Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 399 12.3.5.2. Criterion Parameter Description. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 399 12.3.5.3. Criterion Availability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 400 12.3.5.4. Criterion Context . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 400 12.3.6.Counter Criterion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 401 12.3.6.1. Criterion Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 401 12.3.6.2. Using a Bundle/Counter Usage Label as the Name of an Accounts Counter . . . . . . . 401 12.3.6.3. Criterion Parameter Description. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 402 12.3.6.4. Tip: Creating and Exploiting a Counter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 404 12.3.6.5. Tip: What If a Tariff Switch Makes A Rule Re-Execute a Counter Criterion? . . . . . . . 405 12.3.6.6. Criterion Availability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 406 12.3.6.7. Criterion Context . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 406 12.3.6.8. Counter Handling in various Cancel scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . 406 12.3.7.Counter Threshold Criterion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 408 12.3.7.1. Criterion Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 408 12.3.7.2. Criterion Parameter Description. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 408 12.3.7.3. Tariff Switches that Are Due to a Counter Threshold Criterion. . . . . . . . . . . . . . . . 410 12.3.7.4. Criterion Availability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 412 12.3.7.5. Criterion Context . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 412 12.3.8.Date Criterion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 413 12.3.8.1. Criterion Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 413 12.3.8.2. Criterion Parameter Description. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 413 12.3.8.3. Tariff Switches that Are Due to a Date Criterion. . . . . . . . . . . . . . . . . . . . . . . . . 414 12.3.8.4. Criterion Availability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 414 12.3.8.5. Criterion Context . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 414 12.3.9.Destination Criterion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 415 12.3.9.1. Criterion Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 415 12.3.9.2. Criterion Parameter Description. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 415 12.3.9.3. Criterion Availability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 416 12.3.9.4. Criterion Context . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 416 12.3.10.Destination Zone Criterion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 418 12.3.10.1.Criterion Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 418 12.3.10.2.Criterion Parameter Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 418 12.3.10.3.Criterion Availability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 418 12.3.10.4.Criterion Context . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 418 12.3.11.Discount Criterion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 420 12.3.11.1.Criterion Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 420 12.3.11.2.Criterion Parameter Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 421 12.3.11.3.How Discounts Cumulate. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 422 12.3.11.4.Criterion Availability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 423 12.3.11.5.Criterion Context . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 423 12.3.12.Event Type Criterion. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 424 12.3.12.1.Criterion Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 424 12.3.12.2.Criterion Parameter Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 424 12.3.12.3.Criterion Availability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 425 12.3.12.4.Criterion Context . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 425 12.3.13.Friends and Family Criterion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 426 12.3.13.1.Criterion Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 426 12.3.13.2.Criterion Parameter Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 426 12.3.13.3.Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 427 12.3.13.4.Criterion Availability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 428 12.3.13.5.Criterion Context . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 428 12.3.14.Generic Criterion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 429 12.3.14.1.Criterion Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 429 12.3.14.2.Criterion Parameter Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 430
Page 10 of 968
11 September 2009
12.3.14.3.Availability of the Objects the Generic Criterion Explorer Shows . . . . . . . . . . . . . . 433 12.3.14.4.Criterion Availability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 434 12.3.14.5.Criterion Context. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 434
12.3.15.Grant Criterion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 435 12.3.15.1.Criterion Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 435 12.3.15.2.Criterion Parameter Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 436 12.3.15.3.Criterion Availability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 437 12.3.15.4.Criterion Context. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 437 12.3.16.LiteSCE Criterion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 438 12.3.16.1.Criterion Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 438 12.3.16.2.Criterion Parameter Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 438 12.3.16.3.Criterion Availability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 440 12.3.16.4.Criterion Context. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 440 12.3.17.Main Balance Criterion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 441 12.3.17.1.Criterion Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 441 12.3.17.2.Criterion Parameter Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 443 12.3.17.3.What happens in case of Tariff Switch? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 443 12.3.17.4.Criterion Availability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 444 12.3.17.5.Criterion Context. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 444 12.3.18.Origin Criterion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 445 12.3.18.1.Criterion Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 445 12.3.18.2.Criterion Parameter Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 445 12.3.18.3.Criterion Availability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 449 12.3.18.4.Criterion Context. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 449 12.3.19.Originating Zone Criterion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 450 12.3.19.1.Criterion Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 450 12.3.19.2.Criterion Parameter Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 450 12.3.19.3.Criterion Availability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 451 12.3.19.4.Criterion Context. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 451 12.3.20.Preferred Number Criterion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 452 12.3.20.1.Criterion Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 452 12.3.20.2.Criterion Parameter Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 452 12.3.20.3.How Discounts Cumulate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 453 12.3.20.4.Criterion Availability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 453 12.3.20.5.Criterion Context. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 453 12.3.21.Promotion Criterion. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 454 12.3.21.1.Criterion Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 454 12.3.21.2.When Should You Use the Promotion Criterion . . . . . . . . . . . . . . . . . . . . . . . . . . 454 12.3.21.3.Criterion Parameter Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 455 12.3.21.4.How Discounts Cumulate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 455 12.3.21.5.Criterion Availability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 456 12.3.21.6.Criterion Context. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 456 12.3.22.Service Criterion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 457 12.3.22.1.Criterion Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 457 12.3.22.2.Criterion Parameter Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 457 12.3.22.3.What Is the Service that is Being Processed? . . . . . . . . . . . . . . . . . . . . . . . . . . . . 457 12.3.22.4.Criterion Availability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 458 12.3.22.5.Criterion Context. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 458 12.3.23.Subscription Criterion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 459 12.3.23.1.Criterion Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 459 12.3.23.2.Criterion Parameter Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 459 12.3.23.3.Whats the Current User? Whats the Current Commercial Offer? . . . . . . . . . . . . . . 459 12.3.23.4.Whats the Current Package? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 460 12.3.23.5.Criterion Availability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 461 12.3.23.6.Criterion Context. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 461 12.3.24.Supervision Criterion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 462 12.3.24.1.Criterion Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 462 12.3.24.2.Criterion Parameter Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 463 12.3.24.3.Criterion Availability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 464
11 September 2009
Page 11 of 968
12.3.24.4.Criterion Context . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 464 12.3.25.Time Criterion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 465 12.3.25.1.Criterion Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 465 12.3.25.2.Criterion Parameter Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 465 12.3.25.3.Tariff Switches that Are Due to a Time Criterion. . . . . . . . . . . . . . . . . . . . . . . . . 466 12.3.25.4.Criterion Availability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 466 12.3.25.5.Criterion Context . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 466 12.3.26.Matrix Component Criterion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 467 12.3.26.1.Criterion Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 467 12.3.26.2.Criterion Parameter Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 467 12.3.26.3.Criterion Availability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 468 12.3.26.4.Criterion Context . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 468 12.4. The Leaves. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 468 12.4.1.Service Leaf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 469 12.4.1.1. Leaf Purpose. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 469 12.4.1.2. Leaf Parameter Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 469 12.4.1.3. Leaf Availability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 470 12.4.2.Forbidden Leaf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 471 12.4.2.1. Leaf Purpose. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 471 12.4.2.2. Leaf Parameter Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 471 12.4.2.3. Leaf Availability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 471 12.4.3.Allowed Leaf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 472 12.4.3.1. Leaf Purpose. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 472 12.4.3.2. Leaf Parameter Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 472 12.4.3.3. Leaf Availability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 472 12.4.4.Customer Account Leaf. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 473 12.4.4.1. Leaf Purpose. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 473 12.4.4.2. Leaf Parameter Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 473 12.4.4.3. Leaf Availability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 473 12.4.5.Tariff Leaf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 474 12.4.5.1. Leaf Purpose. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 474 12.4.5.2. Leaf Parameter Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 474 12.4.5.3. Leaf Availability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 475 12.4.6.Service Offer Leaf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 476 12.4.6.1. Leaf Purpose. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 476 12.4.6.2. Leaf Parameter Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 476 12.4.6.3. Leaf Availability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 476 12.4.7.Usage Rating Rule Reference Leaf. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 477 12.4.7.1. Leaf Purpose. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 477 12.4.7.2. Leaf Parameter Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 477 12.4.7.3. Leaf Availability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 477 12.4.8.Charging Rule Reference Leaf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 478 12.4.8.1. Leaf Purpose. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 478 12.4.8.2. Leaf Parameter Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 478 12.4.8.3. Leaf Availability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 478 12.4.9.Rating Plan Rule Reference Leaf. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 479 12.4.9.1. Leaf Purpose. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 479 12.4.9.2. Leaf Parameter Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 479 12.4.9.3. Leaf Availability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 479
Part IV.
13.
Scheduling Engine. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .481
Scheduled Events Processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 483
13.1. Role of the Scheduling Engine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 483 13.2. Scheduled Events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 484 13.3. Scheduled Event List . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 485 13.3.1.Virtual Queue . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 485
Page 12 of 968
11 September 2009
13.3.1.1. 13.3.1.2. 13.3.1.3. 13.3.1.4.
Posting Events to the Scheduled Event List . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 486 Removing Events from the Scheduled Event List. . . . . . . . . . . . . . . . . . . . . . . . . . 487 Default Priority of the Scheduled Events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 487 Past, Present or Future Events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 488
13.3.2.Time Progression: Hourly Granularity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 488 13.3.3.Time Zone Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 490 13.4. Scheduling, Community and Rating Engines Interactions . . . . . . . . . . . . . . . . . . . . . . . . . 490 13.4.1.Launching the Scheduled Events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 490 13.4.2.Processing of the Non-usage Events by the Community and Rating Engines . . . . . . . . 490 13.4.3.Receiving the Community and Rating Engines response. . . . . . . . . . . . . . . . . . . . . 491 13.5. Event Data Record for Scheduled Events Processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . 492 13.5.1.Consolidation of the EDR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 492 13.5.2.Destination of the EDR: always the External Module . . . . . . . . . . . . . . . . . . . . . . . 493 13.6. Error Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 494 13.6.1.Errors Vs. Unsuccessful Events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 494 13.6.2.Error Management Facility at a Glance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 494 13.6.3.Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 495 13.6.3.1. The Error Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 495 13.6.3.2. The Monitoring Counters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 496 13.6.3.3. Switching to Error Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 498 13.6.3.4. Typology of Possible Errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 498 13.6.4.Repairing Scheduled Events in Error Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 500 13.6.4.1. Scheduled Event switched to Error Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 501 13.6.4.2. Partition switched to Error Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 502
14.
Recurring Events Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 503

503 503 504 505 505 505 505 506 506 507 508 508 508 509 509 511 511 514
14.1. Service Cycle. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14.1.1.Cycle Definition and Granularity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14.1.2.Schedule Events at the Beginning or at the End of the Cycle. . . . . . . . . . . . . . . . . . 14.1.3.Starting Date . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14.1.4.Termination Date . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14.2. Synchronizing Recurring Events. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14.2.1.Conditions for Enabling the Synchronization . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14.2.2.Cases of Refused Synchronization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14.2.3.Concrete Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14.3. Refund Cases. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14.3.1.Prorata implied by the Refund . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14.3.2.Case of no Refund. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14.4. Prorating Fees . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14.4.1.Granularity of the Prorata . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14.4.2.Linear Vs. Nonlinear Prorata . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14.4.3.Cycle Truncations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14.4.4.Typical Prorating Cases: Schematic View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14.4.5.Enabling the Prorata . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Part V.
15.
Rating Engine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 516
Rating Paradigm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 517

517 517 517 519 519 519 528
15.1. Ratable Unit Metric object. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15.1.1.Object Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15.1.2.Parameter Description. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15.2. Tariff object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15.2.1.Object Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15.2.2.Parameter Description. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15.2.3.Tariff Application Modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11 September 2009
Page 13 of 968
15.2.3.1. Tapered Vs. Tiered . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 528 15.2.3.2. Mode A Vs. Mode B. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 529
15.2.4.Tip: Choosing a Cost/Units Ratio for a Tariff Segment . . . . . . . . . . . . . . . . . . . . . . 532 15.2.5.Finite Tariff: Limit Charge on a Balance or Bundle . . . . . . . . . . . . . . . . . . . . . . . . . 532 15.2.5.1. Defining the Scope of a Tariff . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 533 15.2.5.2. What happens when the limit is reached . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 534 15.2.5.3. In Tapered mode, the scope of the Tariff applies per slice . . . . . . . . . . . . . . . . . . 536 15.2.5.4. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 537 15.3. General Ledger Code object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 540 15.3.1.Object Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 540 15.3.2.Parameter Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 541
16.
Zoning Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 543
16.1. Main Features. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 543 16.1.1.Purpose: Making Decisions based on Zoning features . . . . . . . . . . . . . . . . . . . . . . . 543 16.1.1.1. Simple Areas versus Super Areas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 544 16.1.1.2. When It Is Not Preceded by Word Super, Area Means Simple Area . . . . . . . . . . . 545 16.1.1.3. The Two Possible Meanings of Zone Term . . . . . . . . . . . . . . . . . . . . . . . . . . . . 545 16.1.1.4. The Zoning Criteria at a Glance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 545 16.1.2.First Level of Flexibility of the Zoning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 546 16.1.2.1. What this Level Is - Why this Level . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 546 16.1.2.2. How You Can Take Advantage of this Level of Flexibility . . . . . . . . . . . . . . . . . . . 547
16.1.2.2.1.The Criteria May Use the Zoning Settings of the Default Service Retailer . . . . . . . . . 547 16.1.2.2.2.A Zones Simple Area Can Be from the Default or the Current Service Retailer. . . . . 547 16.1.2.2.3.Choosing a Name for the Instances of the Zoning Management Objects . . . . . . . . . . . 547
16.2.
16.3.
16.4.
16.5.
16.6.
16.1.3.Second Level of Flexibility of the Zoning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 548 16.1.4.More than Geographical Zoning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 548 Implementation at a glance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 549 16.2.1.The Three Levels of Zoning Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 550 16.2.2.The Data Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 552 16.2.3.Zoning Parameters Identification Logic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 553 Basic Zoning Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 553 16.3.1.Area Identifier Type object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 554 16.3.1.1. Object Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 554 16.3.1.2. Parameter Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 554 16.3.2.Area object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 555 16.3.2.1. Object Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 555 16.3.2.2. Parameter Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 556 16.3.3.Area Identifier object. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 556 16.3.3.1. Object Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 556 16.3.3.2. Parameter Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 557 16.3.3.3. An additional method: Refresh. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 559 Using Matrix Object to Set Up Origin-Destination Combinations . . . . . . . . . . . . . . . . . . . . . 559 16.4.1.Matrix Component object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 562 16.4.1.1. Object Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 562 16.4.1.2. Parameter Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 562 16.4.2.Matrix object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 563 16.4.2.1. Object Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 563 16.4.2.2. Parameter Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 563 Advanced Zoning: Differentiating Zoning settings according to the Product Catalog. . . . . . . . 565 16.5.1.Zone Object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 566 16.5.1.1. Object Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 566 16.5.1.2. Parameter Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 568 16.5.2.Tip: Safely Provisioning Zones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 570 16.5.3.Example of Provisioning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 570 Zoning Parameters Identification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 579 16.6.1.Default Service Retailer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 579 16.6.2.Zoning Parameters Identification Logic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 580
Page 14 of 968
11 September 2009
16.6.3.Area Identification Match Algorithms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 583 16.6.3.1. Available Match Algorithms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 584 16.6.3.2. Role of the Area Identifier Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 585
17.
Rewarding Accounts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 589
17.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 589 17.1.1.The Available Rewarding Methods: Crediting and Discounting . . . . . . . . . . . . . . . . . 589 17.1.2.Rewarding by Giving Some Credit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 589 17.1.3.Rewarding by Granting Some Discount . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 589 17.2. Grant Tool Object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 590 17.2.1.Object Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 590 17.2.1.1. Rewarding an Account with Some Credit. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 590 17.2.1.2. Rewarding an Account Activity/Inactivity extension . . . . . . . . . . . . . . . . . . . . . . . 590 17.2.1.3. When You should Use the Grant Tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 590 17.2.1.4. Making the CRE Take into Account the Terms of a Credit Grant . . . . . . . . . . . . . . 591 17.2.2.How the Terms of a Credit Grant Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 592 17.2.2.1. Principle of Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 592 17.2.2.2. Key Terms You Need to Know . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 593 17.2.2.3. Specifying the Quantity to Observe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 594 17.2.2.4. Specifying the Value Ranges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 596 17.2.2.5. Specifying Whether some Credit Is Associated with a Range or Not . . . . . . . . . . . . . 597 17.2.2.6. Indicating How the Granted Credit Has to Be Computed . . . . . . . . . . . . . . . . . . . . 598
17.2.2.6.1.Indicating How to Compute an Absolute Credit . . . . . . . . . . . . . . 17.2.2.6.2.Indicating How to Compute a Percentage Credit . . . . . . . . . . . . . 17.2.2.6.3.What Is Tapered Mode Calculation? . . . . . . . . . . . . . . . . . . . . . . 17.2.2.6.4.What Is Tiered Mode Calculation? . . . . . . . . . . . . . . . . . . . . . . .
............ ............ ............ ............
599 600 601 603
17.2.2.7. Indicating Which Accounts Value Sub-Repository Is Granted Credit. . . . . . . . . . . . . 606

17.2.2.7.1.When Absolute Radio Button Is Checked . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 606 17.2.2.7.2.When Percentage Radio Button is Checked . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 606
17.2.3.Parameter Description. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 607 17.3. Discount Object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 616 17.3.1.Object Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 616 17.3.1.1. Rewarding a Postpaid Account with Some Credit . . . . . . . . . . . . . . . . . . . . . . . . . 616 17.3.1.2. When You Should Use the Discount Object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 616 17.3.1.3. Making the CRE Apply the Terms of a Discount on an Account . . . . . . . . . . . . . . . 617 17.3.2.How a Discount Works . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 619 17.3.2.1. Principle of Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 619 17.3.2.2. Key Terms You Need to Know . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 620 17.3.2.3. Specifying the Quantity to Observe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 621 17.3.2.4. Specifying the Value Ranges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 623 17.3.2.5. Specifying Whether some Credit Is Associated with a Range or Not . . . . . . . . . . . . . 624 17.3.2.6. Enabling/Disabling VAT on the Current Terms of Discount . . . . . . . . . . . . . . . . . . 625 17.3.2.7. Indicating How the Granted Credit Has to Be Computed . . . . . . . . . . . . . . . . . . . . 625
17.3.2.7.1.Indicating How to Compute an Absolute Credit . . . . . . . . . . . . . . 17.3.2.7.2.Indicating How to Compute a Percentage Credit . . . . . . . . . . . . . 17.3.2.7.3.Specifying How the Value to Reward Must Be Calculated. . . . . . . . 17.3.2.7.4.What Is Tapered Mode Calculation? . . . . . . . . . . . . . . . . . . . . . . 17.3.2.7.5.What Is Tiered Mode Calculation? . . . . . . . . . . . . . . . . . . . . . . . ............ ............ ............ ............ ............ 626 628 630 632 634
17.3.2.8. Indicating Which Accounts Value Sub-Repository Is Granted Credit. . . . . . . . . . . . . 636 17.3.3.General Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 637 17.3.4.Perimeters Tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 639 17.3.4.1. Application Parameter GUI Frame . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 641 17.3.4.2. Calculation Parameter GUI Frame . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 643 17.3.5.Discount Options and Thresholds Tab . . . . . . . . . . . . . . . . . . . . . . . . . . . 645 17.3.6.View Graph Tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 649 17.4. Account Discount Object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 650 17.4.1.Object Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 650 17.4.2.Parameter Description. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 650
11 September 2009
Page 15 of 968
17.5. Promotion Tool Object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 651 17.5.1.Object Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 651 17.5.1.1. Rewarding an Account Either with Some Credit or with Some Discount . . . . . . . . . . 651 17.5.1.2. When Should You Use the Promotion Tool? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 653 17.5.1.3. Making the CRE Take into Account a Promotion. . . . . . . . . . . . . . . . . . . . . . . . . . 653 17.5.2.How a Promotion Works . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 655 17.5.2.1. Principle of Work. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 655
17.5.2.1.1.Promotion Basics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 655 17.5.2.1.2.What If a Usage Rating Rule Goes Across a Supervision Criterion? . . . . . . . . . . . . . . . 657 17.5.2.1.3.What If a Usage Rating Rule Goes Across a Promotion Criterion? . . . . . . . . . . . . . . . 658 17.5.2.1.4.What Happens When the Current Supervision Period Completes . . . . . . . . . . . . . . . . 659 17.5.2.1.5.Who Detects and Processes the Completion of the Current Supervision Period?. . . . . . 661 17.5.2.1.6.When Does the Supervision of an Account by a Promotion Start? . . . . . . . . . . . . . . . 661 17.5.2.1.7.Do the Supervision Periods of a Promotion on Two Different Accounts Match? . . . . . . 661
17.5.2.2. 17.5.2.3. 17.5.2.4. 17.5.2.5. 17.5.2.6. 17.5.2.7. 17.5.2.8. 17.5.2.9.
Key Terms You Need to Know. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Indicating to Which Accounts a Promotion Applies . . . . . . . . . . . . . . . . . . . . . . . . Specifying the Observed Values Container. . . . . . . . . . . . . . . . . . . . . . . . . . . . . Specifying How the Observed Value Is Computed . . . . . . . . . . . . . . . . . . . . . . . . . Applying Some Filtering to the Computation of the Observed Value . . . . . . . . . . . . Specifying Whether a Promotions Reward Is a Credit or a Discount . . . . . . . . . . . . Specifying When the Supervision Periods Are Allowed to Run. . . . . . . . . . . . . . . . . Specifying the Supervision Periods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
662 663 664 665 666 666 667 668
17.5.2.10.Specifying the Value Ranges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 674 17.5.2.11.When the Reward Is a Discount . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 676
17.5.2.11.1.Specifying How the Discount Is Computed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 676 17.5.2.11.2.Specifying How Long the Discount Is Granted . . . . . . . . . . . . . . . . . . . . . . . . . . . 677 17.5.2.11.3.Applying Some Filtering to the Discounts that a Promotion Grants . . . . . . . . . . . . . 677
17.5.2.12.When the Reward Is a Credit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 678

17.5.2.12.1.Specifying How the Credit Is Computed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 678 17.5.2.12.2.Specifying Which Account Sub-Repository(ies) Benefit of the Credit . . . . . . . . . . . . 679
17.5.2.13.Customizing a Promotion (LiteSCE Scripting) . . . . . . . . . . . . . . . . . . . . . . . . . . . 680

17.5.2.13.1.When Does a Promotion Call Its LiteSCe Script? . . . . . . . . . . . . . . . . . . . . . . . . . . 680 17.5.2.13.2.Customizing the Computation of the Observed Value (i.e., of VAL Parameter) . . . . . 680 17.5.2.13.3.Customizing the Computation of the End of the First Supervision Period . . . . . . . . . 681
17.5.3.Parameters. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 682 17.5.3.1. Promotion Identification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 682 17.5.3.2. General Tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 683 17.5.3.3. Supervision Tab. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 686 17.5.3.4. Attribution Tab. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 691 17.6. Comparing the Grant Tool, the Discount and the Promotion Tool Objects . . . . . . . . . . . . . . 695
18.
Preferred Charging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 699
18.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 699 18.2. Friends and Family List object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 699 18.2.1.Object Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 699 18.2.2.Parameter Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 699 18.3. Friends and Family Member Type object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 700 18.3.1.Object Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 700 18.3.2.Parameter Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 700 18.4. Friends and Family Member object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 701 18.4.1.Object Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 701 18.4.2.Parameter Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 702
Page 16 of 968
11 September 2009
17.5.2.9.1.Specifying a Supervision Period that Does Not Repeat (Fixed Period). . . . . . . . . . . . 668 17.5.2.9.2.Specifying a Periodic Supervision Period in Days (Day Period) . . . . . . . . . . . . . . . . . 669 17.5.2.9.3.Specifying a Periodic Supervision Period in Weeks (Week Period) . . . . . . . . . . . . . . . 670 17.5.2.9.4.Specifying a Periodic Supervision Period in Months (Month Period). . . . . . . . . . . . . . 671 17.5.2.9.5.At Which Time of the Day Does a Supervision Period Start? . . . . . . . . . . . . . . . . . . . 671 17.5.2.9.6.How Is the Completion of a Supervision Period Detected? . . . . . . . . . . . . . . . . . . . . 672 17.5.2.9.7.How Is the End of the First Supervision Period Computed? . . . . . . . . . . . . . . . . . . . 673
Part VI.
19.
Balance Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 703
Creating and Provisioning Accounts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 704
19.1. Account Profile object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 704 19.1.1.Object Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 704 19.1.2.Types of Account Profile Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 704 19.1.3.Parameter Description. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 706 19.2. Tips . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 744 19.2.1.About Minimum Credit Allowed and Maximum Credit Allowed . . . . . .744 19.2.2.Setting Up an Account Profile According to Its Accounts Type . . . . . . . . . . . . . . . . . 745 19.2.2.1. Summary Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 745 19.2.2.2. Detailed Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 745 19.3. Account Object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 747 19.3.1.Object Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 747 19.3.1.1. Whats an Account?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 747 19.3.1.2. Account with Customer vs. Account without Customer . . . . . . . . . . . . . . . . . . . . . 747 19.3.1.3. LC Charging Requests and LC Top-Up Request . . . . . . . . . . . . . . . . . . . . . . . . . . . 748
19.3.1.3.1.LC Charging Requests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 748 19.3.1.3.2.LC Top-UP Requests. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 748
19.3.2.Main Parameters Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 749 19.3.3.General Tab Parameter Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 757 19.3.4.Loyalty Tab Parameter Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 763 19.3.5.Charging Tab Parameter Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 769 19.3.6.ARENA Tab Parameter Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 770 19.3.7.Status Tab Parameter Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 771 19.3.8.Bundle Tab Parameter Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 784 19.3.9.Counter Tab Parameter Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 785 19.3.10.Subscriptions Tab Parameter Description. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 785 19.3.11.Fees Tab Parameter Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 787 19.3.12.Last 10 Events Tab Parameter Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 789 19.3.13.About an Accounts Life Cycle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 791 19.3.13.1.What Makes an Accounts Life Cycle Status Change of Value . . . . . . . . . . . . . 791 19.3.13.2.When Does the CRE Update an Accounts Life Cycle Status? . . . . . . . 792 19.3.14.Tips . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 793 19.3.14.1.About Begin/End Validity/Activity/Inactivity Dates. . . . . . . . . . . . . . . . 793 19.3.14.2.Making an Account Valid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 793 19.3.14.3.Activating an Account (i.e., Performing an Account Activation) . . . . . . . . . . . . . . . 794 19.3.15.How to Cleanly Remove an Account: the Purge Account Command . . . . . . . . . . . . . 794 19.3.15.1.Removing an Account via the CRE GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 796 19.3.15.2.Removing an Account via the Purge Account Command . . . . . . . . . . . . . . . . . . . . . 796
20.
Bundles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 799
20.1. Bucket Object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 799 20.1.1.Object Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 799 20.1.2.Setting Up an Accounts Bundle. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 800 20.1.3.Parameter Description. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 800 20.1.4.Bundle Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 803 20.1.4.1. Buckets Validity Period . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 803 20.1.4.2. Reset . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 804 20.2. Account Profile and Usage Link object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 804 20.2.1.Object Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 804 20.2.2.Parameter Description. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 805 20.3. Top-Up Profile Object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 808 20.3.1.Object Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 808 20.3.2.Non-resetable Mono-Bucket Bundles: Constraint and Solution . . . . . . . . . . . . . . . . . 808 20.3.3.Modifying a Top-Up Profile: not on Bundles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 810
11 September 2009
Page 17 of 968
20.3.4.Parameter Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 810 20.3.4.1. Top-Up Definition Tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 811 20.3.4.2. Main Balance Tab. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 814 20.3.4.3. Bundles Tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 816 20.3.5.Setting the Expiry of Buckets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 818 20.3.6.Bucket with Warning SMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 821 20.3.6.1. Feature description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 821 20.3.6.2. Computing the date for SMS notification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 822 20.3.6.3. Feature activation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 823 20.3.6.4. Restriction: Notification Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 824
21.
Updating the Accounts Credit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 825
22.
Counters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 852
22.1. Counter object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 852 22.1.1.Object Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 852 22.1.2.Parameter Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 853
Part VII.
23.
Flexibility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .855
Arena . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 857
23.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 857 23.2. Arena Object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 857 23.2.1.Object Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 857 23.2.2.Arena Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 857 23.2.3.Modification of ARENA value . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 858 23.2.4.Parameter Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 858
24.
CE Flexibility Point Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 861
24.1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 861 24.1.1.Purpose of CE Flexibility Point Management Objects . . . . . . . . . . . . . . . . . . . . . . . 861 24.1.2.Beware! Make Sure that CE Configuration Settings Agree! . . . . . . . . . . . . . . . . . . . . 861 24.2. Flexibility Point Object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 862
Page 18 of 968
11 September 2009
21.1. Operator Deposit Object. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 825 21.1.1.Object Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 825 21.1.1.1. Regular Top-up Operation: Implications. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 825 21.1.1.2. Specifying the user: an Account and potentially a Customer . . . . . . . . . . . . . . . . . 826 21.1.1.3. Commercial Offer Identification Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 826 21.1.2.Parameter Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 827 21.1.2.1. Top-up Definition, Main Balance and Bundles tabs . . . . . . . . . . . . . . . . . . . . . . . . 828 21.1.3.How to launch an Operator Deposit? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 832 21.2. Balance / Bucket Adjustment Object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 833 21.2.1.Object Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 833 21.2.1.1. Why is the Adjustment Interface Necessary? . . . . . . . . . . . . . . . . . . . . . . . . . . . . 833 21.2.1.2. Operator Deposit Vs. Balance/Bucket Adjustment . . . . . . . . . . . . . . . . . . . . . . . . 835 21.2.1.3. Selecting Buckets for Adjustment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 835 21.2.2.Parameter Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 836 21.2.2.1. Balance Tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 837 21.2.2.2. Buckets Tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 838 21.2.2.3. Bucket Search Tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 841 21.2.2.4. Bucket Adjustment GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 843 21.2.3.How to Adjust the Main Balance? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 844 21.2.4.How to Adjust a Bucket? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 846 21.2.5.Bucket Selection and Adjustment via the SOAP Interface . . . . . . . . . . . . . . . . . . . . 850
24.2.1.Parameter Description. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24.2.2.Configuration-dependent Flexibility Point . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24.2.3.Module Connector Combinations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24.2.4.Flx_reas Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24.3. CE Object Class Priority Order . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24.3.1.CE Priority Rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24.3.2.CE Object Priority Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
862 863 863 863 864 864 865
25.
RE Flexibility Point Management. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 869

869 869 869 869 869 870 870 870 872 872 872 872 872 873 874 874 874 874 875 876
25.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25.1.1.Purpose of Flexibility Point Management Objects . . . . . . . . . . . . . . . . . . . . . . . . . 25.1.2.Beware! Make Sure that RE Configuration Settings Agree! . . . . . . . . . . . . . . . . . . . 25.1.3.Flexibility User / Config: Same Functionality . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25.1.4.Why 2 Objects? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25.2. Flexibility Config Object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25.2.1.Object Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25.2.2.Parameter Description. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25.2.3.Configuration-dependent Flexibility Point . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25.2.4.Module Connector Combinations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25.2.5.flx_reas Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25.3. Flexibility User Object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25.3.1.Object Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25.3.2.Parameter Description. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25.3.3.Module Connector Combinations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25.3.4.flx_reas Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25.4. RE Object Class Priority Order . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25.4.1.RE Priority Rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25.4.2.Important Remark. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25.4.3.RE Object Priority Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
26.
26.1. 26.2. 26.3. 26.4. 26.5.
RE LiteSCE Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 879

If You Were Using a CRE Version Running on OSP 2.3. . . . . . . . . . . . . . . . . . . . . . . . . . . . CE and RE LiteSCE Profile Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . CE and RE LiteSCE Customer Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . CE and RE LiteSCE Script Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . LiteSCE Script Pool Object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26.5.1.Object Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26.5.2.Parameter Description. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 879 879 879 879 879 880 881
Part VIII.
27.
Community Engine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 882
Creating and Provisioning Customers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 883
27.1. Customer object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 883 27.1.1.Object Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 883 27.1.1.1. Trigger on Customer or Account?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 883 27.1.2.Parameter Description. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 884 27.1.3.How to Cleanly Remove a Customer: the Purge Customer Command . . . . . . . . . . . . 900 27.1.4.Commercial Offer History. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 900 27.2. Customer Account object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 901 27.2.1.Object Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 901 27.2.2.Parameter Description. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 902
11 September 2009
Page 19 of 968
28.
Communities of Customers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 904
28.1. Community object. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 904 28.1.1.Object Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 904 28.1.2.Parameter Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 904 28.2. Customer Association object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 904 28.2.1.Object Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 904 28.2.2.Parameter Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 905 28.3. Association Type object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 907 28.3.1.Object Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 907 28.3.2.Parameter Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 907
29.
Revenue Sharing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 909
29.1. Feature Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 909 29.1.1.Types of Actors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 909 29.1.2.Implementation of Revenue Sharing Schemes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 910 29.1.2.1. Terminology Clarification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 911 29.1.2.2. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 911 29.1.3.Advantages of the Integrated Revenue Sharing Scheme. . . . . . . . . . . . . . . . . . . . . . 912 29.2. Determining the Settlement Amount. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 912 29.2.1.Fixed Amount . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 912 29.2.2.Percentage of the initial events cost . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 912 29.2.3.About VAT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 913 29.3. Event Flows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 913 29.3.1.When Transaction Type is Debit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 914 29.3.2.When Transaction Type is Credit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 915 29.3.3.Network Event Type of the Settlement Events . . . . . . . . . . . . . . . . . . . . . . . . . . . 915 29.3.4.Event Data Records of the Settlement Events . . . . . . . . . . . . . . . . . . . . . . . . . . . . 915 29.3.5.Multi-level Settlement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 916 29.4. Partner Contract Object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 917 29.4.1.Object Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 917 29.4.2.Parameter Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 918 29.4.3.Settlement Accounts: Account Profile Implications . . . . . . . . . . . . . . . . . . . . . . . . 922 29.4.4.Settlement defined as a Service: Implications . . . . . . . . . . . . . . . . . . . . . . . . . . . . 922 29.4.4.1. Provisioning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 922 29.4.4.2. Typical Call Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 923
Document References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 963
Page 20 of 968
11 September 2009
Part I. Introduction
11 September 2009
Page 21 of 968
Page 22 of 968
11 September 2009
1. Introduction
1.1. Context
The Alcatel 8690 Open Services Platform provides comprehensive support for the rapid development of attractive services, and their introduction on the market ahead of competition. That way, the OSP enables telecom/network operators to generate additional revenue streams by providing new valueadded services to their customers. The Alcatel 8618 Convergent Rating Engine (CRE) is the central module of OSPs Convergent Billing. It helps telecom/network operators decreasing their costs because it reduces the complexity of the rating and the charging. The CRE provides two OSP services, which work hand in hand. These two services are: The Rating Engine (RE) service, and The Community Engine (CE) service.
1.2.
Purpose and Scope
This manual documents the CRE objects as made available by the CRE GUI.
1.3.
Intended Audience
This manual is intended for those persons who need to use the CRE GUI: CRE installers. Providers Service Retailers.
1.4.
Related Documents
While you read this manual, you might need to consult other documents. What follows lists some of them: [1] ALCATEL 8618 Convergent Rating Engine 2.0 South API Specification, 3BL 45180 DAAA PBZZA, Edition 01 or Higher [2] ALCATEL 8618 Convergent Rating Engine 2.6.2 Installation and Optimization Guide, Version 1.0 or Higher, 3CL-02660-BAHA-RJZZA
11 September 2009
Page 23 of 968
Introduction
1.5.
General Abbreviations
Note: See also Table 2, Technical Abbreviations, on page 24. Table 1 - General Abbreviations Abbreviation aka e.g. i.e. n.a. TBC TBD Meaning of Abbreviation Also Known As Exempli Gratia (for example) Id Est (that is) Not Applicable To Be Confirmed To Be Defined
1.6.
Technical Abbreviations
Note: See also Table 1, General Abbreviations, on page 24.

Table 2 - Technical Abbreviations Abbreviation ARENA ARES Meaning of Abbreviation Advanced Rating ENgine Application Advanced Recurrent Events Scheduler Thats the name by which the CREs Scheduling Engine is usually referred to. CDR Call Detail Record This abbreviation is hereby no longer used. Indeed, the CRE also rates events that are not calls. As a result, in the CRE, this abbreviation has been superseded by the more general EDR. A CDR is an EDR variant: A CDR is an EDR, but an EDR is not always a CDR. CE CRE DDUP DPE EDR Community Engine Convergent Rating Engine Dynamic Data UPdate Distributing Processing Environment Event Data Record See also CDR. See also Ticket. FNF IDL IN Friends and Family Interface Description Language Intelligent Network
Page 24 of 968
11 September 2009
Table 2 - Technical Abbreviations (continued) Abbreviation GI GUI GWEN LC LCS MOC MP MSID MTC MVNO OOC OSP PSMF
Meaning of Abbreviation Generic Installer Graphic User Interface GateWay ENgine Life Cycle Life Cycle Status Mobile Originating Call Mated Pair
Mobile Terminating Call Multiple Virtual Network Operators Out Of Call Open Services Platform The SMF that is the Primary SMF. Rating Engine Row ID Real Time Event Generator Service Data Point Scheduling Engine Service Execution Process. Shared Memory Database Service Logical Execution Environment Service Management Function. The PSMF is an SMF example. Service Management Point SMP Mated pair Simple Object Access Protocol Open Services Platform Text Oriented Client
RE RI RTx SDP SE SEP SHMDB SLEE SMF SMP SMPMP SOAP OSP TOC UNS VAT
Value Added Tax
11 September 2009
Page 25 of 968
Introduction
1.7.
Technical Terms
Table 3 - Technical Terms Term Meaning of Term Performing an Account activation consists in making the Account go from Valid state to the Active state. An Account activation is usually performed upon first charging of an Account. The CRE repository of Accounts data is spread over one or more database partitions, where the data related to a given Account are stored in one, and only one, database partition. These database partitions are hereby called Account partitions.
Account Activation
Account Partition

Its the partition algorithm in force that decides in which Account partition a given Account data are stored. The CRE usually maintains several copies of each of its Account partitions. At SMF level, there exists one, and only one, copy of each Account partition (that copy is said to be the master one and is located on one of the SMFs). At SLEE level, there exists one or more copies of each Account partition (each copy of the same Account partition being on different SLEEs). As the OSP keeps the content of all the copies of an Account partition consistent, we use Account partition to refer to all these copies, since they all can be seen as representing the same content. On the other hand, to refer to a copy of an Account partition on a network component, we use Account partition copy.
To know which Account partitions are installed for the CRE, use PARTITION object of PFMCONFIG (you need to log in with a user name that gives you the right to consult the data related to this object): Enter creactor in the object Service entry field, then execute List command from the object drop-down menu. In the window that then appears, click SELECT ALL button, and then DONE button. As a result, the list of partitions installed for the CRE appears, one row per partition installation on either an SMF or a SLEE. The Account partitions installed for the CRE correspond to the rows that indicate no host name and that have a Partition ID different of zero.

Partition 0 is not an Account partition. In the CRE installation ZIP files, an Account partition is one that has a name that is of the following form: Partition n, where n is to be replaced by a number. This number is the same as the Partition ID value of that partition in PARTITION object.
Active Bucket Active Service Offer Group
A bucket is active from its Valid from date until its To date. Outside of that time interval, the bucket is inactive. See section 9.8.1.2, Active Service Offer Groups of a Commercial Offer, on page 276.
Page 26 of 968
11 September 2009
Table 3 - Technical Terms(continued) Term Advanced Recurrent Events Engine Meaning of Term An OSP service that performs recurrent RTx requests to the CRE, upon request and as scheduled by the CRE. The knowledge of the periodicity of these RTx requests is in the CRE, not in the Advanced Recurrent Events Engine. Once an RTx request issued by the Advanced Recurrent Events Engine has been processed by the CRE, the CRE schedules indicates to the Advanced Recurrent Events Engine when the next one has to be issued. The event, that the current network event is about, has an origin and a destination. The called party of the network event is that destination. Note that, as that destination is not necessarily a CRE user, it is not necessarily known by the CRE. The term party is used in order to reflect this fact.
Called Party

Calling Customer Calling User
See also Called Party, on page 379.
A calling user who is a customer. The user who originated the event that the current network event is about. Although using calling is a slight language misuse (the network events are about events, and thus not only about events that are calls), this term is still used because of its vividness.

Charging Gateway
See also Calling user, on page 379.
The gateway that allows an application to interact in XML with the SouthBound Interface of the CRE. Any request the application makes to the gateway in XML is converted by the gateway into a request to the CRE SouthBound Interface. The response from the CRE SouthBound Interface to the application is issued by the CRE SouthBound Interface to the gateway so that this latter converts it into an XML message that it afterwards sends to the application. Because the SouthBound API is mainly about charging, this gateway is called Charging Gateway. The Charging Gateway is implemented as a set of LiteSCE scripts run by the GWEN. It is run as an OSP service.
Community Engine
One of the two OSP services that the CRE provides. The other service is the Rating Engine OSP service.
11 September 2009
Page 27 of 968
Introduction
Table 3 - Technical Terms(continued) Term DB Name Meaning of Term An object attribute has normally two names. The first name is a user-friendly one, that the CRE GUI displays and that the operators thus see. Whenever a GUI window allows the operator to update an object attribute, the window makes appear the attribute value as a value in an entry field, and the label of that entry field, which is text that can appear e.g. to the left or just above the entry field, is the user-friendly name of the attribute But an object attribute has another name. Its the name of that attribute in the CRE database. Its in fact the name of a column of an ORACLE table. That second name is called the DB name of the object attribute. DSC File SHMDB Description File Describes how the SHMDB data are organized. Frame Either a GUI frame or a windows frame.
GateWay ENgine
The GateWay ENgine (GWEN) is an implementation and execution environment for LiteSCE Scripts.
Using the standard set of LiteSCE actions provided by GWEN, a set of LiteSCE scripts can be implemented and then executed on the OSP. On behalf of these scripts, GWEN takes care of the following: The interaction with an external application The interaction with the CRE The activation of some of these scripts upon request of the external application. The GWEN then launches the script and gives it the request from the external application. The script then analyzes the request, converts it into a format that the CRE understands and then submits the converted request to the targeted interface of the CRE. Upon response from the CRE, the GWEN launches the script and gives it the response. The script converts the response into a format suitable to the external application and issues the converted response to the external application. As an example, thanks to the GateWay Engine, LiteSCE scripts can be used for implementing a gateway between an external application and the CRE. In a gateway that is implemented that way, the gateway specificities are in the LitesCE scripts and the communication with the external application and with the CRE is taken over by the GateWay Engine. The Charging Gateway, which is implemented as a set of LiteSCE scripts executed by the Gateway ENgine, is an example of such a use of the GWEN.
Page 28 of 968
11 September 2009
Table 3 - Technical Terms(continued) Term GUI Frame Meaning of Term A window graphical component that is used to show a grouping of an object attributes. The figure below shows a GUI frame example (thats the VAT GUI frame of the Tariff Window). The grouped attributes are the following ones: VAT Flag attribute, GL Code attribute and VAT Rate attribute.
Figure 1 - The VAT GUI Frame of Tariff Window HELP Button A HELP button is a button that appears to the right of some parameter and that shows the list of valid values for the parameter when it is clicked on. Selecting one of the values from the list sets the parameter to the selected value. Thanks to HELP buttons, you do not need to remember/guess which values are valid parameter values. A HELP button always appears as a button showing a magnifying glass, as the following figure illustrates.
Figure 2 - The HELP Button of Service Retailer Parameter In the above figure, the button that appears to the right of Service Retailer parameter is a HELP button, since it shows a magnifying glass. It is the HELP button of Service Retailer parameter since it appears to the right of the parameter. Hybrid Mode Means the same as Normal Mode. The CRE may run in one of the two following modes: Gateway Mode Normal Mode (i.e. the CRE does not run in Gateway Mode).
For more on these modes, see also parameter Gateway Mode, page 98.
Installer An operator who is logged in as an Installer to the CRE GUI. An Installer is essentially involved in technical-level issues, such a the management of CRE partitions. Main Balance
See section 7.2, Usage Rating Rule object, on page 232.
11 September 2009
Page 29 of 968
Introduction
Table 3 - Technical Terms(continued) Term Main menu Meaning of Term This refers to any one of the Views, such as the Profile View, that you find in the Views panel of the OSP GUI.
The Views Panel, where you find the following Views: The Profile View, the Preferred Items View, the Recent Items View and the Opened Items View.
Figure 3 - Main Menu Example Multiple Virtual Network Operators Network component The same as hosting several Service Retailers.
Either an SMF or a SLEE.
Page 30 of 968
11 September 2009
Table 3 - Technical Terms(continued) Term Network event From the Users Standpoint. A network event is one single experience corresponding to one global goal. For instance: performing a top-up, receiving an SMS, making a voice call, and even a call. Frequent synonym: Call, which is less generic. From the CREs Standpoint. The CRE receives requests from the RTx. These are the so-called RTx requests. Most of the time, the message the RTx request contains is called a network event too. That network event message that the RTx request submits to the CRE is always about some Users standpoint network event that occurs in the network. Thus, from the CREs standpoint, there are two kinds of network events: On the one hand, the Users standpoint network event and, on the other hand, the network event message, which simply contains information about a Users standpoint network event. There Is Not Always a One-to-One Mapping
Meaning of Term
Be aware that there is not always a one-to-one mapping between a Users standpoint network event and the network event message that an RTx request delivers to the CRE. For example, a call is a Users standpoint network event and, if that call is subject to Reserve and Commit Charging, several RTx requests for the call (i.e., for that Users standpoint network event) can be made to the CRE. The first one delivers a network event message to fstreq connector, the zero or more next ones deliver each a network event message to nextreq connector, and the final one delivers a final network event message, for the call, to the endcall connector. All these network event messages are about the same Users standpoint network event. How the Users Guide Deals with the Ambiguity The Users Guide uses the term network event to both refer to the Customers standpoint network event and to a network event message. When there is a one-to-one mapping between a Customers standpoint network event and network event message, there is no ambiguity when the two are referred to using the term network event. But when the mapping is not one-to-one, the ambiguity is possible. For that reason, whenever the ambiguity is possible, the Users Guide attempts, to the extent feasible, to avoid using network event term. However, this has not always be done. As a result, whenever the Users Guide still uses network event, the ambiguity might still be possible. Normally, context should then help you resolving the ambiguity. Network operator The company who is opening and renting its network platform to other Service Retailers in the context of a Revenue sharing Scheme.
11 September 2009
Page 31 of 968
Introduction
Table 3 - Technical Terms(continued) Term Operator Meaning of Term Any person who is using the CRE GUI. In other terms, this is any person who is logged in to the CRE GUI. There are three kinds of operators: Installers Providers Subscribers (not used). Out Of Call Out Of Call is a term that refers to the various background tasks that the CRE performs. These tasks are executed periodically. These tasks serve various purposes. For example, they can be used to set Inactive the Life Cycle Status of Accounts that are past their Begin Inactivity Date and whose Life Cycle Status is still set to Active. As another example, these tasks can be used to detect Accounts for which some warning, such as an End of Active Period warning, has to be issued. Naturally, the CRE also does these checks as necessary while it processes RTx requests. Provider An operator who is logged in as a Provider to the CRE GUI.
A Provider is essentially involved in business-level issues. E.g. he/she focuses on the management of his/her companys Customers, Accounts and Product Catalog. There exists two kinds of providers: One who represents the network operator (aka main Service Retailer) towards the CRE, and who has thus the power to open and rent the platform to other Service Retailers in the context of a Revenue Sharing scheme. One who represents another CRE service retailer towards the CRE, and who thus does not have the power to open and rent the platform. Provisioning Gateway The gateway that allows an application to interact in XML with the NorthBound Interface of the CRE. The NorthBound Interface is the interface by means of which the CRE GUIs do the CRE database provisioning. Any request the application makes to the gateway in XML is converted by the gateway into a request to the CRE NorthBound Interface. The response from the CRE NorthBound Interface to the application is issued by the CRE NorthBound Interface to the gateway so that this later converts it into an XML message that it afterwards sends to the application. Because the NorthBound API is about doing provisioning, this gateway is called Provisioning Gateway. The Provisioning Gateway is implemented as a set of LiteSCE scripts run by the GWEN. It is run as an OSP service.
Page 32 of 968
11 September 2009
Table 3 - Technical Terms(continued) Term Range of Values Meaning of Term A range of values is a contiguous set of one or more positive integer values. For example, 7 to 123 represents all the integer numbers from 7to 123, 7and 123 being included. Note that a range can be made up of a single value. for example, 154 to 154 represents a range of value that is made up of one integer number, which is 154. Rating Engine Real Time Event Generator RTx Request One of the two OSP services that the CRE provides. The other service is the Community Engine OSP service. The OSP component that triggers the CRE in real-time with events that occurs on the network: a voice call, an SMS, a data session, and so on. Originally, the means by which a Real Time Event Generator (=RTx) triggers the CRE in real-time. Now, the means by which an OSP service, other than the CRE, triggers the CRE. This consists in the OSP service requesting a given CE connector, of the CRE, to process a message, sent to that connector, that contains the data of the RTx request. That message is also called an RTx request.

The ARES OSP service is an example of an OSP service, other than an RTx, that may make an RTx request to the CRE. The Charging Gateway OSP Service is another example of an OSP service, other than an RTx, that may make an RTx request to the CRE.
RTx requests are described in the following document: ALCATEL 8618 Convergent Rating Engine 2.0 South API Specification, 3BL 45180 DAAA PBZZA, Edition 01 or Higher. SDP Parameter An SDP parameter is one for which the sole CRE responsibility is: To store the parameter value, To provide that stored value to an external system (usually, thats the RTx). Apart from that, the CRE does not treat an SDP parameter. That is, apart from storing the value of an SDP parameter on behalf of some external system, and restituting it to the external system, the CRE applies no logic to an SDP parameter. Service Execution Process Shared Memory Database Telecom operator Text Oriented Client (TOC) In the context of the Users Guide, its enough to say that is an Operating System process. An Alcatel proprietary database system by means of which tuples containing volatile data can be stored in RAM and shared between several processes. Same as network operator. This is a command line interpreter that lets you issue textual commands to the CRE objects in the same way the CRE GUI does. The TOC is only available on OSP 2.4, which means the TOC is only available for CRE 2.x.2 products. On OSP 2.3, the TOC is replaced by the GCC.
11 September 2009
Page 33 of 968
Introduction
Table 3 - Technical Terms(continued) Term Ticket Trigger Message Usage RTx Request Same as EDR RTx Request This is an RTx request that is about some use of the network by an user. For example, that is about a call, about an SMS, and so on. Such an RTx request always triggers one of the following connectors, and only them: oneshot connector, fstreq connector, nextreq connector, endcall connector. As a result, an RTx request that is about a Top-Up is certainly not an usage RTx request, since it does not trigger any of the above mentioned connectors. Moreover, a Top-Up does not really correspond to some use of the network which needs to be rated. Such an RTx request will always be mapped by the CRE onto a Service object instance that is of type Usage. This is one other reason why such an RTx request is called an usage RTx request. Meaning of Term
To remember, its the Service Offer that uses a given service that decides of the type of that service. You will find more information on this at section 7.1, Service Types based on the Events Characteristics, on page 229, from chapter 7., "Types of Service Offers", on page 228.
This term has been introduced in order to help removing possible ambiguities in the text. The authors apologize for introducing one additional term there are already so many of them , but the goal here is to enhance accuracy of the text. An usage RTx request is always subject to charging. User A user is Either any Customer Or any Account that belongs to no Customer. Whenever the CE is running in Gateway Mode, a User is any Account defined in the CRE, and vice-versa. (Any Customer that would have been defined in the CRE is ignored and the Accounts thus belong to no Customers, even when Customers are defined.) Whenever the CE is running in Normal mode (i.e. not in Gateway mode), any Customer, as well as any Account that belongs to no Customer, is a User. And vice-versa. (If the CRE does not find a Customer for processing a given RTx message, it attempts to further process it by trying to find out an Account for it).
Page 34 of 968
11 September 2009
Table 3 - Technical Terms(continued) Term Windows Frame Meaning of Term The windows frame is the OSP GUIs area in which the management windows of the OSP services are displayed.
The windows frame
Figure 4 - Windows Frame Example
1.8.
Data Type of the GUI Entry Fields
The value you enter into a given GUI entry field has to be of a given data type. For example, a given entry field might require a value that is a date, while another one might require a value that is a character string. Whenever you are told that a GUI entry field value is of some data type, issues such as the ones here below may arise: What characters am I allowed to put into the entry field? Do I have to observe a pre-defined layout whenever I enter characters into the entry field.
11 September 2009
Page 35 of 968
Introduction
The table below addresses these issues. Table 4 - Entry Fields Data Types Data Type of Entry Field Value Character string Explanation A character string is a string that only contains the following characters: Alphabetic characters, whether in lower case or in upper case. The case is significant. These alphabetic characters must be English letters. In other terms, letters such as , , and son on, are not permitted. Decimal digits. That is: 0, 1, 2, 3, 4, 5, 6, 7, 8, 9. The following special characters: Space ( ), dot (.), hyphen (-), ampersand (&), underscore (_), slash (/), double backslash (\\), colon (:), plus sign (+), minus sign (-), the crossroads sign (#).
Database Name Date A date is a character string that has the following layout:
DD/MM/YYYY
That is, two digits for the day of the month, followed by a slash, followed by two digits for the month of the year, followed by a slash, followed by the four digits of the year. Date and Time A date, followed by a space, followed by a time. A date and time has the following layout:
DD/MM/YYYY hh:mm:ss
Decimal Value A decimal value consists of an integral part and of an optional fractional part. Both the integral and fractional parts consist of a series of digits that range from zero to nine (0 to 9). The integrated and fractional parts are separated by a decimal point. A decimal value is either negative or positive. Here are examples of valid decimal value: 123.45 123 -123.4 -123 Flag A flag can have two values: It is either checked or unchecked.
SEP Group Name
Page 36 of 968
11 September 2009
Table 4 - Entry Fields Data Types Data Type of Entry Field Value Time Explanation A time is a character string that has the following format:
hh:mm:ss
That is, two digits for the hour of the day, followed by a colon, followed by two digits for the minute of the hour, followed by a colon, followed by two digits for the seconds.
11 September 2009
Page 37 of 968
Introduction
Page 38 of 968
11 September 2009
2. Whats New in Alcatel-Lucents OSP 2.4

Unlike the 2.x.1 members of the Alcatel-Lucent 8618 Convergent Rating Engine products family (which all run on OSP 2.3), the 2.x.2 members (such as the Alcatel-Lucent 8618 Convergent Rating Engine 2.6.2) of the family run on OSP 2.4. Whether you are a first-time user of Alcatel-Lucents OSP or you are already familiar with the OSPs 2.3 release, you will appreciate the advanced management facilities offered by the OSP 2.4. As a service management operator, you will mainly benefit from major improvements in the following four areas: The OSPs management interface now runs as a PC application.
See section 2.1, An Application Running on Your PC, on page 39.
The operator can now log-in online or offline.
See section 2.2, Logging in to the OSP, on page 39.
The user-friendly graphical user interface offers improved commands, especially for editing and exchanging data.

See section 2.3, Graphical User Interface, on page 43.
The LiteSCE management allows smoother while comprehensive definition of the flexibility points.
See section 2.4, Managing LiteSCE Flexibility, on page 49.
2.1.
An Application Running on Your PC
The first time you connect to your OSP, you connect to the server via your browser. The application is then downloaded from the server on your PC. Later on, for managing any OSP service, you do not need to use any browser. Just open your OSP application on your PC, and log in to the server as prompted by the application. Once it is installed, you never have to download the application again. The application is able to download only the parts of code that changed and not the whole application.
2.2.
Logging in to the OSP
Each operator, before performing any management operation to an OSP service, needs to log in to the OSPs management interface. The main breakthrough of the OSP 2.4 regarding log-in is the possibility to log-in offline. Moreover, the login procedure has been enhanced thanks to histories.
2.2.1.
Working Offline Vs. Online
When you work offline, you are not connected to your services database. Consequently, all the provisioning operations you perform are not saved into the database. However, you can save them locally and import them later on into your service database, in an online session.
11 September 2009
Page 39 of 968
Whats New in Alcatel-Lucents OSP 2.4
Working offline offers the following advantages: You do not depend on the networks traffic You are not impacted by any transaction occurring on the live system You cannot damage any crucial data on the live system.
Page 40 of 968
11 September 2009
2.2.2.
1.
Log-in Procedure
Connect to your OSP machine via your browser.
Figure 5 - Connecting to the OSP 2.4 Management Interface 2. Click on Start Management Application.
Figure 6 - Starting Up the OSP 2.4 Management Application The management application is being downloaded. In the meantime, a status window is displayed.
Figure 7 - The Management Application Is Being Downloaded 3. When download is completed, the management interface opens, with a pop-up window prompting for authentication.
11 September 2009
Page 41 of 968
Figure 8 - The Login Window of the Management Application

4.
Enter your Login and Password information. A history of the previously used Logins is available.
Figure 9 - Entering Log-In Information, Using the History or Not 5. To be connected to your OSP service and its database, click on Login.
Figure 10 - Connecting to the Management Application in Order to Work Online
Page 42 of 968
11 September 2009
If you prefer to work offline, click on Local Session instead of Login. See also Working Offline Vs. Online, on page 39.
Figure 11 - Connecting to the Management application in Order to Work Offline 6. The OSP services available on the machine to which you are connected are now displayed in the views panel.
Figure 12 - The Management Applications Work Space
2.3.
Graphical User Interface
The window-based graphical user interface allows the user to intuitively find out how to perform management operations. The screen is indeed divided into six functional zones.
11 September 2009
Page 43 of 968
3 4
5 6
Figure 13 - The Main Components of the Management Applications Work Space
1 2 3 4 5 6
Views panel Windows frame Menu bar Tool bar Message area Status bar
for browsing through OSP windows for service data windows for a comprehensive set of commands for easy access to most usual commands for real-time command result monitoring for current basic settings visualization
Page 44 of 968
11 September 2009
2.3.1.
In the Views Panel
The views panel offers the high level view on all management windows available to the operator that is logged in. The availability of a given service window or not depends on the operators Profile. Four different views can be displayed in the views panel: Profile view, displaying the directory structure of all the windows of every service installed on the OSP. This view can be customized via the Edit > Customize GUI menu command. Preferred Items view, in which the operator can manage its favorite windows. Recent Items view, showing the ordered list of the last 10 opened windows. Opened items view, showing the windows currently opened in the windows frame. The views panel can be hidden in order to leave more space for the windows opened in the windows frame.
Figure 14 - The Views Panel
11 September 2009
Page 45 of 968
2.3.2.
In the Windows Frame
The windows frame is the display area for every management window of the services running on the OSP. For opening a service management window, double click on its name in the views panels directory.
Figure 15 - The Windows Frame In the windows frame, you can resize the window as usual: By clicking on the icons at the top of the window or by using the arrows appearing under your mouse on the edges of the window.
Maximize
Minimize
Close
Figure 16 - Maximizing, Minimizing and Closing a Window that the Windows Frame Shows The tasks that you can perform in a specific window are defined in the menu bar, in a menu item named like the window currently opened. If you were familiar with OSP 2.3, you will notice that the tasks are no longer available from the object window itself.
Page 46 of 968
11 September 2009
Figure 17 - The Tasks You Can Perform on the Window that Is Currently Selected in the Windows Frame
2.3.3.
In the Menu Bar
In the menu bar, you can find the complete set of commands that are available for the window currently active in the windows frame. It is divided into 5 menus:
File Menu
The File menu contains all the commands applicable to non-OSP data files: Open, Save, Export. When managing your OSP services, typically online, you manage data via the windows and do not use any files. However, working with files represents a big advantage in various cases: For exporting OSP service data to a standard file format, allowing readability for many other application, For saving work done during an offline session, For importing to the online database data coming from an external application or system, or saved locally during an offline session. The File menu also offers a Print command (to any printer including PDF and to file), and a convenient screenshot facility.
Edit Menu
The Edit menu contains all the usual editing commands, in order to facilitate the provisioning of your service windows: Clear, Cut, Copy, Paste, Cut all, Copy all, Paste all, Find. Note: These commands are only for text fields and are NOT valid to cut, copy, paste, etc. in routing trees like charging rule, usage rating rule, top up rule and the like. The Edit menu also provides a Preferences item, allowing the operator to customize various settings of their OSP management interface.
11 September 2009
Page 47 of 968
Session Menu
The Session menu lists the following commands: Display executed methods Record log file / Stop Logging Record batch file / Stop batch record Play batch file Change password Customize GUI menu Logout
Currently Active Service Windows Menu

The menu bar contains a non-fixed menu item, which depends on the window currently active in the windows frame. This menu lists the set of tasks that have been defined for the window. You will typically find the following commands: Count Create Display List Modify Remove This list is not exhaustive. Some objects are equipped with additional tasks.
Windows Menu
The Windows menu lists all opened windows, allowing swapping from one window to another. You can also arrange the windows opened in the windows frame via the Close, Tile Horizontally, Tile Vertically and Close commands.
Help Menu
The Help menu allows displaying the help info about the currently active window.
Page 48 of 968
11 September 2009
2.3.4.
In the Tool Bar
For a user-friendlier interface, the tool bar displays the icons of the most usual commands available in the menus: Logout Minimize/Restore splitters Open, Save, Export, Print Clear, Cut all, Cut, Copy, Paste, Find, Find again Help, About The tool bar may also display some additional icons specific to the currently active window.
2.3.5.
In the Message Area
The message area ensures easy basic monitoring by indicating the result of each command performed. The message area can be hidden in order to leave more space for the windows opened in the windows frame.
2.3.6.
In the Status Bar
The status bar displays some basic settings and information: Session mode: Offline or online Batch file and log files activated or not Date and time Editing mode: insert or overwrite
2.4.
Managing LiteSCE Flexibility

See also section 26.1, If You Were Using a CRE Version Running on OSP 2.3, on page 879.
The OSPs LiteSCE facility allows defining customized logic for any other service running on the OSP and equipped with so-called flexibility points. In the OSP 2.4, the LiteSCE is a platform service, in which Actions can be defined for the other service installed on the same platform.
Figure 18 - PFMLiteSCE As Shown by the Profile View Among the main new features regarding LiteSCE in the OSP 2.4, the following ones will considerably ease the way you manage logic flexibility of your services.
11 September 2009
Page 49 of 968
The Profile of the operator determines the set of components and variables from the main service that they can access. This limitation can even be redefined per login. The OSP 2.4 automatically generates a GUI for the LiteSCE Actions created by the operator. When generating a LiteSCE Action, the operator may activate it on all SLEEs or on a test SLEE only. It is possible to see all the dependencies of a LiteSCE Action, i.e. all the places where it is used. Note: Pay attention to the terms. If you were used to LiteSCE in the OSP 2.3, you might get confused by some terms. The concept of LiteSCE script in the OSP 2.3 is now called a LiteSCE Action. The concept of LiteSCE Action in the OSP 2.3 no longer exists. A flexibility script (now called LiteSCE Action!) is composed of SIBs (or of other action sor interfaces), just like the main service script. In other words, from the implementation standpoint, the difference between SCE and LiteSCE fades out.
2.5.
Finding More Information About OSP 2.4
A comprehensive documentation set about Alcatel-Lucents Open Services Platform 2.4 is available. For more information, see in particular the following documents: [3] Alcatel-Lucent 8690 OSP 2.4 Management System User Guide, 3CL-02350-BCXX- MSZZA [4] Alcatel-Lucent 8690 OSP 2.4 Basic Operations Guide, 3CL-02350-BCXX-BAZZA [5] Alcatel-Lucent 8690 OSP 2.4 LiteSCE Developers Guide, 3CL-02350-BCXX-MIZZA [6] Alcatel-Lucent 8690 OSP 2.4 General Introduction, 3CL-02350-BBXX-DEZZA
Page 50 of 968
11 September 2009
Part II. Configuration
11 September 2009
Page 51 of 968
Page 52 of 968
11 September 2009
3. OSP Level Setup

Before you start creating your first CRE objects, as well as every time you need to add a new service retailer to the CRE, ensure that the necessary operators have been defined at OSP level.
Operators Make It Possible to Protect the Data of the Service Retailers

The CRE features MVNO. As a result: Service retailers need to manage their own product catalog in a way that guarantees the confidentiality of their data. For that reason, you need to create for each service retailer, at OSP level, an operator by means of which each service retailer manages, in confidentiality, its own set of objects. Because use of the CRE by service retailers is mainly about managing their own product catalog, the created operators must be provider operators. The network operator, who is renting its IN services to the service retailers, needs a management access to all CRE objects. For that reason, you need to create, at OSP level, an operator by means of which the network operator receives a management access to all CRE objects. Because the CRE sees the network operator as a service retailer, but who has more rights than the other service retailers, the operator you create for a network operator must be a provider operator too.
What to Do When Needing to Create a CRE Provider Operator

Note: In this chapter, operator is always synonymous with provider operator. Creating a provider operator is a four steps process: 1. If the pre-defined profile that comes with the CRE (the profile is called crefull) does not suit the needs of the provider operator you are going to create, create your own profile. You will afterwards assign that profile to the provider operator you are going to create. Note: This is usually not needed: crefull profile works fine with all provider operators. Creating a profile consists in creating and suitably setting up an instance of PROFILE object of PFMACCESS.

2.
If you want to create a specific profile for your CRE provider operators, be sure you read section 3.1, Creating a Custom Profile for Your CRE Provider Operators, on page 54.
If it does not exist yet, create the operator group that will be the provider group of the provider operator that you are going to create. Creating an operator group consists in creating and suitably setting up an instance of OPERATOR GROUP object of PFMACCESS.

3.
On what a provider group is, see 3.3.3, Whats a Provider Group?, on page 59. On creating an operator group, see section 3.2, Creating an Operator Group, on page 57.
Create the provider operator.
11 September 2009
Page 53 of 968
OSP Level Setup
Creating a provider operator consists in creating and suitably setting up an instance of OPERATOR object of PFMACCESS. While creating a provider operator, you assign it a profile and a provider group.

4.
On creating the provider operator, see section 3.4, Creating a CRE Provider Operator, on page 60.
If the service retailer that is to be associated with the just created provider operator does not exist yet, create it now. Creating a service retailer consists in creating and suitably setting up an instance of SERVICE RETAILER object of the CRE.

On how you know whether a service retailer is associated with a provider operator, see 3.3.1, The Access Rule, on page 57. On creating a service retailer, see 3.5, Creating a Service retailer, on page 65.
3.1.
Creating a Custom Profile for Your CRE Provider Operators
The CRE comes with a generic profile, which is called crefull and which grants all the objects access rights that a CRE provider operator usually needs.
Unless crefull profile does not fit with your requirements in terms of the objects access rights it grants, you are recommended to keep using crefull profile. Note: If you intend to only use crefull profile for your CRE operators, you can safely skip this section. Note: Any provider operator you create has to be assigned a profile. Roughly speaking, the profile of a provider operator tells which objects the operator is allowed to use and which ones the operator is not allowed to use. If you need that some of your operators use a different set of objects access rights, you will find yourself wanting to set up another profile. If you decide to set up your own profile, please take enough time to carefully read this section. It will help you speeding up the tuning of the profile, by telling you how you must cope with dependencies between objects, by giving hints on how to find out these dependencies and by drawing your attention on what to first investigate in case you observe some unexpected behaviors while logged in to the CRE GUI as one of the operators that use the profile.
3.1.1.
What You Need to Take Care Of
When setting up your own profile, always keep in mind that objects have dependencies with each other. This implies that, if you set up a profile so that it gives the right to use some object and if instances of that object must or may use instances of some other objects, then the profile must also give the right to use these latter objects. To give an example, if a profile gives the right to use the Top-Up Profile object, the profile must also give the right to use the Service Retailer object, the Account Profile object, the General Ledger Code object and the Bundle/Counter Usage Label object. The problem is of course to identify which objects a given object must or may use.
Page 54 of 968
11 September 2009
Next section gives you hints on how to do that.
3.1.2.
Investigating Dependencies Between Objects
To know which objects a given object must or may use, carefully review the GUI of the object and find out in the CRE documentation which parameters of the object correspond to a reference to some other object. You can speed up your investigation by looking for the parameters that have a HELP button appearing at their right end. Indeed, parameters which refer to objects have most of the time, if not always, such a button at their right end.
Figure 19 - Locating the Parameters that Have a HELP Button at Their Right End
The above figure illustrates this. In the figure, parameter labeled Service Retailer* has a HELP button at its right end. Moreover, looking at the documentation of the parameter indicates that the parameter value must refer to an instance of Service Retailer object. The same is true for Name* parameter: Since it has a HELP button at its right end, its value must refer to the instance of some object. On the other hand, Nominal Value (Money) parameter has no HELP button appearing at its right end and having a look to the documentation confirms that the parameter is not used to refer to some object. What follows illustrates, using the Top-Up Profile object, the quick way to investigate which object must or may use which objects. The figure below shows the Top-Up Profile objects GUI, in which Top-Up Definition tab is selected.
11 September 2009
Page 55 of 968
OSP Level Setup
Figure 20 - Investigating Which Objects Top-Up Profile Object Must or May Use
Since Service Retailer* parameter has a HELP button at its right end, the parameter refers to an object. Having a look to the documentation of Service Retailer* parameter confirms us that the parameters value must refer to a Service retailer object. Note: Note that, since a star (*) appears at the end of the parameters label, Service Retailer* parameter of any instance of Top-Up Profile must have a value. In other terms, any instance of Top-Up Profile object must use a Service Retailer object. Since Account Profile* parameter has a HELP button at its right end, the parameter refers to an object. Having a look to the documentation of Account Profile* parameter confirms us that the parameters value must refer to an Account Profile object. Note: Here again, because of the * at the end of the parameters label, any instance of Top-Up Profile object must use an Account Profile object. Since General Ledger Code parameter has a HELP button at its right end, it refers to an object. Having a look to the documentation of General Ledger Code parameter confirms us that the parameters value is one that refers to a General Ledger Code object. Note: Note that, since no star (*) appears at the end of the parameters label, General Ledger Code parameter of an instance of Top-Up Profile may have no value. As a result, when a profile allows to access Top-Up Profile object, the profile must also allow access to Service Retailer object, Account Profile object and General Ledger Code object. Note: Although this example does not investigate them, the other tabs of the Top-Up Profile object have to be investigated too. If you do that investigation, you will see that Bundles tab has parameters whose value must refer to an object: These are the parameters that appear under Bundle(s) label. Since the value of any of these parameters is one that refers to a Bundle/Counter Usage Label object, any profile granting access to Top-Up Profile object must also grant access to Bundle/ Counter Usage Label object.
Page 56 of 968
11 September 2009
3.1.3.
Troubleshooting Profiles that You Have Set up
If, while logged in to the CRE GUI as an operator that uses a profile that you have set up, you get unexpected behaviors, first check that the object you are currently using is allowed to access all the objects it must or may use. To identify these latter objects, proceed as previous section explains. For example, if while logged in as an operator that uses a profile that you have set up, you get an unexpected behavior and you are using the Top-Up Profile object, first check that the operators profile allows to access the Service Retailer object, the Account Profile object, the General Ledger Code object as well as the Bundle/Counter Usage Label object.
3.2.
Creating an Operator Group
For a service retailer, you need to create an operator group that has the same name as the service retailer name. Thus, if you will create a service retailer (i.e., an instance of Service Retailer object of the CRE) called retail01 in your CRE installation, you need to create an operator group that is called retail01. For the network operator, you have to create an operator group that is called sdpprov.
Figure 21 - Creating an Operator group for Service Retailers The two above pictures illustrate the creation of an operator group for sdpprov and retail01 service retailers. You create an operator group by means of OPERATOR GROUP object of PFMACCESS. You need to be logged in as a provider operator that lets you manage PFMACCESS objects. Note: If pfmaccessprov provider operator exists on your system, pfmaccessprov is such a provider operator.
3.3.
3.3.1.
CRE Objects Access Rule

The Access Rule
The access rule to any CRE object is as follows: If the name of the provider group of the logged operator equals sdpprov: The operator has then unlimited access to all the objects instances of all the service retailers and is thus able to fully act on behalf of any of these service retailers.
11 September 2009
Page 57 of 968
OSP Level Setup
In other terms, such an operator is enabled to act as a network operator. When wanting to act on behalf of a given service retailer, such an operator must make sure that Service Retailer parameter of any objects instance he/she manages on behalf of the service retailer is set to the name of that service retailer. Note: Each operator has to be associated with one, and only one, service retailer. You associate a service retailer with an operator of this kind by creating an instance of SERVICE RETAILER object, of the CRE, that has its Provider Group* parameter set to sdpprov. Only one service retailer (i.e., instance of SERVICE RETAILER object) is allowed to have its Provider Group* parameter set to sdpprov. As a result, each operator of this kind is associated with the same service retailer (i.e., same instance of SERVICE RETAILER object). Unlike the other instances of SERVICE RETAILER object that you will set up, you freely choose the name of the unique service retailer (i.e., instance of SERVICE RETAILER object) whose Provider Group* parameter is set to sdpprov. Its Service Retailer Name* parameter of the instance that has to be filled in with that name. Otherwise (i.e., if the name of the provider group of the logged operator does not equal sdpprov): The operator can only access the objects instances of the service retailer that has the same name as that of the provider group of the operator. This means that such an operator is not enabled to act as a network operator. Thus, when value of Service Retailer parameter of an objects instance does not match the name of the provider group of a logged operator for which the name of the provider group does not equal sdpprov, the logged operator has no access at all to the instance. Which means he/she even cant consult the data of the instance. Note: Each operator has to be associated with one, and only one, service retailer. You associate a service retailer with an operator of this kind by creating an instance of SERVICE RETAILER object, of the CRE, that has its Provider Group* parameter set to the name of the provider group of the operator. No two instances of SERVICE RETAILER object may have the same value for their Provider Group* parameter. Which means that, when two operators of this kind have the same provider group, they are associated with the same retailer. You cannot freely choose the name of a service retailer that is associated with this kind of operator: The name of such a service retailer (i.e., such an instance of SERVICE RETAILER object) must equal the value of Provider Group* parameter of the service retailer. Thus, in any instance of SERVICE RETAILER object that is associated with an operator of this kind, Provider Group* and Service Retailer Name* parameters must have identical values.
3.3.2.
Examples
The table below shows a few examples of provider group settings and their impact on the access to the Service Retailers. Table 5 - Provider Group Settings Examples Operator Login John_Smith Provider Group sdpprov Accessible Service Retailer(s) all
Page 58 of 968
11 September 2009
Table 5 - Provider Group Settings Examples Paul_Taylor Sdpprov Bill_Black According to the above table: When logged in as either John_Smith or Sdpprov operator, you are able to act on behalf of retail01 and retail02 service retailers, since the name of the provider group of these operators match sdpprov. When logged in as Paul_Taylor operator, you are not able to act on behalf of retail02 service retailer, since the name of the provider group of that operator is called neither retail02 nor sdpprov. Thus, when logged in as Paul_Taylor, you have no access at all (and thus even cant consult) to object instances whose Service retailer parameter is set to retail02. As a result, you can neither see nor modify any data of retail02 service retailer. On the other hand, while logged in as Paul_Taylor operator, you are able to act on behalf of retail01 service retailer, since the name of the provider group of Paul_Taylor operator is called either retail01 or sdpprov. Thus, while logged in as Paul_Taylor operator, you can manage (i.e., create, modify, remove, list, view, and so on) without restriction any objects instance whose Service Retailer parameter is set to retail01. retail01 sdpprov retail02 retail01 all retail02
3.3.3.
Whats a Provider Group?
A provider group of an operator (i.e., of an instance of OPERATOR object of PFMACCESS) is an operator group (i.e., an instance of OPERATOR GROUP object of PFMACCESS) that the operator uses as its provider group. An operator uses an operator group as its provider group when Provider Group parameter, of the instance of OPERATOR object (of PFMACCESS) that defines the operator, is set, for each service that the operator is allowed to use, to the name of the operator group. For example, the figure below shows the GUI for the OPERATOR object (of PFMACCESS) filled in with the data of a given operator. According to the figure, that operator is able to use ce20 service, creactor service, pfmlitesce service and ares service. For each of these services, Provider Group parameter is set to sdpprov. That means that that operator uses sdpprov operator group as its provider group.
11 September 2009
Page 59 of 968
OSP Level Setup
Figure 22 - sdpprov Operator Group Is Used as a Provider Group by Operator

Note: sdpprov is an operator group since there exists some instance of OPERATOR GROUP object, of PFMACCESS, that defines it.
On using OPERATOR object to create an operator, see also section 3.4, Creating a CRE Provider Operator, on page 60.
3.4.
Creating a CRE Provider Operator
Briefly said, creating a provider operator consists in creating an instance of OPERATOR object of PFMACCESS and in suitably setting it up. While suitably setting the instance up, you assign a series of profiles (usually, creactorprov, ce20prov and aresprov profiles) to the instance and you indicate to the instance which operator group is the provider group of the instance. Less briefly said, to create a provider operator: Note: The figures, that illustrate the creation steps of a provider operator for the CRE, create Paul_Taylor provider operator. They create Paul_Taylor according to Table 5, Provider Group Settings Examples, on page 58. Thus, in these figures, Paul_Taylor is set up to use retail01 operator group as its provider group, since this is what the table specifies for Paul_Taylor. 1. Log in to the OSP GUI using an OSP provider operator that lets you manage PFMACCESS objects. Note: If pfmaccessprov provider operator exists on your installation, you may want to log in as pfmaccessprov. 2. In the menu that is to the left of the window that then appears, locate OPERATOR menu entry.
Page 60 of 968
11 September 2009
Figure 23 - Creating a CRE Provider Operator - Locating OPERATOR Menu Entry
11 September 2009
Page 61 of 968
OSP Level Setup
3.
Double-click on OPERATOR menu entry. The following window then appears.
Figure 24 - Creating a CRE Provider Operator - The Empty OPERATOR GUI Window 4. Update as necessary the parameters of General tab: 4.1. If the parameters of General tab do not appear, make them appear by clicking in the tabs name. 4.2. Enter into Login parameter the login name of the operator. The login name is the User Name that you use to log in to the CRE GUI. Note: In the figure below, Login parameter is set to Paul_Taylor. Feel free however to choose for this parameter any other text string that suits you. 4.3. Specify in Profile GUI frame the profiles to be assigned to the operator being created. You will normally want to assign the following profiles to the operator being created: creactorprov, ce20prov and aresprov. Note: To assign a profile, click on the HELP button that appears in the GUI frame and, in the list of profiles that then appears, double-click on the name of the profile. If you however have set up a profile of your own (in which case you need to make sure you have read section 3.1, Creating a Custom Profile for Your CRE Provider Operators, on page 54) and if you want that the operator being created uses that profile of your own, assign that profile to the operator. Note: Unless you have very good reasons to create your own profile and to want that some of your provider operators use it, you are recommended to assign creactorprov, ce20prov and aresprov profiles to your CRE provider operators.
Page 62 of 968
11 September 2009
4.4. Enter an integer value into Inactivity time-out [minutes] parameter. You will typically want to set this parameter to 999.
Figure 25 - Creating a CRE Provider Operator - Filling In General Tab 5. Update as necessary the parameters of Service tab.
11 September 2009
Page 63 of 968
OSP Level Setup
5.1. If the parameters of Service tab do not appear, make them appear by clicking on the tabs name. 5.2. Update the parameters of the tab as the figure below explains.
Enter here, for each checked service, the operator group that the operator will use as its provider group.
Indicate that the operator is a Provider one for each checked services. Be sure you select the four following services: . creactor, ce20, pfmlitesce and ares.
Figure 26 - Creating a CRE Provider Operator - Filling In Service Tab Note: In the above figure, Provider Group parameter of each checked service is set to retail01 because, in our example (which is based on Table 5, Provider Group Settings Examples, on page 58), Paul_Taylor provider operator has to use retail01 operator group as its provider group. As a result, Paul_Taylor can only manage object instances of retail01 retailer (since the name of Paul_Taylors provider group does not equal sdpprov). Note: If you want to enable a provider operator such as Paul_Taylor to manage all the object instances of all service retailers, you have to set Provider Group parameter of each checked service of that provider operator to sdpprov. In other terms, you then have to set up Paul_Taylor operator so that it uses sdpprov operator group as its provider group.

6.
On provider groups, see also section 3.3, CRE Objects Access Rule, on page 57. Create now the provider operator.
Page 64 of 968
11 September 2009
6.1. Click on OPERATOR text that appears in the menu bar. 6.2. In the menu that then appears, select Create.
Figure 27 - Creating an Operator - Running Create Command
3.5.
Creating a Service retailer
Each operator has to be associated with a service retailer (i.e., an instance of SERVICE RETAILER object of the CRE). Thus, if you just created an operator and no service retailer is already associated with the operator, you need to create that service retailer. This consists in creating an instance of SERVICE RETAILER object and in suitably setting that instance up.
To know which service retailer has to be associated with an operator, and thus to be able to know whether an operator is already associated with a service retailer, see section 3.3.1, The Access Rule, on page 57. To know which name you have to give to a service retailer you are going to create and which provider group you have to give to it, see section 3.3.1, The Access Rule, on page 57.
To create the service retailer of a given provider operator (e.g., of Paul_Taylor operator, as Table 5, Provider Group Settings Examples, on page 58, specifies it):
11 September 2009
Page 65 of 968
OSP Level Setup
1.
Log in to the CRE GUI as the provider operator (for example, as Paul_Taylor).
Figure 28 - Creating a Service Retailer - Logging In as an Operator of the Service Retailer to Create 2. In the menu that is to the left of the window that then appears, locate Service Retailer menu entry.
Figure 29 - Creating a Service Retailer 3. Double-click on Service Retailer menu entry. The following window then appears.
Page 66 of 968
11 September 2009
Figure 30 - Creating a Service Retailer - The Empty Service Retailer GUI Window
11 September 2009
Page 67 of 968
OSP Level Setup
Page 68 of 968
11 September 2009
4. Mandatory Convergent Rating Engine Settings

In order for the CRE to run well, some setup work is necessary. This chapter documents the objects that are involved in that setup work.
4.1.
4.1.1.
RE Configuration Object
Object Purpose
You use this object to configure the Rating Engine service of the CRE. You need to create one, and only one, instance of this object. Because that instance is unique, the RE service is configured identically for all the service retailers that your CRE installation hosts. Beware that many parameters of this object can only be set by an operator who is logged is as an Installer. Therefore, whenever you are not logged in that way, the corresponding entry fields will appear inactive (that is, these entry fields values are still visible but are shown in gray). Note: Whenever a parameter of this object can only be set by an operator who is logged in as an Installer, the text describing the parameter does not say who can update it. In the other case for example, entry fields that never can be updated from this object the text that describes the parameter says explicitly who can, or who cannot, update it. Note: The RE service reads every five minutes the data of its unique RE configuration object instance.
4.1.2.
General Tab
4.1.2.1. Parameter Description
Figure 31 - RE Configuration GUI - General Tab
11 September 2009
Page 69 of 968
Mandatory Convergent Rating Engine Settings
Table 6 - RE Configuration - sdpcfg - General Tab (Sheet 1 of 4) Parameter Number of Partitions* Description Enter here the number of Account partitions that the CRE is using.
When counting the Account Partitions, do not include Partition 0 (this partition is also sometimes referred to as P0) in the count, since Partition 0 is not an Account Partition.
See also Account Partition, on page 26.

When modulo partition algorithm is used, the partition algorithm uses this parameter to identify the Account partition of a given Account. Number of Contexts per SEP This is an unsigned integer value that gives the maximum number of entries (i.e., of RTx request contexts) that an RE contexts table can contain for a given SEP. Default value: 10000
See also 4.2.4.3, Sizing a Contexts Table, on page 108.
The RE has one RE contexts table per host on which it is running. The RE contexts table of such a host is used by all the SEPs of the host. But each of these SEPs cannot have more than Number of Contexts per SEP entries (i.e., RTx requests contexts) in that table. An RTx request context of the RE is 5000 bytes big.
Page 70 of 968
11 September 2009
To learn more about RTx request contexts and about contexts table, see also section 4.2.4.1, Purpose of the Tab, on page 103. Although the section introduces these notions for the CE, what it says fully applies to the RE too.
Table 6 - RE Configuration - sdpcfg - General Tab (Sheet 2 of 4) Parameter Partition Attribute* Description Indicate here which attribute of the Accounts the partition algorithm uses to identify the Account partition of a given Account. Choose one of the following Account attributes: Card Number Choose this if you want that the partition algorithm uses Card Number* parameter of Account object for choosing/locating a given Accounts partition. Identifier Choose this if you want that the partition algorithm uses Identifier (Login)* parameter of Account object for choosing/locating a given Accounts partition. MSID Choose this if you want that the partition algorithm uses MSID* parameter of Account object for choosing/locating a given Accounts partition.
Try to choose an Accounts attribute whose value never changes during the lifetime of the Accounts. Indeed, if the value changes, you will have to first remove the Account and then re-create it. Firstly, because the partition algorithm is only executed at time of an Account creation. Secondly, because the value change is likely to imply a change of partition for the Account.
11 September 2009
Page 71 of 968
Table 6 - RE Configuration - sdpcfg - General Tab (Sheet 3 of 4) Parameter Routing Algorithm* Description Choose here the method by which the CRE chooses the SEP group it will use to access the data of a given Account. This must be one of the following: None To access the data of a given Account, the CRE uses the default SEP group of the partition to which the Account belongs. Choose this only if the CRE is using the modulo partition algorithm and if you do not need to associate with some Account a SEP group other than the default SEP group of the partition of that Account. Range To access the data of a given Account, the CRE uses the SEP group that is associated to the range to which the Account belongs. Choose this value if the CRE is using the range partition algorithm. External To access the data of a given Account: If a SEP group has been explicitly associated to the Account, the CRE uses that SEP group. Otherwise, if no SEP group has been associated to the Account, the CRE uses the default SEP group of the partition to which the Account belongs. Choose this only if the CRE is using the modulo partition algorithm and if you do need to associate with some Account a SEP group other than the default SEP group of the partition of that Account.
See also Forced SEP Group, on page 752.

Maximum Balance Lock Time (sec)* Locking is the mechanism by which the RE ensures of the consistency of its Accounts data. The RE SEPs unlock as necessary the Accounts they lock. In spite of this, there might still be cases where a locked Account is not unlocked as it deserves. Think to the case of a SEP that unexpectedly terminates in consequence of a fatal error encountered. In order to smoothly cope with such situations, a SEP, every time it wants to lock an Account, first checks whether the Account has been locked for longer than this parameters value. If it is so, the SEP unlocks the Account and afterwards locks it for itself. Naturally, if it is not so, the SEP cannot access the Account. This must be an unsigned integer. Setting this parameter to 1 is safe.
Page 72 of 968
11 September 2009
Table 6 - RE Configuration - sdpcfg - General Tab (Sheet 4 of 4) Parameter Number of Contexts per Scan Description For each SEP that has entries in the RE contexts table, the RE does at regular time intervals (every 5 minutes) a bit of cleanup of that SEPs RTx request contexts. Cleaning up an RE contexts table for a given SEP consists in removing from that table that SEPs entries (i.e., the RTx request contexts) that are obsolete.
An obsolete RTx request context is one that has run out of its lifetime. The lifetime of an RTx request context is either from the corresponding RTx request (in case the RTx request specified a lifetime parameter not set to 0) or is deduced from the Default Reservation Lifetime defined for the RTx requests network event by Network Event Type object (i.e., in case the RTx request specified a lifetime parameter equal to 0).
Scanning in one shot all the RE contexts table entries of a given SEP can be too inefficient. By means of this parameter, you can control how many RTx requests, of a given SEP, the RE scans for removal every time it starts doing RE contexts table cleanup.
Thus, this value is per SEP, not per host. This must be an unsigned integer. Default value: The value of Number of Contexts per SEP parameter.

The value of Number of Contexts per SEP parameter could itself be the default value of Number of Contexts per SEP. To learn more about RTx request contexts and about contexts table, see also section 4.2.4.1, Purpose of the Tab, on page 103. Although the section introduces these notions for the CE, what it says fully applies to the RE too.
Partition Algorithm*
Indicate here which partition algorithm the CRE uses.
The partition algorithm is used by the CRE to know in which partition a given Account data are located.
Choose one of the following: Modulo Range

As you can only specify ranges of numeric values and as an Identifier is a character string, you cannot use Range partition algorithm when the partition attribute is set to Identifier. The partition algorithm is only executed at time an Account is created. Afterwards, it is never executed for that Account.
11 September 2009
Page 73 of 968
4.1.2.2. Setting Up Your Account Partitions

To set up your Account partitions, do the following steps in the order they are listed: 1. 2. 3. 4. Set the Partition Attribute of this objects unique instance. Set the Partition Algorithm of this objects unique instance. Set the Routing Algorithm of this objects unique instance. Create the necessary instances of Partition Ranges object, whatever partition algorithm is used. See also section 4.8, Partition Ranges Object, on page 153.
4.1.3.
Levels, Modules and Connectors Tabs Parameter Description
You use these tabs to control which flexibility points can be used by your CRE installation. And which ones cannot.
4.1.3.1. Reminder About Flexibility Points

A Flexibility Point activation is conditioned by up to three parameters:
1. 2. 3.
An Object Class instance A Module A Connector
For enabling a Flexibility Point, one specifies (according to the above-mentioned conditions) a particular LiteSCE script via the Flexibility Config object or Flexibility User object.
For more details, see chapter 25., "RE Flexibility Point Management", on page 869.
4.1.3.2. Purpose of the Tabs

The Connectors, Modules and Levels tabs of the RE Configuration set the primary conditions for the Flexibility Config and Flexibility User object instances to be taken into account.
4.1.3.3. Levels Tab

4.1.3.3.1. Purpose
The Levels tab allows or forbids, object class per object class, the activation of any Flexibility Point defined in Flexibility Config or Flexibility User.
Page 74 of 968
11 September 2009
4.1.3.3.2. Parameter Description
Figure 32 - RE Configuration GUI - Levels Tab
Table 7 - RE Configuration - Levels Tab - Parameter Values Parameter Object Class Name
Description When the flag of a given Object Class is checked, the Flexibility Points defined for any instance of it can be enabled, provided that the appropriate Connector and Module are enabled too in the RE Configuration. Otherwise, the Flexibility Points defined for any instance of it will never be enabled, whatever the status of the Connector and Module flags in the RE Configuration.
The following table lists the object classes for which Flexibility Points can be enabled/disabled. Table 8 - RE Configuration - Levels Tab - Object Classes Object Class Configuration
sdpcfg
Service Retailer
servret
Account Profile
servclas
Account
ppm
Usage Rating Rule

priceplan
11 September 2009
Page 75 of 968
Table 8 - RE Configuration - Levels Tab - Object Classes(continued) Object Class Tariff

pricetab
4.1.3.3.3. The Levels (Object Classes Priorities)

There are 6 object classes in function of which a Flexibility Point can be enabled. When checking if a Flexibility Point has to be activated, several Object Class conditions might be fulfilled at the same time. In order to solve the concurrence between several Flexibility Point definitions, levels have been assigned to the 6 object classes, which implies a priority order between them: 1. 2. 3. 4. 5. 6. Tariff Usage Rating Rule Account Account Profile Service Retailer Configuration For a detailed explanation of the relative level of each object, see section 25.4, RE Object Class Priority Order, on page 874.
4.1.3.4. Modules Tab

4.1.3.4.1. Purpose
The Modules tab allows or forbids, module per module, the activation of any Flexibility Point defined in Flexibility Config or Flexibility User.
4.1.3.4.2. Whats a Module

A Module is a script macro representing an independent part of the service logic. In other words, a Module implements a functionality of the RE, like for instance Estimating, Managing the Life Cycle, Rating, Reserving, and so on.
Page 76 of 968
11 September 2009
Figure 33 - RE Configuration GUI - Modules Tab
Table 9 - RE Configuration - Modules Tab - Parameter Values Parameter Module Name

Description When the flag of a particular Module is checked, the Flexibility Points defined for it can be enabled, provided that the appropriate Connector and Level (or Object Class) are enabled too in the RE Configuration. Otherwise, the Flexibility Points defined for it will never be enabled, whatever the status of the Connector and Level (or Object Class) flags in the RE Configuration.
The following table lists the modules for which Flexibility Points can be enabled/disabled. Table 10 - RE Configuration - Modules Tab - Modules (Sheet 1 of 2) Module None Reception (before receiving the event) Identification (before ppm identification) Recurrent_fee Life_cycle Authorization Get_reservation Estimate_cost Reserve Rate_event_before Rate_event_after
11 September 2009
Page 77 of 968
Table 10 - RE Configuration - Modules Tab - Modules (Sheet 2 of 2) Module Top-up End_call End_call_answer Post_processing Notify Balance Notify Bundle Identification After Notification
4.1.3.5. Connectors Tab

4.1.3.5.1. Purpose
The Connectors tab allows or forbids, connector per connector, the activation of any Flexibility Point defined in Flexibility Config or Flexibility User.
4.1.3.5.2. Whats a Connector

A Connector is an entry point into the script, launching the sequential execution of any number of Modules. A Connector corresponds to a particular event occurring in the service.
For the complete Module/Connector table, see section 25.4, RE Object Class Priority Order, on page 874.
Figure 34 - RE Configuration GUI - Connectors Tab
Page 78 of 968
11 September 2009
Table 11 - RE Configuration - Connectors Tab - Parameter Values Parameter Connector Name Description When the flag of a particular Connector is checked, the Flexibility Points defined for it can be enabled, provided that the appropriate Module and Level (or Object Class) are enabled too in the RE Configuration. Otherwise, the Flexibility Points defined for it will never be enabled, whatever the status of the Module and Level (or Object Class) flags in the RE Configuration.
Table 12 - RE Configuration - Connectors Tab - Connectors (Sheet 1 of 2) Connector Undefined Getppm Oneshot Estimate
Accupdate Fstreq Nextreq Endcall Cancel Reset Credupdreq Generic Fraudupd Ppmcreatebefore Ppmcreateafter Ppmmodifybefore Ppmmodifyafter Ppmremovebefore Ppmremoveafter Charge Fee Estimate Fee Account Update Arena Get and Check ppm
11 September 2009
Page 79 of 968
Table 12 - RE Configuration - Connectors Tab - Connectors (Sheet 2 of 2) Connector Get ppm All Buckets
Page 80 of 968
11 September 2009
4.1.4.
Statistics Tab
4.1.4.1. When Does the CRE Use these Settings

Whenever the CRE processes an RTx request, the CE first treats it, and afterwards forwards it to the RE. In consequence of this, the CRE produces two kinds of EDR information: RE EDR information, which is the EDR information the RE produced, and CE EDR information, which is the EDR information the CE produced. Whether the CRE delivers or not this information to either the RTx or to an external module, to both of them or to none of them, depends on a number of criteria. Which are: Either the RTx request tells the CRE to whom it has to deliver and to whom it cannot. The RTx request does that by setting its stlan_f and stext_f fields to a non-zero value (Note that both fields are always simultaneously set to a non-zero value). In this case, the CRE has to obey what the RTx request tells it in terms of EDR delivery. For example, if the RTx request tells the CRE to deliver its EDR information to the RTx (stlan_f field of the request set to 2), the CRE has to comply. Conversely, if the request tells the CRE it cannot deliver its EDR information to the RTx (stlan_f field set to 1), the CRE has to comply too. As a third example, if the RTx request tells the CRE it has to deliver its EDR information to an external module (stext_f field of request set to 2), the CRE has to comply.
In this case, trying to influence by means of RE or CE configuration settings to whom the CRE will deliver its EDRs is impossible. Or the RTx request lets the CRE choose to whom it will deliver its EDRs. This corresponds to the case where both stlan_f and stext_f of the request are set to 0. In this case, by means of RE and CE configuration settings (the RE configuration ones for the RE EDRs, the CE configuration ones for the CE EDRs), you can control to whom EDRs will be delivered. In this case, for the RE, you can use the following flags of this tab to control RE EDRs delivery: Send Ticket to External Module flag Send back Ticket to the RTx Module flag. While, for the CE, you can use the following flags of the CE configuration object to control to CE EDRs delivery: EDR Sending to Ext Module EDR Sending to RTX. Naturally, next sections explain these flags. But, more importantly, these sections also explain you how you set these flags so that the CRE only sends full EDRs (i.e. EDRs that concatenate the produced RE EDR and CE EDR), in a controlled way, to the RTx and to a given external module.
11 September 2009
Page 81 of 968
Figure 35 - RE Configuration GUI - Statistics Tab
Table 13 - RE Configuration - Statistics Tab (Sheet 1 of 2) Parameter Send Ticket to External Module Description Whenever the RTx request lets the CRE decide whether it will or not deliver its EDR to an external module, one of the two following cases arise: If this flag is checked, the RE hands over the RE EDR it has produced to an external module. Otherwise, the RE does not hand over its RE EDR to an external module.
Recommendation: Most probably, you will not want to check this flag. Indeed, you will usually want the RE and the CE EDRs to be both delivered to the same external module. If that is so, you can have the CRE deliver its RE and CE EDRs in one shot to a single external module by doing what follows: uncheck this flag, but check the Send Back Ticket to RTx Module flag of the RE Configuration as well as the EDR Sending To Ext Module flag of the CE configuration. That way, the RE will always send its RE EDR to the CE and the CE, upon reception of the RE EDR and before the sending of its CE EDR, will concatenate it to its CE EDR. As a result, the EDR sent to the external module contains both RE EDR information and CE EDR information.
Whenever the RTx request does not let the CRE decide whether it will or not deliver its EDR to an external module, this flag value is not used, since the CRE then obeys what the RTx request then tells the CRE to do.
In this latter case, if the RTx request tells the CRE to send its EDR to an external module, the CRE will send its EDR, containing both its RE EDR and its CE EDR, to the external module that the CE configuration specifies (thus not to the External Module SEP Group that the RE configuration specifies). Thats guaranteed, whatever the settings of this tab.
Page 82 of 968
11 September 2009
Table 13 - RE Configuration - Statistics Tab (Sheet 2 of 2) Parameter Send Back Ticket to RTx Module Description Whenever the RTx request lets the CRE decide whether it will or not deliver its EDR to the RTx, one of the two following cases arise: If this flag is checked, the RE hands over to the CE (not to the RTx) the RE EDR it has produced. At time the RE EDR arrives to the CE, this latter will build an EDR made up of the RE EDR received and of its own CE EDR. As soon as the CE has done that, the CE will do what follows: Hand over the built EDR to the RTx if, and only if, EDR Sending to RTx flag of the CE configuration is set. Hand over the built EDR to the external module attached to the CE configuration if, and only if, EDR Sending to Ext Module flag of the CE configuration is set. Otherwise, the RE hands over neither to the CE nor to the RTx the RE EDR it has produced. Whenever the RTx request does not let the CRE decide whether it will or not deliver its EDR to the RTx, this flag value is not used, since the CRE then obeys what the RTx request then tells it to do.
External Module Partitioned
If this flag is checked, the name of the SEP group to which the RE sends a given EDR depends on the number of the partition that stores the data of the Account that the EDR is about. The name of the SEP group is built by appending string _Pn to External Module SEP Group parameter value, n being the number of the partition of the Account that the EDR to send is about. This naturally implies that the external module is expecting to receive its EDRs from these SEP groups. In other terms, this implies that the external module is partitioned (with the same number of partitions as CRE). Otherwise, the RE always uses one the same SEP group to send its EDRs to the external module. Thats the SEP group that External Module SEP Group parameter indicates.
4.1.4.3. Tips
4.1.4.3.1. Basic Recommendation
The basic recommendation is this: If you can afford that, let the CE take care of everything in terms of EDR delivery to RTx and to an external module whenever the RTx request lets the CRE choose to whom deliver. Can you afford doing that? Yes, you can afford doing that if all you want is control (naturally, to the extent the RTx request allows you to control that) the delivery of full EDRs (i.e. EDRs that contain both RE and CE EDR information) to the RTx and to an external module. In such a case, to let the CE take care of everything, do what follows in the unique RE configuration object instance of the CRE:
11 September 2009
Page 83 of 968
Uncheck Send Ticket to External Module Check Send Back Ticket to RTx Module. This latter setting guarantees you that the CE will always receive the RE EDR, so that it can add it to the EDR it has to deliver. As a precaution, specify in External Module SEP Group the same SEP group name as the one the CE uses to deliver EDRs to the external module. As a precaution again, specify in External Module Partitioned flag the same values as the External Module Partitioned flag of CE configuration. Now, to enable/disable (to the extent the RTx request allows the CRE to do that) EDR deliveries, only act from the CE configuration GUI.
4.1.4.3.2. To Always Send a Full (i.e. RE + CE) EDR to the RTx

Uncheck Send Ticket to External Module in RE Configuration Check Send Back Ticket to RTx Module in RE Configuration. Check EDR Sending to RTx in CE Configuration
4.1.4.3.3. To Never Send an EDR to the RTx

Uncheck Send Ticket to External Module in RE Configuration Check Send Back Ticket to RTx Module in RE Configuration. Uncheck EDR Sending to RTx in CE Configuration
4.1.4.3.4. To Always Send a Full (i.e. RE + CE) EDR to a Given External Module
Uncheck Send Ticket to External Module in RE Configuration Check Send Back Ticket to RTx Module in RE Configuration. Check EDR Sending to Ext Module in CE Configuration Ensure that SEP Group Prefix for External Module of CE configuration specifies the SEP group name of the external module.
4.1.4.3.5. To Never Send a Full (i.e. RE + CE) EDR to a Given External Module
Uncheck Send Ticket to External Module in RE Configuration Check Send Back Ticket to RTx Module in RE Configuration. Uncheck EDR Sending to Ext Module in CE Configuration
Page 84 of 968
11 September 2009
4.1.5.
SEP Groups Tab Parameter Description
Figure 36 - RE Configuration GUI - SEP Groups Tab
Table 14 - RE Configuration - SEP Groups Tab (Sheet 1 of 3) Parameter Community Engine

Description This field indicates the name of the SEP group dedicated to the Community Engine processes. This field indicates the name of the SEP group dedicated to the Notification processes. This field indicates the name of the SEP group dedicated to the Event Scheduler processes. External Module
Notification
Event Scheduler
11 September 2009
Page 85 of 968
Table 14 - RE Configuration - SEP Groups Tab (Sheet 2 of 3) Parameter Type

septype
Description Type of partitioning method used, if the External Module is partitioned. You can check if the External Module is partitioned in the Statistics flag (see page 83). There are 3 partitioning methods available: RE Partitioned If you select RE Partitioned, the name of the External Modules SEP group will be selected according to the name of the Rating Engines partitions. For instance: Creactor_P1 associated with event_collector_P1. Modulo Card Number If you select Modulo Card Number, the name of the External Modules SEP group will be selected according to a modulo on the Accounts Card Number. For instance: for Card Number 5, Modulo 4, we will use event_collector_P1. You will have to specify the modulo to be used in the field SEP Module below. Modulo MSID If you select Modulo MSID, the name of the External Modules SEP group will be selected according to a modulo on the Accounts MSID. You will have to specify the modulo to be used in the field SEP Module below.
External Module SEP Group
Whenever the RE has to send an EDR to an external module, it needs to choose the SEP group to which it will send the EDR. This parameter provides the RE with information that is necessary for choosing that SEP group. Whenever External Module Partitioned flag (see page 83) is checked, the RE chooses the SEP group in function of the number of the partition of the Account that the EDR is about. In this case, the RE has thus at its disposal one SEP group per CRE Account partition. The name of each SEP group is built by appending string _Pn to this parameter value, where n is the number of an Account partition. Enter thus here the part of these SEP group names that is common to all of them. Otherwise, the RE always sends its EDRs to the SEP group this parameter specifies. That is, no string is then appended to the SEP group this parameter specifies. Enter thus here the SEP group name of an external module that is able to receive EDRs. Pfmstat and the Event Collector are such modules examples.
Page 86 of 968
11 September 2009
Table 14 - RE Configuration - SEP Groups Tab (Sheet 3 of 3) Parameter SEP Module

sepmodul
Description
Only available with Type Modulo Card Number or MSID
Value to be used as modulo for computing the External Modules partitioning. Format: Unsigned integer between 1 and 15.
4.1.6.
Fees Tab Parameter Description
Figure 37 - RE Configuration GUI - Fees Tab
11 September 2009
Page 87 of 968
Table 15 - RE Configuration - Fees Tab Parameter Fees Activated Description Option indicating whether or not the Subscriptions life cycle in the CRE is linked to the execution of scheduled non-usage events.
If you check this flag

then the Subscriptions including non-usage Service Offer(s) will have their life cycle subdued to the on-time correct execution of the related scheduled events.
If you dont check this flag

then the Subscriptions including non-usage Service Offer(s) will have their life cycle totally independent from the related scheduled events. So even if some scheduled event fails, it wont impact the Subscriptions State.
See 10.4.4, Subscriptions Life Cycle, on page 296.

Fee Processing Timeout Timer for the maximum delay to elapse between a Subscription management operation performed via the GUI and the processing of the corresponding non-usage events. For instance, when activating a Subscription via the GUI, the CRE may launch an activation fee event. If this event is not fully processed by the end of the period set in this field, then an error message is issued and/or the Subscription is set to Suspended. Unit: seconds.
See 10.4.4, Subscriptions Life Cycle, on page 296.
Page 88 of 968
11 September 2009
4.1.7.
ARENA Tab Parameter Description
This tab lists the ARENA parameters that are defined for this object.
Figure 38 - RE Configuration GUI - ARENA Tab
Table 16 - RE Configuration - ARENA Tab Parameter

Description Logical name of the ARENA attribute. This parameter is set in the ARENA object and is only available at display in the RE Configuration GUI.
Logical Name
DB Name
Database name of the ARENA attribute. This parameter is set in the ARENA object and is only available at display in the RE Configuration GUI.
Type
Data Type of the ARENA attribute. This parameter is set in the ARENA object and is only available at display in the RE Configuration GUI.
Value
Value of the ARENA attribute. This parameter receives a default value in the ARENA object. If you are logged in either as a Provider or as an Installer, you can use the RE Configuration GUI to give a new value to this parameter.
4.1.7.1. Global Variables

Some variables defined in this tab may impact the behaviour of some service logic, while being not referred to in the objects GUIs that are related with this logic. For example, the behaviour of the Top-up mechanism is directly determined by the value of the PPS_RESET Arena variable (if it is defined in the ARENA tab described above). However, the Top-up Profile GUI does not present a flag to activate this behaviour. The PPS_RESET Arena variable is a Boolean variable. The default value is false.
11 September 2009
Page 89 of 968
If the variable PPS_RESET does not exist or is equal to fasle, the behavior of Top-up for refillable mono-bucket bundle is as follows: the new value in the bundle is equal to the sum of the current value plus the Top-up value. This behavior is independent of the End of Validity Date of the bucket. If the variable PPS_RESET exists and is equal to true, then the behavior of Top-up for refillable mono-bucket bundle is as follows: 1. 2. if the bucket is still valid at the date of the topup (if the End of Validity Date of the bucket is greater than or equal to the Top-up date), then the behavior is the same as above. if the bucket is not valid at the date of the topup (if the End of Validity Date of the bucket is smaller than the topup date), then the value of the bucket is set to the value of the topup. The value that was contained in the bucket before the Top-up is lost and its amount is reported into the stat ticket for the Top-up.
In all cases, the End Validity Date of the bucket is set to the validity computed by the Top-up action.
4.1.8.
Partition Range Tab Parameter Description
This tab gives you an overview of the Account partitions settings, by displaying a list of rows that indicate which SEP groups the CRE is allowed to use whenever it needs to access a given Account partition.

When range partition algorithm is used, one row per range of values that is associated to an Account partition is shown. Its then easy to deduce, from each range of values displayed, which SEP group the CRE uses to access the Accounts that fall in that range. Thats the SEP group that belongs to the same row as the range. Its also then easy to deduce, from each range of value displayed, in which Account partition any Account that falls in that range is stored. Thats the partition that is indicated in the same row as the range. Its also easy to see which ranges are associated to a given partition. Just click on Partition word in the tab. This will sort the rows either in ascending or descending order. Click a second time on the word if you did not get the sort order you want. And if you want to know which ranges are associated to a given SEP group, proceed similarly by clicking one or more times on SEP Group word in the tab. When modulo partition algorithm is used, one row per SEP group used for accessing Account partitions is shown. Its then easy to see which SEP groups are the default SEP groups of which partitions. Just look for rows whose Default column is set to 1. In each of these rows, the SEP group the row mentions is the default SEP group of the partition that the same row mentions. Its then also easy to see which SEP groups are associated to a given partition. Just click on Partition word in the tab. This will sort the rows either in ascending or descending order. Click a second time on the word if you do not get the sort order you want.
Page 90 of 968
11 September 2009
Figure 39 - RE Configuration GUI - Partition Range Tab
For more info, see also 4.8, Partition Ranges Object, on page 153. Table 17 - RE Configuration - Partition Range Tab (Sheet 1 of 2) Parameter Range Description When range partition algorithm is used, this parameter shows the highest value of a range of values that is associated to the corresponding SEP group of the corresponding partition. When modulo partition algorithm is used, this parameter shows no meaningful value.
To easily figure out the lowest and the highest bounds of each range of value, sort the displayed rows by ascending or descending Range value (for doing that, click on Range word in the tab. If the sort order does not suit you, click a second time on Range word).
This parameter is set by means of the Partition Ranges object and is only available at display in the RE Configuration GUI. Partition This parameter indicates the number of the partition to which the corresponding SEP group (the one that SEP group parameter mentions) is associated. If range partition algorithm is used, this parameter indicates the number of the partition that is associated to the corresponding range (the one that Range parameter specifies). The number you see here corresponds to Partition ID of the Account partition, as shown by PARTITION object of PFMCONFIG. This parameter is set by means of the Partition Ranges object GUI and is only available at display in the RE Configuration GUI.
11 September 2009
Page 91 of 968
Table 17 - RE Configuration - Partition Range Tab (Sheet 2 of 2) Parameter Default Description When range partition algorithm is used, this parameter indicates no meaningful value. When modulo partition algorithm is used: If this parameter is set to 1, the corresponding SEP group is the default SEP group of the corresponding partition. If this parameter is set to 0, the corresponding SEP group is not the default SEP group of the corresponding partition. This parameter is set by means of the Partition Ranges object GUI and is only available at display in the RE Configuration GUI. SEP Group Indicates a SEP group that is associated to the corresponding partition. When range partition algorithm is used, this parameter also indicates the SEP group that is associated to the corresponding range of values. This parameter is set by means of the Partition Ranges object GUI and is only available at display in the RE Configuration GUI.
Page 92 of 968
11 September 2009
4.1.9.
Advanced Tab Parameter Description
Figure 40 - RE Configuration GUI - Advanced Tab
11 September 2009
Page 93 of 968
Table 18 - RE Configuration - Advanced Tab (Sheet 1 of 3) Parameter Last Ten Events Enabled Description You use this parameter to activate or deactivate the Last Ten Events feature. You also use this parameter to know whether the feature is currently activated (i.e., enabled) or not. When this parameter is checked, the Last Ten Events feature is activated (i.e., up and running). Else, the Last Ten Events feature is not activated.
To know what the Last Ten Calls feature is about, see section 19.3.12, Last 10 Events Tab Parameter Description, on page 789.
How the Last Ten Events Feature Is Activated on an Account To have the Last Ten Events activated on an Account, the Account must have been created at a time when this parameter was checked. The feature is then activated on the Account as soon as the Account is created.
Thus, if you create an Account at a time when this parameter is unchecked (i.e., at a time when the Last Ten Events feature is not activated), checking this parameter will never activate the Last Ten Events feature on the Account. In fact, activating the Last Ten Events feature on such an Account requires some system-level intervention, carried out by an Alcatel support engineer. On how such an intervention can be carried out, see manual ALCATEL 8618 Convergent Rating Engine 2.6.2 Installation and Optimization Guide, Version 1.0 or Higher, 3CL-02660-BAHA-RJZZA.
You can activate (i.e., check) and de-activate (i.e., uncheck) this parameter as many times as you want. Of course, once the Last Ten Events feature has been activated on an Account, unchecking this parameter later on de-activates the Last Ten Events feature on the Account (which means that the Last Ten Events tab of the Account is still shown but is no longer updated and hence keeps showing the old events) and checking again this parameter later on re-activates the Last Ten Events feature on the Account (which means the CRE then resumes updating the Last Ten Events tab of the Account).
Page 94 of 968
11 September 2009
Table 18 - RE Configuration - Advanced Tab (Sheet 2 of 3) Parameter Enable Dynamic Counters Description Option determining whether the Dynamic Counter Creation capability is activated or not for the current installation of the Convergent Rating Engine.
IMPORTANT
This functionality is activated at installation time, when the RE Configuration object is created. Even the operator logged as installer cannot modify it later on.

then whevener a Counter has to be updated (whether via a Counter Criterio or via any other logic, including LiteSCE), if the current Account doesnt have yet that particular Counter, it will be automatically immediately created.
If you leave this flag unchecked

then whenever a Counter has to be updated, if the current Account doesnt have yet that particular Counter, it wont be dynamically created. No Counter update will then be performed by the Rating Engine.
See also 12.3.6, Counter Criterion, on page 401.

Customer Subscription History Enabled Option determining the activation of the following two features, for the current installation of the Convergent Rating Engine: Customer Subscription History Customer Commercial Offer History
IMPORTANT: 2 features not treated the same way The Customer Subscription History functionality is activated at installation time, when the RE Configuration object is created. Even the operator logged as installer cannot modify it later on. Nevertheless, the Customer Commercial Offer History functionality can still be activated after installation.

then the last five changes of State of each Customer Subscription and the last five changes of the Customers default Commercial Offer will be displayed in the corresponding GUIs. They will also be used by the Convergent Rating Engine for rating non-real-time events.

then the changes of State of the Customer Subscriptions wont be kept by the Convergent Rating Engine. The changes of the Customers default Commercial Offer will be displayed in the corresponding GUI, but wont be used by the Convergent Rating Engines logic.
See also 10.4.4.6, Subscription History, on page 304. See also 27.1.4, Commercial Offer History, on page 900.
11 September 2009
Page 95 of 968
Table 18 - RE Configuration - Advanced Tab (Sheet 3 of 3) Parameter Automatic Subscription Activation

subact_f
Description Option determining whether the automatic Subscription activation capability is activated or not for the current installation of the Convergent Rating Engine.
IMPORTANT This functionality is activated at installation time, when the RE Configuration object is created. Even the operator logged as installer cannot modify it later on. Moreover, some limitations apply to the automatic Subscription activation feature: see also 10.4.4.2.1, Conditions for automatically activating a Subscription, on page 300.

then when an Accounts life cycle status is activated, the Subscriptions of that Account and their subsequent Scheduled Account Events are immediately automatically activated as well. If the Automatic Subscription Activation is enabled, then the Reset Account feature is not available anymore. All requests to the connector net_evt.reset will return the result code 300.140. Read more in 10.4.4.2, Automatic Subscription Activation, on page 299.

then when an Accounts life cycle status is activated, the Subscriptions of that Account and their subsequent Scheduled Events wont be automatically activated.
4.2.
CE Configuration Object
For understanding the role of the Community Engine, read Part VIII., Community Engine, on page 882.
4.2.1.
Object Purpose
You use this object to configure the Community Engine service of the CRE. You need to create one, and only one, instance of this object. Because that instance is unique, the CE service is configured identically for all the service retailers that your CRE installation hosts. Beware that many parameters of this object can only be set by an operator who is logged is as an Installer. Therefore, whenever you are not logged in that way, the corresponding entry fields will appear inactive (that is, these entry fields values are still visible but are shown in gray). Note: Whenever a parameter of this object can only be set by an operator who is logged in as an Installer, the text describing the parameter does not say who can update it. In the other case for example, entry fields that never can be updated from this object the text that describes the parameter says explicitly who can, or who cannot, update it.
Page 96 of 968
11 September 2009
4.2.2.
General Parameters and Forwarding of Statistics
Figure 41 - CE Configuration GUI
Table 19 - CE Configuration - (Sheet 1 of 4) Parameter

Description The CE service reads at regular time intervals the data of its unique CE configuration object instance. This parameter defines that time interval. Moreover, when CE contexts cleanup (removal of obsolete CE contexts) is enabled (as governed by Context tab of this object), the CE does a bit of CE context cleanup at regular time intervals.
Configuration Reading Period [10s]
On CE contexts, see section 4.2.4, Context Tab, on page 103.
This parameter also defines that time interval. The value you enter here is expressed in tens of seconds. This must be an unsigned integer lower than or equal to 255. Default value: 6
11 September 2009
Page 97 of 968
Table 19 - CE Configuration - (Sheet 2 of 4) Parameter Max Nbr of Loops in Trees (Tree Ref Leaves) Description This parameter is meant for the CRE rules (such as Charging rules) that can be implemented by means of more than one decision trees. In that case, a decision tree can always trigger the execution of some decision tree. If, during a run of such a rule, the triggered decision tree is one the run already executed in the past, there is a risk that the run, and thus the CE, enters into a loop. You use this parameter to avoid such loops, since the value you give to this parameter limits the number of times a rule run can call decision trees. Setting initially this parameter to 10 appears to be a reasonable choice.
Whenever only one decision tree is involved in the execution of a rule, there is no danger that the rule execution enters into a loop.
Gateway Mode
Check this flag if you want the CE to work in gateway mode. Unchek this flag if you want the CE to work in normal mode. Default: Normal mode
Changing this setting while the CE is running takes effect without having to re-start the CE, since the CE regularly re-reads the data of its unique CE configuration object instance.
Gateway Mode In gateway mode, the CE only dispatches the RTx Requests to the RE. The CE is then only used to route the RTx requests to the RE. In this case, the CE produces no CE EDR information. However, if Send Back Ticket to RTx Module is checked in the RE configuration, the CE still produces an EDR, which is made up of the EDR information the RE produced. Normal Mode In normal mode, the CE selects the customers who will pay for the event the RTx request is about. It also selects the customer's account and the service offer that will be used to rate and charge that event. Unlike when it is in the Gateway Mode, during this processing, the CE generates CE EDR information. If Send Back Ticket to RTx Module is checked in the RE configuration, the CE produces an EDR that is made up of the EDR information that both the RE and the CE produced.
When some CE setting depends on whether the CE is in gateway mode or not, the text of this manual indicates that explicitly. Conversely, whenever such a mention is not present for a CE setting, that setting does not depend on whether the CE is in gateway mode or not.
Page 98 of 968
11 September 2009
Table 19 - CE Configuration - (Sheet 3 of 4) Parameter EDR Sending to Ext Module Description

Recommendation: Before you read this, be sure you have taken knowledge of what section 4.1.4, Statistics Tab, on page 81, says. Before you decide to check this flag, make sure that parameter SEP Group Prefix for External Module is filled in with a suitable value. Otherwise, the CRE will not agree to check this flag.
Whenever the RTx request lets the CRE decide whether it will or not deliver its EDR to an external module, one of the two following cases arise: If this flag is checked, the CE hands over its EDRs to an external module. If the CE generated EDR information, the handed over EDR contains that information. If Send Back Ticket to RTx Module flag of RE configuration is checked, that EDR also contains the EDR information that the RE generated. Otherwise, the CE hands over no EDRs to an external module. Whenever the RTx request does not let the CRE decide of whether it will or not deliver its EDR to an external module, this flag value is not used, since the CRE then obeys what the RTx request then tells the CRE to do. In this latter case, when the CE hands over an EDR to an external module, it contains both the EDR information the CE generated (if the CE generated EDR information) and the EDR information the RE generated. EDR Sending to RTx
Recommendation: Before you read this, be sure you have taken knowledge of what section 4.1.4, Statistics Tab, on page 81, says.
Whenever the RTx request lets the CRE decide of whether it will or not deliver its EDR to the RTx, one of the two following cases arise: If this flag is checked, the CE hands over to the RTx its EDRs. If the CE generated EDR information, the handed over EDR contains that information. If Send Back Ticket to RTx Module flag of RE configuration is checked, that EDR also contains the EDR information that the RE generated. Otherwise, the CE hands over no EDRs to the RTx. Whenever the RTx request does not let the CRE decide of whether it will or not deliver its EDR to the RTx, this flag value is not used, since the CRE then obeys what the RTx request then tells the CRE to do. In this latter case, when the CE hands over an EDR to the RTx, it contains both the EDR information the CE generated (if the CE generated EDR information) and the EDR information the RE generated.
11 September 2009
Page 99 of 968
Table 19 - CE Configuration - (Sheet 4 of 4) Parameter External Module Partitioned Description If this flag is checked, the name of the SEP group to which the CE sends a given EDR depends on the number of the partition that holds the data of the Account that is used by the customer that the EDR is about. The name of the SEP group is built by appending string _Pn to SEP Group Prefix for External Module parameter value, n being the number of the partition of the Account that is used by the customer that the EDR is about. This naturally implies that the external module is expecting to receive its EDRs from these SEP groups. In other terms, this requires that the external module is partitioned (with the same number of Account partitions as the CRE) Otherwise, the CE uses one, and only one, SEP group to send its EDRs to the external module. Thats the SEP group that SEP Group Prefix for External Module parameter indicates.
4.2.2.2. Tips
Be sure you have read section 4.1.4.3, Tips, on page 83. It contains useful tips that applies to the way you configure the CE.
Page 100 of 968
11 September 2009
4.2.3.
Communication Tab
Figure 42 - CE Configuration GUI - Communication Tab
Table 20 - CE Configuration - - Communication Tab (Sheet 1 of 2) Parameter CE-RE Communication Time-Out Description This must be an unsigned integer value lower than or equal to 255. This specifies a number of seconds. For each RTx request that the CE submits to the RE, this parameter specifies the amount of time within which the CE expects the result of the processing of the RTx request by the RE. Default: 1 second SEP Group for Emulation End This field indicates the name of the SEP group dedicated to call end test and simulation processes. You do not need to enter a value here. SEP Group for Emulation Next This field indicates the name of the SEP group dedicated to next reservation test and simulation processes. You do not need to enter a value here. SEP Group for Emulation Start This field indicates the name of the SEP group dedicated to call start test and simulation processes. You do not need to enter a value here.
11 September 2009
Page 101 of 968
Table 20 - CE Configuration - - Communication Tab (Sheet 2 of 2) Parameter RE Service Name Description Enter here the name of RE service as it has been specified to the Generic Installer Service Name entry field at time RE service was installed on the platform. Usually, the name of the RE service is creactor. SEP Group Prefix for External Module Whenever the CE has to send an EDR to an external module, it needs to choose the SEP group to which it will send the EDR. This parameter provides the CE with information that is necessary for that. Whenever External Module Partitioned flag is checked, the CE chooses the SEP group in function of the number of the partition of the Account that is used by the customer that the EDR is about. In this case, the CE has thus at its disposal one SEP group per CRE Account partition. The name of each SEP group is built by appending string _Pn to this parameter value, where n is the number of the Account partition that is used by the customer that the EDR is about. Enter thus here the part of these SEP group names that is common to all of them.
Otherwise, the CE always sends its EDRs to the SEP group this parameter specifies. Enter thus here the SEP group name of an external module that is able to receive EDRs. Pfmstat and the Event Collector are such modules examples.
Page 102 of 968
11 September 2009
4.2.4.
Context Tab
4.2.4.1. Purpose of the Tab

Some RTx requests are correlated with each other, and thus make up a specific series of correlated RTx requests. In order to suitably process any RTx request that is part of a such a series, the CE maintains some context information that is specific to the series and that the CE retrieves and updates as it processes RTx requests of the series. To give a concrete example, a First Reservation RTx request arriving to the CE starts such a series of correlated RTx requests. Indeed, that RTx request may be followed by a number of Next Reservation RTx requests that are linked to it. To be able to suitably process each Next Reservation RTx request, the CE needs to maintain some context information that is specific to the series. Such a context information, that is specific to a given series of correlated RTx request, is hereby called an RTx request context (i.e. the context that the CE uses when processing each RTx request in the series). As, at the same time, several series of correlated RTx requests may have been started in the CE (e.g. a number of First Reservation RTx requests have arrived and have each started their own series of RTx requests), there may be, at any time, several RTx request contexts present in the CE, one per started series. The set of all the RTx request contexts that are present at a time in the CE is called the CE contexts table. By means of this tab, you customize and manage the contexts table of the CE.
Note: To implement that CE contexts table, the CE uses SHMDB, which is an Alcatel proprietary technology that allows sharing of RAM data (i.e. volatile data) between processes. The CE contexts table is an SHMDB volatile table, of which each tuple is an RTx request context. Note: Only some kinds of RTx requests can be part of a series of correlated requests. Thus, only these kinds of RTx requests can be associated to an RTx request context.
11 September 2009
Page 103 of 968
Figure 43 - CE Configuration GUI - Context Tab
Page 104 of 968
11 September 2009
Table 21 - CE Configuration - - Context Tab (Sheet 1 of 4) Parameter DSC File id (e.g.: 99999) Description This must be an unsigned integer, greater than 10000 (to avoid using RI values which use 4 digits that are already assigned to SEPs). This parameter value is used to build up the name of the SHMDB DSC file that describes the structure of the CE contexts table (which is a shared volatile table whose tuples are each an RTx request context). That built name is as follows: sh_nnnnn.dsc where nnnnn is to be replaced by the value of this parameter. If file sh_nnnnn.dsc does not exist at time you create (i.e. select Create in this object pull-down menu) or modify (i.e. select Modify in this object pull-down menu) the unique instance of the CE configuration, then the CE creates the DSC file and fills it in with the suitable data. You then need to restart all the CE SEPs, if you want them to use that DSC file. For example, if you modified Data Size and/or Number of Tuples parameter(s), the new values have been stored in the new DSC file and will thus be used only if you restart the CE SEPs. Otherwise, the existing file is not touched. Thats important to now. Because, if you modified the value of Data Size and/or of Number of Tuples parameter(s), which are stored in SHMDB DCS files, the existing SHMDB DSC file is not updated with these new values. Therefore, even if you restart the CE SEPs, these new values wont be used by the CE.
As a result, every time you modify Data Size and/or Number of Tuples parameter value(s), you need also to modify this parameter value, by giving it a DSC File Id that is not used. And afterwards restart the CE SEPs.
Data Size
This is an unsigned integer that gives the size in bytes of each tuple (i.e. each RTx request context) of the CE contexts table. This parameter value is to be stored into the DSC file that corresponds to DSC File Id parameter. It is safe to set this parameter to 600 or higher.
If you modify the value of this parameter and the DSC file corresponding to the value in DSC File Id parameter is already existing, you need to give to DSC File Id parameter a value that is not used yet by another DSC file. Otherwise, the new value of this parameter has no chance to be taken into account by SHMDB. Be also sure you fully read this tables entry that documents DSC File Id parameter.
11 September 2009
Page 105 of 968
Table 21 - CE Configuration - - Context Tab (Sheet 2 of 4) Parameter Number of Tuples Description This is an unsigned integer value that gives the maximum number of tuples (i.e. RTx request contexts) that the CE contexts table can contain. This parameter value is to be stored into the DSC file that corresponds to DSC File Id parameter.
See also 4.2.4.3, Sizing a Contexts Table, on page 108.
If you modify the value of this parameter and the DSC file corresponding to the value in DSC File Id parameter is already existing, you need to give to DSC File Id parameter a value that is not used yet by another DSC file. Otherwise, the new value of this parameter has no chance to be taken into account by SHMDB. Be also sure you fully read this tables entry that documents DSC File Id parameter. There are as many CE contexts tables as machines that are running the CE. It goes without saying that this limitation is per CE contexts table. That is, each CE contexts table can contain up to Number of Tuples entries (i.e., RTx Request Contexts).
SHMDB Path
This is a character string. Enter here the path to the directory where the DSC files (.dsc extension) are used. Use this flag to enable/disable the cleanup of the CE context. CE context cleanup consists in removing, from the CE contexts table, the tuples (i.e., the RTx request contexts) that are obsolete (each RTx request context has a lifetime). Whenever this flag is checked, CE contexts table cleanup is enabled (active). Although it is enabled, it will enter into action only if current time falls between Start Time and Stop Time parameter values. If First Reservation and Next reservation RTx requests are used, you need to check this flag. Otherwise, CE contexts table cleanup is disabled (not active).
Standard path: in/local/conf/shmdb Cleaning Activated
Cleaning Winter Flag
If this flag is set, the CE does not use daylight saving time when it checks whether the current time is between start time and stop time or not.
In the summer, to know whether the current time falls in the start-stop interval, the CE checks whether system time minus one hour is in the start-stop interval. But in the other seasons, it checks whether system time is in the interval.
If this flag is not set, the CE uses daylight saving time when it does that check.
Whatever the season, to know whether the current time falls in the start-stop interval, the CE always checks system time against that start-stop interval.
Page 106 of 968
11 September 2009
Table 21 - CE Configuration - - Context Tab (Sheet 3 of 4) Parameter Start Time Enter here a time. Description
See also Time, on page 37.
Provided that Cleaning Activated flag is checked, the CE starts effectively doing CE contexts table clean up as soon as start time of the current day is reached. Until then, no clean up is thus done. Default value: 00:00:00 Stop Time Enter here a time.
See also Time, on page 37.
The CE stops effectively doing CE contexts table clean up as soon as stop time of the current day is reached. Default value: 23:59:59 Table Fraction When this radio button is checked, every time the CE does a bit of CE contexts table cleanup (see Configuration Reading Period [10s], on page 97), it scans, for cleanup purposes, a fraction, expressed by Fraction parameter, of the CE RTx request contexts, starting: Either just after the last RTx request context that the previous bit of CE contexts table cleanup scanned, in case the previous bit did not reach the end of the CE context. Or from the first RTx request context of the CE contexts table, in the other case. As soon as it encounters an RTx request context that is obsolete, the CE removes that RTx request from its CE contexts table. Fixed Nb Tuples When this radio button is checked, every time the CE does a bit of CE contexts table cleanup (see Configuration Reading Period [10s], on page 97), it scans, for cleanup purposes, Nb Tuples RTx request contexts, starting: Either just after the last RTx request context that the previous bit of CE contexts table cleanup scanned, in case the previous bit did not reach the end of the CE contexts table. Or from the first RTx request context of the CE contexts table, otherwise. As soon as it encounters an RTx request context that is obsolete, the CE removes that RTx request from its CE contexts table. Fraction Enter here an unsigned integer. This parameter is used when Table Fraction is checked. It expresses a fraction of the CE contexts table tuples (i.e. of the CE RTx request contexts) that the CE scans for cleanup every time it does a bit of cleanup. That fraction is equal to: 1 / (this parameter value) By default, this parameter is set to 1000.
Whenever this parameter shows 0, the default value is used.
11 September 2009
Page 107 of 968
Table 21 - CE Configuration - - Context Tab (Sheet 4 of 4) Parameter Nb Tuples Enter here an unsigned integer. This parameter is used when Fixed Nb Tuples is checked. It expresses a number of CE contexts table tuples (i.e. a number of CE RTx request contexts) that the CE scans for cleanup every time it does a bit of cleanup. It is advised to enter here a value that is not higher than 1000. By default, this parameter is set to 1000. Description
Whenever this parameter shows 0, the default value is used.
4.2.4.3. Sizing a Contexts Table

To size the contexts table of a given host, whether the contexts table is either an RE or a CE one, you need to know: How many reservation requests the host is able to process per second. A reservation request corresponds to either a First Reservation RTx request or to Next Reservation RTx request. The lifetime of the requested reservations. When lifetime parameter in a reservation request is non zero, the lifetime of the requested reservation is the value that lifetime parameter specifies. Else, the lifetime of the requested reservation is deduced from Default Reservation Lifetime parameter that Network Event Type object specifies for the corresponding network event type. The size in bytes of an entry of the contexts table. Here is a sizing example for the RE. Assuming that the host is able to process 100 reservations per second and that the average lifetime of a reservation is 2 minutes (120 seconds), the minimum number of RE contexts table entries is: 100 (reservations/sec) * 120 (seconds) = 12000 (reservations). Thus, the RE contexts table needs, as a minimum, 12000 entries (i.e., RTx request contexts entries). While the needed RAM amounts to: 12000 (entries) * 5000 (bytes) = 57.220459 MegaBytes. Note: The lifetime depends on the service the reservations are about. For example, for a Voice service, an average lifetime of 2 minutes, which could correspond to 2 minutes of voice communication being reserved, is typical. But for a Data service, an average lifetime of 30 minutes makes more sense. As a result, whenever you size a contexts table, you need to also take this variety of lifetimes into account.
Page 108 of 968
11 September 2009
4.2.5.
LiteSCE Tab
The Levels, Modules and Connectors tabs of CE configuration object work exactly as the Levels, Modules and Connectors tabs of the RE Configuration object.
Section 4.1.3, Levels, Modules and Connectors Tabs Parameter Description, on page 74, documents these latter tabs. See there if you would like to read some introductory material, or would like to understand what this section is about. What is said there applies to this section too.
4.2.5.1. Modules Sub-Tab
Figure 44 - CE Configuration GUI - Modules Subtab of LiteSCE Tab
Table 22 - CE Configuration - Modules Subtab of Lite SCE Tab - Parameter Values Parameter Module Name Description When the flag of a particular Module is checked, the Flexibility Points defined for it can be enabled, provided that the appropriate Connector and Level (or Object Class) are enabled too in the CE Configuration. Otherwise, the Flexibility Points defined for it will never be enabled, whatever the status of the Connector and Level (or Object Class) flags in the CE Configuration.
11 September 2009
Page 109 of 968
The following table lists the modules for which Flexibility Points can be enabled/disabled. Table 23 - CE Configuration - Modules Subtab of Lite SCE Tab - Modules Module None Event Receiver Identification Authorization Compute Percentage Precision Partitioning RE triggering Answer Post-Processing
4.2.5.2. Connectors Sub-Tab
Figure 45 - CE Configuration GUI - Connectors Subtab of Lite SCE Tab
Page 110 of 968
11 September 2009
Table 24 - CE Configuration - Connectors subtab - Parameter Values Parameter Connector Name Description When the flag of a particular Connector is checked, the Flexibility Points defined for it can be enabled, provided that the appropriate Module and Level (or Object Class) are enabled too in the CE Configuration. Otherwise, the Flexibility Points defined for it will never be enabled, whatever the status of the Module and Level (or Object Class) flags in the CE Configuration. The following table lists the connectors for which Flexibility Points can be enabled/disabled. Table 25 - CE Configuration - Connectors subtab - Connectors (Sheet 1 of 2) Connector Authorization flag Getppm Oneshot Estimate
Getppm2 Fstreq Nextreq Endcall Cancel Reset Credupdreq Generic Fraudupd Fee estimate Fee charge Account Update Account Update Arena Get and Check ppm Get Customer Get and Check Customer GEt Customer and Default Account Get and Check Customer and Default Account Direct Top-up
11 September 2009
Page 111 of 968
Table 25 - CE Configuration - Connectors subtab - Connectors (Sheet 2 of 2) Connector Customer Update Get ppm all Buckets
4.2.5.3. Level Sub-Tab
Figure 46 - CE Configuration GUI - Level Subtab of Lite SCE Tab
Table 26 - CE Configuration - Level subTab - Parameter Values Parameter Object Class Name Description When the flag of a given Object Class is checked, the Flexibility Points defined for any instance of it can be enabled, provided that the appropriate Connector and Module are enabled too in the CE Configuration. Otherwise, the Flexibility Points defined for any instance of it will never be enabled, whatever the status of the Connector and Module flags in the CE Configuration. The following table lists the object classes for which Flexibility Points can be enabled/disabled.
Page 112 of 968
11 September 2009
Table 27 - CE Configuration - - Level subtab - Object Classes Level Configuration
Service Retailer
4.2.6.
ARENA Tab
Figure 47 - CE Configuration GUI - ARENA Tab
Table 28 - CE Configuration - - ARENA Tab (Sheet 1 of 2) Parameter Logical Name Description Logical name of the ARENA attribute. This parameter is set in the ARENA object and is only available at display in the CE Configuration GUI. DB Name Database name of the ARENA attribute. This parameter is set in the ARENA object and is only available at display in the CE Configuration GUI.
11 September 2009
Page 113 of 968
Table 28 - CE Configuration - - ARENA Tab (Sheet 2 of 2) Parameter Type Description Data Type of the ARENA attribute. This parameter is set in the ARENA object and is only available at display in the CE Configuration GUI. Value Value of the ARENA attribute. This parameter receives a default value in the ARENA object. If you are logged in either as a Provider or as an Installer, you can use the CE Configuration GUI to give a new value to this parameter.
4.3.
Scheduling Engine (SE) Settings

For understanding the role of the Scheduling Engine, read Part IV., Scheduling Engine, on page 481.
4.3.1.
The SE Service Runs per SMF

The Scheduling Engine is implemented as a set of SE services providing each the same functionality, but on separate sets of data. The SE service runs as an OSP service. Moreover, it runs on each SMF that holds one or more Account partitions copies. See Account Partition, on page 26. On each of these SMFs, the SE service runs with its own service name. So this name is different from the other OSP services that your CRE platform runs, and different from the other SE services that your CRE platform runs. Normally, the service name of an SE service is the concatenation of ares- string with the name of the SMF running the SE service. In summary, each SMF holding one or more Account partitions copies runs a different SE service. Consequently, this manual assumes that your CRE platform runs one or more SE services, one per SMF on which the Scheduling Engine has been installed.
Page 114 of 968
11 September 2009
4.3.2.
Using the CRE Main Menu to Configure the SE Services
For each SE service that your CRE platform runs, the CREs main menu provides a top-level entry named like your SE service: ARES (for Advanced Rating Engine Scheduler). From that top-level menu, you can access the graphical interfaces allowing to configure a Scheduling Engine service. Follow the procedure described below. Step 1: Log in to the CRE GUI as Provider operator. Step 2: In the main menu, locate the SE services configuration entry: typically ARES.
The Main Menu, which you find in the Profile View of the Views panel.
Step 3: Double-click on the SE services configuration entry for expanding its contents. Under the ARES menu, two names are displayed: Configuration and Jobs. Configuration is the sub-menu that you use to configure the SE service. Double-click on it. As a result, the two following names get displayed: Configuration and Partition. These are two objects with a graphical interface, via which you will define the settings of your Scheduling Engine service.
11 September 2009
Page 115 of 968
Step 4: You will first configure the Scheduling Engine as a whole, via the Configuration object (see page 118). Double-click on Configuration in order to open the GUI.
Step 5: Once the global configuration of your Scheduling Engine is set up, you must specify the settings that are user type-dependent, i.e. scheduled events concerning Accounts or concerning Customers. You will do that via the Partition object (see page 129). Double-click on Partition configuration in order to open the GUI.
Page 116 of 968
11 September 2009
11 September 2009
Page 117 of 968
4.3.3.
SE Configuration Object
Within the Convergent Rating Engine, the Scheduling Engine is implemented via an independent OSP service. It interacts with the Community and Rating Engines in order to trigger them with scheduled events, not initiated by the user in real-time. Only one instance of the SE Configuration object must be created.
4.3.3.1. Object Purpose

The SE Configuration defines settings for the Scheduling Engine as a whole. The settings of the SE Configuration apply to all the user types (Customers or Accounts). In other words, the two SEPs of the SE service, which process two independent Scheduled Event Lists - one per user type: Accounts and Customers, rely on the same SE Configuration. Some settings may be differentiated per SEP: see 4.3.4, SE Partition Object, on page 129.
4.3.3.2. Services Tab Parameter Description
Figure 48 - SE Configuration GUI - Services tab
Table 29 - SE Configuration GUI - config- Services tab (Sheet 1 of 2) Parameter ARES SEP group*
essepg
Description Name of the SEP group of the current Scheduling Engine service, as automatically created during the Scheduling Engine installation. If you chose a SEP Group name different than the one created at installation, you must then create that SEP group and suitably configure it.
Page 118 of 968
11 September 2009
Table 29 - SE Configuration GUI - config- Services tab (Sheet 2 of 2) Parameter CE Service Name*
cename
Description Service Name of the Community Engine service that will process the Scheduled Events launched by the current Scheduling Engine. This parameter is usually set to ce20 (standard service name of the CE service). Use of this parameter The Scheduling Engine computes statistics about the CEs load. For computing those statistics, the Scheduling Engine needs to retrieve all the hosts involved in the processing of the scheduled events.
See parameter CE Load (%), page 138.

RE Service Name*
rename
Service name of the Rating Engine service that will process the Scheduled Events launched by the current Scheduling Engine. This parameter is usually set to creactor (standard service name of the RE service). Use of this parameter The Scheduling Engine computes statistics about the REs load. For computing those statistics, the Scheduling Engine needs to retrieve all the hosts involved in the processing of the scheduled events.
See parameter RE Load (%), page 138.
4.3.3.3. General Tab Parameter Description
Figure 49 - SE Configuration GUI - General tab
11 September 2009
Page 119 of 968
Table 30 - SE Configuration GUI - config- General tab (Sheet 1 of 3) Parameter Scheduler Timer (100 millisec)*
schutime
Description Time interval defining the rate at which a SEP of the current Scheduling Engine service, should send its packets of events. Unit: multiple of 100 milliseconds. When does the Scheduling Engine use this parameter? A SEP of the current SE service uses this parameter only if it is busy processing packets of events, i.e. when the Scheduled Event List is not empty. The Scheduler Timer specifies the pace at which the Scheduling Engine should check for a new packet of scheduled events to be processed. On the other hand, when the current SE service is in sleep mode (i.e. when the Scheduled Event List is empty), another time interval is taken into account: the Wait Timer. This timer specifies the pace at which the Scheduling Engine must wake up for checking if some new packets of events have to be processed. See parameter Wait Timer, page 121. Why should? The SEP of the Scheduling Engine processes the packets of events one at a time. So before handling a new packet of events, it checks whether the processing of the current packet of events is completed. The SEP processes no new packet until the current packets processing is done. This explains why the Scheduler Timer is the rate at which the SEP should send its packets: if the processing of a packet takes more time than the value of the Scheduler Timer, then the packets will actually be sent at a lower rate than the one specified here. Choosing the value of the Scheduler TImer You should set the Scheduler Timer to a value greater or equal to the time the CRE takes to process a packet of events. In general, a value between 2 (i.e., 200 milliseconds) and 3 (i.e., 300 milliseconds) could be a reasonable choice, for packets of maximum 100 scheduled events.
Page 120 of 968
11 September 2009
Table 30 - SE Configuration GUI - config- General tab (Sheet 2 of 3) Parameter Wait Timer
waittime
Description Time interval defining the rate at which a SEP of the current Scheduling Engine service, when it is in sleep mode, must check if some new packets of events of the Scheduled Event List has to be processed. This parameter is also called sleeping period. Unit: minutes. When does the Scheduling Engine use this parameter? A SEP of the current SE service uses this parameter only if it is in sleep mode, which it is switched to when the Scheduled Event List is empty. The Scheduler Timer specifies the pace at which the Scheduling Engine must wake up for checking if some new packets of events have to be processed. On the other hand, when the current SE service is busy processing the Scheduled Event List (which is hence not empty), another time interval is taken into account: the Scheduler Timer. This timer specifies the pace at which the Scheduling Engine should check for a new packet of scheduled events have to be processed. See parameter Scheduler Timer (100 millisec)*, page 120.
Delay Before Insert Fee (min)

delay
Not used.
Max of Empty Loops

max_empt
Number of consecutive empty hour slices after which a SEP of the current Scheduling Engine service directly jumps to the next non-empty hour slice, i.e. skips the processing of the remaining empty hour slices.
About hour slices, see 13.3.2, Time Progression: Hourly Granularity, on page 488.
Why would the Scheduling Engine skip empty hour slices? The processing of an empty hour slice takes a fixed amount of time and there is no way to speed it up. Indeed, the processing time of an empty hour slice always takes a time equal to: Scheduler Timer x 4 because there are 4 levels of priority among the Scheduled Events. Therefore, when there is absolutely a need to speed up the processing of an empty hour slice, there is no other choice than skipping that processing. Functionally, it doesnt make any difference: there is no scheduled event to launch anyway. Why not ALWAYS skipping empty hour slices? When there is only a few consecutive empty hour slices, there is no real need to speed up their processing: the incurred overhead is negligible. However, when dealing with a large number of consecutive empty hour slices, processing all of them may take a too long time. As a result, some scheduled events could be launched too late, preventing the CRE to process them in due time.
11 September 2009
Page 121 of 968
Table 30 - SE Configuration GUI - config- General tab (Sheet 3 of 3) Parameter Validity of Late Fees (days)
nbvalday
Description Maximum age of a Scheduled Event. Scheduled Events older than this wont be launched anymore by the Scheduling Engine; they will simply be disregarded. Unit: day. How to calculate the age of a Scheduled Event? The age of a Scheduled Event is equal to NOW - date of the next scheduled occurrence of the event
See parameter Next Fee Date, page 312.

Example For instance, today is 30 September 2006 and the Validity is set to 21 days. Consider an event scheduled for 6 September 2006; it is still in the Scheduled Event List because the corresponding Subscription was suspended. If the Subscription is reactivated today 30 September 2006, the scheduled event wont be processed by the Scheduling Engine, because it is too old. Indeed: 30 September 2006 - 6 September 2006 = 24 days whereas the Validity is limited to 21 days.
4.3.3.4. CRE Load Thresholds Tab Parameter Description
Figure 50 - SE Configuration GUI - CRE Load Thresholds Tab
Page 122 of 968
11 September 2009
Table 31 - SE Configuration GUI - config- CRE Load Thresholds Tab Parameter Min. CPU Threshold*
cpumid
Description Minimum CRE CPU load. When the CREs CPU load is below this value, the Scheduling Engines SEP extends the size of the next packet of events that it will send to the CRE.
Read Determining the Size of the Packets: Rule, on page 124.

Unit: percent. This parameter must be strictly greater than 10. Max. CPU Threshold*
cpustop
Maximum CRE CPU load. When the CREs CPU load is above this value, the Scheduling Engines SEP reduces the size of the next packet of events that it will send to the CRE.
Read Determining the Size of the Packets: Rule, on page 124.

Unit: percent. This parameter must be strictly greater than 50. Refresh Period (min)
Time interval defining the rate at which a SEP of the current Scheduling Engine service recomputes (refreshes) its time-based statistics, i.e. the CRE CPU load the number of events processed in the last second (see page 139). Unit: minutes.
refresht
Read 4.3.3.4.1, Computing the CRE CPU Load, on page 123. 4.3.3.4.1. Computing the CRE CPU Load
The Scheduling Engine SEP regularly computes the CRE CPU load. Based on this information, the Scheduling Engine adapts the flow of the scheduled events sent to the CRE. The goal is to optimize the performances of the CRE, without overloading it. See below Determining the Size of the Packets: Rule.
11 September 2009
Page 123 of 968
For computing the CRE CPU load, the Scheduling Engine SEP takes the maximum of the CE load and the RE load of the corresponding Partition.
CRE load CE
%
load
load
RE
%
4.3.3.4.2. Determining the Size of the Packets: Rule

About the packets of scheduled events, see 13.3.2, Time Progression: Hourly Granularity, on page 488.
The CRE CPU load must always be kept between the Minimum and the Maximum thresholds. In order to optimize the performance, the size of the packets of scheduled events sent to the CRE by the Scheduling Engine is constantly adapted, per SEP, in function of the current CRE CPU load. This rule is applicable individually for each SEP of the Scheduling Engine. As a result, the size of the packets may vary from one SEP to another. So as long as the CRE CPU load is above the Maximum threshold, the size of the next packet to be sent by the Scheduling Engine is decreased by 10%. Conversely, if the CRE CPU load is beyond the Minimum threshold, the size of the next packet to be sent by the Scheduling Engine is increased by 10%. When the CRE CPU load is between the Minimum and the Maximum thresholds, the size of the packets doesnt change. This rule can be formalized as follows: IF CRE CPU load <= Min CPU threshold THEN next packet size = current packet size + 10% IF CRE CPU load >= Max CPU threshold ELSE next packet size = current packet size - 10%
Page 124 of 968
11 September 2009
Min CPU threshold
Max CPU threshold
CRE CPU threshold (%) 60 70 80
10
20
30
40
50
Limit of the min
Limit of the max
Current CRE CPU load (%) Next packet size = current packet size - 10%
Next packet size = current packet size + 10%
Next packet size wont change
Additional limitation on the packets size

Increasing the size of the packets by 10% can only be done until it doesnt exceed the maximum size of the packet. Indeed, the maximum number of events embedded in a packet is set per Scheduling Engine partition. See parameter Max. # Events Processed*, page 137. As soon as one of these 2 maximum values is reached, the packet size mustnt be increased anymore.

See also 4.3.3.4.1, Computing the CRE CPU Load, on page 123.
4.3.3.5. Errors Handling Tab Parameter description

The parameters of the Errors Handling tab are related to the Error Management facility of the Scheduling Engine. Read 13.6, Error Management, on page 494.
Figure 51 - SE Configuration GUI - Errors Handling Tab
11 September 2009
Page 125 of 968
Table 32 - SE Configuration GUI - config - Errors Handling Tab (Sheet 1 of 3) Parameter Max # of retries in case of communication problem
nbretry
Description Maximum number of times that a given failed Scheduled Event can be relaunched by the Scheduling Engine towards the Community Engine. If a Scheduled Events processing fails because of a communication problem on the DPE bus between the Scheduling Engine and the Community Engine, the Scheduling Engine is normally warned via the CREs response. Moreover, if the Scheduling Engine doesnt receive any response, it assumes that a communication problem occurred. In these two cases, the Scheduling Engine will re-launch the Scheduled Event towards the Community Engine, so that it re-attempts to successfully process the event. This retry mechanism is applied two limitations: a maximum number of occurrences (specified here) a timer defining the minimal time interval between two occurrences (see parameter Error Retry Timer, page 128). What happens when this threshold is exceeded? When the failed event has been retried the maximum number of times, without being successfully processed, the Scheduling Engine may adopt one of the following two behaviors, depending on the type of problem actually encountered: either the Scheduled Event is set to the Error mode, which concretely blocks it (in case of Wait and Retry error, see page 499); or the Partition corresponding to the current packet of scheduled events is set to Status Error (in case of Switch and Retry error, see page 500). Reset of the Counter The counter that is compared to this threshold value is an internal counter of the CRE logic. It is reset for each new Scheduled Event processed.
Page 126 of 968
11 September 2009
Table 32 - SE Configuration GUI - config - Errors Handling Tab (Sheet 2 of 3) Parameter Max # of kills per refresh before stop host
errnbret
Description Maximum number of times that the Scheduling Engine may receive responses indicating kill captures from the Community and Rating Engines, during a given Refresh Period (see parameter Refresh Period (min), page 123). Whats a kill? A kill is an abrupt process termination, due to an unexpected severe error in the execution of the CRE logic. The type of error provoking a kill is not datarelated, so not due to the way the CRE is configured. When a kill occurs, a kill capture process is started in the CRE, so that the RTx (or any requesting entity, like here the Scheduling Engine) is informed that the processing failed. See also Kill capture, page 500. What happens when this threshold is exceeded? When the CRE encounters, within one refresh period, a number of kills greater than the maximum specified here, the Partition corresponding to the current packet of scheduled events is set to the Error Status. Moreover, the SEP sends an alarm. Reset of the Counter The counter that is compared to this threshold value is an internal counter of the CRE logic. It is reset at each Refresh of the Scheduling Engine. See also parameter Refresh Period (min), page 123.
11 September 2009
Page 127 of 968
Table 32 - SE Configuration GUI - config - Errors Handling Tab (Sheet 3 of 3) Parameter Max # of errors per slice before stop host
maxerr
Description Maximum number of times that the Scheduling Engine may receive error responses of type NOK data or NOK service from the Community and Rating Engines, for the scheduled events of a given packet.
A packet is, within a slice of one hour, a set of up to 10 scheduled events processed in group by the Scheduling Engine. See 13.3.2, Time Progression: Hourly Granularity, on page 488.)
What is a NOK data or NOK service error? A NOK data error is due to a defect in the CREs configuration, in the definition of the user (Account or Customer). For instance, when the CRE cannot identify any Account for the triggered Customer. A NOK service error is due to a defect in the CREs configuration, in the Product Catalog. For instance, when the CRE cannot identify a Service Offer complying with the triggered Service in the portfolio of the user. In both cases, the CRE is unable to perform the complete logic through the Community and Rating Engines, so the event is aborted. What happens when this threshold is exceeded? When the SEP must abort more events than the maximum specified here, because of errors of type NOK data or NOK service, the Partition corresponding to the current packet of scheduled events is set to the Error Status. Moreover, the SEP sends an alarm. Reset of the Counter The counter that is compared to this threshold value is reset is an internal counter of the CRE logic. It is reset at each new packet of scheduled events processed by the Scheduling Engine. Error Retry Timer
errtimer
Time interval (in minutes) between two launches of the same event by the Scheduling Engine towards the Community Engine. If a Scheduled Events processing fails because of a communication problem on the DPE bus between the Scheduling Engine and the Community Engine, the Scheduling Engine is warned via the CREs response and potentially by an alarm. The Scheduling Engine will then re-launch the Scheduled Event towards the Community Engine, so that it re-attempts to successfully process the event. This retry mechanism is applied two limitations: a maximum number of occurrences (see parameter Max # of retries in case of communication problem, page 126) a timer defining the minimal time interval between two occurrences (specified here).
Page 128 of 968
11 September 2009
4.3.4.
SE Partition Object

The Partition object is used to configure each SEP of the Scheduling Engine service. The Scheduling Engine service is implemented by up to two SEPs. A SEP is dedicated to one type of users: Customers or Accounts. Each SEP processes then an independent Scheduled Event List, containing either the Scheduled Customer Events or the Scheduled Account Events.
4.3.4.2. How many Partitions do I have to create?

Per Scheduling Engine service, you may create up to two instances of the Partition object. If you create two instances, make sure that each of them specifies a different user type: one for the Accounts and the other one for the Customers. If you need the Scheduling Engines functionalities for only one type of users, then you will create only one Partition, for the Accounts or for the Customers. If you need none of the functionalities of the Scheduling Engine, then you may create no Partition instance.
4.3.4.3. Partition Name Parameter Description

Figure 52 - SE Partition GUI - Partition Name Parameter
Table 33 - SE Partition GUI - crepart Parameter Partition Name*

partnm
Description Name of the current Partition. Tip It is a good practice to give a meaningful naming to the Partition by, for instance, relating it to its User Type. You could then name your Partition Accounts or Customers.
See parameter User Type*, page 132.
11 September 2009
Page 129 of 968
4.3.4.4. General Tab Parameter Description
Figure 53 - SE Partition GUI - General Tab
Page 130 of 968
11 September 2009
Table 34 - SE Partition GUI - crepart - General Tab (Sheet 1 of 2) Parameter Status*

lstatus
Description Status of the current Scheduling Engine SEP. Whatever its Status, the current SEP is up and running. Simply, when it is not in the Active Status, the SEP no longer does useful job. There are 3 possible Statuses: Active The SEP processes the Scheduled Event List. So the SEP is either busy The Scheduled Event List is not empty, so the SEP retrieves scheduled events, ranks them by priority, builds packets and sends these packets to the Community Engine. or sleeping The Scheduled Event List is empty and the SEP regularly awakes for checking it. Only an operator can set the Partition to the Active Status. Suspended
The SEP doesnt process the Scheduled Event List. Its scheduling functionality is disabled. However, it is still possible to send events to the Community Engine by manually launching them, via the Scheduled Event GUIs in the ARES. See complete procedure in How to manually launch a Scheduled Event, on page 132. Only an operator can set the Partition to the Suspended Status. Error The SEP doesnt process the Scheduled Event List. There is no possibility to send any event until an operator cancels the Partitions Error Status and sets it back to the Active Status.
The Error Status is automatically set when some error thresholds are exceeded, like the Max # of errors per slice before stop host (see page 128). For more info, read 13.6, Error Management, on page 494.
Only the SEP can set the Partition to the Error Status. Only an operator can switch the Partitions Status from Error to another Status.
11 September 2009
Page 131 of 968
Table 34 - SE Partition GUI - crepart - General Tab (Sheet 2 of 2) Parameter User Type*
type
Description Type of CRE user concerned by the Scheduled Events sent by the current SEP to the Community Engine. This parameter can have two values: Account The Scheduled Events sent by the current SEP concern Accounts (so they are Scheduled Account Events, see page 313). In other words, these Scheduled Events are defined in a Service Offer Group to which an Account subscribed. Such an Account is thus considered as a stand-alone user, and is not related to a Customer. In such a case, the Community Engine acts as a gateway to the Rating Engine. Customer The Scheduled Events sent by the current SEP concern Customers (so they are Scheduled Customer Events, see page 307). In other words, these Scheduled Events are defined in a Service Offer Group to which a Customer subscribed. Such an Customer must then be linked to an Account.
Date of Last Executed Fee

okbilldt
Read-only.
Additional SQL Constraint

sqlcond
Not used.
4.3.4.4.1. How to manually launch a Scheduled Event

When a scheduled event is not automatically launched by the Scheduling Engine, for instance because the Partition is in the Suspended status, it is still possible to manually send the event to the Community Engine. Therefore, you have to perform the steps described below.
Page 132 of 968
11 September 2009
Step 1: At the SMP, go to the ARES menu. Under that menu, you have two choices: Configuration and Jobs. Double-click on Jobs. The two following choices then appear: Scheduled Account Event and Scheduled Customer Event.
Step 2: The two GUIs from the Jobs menu are actually views on the objects Scheduled Account Event (accfee) and Scheduled Customer Event (cltfee).
is a view on (so indicates the row ID of the actual value of)
Since it is only a view on the actual object instances in the database, the Scheduled Event GUI from the Jobs menu does not enable the same commands. You cannot create, modify or remove any scheduled event from the ARES GUIs.
11 September 2009
Page 133 of 968
Step 3: On the other hand, the ARES GUIs offer a specific command for launching events, without having the actual scheduler functionality processing them. Indeed, by clicking on the EXECUTE command, you send the current Scheduled Event to the Community Engine.
4.3.4.5. Service Tab Parameter Description

Figure 54 - SE Partition GUI - Service Tab
Table 35 - SE Partition GUI - crepart - Service Tab (Sheet 1 of 2) Parameter SMF*

smf
Description Name of the SMF running the current Scheduling Engine service.
SEP Name*
sepnm
Name of the SEP, of the current SE service, configured by the current Partition instance.
Page 134 of 968
11 September 2009
Table 35 - SE Partition GUI - crepart - Service Tab (Sheet 2 of 2) Parameter Active Host ID
achost
Description ID of the host running the current SE service. This parameter is automatically filled in.
4.3.4.6. SEP Groups Tab Parameter Description
Figure 55 - SE Partition GUI - SEP Groups Tab
Table 36 - SE Partition GUI - crepart - SEP Groups Tab (Sheet 1 of 2) Parameter Active CE SEP Group*
acesgnm
Description SEP Group name of the Community Engine to which the current Scheduling Engine SEP normally sends its scheduled events. This is the Community Engine used at startup. All SEPs in the SEP Group must run on the same host. Active / Stand-By Switch If a Scheduled Event sent to the Active CE returns a DPE error, the Scheduled Event will be sent again, but to the Stand-By CE. This SEP Group switch is done only once per event in error. See error of type Switch and Retry (page 500). Once the Stand-By CE is used, the Scheduling Engine keeps sending the scheduled events to it until an error occurs. Then a switch back to the Active CE is performed.
11 September 2009
Page 135 of 968
Table 36 - SE Partition GUI - crepart - SEP Groups Tab (Sheet 2 of 2) Parameter Active
cesgflg
Description Indicates whether the Active CE is the Community Engine to which the Scheduling Engine SEP currently sends the scheduled events. The rule is as follows: IF this flag is checked, the current SEP sends its scheduled events to the Active CE. ELSE it does not issue them to the Active CE, but to the Stand-by CE. This flag is automatically updated by the current SEP, and only by it.
Stand-By CE SEP Group

scesgnm
SEP Group name of the Community Engine acting as a back-up of the Active CE. All SEPs in the SEP Group must run on the same host. Active / Stand-By Switch If a Scheduled Event sent to the Stand-By CE returns a DPE error, the Scheduled Event will be sent again, but to the Active CE. This SEP Group switch is done only once per event in error. See error of type Switch and Retry (page 500). Once the Active CE is used, the Scheduling Engine keeps sending the scheduled events to it until an error occurs. Then a switch back to the Stand-By CE is performed.
Stand-By
cesgflg
IF this flag is checked, the current SEP sends its scheduled events to the Stand-By CE. ELSE it does not issue them to the Stand-by CE, but to the Active CE. This flag is automatically updated by the current SEP, and only by it.
4.3.4.7. Thresholds Tab Parameter Description
Figure 56 - SE Partition GUI - Thresholds Tab
Page 136 of 968
11 September 2009
Indicates whether the Stand-By CE is the Community Engine to which the Scheduling Engine SEP currently sends the scheduled events. The rule is as follows:
Table 37 - SE Partition GUI - crepart- Thresholds Tab Parameter Max. # Events Processed*
maxtup
Description Maximum size of the packets of scheduled events sent by the current SEP to the Community Engine. In other terms, this is the maximum number of events that the current SEP is allowed to process in parallel. Maximum value: 250. Use of this parameter The Scheduling Engine Configuration specifies for the CRE a Maximum CPU Threshold. When that maximum CPU load is reached, the size of the packets is automatically reduced, in order not to overload the CRE. So the size of the packets stops increasing as soon as one of both maximums is reached: either the Maximum # of Events Processed, or the Maximum CPU Threshold (see page 123). As a result, the packets will maybe never reach the value of this parameter.
See 4.3.3.4.2, Determining the Size of the Packets: Rule, on page 124.
Processing Timeout (100 ms)
Time interval after which the current Scheduling Engine SEP considers that the last event sent to the Community Engine has timed out. Unit: multiple of 100 milliseconds. In other words, if the Scheduling Engine doesnt receive a response from the Community Engine within that time frame, the Scheduling Engine assumes that an error of type Communication Problem occurred. The appropriate retry mechanism is then executed by the Scheduling Engine. See parameter Max # of retries in case of communication problem, page 126.
ptimeout
4.3.4.8. Statistics Tab Parameter Description
Figure 57 - SE Partition GUI - Statistics Tab
11 September 2009
Page 137 of 968
Table 38 - SE Partition GUI - crepart - Statistics Tab (Sheet 1 of 2) Parameter CE Load (%)
ceload
Description CPU load of the Community Engine, on the SEP Group currently used (Active or Stand-by). This value is computed by the Scheduling Engine SEP at regular intervals. See parameter Refresh Period (min), page 123. Unit: percents. Why computing the CE CPU load? This parameter is used by the Scheduling Engine for computing the global CRE CPU load. See Computing the CRE CPU Load, on page 123. If CE Load = 0 (zero) When the CE and the RE are run on the same host, the CE Load is set to zero.
RE Load (%)
reload
Maximum CPU load of the Rating Engine (*). This value is computed by the Scheduling Engine SEP at regular intervals. See parameter Refresh Period (min), page 123.
(*) More accurately: Maximum CPU load of the hosts running a SLEE that has active RE partitions installed on the SMF running the current SE service. Partition 0 is not an Account partition. To know which Account partitions are present in your CRE installation, see Account Partition, on page 26.
Unit: percents. Why computing the CE CPU load? This parameter is used by the Scheduling Engine for computing the global CRE CPU load. See Computing the CRE CPU Load, on page 123. How is the RE Load computed? IF The current SE service runs on MySMF SMF, and RE Account partitions 2, 3, 4 and 5 are installed on MySMF, and No other RE Account partitions are installed on MySMF, and SLEE1 holds RE partitions 2, 4, and SLEE2 holds RE partition 3, and SLEE3 holds RE partition 5, and All these partitions are active RE partitions. THEN the RE Load is computed as follows: Max (CPUloadHostOfSLEE1, CPUloadHostOfSLEE2, CPUloadHostOfSLEE3)
Page 138 of 968
11 September 2009
Table 38 - SE Partition GUI - crepart - Statistics Tab (Sheet 2 of 2) Parameter Last # Events / Sec
lstnbs
Description Number of events sent to the Community Engine by the current Scheduling Engine SEP during the last second. This value is computed by the Scheduling Engine SEP at regular intervals. See parameter Refresh Period (min), page 123. Size of the last packet sent by the current Scheduling Engine SEP. Unit: number of scheduled events embedded in the packet.
Last # Events / Slot

nbevt
4.4.
4.4.1.
Service Retailer Object

Object Purpose
The Convergent Rating Engine implements the notion of Service Retailer. A Service Retailer owns a set of Customers and Accounts and manages his own Product Catalog, applicable to those Customers and Accounts only. All Customers, Accounts, and Product Catalog items belong to a Service Retailer.
Among the various Service Retailers active on a Convergent Rating Engine platform, one is typically the actual Network Operator (aka main Service Retailer), opening and renting his platform to other Service Retailers in the context of a Revenue Sharing scheme. Each Service Retailer has management rights on a restricted set of objects. This set of objects allows the Service Retailer to customize his global offer for his own Customers and Accounts only. This access restriction ensures the confidentiality of the Service Retailers data, offering a reliable framework for implementing MVNOs (Multiple Virtual Network Operators).
4.4.2.
Parameter Description
Figure 58 - Service Retailer GUI
11 September 2009
Page 139 of 968
Table 39 - Service Retailer - servret (Sheet 1 of 2) Parameter Service Retailer Name*

name
Description If you are creating a new Service Retailer instance, enter here the name of the Service Retailer you are wanting to create. If you are wanting to use an existing Service Retailer instance, click on the button to the right of the entry field and then choose a Service Retailer Name from the list that is then displayed. Choosing a Value for this Parameter When Provider Group* parameter of the current instance of Service Retailer object is set to sdpprov, Service Retailer Name* parameter of the current instance may contain any name. Otherwise, Provider Group* parameter and Service Retailer Name* parameter of the current instance must have the same value and must thus specify the same name.
See also chapter 3., OSP Level Setup, on page 53, which you are recommended to
read carefully.
Creating a New Service Retailer To learn more on creating a Service Retailer, choosing its Service Retailer Name and setting up the necessary operators for it, you are recommended to fully read chapter 3., "OSP Level Setup", on page 53. The chapter not only explains how you create a Service Retailer and how you need to choose its name but also explains how you set up operators for a given Service Retailer. Service Retailer ID
custid
Internal row ID of the current Service Retailer.

The operator cannot set this value; thats why the field is inactive and only visible at display.
Page 140 of 968
11 September 2009
Table 39 - Service Retailer - servret (Sheet 2 of 2) Parameter Provider Group* Description Name of the group to which the Service Retailer belongs.
A group is an instance of OPERATOR GROUP object of PFMACCESS. The name of a group is given by Group Name parameter of the instance.
When this parameter is not set to sdpprov, both this parameter and Service Retailer Name* parameter must have the same value. That is, when a Service Retailer does not belong to sdpprov group, the name of the Service Retailer must match the name of the group to which the Service Retailer belongs.
Make sure that there exists a provider operator that belongs to the group that this parameter specifies.
provider operator for a given Service Retailer, see chapter 3., OSP Level Setup, on page 53.
To learn more on how you set up a Service Retailer and on how you set up a
Confidentiality of Service Retailers Data The CRE protects the confidentiality of the data of the Service Retailers it hosts and therefore supports MVNO.
Section 3.3, CRE Objects Access Rule, on page 57, explains how the confidentiality
of these data is achieved.
Subscriber Group
Not used.
11 September 2009
Page 141 of 968
Figure 59 - Service Retailer GUI - General tab
Table 40 - Service Retailer - General Tab Parameter Default Service Retailer

servret
Description Reference to the Service Retailer owning the default zoning settings of the current Service Retailer.
For more information about the role of the Default Service Retailer in the Zoning
Parameters Identification, please see section 16.6.1, "Default Service Retailer", on page 579.
Default Matrix Component

chgdef
Reference to the Matrix Component to be set as default when no Matrix Component can be identified in the Area Matrix of the current or of the default Service Retailer.
For more information about the role of the Default Matrix Component in the Zoning
Parameters Identification process, please see section 16.6.2, "Zoning Parameters Identification Logic", on page 580.
Min. Nb of Matching Characters*

chgmin
The minimum number of matching characters is a setting of the Match Algorithms 3 and 5 for the identification of the Area matching the origin or the destination of an event.
For more information about the role of the Minimum and Maximum in the Area
Identification process, please see section 16.6.3, "Area Identification Match Algorithms", on page 583.
Page 142 of 968
11 September 2009
Table 40 - Service Retailer - General Tab Parameter Max. Nb of Matching Characters*

chgmax
Description The maximum number of matching characters is a setting of the Match Algorithms 3 and 5 for the identification of the Area matching the origin or the destination of an event.
For more information about the role of the Minimum and Maximum in the Area
Identification process, please see section 16.6.3, "Area Identification Match Algorithms", on page 583.
Address
address
Administrative address of the current Service Retailer.
Activity Top-Up Algorithm*
Activity Top-Up/Reaload Algorithm that applies upon use of a Top-Up Profile that specifies no Activity Top-Up/Reload Algorithm. When Does this Parameter Apply? There are two ways for a Top-Up RTx request to specify the Top-Up Profile that governs the Top-Up it is requesting: Either the RTx request indicates which instance of TOP-UP PROFILE object has to be applied (by suitably filling in profId parameter of the Top-Up RTx request, which identifies the instance of TOP-UP PROFILE object to apply).
This parameter never applies to such a Top-Up RTx Request, since any instance of TOP-UP PROFILE object always specifies its own Activity Top-Up Algorithm (by means of its Activity Reload Algorithm parameter, which is always filled in with some meaningful value). Or the RTx request carries its own Top-Up Profiles data, which will exclusively govern the requested Top-Up. This parameter applies to such a Top-Up RTx Request if, and only if, the TopUp Profiles data the request carries do not specify any Activity Top-Up/ Reload Algorithm. Else the Activity Top-Up/Reload Algorithm that applies is the one that the Top-Up RTx Request specifies. Understanding this Parameter This parameter must be set to one of the following values: Cumulative Maximum This parameter works exactly as parameter Activity Reload Algorithm*, page 815, which is one of the parameters of TOP-UP PROFILE object. See there to understand what the above values mean.
11 September 2009
Page 143 of 968
Table 40 - Service Retailer - General Tab Parameter Allow Tariff Switch*

notarrws
Description
When this flag is checked,

Tariff switching is enabled for the current service retailer.
When this flag is not checked,

Tariff switching is not enabled for the current service retailer.
Section 12.3.1.5, Switching of Tariff, of Customer Account, of Service Offer, of

Service, on page 382, introduces tariff switching.
Postpaid Discount Mode

disc_mod
This parameter has only meaning when several instances of Discount object: Apply to the same Account and Use the same counter of the Account as their application perimeter.
Thus, this parameter never applies to Discount Object instances that use the Accounts main balance as their application perimeter.
You choose one of the following values to indicate how the discounts calculated on the Accounts counter then cumulate: Bundled
The discount amount is not deduced from the counter each time the discount is calculated. Tiered The discount amount is deduced from the counter each time the discount is calculated. Example Assume that a counter of a given Account indicates an amount of 20 Euros. Assume also that two instances of Discount object are associated with that Account and are using that counter as their application perimeter. Assume also that the first instance of Discount object applies a 15% discount on the counter, and that the second instance of the Discount object applies a 10% discount on the counter. With this parameter set to Bundled, the cumulated discount equals (20*15%) + (20*10%) = 3 + 2 = 5. That is, the main balance of the Account then receives 5 EUROs. With this parameter set to Tiered, the cumulated discount equals (20*15%) + ((17)*10%) = 3 + 1.7 = 4.7. That is, the main balance of the Account then receives 4.7 EUROs.

Account Interrogation
crditacs
This parameter is only used by Discount object.
Access Code dialled free of charge by the Customers of the current Service Retailer, for Account credit interrogation.
Help Desk
helpdesk
Access Code dialled free of charge by the Customers of the current Service Retailer for accessing his Help Desk.
Page 144 of 968
11 September 2009
Table 40 - Service Retailer - General Tab Parameter Account Management

mngmtacs
Description Access Code dialled free of charge by the Customers of the current Service Retailer for performing Account management operations.
Top-Up
scratacs
Access Code dialled free of charge by the Customers of the current Service Retailer for Top-up. Number of decimals taken into account in the amounts (i.e., money values) stored in the Service Retailer database of Accounts.
Decimal Precision*
currency
See also parameter Computing Precision*, page 146. See also parameter Rounding Method*, page 147.
No Rounding Is Done Whenever an Operator Enters a Decimal Value Whenever an operator enters into some GUI parameter (e.g., into an Accounts Main Balance parameter) a decimal value that has more fractional digits than Decimal Precision* parameter value, the CRE does no rounding. Simply, at time it stores the decimal value into its database, the CRE drops the fractional digits in excess.
For example, if an operator enters 1234.5678 into an Accounts Main Balance parameter, and Decimal Precision* parameter for the Service Retailer of the Account is set to 2, the CRE stores 1234.56 into its database at time CREATE/MODIFY button of the Accounts GUI is clicked on. Understanding Decimal and Computing Precision The precision that the CRE uses to do its calculations is equal to Computing Precision value. However, at time it has to store a calculation result into the database of Accounts, the CRE first converts the computed value to one that has Decimal Precision decimals, and afterwards stores the result of the conversion into the database. For example, if Computing Precision is set to 5 and Decimal Precision is set to 2, the CRE does all its calculations with 5 decimals. At time it stores a calculation result into the database of Accounts, it converts the 5 decimals value to one with 2 decimals, and afterwards stores the 2 decimals value into the database. When it converts from Computing Precision decimals to Decimal Precision decimals, the CRE performs some rounding. The rounding method the CRE then uses is the one that Rounding Method parameter indicates.
See also section , "What Is Delta?", on page 146.

Constraints The following constraint applies on Decimal Precision value: The Decimal Precision must be strictly less than 9.
11 September 2009
Page 145 of 968
Table 40 - Service Retailer - General Tab Parameter Computing Precision*

cprec
Description Number of decimals taken into account internally by the Rating Engine to do money values calculations in the rating and charging processes. By increasing the computing precision, the impact of the small imprecisions (in tax calculation, reserve and commit processes,...) can be limited as much as possible.
See also section , "Understanding Decimal and Computing Precision", on page 145. See also parameter Decimal Precision*, page 145. See also parameter Rounding Method*, page 147.
Constraints The following constraints apply on Computing Precision value: The Computing Precision must be strictly less than 18. The Computing Precision must be greater or equal to the Decimal Precision. Computing Precision minus Decimal precision must be strictly less than 10. What Is Delta? Document ALCATEL 8618 Convergent Rating Engine 2.0 South API Specification, 3BL 45180 DAAA PBZZA, Edition 01 or Higher, which documents the CRE South API, uses the term delta precision. What is that delta? Internally, when it does its calculations, the CRE uses the Decimal Precision and a so-called internal delta. Thats the delta the South API talks about. That delta always equals Computing Precision minus Decimal Precision. Thus, when you choose a value for Computing Precision, the CRE deduces from it the delta it will apply. As a result, given the above constraints, the maximum value of delta is 9.
Page 146 of 968
11 September 2009
Table 40 - Service Retailer - General Tab Parameter Rounding Method*

rounding
Description Rounding method to be applied in all the rating operations performed by the Rating Engine for the current Service Retailer.
Pay attention to that fact that this parameter specifies the rounding method for the rating operations only. Be fully aware of the consequences. For example, whenever an operator enters a decimal value into a parameter (e.g., into an Accounts main balance) that has more fractional digits than Decimal Precision* parameter value, the rounding method this parameter specifies does not apply.
the CRE simply drops the fractional digits in excess at time it stores the decimal value into its database. The Rounding operation occurs when reducing the amount used for calculation (with the Computing Precision) to the amount to be stored in the database (with the Decimal Precision): some digits after the decimal point are removed, and the last that is kept is determined according to one of the following three methods: Floor (Lower rounding): The values are rounded to the lower unit. - 2.3 is rounded to 2.0 - 7.89 is rounded to 7.8 Nearest: The values are rounded to the nearest unit. - 2.3 is rounded to 2.0 - 7.89 is rounded to 7.9 Ceil (Upper rounding): The values are rounded to the upper unit. - 2.3 is rounded to 3.0 - 7.89 is rounded to 7.9
See also section , "Understanding Decimal and Computing Precision", on page 145. See also parameter Decimal Precision*, page 145. See also parameter Computing Precision*, page 146.
Minimum Granted Unit
mgu
Minimum unit stored in the database, after rounding. Concretely, this setting applies when the rounded amount equals 0 (zero), which can happen with Rounding Methods Nearest and Floor. In order to avoid having very small costs rounded to zero, it is possible to define sort of a minimal cost to be taken into account. Example The internal computation value 0.3 would become 0 when stored in the database, after applying the Floor rounding method. If the Service Retailer doesnt want that event to be actually free for the user, he can set the Minimum Granted Unit to 25, which will then be the value stored in the database. And computation as per "Decimal Precision" will be done, i.e., if decimal precision is 2, it will be considered as 0.25..
11 September 2009
Page 147 of 968
Figure 60 - Service Retailer GUI - ARENA Tab
Table 41 - Service Retailer - ARENA Tab Parameter Logical Name Description Logical name of the ARENA attribute. This parameter is set in the ARENA object and is only available at display in the Service Retailer GUI. DB Name Database name of the ARENA attribute. This parameter is set in the ARENA object and is only available at display in the Service Retailer GUI. Type Data Type of the ARENA attribute. This parameter is set in the ARENA object and is only available at display in the Service Retailer GUI. Value Value of the ARENA attribute for the current service retailer. This parameter receives a default value in the ARENA object.
Page 148 of 968
11 September 2009
Figure 61 - Service Retailer - Flexibility Tab
Table 42 - Service Retailer - Flexibility Tab Parameter LiteSCE Pool Description Reference to the LiteSCE Pool containing the scripts available to the Generic Connector, at Service Retailer level.
See also section 26.5, LiteSCE Script Pool Object, on page 879.
To indicate that a Service Retailer has no LiteSCE pool, leave this entry field empty.
4.5.
4.5.1.
Language Object
Object Purpose
The Language is a parameter of the Account, which the default value of is provided by the Account Profile. It ensures that the Customer is addressed in the appropriate language, among others when receiving notifications.
11 September 2009
Page 149 of 968
4.5.2.
Figure 62 - Language GUI
Table 43 - Language - sdplang Parameter Language Name*

mn30
Description Name of the current Language.
Language ID*
langid
Internal ID of the current Language. The operator sets this value when creating a new language instance. Language IDs can range from 1 to 10.
4.6.
4.6.1.
Calendar Object
Object Purpose
The Calendar object allows assigning a type to each day of the year, across two years. Up to 16 day types can be defined. The Calendar and the day types it defines are used in the Date Criterion, available in all the decision trees of the Product Catalog.
Page 150 of 968
11 September 2009
4.6.2.
The Day Types set
The Calendar days.
Figure 63 - Calendar GUI
Table 44 - Calendar - calendar Parameter Service Retailer*

cal_own
Description Service Retailer owning the current Calendar.
Calendar Name*
mn10
Name of the Calendar currently displayed. Any decision tree must reference a particular Calendar Name. The Day Types are then available to the Date Criterion inserted in the decision tree. Name given to the Day Type button currently selected in the GUI.
Day Type...
td_mn_0
11 September 2009
Page 151 of 968
4.6.3.
Calendar GUI Management
4.6.3.1. Modifying the Name of a Day Type

1. In the Day Types set, select the button of the day type to rename. For example, if you would like to rename button DAYTYPE13, click on the button that has that name. 2. The current name (for example, daytype13) of the clicked on day type now appears in the entry field that is just above UPDATE button. In that entry field, replace the current day type name by its new name. For example, type in WeekendDays, if you would like to rename it that way. 3. Click now on UPDATE button, which appears below the entry field. The new name (for example, WeekendDays) is now displayed in the button. 4. Make now this change permanent. That is, if the calendar was not created yet, click on CREATE button, which is one of the buttons that appear at the top of the Calendar window. Otherwise, if the calendar was already existing, click on MODIFY button, which is one of the buttons that appear at the top of the Calendar windows.
4.6.3.2. Assigning a Day to a Given Day Type

1. 2. Select the appropriate Day Type in the Day Types Set. Click now on the Calendar days, which appears to the right of the Day Types Set, which have to belong to that Day Type. Notice that, as soon as a day belongs to the Day type, its button takes on the color of the Day Type button. 3. Make now these changes permanent, as step 4 of section 4.6.3.1, Modifying the Name of a Day Type, on page 152, explains.
4.6.3.3. Removing a Day from a Given Day Type

Just make that day belong to another day type, as section 4.6.3.2, Assigning a Day to a Given Day Type, on page 152, explains.
4.7.
4.7.1.
Result Code Object

Object Purpose
The Convergent Rating Engine returns a complete range of result codes to describe precisely its internal behavior, in every not OK branch of the script. The operator may want to keep track of some particular Result Codes, in order to analyze those errors like any other kind of statistics.
Page 152 of 968
11 September 2009
Meaning of the Result Code

The Convergent Rating Engine defines a large number of Result Codes together with their individual meaning. For knowing what Result Code complies with the processing event you want to keep track of in your statistical report, please see your Result Code Catalog.
4.7.2.
Figure 64 - Result Code GUI
Table 45 - Result Code - rescode Parameter Result Code*

Description Result Code that has to be inserted in the statistical ticket when occurring, in order to be available as a statistics dimension in pfmstat.
rescode
4.8.
4.8.1.
Partition Ranges Object

Object Purpose
You use this object to set up the Account partitions.
For example, you use this object to indicate which SEP groups can be used to access which Account partitions. Which means that an Account cannot be associated to a given SEP group if no instance of this object is associating the SEP group to the partition of the Account. As a result, the setup of an Account partition is strongly related to the routing algorithm in force. That setup consists in doing what follows: If you selected None as the Routing Algorithm, you use this object to tell the CRE which is the default SEP group of each of its Account partitions. With None, the default SEP group of an Account partition is the SEP group that the CRE uses every time it accesses the partition. If you selected Range as the Routing Algorithm, you use this object to tell the CRE how it deduces, from the range of values to which an Account belongs, which SEP group it has to use and which partition it has to access in order to get access to the Account. If you selected External as the Routing Algorithm, you use this object to tell the CRE which SEP groups can be specifically associated to the Accounts of a given partition.
11 September 2009
Page 153 of 968
Note: On associating a specific SEP group to an Account, see Forced SEP Group, on page 752. Note that, even in this case, you still need to indicate, for each partition, which is its default SEP group. Thats because, in case you decide not to associate a specific SEP group to an Account, the CRE will then associate to the Account the default SEP group of the partition of the Account. Note: An Account partitions SEP group always refers to an active SLEE partition (i.e. to a copy of the Account partition that is on a SLEE and that is active on that SLEE). In case the CRE installation associated a standby SLEE partition (i.e. a copy of the same Account partition that is on another SLEE and that is standby on that SLEE) to the active SLEE partition, that same SEP group also refers to that standby SLEE partition.
Page 154 of 968
11 September 2009
4.8.2.
Figure 65 - Partition Ranges GUI Note: To view the instances of this object, prefer to use Partition Ranges tab of RE Configuration object. For example, that tab makes it very easy o figure out what the lower bounds and the upper bounds of the existing ranges of values. Section 4.1.8, Partition Range Tab Parameter Description, on page 90, explains that tab.
11 September 2009
Page 155 of 968
Table 46 - Partition Ranges - (Sheet 1 of 2) Parameter Number Range Description You use this parameter to specify a range of values. You specify the range by supplying the highest value that belongs to the range. This must be an integer number that is greater or equal to zero.
To specify the range of an instance of this object, there is no need to specify the lowest value in the range: The CRE deduces that lowest value from the value of this parameter in the other instances of this object. That lowest value simply equals the highest value, from the other instances of this object, that is less than the Number Range value of the considered instance plus 1. When range partition algorithm is used, its by means of this object that you associate a specific SEP group to a given Account: A range of values can be made up of a single value. On the other hand, when modulo partition algorithm is used, you use Account object to associate a specific SEP group to a given Account. You do not use this object for doing that.

Be aware that, whatever the routing algorithm the CRE uses: You must always enter a value in this parameter. The value you give to this parameter must be different in each instance of this object. Of course, the CRE ignores this parameter value when it is using a routing algorithm other than Range. However, even then, a value is required in this parameter.
To effortlessly take knowledge of the lower and upper bounds of the existing ranges of value, use Partition Range tab of RE Configuration object. That tab lists all the instances of this object, one row per instance. To use it to easily visualize the lower and upper bounds of the ranges of value, sort the list by descending values of Range column. The lower bound of a range is then the upper bound of the row that appears just below, plus 1. Section 4.1.8, Partition Range Tab Parameter Description, on page 90, explains Partition Range tab of RE Configuration object.
Page 156 of 968
11 September 2009
Table 46 - Partition Ranges - (Sheet 2 of 2) Parameter SEP Group Description Specify here the name of a SEP group. This must be a character string. Example: etf147-creactor-P1-range2. This is the way you associate that SEP group to the partition that Partition parameter specifies. Moreover, if the used routing algorithm is Range, this is also the way you associate that SEP group to the range of values that Number Range parameter identifies.

Partition
You must associate at least one SEP group to each Account partition. A given SEP group cannot be associated to more than one Account partition. Of course, a SEP group can be associated to more than one ranges of values, provided these ranges belong to the same Account partition. An Account partition can be associated to more than one SEP group, provided the routing algorithm used is not None.
The number that is used to identify the concerned Account partition.

This must be an unsigned integer (different of zero, since partition 0 is not an Account partition). This corresponds to the Partition ID of the Account partition, as shown by PARTITION object of PFMCONFIG. Default Partition Indicates whether the SEP group is the default SEP group of the partition. The SEP group is the default SEP group of the partition only if this box is checked. Otherwise, the SEP group is not the default one of the partition. If the CRE is using either None or External routing algorithm, each partition must have one, and only one, default SEP group. On the other hand, Range routing algorithm does not use this parameter.
11 September 2009
Page 157 of 968
4.8.3.
Examples
4.8.3.1. Example for None Routing

Each row in the following table corresponds to one instance of this object. Table 47 - None Routing Example Number Range 0 1 2 3 SEP Group sleeC-creactor-P1 sleeA-creactor-P2 sleeA-creactor-P3 sleeB-creactor-P4 1 2 3 4 Partition Y Y Y Y Default Partition
As this example is for a CRE installation that is using None routing, values have still been put into Number Range column, taking care that these values are different for each instance of this object. Apart from this last constraint, these values have been arbitrarily chosen: Other values would suit too, provided they are all different. To remember, it is always mandatory to supply Number Range values. In this table, there is exactly one instance of this object per partition: With None routing, an account partition must have one, and only one, SEP group. Moreover, that SEP group must be the default one of the Account partition, which explains why the Default Partition column is showing no N.
4.8.3.2. Example for External Routing

Each row in the following table corresponds to an instance of this object. Table 48 - External Routing Example Number Range 0 1 5 2 3 SEP Group sleeD-creactor-P1 sleeA-creactor-P2 sleeE-creactor-P2 sleeA-creactor-P3 sleeB-creactor-P4 1 2 2 3 4 Partition Y Y N Y Y Default Partition
This table is showing the same rows as the table in the previous example, plus a new row (the one that shows N in Default Partition column). The N in Default Partition is now allowed because this example is for a CRE installation that is using External routing. In this example, partition 2 is installed on two different slees (the naming of the SEP groups is such that it contains the slee name): It is installed on slee A and on slee E. Note that each partition has a default SEP group, since, when modulo partition algorithm is used, each partition must have a default SEP group. Here too, values have been entered into Number Range column, taking care that they are different for each instance of this object. Values have always to be supplied for Number Range column.
Page 158 of 968
11 September 2009
In this example, whenever the CRE accesses an Account of partition 2, it uses sleeA-creactor-P2 SEP group by default, unless the Account has been explicitly set up, by the operator and through the use of the Account object GUI, to use sleeE-creactor-P2 SEP group.
4.8.3.3. Example for Range Routing

Each row in the following table corresponds to an instance of this object. Table 49 - Range Routing Example Number Range 1999999 2999999 3999998 3999999 6999999 SEP Group sleeD-creactor-P1-range1 sleeC-creactor-P2-range1 sleeD-creactor-P1-range1 sleeD-creactor-P1-range2 sleeB-creactor-P3-range1 1 2 1 1 3 Partition Default Partition n.a. n.a. n.a. n.a. n.a.
This example is about phone numbers: These phone numbers are made up of a prefix followed by a six digits number.
Note: The partition attribute of this example would be either Card Number or MSID, depending on in which one of these attributes the phone number is stored. According to the above table: Phone numbers from 000 000 to 1 999 999 correspond to Accounts that will be accessed by means of sleeD-creactor-P1-range1 SEP group and are stored into partition 1. Thus, if the CRE needs to access the Account that corresponds to 1 372 145 phone number, it will use sleeD-creactor-P1-range1 SEP group for doing that. This comes from the fact that the phone number belongs to this range. Phone numbers from 2 000 000 to 2 999 999 correspond to Accounts that will be accessed by means of sleeC-creactor-P2-range1 SEP group and are stored into partition 2. Phone numbers from 3 000 000 to 3 999 998 correspond to Accounts that will be accessed by means of sleeD-creactor-P1-range1 SEP group and are stored into partition 1. Phone number 3 999 999 corresponds to an Account that will be accessed by means of sleeD-creactorP1-range2 SEP group and that is stored into partition 1. Phone numbers from 4 000 000 to 6999 999 correspond to Accounts that will be accessed by means of sleeB-creactor-P3-range1 SEP group and are stored into partition 3. Note: In this example, there exists no phone number whose prefix is zero. These not existing numbers have nevertheless been included in the first range.
11 September 2009
Page 159 of 968
Page 160 of 968
11 September 2009
5. Optional Convergent Rating Engine Settings

5.1.
5.1.1.
Notification Feature Table Object

Object Purpose
Before explaining this objects purpose, you are introduced to the basics of notifications.
If you think you do not need to be introduced to the basics, skip to section 5.1.1.5, Notification Feature Table Object Purpose, on page 163, which explains the purpose of this object.
5.1.1.1. Whats a Notification

A notification is information that is about something that has happened to an Account and that the CRE notifies to the customer owning the Account, in order to make the customer aware of what has happened to the Account. A notification is a message sent by the CRE either by e-mail or by SMS. Thus, in a notification, the recipient of the notification (who corresponds to the customer owning the Account) is indicated by means of an e-mail address (case where the notification is sent by e-mail) or an MSISDN (case where the notification is sent by MSISDN).
A message telling to a customer that a top-up has completed on some of his/her Account is a notification example.
5.1.1.2. Whats a Notification Feature

The CRE provides several types of notifications, and groups them according to the thing (would it be more suitable to say subject?) they are about. Each such group is called a notification feature. For example, the Account State and Status notification feature groups all the types of notifications that indicate a change of an Accounts Life Cycle Status.
Table 51, CRE Notification Features and their Notification Types, on page 166, gives the complete list of the CRE notification features.
To give an idea of what a notification type is, the ones that Account State and Status notification feature groups are given here below: Valid to Active notification type Such a notification is issued when an Accounts Life Cycle Status changes from Valid to Active. Active to Inactive notification type Such a notification is issued when an Accounts Life Cycle Status goes from Active to Inactive. Valid to Deactivated notification type
11 September 2009
Page 161 of 968
Optional Convergent Rating Engine Settings
Such a notification is issued when an Accounts Life Cycle Status goes from Valid to Deactivated. Inactive to Deactivated notification type Such a notification is issued when an Accounts Life Cycle Status goes from Inactive to Deactivated.
5.1.1.3. Whats the Index ID

Each notification type needs to be uniquely identified within its notification feature (i.e., within its group). That way, each notification type can be distinguished from the other ones that belong to the same notification feature. Its the Index ID of a notification type that uniquely distinguishes it within its notification feature. As a result, the Index ID of a notification type has to be unique with respect to the other notification types that belong to the same notification feature. But it does not need to be unique with respect to the notification types that belong to the other notification features. For a few notification features, the CRE imposes the value of the Index ID of their notification types. For the other notification features, the Index ID of their notification types is not imposed, which means that you can give them a value that is specific to your CRE installation. Note: Thus, when you choose a value for a notification type that belongs to a notification feature whose Index IDs are not imposed, be sure you choose for it an Index ID that is distinct of the Index ID of the other notification types of the notification feature.

To know which notification types have their Index ID value imposed by the CRE, and which dont, see Table 51, CRE Notification Features and their Notification Types, on page 166. For details on how you choose an Index ID value of notification types, see 5.1.4.1, Enabling a Notification Feature in the CRE, on page 174.
5.1.1.4. Whats a Rating Engine Number? Whats a Feature Id?

5.1.1.4.1. How the CRE Identifies its Notification Features: The Rating Engine Number
We have seen that a notification type has an identification number (which is called the Index ID of the notification type) that is unique within the notification feature of the notification type. In addition to this, a notification feature has also its own identification number, which is unique with respect to the other notification features. That number, which is only known within the CRE, is called the Rating Engine Number of the notification feature. The Rating Engine Number of a notification feature is imposed by the CRE. It is thus a fixed number and you can find out its value by consulting Table 51, CRE Notification Features and their Notification Types, on page 166. As a result, within the CRE, each notification type can be unambiguously distinguished from any other notification type, by combining its Index ID with the Rating Engine Number of its notification feature.
Page 162 of 968
11 September 2009
5.1.1.4.2. How the UNS Identifies its Notification Features: The Feature Id
The UNS service, which is distinct from the CRE service, is an OSP service that is in charge of sending notifications that have to be delivered either by SMS or by e-mail. As a result, whenever an RTx, or the CRE, needs to send a notification that is to be delivered either by SMS or by e-mail, it delegates this task to the UNS, by requesting the UNS to send that notification. Note: CRE notifications are either delivered by SMS or by e-mail. Like the CRE, the UNS groups notification types by notification features. Except for two notification features, there is a direct mapping between CRE and UNS notification features. That is, a CRE notification feature contains the same notification types as its UNS counterpart. Note: The two notification features that do not follow this direct mapping rule are tackled further down. Since it is an OSP service, the UNS is also used by other OSP services. This means that some OSP service might internally assign to its notification features one or more numbers (e.g. for the CRE, these numbers would be Rating Engine Numbers) that other OSP services also internally assigned to some of their own notification features. To smoothly settle such conflicts, the UNS makes it possible to give to any of its notification features, in order to uniquely distinguish it within the UNS, an arbitrary number that is different from the ones assigned to the other UNS notification features. That number, which the UNS assigns to a notification feature, is chosen independently of the CRE Rating Engine Numbers, and is called the Feature Id of the notification feature.
As a result, within the CRE, a notification feature is identified by means of a Rating Engine Number. And within the UNS, a notification feature is identified by means of a Feature Id. Note: As a result, within the UNS, each notification type can be unambiguously distinguished from any other notification type, by combining its Index ID with the Feature ID of its notification feature. Note: The Rating Engine Number of a notification feature, as well as its Feature Id, can of course have a different value. Whenever the CRE, like any other OSP service, requests the UNS to send a notification, it must give in the request to the UNS the Feature Id to which the notification type, of the notification, belongs. The problem is that the CRE internally uses Rating Engine Numbers to identify its notification features. As a result, whenever the CRE wants to request the UNS to send some notification, the CRE needs to convert the Rating Engine Number, of the notification feature to which the notification to send belongs, to the corresponding Feature Id, which it puts in the request. The information that enables the CRE to convert a Rating Engine Number to a Feature Id is supplied by the Notification Feature Table. At this stage, we have discovered one purpose of Notification Feature Table: Converting a Rating Engine Number into a Feature Id. This table has however another purpose. Therefore, be sure your read next section: It fully presents the various purposes of the Notification Feature Table. Note: As you see, Index IDs do not need to be converted.
5.1.1.5. Notification Feature Table Object Purpose

You use this object to: Indicate which Rating Engine Number value corresponds to which Feature Id value,
11 September 2009
Page 163 of 968
Enable/disable a given notification feature in the CRE.
5.1.1.5.1. Converting a Rating Engine Number into a Feature Id

Because The Rating Engine Number and the Feature Id of a notification feature can have a different value, and The UNS service only understands notification issuing requests that are expressed in terms of Feature Ids, the CRE hosts a table that it uses to convert a Rating Engine Number into its corresponding Feature Id whenever it requests the UNS to send a notification.
5.1.1.5.2. Enabling/Disabling a Given Notification Feature in the CRE

Its by means of the Notification Feature Table object that you enable or disable a notification feature not in the CRE. To enable a given notification feature, make sure that one instance of Notification Feature Table object has its Rating Engine Number parameter set to the Rating Engine Number of the notification feature. Make also sure that the instance is correctly filled in. As soon as that has been done, the notification feature is enabled in the CRE. Note: Before you enable a notification feature in the CRE, you need to make sure that the notification feature is correctly set up in the UNS.
On this, see also 5.1.4.1, Enabling a Notification Feature in the CRE, on page 174.
To disable a given notification feature, make sure that no instance of Notification feature Table object has its Rating Engine Number parameter set to the Rating Engine Number of the notification feature. As soon as that has been done, the notification feature is disabled in the CRE.
5.1.2.
Figure 66 - Notification Feature Table GUI
Page 164 of 968
11 September 2009
A notification feature is enabled in the CRE if there is one instance of Notification Feature Table object for it. Here below the description of the parameters that have then to be filled in for the notification feature: Table 50 - Notification Feature Table Parameter Service Retailer* Feature Description Feature ID* Description Reference to the Service Retailer defining the current Notification Feature. Insert here a short text reminding what the notification feature is about. This is free text. Enter here the Feature ID value of the notification feature. This must be a positive unsigned integer value.
This must naturally be a Feature ID value that is defined in the UNS. Of course, if the notification feature has no Feature ID defined in the UNS yet, that means that the notification feature is not yet configured in the UNS. In that case, you need to first configure the notification feature in the UNS (which implies you will choose a Feature Id value for it) and to afterwards enter its Feature ID value into this parameter.
See also 5.1.1.4, Whats a Rating Engine Number? Whats a Feature Id?, on page 162.
Rating Engine Number*
Enter here the Rating Engine Number value of the notification feature. This must be a positive unsigned integer value.
See also 5.1.1.4, Whats a Rating Engine Number? Whats a Feature Id?, on page 162. To know which values to use here, see Table 51, CRE Notification Features and their
Notification Types, on page 166.
LiteSCE Flag
Not used.
11 September 2009
Page 165 of 968
5.1.3.
Notification Features
The following table lists the available notification features and their notification types and attempts to concisely describe them. Table 51 - CRE Notification Features and their Notification Types Is Index ID Imposed?b Notification Feature Name
Recommended Feature Id
Rating Engine Number
Available?a
Notification Type Name
Account State and Status
The purpose of this notification feature is to warn the customer owning the Account that the Accounts Life Cycle Status changed. This notification feature provides the following types of notifications: Valid to Active (Index ID = 1) Indicates that the Accounts Life Cycle Status went from Valid to Active. Active to Inactive (Index ID = 2) Indicates that the Accounts Life Cycle Status went from Active to Inactive. Valid to Deactivated (Index ID = 3) Indicates that the Accounts Life Cycle Status went from Valid to Deactivated. Inactive to Deactivated (Index ID = 4) Indicates that the Accounts Life Cycle Status went from Inactive to Deactivated. As soon as this notification feature has been enabled in the CRE, all the notification types of this notification feature are enabled for each CRE Account. Thus, when this notification feature is enabled in the CRE and this notification feature sees that an Accounts Life Cycle Status went from Valid to Active, this notification feature issues a Valid to Active notification to the customer owning the Account This notification feature acts similarly for its other notification types.
Page 166 of 968
11 September 2009
Table 51 - CRE Notification Features and their Notification Types Is Index ID Imposed?b Notification Feature Name
Available?a
Top Up
The purpose of this notification feature is to warn the customer owning the Account that a Top-Up of the Accounts main balance has completed. This notification feature provides the following notification type: Reload on Main Account Indicates that Top-Up of Accounts main balance has completed. Top Up on Sub Account Indicates the number of units available on an Accounts Bundle. By default, this type of notification is never issued by the CRE. As a result, to have the CRE issue this type of notification, you have to set up a LiteSCE script that issues this type of notification. When Reload on Main Account notification type is enabled on a given Account and this notification feature sees that a Top-Up of the Accounts main balance has completed, the notification feature issues a Reload on Main Account notification to the customer owning the Account.
Activation Fee Activation Bonus Loyalty Bonus
n n n
3 4 5
3 4 5
11 September 2009
Page 167 of 968
Available?a
Credit Level on Main Balance
The purpose of this notification feature is to warn the customer owning the Account that the Accounts main balance is getting too low. This notification feature provides the following notification type: Credit Warning Threshold Indicates that the Accounts main balance has become lower than some threshold value. You enable this notification type per Account Profile. Thus, to enable this notification type on a given Account, you have to enable the notification type on the Account Profile of the Account. Doing that, you also enable the notification type for all the other Accounts associated with the Account Profile. As a result, with the CRE, you always enable this notification type for a range of Accounts. Whenever you enable this notification type on an Account Profile, you need to specify up to two threshold values, namely the 1st Credit Warning Threshold and the 2nd Credit Warning Threshold. When Credit Warning Threshold notification type is enabled on a given Account and this notification feature sees that the main balance of the Account gets lower than then 1st Credit Warning Threshold associated with the Accountc, the notification feature issues a Credit Warning Threshold notification to the customer owning the Account. Similarly, when Credit Warning Threshold notification feature is enabled on a given Account and this notification feature sees that the main balance of the Account gets lower than then 2st Credit Warning Threshold associated with the Account, the notification feature issues another Credit Warning Threshold notification to the customer owning the Account.
Page 168 of 968
11 September 2009
Available?a
Promotion (Bonus or on call)
The purpose of this notification feature is to warn the customer owning the Account that the Promotion Tool has granted a promotion (that is, either an On Call promotion or a Bonus promotion) to the Account. This notification feature provides one single notification type: On Call Promotion This notification type indicates that an On Call promotion has been granted to the Account. As you see, this notification feature provides no notification type to warn of a Bonus promotion. Thats because there is no need for that, since a Bonus promotion always results in a TopUp done on the main balance of the Account. Thus, if notification feature Top Up is enabled on the Account at time the Bonus promotion is granted, a Reload on Main Account notification is issued. Using a Reload on Main Account notification is the way this features notifies a Bonus promotion grant. Therefore, if you want Bonus promotion notification to be enabled on some Account, be sure that Top Up notification feature is enabled on that Account. When On Call Promotion notification type is enabled on a given Account and this notification feature sees that an On Call Promotion has been granted to the Account, this notification feature issues an On Call Promotion notification to the customer owning the Account.
11 September 2009
Page 169 of 968
Available?a
Credit Level on Bundle
The purpose of this notification feature is to warn the customer owning the Account that the has become low (the total includes the bundles reserved units). This notification feature provides the two following notification types: All Counters This notification type informs of the total units that the bundle makes available for consumption. As it is about units available for consumption, the total equals the bundles remaining units plus the bundles reserved units. Counters Accumulated
This notification type informs of the units that eachd bucket of the bundle makes available for consumption. Again, as they are about units available for consumption, the units given for a bucket equal the buckets remaining units plus the buckets reserved units. As you see, these two notification types only differ by their content.
Only the bundles buckets active at time of notification issuing are considered for calculating the totals in the notification.
When either All Counters or Counters Accumulated is enabled on a given Accounts bundle and this notification feature sees that the total units that the Accounts bundle makes available for consumption has become low, this notification feature issues either an All Counters or a Counters Accumulated notification type to the customer owning the Account, depending on which one of the notification types is enabled on the Accounts bundle.
Section 20.2, Account Profile and Usage Link object, on

page 804, explains how the CRE decides that the total units available for consumption are too low.
Active Bucket, on page 26, explains active buckets. At a time, you can enable on an Accounts bundle only one
notification type of this notification feature.
Subscripti on
Page 170 of 968
11 September 2009
Available?a
Interrogati on
10
10
This notification feature makes it possible to interrogate a given CRE Account from outside the CRE (e.g. from an RTx). Only the following RTx requests can interrogate a CRE Account: getppm, getandcheckppm, getcustndefacc, getncheckcustndefacc and getcust and getncheckcust in case an Account is returned.e A notification belonging to this feature is of one of the following types: Credit Level on Main Account This type of notification returns back the main balance value. Credit Level on Bundle (All Counters) This is the same as All Counters notification type of Credit Level on Sub feature. Credit Level on Bundle (Counters Accumulated) Same as Counters Accumulated notification type of Credit Level on Sub feature. Whenever Credit Level on Main Account is enabled on a given Account and this notification feature sees that the Account main balance is interrogated, this notification feature issues a Credit Level on Main Account notification type to the customer owning the Account. Whenever either Credit Level on Bundle (All Counters) or Credit Level on Bundle (Counters Accumulated) is enabled on a given Accounts bundle and this notification feature sees that the Accounts bundle is interrogated, this notification feature issues either Credit Level on Bundle (All Counters) or a Credit Level on Bundle (Counters Accumulated) notification type to the customer owning the Account, depending on which one of the notification types is enabled on the Accounts bundle.
11 September 2009
Page 171 of 968
Available?a
End of Active Period (Prepaid Only)
11
11
The purpose of this notification feature is to warn the customer owning the Account that the end of the Accounts Active Period will soon be reached. This notification feature provides the following notification type: Warning Indicates that End of Accounts Active Period will soon be reached. You enable this notification type per Account Profile. Thus, to enable this notification type on a given Account, you have to enable the notification type on the Account Profile of the Account. Doing that, you also enable the notification type for all the other Accounts associated with the Account Profile. As a result, with the CRE, you always enable this notification type for a range of Accounts. Whenever you enable this notification type on an Account Profile, you need to specify up to two threshold values, namely Days before 1st Activity End Warning and Days Before 2nd Activity End Warning. When Warning notification type, of this notification feature, is enabled on a given Account and this notification feature sees that the number of days before the end of the Accounts Active period gets lower then Days Before 1st Activity End Warning, this notification feature issues its Warning notification to the customer owning the Account. When Warning notification type, of this notification feature, is enabled on a given Account and this notification feature sees that the number of days before the end of the Accounts Active period gets lower then Days Before 2nd Activity End Warning, this notification feature issues its Warning notification again, to the customer owning the Account.
Periodic Fee
12
12
Page 172 of 968
11 September 2009
Available?a
End of Inactivity Period Warning (Prepaid Only)
13
13
The purpose of this notification feature is to warn the customer owning the Account that the end of the Accounts Active Period will soon be reached. This notification feature provides the following notification type: Warning End of Accounts Inactive Period will be soon reached.
You enable this notification type per Account Profile. Thus, to enable this notification type on a given Account, you have to enable the notification type on the Account Profile of the Account. Doing that, you also enable the notification type for all the other Accounts associated with the Account Profile. As a result, with the CRE, you always enable this notification type for a range of Accounts. Whenever you enable this notification type on an Account Profile, you need to specify up to two threshold values, namely Days before 1st Inactivity End Warning and Days before 2nd Inactivity End Warning. When Warning notification type, of this notification feature, is enabled on a given Account and this notification feature sees that the number of days before the end of the Accounts Active period gets lower then Days before 1st Inactivity End Warning, this notification feature issues its Warning notification to the customer owning the Account. When Warning notification type, of this notification feature, is enabled on a given Account and this notification feature sees that the number of days before the end of the Accounts Active period gets lower then Days before 2nd Inactivity End Warning, this notification feature again issues its Warning notification, to the customer owning the Account.
a. y: The notification feature is available (can be enabled in the CRE). n: The feature is not available (cannot be enabled in the CRE). b. y: The Index ID of each notification type of the notification feature is imposed. n: No Index ID is imposed. -: Its not relevant to answer the question. c. To be more accurate, this is the 1st Credit Warning Threshold from the Account Profile associated with the Account. d. This is limited to the first three buckets. The order in which the buckets are given depend on the value of parameter Order of Bucket Usage of the bundle (which is an instance of Bundle/Counter Usage Label object). e. When the CRE runs in Gateway mode, getcust and getncheckcust can only return an Account. On the other hand, when the CRE does not run in Gateway mode, getcust and getncheckcust can return an Account only if they do not specify the ppmindex and the ppmvalue of a Customer.
11 September 2009
Page 173 of 968
5.1.4.
Tips
5.1.4.1. Enabling a Notification Feature in the CRE

1. Find out the Rating Engine Number of the notification feature For that, consult Table 51, CRE Notification Features and their Notification Types, on page 166. 2. Find out the notification types of the notification feature. For that, consult Table 51, CRE Notification Features and their Notification Types, on page 166. 3. Find out the Index ID of each notification type of the notification feature. For that, do the steps here below in the order they are listed: Check whether the Index ID of the notification types is imposed by the CRE or not. To know whether the Index ID is imposed or not, consult Table 51, CRE Notification Features and their Notification Types, on page 166. If the Index ID is imposed, the Index ID of each notification type is given by Table 51, CRE Notification Features and their Notification Types, on page 166. If the Index ID is not imposed, assign to each notification type an Index ID value that is a positive (thus, not equal to zero) integer value and that is unique within the notification feature of the notification type. In other terms, no two or more notification types belonging to the same notification feature may have the same Index ID. One way of doing this is to assign 1 to the first notification type, 2 to the next one, 3 to the next one, and so on until each notification type has been assigned an Index ID value, different from the Index ID value of the other notification types of the notification feature. Note: When both Top Up and Interrogation notification features are enabled in the CRE, Reload on Main Account notification type (of Top Up notification feature) and Credit Level on Main Account notification type (of Interrogation notification feature) must have the same Index ID value. Note: When both Credit Level on Bundle and Interrogation notification features are enabled in the CRE, All Counters notification type (of Credit Level on Bundle notification feature) and Credit Level on Bundle (All Counters) notification type (of Interrogation notification feature) must have the same Index ID value. Note: When both Credit Level on Bundle and Interrogation notification features are enabled in the CRE, Counters Accumulated notification type (of Credit Level on Bundle notification feature) and Credit Level on Bundle (Counters Accumulated) notification type (of Interrogation notification feature) must have the same Index ID value. Note: Never use 0 as the Index ID of a notification type. Note: When the Index ID is not imposed, be sure you make a note (e.g., on a sheet of paper that you would file for later use) of the Index IDs you assign to the notification types of the notification feature. You will need to remember them several times later on. 4. Configure the notification feature in the UNS. For that, do the steps below in the order they are listed:
Page 174 of 968
11 September 2009
Choose a Feature Id value for the notification feature. This must be a Feature ID value that no notification feature defined in the UNS is using. Define in the UNS the notification feature, assigning it the Feature Id you just chose. Note: For Credit Level on Main Balance notification feature, you need to define three notification features in the UNS instead of only one.
The first one has to be defined with the Feature Id you chose for Credit Level on Main Balance notification feature (let us call this Feature Id value first-feature-id-value). This notification feature is used when Credit Level on Main Balance notification contains a positive main balance. The second one has to be defined with its Feature Id set to first-feature-id-value + 100. This notification feature is used when Credit Level on Main Balance notification contains a negative main balance. The third one has to be defined with its Feature Id set to first-feature-id-value + 200. This notification feature is used when Credit Level on Main Balance notification contains a null main balance.
Note: For Interrogation notification feature too, you need to define three notification features in the UNS instead of only one. To do that, you follow the same logic as for Credit Level on Main Balance notification feature. That is, the first notification feature has to be defined with the Feature Id you chose for Interrogation notification feature. The second one has to be defined with the feature you chose for Interrogation notification feature plus 100. The third one has to be defined with the feature you chose for Interrogation notification feature plus 200. Define in the UNS each notification type of the notification feature, assigning it, in the UNS, the Index ID you found out for it at step 3. Note: For Credit Level on Main Balance notification feature, its notification type (which is called Credit Warning Threshold) has to be defined for each of the three features defined for Credit Level on Main Balance notification feature in the UNS. Note: For Interrogation notification feature, notification type Credit Level on Main Account has to be defined for each of the three features defined for Interrogation notification feature in the UNS. If the notification is to be delivered by SMS, make sure it is suitably configured in the UNS for SMS delivery. If the notification is to be delivered by e-mail, make sure it is to be suitably configured in the UNS for e-mail delivery. 5. Enable the notification feature in the CRE. Create a new instance of Notification Feature Table object in which: Feature ID* parameter is set to the Feature ID chosen at step 4. Note: This is also true for Credit Level on Main Balance and for Interrogation notification feature. That is, although you need to define three notification features in the UNS for each of these notification features, you create only one instance of the Notification Feature Table object for each of these notification features. Rating Engine Number parameter is set to the Rating Engine number discovered at step 1.
11 September 2009
Page 175 of 968
5.1.4.2. Initial Set Up of the Notification Feature Table

If you do not need that the CRE issues notifications, just make sure that no instances of Notification Feature Table object exist in the CRE. This will disable in the CRE all the notification features, and thus all the notifications. If you otherwise want that the CRE issues notifications: 1. Make first a list of the notification features you need. For that, just pick from table Table 51, CRE Notification Features and their Notification Types, on page 166, the notification features that suit you. 2. Enable in the CRE each notification feature you have selected. For that, for each selected notification, do what section 5.1.4.1, Enabling a Notification Feature in the CRE, on page 174, explains. Of course, you can enable and disable notification features at any time later on. That is, you can add/ remove new/existing instances of Notification Feature Table at any time.
5.1.5.
Enabling a Given Notification Type on a Given Account
Note: Only the notification types belonging to Account State and Status notification feature are automatically enabled on all CRE Accounts in consequence of enabling their notification feature in the CRE.
On how you enable a notification feature in the CRE, see section 5.1.4.1, Enabling a Notification Feature in the CRE, on page 174.
There is something more to do: You have to indicate that the CRE has to issue, as necessary, that type of notification for the Account. Or, in other terms, you need to enable on the Account that type of notification. The goal of this section is to explain you how you enable a given notification type on a given Account. For that, you are first given a practical example. Afterwards, you are introduced to the general case. Finally, a table indicates you for each notification type the specific actions you need to undertake in order to enable the notification type on a given Account.
5.1.5.1. Enabling Reload on Main Account Notification Type on a Given Account

Let us assume we want that the CRE issues a Reload on main account notification every time a Top-Up of the main balance of a given Account completes. For that, you need to modify the Account Profile of the Account in such a way that Notification Index ID* parameter, from Warning tab of the Account Profile, is no longer set to 0, but contains the Index ID you assigned to Reload on main account notification type at step 3 of section 5.1.4.1, Enabling a Notification Feature in the CRE, on page 174.
Page 176 of 968
11 September 2009
If a given notification type is one that is not automatically enabled on all CRE Accounts in consequence of enabling in the CRE the notification feature to which it belongs, and if you want that the CRE issues as necessary notifications of that notification type for a given Account, its not enough that you enable in the CRE the notification feature of the notification type.
The figure here below shows an example of that tab:
Figure 67 - Reload on main account Notification Type Enabled In the figure above, Notification Index ID* is set to 1. It has been set to 1 because: While performing on notification feature Top Up step 3, from section 5.1.4.1, Enabling a Notification Feature in the CRE, on page 174, it was decided that the Index ID of Reload on main account notification type would be 1,
Notification Index ID* is the Account Profiles parameter you use to enable Reload on main account notification type on the Accounts of the Account Profile. Of course, you cannot guess that Notification Index ID* parameter serves that purpose. One way to find out that information is by consulting Table 52, Enabling a Given Notification Type on a Given Account, on page 178. In addition, if you consult section 19.1, Account Profile object, on page 704,which documents Account Profiles, you will read there that Notification Index ID* is used to enable Reload on main account notification type on the Accounts associated to the Account Profile. But using the table previous paragraph mentions is certainly the quickest method. As you see with this example: You enable Reload on main account notification type on a specific Account by enabling the notification type on the Account Profile of the Account. That means that you always enable Reload on main account notification type on a range of Accounts: That is, on those Accounts that are associated with the Account Profile on which you enable the notification type. In fact, whenever you need to enable a notification type on an Account, you never directly enable the notification type on the Account: You always enable the notification type on an object instance that is associated with the Account. To know on which associated object you need to enable a given notification type, you should consult Table 52, Enabling a Given Notification Type on a Given Account, on page 178. As you see too, specifying a non null Index ID in the right parameter of the right object instance is the way you enable a specific notification type for a given Account. Again, to find out which parameter is involved, you should consult Table 52, Enabling a Given Notification Type on a Given Account, on page 178.
11 September 2009
Page 177 of 968
5.1.5.2. Enabling a Given Notification Type on a Given Account

As has been seen in previous section, to enable a given notification type on a given Account, you enter the Index ID of the notification type into some parameter of some object instance that is associated with the Account. Use the table below to find out which parameter and which object instance are involved. Also use the table below to know how you enable a given notification type on a given account. Note: Do not forget that a notification type cannot be enabled on an Account if the notification feature to which it belongs is not enabled in the CRE.
On how you enable a notification feature in the CRE, see section 5.1.4.1, Enabling a Notification Feature in the CRE, on page 174. Table 52 - Enabling a Given Notification Type on a Given Accounta
Feature Name Account State and Status
Notification Type Valid to Active Active to Inactive Valid to Deactivated Inactive to Deactivated
How to Enable on a Given Account These notification types are automatically enabled for any Account (of course, for that, Account State and Status notification feature must be enabled in the CRE).
Top Up
Reload on Main Account
To enable this notification type on a given Account, proceed as follows: 1. Display Warning tab of the Account Profile associated with the Account 2. Enter into Notification ID* parameter of the tab the Index ID you chose for this notification type.
Activation Fee Activation Bonus Loyalty Bonus
Page 178 of 968
11 September 2009
Table 52 - Enabling a Given Notification Type on a Given Accounta Feature Name Credit Level on Main Balance Notification Type Credit Warning Threshold How to Enable on a Given Account To enable this notification type on a given Account, first enable the notification type on the Account Profile of the Account. To enable this notification type on the Account Profile, proceed as follows: 1. Display General tab of the Account Profile associated with the Account. 2. Enter into 1st Credit Warning Threshold parameter the main balance value under which the CRE decides that a first Credit Warning Threshold notification is to be issued for the Account. 3. Enter into 2nd Credit Warning Threshold parameter the main balance value under which the CRE decides that a second Credit Warning Threshold notification is to be issued for the Account. 4. Display Warning tab of the Account Profile 5. Enter into Low Credit Warning parameter of the tab the Index ID you chose for this notification type.
6. Display Flexibility tab of the Account Profile. 7. Click on the black solid triangle to the left of Low Credit Warning Activation parameter of the tab. 8. In the drop-down menu that then appears, select Enable. Now that this notification type is enabled on the Account Profile associated with the Account, do what follows on the Account: 1. Display Status tab of the Account. 2. Make sure that 1st Low Credit Warning Done is not checked. 3. Make sure that 2nd Low Credit Warning Done is not checked. Promotion (Bonus or on call) On Call Promotion To enable this notification type on a promotion that is associated with an Account, proceed as follows: 1. Display General tab of the promotion (this is an instance of Promotion Tool object that is associated with the Account). 2. Enter into Notification ID* parameter of the tab the Index ID you chose for this notification type.
11 September 2009
Page 179 of 968
Table 52 - Enabling a Given Notification Type on a Given Accounta Feature Name Credit Level on Bundle Notification Type All Counters Counters Accumulated How to Enable on a Given Account To enable one of these notification types on a bundle that an Account usesb, proceed as follows: 1. Display the instance of Account Profile and Usage Link object that associates the bundle to the Account Profile of the Account 2. Click on the black solid triangle that appears to the right of Type of notification. 3. In the drop-down menu that then appears, select the notification type you want (that is, select either All Counters or Counters Accumulated). 4. Enter into Notification ID parameter the Index ID you chose for the just selected notification type. 5. Enter into Warning Threshold parameter the threshold value that the CRE compares against the Accounts bundle total units in order to decide whether the notification is to be issued or not.
With a given Account Profile, a bundle cannot be involved in more than one Account Profile and Usage Link. As a result, its not possible to have the two notification types enabled at the same time on a given Accounts bundle.
Subscription Interrogation
Credit Level on Main Account
To enable this notification type on a given Account, proceed as explained for Top Up notification feature.
Thus, if you already enabled the notification type of Top Up notification feature on the Account, and you additionally want to enable Credit Level on Main Account notification type of this notification feature on the Account, you have nothing to do.
Interrogation
Credit Level on Bundle (All Counters) Credit Level on Bundle (Counters Accumulated )
To enable this notification type on a given Account, proceed as explained for Credit Level on Bundle notification feature.
Thus, if you already enabled one of the notification types of Credit Level on Bundle notification feature on the Account, and you additionally want to enable one notification type of this notification feature on the Account, you have nothing to do.
Page 180 of 968
11 September 2009
Table 52 - Enabling a Given Notification Type on a Given Accounta Feature Name End of Active Period (Prepaid Only) Notification Type Warning How to Enable on a Given Account To enable this notification type on a given Account, first enable this notification type on the Account Profile of the Account. To enable this notification type on the Account profile, do what follows: 1. Display Warning tab of the Account Profile associated with the Account 2. Enter into Days before 1st Activity End Warning parameter the number of days, before the end of the activity period, at which the first warning has to be issued. 3. If you need a second warning, enter into Days Before 2nd Activity End Warning parameter the number of days, before the end of the activity period, at which the second warning has to be issued. 4. Enter into Activity Period Warning parameter of the tab the Index ID you chose for this notification type. Now that this notification type is enabled on the Account Profile associated with the Account, do what follows on the Account:
1. 2. 3. Periodic Fee -
Display Status tab of the Account. Make sure that 1st Active Period Warning Done is not checked. Make sure that 2nd Active Period Warning Done is not checked.
11 September 2009
Page 181 of 968
Table 52 - Enabling a Given Notification Type on a Given Accounta Feature Name End of Inactivity Period Warning (Prepaid Only) Notification Type Warning How to Enable on a Given Account To enable this notification type on a given Account, first enable this notification type on the Account Profile of the Account. To enable this notification type on the Account profile, do what follows: 1. Display Warning tab of the Account Profile associated with the Account 2. Enter into Days before 1st Inactivity End Warning parameter the number of days, before the end of the inactivity period, at which the first warning has to be issued. 3. If you need a second warning, enter into Days before 2nd Inactivity End Warning parameter the number of days, before the end of the inactivity period, at which the second warning has to be issued. 4. Enter into Inactivity Period parameter of the tab the Index ID you chose for this notification type. Now that this notification type is enabled on the Account Profile associated with the Account, do what follows on the Account: 1. 2. 3. Display Status tab of the Account. Make sure that 1st Inactive Period Warning Done is not checked. Make sure that 2nd Inactive Period Warning Done is not checked.
a. Whenever you need to enable a given notification type on a given Account, do not forget to make sure that the notification feature, to which the notification type belongs, is enabled in the CRE. b. A given Account is using a given bundle if, and only if, there exists one or more instances of bucket object that refer to both the bundle and the Account.
5.1.6.
Specifying the MSISDN and/or the E-Mail Address of the Notifications
Whenever it issues a notification to be sent by SMS, the CRE assumes that the MSISDN of the notifications recipient is stored into Card Number* parameter of the Account that the notification is about. If not, the CRE sends notification to the coressponding e-mail id address of that recipient (If and only if the Card Number* is empty) Therefore, if an Account may be subject to one or more notifications and some of these notifications may be sent by SMS to the customer owning the Account, be sure that Card Number* parameter of the Account contains the MSISDN of the customer owning the Account. But if this field is empty then, E-Mail parameter must be filled in order to send the notification as e-mail. Whenever it issues a notification to be sent by e-mail, the CRE assumes that the e-mail address of the notifications recipient is stored into E-mail and MSISDN in Card Number * parameter of the Account that the notification is about.
Page 182 of 968
11 September 2009
Therefore, if an Account may be subject to one or more notifications and some of these notifications may be sent by e-mail as well as to the customer owning the Account, be sure that the E-mail address and Card Number parameters of the Account contains the e-mail address of the customer owning the Account. If either of the two is missing the notification is still being sent to the one which exists.
5.1.7.
Indicating Whether a Notification Is to Be Sent by SMS or by E-mail.
It is Notify By* parameter of the Account Profile of an Account that indicates whether the notifications enabled on the Account have to be sent either by SMS or by e-mail. Since Notify By* parameter of a given Account Profile applies to all the Accounts associated with the Account Profile, you make per Account Profile the decision to send notifications by SMS or e-mail. That is, you always make that decision for a range of Accounts, which is the set of all the Accounts that are associated with the Account Profile.
11 September 2009
Page 183 of 968
5.1.8.
What Does When a Notification Feature Sees that... Means
For each type of notification that is enabled on an Account, the CRE checks at specific points in time whether it has to issue the notification or not. This is the reason why expressions such as ... when a notification feature sees that... are found in the text of Table 51, CRE Notification Features and their Notification Types, on page 166. Such expressions refer to these specific points in time, at which the CRE checks whether it has to issue or not a notification.
Page 184 of 968
11 September 2009
The table here below indicates for each notification type at which point in time the CRE checks whether a notification of that type has to be issued for a given Account or not. Table 53 - When can a Notification be issued? When account goes from inactive to deactive state in first request CRE will try to send all the notifications which are currently send in end of call. Notification Feature Account State and Status Notification Type Valid to Active The Notification Can Be Issued Upon fstreq RTx request oneshot RTx request getandcheckppm RTx request getncheckcustomerndefacc Rtx request getncheckcust RTx request Active to Inactive fstreq RTx request oneshot RTx request endreq RTx request cancel RTx request
getandcheckppm RTx request getncheckcustomerndefacc Rtx request getncheckcust RTx request OOC processing Valid to Deactivated fstreq RTx request oneshot RTx request getandcheckppm RTx request getncheckcustomerndefacc Rtx request getncheckcust RTx request OOC processing Inactive to Deactivated fstreq RTx request oneshot RTx request getandcheckppm RTx request getncheckcustomerndefacc Rtx request getncheckcust RTx request OOC processing Top Up Activation Fee Reload on Main Account credupdreq RTx request -
11 September 2009
Page 185 of 968
Table 53 - When can a Notification be issued? (continued) When account goes from inactive to deactive state in first request CRE will try to send all the notifications which are currently send in end of call. Notification Feature Activation Bonus Loyalty Bonus Credit Level on Main balance Credit warning Threshold in consequence of 1st Credit Warning Threshold reached Credit warning Threshold in consequence of 2nd Credit Warning Threshold reached Notification Type fstreq RTx request oneshot RTx request directdebit RTx request endcall RTx request directdebit RTx request oneshot RTx request cancel RTx request Promotion (Bonus or on call) On Call Promotion Bonus fstreq RTx request oneshot RTx request OOC processing Credit Level on Bundle All Counters Counters Accumulated fstreq RTx request oneshot RTx request nextreq RTx request endcall RTx request cancel RTx request Subscription Interrogation Credit Level on Main Balance Credit Level on Bundle (All Counters) Credit Level on Bundle (Counters Accumulated) getppm RTx request getandcheckppm RTx request getcustndefacc RTx request getncheckcustndefacc RTx request getcust or getncheckcust RTx request in case the RTx request returns an Account
The Notification Can Be Issued Upon
Page 186 of 968
11 September 2009
Table 53 - When can a Notification be issued? (continued) When account goes from inactive to deactive state in first request CRE will try to send all the notifications which are currently send in end of call. Notification Feature End of Active Period (Prepaid Only) Notification Type Warning in consequence of Days Before 1st Activity End Warning reached. The Notification Can Be Issued Upon OOC Processing endcall RTx request cancel RTx request fstreq RTx request oneshot RTx request Warning in consequence of Days Before 2nd Activity End Warning reached. fstreq RTx request oneshot RTx request endcall RTx request cancel RTx request OOC processing End of Inactivity Period Warning (Prepaid Only) Warning in consequence of Days before 1st Inactivity End Warning reached. Warning in consequence of Days before 2nd Inactivity End Warning reached. fstreq RTx request oneshot RTx request OOC processing
5.2.
5.2.1.
Out of Call Processing

What It Is About
Any processing that the CRE performs is either done in call or out of call. Any in call work done by the CRE corresponds to work that is done while, and in consequence of, processing an RTx request. As a result, any other kind of processing done by the CRE is called out of call processing (often referred to as the out of call or as OOC).
5.2.2.
What It Does
The role of the OOC is to execute macros 0-7 within the daily timebands that the OOC configuration specifies. Moreover, the OOC delays the execution of its macros on a given SLEE when that SLEE CPU load is too high (i.e., higher than the CPU load threshold that the OOC configuration specifies). Note: The OOC runs on SLEEs only. On a SLEE, it is implemented by one SEP of the SLEE, which takes care of all of the active Account partitions of the SLEE. No more than one SEP of a SLEE may implement the OOC.
11 September 2009
Page 187 of 968
5.2.2.1. OOC Macros 1-7

By configuring the out of call processing, you can make it perform any of the following tasks in background: MACRO 1: Housekeeping of Accounts life cycle management. This task is referred to as macro 1. This macro fetches accounts that are - currently "valid" but whose validity period has got expired (case 1), - currently "active" but whose activity period has got expired (case 2), - currently "inactive" but whose inactivity period has got expired (case 3) For case 1: status of account is transformed from "valid" to "deactive". For case 2: status of account is transformed from "active" to "inactive". For case 3: status of account is transformed from "inactive" to "deactive". Note: All OOC macros 0-7 need to be configured in "OOC Timeband" object. In case if they are required, set them "active" (i.e. green timeband) else set them inactive (i.e. red timeband). This is MANDATORY to avoid alarms "Object not found" with regard to respective OOC macro that hasn't been configured in "OOC Timeband object." MACRO 2: Computing and granting to Accounts the credits that the instances of Account Discount and of Discount objects specify. This task is referred to as macro 2. The macro processes accounts that are postpaid & whose "next discount date" (specified in account object) has got expired. Certain amount of money is credited to the MB as per the terms of discount configured. For details corresponding to postpaid discount, refer section chapter 17.3, "Discount Object", on page 616 Note: All OOC macros 0-7 need to be configured in "OOC Timeband" object. In case if they are required, set them "active" (i.e. green timeband) else set them inactive (i.e. red timeband). This is MANDATORY to avoid alarms "Object not found" with regard to respective OOC macro that hasn't been configured in "OOC Timeband object." MACRO 3: Attribution of Promotion Tool discounts and credits. This task is referred to as macro 3. For details corresponding to promotion tool, refer section chapter 17.5, "Promotion Tool Object", on page 651 Note: All OOC macros 0-7 need to be configured in "OOC Timeband" object. In case if they are required, set them "active" (i.e. green timeband) else set them inactive (i.e. red timeband). This is MANDATORY to avoid alarms "Object not found" with regard to respective OOC macro that hasn't been configured in "OOC Timeband object." MACRO 4: Issuing of Notifications About Accounts. This task is referred to as macro 4. This macro processes prepaid accounts that are,
Page 188 of 968
11 September 2009
- active & whose activity period has not yet expired, with either first/second activity period warnings not yet done. The notifications would be sent as per the configured "days before 1st/2nd activity end warning" parameter of account profile. - inactive & whose inactivity period has not yet expired, with either first/second inactivity period warnings not yet done. The notifications would be sent as per the configured "days before 1st/2nd inactivity end warning" parameter of account profile. For details corresponding to notifications, refer section chapter 5.1, "Notification Feature Table Object", on page 161. Note: All OOC macros 0-7 need to be configured in "OOC Timeband" object. In case if they are required, set them "active" (i.e. green timeband) else set them inactive (i.e. red timeband). This is MANDATORY to avoid alarms "Object not found" with regard to respective OOC macro that hasn't been configured in "OOC Timeband object." MACRO 5: Sending warning SMS to the user X days before (configurable arena parameter "nbrdayssmsendbucket" at Account profile) to warn about the nearby approaching expiration of his/her bucket. This task is referred to as macro 5. For this macro, use "N for warning act/inactive period" parameter specified in OOC Object for view creation. For details corresponding to "Warning SMS Bucket", refer section chapter 20.3.6, "Bucket with Warning SMS", on page 821. For further details, refer VELin64025.
Note: All OOC macros 0-7 need to be configured in "OOC Timeband" object. In case if they are required, set them "active" (i.e. green timeband) else set them inactive (i.e. red timeband). This is MANDATORY to avoid alarms "Object not found" with regard to respective OOC macro that hasn't been configured in "OOC Timeband object." MACRO 6: To barr an account at HLR Level after N number of days of inactivity start date (configurable arena parameter at Account profile). This task is referred to as macro 6. This macro finds accounts whose status is inactive & whose inactivity period has not yet expired, with tcblock value as 0 [i.e for which NEIF(HLR Barring) flag of account object is unchecked]. A LiteSCE hook point has been provided for module as "Lifecycle" ,connector as "all", where the treatment for barring needs to be carried out. Note: 1. 2. 3. No stats has been generated by creactor script for this new logic, if stats are required litesce will be responsible for that. No default OOC notification is sent in this new logic. It is the responsibility of litesce script to send the barring notification. It is the responsibilty of litesce script to set the ppm.tcblock flag [i.e. NEIF(HLR Barring) flag in account object]. Note: 4. 5. DDUP will be sent by creactor script.
No ddup will be sent in case of nok from litesce script i.e when allowed [root]= 0 in LiteSCE. To run this new logic, configure the sixth timeband in OOC timeband object. Note:
Litesce script needs to be invoked at refill also, to unbarr the account at HLR level.
11 September 2009
Page 189 of 968
For this macro, "N for warning act/inactive period" parameter specified in OOC Object would be used for view creation. Therefore, the parameter must be configured. For details corresponding to HLR barring, refer to VELin60137. Note: All OOC macros 0-7 need to be configured in "OOC Timeband" object. In case if they are required, set them "active" (i.e. green timeband) else set them inactive (i.e. red timeband). This is MANDATORY to avoid alarms "Object not found" with regard to respective OOC macro that hasn't been configured in "OOC Timeband object." MACRO 7: To provide dynamic functionality with the help of "SELECT" query configured by the user. This task is referred to as macro 7. In order to allow any generic query (dynamic query) to be processed by OOC, a new functionality "OOC Generic" has been added to the OOC Logic. For this, timeband corresponding to macro no.7 needs to be configured in OOC Timeband object. Implementaion Aspects Two new LiteSce hook points "OOC generic before" & "OOC generic" have been added in the "Generic OOC Logic". In order to play a dynamic query via OOC, a LiteSce needs to be created at the hook point "OOC generic before". The LiteSce should set the SQL query in the transient attribute "ooc_sql" of ooc_cfg object.
Query should have a format like: select distinct(p.RI), p.MSID, p.DYNUPDT from PPM_P::i p where (p.ri=::refresh_generic_range_min and p.ri< ::refresh_generic_range_max and (...)) Note:
i stands for partition number.
refresh_generic_range_min & refresh_generic_range_max denote the range of accounts to be processed at a time.

There is a provision for an additional placeholder "today" implying current date & time(i.e now). These place holders are prefixed with '::' & suffixed by a space(if they occur in b/w the query). These place-holders are later on replaced with appropriate values in the code. For example: A sample query to fetch all active or inactive accounts is as follows: "select distinct(p.RI), p.MSID,p.DYNUPDT from PPM_P::i p where (p.ri>=::refresh_generic_range_min and p.ri<::refresh_generic_range_max and (p.CYCLSTAT=chr(2) or p.CYCLSTAT=chr(3)))" For instance, with partition=1, refresh_generic_range_min=268435456 and refresh_generic_range_max=268445456, above all query will become "select distinct(p.RI), p.MSID,p.DYNUPDT from PPM_P1 p where (p.ri>=268435456 and p.ri<268436456 and (p.CYCLSTAT=chr(2) or p.CYCLSTAT=chr(3)))" Another example highlighting the use of place-holder "today" is as follows: "select distinct(a.RI), a.MSID, a.DYNUPDT from PPM_P::i a, SERVCLAS s where a.ri>=::refresh_generic_range_min and a.ri<::refresh_generic_range_max and a.SERVCLAS=s.RI
Page 190 of 968
11 September 2009
and ((a.CYCLSTAT=chr(1) and a.VALIDEND<::today ) or (a.CYCLSTAT=chr(2) and a.ACTIVEND<::today ) or (a.CYCLSTAT=chr(3) and a.INACTEND<::today ))" Note the space after the place holders. It is a must for correct parsing of query & proper creation of view. The query can be based upon any other table if required along with ppm (account). Since currently, deactive accounts are not processed by OOC. Therefore, the context variable "ooc_deactiv_4_generic [root]" should be set to 1 explicitly in the first LiteSce (i.e for the LiteSce configured at "OOC generic before") so as to enable processing of deactive accounts. (This was done as per requirement for VELin85129.) Therefore, OOC view is built depending upon the query placed in "ooc_sql" attribute of ooc_cfg object. Another LiteSce needs to be created at the hook point "OOC generic" for the treatment of accounts fetched in the above view. Configuration Aspects Configure RE Flexibility config instance for OOC Generic before with 3CL-02660-BAHA-PCZZA
LiteSce script as required Object class as config Module as OOC Generic before Connector as all Object Identifier as config
Configure RE Flexibility config instance for OOC Generic with LiteSce script as required Object class as config or servert or servclas or ppm Module as OOC Generic Connector as all Object identifier depends upon Object class
Two objects OOC and OOC timeband needs to be configured. - In OOC object, we need to specify N for generic OOC in the Prepaid OOC tab. - In OOC timeband object, configure timeband for macro7 Generic OOC. Note: 1. 2. 3. The generic OOC Logic sends DDUP for ppm(account) & credit only from creactor script. For other objects, DDUP needs to be sent from second liteSCE. Notifications would have to be created from second liteSCE but would be sent from creactor script. No ddup will be sent in case of nok from litesce script i.e when allowed [root]= 0 in LiteSCE. For further details, refer to VELin85129. Note: All OOC macros 0-7 need to be configured in "OOC Timeband" object. In case if they are required, set them "active" (i.e. green timeband) else set them inactive (that is,red timeband). This is MANDATORY to avoid alarms "Object not found" with regard to respective OOC macro that hasn't been configured in "OOC Timeband object." Note: Statistics buffer will be cleared in case of nok from liteSCE script that is, when allowed [root]= 0 in LiteSCE. For further details, refer to NAMin26010.
11 September 2009
Page 191 of 968
5.2.2.2. Macro 0
As the role of the out of call processing is to perform a number of tasks (which are called macros), the out of call processing is responsible for scheduling these tasks (i.e., these macros) as necessary. The CRE sees also the scheduling of these tasks (i.e., of these macros) as a task. This last task is referred to as macro 0.
5.2.3.
Configuring the Out Of Call Processing
5.2.3.1. Setting Up the Macros Timebands

Whenever you configure the out of call processing, you need to specify, for each task (i.e., macro) that you want to be performed by the out of call processing, during which period(s) of the day you want the task (i.e., the macro) to be performed. These periods of the day are called green timebands and you set them up by creating the necessary instances of the Out Of Call Timeband object, one instance per macro, including macro 0. These periods of the day are called green timebands because, in an instance of Out of Call Timeband object, you graphically set up them by drawing a green timeband for each of these periods of the day.
See also 5.2.5, Out of Call TimeBand Object, on page 198.
Beware that a macro other than macro 0 will be run by the out of call processing if, and only if:
You also set one or more green timebands for macro 0, and The green timebands for macro 0 encompasses (includes) all green the timebands of the macro. The green timebands you specify for a macro are daily timebands. That is, you can only specify the periods of the day during which the macro can run. As a result, the OOC will keep attempting every day to execute the macro as long as current time is in the green timebands.
See also 5.2.5, Out of Call TimeBand Object, on page 198.
5.2.3.2. Preventing OOC Processing to Work When CPU Load Is Too High
You can make the OOC delay its work on a SLEE in consequence of the CPU load of that SLEE being too high. You do that by suitably updating Maximum CPU Load (%) parameter of the unique instance of Out Of Call object. When the CPU load of a SLEE is above that parameter value, the CPU load of that SLEE is considered too high by the OOC.
See also 5.2.4, Out of Call Object, on page 194.
5.2.3.3. Sizing the Macro Runs

As long as macro 0 is active (i.e., as long as current time belongs to one of macro 0 green timebands) and as long as the CPU load of a SLEE is below Maximum CPU Load (%) parameter value (if CPU load gets higher at some moment, macro 0 will try to resume its work as soon as CPU load is again below the threshold), macro 0 keeps attempting to execute on the SLEE each of the other macros. Of course, the OOC processing will not attempt to run a macro if no green timeband exists for the macro or if the current time does not belong to one of the green timebands of the macro. Each macro run spawned by the OOC treats a limited number of Accounts.
Page 192 of 968
11 September 2009
The maximum number of Account instances that a macro run is allowed to process is specified by a given parameter of the unique instance of Out of Call object. The name of such a parameter always starts with letter N and is always followed by a blank and then by some text. Such a parameter is therefore hereby called a N parameter.
See 5.2.4, Out of Call Object, on page 194, for the exhaustive list of these N parameters.
For example, the maximum number of Accounts that a run of macro 2 is allowed to process is governed by N for Discount parameter of the unique instance of Out of Call object. That is, the N parameter of macro 2 is called N for Discount. As a result, you need to specify for each macro, that is other than macro 0 and that the OOC will run, the N parameter of the macro, since that N parameter indicates the maximum number of Accounts that a run of the macro is allowed to process. Of course, if no green timeband is set up for a given macro, the macro will never execute and you thus do not need to set N parameter of the macro to some value.
See also 5.2.4, Out of Call Object, on page 194.
At a time and per SLEE, the OOC only executes one macro run. Per SLEE, the OOC however schedules macro runs in turn. It does that as follows. As long as current time does not belong to a green timeband of macro 0, macro 0 (and thus the OOC) does not do any work. As long as current time belongs to a green timeband of macro 0, macro 0 keeps doing what follows per SLEE:
1. 2.
Macro 0 checks whether the currently considered macro (which is a macro other than macro 0) can be scheduled or not. If the macro can be scheduled, macro 0 launches a run of the macro. As soon as the macro run terminates (the macro run will at the latest terminate after it has processed a number of Accounts equal to the N parameter of the macro), macro 0 executes next step. Else, macro 0 directly proceeds to next step.
3. 4.
The next macro (which is a macro other than macro 0) becomes the currently considered macro. Macro 0 proceeds to step 1.
At time macro 0 wants to schedule a run of some macro, macro 0 do what follows: If current time does not belong to a green timeband of the macro to schedule, macro 0 concludes that the macro cannot be scheduled. Else, if the CPU load of the currently considered machine is higher than Maximum CPU Load (%) parameter of the unique instance of Out Of Call object, macro 0 concludes that the macro cannot be scheduled. Else, macro 0 concludes that the macro can be scheduled. A run of a given macro starts its work at the point where the previous run of the same macro stopped. For example, assuming that a given run of macro 1 processed N for Account State Management Accounts, the next run of macro 1 will process the next N for Account State Management. However, crossing midnight breaks this rule. That is, after midnight, the first run of a given macro on a SLEE restarts its work from the first Account that belongs to the active Account partitions of the SLEE. And thus not at the point where the previous run of the same macro stopped.
11 September 2009
Page 193 of 968
5.2.4.
Out of Call Object

There must be in your CRE one, and only one, instance of the Out of Call object. You use the unique instance of Out Of Call object: To indicate above which CPU load the out of call processing must delay its work, To size the runs of macros 1-7 that the out of call processing launches, To indicate which SEP group the out of call processing has to use. That is, you use the Out Of Call object for doing any out of call processing setup that is not macros timeband related. You carry out this latter kind of setup by means of the Out Of CallTimeband object.
5.2.4.2. Main Parameters
Figure 68 - Out of Call GUI
Table 54 - Out of Call - Main Parameters Parameter Name Description Name of the Out of Call object instance. You need to create one, and only one, instance of this object. Choose any name you want. Next sections document the other parameters.
Page 194 of 968
11 September 2009
5.2.4.3. OOC Tab
Figure 69 - Out of Call GUI - OOC Tab
Table 55 - Out of Call - OOC Tab

Parameter SEP Group Name
Description The name of the SEP group of the OOC. The OOC runs on the SLEEs. On a SLEE, the OOC is implemented as a SEP, which we hereby call the OOC SEP.
No more than one SEP of a given SLEE can implement the OOC on the SLEE.
The OOC SEP of a SLEE takes care of all the active Account partitions of the SLEE.

Max Range
The SEP group of the OOC cannot refer to more than one SEP of a given SLEE.
You need to choose for this parameter a value that is greater than the following parameters: N for Discount N for Bonus From Promotion N for Warning Act/Inactive Period N for Account State Management
Maximum CPU Load (%)
The OOC delays its work on a SLEE if that SLEE has its CPU load, expressed in percentage, above this parameters value.
11 September 2009
Page 195 of 968
5.2.4.4. Postpaid OOC Tab
Figure 70 - Out of Call GUI - Postpaid OOC Tab
Table 56 - Out of Call - Postpaid OOC Tab Parameter N for Periodic Fee N for Discount Not used. Maximum number of postpaid Accounts that a run of macro 2 processes. This is thus the N parameter of macro 2. Description
The value of this parameter must be less than Max range parameter value.
N parameter of a macro is.
Section 5.2.3.3, Sizing the Macro Runs, on page 192, explains what the
Page 196 of 968
11 September 2009
5.2.4.5. Prepaid OOC Tab
Figure 71 - Out of Call GUI - Prepaid OOC Tab
Table 57 - Out of Call - Prepaid OOC Tab

Parameter N for Pre-Defined Bonus N for Bonus From Promotion Not used.
Description
Maximum number of Accounts that a run of macro 3 processes. This is thus the N parameter of macro 3.
parameter of a macro is.
Section 5.2.3.3, Sizing the Macro Runs, on page 192, explains what the N
N for Warning Act/ Inactive Period Maximum number of Accounts that a run of macro 4, 5 or 6 processes. This is thus the N parameter of macro 4, 5 and 6.
parameter of a macro is.
Section 5.2.3.3, Sizing the Macro Runs, on page 192, explains what the N
N for Periodic Fee N for Account State Management Not used. Maximum number of Accounts that a run of macro 1processes. This is thus the N parameter of macro 1.
Section 5.2.3.3, Sizing the Macro Runs, on page 192.
11 September 2009
Page 197 of 968
5.2.4.6. Session OOC Tab
Figure 72 - Out of Call - Session OOC Tab

Table 58 - Out of Call - Session OOC Tab Parameter Timer Description Waiting period in milliseconds between two OOC macros processing. Standard value is 100ms. It can be increased to a higher value in case of SMS-C overload. Session OOC Activation N for Session Not used. Not used.
5.2.5.
Out of Call TimeBand Object

By means of an instance of this object, you indicate: The daily period of times during which the macro, that the instance is about, is active (i.e., is run by the OCC). Each such daily period of time, during which a macro is active, has to be specified by means of a green timeband. The daily period of times during which the macro, that the instance is about, is inactive (i.e., is not run by the OOC).
Page 198 of 968
11 September 2009
Each such daily period of time, during which a macro is inactive, has to be specified by means of a red timeband. For each macro, including macro 0, you need to create one, and only one, instance of Out Of Call Timeband object that refers to the macro. Then, in each of these instances, you set up the green timeband(s) during which you want the corresponding macro to be active. If you want that the macro is never active, set up no green timeband for it in the instance of Out of Call Timeband object for the macro. Note: If you do not set up for a given macro the unique instance of Out Of Call Timeband object that refers to it, the CRE will regularly issue alarm messages reminding you that the instance is missing. If you do not want to be bothered by these alarm messages, make sure that each macro has its unique instance of Out Of Call Timeband object.

Not yet done.
5.3.
5.3.1.
Tariff Tester Object

Object Purpose
This object enables you to check whether your Product Catalog, and thus your pricing, behaves as you expect. Note: The Tariff Tester object uses the CE SEP Group. Therefore, this latter needs to be configured in the RE Configuration object (it is usually set to ce20). Without doing this, the Tariff Tester will not be able to execute any tests. You use Community Engine parameter of Sep Groups tab of the unique instance of RE Configuration object to indicate which is the CE SEP group. See also Community Engine, on page 85. Note: On the Product Catalog, see chapter 9., "Catalog Structure", on page 259. You do that by simulating RTx requests to the CRE, and by then checking the simulation results. In fact, everything happens as if you were yourself an RTx: You fill in an RTx request, then give it to the CRE for execution, and, finally, check the execution results the CRE returns to the RTx (that is, to you). Note: While you use the Tariff Tester, you will need to refer times to times to the following document, which describes the API and thus the data, the so-called RTx requests, the result codes, the EDRs that the RTxses use in order to interact with the CRE: ALCATEL 8618 Convergent Rating Engine 2.0 South API Specification, 3BL 45180 DAAA PBZZA, Edition 01 or Higher. Be sure you have this document at hand while you use the Tariff Tester. You can only simulate the following types of RTx requests: One-shot RTx requests, Top-up RTx requests. Whenever you simulate a one-shot RTx request, you receive the following kind of information from the simulation: What service offer has been used, What Usage Rating Rule has been used,
11 September 2009
Page 199 of 968
What tariff has been applied, Whats the resulting price. On the other hand, whenever you simulate a top-up RTx request, you learn from the simulation things like: What top-up rules have been used, What balances were impacted, To which extent were the balances impacted. To simulate an RTx request, do the following steps, in the order they are numbered: 1. Prepare the RTx request you want to simulate. For doing that, prepare a Tariff Tester instance, either by creating a new one or by using an existing one. Ensure that the instance suitably describes the RTx request you want to simulate. Its the following tabs of the instance that describe that RTx request. Config Basic Quantities (one-shot RTx requests only) Zoning (one-shot RTx requests only) Top Up (top-up RTx requests only).
2.
Simulate the RTx request. Now that the RTx request is ready (i.e. the Tariff Tester instance is ready), perform the simulation. To perform the simulation, do one of the following: Click on EXECUTE button, of which the figure below shows an example, and which appears in the menu bar, to the right of REMOVE button.
Figure 73 - Tariff Tester GUI - EXECUTE Button Select execute from the tariftst drop-down menu.
Figure 74 - Tariff Tester GUI - Drop Down Menu
Page 200 of 968
11 September 2009
Thus, if you are creating a new Tariff Tester instance, fill in these tabs suitably. Otherwise, if you are using an existing one, check whether these tabs have correct values, and update them if that is necessary.
3.
Analyze the simulation results. To do that, take knowledge of what the following Tariff Tester instance tabs display: Result Adv Result
5.3.2.
Figure 75 - Tariff Tester GUI Table 59 - Tariff Tester - tariftst Parameter

Description Enter here the name of the service retailer of which the product catalog is going to be tested. If you are creating a new Tariff Tester instance, enter here a new Test ID value. If you are wanting to use an existing Tariff Tester instance, click on the button to the right of the entry field and then choose a Test ID from the list that is then displayed. A Test Id value is a character string.
Service Retailer
aasrvret
Test ID
tstid
Config, Basic Parameters, Quantities, Zoning, Top Up Criteria Result
You use the Config, Basic, Quantities, Zoning and Top Up tabs to prepare the RTx request that you will submit to the CRE. A number of tables below explain these tabs.
This tab is not available. Result tab gives you an overall view of the simulation results. One of the tables below explains this tab.
Adv Result
Adv Result tab provides a detailed view of the simulation results: It displays the content of the EDR that the simulation produced, one EDR event per line the tab shows. One of the tables below explains this tab.
11 September 2009
Page 201 of 968
Figure 76 - Tariff Tester GUI - Config Tab
Page 202 of 968
11 September 2009
Table 60 - Tariff Tester - Config Tab Parameter Requests Type*

reqtyp
Description Specify here the type of the RTx request you want to simulate. You choose between: One-Shot (reqtyp = 0) If you choose this, Top-Up tab becomes unavailable (it becomes greyed), and the RTx request will be processed by oneshot connector. immediate call flag (net_evt.immcall) = 0 , Implies immediate call, history of the subscription should not be analyzed Top-Up (reqtyp = 1) If you choose this, Quantities and Zoning tabs become unavailable (they become greyed), and the RTx request will be processed by credupdreq connector. immediate call flag (net_evt.immcall) = 0 , Implies immediate call, history of the subscription should not be analyzed One-Shot Offline(reqtyp = 2) If you choose this, Top-Up tab becomes unavailable (it becomes greyed), and the RTx request will be processed by oneshot connector. immediate call flag (net_evt.immcall) = 1, Implies the call is not immediate, this means the subscription history should be analysed. Top-Up Offline (reqtyp = 3) If you choose this, Quantities and Zoning tabs become unavailable (they become greyed), and the RTx request will be processed by credupdreq connector. immediate call flag (net_evt.immcall) = 1, Implies the call is not immediate, this means that the subscription history should be analysed.t
Interface Time Out*

msgtout
Indicate here the time interval, in seconds, within which you expect the simulation to complete. If the simulation execution takes longer, you get no result. This must be an unsigned integer value. It does not make sense to enter 0 here. Since that would mean it is expected the simulation will complete in zero seconds and since this is clearly not possible. Maximum value is 65535.
11 September 2009
Page 203 of 968
Table 60 - Tariff Tester - Config Tab Parameter EDR

tckext
Description Indicate here whether the CRE has to send to not to external module(s) the EDR that the simulation produces. This entry field corresponds to stext_f field of the RTx request that is being simulated. You choose between: None (tckext = 0) This sets stext_f field of the RTx request to 1. That means that the RTx request forbids the CRE to hand over to external module(s) the CE EDR and the RE EDR the simulation produced. Thus, the EDR remains inside the CRE. This is the default value. External Module (tckext = 1) This sets stext_f field of the RTx request to 2, which means that the CRE must hand over to external module(s) the CE EDR and the RE EDR that the simulation produced.
save_flg
You choose between: No (save_flg = 0) The results of the simulation wont be saved into the database. This is the default. Yes (save_flg = 1) The results of the simulation will be saved into the database.
The value of this parameter is never stored into the database. Therefore, before you start executing a simulation, always ensure that this parameter is set as you want.
Page 204 of 968
11 September 2009
Save Result After Execution
Indicate here whether you want the results of the simulation to be saved into the database or not.
Figure 77 - Tariff Tester GUI - Basic Parameters Tab
11 September 2009
Page 205 of 968
Table 61 - Tariff Tester - Basic Parameters Tab Parameter Key Type*

ppmindex
Description An RTx that you simulate is either about a Customer or about an Account. In the RTx request, the Customer/Account is indicated by means of two parameters: ppmindex and ppmvalue. This parameter indicates the value of ppmindex parameter of the RTx request to simulate. As a result, together with Key* parameter, this parameter indicates which Customer/ Account the RTx request to simulate is about. Indicate here whether a Card Number (ppmindex = 1), or an MSID (ppmindex = 2), or an Identifier (ppmindex = 3), or a Customer ID (ppmindex = 4) will be used to retrieve from the CRE database the Customer/Account of the RTx request that is being simulated.

Both Customers and Accounts may have a Card Number, an MSID, an Identifier. On the other hand, only Customers have a Customer ID. On Accounts Card Number , see Card Number*, on page 751. On Customers Card Number, see Card Number, on page 892. On Accounts MSID, see MSID*, on page 755. On Customers MSID, see MSID, on page 891. On Accounts Identifier, see Identifier (Login), on page 750. On Customers Identifier, see Identifier (Login), on page 891. On Customers Customer ID, see Client Identifier*, on page 889.
Page 206 of 968
11 September 2009
Table 61 - Tariff Tester - Basic Parameters Tab (continued) Parameter Key*

ppmvalue
Description In the RTx request, the Customer/Account is indicated by means of two parameters: ppmindex and ppmvalue. This parameter indicates the value of ppmvalue parameter of the RTx request to simulate. As a result, together with Key Type* parameter, this parameter indicates which Customer/ Account the RTx request to simulate is about. The value you enter here will be used to retrieve from the CRE database the Customer/Account of the RTx request to simulate. This must be either a card number value, or an MSID value, or an identifier value, or a customer ID value depending on whether Key Type is set, respectively, either to Card Number, or to MSID, to Identifier, or to Customer ID.
Which Product Catalogs instances versions the simulation uses depends on whether the retrieved Customer/Account is a test one or not. If the retrieved Customer/Account is a test one, the simulation will always prefer to use a Product Catalogs instance version that is in test (i.e. that is either Test-Active or Test-Inactive) over a version of the same instance that is not in test. That is, it will use an instance version that is either Active or Inactive only if it could not find either a Test-Active or Test-Inactive version of the same instance. If the retrieved Customer/Account is not a test one, the Product Catalogs instances that the simulation considers are either Active or Inactive ones. A test Account is one that has its Operator Specific Account flag checked. A test Customer is one that has its Version* parameter set to Test.

See also Operator Specific Account, on page 756. See also Version*, on page 885. See also chapter 11., "Versioning", on page 324.
Event Type*
calltype
Enter here the network event type you are wanting to play. For that, click on the button that is to the right of this entry field, and pick the event type from the list that then shows up.
11 September 2009
Page 207 of 968
Table 61 - Tariff Tester - Basic Parameters Tab (continued) Parameter Event Date*
calldate
Description Specify here the processing date you want to simulate. The Tariff Tester will process the RTx request as if it happened at the date that Event Date specifies.
Format: See Table 4, Entry Fields Data Types, on page 36.
Playing with the Event Date and with the Event Time values enables you to test different versions of the same object instance. See also chapter 11., Versioning, on page 324.
Event Time*
calltime
Specify here the processing time you want to simulate. The Tariff Tester will process the RTx request as if it happened at the time that Event Time specifies.
Format: See Table 4, Entry Fields Data Types, on page 36.

First Call Management
fcallmgt
Indicate here whether the RTx request is one of a first call or not. If it is, some related additional processing will be done by the simulation too. This corresponds to firstcal field of the RTx request that is being simulated.
You choose between: No (fcallmgt = 1) No additional processing related to first calls will be simulated. This is the default. Yes (fcallmgt = 0) The related first call additional processing will be simulated.
Figure 78 - Tariff Tester GUI - Quantities Tab
Page 208 of 968
11 September 2009
Table 62 - Tariff Tester - Quantities Tab Parameter First RUM*

qt2resv1
Description Enter here a quantity. It is expressed in terms of the units of the first RUM of the simulated network event type. It must be a positive integer number. 0 is rejected.
Second RUM
qt2resv2
If the simulated network event type has a second RUM defined, enter here a quantity. It is expressed in terms of the units of that second RUM. It must be a positive integer number. 0 is rejected. There is no default value.
Third RUM
qt2resv3
If the simulated network event type has a third RUM defined, enter here a quantity. It is expressed in terms of the units of that third RUM. It must be a positive integer number. 0 is rejected. There is no default value.
Figure 79 - Tariff Tester GUI - Zoning Tab
Table 63 - Tariff Tester - Zoning Tab Parameter Calling

clg
Description This corresponds to clg field of the RTx request that is being simulated.
Origin Type
origtype
This corresponds to origtype field of the RTx request that is being simulated.
Origin
origmc
This corresponds to origmc field of the RTx request that is being simulated.
11 September 2009
Page 209 of 968
Table 63 - Tariff Tester - Zoning Tab Parameter Origin Search Algorithm

origalgo
Description This corresponds to origalgo field of the RTx request that is being simulated. You can choose between: Old Mode (origalgo = 0) Exact Match (origalgo = 1) This is the default value. Greatest Match from left to right(Min, Max) (origalgo = 3) This choice reads as follows: Greatest match from left to right, with a minimum and a maximum number of matching characters.
See also section 16.6.3, Area Identification Match Algorithms, on page 583.
Called*
cld
This corresponds to cld field of the RTx request that is being simulated.
Destination Type
desttype
This corresponds to desttype field of the RTx request that is being simulated.
Destination
destmc
This corresponds to destmc field of the RTx request that is being simulated.
Destination Search Algorithm

destalgo
This corresponds to destalgo field of the RTx request that is being simulated. You can choose between: Old Mode (destalgo = 0) Exact Match (destalgo = 1) This is the default value. Greatest Match from left to right(min, max) (destalgo = 3) This choice reads as follows: Greatest match from left to right, with a minimum and a maximum number of matching characters.
See also section 16.6.3, Area Identification Match Algorithms, on page 583.
Page 210 of 968
11 September 2009
Figure 80 - Tariff Tester GUI - Top Up Tab
Table 64 - Tariff Tester - Top Up Tab Parameter Top-Up Profile*

topprof
Description This corresponds to profID field of the RTx request that is being simulated.
Profile Ratio
profrat
Not used.
Note: The tab Criteria is not used.
11 September 2009
Page 211 of 968
Figure 81 - Tariff Tester GUI - Result Tab
Parameter Last Execution Date

lstdate
Description Whenever you execute a simulation, this read-only field is updated with the date and time of that simulation. This is the date and time at which the simulation completed. This is a read-only unsigned integer value. Its a code that summarizes the results of the last executed simulation. For example, if the last simulation succeeded, this field displays the following value: 1.
Result Code
rescode
Presents a read-only short text that explains the meaning of the result code displayed just above. To give an example, if result code is set to 1, the following text appears just below Result Code text: OK. If no result code value is available (as is the case as long as no simulation has been done), a question mark is displayed.
Sub Result Code

resc_sub
This is a read-only unsigned integer value. Its a code that refines the test results. For example, if the test succeeds, this field displays the following value: 1.
Page 212 of 968
11 September 2009
Table 65 - Tariff Tester - Result Tab
Table 65 - Tariff Tester - Result Tab (continued) Parameter ? Description Presents a read-only short text that explains the meaning of the sub result code displayed just above. If no sub result code value is available (as is the case as long as no simulation has been done), a question mark is displayed. To give an example, if sub result code is set to 1, the following text appears just below Sub Result Code text: OK.
Figure 82 - Tariff Tester GUI - Adv Result Tab
11 September 2009
Page 213 of 968
Table 66 - Tariff Tester - Adv Result Tab Parameter Parameter Description Each row this tab shows displays a Parameter field. This is a read-only field, which displays the description of one of the events that the EDR resulting from the simulation contains, followed by the feature, the subfeature, the type and the sub-type of the event. This information is displayed in the following form:
event-description(feature, sub-feature, type, sub-type)

The figure below shows an example of this:
Figure 83 - Adv Result Tab Parameter Example The row the above figure shows is about the following EDR event: Correlation ID EDR event. The feature, the sub-feature, the type and the sub-type of this EDR event are, respectively: 100, 2, 1 and 26. Value Each row this tab shows displays a Value field. This is a read-only field, which displays the value of the EDR event that the Parameter field from the same row describes.
Page 214 of 968
11 September 2009
5.4.
5.4.1.
Statistic Cycle Object

Object Purpose
This object, provides information on the total credit on the accounts (remaining, used and lost credit), or on the state of the accounts and the account profiles . It is used to create an Account statistic and get a snapshot of the database at a given time.
5.4.2.
Table 67 - Statistic Cycle Object Parameter Description Parameter Service Retailer*

servret
Description Service retailer reference.
Name
st_name
Name of the statistics.
Nb of accounts activated this day

nbsb_atd
Number of subscriber activated on this day
11 September 2009
Page 215 of 968
Parameter Nb of accounts in Blocked state

nbsb_ibs
Description Number of accounts in blocked state.
Nb of accounts in Deactivated state

nbsb_ids
Number of accounts in deactivated state.
Nb of accounts Inactivate state

nbsb_iis
Number of accounts in inactive state.
Nb of accounts in Valid state

nbsb_ivs
Number of accounts in valid state.
Nb of accounts in Reload Suspended state

nbsb_rss
Number of accounts in reload suspended state.
nbsb_as
Total number of prepaid accounts

tnb_prsb
Total number of prepaid accounts
Financial Statistic Total lost credit Total main balance for Prepaid account Total main balance for Postpaid account Financial Statistic per profile
Financial statistic gives the information about the parameters name associated with the account profile of that service retailer Total number of lost credit when the account is inactive Total main balance for prepaid accounts
Total main balance for postpaid account
If service retailer has multiple account profile then in drop down box a particular account profile is selected and information of all the parameters related to that account profile are listed. The following attibutes are list once the account profile is selected: Total remaining credit for profile Total number of subscribers Usage Name Total Bundle Units
Page 216 of 968
11 September 2009
Nb of accounts in Active state
Number of accounts in active state.
Parameter Total remaining credit for profile

torcf000
Description Total remaining credit for profiles
Total number of subscribers

tonbs000
Total number of subscribers
Usage Name
usagname
Usage name associated with each profile
Total Bundle Units

tousgamt
Total bundle unit for a usage
11 September 2009
Page 217 of 968
Part III. Product Catalog
Page 218 of 968
11 September 2009
6. Service Identification
When the Convergent Rating Engine is triggered by an event, it receives: a Network Event Type a user identifier (Customer or Account) From these two pieces of information, the Convergent Rating Engine must be able to identify the Service that is triggered. The Service Identification is initially performed by a match found between the Network Event Type and the name of a Service, as defined in the Network Event Type object. This is the standard Service Identification process. However, the Convergent Rating Engine allows redefining the Service, for a more sophisticated approach of the Service offering in the Product Catalog. For each Commercial Offer, the Service initially identified thanks to the Network Event Type can be modified thanks to the first (optional) decision tree of the Product catalog: the Service Rule. Thanks to this tool, the notion of Service can be detached from the network service, in order to become any feature offered by the Service Provider. For more details about the Service, see section 9.2, "Service Object", on page 260.
6.1.
Network Event Type object

Object Purpose
6.1.1.
The Network Event Type is a piece of information passed by the RTx, which the aim of is to reflect the type of event occurring on the network. The Convergent Rating Engine is asked to perform a rating/ charging operation for that specific event. The Network Event Type Defines, for a specific type of event, the Ratable Unit Metric(s) according to which it has to / can be rated and charged; Establishes the one-to-one equivalence between the integer and character string formats of the event type info sent by the RTx; Is used by the Event Type Criterion of the various decision trees of the Convergent Rating Engine; Allows identifying the Service triggered, for which a Service Offer needs to be found in the Product Catalog. One Network Event Type matches a single Service, but several Network Event Types can match the same Service. For instance, MOC and MCT each match the Voice Service.
11 September 2009
Page 219 of 968
Service Identification
6.1.2.
Figure 84 - Network Event Type GUI
Table 68 - Network Event Type - evt_typ Parameter Service Retailer

aservret
Description Reference to the Service Retailer defining the current Network Event Type. Reference to the Service that is identified when the current Network Event Type is sent to the Convergent Rating Engine. This Service can potentially be redefined by the Service Rule of the users Commercial Offer.
Service*
serv_ri
Page 220 of 968
11 September 2009
Table 68 - Network Event Type - evt_typ Parameter Event Type Name*

name
Description Name of the current Event Type, corresponding to the info in character string format, sent by the RTx. Examples: MOC, MOSMS,... The RTx may actually send the Network event Type info in a character string format only OR in an integer format only (which has exactly the same meaning) OR in a character string and an integer format (redundant information). The Event TYpe Name is the parameter used in the Event Type Criterion, available in all decision trees of the Convergent Rating Engine. Since that criterion requires a character string format, a translation has to be done if the RTx sends the info in integer format only. Thats why both the Event Type Number and the Event Type Name are mandatory attributes.
Event Type Number*

type_nbr
Number of the current Event Type, corresponding to the info in integer format, sent by the RTx. Example: 100 (= MOC),... Event Type Number cannot have a value 0, which is its default value. Value 0 is not allowed for this field typ_nbr.
For more details, see parameter Event Type Name* above.
11 September 2009
Page 221 of 968
Table 68 - Network Event Type - evt_typ Parameter Default Reservation Lifetime

lifetime
Description Number of seconds that a reservation for the current Network Event Type lasts at maximum. Beyond that lifetime, the reservation is considered out-of-date and the reserved quantities are released. So, whatever the RUM(s) associated with the current Network Event Type, the quantities of those RUMs potentially reserved for such an Event will remain reserved for this limited period of time. Functionality The aim of this parameter is to adapt the duration of the reservation to the Network Event Type (that is say to the Service). For instance: For a Voice Network Event Type, it is most likely meaningless to keep the reserved quantities for a long time, the Service has to be delivered in real-time. If 5 minutes reserved havent been used after 5 minutes, then it probably means that the Service has been disrupted.
For a Data Download Network Event Type though, it is probably safe to keep the reserved quantities during quite a long time, because the Service is not a realtime one. The complete download of 15 MB may take a variable amount of seconds, depending on several parameters. Pay attention Dont get confused with the Default Reserved Quantity, which is an attribute of the RUM object and specifies the number of units reserved by default for the current RUM.
Figure 85 - Network Event Type GUI - Description tab
Page 222 of 968
11 September 2009
Table 69 - Network Event Type - Description tab Parameter Description

evt_desc
Description Description and comments about the current Network Event Type.
Figure 86 - Network Event Type GUI - RUM tab
Table 70 - Network Event Type - RUM tab Parameter RUM 1*

rum_nam0
Description Reference to the (first) RUM applicable to the current Network Event Type.
Pay attention
The RUM order here (1, 2, 3) has a high importance. In case of multiple rating process (i.e. if the event is rated according to more than one RUM), the quantities passed in an array of the DPE message from the RTx will be sorted in the order defined here. Consequently, bear in mind that he RUM order specified in the Network Event Type will have to be the same in the Tariff instances created for that event type. RUM 2
rum_nam1
Reference to the second RUM applicable to the current Network Event Type. Reference to the third RUM applicable to the current Network Event Type.
RUM 3
rum_nam2
11 September 2009
Page 223 of 968
6.2.
6.2.1.
Service Rule object

Object Purpose
6.2.1.1. Why Service Rules?

Each event sent by the RTx in the trigger message is automatically translated into a given Service (which is hereby called the initial Service). Note: The CRE finds out the initial Service thanks to the instance of Network Event Type object that corresponds to the Network Event Type of the event. An event is always processed in the context of a Commercial Offer, which is hereby called the current Commercial Offer. Finding which Service is associated with the event that is being processed enables the CRE to locate in the current Commercial Offer which Service Offer will govern the processing of the event in the context of that Commercial Offer: A Service Offer is always associated with a given Service and never with a given Network Event Type. However, before the CRE starts locating the Service Offer in the current Commercial Offer, you may want that the CRE translates the initial Service, of the currently processed event, into another Service. That way, the CRE will use that latter Service, and not the initial one, to locate the Service Offer, of the current Commercial Offer, that will govern the processing of the event (in the context of the current Commercial Offer).
On why you may want that behavior, see the examples of section 6.2.1.2, Typical Service Rules Example, on page 224.
If you want such a behavior, you need to suitably set up and associate a Service Rule with the current Commercial Offer. A Service Rule is the mechanism by which the initial Service can be translated into another Service. The Service Rule of the current Commercial Offer is executed after the current event has been translated to its initial Service (this happened thanks to Network Event Type object) and before the CRE starts locating in the current Commercial Offer the Service Offer that will govern the processing of the event in the context of the current Commercial Offer. The Service to which the Service Rule translated the initial Service is then used to locate which Service Offer will be used for processing the current event. Of course, when no Service Rule is associated with the current Commercial Offer, its the initial Service that is used to locate the Service Offer. Important - When the Service Offer that governs the processing of the current event is not located using the initial Service of the event, no part of the processing that the Service Offer governs is able to refer to that initial Service. Said in another way, as long as the processing of an event is governed by the same Service Offer in the context of the same Commercial Offer, the only Service known by the event processing is the Service on which the Service Offer is based and that was thus used to locate the Service Offer. Note: A Service Rule is an optional attribute of the Commercial Offer, by means of which a custom Service definition can be set up inside that particular Commercial Offer.
6.2.1.2. Typical Service Rules Example

Here below a few examples illustrating the purpose of Service Rules:
Page 224 of 968
11 September 2009
As a first example and assuming that a Mobile Originating Call event was translated to a Voice initial service, you might want that Voice service be translated into a Voice Peak Service when between 8:00 AM and 5:00 PM and into a Voice Off Peak Service otherwise. To achieve such a result, you would set up a Service Rule that suitably uses a Time Criterion. Naturally, setting up such a Service Rule implies that you need to set up, in any Commercial Offer associated with the Service Rule, a Service Offer based on Voice Peak Service and another one based on Voice Off Peak Service. On the other hand, setting up in the Commercial Offer a Service Offer based on Voice Service is then useless, since Voice Service will never be used to look up the Service Offer in the Commercial Offer. As a second example and still assuming that a Mobile Originating Call event was translated to a Voice initial service, you might want that Voice initial service be translated into either a Voice National Service or a Voice Roaming Service. You would achieve such a result by setting up a Service Rule that uses an Origin criterion that checks whether the event is from the home country or not. In this case too, setting up such a Service Rule implies that you need to set up, in any Commercial Offer associated with the Service Rule, a Service Offer based on Voice National Service and another one based on Voice Roaming Service. On the other hand, setting up in the Commercial Offer a Service Offer based on Voice Service is then useless, since Voice Service will never be used to look up the Service Offer in the Commercial Offer. As a final example and keeping assuming that a Mobile Originating Call event was translated to a Voice initial service, you might want that Voice initial service be translated into either a Voice Week Service or a Voice Weekend Service. You would achieve such a result by setting up a Service Rule that suitably uses a Date Criterion. As highlighted in the previous examples, setting up such a Service Rule implies that you need to set up, in any Commercial Offer associated with the Service Rule, a Service Offer based on Voice Week Service and another one based on Voice Weekend Service. On the other hand, setting up in the Commercial Offer a Service Offer based on Voice Service is then useless, since Voice Service will never be used to look up the Service Offer in the Commercial Offer.
11 September 2009
Page 225 of 968
6.2.2.
Figure 87 - Service Rule GUI Table 71 - Service Rule - servrule Parameter Service Retailer*
aservret
Description Reference to the Service Retailer defining the current Service Rule. Name of the current Service Rule.
Service Rule Name*

name
Calendar*
cal_ref
Reference to the Calendar valid for the current Service Rule. So, within this decision tree, the Date Criterion will allow referring to the Day Types defined in this Calendar. Name of the Version of the current Service Rule.
Version
version
For a detailed explanation of the Product Catalog versioning,

please see chapter 11., "Versioning", on page 324.
Start Date
vstartd
Date at which the Version as mentioned above for the current Service Rule reaches the status defined below.
Page 226 of 968
11 September 2009
Table 71 - Service Rule - servrule Parameter Status

vstatus
Description Versioning status that the current Service Rule Version reaches at the Start Date. Before that date, the current Version remains in its previous Status. After that date, the current Version holds the current Status until no other Status has started.
6.2.3.
Making Up a Service Rule
You implement a Service Rule as a decision tree. To know how you implement a rule as a decision tree, and have an example, see chapter 12., "Decision Trees", on page 329. A decision tree is made up of criteria and leaves.
6.2.3.1. The criteria

To know what criteria are available when making up a Service Rule, and have details about them, please see section 12.3, The Criteria, on page 378. Note: Counters are not used/updated/supported in the LiteSCE criterion of Service Rule. Counters can not be used in Service Rule. Counters can be managed only on RE and not on CE, but Service Rule will be triggered on CE20 or RE.That is why no Counter Related Criterions are available in the service rule.
6.2.3.2. The Leaves

A Service Rule returns: Service leaf, which references the identified Service Allowed leaf ,the allowed leaf works same as it works in the topup rule. See chapter 12.4.3, "Allowed Leaf", on page 472 Forbidden Leaf Note: To know more about these leaves, and have details about them, please see section 12.4, "The Leaves", on page 468
11 September 2009
Page 227 of 968
Types of Service Offers
7. Types of Service Offers
In a Nutshell... The Convergent Rating Engine can be triggered by three types of events: usage events, non-usage events and top-up events. The processing of all these events is predefined in the Product Catalog, thanks to Service Offers of three possible types. Whatever their types, the events triggering the Convergent Rating Engine can always be flexibly rated, and can affect the main balance and/or the Bundles of any Account.
Page 228 of 968
11 September 2009
7.1.
Service Types based on the Events Characteristics
In the Convergent Rating Engine, there are three types of Services. The type of a given Service depends on the characteristics of the events triggering that particular Service. For each type of Service, there is a different way to define the Service Offers of the Product Catalog. The figure 88 below shows a summary of the Service types classification, based on the events characteristics.
Event initiated by the user?
yes
no
Account debited?
At a predictable time?
yes
no
yes
no
usage
top-up
Recurrent?
non-usage
yes
no
non-usage scheduled recurring
non-usage scheduled discrete
Figure 88 - Service types, based on the events characteristics
7.1.1.
Usage Events
We talk of a Usage Service if the events matching that Service are always initiated by the user himself, at an unpredictable time. In general, a Usage Service represents the use that the subscriber makes of the network, like sending an SMS, making a voice call, downloading data, etc. The usage events are always rated according to a Tariff. Their cost is charged on the users Account. A Service Offer of type Usage provides a Tariff, by means of a decision tree called Usage Rating Rule. See 7.2, Usage Rating Rule object, on page 232.
7.1.2.
Non-usage Events
We talk of a Non-usage Service if the events matching that Service dont come from the network, initiated by the user. The events are typically generated by the CRE system itself, via its sub-module called Scheduling Engine. The non-usage events can
11 September 2009
Page 229 of 968
either have a cost, charged on the users Account, or increase in value the users Account, or do both, i.e. charge and top-up the users Account. A Service Offer of type Non-usage is defined by a Service Offer Definition, which specifies:
1.
2. 3.
the moment of the events - punctual or recurring,

the type of operation on the Account - debit or credit, and the amount of the transaction - either a fixed cost, or a Tariff selected thanks to a decision tree, or a Top-up Profile.
See 7.3, Service Offer Definition object, on page 235.
7.1.2.1. Discrete non-usage events

Discrete non-usage events occur only once. The moment at which a discrete non-usage event occurs may be planned in advance; it is then called a scheduled event. A discrete non-usage event may also be generated by the CRE at some threshold trespassing or status change. For example, consider the case of a cancellation fee that the user must pay when he cancels his Subscription before the initially-foreseen term. In such cases, the discrete non-usage event can often still be considered scheduled (at very short term or maybe even in the past), to the extent that this event is initiated by the Scheduling Engine as well, which guarantees that it will be processed once and only once.
7.1.2.2. Recurring non-usage events

A non-usage event can also be designed for occurring at regular intervals; it is then called a recurring event. They are always initiated by the Scheduling Engine. The recurring events typically represent the periodic fees that the Service Provider applies to the user, generally for the delivery of a Usage Service. For instance, a non-usage event can be the monthly fees to be paid for the access to the Voice Service.
7.1.3.
Top-up Events
We talk of a Top-up Service if the events matching that Service are initiated by the user, via the network or via a management interface of the Convergent Rating Engine. These events represent an increase in value of the users Account, typically at occasional reload of a prepaid account, but also at invoice payment, or at reception of any kind of bonus. These events are rated according to a flexible Top-up Profile, defined in the Convergent Rating Engine and/or provided by an external module. A Service Offer of type Top-up is defined by a Top-up Rule, which specifies whether the attempted Topup operation is allowed or not on the target Account. See 7.4, Top-up Rule object, on page 252. The type of triggering events is specified in the Service Offer object, by means of the following check boxes: Usage Rating Rule check box, if the service is of type Usage, Top-Up Rule check box, if the service is of type Top-Up. Service Offer Definition check box, if the service if of type Non-usage.
Page 230 of 968
11 September 2009
For more details on the Service Offers and the global Product Catalog, see 9., Catalog Structure, on page 259.
11 September 2009
Page 231 of 968
7.2.
7.2.1.
Usage Rating Rule object

Object Purpose
A Usage Rating Rule is a decision tree that aims at finding out the information enabling the CRE to rate the current network event quantities, provided that network event is of type Usage. A Usage Rating Rule always runs on a given Account, which is called the current Account of the rule. It is called by the CRE at time it needs either to charge the Account or to reserve some quantities on the Account. In its simplest form, the goal of a Usage Rating Rule is to identify the Tariff to apply to the main balance of the current Account. Moreover, if the current Account has Bundles (quantity-based sub-balances of the Account) and if the Usage Rating Rule is using the Bundle criterion, the Usage Rating Rule might also return to the CRE a list of Bundles, specifying for each bundle which part of the current network quantities the bundle is able to pay with which tariff.

See also 12.3.3, Bundle Criterion, on page 387. See also 12.2.1, Creating a Decision Tree, on page 333.
Page 232 of 968
11 September 2009
7.2.2.
Figure 89 - Usage Rating Rule GUI
Table 72 - Usage Rating Rule - pricplan Parameter Service Retailer*

aservret
Description Reference to the Service Retailer defining the current Usage Rating Rule.
Rating Tree Name*

name
Name of the current Usage Rating Rule.
Calendar*
cal_ref
Reference to the Calendar valid for the current Usage Rating Rule. So, within this decision tree, the Date Criterion will allow refer to the Day Types defined in this Calendar. Name of the Version of the current Usage Rating Rule.
Version
version
For a detailed explanation of the Product Catalog versioning, please see chapter
11., "Versioning", on page 324.
11 September 2009
Page 233 of 968
Table 72 - Usage Rating Rule - pricplan Parameter Start Date

vstartd
Description Date at which the Version as mentioned above for the current Usage Rating Rule reaches the status defined below. Versioning status that the current Usage Rating Rule Version reaches at the Start Date. Before that date, the current Version remains in its previous Status. After that date, the current Version holds the current Status until no other Status has started.
Status
vstatus
7.2.3.
Making Up a Usage Rating Rule
You implement a Usage Rating Rule as a decision tree. A decision tree is made up of criteria and leaves.
See chapter 12., "Decision Trees", on page 329.

The criteria available in a Usage Rating Rule are listed and explained in 12.3, The Criteria, on page 378.
7.2.3.2. The Leaves

A Usage Rating Rule returns: Either a Tariff leaf, which references a Tariff. See 12.4.5, Tariff Leaf, on page 474. Or a Usage Rating Rule leaf, Or a Forbidden Leaf.
See detailed description in 12.4, The Leaves, on page 468.
Page 234 of 968
11 September 2009
7.3.
7.3.1.
Service Offer Definition object

Object Purpose
A Service Offer Definition defines all the parameters of a Service Offer of type non-usage. Such a Service Offer implies to have the Convergent Rating Engine triggered by non-usage events that are either scheduled or subdued to the life cycle of a Subscription. The Service Offer Definition specifies all the parameters that enable the Convergent Rating Engine to process those non-usage events. This processing may include: cost computation, via a Usage Rating Rule; balance management (charge and/or top-up); Subscription management (activation, suspension, re-activation, termination); Account Life Cycle management (due to Top-up operations); event processing management (communication from the Convergent Rating Engine to the Scheduling Engine about the success of the previous events processing, and what to do next); recurrence management (calculation of the next occurrence of the non-usage event, as an instruction to the Scheduling Engine). The Service Offer Definition generically defines all the events of a non-usage Service Offer, as available in the Product Catalog. In addition, if you want to see the status of a particular Scheduled Event, at a particular moment, for a particular user, then you should have a look at the Scheduled Event object, as part of the users portfolio. For a complete description, see chapter 10.5, "Scheduled Event Objects", on page 305.
7.3.2.
Figure 90 - Service Offer Definition GUI
Table 73 - Service Offer Definition - feeplan Parameter Service Retailer*

servret
Description Service Retailer defining the current Service Offer Definition.
Name*
name
Name of the current Service Offer Definition.
11 September 2009
Page 235 of 968
Figure 91 - Service Offer Definition GUI - Version tab
Table 74 - Service Offer Definition - Version tab Parameter Version

version
Description Name of the Version of the current Service Offer Definition.
Start Date
vstartd
Date at which the Version as mentioned above for the current Service Offer Definition reaches the status defined below. Versioning status that the current Service Offer Definition Version reaches at the Start Date. Before that date, the current Version remains in its previous Status. After that date, the current Version holds the current Status until no other Status has started.
Status
vstatus
Figure 92 - Service Offer Definition GUI - General tab
Page 236 of 968
11 September 2009
Table 75 - Service Offer Definition - General tab Parameter Type of Nonusage Event
feemode
Description Mode in which the non-usage event defined by the current Service Offer Definition triggers the Rating Engine and affects the Accounts. There are 4 possible types: 1. Charge (feemode = 0) A non-usage Service Offer of type Charge consists in a debit operation to be applied on the Account (main balance or bundles). Inside a Service Offer Group, such a Service Offer typically represents amounts to be paid by the user, at one particular moment, or at regular intervals (e.g. monthly fees). If you select Charge, then you will further define your Service Offer Definition in the Charge Info tab (see Service Offer Definition - Charge Info tab page 245). 2. Top-up (feemode = 1) A non-usage Service Offer of type Top-up consists in a credit operation on the Account (main balance or bundles), at a particular moment or at regular intervals (e.g. bonus granted at the anniversary date of a Subscription). If you select Top-up, then you will further define your Service Offer Definition in the Top-up Info tab (see Service Offer Definition - Top-up Info tab page 247). 3. Charge linked with Top-up (feemode = 2) A non-usage Service Offer of type Charge linked with Top-up consists in a double operation: credit and debit, potentially on two different Accounts (e.g. monthly top-up of a voice bundle, paid by the main balance, or potentially by another Account). If you select Charge linked with Top-up, then you will further define your Service Offer Definition in the Charge Info tab (see Service Offer Definition Charge Info tab page 245) and in the Top-up Info tab (see Service Offer Definition - Top-up Info tab page 247). 4. LiteSCE (feemode = 3) A non-usage Service Offer of type LiteSCE can consist in any logic executed, since any LiteSCE script can be built by the operator for customizing the Convergent Rating Engine service. The LiteSCE script implementing the non-usage Service Offer is supposed to be executed at a particular moment, or a regular intervals. If you select LiteSCE, then you will further define your Service Offer Definition in the LSCE Info tab (see Service Offer Definition - LSCE Info tab page 249).
11 September 2009
Page 237 of 968
Table 75 - Service Offer Definition - General tab Parameter Moment of the Non-usage Event
feetype
Description Moment at which the non-usage events defined by the current Service Offer Definition are launched for triggering the CRE. 1. Activation (feetype = 0) If you select Activation, then the non-usage event defined by the current Service Offer Definition will trigger the CRE at the moment that the Subscription is activated. Note: The Subscription that is intended here is the one to the Service Offer Group containing the Service Offer defined by the current Service Offer Definition. 2. Cancellation (feetype = 1) If you select Cancellation, then the non-usage event defined by the current Service Offer Definition will trigger the CRE at the moment that the Subscription is cancelled. Note: The Subscription that is intended here is the one to the Service Offer Group containing the Service Offer defined by the current Service Offer Definition. 3. External Triggering (feetype = 2) If you select External Triggering, then the non-usage event defined by the current Service Offer Definition will trigger the CRE when sent through the interface by any other module (typically a RTxx). The Scheduling Engine is not involved in the launch and post-processing of these external events. Note: The events triggering the CRE from an external module, instead of being sent by the Scheduling Engine dont benefit from the follow-up scheme applied to the events managed by the Scheduling Engine. For instance, there will be no retry upon failure. 4. Recurrent (feetype = 3) If you select Recurrent, then the non-usage events defined by the current Service Offer Definition will trigger the CRE according to a given recurrence pattern. You will further define it in the Recurrence Info tab (see Service Offer Definition Recurrence Info tab page 241).
Page 238 of 968
11 September 2009
Table 75 - Service Offer Definition - General tab Parameter Scheduling Engine Behavior in Case of Error
nocred
Description Impact on the Subscriptions state in case the non-usage event defined by the current Service Offer Definition cannot be processed properly by the CRE (for whatever reason). Note: The Subscription that is intended here is the one to the Service Offer Group containing the Service Offer defined by the current Service Offer Definition. 1. Keep Subscription unchanged (nocred=0) The Subscriptions state wont be modified if the event cannot be properly processed by the CRE. 2. Set Subscription to suspended - retry state (nocred=1) The Subscriptions state will be set to Suspended - Retry if the event cannot be properly processed by the CRE. The Subscription can go back to the Active state if the next event gets processed by the CRE. 3. Set Subscription to suspended - no retry state (nocred=2) The Subscriptions state will be set to Suspended - No Retry if the event cannot be properly processed by the CRE. The Subscription cannot go back to the Active state since the next event wont be retried. The only way to re-activate the Subscription is to perform a management operation.
4. Set Subscription to cancelled state (nocred=3) The Subscriptions state will be set to Cancelled if the event cannot be processed properly by the CRE. Notification ID for Errors
notif_id
The notification feature for the Fees is not available in the Convergent Rating Engine V2.4. Note: Feature ID used in case of ARES error notification
11 September 2009
Page 239 of 968
Figure 93 - Service Offer Definition GUI - Recurrence Info tab
Page 240 of 968
11 September 2009
Table 76 - Service Offer Definition - Recurrence Info tab Parameter Description
A complete chapter of this manual is dedicated to the Recurring Events: see chapter 14., Recurring Events Management, on page 503. For the non-usage events defined as Recurrent (see parameter Moment of the Non-usage Event page 238), you can define whether you want the event to trigger the CRE (and then launch the charging of an Account) at the beginning or at the end of the designed recurrence pattern. The recurrence pattern itself is defined thanks to the parameters available in the Recurrence Info tab. In Advance (pflg=0) If you select In Advance, then the non-usage event defined by the current Service Offer Definition will trigger the CRE at the beginning of the designed cycle (e.g. a monthly fee actually covering the month that starts). In Arrears (pflg=1) If you select In Arrears, then the non-usage event defined by the current Service Offer Definition will trigger the CRE at the end of the designed cycle (e.g. a monthly fee actually covering the month that just finished).
The Non-usage Event covers the Period

pflg
See also 14.1.2, Schedule Events at the Beginning or at the End of the Cycle, on
page 504.
Note: Whether the Recurrent fee event is actually paid in advance or in arrears has an impact on the potential Refund operation allowed or not for the fee. Indeed, refunds are only relevant for fees paid in advance.
For more details, see parameter Allow Refunds page 246.

Recurrence Pattern
pertype
Standard period according to which the non-usage event defined by the current Service Offer Definition will be applied, i.e. sent by the Scheduling Engine for triggering the Convergent Rating Engine. Daily (pertype=0) Weekly (pertype=1) Monthly (pertype=2) Yearly (pertype=3) The exact period definition is achieved thanks to the next parameters: Number of days/weeks/months/years. Day of the Week or Day of the Month or Month of the Year
11 September 2009
Page 241 of 968
Table 76 - Service Offer Definition - Recurrence Info tab Parameter Number of days/ weeks/months/ years
every
Description This number completes the recurrence period definition provided by the Recurrence Pattern. Examples For Recurrence Pattern Weekly, if you enter 2 in this field, the non-usage event will be sent every other week. For Recurrence Pattern Yearly, if you enter 1 in this field, the non-usage event will be sent every year.
Day of the Week

dayweek
Monday, Tuesday, Wednesday, Thursday, Friday, Saturday, Sunday For Recurrence Pattern Weekly, this parameter specifies on which day of the week the non-usage event has to be sent by the Scheduling Engine. 1, 2,..., 27, 28 For Recurrence Patterns Monthly and Yearly, this parameter specifies on which date of the month the non-usage event has to be sent by the Scheduling Engine. Note: The dates are intentionally limited to the 28th day of the month, so that the recurrence pattern can be guaranteed for every month of the year.
Day of the Month

daymonth
Month of the Year

month
January, February,..., November, December For Recurrence Pattern Yearly, this parameter specifies in which month of the year the non-usage event has to be sent by the Scheduling Engine. This flag indicates whether the non-usage event s Recurrence Pattern has to be aligned with a specific date.
Align with Subscriptions Synchronization Date

syncfee
If the flag is checked

The scheduled events defined by the current Service Offer Definition will be synchronized with the date specified in the corresponding Subscription. See parameter Forced Charging Date page 293.
If the flag is unchecked

The scheduled events defined by the current Service Offer Definition wont be synchronized, even if the corresponding Subscription specifies a Forced Charging Date.
Pay attention The synchronization of some Recurrence Patterns is irrelevant and therefore the Convergent Rating Engine makes it impossible, even though you would configure your objects in order to enable the synchronization. For detailed explanation, see 14.2.2, Cases of Refused Synchronization, on page 506.
For more information, see 14.2, Synchronizing Recurring Events, on page 505.
Page 242 of 968
11 September 2009
Table 76 - Service Offer Definition - Recurrence Info tab Parameter Termination Type
stoptype
Description Parameter according to which the recurrence of the non-usage event is stopped but subscription remains active. Fixed Date (stoptype=0) If you select Fixed Date, then after that particular date, the event wont trigger the CRE anymore. Maximum Number of Occurrences (stoptype=1) If you select Maximum Number of Occurrences, then the event wont be generated more than that number of times for triggering the CRE. Unlimited (stoptype=2) The recurrence of the event has no limit.
Fixed Termination Date

stopdate
If you selected Termination Type Fixed Date.
Date from which the non-usage event defined by the current Service Offer Definition will no longer be sent by the Scheduling Engine for triggering the CRE. This date must be entered in the standard OSP Date & Time format: DD/MM/YY hh:mm:ss.
Maximum Number of Occurrences

stopocc
If you selected Termination Type Maximum Number of Occurrences
Maximum number of times that the non-usage event defined by the current Service Offer Definition will be sent by the Scheduling Engine for triggering the CRE. Only the successful occurrences of the non-usage event are taken into account. At any time, the current number of occurrences can be checked in the corresponding Scheduled Event object, which displays the counter. See parameter # Execution, page 312.
Prorata
at First and Immediate Occurrence
prorata1
This flag indicates whether pro-rata of the current fee event is allowed at the first or intermediate occurrences.
For complete explanation about the prorata, read carefully 14.4, Prorating Fees, on
page 508.
Prorata at Last Occurrence

prorata2
This flag indicates whether pro-rata of the current fee event is allowed at the last occurrence.
For more details about the prorata, read carefully 14.4, Prorating Fees, on
page 508.
11 September 2009
Page 243 of 968
Figure 94 - Service Offer Definition GUI - Charge Info tab (1)
Figure 95 - Service Offer Definition GUI - Charge Info tab (2)
Page 244 of 968
11 September 2009
Table 77 - Service Offer Definition - Charge Info tab Parameter Rating Method
debtype
Description
For Type of Non-usage Event Charge
When the non-usage events defined by the current Service Offer Definition consist in debit operations on the Account, the cost of the event can be defined in two different ways. Fixed Amount (debtype=0) In this case, the amount debited from the Account will always be the same, i.e. each time that the event occurs. Only the main Balance of the Account will be affected (not the Bundles). Trigger Usage Rating Rule (debtype=1) In this case, for each non-usage event triggering the Convergent Rating Engine, a decision tree will be translated in order to identify a Tariff, which provides a cost. The decision tree used for finding the Tariff is a Usage Rating Rule. Not only the main Balance, but also the Bundles of the Account can be affected by the debit operation.
Fixed Amount (Money)

feemoney
If you selected Rating Method Fixed Amount
Amount to be removed from the Accounts main Balance when the event defined by the current Service Offer Definition is processed.
Default Quantity
feevalue
If you selected Rating MethodTrigger Usage Rating Rule
Quantity that will be used for performing the quantity-to-cost or quantity-toquantity translation defined by the Tariff used to rate the fee event defined by the current Service Offer Definition.
For more details about quantity translation, see chapter 15.2, "Tariff object", on
page 519.
The RUM in which this quantity is expressed is the RUM 0, which always represents Time units.
For more information, see chapter 15.1, "Ratable Unit Metric object", on page 517.
This Default Quantity will be used for every fee event, except: if you modify it via a LiteSCE Script. Therefore, you have to enable the Flexibility Point for LiteSCE Fee defined in the LiteSCE Info tab (see description page 249); or if the fee event is launched via an External Triggering (see parameter Moment of the Non-usage Event, page 238). In this case, the entity sending the fee event message can fill in the quantity parameter with any value, which overrides the Default Quantity defined here. Usage Rating Rule
ustree
If you selected Rating Method Trigger Usage Rating Rule
Reference to the Usage Rating Rule to be translated for identifying the Tariff that will provide the rating of the event defined by the current Service Offer Definition.
11 September 2009
Page 245 of 968
Table 77 - Service Offer Definition - Charge Info tab Parameter General Ledger Code
gl_code
Description Reference to the General Ledger Code to be associated with the debit operation.
Allow Refunds
refund
This flag specifies whether amounts previously charged on the Account for the current fee may be refunded.
Fore more information about the Refund, read carefully 14.3, Refund Cases, on
page 507.
Notification ID for Warning

notifchg
The notification feature for the non-usage events is not available in the Convergent Rating Engine V2.0.3. Note: Feature ID used in case of ARES charge notification
Figure 96 - Service Offer Definition GUI - Top-up Info tab
Page 246 of 968
11 September 2009
Table 78 - Service Offer Definition - Top-up Info tab Parameter Top-up Method
toptype
Description
For Type of Non-usage Service Offer Top-up
When the non-usage events defined by the current Service Offer Definition consist in credit operations on the Account, the amount of that Top-up can be defined in two different ways. Simple (toptype = 0) In this case, the amount added to the Account will always be the same, i.e. each time that the event occurs. Only the main Balance of the Account will be affected (not the Bundles). Advanced (toptype = 1) In this case, for each non-usage event triggering the Convergent Rating Engine, the top-ups configuration will be identified via a Top-up Profile, which details how much money and/or how many units are added to the main Balance and or to which Bundles of the Account. Not only the main Balance, but also the Bundles of the Account can be affected by the top-up operation defined by a a Top-up Profile.
Top-Up Rule
topref
Reference to the Top-up Rule associated with the current Top-up operation. The Top-up Rule is a decision tree that makes the decision on whether or not the Topup operation is allowed.
For more information, see chapter 7.4, "Top-up Rule object", on page 252.
Top-Up Profile
topprof
If you selected Top-up Plan Type Advanced

Reference to the Top-up Profile defining the Top-up operation to be performed on the Account when the non-usage event defined by the current Service Offer Definition triggers the Convergent Rating Engine.
See chapter 20.3, "Top-Up Profile Object", on page 808.

Top-Up Amount (Money)
topvalue
If you selected Top-up Plan Type Simple

Amount to be added to the Accounts main Balance when the non-usage event defined by the current Service Offer Definition triggers the Convergent Rating Engine.
11 September 2009
Page 247 of 968
Table 78 - Service Offer Definition - Top-up Info tab Parameter Activity Period Extension (days)
actdays
Description This parameter impacts the Life Cycle of the Account topped-up when the nonusage event defined by the current Service Offer Definition triggers the Convergent Rating Engine. Number of days to be added to the Accounts Activity Period. The actual way the Life Cycle of the Account will be updated depends on the Activity Reload Algorithm. This algorithm can be either Cumulative or Maximum. The Reload Algorithm is either defined in the Top-up Profile mentioned above (if Top-up Plan Type is Advanced); or automatically set to its default value, which is set in the Service Retailer object (if Top-up Plan Type is Simple).
For more details on how these algorithms update the Accounts Life Cycle, see
parameter Activity Reload Algorithm*, page 815.
Inactivity Period Extension (days)

inacdays
This parameter impacts the Life Cycle of the Account topped-up when the nonusage event defined by the current Service Offer Definition triggers the Convergent Rating Engine.
Number of days to be added to the Accounts Inactivity Period. The actual way the Life Cycle of the Account will be updated depends on the Activity Reload Algorithm. This algorithm can be either Cumulative or Maximum. The Reload Algorithm is either defined in the Top-up Profile mentioned above (if Top-up Plan Type is Advanced). or automatically set to its default value, which is set in the Service Retailer object (if Top-up Plan Type is Simple).
For more details on how these algorithms update the Accounts Life Cycle, see
parameter Activity Reload Algorithm*, page 815.
Notification ID for Warning

notiftup
The notification feature for the Fees is not available in the Convergent Rating Engine V2.0.3. Note: Feature ID used in case of ARES top up notification
Page 248 of 968
11 September 2009
Figure 97 - Service Offer Definition GUI - LSCE Info tab
Table 79 - Service Offer Definition - LSCE Info tab Parameter LiteSCE Script Pool
lscepool
Description Reference to the LiteSCE Script Pool containing the LiteSCE Scripts used by the current Service Offer Definition
Position in LiteSCE Pool for LiteSCE Fee

lscepos0
Only used when Type of Non-usage Service Offer is set to LiteSCE.
See parameter LiteSCE (feemode = 3) page 237.

Position in the above-mentioned LiteSCE Script Pool of the LiteSCE Script that defines the logic to be executed by the Rating Engine when triggered on its feereq connector. No limit is applied to the logic implemented by this LiteSCE Script. Be aware that no logic other than the one defined in this Script will be executed on the feereq connector. In other words, this LiteSCE Script doesnt provide some customizing of the standard non-usage event processing logic; it totally replaces it.
Position in LiteSCE Pool for End of Treatment

lscepos1
Enables the second and last Flexibility Point of the feereq connector.
Position in the above-mentioned LiteSCE Script Pool of the LiteSCE Script that defines a custom logic to be executed by the Rating Engine when triggered on its feereq connector. This logic takes place after the execution of the default logic of the Rating Engine. Consequently, it is especially offered for extra post-processing or for modifying the statistical event to be stored in the ticket or for modifying the answer message sent back to the Scheduling Engine.
This LiteSCE Script customizes the standard non-usage event processing logic. As a consequence, it is incompatible with the LiteSCE Type of Non-usage Service Offer (see parameter Type of Non-usage Event page 237).
11 September 2009
Page 249 of 968
Table 79 - Service Offer Definition - LSCE Info tab Parameter Position in LiteSCE Pool for Next Date and Prorata
lscepos2
Description
Enables the first Flexibility Point of the feereq connector.
Position in the above-mentioned LiteSCE Script Pool of the LiteSCE Script that defines a custom logic to be executed by the Rating Engine when triggered on its feereq connector. This logic takes place before the execution of the default logic of the Rating Engine. Consequently, be aware that, if you set in this LiteSCE Script the value of the prorata (feereq.prorata) and nature: percentage, flag yes/no,...?) or the value of the Next Date (feereq.nextrfdt), they wont be recomputed according to the standard algorithm afterwards. They will indeed be used as such by the Rating Engine.
This LiteSCE Script customizes the standard non-usage event processing logic. As a consequence, it is incompatible with the LiteSCE Type of Non-usage Service Offer (see parameter Type of Non-usage Event page 237).
Figure 98 - Service Offer Definition GUI - Arena tab
Table 80 - Service Offer Definition - Arena tab Parameter Logical Name Description Logical Name of the Arena attribute, as it will be displayed in the GUIs. This parameter is set in the Arena object and is only available at display in the Service Offer Definition object. DB Name Database name of the Arena attribute. This parameter is set in the Arena object and is only available at display in the Service Offer Definition object. Type Data Type of the Arena attribute. This parameter is set in the Arena object and is only available at display in the Service Offer Definition object.
Page 250 of 968
11 September 2009
Table 80 - Service Offer Definition - Arena tab Parameter Value Description Value of the Arena attribute for the current instance of the Service Offer Definition. This parameter is set in the Arena object and is only available at display in the Service Offer Definition object.
Arena Implementation - Reminder When managing the Convergent Rating Engine via the GUIs, the Arena attributes visible in the Arena tab for each object instance are always up-todate. However, when managing the Convergent Rating Engine directly on the SOAP interface, or when making SQL queries onto the database, it is up to the operator to keep in mind that the records of the objects database may not reflect the exact status of the object instance.
For more details about the impact of the Arena implementation, see section 23.2.2,
"Arena Implementation", on page 857.
11 September 2009
Page 251 of 968
7.4.
7.4.1.
Top-up Rule object

Object Purpose
The goal of a Top-Up rule is to indicate whether a Top-Up is allowed or not.
7.4.2.
Figure 99 - Top-up Rule GUI
Table 81 - Top-up Rule - toprule Parameter Service Retailer*

aservret
Description Reference to the Service Retailer defining the current Top-up Rule.
Name*
name
Name of the current Top-up Rule.
Page 252 of 968
11 September 2009
Table 81 - Top-up Rule - toprule Parameter Calendar*

cal_ref
Description Reference to the Calendar valid for the current Top-up Rule. So, within this decision tree, the Date Criterion will allow referring to the Day Types defined in this Calendar. Name of the Version of the current Top-up Rule.
Version
version
For a detailed explanation of the Product Catalog versioning, please see

chapter 11., "Versioning", on page 324.
Start Date
vstartd
Date at which the Version as mentioned above for the current Top-up Rule reaches the status defined below. Versioning status that the current Top-up Rule Version reaches at the Start Date. Before that date, the current Version remains in its previous Status. After that date, the current Version holds the current Status until no other Status has started.
Status
vstatus
7.4.3.
Making Up a Top-Up Rule
You implement a Top-Up Rule as a decision tree. To know how you implement a rule as a decision tree, and have an example, see chapter 12., "Decision Trees", on page 329. A decision tree is made up of criteria and leaves.

To know what criteria are available when making up a Top-Up Rule, and have details about them, please see section 12.3, The Criteria, on page 378.
7.4.3.2. The Leaves

A Top-Up Rule returns: Either an Allowed leaf. In order to indicate that a Top-Up is allowed, a Top-Up rule returns an Allowed leaf. Or a Forbidden Leaf In order to indicate that a Top-Up is not allowed, a Top-Up rule returns a Forbidden leaf. To know more about these leaves, and have details about them, please see section 12.4, "The Leaves", on page 468
11 September 2009
Page 253 of 968
Guiding Rules
8. Guiding Rules
8.1. Introduction
The notion of Guiding covers the dynamic identification, via the Rules of a Service Offer, of two major parameters of the event to be processed:
1.
2.
Charged Account1
Plan to be applied for cost computation.
These two decisions are defined by decision trees that are part of the Service Offer itself, so part of the Product Catalog of the Service Provider. Each Service Offer (of whatever type: Usage, Non-usage, Top-up) has a reference to a Charging Rule and a Rating Plan Rule. These two Guiding rules are optional. The Guiding is successful only when the charged Account and the Rule (Usage Rating Rule or Top-up Rule) are identified.
8.2.
Commercial Offer Application Order
In other words, it means that, for a given user, several different Guidings could potentially be successful. Which one will be applied then? When a Customer belongs to several Communities, he has a different Commercial Offer for each Community, and still his own personal Default Commercial Offer. As long as the full Guiding process is not successfully completed, the Community Engine re-attempts the whole process with another Commercial Offer of the Customer. Below is the order applied by the Community Engine for identifying the Commercial Offers of the Customer. 1. Commercial Offer of the Communities, in the increasing order to the relative Weight of the Customers Associations, exploring the hierarchy from the higher Customer to the one just above the calling Customer (his Upper Customer in the Community), so the calling Customers Charging Rule is not translated. 2. 3. If no payer found in any Community: Default Commercial Offer of the Customer If Customer unable to find a Service Offer, a charged Account, or whatever the reason of the denial of Authorization via the Default Commercial Offer Commercial Offer of each Community in the order of their place in the database (so NOT based on the relative Weight of the Associations attaching the Customer to the Communities), without exploring the hierarchy, so only at the calling Customers level, via his own Charging Rule.
1. By charged Account, it is generally intended the Account affected by the current event: it is typically charged for a usage event, but incremented for a top-up event.
Page 254 of 968
11 September 2009
The Guiding is performed by translating the Charging Rule and the Rating Plan Rule of a Service Offer. Dont forget that a Service Offer is part of a Commercial Offer, and yet a Customer can have links to several Commercial Offers, which might each contain a relevant Service Offer for the event triggering the CRE.
8.3.
8.3.1.
Charging Rule object

Object Purpose
Within a Service Offer, a Charging Rule is an optional parameter. A Charging Rule is: useless when the CRE is running in Gateway mode, since the Community Engine then directly dispatches to the RE all the Rtx requests it receives. So there is no need to identify them. useless for Customers owning only one Account: their default Account. For those Customers, there is only one account to be charged anyway. This can be the configuration of a Prepaid Customer database. mandatory for Customers owning more than one Account: the selection of which one should be charged can only be performed by a Charging Rule.
8.3.2.
Figure 100 - Charging Rule GUI
Table 82 - Charging Rule - billrule Parameter Service Retailer*

aservret
Description Reference to the Service Retailer defining the current Charging Rule.
Charging Rule Name*

name
Name of the current Charging Rule.
11 September 2009
Page 255 of 968
Guiding Rules
Table 82 - Charging Rule - billrule Parameter Calendar*

cal_ref
Description Reference to the Calendar valid for the current Charging Rule. So, within this decision tree, the Date Criterion will allow referring to the Day Types defined in this Calendar. Name of the Version of the current Charging Rule.
Version
version

Start Date
vstartd
Date at which the Version as mentioned above for the current Charging Rule reaches the status defined below. Versioning status that the current Charging Rule Version reaches at the Start Date. Before that date, the current Version remains in its previous Status. After that date, the current Version holds the current Status until no other Status has started.
Status
vstatus
8.3.3.
Making Up a Charging Rule

You implement a Charging Rule as a decision tree. To know how you implement a rule as a decision tree, and have an example, see chapter 12., "Decision Trees", on page 329. A decision tree is made up of criteria and leaves.

To know what criteria are available when making up a Charging Rule, and have details about them, please see section 12.3, The Criteria, on page 378.
8.3.3.2. The Leaves

The Charging Rule is a decision tree of which the expected decision is the Customer Account on which the values computed for the current event have to be applied (balance and/or bundle charging, counter update, top-up,...). A Charging Rule returns: Either a Customer Account leaf, which references the identified Customer Account Or a Charging Rule leaf Or a Forbidden Leaf
To know more about these leaves, and have details about them, please see section 12.4, "The Leaves", on page 468.
Page 256 of 968
11 September 2009
8.4.
8.4.1.
Rating Plan Rule object

Object Purpose
The Rating Plan Rule allows defining, within a Service Offer, another Service Offer to be applied for the current event. The purpose of a Rating Plan Rule is very particular since it means that you want to escape your Service Offers plan and switch to another one. Doing so, you break the notion of Commercial Offer. A Rating Plan Rule is always optional.
8.4.2.
Figure 101 - Rating Plan Rule GUI
Table 83 - Rating Plan Rule - ratrule Parameter Service Retailer*

aservret
Description Reference to the Service Retailer defining the current Rating Plan Rule.
Rating Plan Rule Name*

name
Name of the current Rating Plan Rule.
Calendar*
cal_ref
Reference to the Calendar valid for the current Rating Plan Rule. So, within this decision tree, the Date Criterion will allow referring to the Day Types defined in this Calendar.
11 September 2009
Page 257 of 968
Guiding Rules
Table 83 - Rating Plan Rule - ratrule Parameter Version

version
Description Name of the Version of the current Rating Plan Rule.

Start Date
vstartd
Date at which the Version as mentioned above for the current Rating Plan Rule reaches the status defined below. Versioning status that the current Rating Plan Rule Version reaches at the Start Date. Before that date, the current Version remains in its previous Status. After that date, the current Version holds the current Status until no other Status has started.
Status
vstatus
8.4.3.
Making Up a Rating Plan Rule
You implement a Rating Plan Rule as a decision tree. To know how you implement a rule as a decision tree, and have an example, see chapter 12., "Decision Trees", on page 329. A decision tree is made up of criteria and leaves.

To know what criteria are available when making up a Rating Plan Rule, and have details about them, please see section 12.3, The Criteria, on page 378.
8.4.3.2. The Leaves

The Rating Plan Rule is a decision tree which the expected decision of is the Service Offer which the Plan of (Usage, Non-usage or Top-up) is to be applied for processing the current event. A Rating Plan Rule returns: Either a Service Offer leaf, which references the identified Service Offer Or a Rating Plan Rule leaf Or a Forbidden Leaf
To know more about these leaves, and have details about them, please see section 12.4, "The Leaves", on page 468.
Page 258 of 968
11 September 2009
9. Catalog Structure
9.1.
9.1.1.
Catalog Creation Logic

Introduction
The Product Catalog is the repository of all the Commercial Offers that the Customers of a Service Retailer can register to. A Commercial Offer is a structured set of Service Offers. One Service Offer can be used by more than one Commercial Offer.
For a detailed description of the Product Catalog s functionality and design, please refer to your Convergent Rating Engine Product Description.
9.1.2.
Object Provisioning Order
For creating a new Commercial Offer from scratch within the Product Catalog, the objects have to be created in the order described below. 1.
Define Services, which can either match a Network Event Type, received in the trigger message by the interface; or a series of criteria as set in the Service Rule of the Commercial Offer. (e.g. if the voice event occurs between 8:00 AM and 6:00 PM, than the Service is Voice Peak; else the Service is Voice Off Peak). In this case, you must create the appropriate Service Rule (section 6.2, Service Rule object, on page 224).
2.
Create a Commercial Offers name If required, attach the appropriate Service Rule to your Commercial Offer, if you want it to discriminate between more sophisticated Services than the ones based on the Network Event Types sent by the RTx.
3. 4.
Create a Packages name Create a Service Offer, by mainly defining: the Service for which it defines an offer the type of Service that is handled by this offer (chapter 7., "Types of Service Offers", on page 228) attach the appropriate Rules (for rating and for guiding)
5.
Create a Service Offer Groups name And define if this Service Offer is possibly a Barring offer or a Add-On Service Offer.
6. 7.
Link inter-dependent Service Offers into a Service Offer Group Insert a Service Offer Group into a Package And define if this Service Offer Group is mandatory/default in that Package or if it has to be explicitly subscribed to.
11 September 2009
Page 259 of 968
Catalog Structure
8. Each
Insert a Package into a Commercial Offer step can be re-iterated, in order to have one or more Service Offers in a Service Offer Group, one or more Service Offer Groups in a Package one or more Packages in a Commercial Offer one or more Commercial Offers in the Product Catalog.
9.2.
9.2.1.
Service Object
Object Purpose
A Service is a feature or functionality that the Service Retailer can eventually do two things with:
1.
2.
make the users pay for having it (how much, how and when they pay being defined by the Service Offer);
make the users somehow subscribe to it (potential constraints may apply to the Service registration).
The Service for which the Convergent Rating Engine is triggered is initially identified thanks to the Network Event Type received in the trigger message. See section 6.1, "Network Event Type object", on page 219.
Nevertheless, a more sophisticated Service distinction can be performed by using a Service Rule, which eventually provides a Service. When a Service has been identified via the Service Rule of a Commercial Offer, that Service is the only one known by the Convergent Rating Engine from then on for the current event. See section 6.2, "Service Rule object", on page 224.
9.2.2.
Figure 102 - Service GUI
Table 84 - Service - services Parameter Service Retailer*

aservret
Description Reference to the Service Retailer defining the current Service.
Page 260 of 968
11 September 2009
Table 84 - Service - services Parameter Service Name

srvname
Description Name of the current Service.
Description
descript
Free text field for describing the current Service.
9.3.
9.3.1.
Commercial Offer Object

Object Purpose
A Commercial Offer is a structured set of Service Offer Groups (see section 9.6, Service Offer Group Object, on page 270). Granting a Commercial Offer to a user (i.e. to either a Customer or an Account that belongs to no Customer) is the only way to grant Service Offer Groups, and thus the Service Offers (see section 9.5, Service Offer Object, on page 265) it contains, to that user. There is thus no user without a Commercial Offer: a user without any Commercial Offer will never be processed by the CRE.
For clarifications on what a user is, see also User, on page 34.
9.3.1.1. Important Limitation on Commercial Offers

Since a Commercial Offer is a structured set of Service Offer Groups, and since a Service Offer Group is itself made up of Service Offers, a Commercial Offer is also a structured set of Service Offers.
9.3.1.1.1. For baring service offer groups Within a given Commercial Offer, an important limitation applies:
Among the Service Offer Groups of a Commercial Offer, that are active for a given user of that Commercial Offer the Barring Service Offer Groups of the Commercial Offer being excluded no Service Offer can refer to the same service. Note: On the other hand, nothing prevents several Service Offers that are not active in a Commercial Offer (i.e. that belong to non-active Service Offer groups of the Commercial Offer) to be about the same service.
Whats the reason of this limitation?

Whenever the CRE scans a Commercial Offer in order to locate the Service Offer it has to process, the CRE tries to find out, from the active Service Offers of the Commercial Offer, a Service Offer that corresponds to a given Service (the Service to which the RTx network event that caused the scan is mapped). Thus, if two active Service Offers of the same Commercial Offer are about the same service, one of the two Service Offers will always be ignored.
11 September 2009
Page 261 of 968
Catalog Structure
9.3.1.1.2. Not supporting the swaping

The CRE existing product is not supporting the swaping of Commercial Offer, due to various issues involved such as, associated optional SOGs, Subscriptions etc. If you are trying to modify the commercial offer, then changing the name is not sufficient. You have to take care of all the Optional / Subscription which is linked with the old comm offer. Else, they will not be checked / modified.
9.3.2.
Figure 103 - Commercial Offer GUI
Table 85 - Commercial Offer - comoffer Parameter Service Retailer*

aservret
Description Reference to the Service Retailer defining the current Commercial Offer.
Name*
name
Name of the current Commercial Offer. Once a Commercial Offer is created, Packages can be inserted in it via a Package Link. Reference to the Service Rule to be translated for identifying the Services of the current Commercial Offer in a more sophisticated manner than just via the Network Event Type.
Service Rule
servrule
See chapter 6., "Service Identification", on page 219.

Version*
vers
Name of the Version of the current Commercial Offer.
Page 262 of 968
11 September 2009
Table 85 - Commercial Offer - comoffer Parameter Start Date*

vstartd
Description Date at which the Version as mentioned above for the current Commercial Offer reaches the status defined below. Versioning Status that the current Commercial Offer Version reaches at the Start Date. Before that date, the current Version remains in its previous Status. After that date, the current Version holds the current Status until no other Status has started.
Status*
vstatus
Note: For "Display" invoked on Commercial Offer, If the status is not specified by the operator, active version of a commercial offer gets displayed by default. In case active version does not exist, then the message "Commercial Offer not found" would be flashed. However if status of Commercial Offer is specified then commercial offer corresponding to that status only gets displayed.
9.4.
9.4.1.
Package Object
Object Purpose
A Package is a set of Service Offer Groups. The Service Offer Groups are actually inserted into a Commercial Offer via a Package. Several Commercial Offers can refer to the same Package. Concretely, a Package is meant to be a coherent set of Service Offer Groups to be presented to the clients. The Service Offer Groups of a Package are: either Default accessible to all the users having that Package in their Commercial Offer or Optional available for Subscription to all the users having that Package in their Commercial Offer, but actually accessible only if they explicitly subscribe. Within the Package, some Service Offer Groups can be: Barring Service Offer Groups, or Add-On Service Offer Groups
For more details, see section 9.6, "Service Offer Group Object", on page 270.
11 September 2009
Page 263 of 968
Catalog Structure
9.4.2.
Figure 104 - Package GUI
Table 86 - Package - package

Parameter Service Retailer*

aservret
Description Reference to the Service Retailer defining the current Package.
Name*
name
Name of the current Package. Once a Package is created, Service Offer Groups can be inserted in it via a Service Offer Group Link. Name of the Version of the current Package.
Version
version

Default Value This parameter is not only optional, it also has a default value, which is the following string of characters: Default Thus, the first letter of the default value is always in upper case and the other letters of the default value are always in lower case. Start date
vstartd
Date at which the Version as mentioned above for the current Package reaches the status defined below. Default Value This parameter is not only optional, it also has a default value, which is 01 Jan 2000.
Page 264 of 968
11 September 2009
Table 86 - Package - package Parameter Status

vstatus
Description Versioning Status that the current Package Version reaches at the Start Date. Before that date, the current Version remains in its previous Status. After that date, the current Version holds the current Status until no other Status has started. Default Value This parameter is not only optional, it also has a default value, which is: Active
9.5.
Service Offer Object
9.5.1.
Object Purpose
The Service Offer is the central object of the Product Catalog, since it shows all the conditions of Service delivery to the user, from the rating and charging standpoints. Basically, a Service Offer determines: the cost computation of the events of the related Service (whether this latter is of type Usage, Non-usage or Top-up); the guiding to the charged account (i.e. finding which Account of the customer-to-be-charged has to be charged) for the events of the related Service; optionally, the use of another cost computation rule for the events of the related Service. All these Service Offer features are specified via the most flexible and sophisticated decision tool: the OSPs decision tree.
11 September 2009
Page 265 of 968
Catalog Structure
9.5.2.
Figure 105 - Service Offer GUI
Table 87 - Service Offer - srvoffer Parameter Service Retailer*

aservret
Description Reference to the Service Retailer defining the current Service Offer.
Name*
name
Name of the current Service Offer.
Service*
serv_ri
Reference to the Service for which the current Service Offer is created. All triggering events of this Service will then be rated using the current Service Offers Associated Rule.
Page 266 of 968
11 September 2009
Table 87 - Service Offer - srvoffer Parameter Associated Rule*

plan_ref
Description Reference to the Associated Rule of the Service Offer. The value of this parameter must be the name of: Either a Usage Rating Rule (Usage Rating Rule radio-button must then be checked), Or a Top-Up Rule (Top-Up Rule radio-button must then be checked), Or a Service Offer Definition (Service Offer Definition radio-button must then be checked). The Associated rule defines the cost of the network events for the Service that is covered by the current Service Offer.
Usage Rating Rule
Check this radio-button if Associated Rule parameter is holding a reference to a Usage Rating Rule. This choice must naturally comply with the actual events of the Service that the current Service Offer covers. Thus, if the service the Service offer is about (thats the service that Service parameter specifies) is of type Usage: You need to check this radio-button, and
The Associated Rule of the Service Offer must be a Usage Rating Rule.

Top-up Rule
A Usage Rating Rule defines the cost of the usage events.
Check this radio-button if Associated Rule parameter is holding a reference to a Top-Up Rule. This choice must naturally comply with the actual events of the Service that the current Service Offer covers. Thus, if the service the Service offer is about (thats the service that Service parameter specifies) is of type Top-Up: You need to check this radio-button, and The Associated Rule of the Service Offer must be a Top-Up Rule.

Service Offer Definition
A Top-Up Rule checks whether a Top-Up event is allowed or not.
Check this radio-button if Associated Rule parameter is holding a reference to a Service Offer Definition. This choice must naturally comply with the actual events of the Service that the current Service Offer covers. Thus, if the service the Service offer is about (thats the service that Service parameter specifies) is of type Non-usage: You need to check this radio-button, and The Associated Rule of the Service Offer must be a Service Offer Definition.
A Service Offer Definition defines the cost and recurrence of the nonusage events.
11 September 2009
Page 267 of 968
Catalog Structure
Table 87 - Service Offer - srvoffer Parameter Charging Rule

bil_ref
Description If you want the Service Offer to use a given Charging Rule, enter here the name of that Charging Rule. Else, leave this parameter empty. Whenever a Service Offer uses a Charging Rule, the CRE uses that rule to find out, for the events of the Service Offer, which account, of the customer-to-be-charged, has to be charged. Whenever a Service Offer does not use a Charging Rule, it is the default account of the customer-to-be-charged that will be charged.

If the Service Offer is either about a Top-Up Rule or a Service Offer Definition but stills specifies a Rating Plan Rule, everything happens as if the Service Offer had no Charging Rule. Whenever the CRE uses a Service Offer in consequence of a Rating Plan Rule execution, the CRE does not attempt to execute the Charging Rule of the Service Offer, if any. Whenever the CE service of the RE is running in Gateway Mode, Charging Rules do not make sense and are thus ignored. Which means that, if a Charging rule is then still associated to a Service Offer, that Charging Rule never gets executed. As a result, whenever the CE is running in Gateway Mode, it does not make sense you set this parameter to some value.
section 8.3, "Charging Rule object", on page 255.
For more explanations about the guiding and specifically Charging Rules, see
Page 268 of 968
11 September 2009
Table 87 - Service Offer - srvoffer Parameter Rating Plan Rule

rat_ref
Description If you want the Service Offer to use a given Rating Plan Rule, so that the Associated Rule of another Service Offer will be used, enter here the name of that Rating Plan Rule. Else, leave this parameter empty. Whenever a Service Offer uses a Rating Plan Rule, the CRE uses that rule to find out another Service Offer, in order to use the Associated Rule of that other Service Offer, at the place of the one the Service Offer specifies. Whenever a Service offer does not use a Rating Plan Rule, the CRE uses the Associated Rule of the Service Offer.
Whenever the CE service of the RE is running in Gateway Mode, Rating Plan Rules do not make sense and are thus ignored. Which means that, if a Rating Plan Rule is then associated to a Service Offer, that Rating Plan Rule never gets executed. As a result, whenever the CE is running in Gateway Mode, it does not make sense you set this parameter to some value. If a Service Offer has a Rating Plan Rule, but does not have a Charging Rule, then everything happens as if the Service Offer had no Rating Plan Rule. If the Service Offer is either about a Top-Up Rule or a Service Offer Definition but still specifies a Rating Plan Rule, then everything happens as if the Service Offer had no Rating Plan Rule. Whenever the CRE uses a Service Offer in consequence of a Rating Plan Rule execution, the CRE does not attempt to execute the Rating Plan Rule of the Service Offer, if any.
seesection 8.4, "Rating Plan Rule object", on page 257.

For more explanations about the guiding and specifically Rating Plan Rules,
Version*
version
Name of the Version of the current Service Offer.

Start Date*
vstartd
Date at which the Version as mentioned above for the current Service Offer reaches the status defined below. Versioning Status that the current Service Offer Version reaches at the Start Date. Before that date, the current Version remains in its previous Status. After that date, the current Version holds the current Status until no other Status has started.
Status*
vstatus
11 September 2009
Page 269 of 968
Catalog Structure
9.6.
9.6.1.
Service Offer Group Object

Object Purpose
A Service Offer Group gathers several Service Offers that are tightly bound within the Product Catalog. These Service Offers can be linked under several aspects: Link = Constraint on Subscription The user must somehow be obliged to subscribe to the Recurring Charges when subscribing to the Usage of a particular Service. Link = Delivery Enabling The Recurring Charges payment actually enables the delivery of the Usage of a particular Service. If the Recurring Charges are not paid, the Usage should be blocked. Link = Inter-dependence It would be nonsense to have users subscribing to a Top-up Service Offer when they havent subscribed to the Usage Service Offer using the units of the topped-up Bundles. Conversely, the Top-up Service Offer feeding the Bundles needed by the Usage Rating Rule has to be linked to the Usage Service Offer.
9.6.1.1. Add-On Service Offer Group

A Service Offer Group can be defined as an Add-On Service Offer Group. Formally, it is constituted as a usual Service Offer Group, but functionally it fills another role.
Functionality
The functionality of an Add-On Service Offer Group is to enable a rating or guiding feature of another Service Offer Group and to attach Recurring Charges and/or a Top-up Service Offer to that particular feature, while having no impact on the Authorization process. Because an Add-On Service Offer group has only meaning with respect to another Service Offer Group, the functionality it brings is as an add-on to that other Service Offer Group functionality. Hence, the name Add-On Service Offer Group.
Example: the Friends and Family Feature

The functionality to be offered to the Customer is easy to understand: allow him, when calling people that belong to his Friends and Family List, to get a cheaper cost than for a usual event. The reason why the Service Retailer would make the Friends and Family feature a Service Offer Group into the Product Catalog is that he may want to attach it a Recurring Charges Service Offer in order to have the Customer paying for benefitting from the Friends and Family feature (i.e. a monthly fee); and/or a Top-up Service Offer for instance in order to have the charged account equipped with a specific Bundle on which the Friends and Family events are charged (at a preferential rate). Nevertheless, the reason why the Service Retailer wouldnt make the Friends and Family feature a Service Offer Group is that he doesnt want to identify Friends and Family as a Service, because it would have the following consequences: Friends and Family on Voice, on SMS, on MMS, etc. would all be applied the same Usage Rating Rule. Otherwise, one should create as many Service Offers: Voice Friends and Family, SMS
Page 270 of 968
11 September 2009
Friends and Family, MMS Friends and Family,... which is not very pragmatic as to the Product Catalog management. Above all, identifying Friends and Family as a Service leads to actually authorize the Friends and Family event (not the Voice, SMS or MMS event). Concretely, it means that, if the Customer hasnt paid his Recurring Charges for Friends and Family on time (for whatever reason), he would be denied the right to make a Friends and Family event, while he would still be allowed to make any other Voice, SMS or MMS event. Actually, in this particular case, the expected behavior would be that the Customer is allowed to call his Friends, but at the normal Voice, SMS or MMS tariff, not benefitting from the Friends and Family preferential tariff.
The Add-On Service Offer Group implementation

When making Friends and Family an Add-On Service Offer Group, the Service identified is still Voice, SMS or MMS. The Usage Rating Rule used is the one of that Service, and it can then use a Subscription Criterion for checking if the Customer has subscribed to that optional rating feature. If yes, then he can access the decision trees branch where the Friends and Family Criterion is located, leading to a specific tariff. If the Customer hasnt paid his Recurring Charges for Friends and Family (for whatever reason), the Subscription Criterion wont be successfully met and the Friends and Family preferential tariff wont be accessed. However, the Customer will still be able to perform his call, because the Authorization has only been done on the Voice, SMS or MMS Service.
Why does it need to be defined as a Service Offer?

Indeed, one can use a Friends and Family Criterion in a Usage Rating Rule without checking a Subscription. In that case:
1.
2.
all users having access to the Service via that Usage Rating Rule will benefit from the Friends and Family feature. There is no way to block it.
there is no way to have the users paying for the Friends and Family feature itself (including the preferential rating scheme, but also the FNF list management, etc.)
The advantage of the Add-On Service Offer Group implementation of a feature like Friends and Family is that it allows assigning Recurring Charges to the feature, while still keeping the feature optional for the users.
Summary: An Add-On Service Offer Group

doesnt include a Usage Service Offer; typically includes a Recurring Charges Service Offer and/or a Top-up Service Offer; is referenced by the Subscription Criterion of other Service Offer Group(s) Usage Rating Rule(s) and/or Charging Rule(s) and/or Rating Plan Rule(s); must be included in the same Package as the Service Offer Groups to which it applies, i.e. checking the Add-On Service Offer Group in their Rules via a Subscription Criterion; can be subscribed to, so must be defined as Optional in the Package (in the Service Offer Group Link object); has no effect on the Authorization process, since it has no impact on the Service identification process. See chapter 6., "Service Identification", on page 219.
9.6.1.2. Barring Service Offer Group

Functionality
11 September 2009
Page 271 of 968
Catalog Structure
The barring is the denial of authorization performed by the Service Provider on a particular Service, upon request of the Customer. For instance, some parents may want to make sure that the adult contents premium numbers are barred when the children would attempt to access them. This access control can be implemented by the Service Provider as a feature offered to the Customers, and hence defined in the Product Catalog with an associated cost.
How does barring works?

The CRE is triggered with an event, thanks to which the Service is identified. For authorizing the Customer, his Commercial Offer is scanned, in order to find if he has a Service Offer allowing him to access the Service triggered. This step of the Authorization process is called Validation. IF no Service Offer is found No validation The event is rejected. IF a Service Offer is found for the triggered Service:
IF the Service Offer belongs to an optional Service Offer Group Validation OK continue processing the event.
IF the Service Offer belongs to a default Service Offer Group Potential Barring must be verified before validating the event: IF the Package in which the Service Offer has been found also contains a Service
Offer Group of type Barring AND IF the Customer has subscribed to it
IF this Barring Service Offer Group contains a Service Offer for the same Service as the one triggered by the current event No validation The event
is rejected.
IF this Barring Service Offer Group doesnt contain a Service Offer for the same Service as the one triggered by the current event Validation OK
continue processing the event.
Corollaries of this rule 1. Barring can apply to any kind of Service:

Usage (of course: blocking the access to the network service delivery) Non-usage (it is possible to block the Recurring Charges, more likely when the Usage has been blocked). Remark: Barring the charges of the blocked Usage Service doesnt prevent at all to define a Recurring Charges Service Offer for the Barring itself. In other words, it is possible to actually substitute Barring Recurring Charges to the service access Recurring Charges. Top-up 2. 3. 4. A Barring Service Offer Group includes the Service Offer(s) that it bars. Only Default Service Offers can be barred via a Barring Service Offer Group. Optional Service Offer Groups have to be unsubscribed if the user wants to remove them from his access rights. A Barring Service Offer Group must be inserted in the same Package as the Service Offer Group that it bars one or more Service Offer(s) of.
Page 272 of 968
11 September 2009
9.6.2.
Figure 106 - Service Offer Group GUI
Table 88 - Service Offer Group - sroffgrp


aservret
Description Reference to the Service Retailer defining the current Service Offer Group.
Name*
name
Name of the current Service Offer Group. Once a Service Offer Group is created, Service Offers can be inserted in it via a Service Offer Link. Flag indicating whether the current Service Offer Group is an add-on Service Offer group or not.
... Is an Add-On
subsrofg

The current Service Offer Group will be functionally considered as an AddOn Service Offer Group, i.e. enabling an additional rating feature of all the other Service Offer Groups of the same Package using the Subscription Criterion for testing it in their Usage Rating Rule. As a consequence, since an Add-On Service Offer Group must be offered for Subscription, it has to be defined as Optional (not Default) in the Package. See parameter Mandatory in section 9.8, "Service Offer Group Link Object", on page 276.
For more details on the Add-On Service Offer Group notion, see section
9.6.1.1, "Add-On Service Offer Group", on page 270.
11 September 2009
Page 273 of 968
Catalog Structure
Table 88 - Service Offer Group - sroffgrp Parameter ... Is Barring Service

barrflg
Description Flag indicating whether the current Service Offer Group actually defines the barring of another Service Offer Group.

The current Service Offer Group will ensure the barring of the Service Offers included in it. Concretely, the first step of the Authorization process (Validation) for all events of those Service Offers will end up in a denial of authorization for the Customer having subscribed to the Barring Service Offer Group. As a consequence, since a Barring Service Offer Group must be offered for Subscription, it has to be defined as Default (not Optional) in the Package. See parameter Mandatory in section 9.8, "Service Offer Group Link Object", on page 276.
For more details on the Barring notion, see section 9.6.1.2, "Barring Service
Offer Group", on page 271.
Version*
version
Name of the Version of the current Service Offer Group.

Start Date*
vstartd
Date at which the Version as mentioned above for the current Service Offer Group reaches the status defined below. Versioning Status that the current Service Offer Group Version reaches at the Start Date. Before that date, the current Version remains in its previous Status. After that date, the current Version holds the current Status until no other Status has started.
Status*
vstatus
9.7.
9.7.1.
Service Offer Link Object

Object Purpose
A Service Offer Link object allows inserting a Service Offer into a Service Offer Group. A Service Offer can be reused by several Service Offer Groups.
Page 274 of 968
11 September 2009
9.7.2.
Figure 107 - Service Offer Link GUI
Table 89 - Service Offer Link - srvoflnk


aservret
Description Reference to the Service Retailer defining the current Service Offer Link.
Service Offer Group*

srofgref
Reference to the Service Offer Group in which a Service Offer (mentioned below) has to be inserted. Reference to the Service Offer that has to be inserted into the Service Offer Group (mentioned above). Name of the Version of the current Service Offer Link.
Service Offer*
srofname
Version*
version

Start Date*
vstartd
Date at which the Version as mentioned above for the current Service Offer Link reaches the status defined below. Versioning Status that the current Service Offer Link Version reaches at the Start Date. Before that date, the current Version remains in its previous Status. After that date, the current Version holds the current Status until no other Status has started.
Status*
vstatus
11 September 2009
Page 275 of 968
Catalog Structure
9.8.
9.8.1.
Service Offer Group Link Object

Object Purpose
A Service Offer Group Link object allows inserting a Service Offer Group into a Package. A Service Offer Group can be reused by several Packages.
9.8.1.1. Default and Optional Service Offer Groups of a Commercial Offer

In a Commercial Offer, two kinds of Service Offer Groups are possible: Default Service Offer Groups. A default Service Offer Group of a Commercial Offer is one that is offered by default to all the users of the Commercial Offer. In other terms, as soon as an user has been granted a Commercial Offer, no supplementary operator intervention is needed for allowing him/her to get access to any default Service Offer Group of the Commercial Offer. Since the same Commercial Offer can be assigned to several users, making a Service Offer Group a default one in a Commercial Offer is a way to automatically grant that Service Offer Group to all the users of the Commercial Offer.
Optional Service Offer Groups. An optional Service Offer Group of a Commercial Offer is one to which a user of the Commercial Offer has access if, and only if, an operator authorises him/her to get access to it. In order to give that authorization, an operator has to create a subscription that explicitly allows the user to access that optional Service Offer Group of the Commercial Offer. From that moment on, the user has access to that optional Service Offer group of the Commercial Offer. Note: It is correct to think of a default Service Offer Group of a Commercial Offer as one for which a Subscription is automatically created at time the Commercial Offer is granted to a user. There is one difference however: It is not possible to view such a subscription.
Section 10.4, Subscription Objects, on page 290, explains how you create a subcription to an optional Service Offer group for a user.
9.8.1.2. Active Service Offer Groups of a Commercial Offer

A Service Offer Group of a Commercial Offer is active for a user of that Commercial Offer if that user has access (can use) to the Service Offer Group. Be fully aware it can turn out that an optional Service Offer Group of a given Commercial Offer can be accessed by some users of the Commercial Offer, but not by the other users of the Commercial Offer. For example, an user of a Commercial Offer might have received, by means of a subscription set up by an operator, access to some optional Service Offer Group of the Commercial Offer, while some other user of the same Commercial Offer did not receive access to that optional Service Offer Group. Thus, a Service Offer Group of a Commercial Offer can be, at the same time, active with respect to some users of the Commercial Offer, and inactive with respect to the other ones.
Page 276 of 968
11 September 2009
Note: In this document, you might sometimes read something like If a Service Offer Group is active in Commercial Offer, then .... You should then understand something like If a Service Offer Group is active in a Commercial Offer for the concerned user, then ...
9.8.2.
Figure 108 - Service Offer Group Link GUI
Table 90 - Service Offer Group Link - srofgrln Parameter Service Retailer*

aservret
Description Reference to the Service Retailer defining the current Service Offer Group Link.
Package*
packref
Reference to the Package in which a Service Offer Group (mentioned below) has to be inserted. Reference to the Service Offer Group that has to be inserted into the Package (mentioned above).

srofgref
11 September 2009
Page 277 of 968
Catalog Structure
Table 90 - Service Offer Group Link - srofgrln Parameter Mandatory

mandaflg
Description Flag indicating whether the Service Offer Group is a default one into the Package.

The Service Offer Group will be accessible to all the users having this Package in their Commercial Offer. It is not possible to subscribe or unsubscribe a default Service Offer Group; the only way of escaping it is to subscribe to a corresponding Barring Service Offer Group (if existing).

The Service Offer Group will be optional, i.e. available for Subscription to all the users having this Package in their Commercial Offer. As long as they dont subscribe to the optional Service Offer Group, they cant access it. Version*
version
Name of the Version of the current Service Offer Group Link.
For a detailed explanation of the Product Catalog versioning, please see chapter 11.,
"Versioning", on page 324.
Start Date*
vstartd
Date at which the Version as mentioned above for the current Service Offer Group Link reaches the status defined below. Versioning Status that the current Service Offer Group Link Version reaches at the Start Date. Before that date, the current Version remains in its previous Status. After that date, the current Version holds the current Status until no other Status has started.
Status*
vstatus
9.9.
9.9.1.
Package Link Object

Object Purpose
A Package Link object allows inserting a Package into a Commercial Offer. A Package can be reused by several Commercial Offers.
Page 278 of 968
11 September 2009
9.9.2.
Figure 109 - Package Link GUI
Table 91 - Package Link - packlnk


aservret
Description Reference to the Service Retailer defining the current Package Link.
Commercial Offer*
coffname
Reference to the Commercial Offer in which a Package (mentioned below) has to be inserted. Reference to the Package that has to be inserted into the Commercial Offer (mentioned above). Name of the Version of the current Package Link.
Package*
packref
Version*
version

Start Date*
vstartd
Date at which the Version as mentioned above for the current Package Link reaches the status defined below. Versioning Status that the current Package Link Version reaches at the Start Date. Before that date, the current Version remains in its previous Status. After that date, the current Version holds the current Status until no other Status has started.
Status*
vstatus
11 September 2009
Page 279 of 968
Catalog Structure
9.10. Bundle/Counter Usage Label Object

9.10.1. Object Purpose
Bundle/Counter Usage Labels are used to give an explicit name to the satellites of the Account: the Bundles and the Counters.
For more information about Bundles and Counters, see chapter 20., "Bundles", on page 799 and chapter 22., "Counters", on page 852.
The Bundle/Counter Usage Label object ensures several functionalities: 1. It provides the actual labelling, allowing to: Assigning a name to Counters and to Bundles, Referencing them in the Counter Criterion, the Bundle Criterion, the Top-up Profile, the Account Profile & Usage Link,... 2. 3. It specifies the unit of the quantities stored in the Bundle or counted by the Counter When the Bundle/Counter Usage Label is the one of a Bundle, it specifies the settings of the Bundle, such as: Is the Bundle a Multiple Buckets one? If the Bundle is a Multiple Buckets one, the maximum number of buckets the bundle is allowed to have. If the Bundle is a single Bucket one, does that unique bucket credit, and thus the bundle credt, have to be reset prior to topping it up?
9.10.2. Parameter Description
Figure 110 - Bundle/Counter Usage Label GUI The parameters this GUI makes available depend on the value of Type* parameter. The figures below show the available entry fields for each possible value of Type*.
Page 280 of 968
11 September 2009
Figure 111 - Bundle/Counter Usage Label GUI When Type* Is Set to Bundle
Figure 112 - Bundle/Counter Usage Label GUI When Type* Is Set to Counter
Table 92 - Bundle/Counter Usage Label - usage Parameter Service Retailer*

aservret
Description Reference to the Service Retailer defining the current Bundle/Counter Usage Label. Name of the current Bundle/Counter Usage Label.
Name*
name
Ratable Unit Metric*

usgunit
This setting only applies to Bundles.
Reference to the Ratable Unit Metric representing the unit of the quantities stored in the Bundle for which the current Bundle/Counter Usage Label is created.
11 September 2009
Page 281 of 968
Catalog Structure
Table 92 - Bundle/Counter Usage Label - usage Parameter Type*

usgtype
Description Type of Account satellite for which the current Bundle/Counter Usage Label is created: Counter or Bundle.
Multi Bucket Bundle

shiftflg
When the Multi Bucket Bundle flag is checked

The bundle is allowed to have more than one bucket.
When the Multi Bucket Bundle flag is unchecked

The bundle cannot have more than one bucket.

You CANNOT modify a Multi-Bucket Bundle into a Mono-Bucket Bundle and vice-versa. If you attempt to modify the value of this parameter, you will get an error message. After a Bundle/Counter Usage Label of type bundle has been created, you no longer can modify the value of this parameter. That is, if you attempt to do so, you will receive, at time you select MODIFY command, a message telling you that only the allowed changes will be taken into account. The message will also ask you whether you want to cancel the MODIFY command (restores original data) or not (saves only allowed changes). This setting only applies to Bundles.
Maximum Number of Buckets

maxroll
This parameter value is used only if Multi Bucket Bundle flags is checked. This parameter then indicates the maximum number of buckets the bundle may contain. To indicate the bundle may contain an unlimited number of buckets, set this parameter to zero. Entering no value in this parameter is the same as setting it to zero.
After a Bundle/Counter Usage Label of type bundle has been created, you no longer can modify the value of this parameter. That is, if you attempt to do so, you will receive, at time you select MODIFY command, a message telling you that only the allowed changes will be taken into account. The message will also ask you whether you want to cancel the MODIFY command (restores original data) or not (saves only allowed changes).
Page 282 of 968
11 September 2009
Table 92 - Bundle/Counter Usage Label - usage Parameter Order of Bucket Usage

way_flg
Description
This parameter indicates in what order the buckets of the Bundle, when used for charging, should be taken. You can choose between the following values: Youngest first - based on Creation Date The buckets will be used from the youngest to the oldest one. Note: When doing a Top-Up on a multi-bucket bundle (within a specific Service Offer Definition), the top-up replaces the oldest bucket first. It does NOT replace the youngest bucket, even if the attribute 'Order of Bucket Usage' is set to "Youngest first - based on creation date". Oldest first - based on Creation date The buckets will be used from the oldest to the youngest one. Note: A Top-up on an Account containing a multibucket bundle with Maximum allowed buckets does not depend upon the Order of Bucket Usage attribute: it selects the bucket to be reset based on oldest Creation date only. The bucket selected for reset is always the one with oldest Creation Date, no matter the option selected in Order of Bucket Usage. Earliest expiry date first The Bundles buckets are to be used in ascending order of the end date of their validity, thus from the bucket whose validity period terminates first up to the bucket whose validity period terminates last. Only the buckets whose validity period is ongoing at the moment of the Bundles use are considered. Latest expiry date first The bundles buckets are to be used in descending order of the end date of their validity, thus from the bucket whose validity period terminates last down to the bucket whose validity period terminates first. Only the buckets whose validity period is ongoing at the moment of the Bundles use are considered.
Order of Bucket Usage based on Expiry Date is only applied on the buckets which are Activated at creation. In other words, the Expiry Date option will work only for Active buckets. When the Top-up profile contains the option "Buckets Activated at first use", the Order of Bucket Usage based on Expiry Date must not be used.
The end date of the validity of a Bucket is given by its To parameter (see Bucket objects parameter To, page 802).
11 September 2009
Page 283 of 968
Catalog Structure
Table 92 - Bundle/Counter Usage Label - usage Parameter Reset Bucket value at Top-Up
resetflg
Description
This setting is only available for bundles for which Multi Bucket Bundle is not checked.
This flag indicates if the Bundle value has to be reset when it is topped-up.
When the Reset flag is checked

The single-bucket Bundles previous value is lost when a top-up is performed on it.
When the reset flag is unchecked

The single-bucket Bundles previous value is added to the topped-up amount in case of top-up.
9.11. Product Catalog Performance Improvement

If we have a complex commercial offer, then the following rule is applied: The most important or frequently used packages must have their name in alphabetical (increasing/ ascending) order. This permits the creactor to scan/select them in the first position.
This configuration helps to improve the performance by reducing the product catalogue scanning/ traversing time. For example, most frequently used "voice_package" is renamed as "a_voice_package" to get it scanned/ selected in the first instance.
Page 284 of 968
11 September 2009
10. Users Portfolio
In a Nutshell... The Product Catalog is a static framework ultimately defining the possible combinations, at one users level, between the Service Offers created by the network operator. There is one single Product Catalog, but so many possible actual combinations realized by the users. Each user, at a given moment, has its own Portfolio.
10.1. What defines a Users Portfolio?

There are two relevant perspectives on the Product Catalog:
1.
2.
the Product Catalog as a static structure of Offers, as defined independently from any user;
the Product Catalog subset effectively available to a given user, which is potentially unique to that user. This chapter describes the objects showing, for a given user, what his current effective use of the Product Catalog is; in other words, this is the users portfolio.
A user can either be an Account or a Customer. Nevertheless, this distinction globally makes no difference for understanding how the portfolio is composed. Thats why in this chapter, we intentionally talk about users. Three objects offer a view of what binds the user (whether an Account or a Customer) to the Product Catalog. The instances of those three objects, for a given user, provide a picture of his/her current bond(s) to the Product Catalog, that is to say: 1. 2. 3. the set of default Service Offer Groups that he/she can access (i.e. his Commercial Offer); the optional Service Offer Groups that he/she has subscribed to for additional access (or for additional features); the status of the next debit or credit operation scheduled on his/her Account, independently from the events he/she may perform by him/her-self on the network, committed by the user by means of a Subscription.
11 September 2009
Page 285 of 968
Users Portfolio
10.1.1. First and main link to the Product Catalog: link to a Commercial Offer
For any user, there is one basic link to the Product Catalog. It determines, among the whole Product Catalog, the exclusive sub-set to which the user will be able to get access to: his/her own Commercial Offer. What does the Commercial Offer enable the user to?
1.
2. 3.
access all the default Service Offer Groups;

subscribe to the optional Service Offer Groups of the related Commercial Offer; subscribe to barring Service Offer Groups (if they exist in the Commercial Offer) allowing to drop the default SOGs of the Commercial Offer.
There are no user without Commercial Offer. This first and main link from the user to the Product Catalog is materialized by the default Commercial Offer parameter, defined in either the Account object (see parameter Commercial Offer, page 750) or the Customer object (see parameter Commercial Offer (default), page 889). Note: For an isolated user, there can be only one Commercial Offer. Nevertheless, when the user belongs to one or more Communities, he is assigned one Commercial Offer per Community that he is part of. For a detailed explanation on how these multiple links to the Product Catalog are ruled, see chapter 10.3.1.2, "One or more Commercial Offer(s) per Customer?", on page 288.
When the user is a Customer belonging to one or ore Communities, then his/her link(s) to the Product Catalog is (are) defined via the Commercial Offer Link object. For a complete description, see chapter 10.3, "Commercial Offer Link Object", on page 288.
10.1.2. Second type of link to the Product Catalog: Subscriptions

Inside the unique Commercial Offer of the user, there are optional Service Offer Groups. This means that, when only a link to a Commercial Offer binds the user to the Product Catalog, these Service Offer Groups are not accessible to the user. In order to get access to an optional Service Offer Group, the user needs to be linked explicitly again to it: this is done via a Subscription. There can be Subscriptions only to the optional Service Offer Groups of the users Commercial Offer. However, among the optional Service Offer Groups of this Commercial Offer, no limitation applies to the number of Subscriptions. As opposed to the Commercial Offer of the user, the Subscription presents more sophisticated features. The table below lists the major differences between the Commercial Offer bound to the user and the Subscription(s) added by the user to his portfolio.
Table 93 - Commercial Offer Vs. Subscription Commercial Offer Is not granted for a limited period of time Doesnt imply a charge Doesnt imply any periodicity Does not have a state Subscription Has a start and an end May imply one or more charges May imply one or more periods Is conditioned by a life cycle of up to 5 states
Page 286 of 968
11 September 2009
Table 93 - Commercial Offer Vs. Subscription Commercial Offer Cannot be suspended or cancelled Subscription Can be suspended or cancelled
For a complete description, see chapter 10.4, "Subscription Objects", on page 290.
10.1.3. Third type of link to the Product Catalog: Scheduled Events

For some of the Service Offer Groups that the user has access to (whether default ones of his Commercial Offer or optional ones that he subscribed to), the Product Catalog defines events that lead to charge (most often) and/or to a top-up on the users Account. These events are not initiated by the user, but by the CRE system itself, at the appropriate time. Even though these events are initiated and processed internally within the CRE, it is possible to have a view, for any user, on the next such event planned and all its characteristics. This functionality is fulfilled by the Scheduled Event object, which is the third interface through which one can see the users actual link(s) to the Product Catalog. For a complete description, see chapter 10.5, "Scheduled Event Objects", on page 305.
10.2. Visualizing what binds a user to the Product Catalog

The table below specifies, for each type of users, what object instances define and show the users links to the Product Catalog.
Table 94 - What defines and shows a users portfolio? If the user is... an Account What Commercial Offer applies? Default Commercial Offer defined in the Account a Customer involved in no hierarchy Default Commercial Offer defined in the Customer a Customer involved in one or more hierarchies 1 instance of Commercial Offer Link (per Community) What are the optional SOGs subscribed to? 0 to n instances of Account Subscription 0 to n instances of Customer Subscription 0 to n instances of Customer Subscription (per Community) What is the next scheduled event to be processed by the CRE for this user? 0 to n instances of Scheduled Account Event 0 to n instances of Scheduled Customer Event 0 to n instances of Scheduled Customer Event (per Community)
11 September 2009
Page 287 of 968
Users Portfolio
10.3. Commercial Offer Link Object

The Commercial Offer Link object links a Customer to a Commercial Offer, in the context of a Community to which he belongs. So this Commercial Offer is valid for a given event only if the Customer can find a payer in the related Community.
10.3.1.1. Important corollaries

1. When a Customer belongs to no Community, his Commercial Offer can be defined by either the Customer object (see parameter Commercial Offer (default), page 889). or the unique Account of this Customer (see parameter Commercial Offer, page 750). 2. When a Customer belongs to one or more Communities and has no default Commercial Offer, then it just means that no Commercial Offer can be applied when none of his Communities agrees to pay for his events. As a consequence, such events will be barred. Basically, this Customer only has access rights to the Services when somebody else pays for him.
10.3.1.2. One or more Commercial Offer(s) per Customer?

From a logical standpoint, there must be one single Commercial Offer per user. This is obvious: a user chooses, among the whole Product Catalog of his/her Service Retailer, one payment scheme for each Service he intends to have access to. For example, I choose to take the Business Commercial Offer, because the pricing scheme is appropriate to my personal consumption. In that case, I wont register at the same time to the Family Commercial Offer. Indeed, the Rating Engine knows according to what rule the cost must be computed according to the settings of the unique Commercial Offer of the user. If more than one Commercial Offer were applicable to a given user, how would the Rating Engine know in which Commercial Offer to find the Rating Rule applicable to a given event? It would simply be impossible. Concretely, this means that the user selects one Commercial Offer within the Product Catalog to be his/ her unique Commercial Offer. This rule mustnt be bypassed, but when a user belongs to a Community, he/she has a specific Commercial Offer in the context of that particular Community.
What does in the context of a Community mean?
First of all, you must keep in mind that the Community is a charging-related concept. Being part of a Community basically means that there is at least one other user (or in a more complex case, a structured tree hierarchy) who agrees to be charged for some events of mine (of which Service, in which cases, under what conditions,... being all specified in Charging Rules). So, in the context of a Community means when the event eventually gets paid by another user, thanks to a given Community membership. For instance, when my voice calls are paid by my company (because performed during working hours), this is done thanks to the fact that I belong to the Corporate Community. In that case, the applicable Commercial Offer is the one thats been assigned to me by the Community itself. Once again, this is only logical. Indeed, when my company allows me to join the Corporate Community, its goal is to pay for the events I perform during working hours. Since the company is the payer, it makes sense that the company has the right to choose the scheme that will define my events rate. Conversely,
Page 288 of 968
11 September 2009
it would rather be nonsense to have a company agreeing to pay for my events, at the rate that I individually chose for my personal private consumption. There would be no cost control possible for the company then! On the other hand, for the events that my company definitely wont pay, there is no reason either that Id have to pay with their rating scheme. In conclusion, the question One or more Commercial Offer(s) per Customer? can be answered as follows: A Customer can be linked to several Commercial Offers: one for himself as an individual, plus one per Community that he belongs to. Nevertheless, when the CRE is triggered by an event of that Customer, only one Commercial Offer is taken into account: the one of the Community providing a payer. The multiplicity of Commercial Offers at one Customers level has a strong impact on the Guiding issue. Thats why its important to understand which one of the Customers Commercial Offers applies to a given event.
For detailed explanation, see chapter Guiding Rules, section 8.2, "Commercial Offer Application Order", on page 254.
Figure 113 - Commercial Offer Link GUI
Table 95 - Commercial Offer Link - comoflnk Parameter Service Retailer*

aservret
Description Reference to the Service Retailer defining the current Commercial Offer Link. Reference to the Customer registering to the Commercial Offer (mentioned below).
Customer*
clt_ref
11 September 2009
Page 289 of 968
Users Portfolio
Table 95 - Commercial Offer Link - comoflnk Parameter Community*

commu
Description Reference to the Community of the Customer in which the current Commercial Offer Link is valid. Concretely When a Customer belongs to several Communities, he registers to one particular Commercial Offer per Community. The actual Commercial Offer taken into account for processing a given event is the one of the Community in which the Customer finds a payer (via a Charging Rule).
Commercial Offer*
coffname
Reference to the Commercial Offer that the Customer (mentioned above) registers to.
10.4. Subscription Objects

By means of the Subscription object, an operator can create the explicit link that allows a user to use (i.e. get access to) an optional Service Offer Group of his/her Commercial Offer, in order to add those Services to those he/she is already using. Be aware that: You can only create a Subscription for an optional Service Offer Group of a Commercial Offer. Since the goal of a Subscription is to give a right to use, and since that right to use is granted by default in the case of default Service Offer Group, there is no point in creating a Subscription for a default Service Offer Group. The Customer can only make Subscriptions among the optional Service Offer Groups of his own Commercial Offer. No cross-Commercial Offer Subscriptions can be done. Consequently, if the Customer belongs to several Communities, his Subscriptions are only valid in the context of one specific Communitys Commercial Offer.
For more details, see section 10.3.1.2, "One or more Commercial Offer(s) per Customer?", on page 288.
10.4.1.1. Customer or Account?

As only a user can have a Commercial Offer, you create a subscription for a user. That is, for either a Customer or an Account.
See also User, on page 34.
As a result, two similar but distinct objects exist for creating Subscriptions. These are: the Customer Subscription object, and the Account Subscription object.
Page 290 of 968
11 September 2009
10.4.2. Customer Subscription Object

Figure 114 - Customer Subscription GUI - main window
Table 96 - Customer Subscription- subsc_ce Parameter Service Retailer*

aservret
Description Reference to the Service Retailer defining the current Subscription.
Customer*
clt_ref
Only in Customer Subscription object
Reference to the Customer for which the current Subscription is created. Reference to the Service Offer Group to which the Customer subscribes. This Service Offer must belong to the Commercial Offer of the Community specified above. Reminder It is only possible to subscribe to the Service Offer Groups that are optional within the Commercial Offer. The other ones (i.e. the ones for which the Mandatory flag has been checked in the Service Offer Group Link object) are automatically assigned to the Customer when he registers to the Commercial Offer. It is not possible to subscribe or unsubscribe them: only a Subscription to a potential Barring Service Offer Group can disable the features of a Default Service Offer Group.

srvofgpe
11 September 2009
Page 291 of 968
Users Portfolio
Table 96 - Customer Subscription- subsc_ce Parameter State

csstate
Description State of the current Subscription. A Subscription always holds one of the following 7 States. Created (csstate = 0) Active (csstate = 1) Suspended - Customer Care Level (csstate = 2) Suspended - Low Credit - Retry (csstate = 3) Suspended - Low Credit - No Retry (csstate = 4) Cancelled (csstate = 5)
Obsolete (csstate = 6) The State of the Subscription basically determines two important features for the user: 1. the authorization for performing usage events of the Service Offers included in the Service Offer Group subscribed to; 2. the potential fees to be paid for the Subscription itself.
For detailed info, see 10.4.4, Subscriptions Life Cycle, on page 296.
Disable Activation and/or Deactivation Fee(s)
feeavail
This flag indicates whether the activation and cancellation fees for the current Subscription should be disabled.

Then the fees defined (typically in the Non-Recurring Charges Service Offer of the Service Offer Group subscribed to) as Activation Fees (i.e. when the Subscription becomes Activated), or as Cancellation Fees (i.e. when the Subscription becomes Terminated in a forced manner, earlier than foreseen) wont be applied to the current Customer.

Any Activation or Cancellation fees defined will be normally applied to the Customer. This parameter is mainly a management facility: the operator can modify the flags value between the Activation and Cancellation moments, simply by using the MODIFY command. Customer Subscription Row ID
Row ID of the current Customer Subscription object instance within the CREs Oracle database. This is a display-only field.
Page 292 of 968
11 September 2009
Table 96 - Customer Subscription- subsc_ce Parameter Customer Community

commun_r
Description
Reference to the Community of the Customer in which the current Subscription is valid. Concretely, this Community will restrict the set of Service Offer Groups available for Subscription to the optional Service Offer Groups of the Commercial Offer valid in this particular Community (see Commercial Offer Link). Reminder When a Customer belongs to more than one Community, he/she registers to one Commercial Offer per Community (via a Commercial Offer Link). Since a Subscription can only be taken among the optional Service Offer Groups of a Commercial Offer, the Subscription of a Customer are limited to the Service Offer Groups of the Commercial Offer valid in a particular Community.
Creation Date
credat
Date and time at which the current Subscription is created in the database. Every Subscription gets the Created state at the moment of its creation. Date and time at which the current Subscriptions state becomes Active.
Activation Date
activedt
Forced Charging Date

syncchdt
This date is the one with which the scheduled events can be synchronized, provided that the synchronization flag is checked in the Service Offer Definition (see parameter Align with Subscriptions Synchronization Date, page 242). The Forced Charging Date is stored in the accfee object and not in the Subscription object. Even if the Align with Subscriptions Synchronization Date flag is checked in the Service Offer Definition (Recurrence tab), it is not possible to keep the "Forced Charging DT" in the Account Subscription object while creating. It disappears when the Account Subscription is created or modified.
For more details, see 14.2.1, Conditions for Enabling the Synchronization, on
page 505 and 14.2.2, Cases of Refused Synchronization, on page 506.
Why synchronizing? Keep in mind that the Service Offer Group that the Subscription gives access to may contain several Service Offers of type non-usage. The aim of this parameter is to align the various scheduled events to the same date, the same cycle (typically a billing cycle). For instance, the Service Offer Group may include three Service Offers of monthly fees, which the cycle of start on a different day for each. By synchronizing them to this Forced Charging Date, you re-align their three cycles to a single one. Note: A scheduled event is generally a charge applied to an Account. Thats why this parameter is called Forced Charging Date. However, dont forget that a scheduled event can also consist in a top-up.
11 September 2009
Page 293 of 968
Users Portfolio
Table 96 - Customer Subscription- subsc_ce Parameter Suspension Date

suspdat
Description Date and time at which the current Subscriptions state becomes Suspended.
Reactivation Date
unsuspdt
Date and time at which the current Subscriptions state becomes Active again, after being Suspended. Date and time at which the current Subscriptions state becomes Cancelled. Remark Youll notice that, contrarily to the Commercial Offer registration (defined in the Account or in a Commercial Offer Link), which has no end date, the Subscription has a limited duration. For future cancellation date we have to set state as 'Cancelled' and then Modify.
Cancellation Date
stopdat
Figure 115 - Customer Subscription GUI - History tab
Table 97 - Customer Subscription - History tab Parameter Suspension Date Description
Suspension date of the current Customer Subscription. Only the last five State changes are displayed. Format: Date and Time, i.e. DD/MM/YYYY hh:mm:ss.
For more details, see 10.4.4.6, Subscription History, on page 304.
Page 294 of 968
11 September 2009
Table 97 - Customer Subscription - History tab Parameter Reactivation Date Description
Reactivation date of the current Customer Subscription. Only the last five State changes are displayed. Format: Date and Time, i.e. DD/MM/YYYY hh:mm:ss.
For more details, see 10.4.4.6, Subscription History, on page 304.
10.4.2.2. Automatic Customer Subscription Activation

Optionally, CRE now also supports automatic activation of customer subscriptions when the firscall for the customer is done. The feature is performed by external module "SCMD" which activates the customer subscriptions. CRE only sends the request to "SCMD" module for the automatic customer subscription activation. The feature is activated if the "FIRST_CALL" arena is existing in Customer. CRE sends list of all the Customers in the heirarchy leg for which this is the first call. For more details please see the Detail design document for "SCMD" module.
10.4.3. Account Subscription Object


The Account Subscription object is almost identical to the Customer Subscription object. It implements the exact same functionality. The only difference between a Customer Subscription and an Account Subscription lies in the type of user they are linked to: a Customer or an Account (see 10.4.1.1, Customer or Account?, on page 290). Consequently, in the Account Subscription object, youll find a reference to an Account Identifier, instead of a reference to a Customer Identifier. Since Accounts cannot be part of Communities, as opposed to Customers, you wont find the Community parameter in the Account Subscription object. For the description of the Account Subscriptions parameters, please refer to the Customer Subscription object: see page 291.
11 September 2009
Page 295 of 968
Users Portfolio
Figure 116 - Account Subscription GUI
Table 98 - Account Subscription Parameter Account Identifier* Description
Only in Account Subscription object
Reference to the Account for which the current Subscription is created.
For detailed explanation about when a Subscription is created for an Account

(instead of a Customer), please see 10.4.1.1, Customer or Account?, on page 290.
Other parameters
See Customer Subscription object on page 291.
10.4.4. Subscriptions Life Cycle

10.4.4.1. Subscription States
The table below describes the 7 potential states of a Subscriptions life cycle. See also 10.4.4.4, Subscription States Transitions, on page 303.
Table 99 - Subscription States State Created Description When the Subscription is Created, the instance of the Subscription is created in the database, but the Subscription is not effective yet. The user cant access the Service Offers of the Service Offer Group subscribed to, until the state becomes Active. When the Subscription is Active, the user can actually access the Services of the Service Offer Group that he subscribed to and hence perform usage events.
Active
Page 296 of 968
11 September 2009
Table 99 - Subscription States State Suspended... Description When the Subscription is Suspended, the user can no longer access the Services of the Service Offer Group that he subscribed to, although the theoretical end date of the Subscription is not reached yet. The State becomes Suspended typically when the user doesnt meet all his duties regarding the Subscription, e.g. paying the recurring charges. Regularization the users situation brings the state back to Active. Suspended CC Level Suspended Low Credit Retry
Sub-label of the functional state Suspended.
This status is assigned to the Subscription when its been suspended via a management operation, typically performed by a Customer Care agent.
This status is assigned to the Subscription when its been suspended because some fees due for it havent been paid because the Account didnt have enough credit. In this case, the event will trigger the CRE again for attempting to charge the Account. If the retry is successful, then the Subscription will become Active again. Whether the suspended Subscription has to be retried or not is determined in the Service Offer Definition (see parameter Scheduling Engine Behavior in Case of Error, page 239).
11 September 2009
Page 297 of 968
Users Portfolio
Table 99 - Subscription States State Suspended Description

Low Credit No Retry
This status is assigned to the Subscription when its been suspended because some fees due for it havent been paid because the Account didnt have enough credit. In this case, the fee event wont be sent again by the Scheduling Engine; there is no automatic way for reactivating the Subscription. Whether the suspended Subscription has to be retried or not is determined in the Service Offer Definition (see parameter Scheduling Engine Behavior in Case of Error, page 239).
Cancelled
When the Subscription is Cancelled, the user has no longer access to the Services of the Service Offer Group that he subscribed to. The usage events are barred and the scheduled events are in Cancelled status. When a Subscription is Obsolete, it is ready to be removed from the database in a clean manner. See 10.4.4.5, Removing a Subscription, on page 304.
Obsolete
Page 298 of 968
11 September 2009
The constraints on the dates of the Customer and the Account Subscription objects have been reinforced to keep a strong coherency on the data of these object, as follows: Table 100 - Constraints on dates When current state is... created and previous state is... Constraints on dates are: Creation date is available Other dates should be null. active created Creation date and activation date are not null Other dates should be null. active suspended Creation date, activation date, reactivation date are not null Other dates should be null. suspended (all types) Creation date, activation date, suspension date are not null Other dates should be null depending if current date is smaller than reactivation date. active Creation date, activation date, cancellation dates are not null Other dates should be null depending if current date is smaller than reactivation date.
cancelled
cancelled
suspended
Creation date, activation date, cancellation date, suspension dates are not null Other dates should be null depending on the current date.
obsolete
created
Creation date is not null Oher dates should be null.
obsolete
cancelled
Creation date, activation, date cancellation date, suspension date are not null Other dates should be null depending on the current date.
Note: all the checks on the dates performed in the subscription (old and new ones above) are bypassed when the Account or the Customer linked to the subscription is used for test purposes - i.e. when the flag Operator Specific of the Account GUI is checked or the Status of the Customer is set to Test.
10.4.4.2. Automatic Subscription Activation

In the service providers provisioning process, it may be interesting, when creating new Accounts, to create at the same time the corresponding Account Subscriptions. Such a provisioning eventually aims at automatically activating the Account and all its Subscriptions. In other terms, the start of the Accounts life cycle should correspond with the start of the life cycle of the predefined Subscriptions of that Account.
Automatic but not instantaneous
11 September 2009
Page 299 of 968
Users Portfolio
The activation of the Subscription is automatic but not instantaneous. Indeed, while the Accounts life cycle activation is performed on-call, the activation of the Subscription is performed via the Scheduling Engine. Therefore, at least three factors can delay the actual activation of the Subscription: the RE/CE CPU load, which can impact the pace at which the Scheduled Events are processed; the configuration of the Scheduling Engine, which determines how often the Scheduled Events List is screened by the Scheduling Engine; the potential error mode of the Scheduling Engine partition, which prevents any Scheduled Event to be processed until the partition is manually set back to the active mode. The automatic Subscription activation capability of the Convergent Rating Engine is presented in this section. For more details about this features limitations and implementation, read below.
10.4.4.2.1.Conditions for automatically activating a Subscription

If you want to automatically activate the Subscriptions, the following four conditions must be fulfilled: 1. The feature has to be enabled when creating the RE Configuration object, at installation time. This setting can never be modified later on, even by the operator logged as installer! See parameter Automatic Subscription Activation, page 96. 2. The Subscription must be an Account Subscription. The feature is not available for Customer Subscriptions. Indeed, the Customers dont have a life cycle and as such are not activated.
3.
The Service Offer Group of the Subscription must include at least one Scheduled Event. Indeed, the automatic Subscription activations implementation is based on a Scheduled Event, which is launched in real-time by the Scheduling Engine for activating the Subscription. So the condition is to be understood as follows: the Service Offer Group subscribed to must include at least one non-usage Service Offer. The corresponding Service Offer Definition must define at least one Scheduled Event: a recurring event or an activation fee (see Service Offer Definition object, on page 235). If this condition is not fulfilled, a warning message will pop up when you create the Subscription.
4.
The Accounts life cycle activation must occur via the first call An Account in the Created or Valid life cycle status is automatically set to the Active status on call, when the first call occurs. A first call is either a first reservation, either a one-shot rating and charging request, or the payment of any fee. So if a Subscription is activated manually via the GUI, and an activation fee is consequently launched by the Scheduling Engine, then the Accounts life cycle status will be set to Active, and all the other Subscriptions will be automatically activated as well. If the Account is set to the Active life cycle status via the GUI or via a LiteSCE script, it wont be considered as a first call. So the Subscriptions wont be activated automatically.
If any of those 4 conditions is not fulfilled, the Subscriptions have to be activated manually.
Page 300 of 968
11 September 2009
Note: Any Subscription that is created after the first call was done on the Account has to be created in Active state. No more Subscriptions will be automatically activated afterwards, since subsequent calls are no longer first calls.
10.4.4.2.2.Implementation and Call Flow

The automatic Subscription activations implementation is based on the mechanism of automatic Subscription life cycle management by the Scheduled Events. Indeed, each Scheduled Event has a particular Status, which determines two things: the next Scheduled Event to be potentially generated and the potential Subscription life cycle modification to be performed in the database.
See more details in 10.5.4.1, Status List Description; more specifically the To be activated Status, on page 314.
The automatic Subscription activation is performed in three phases.
Phase 1 - At installation time: RE Configuration

The operator logged as installer must enable the Automatic Subscription Activation feature when he creates the RE Configuration object, once for all. See page 96.
Phase 2 - Via the GUI: Subscription creation

For an Account in the Created or Valid life cycle status, the operator creates an Account Subscription, in the Created State. The Scheduled Account Events corresponding to that Subscription are automatically created by the CRE. They get the Created Status, except for activation fees, which get the To be terminated Status (see page 318). The Scheduled Account Event(s) dont have a predefined Next Date (see page 312), so they are not yet inserted in the queue of the Scheduling Engine.
Phase 3 - In real-time: Subscription activation

A first call occurs with the Account, of which the life cycle status is automatically changed to Active. The CRE then updates the Scheduled Account Events in the To be activated status by setting their Next Date to the call date, so now. These Scheduled Account Event(s) are then immediately inserted in the Scheduling Engines queue, and launched immediately. The CRE is triggered by the Scheduled Account Event(s), which the effect of is to activate the corresponding Account Subscription.
11 September 2009
Page 301 of 968
Users Portfolio
Table 101 - Automatic Subscription Activation: Summary Account Steps Life Cycle status Created Account Subscription State Created Scheduled Account Event Status Createda / To be terminatedb 2 3 First Call Scheduled Account Event processing Active Active Created Active To be activated / To be terminated call date (NOW) Next Date none
Creation
See 10.5.4.2, Scheduled Events Status Transitions, on page 316.
a. Status for a Scheduled Event that is a recurring fee. See status Created page 316. b. Status for a Scheduled Event that is an activation fee. Read more in 10.6.1, Activation Fees, on page 318.
10.4.4.3. State and Dates: troubleshooting discrepancies

The following case should normally not occur, but faulty management operations might lead you to a misleading display of a given Subscription in the GUI. In case of discrepancy between the displayed State and the dates defining the Life Cycle of the Subscription, keep in mind that the dates prevail over the State, because the execution logic of the Convergent Rating Engine is anyway based on the dates. The example below shows how to sort out discrepancies in the Subscription GUI.
Page 302 of 968
11 September 2009
If NOW is August 20, 2006 (20/08/2006) and the following GUI is displayed:
The State displayed by the GUI is Active...
... but it appears that the Subscription has actually been suspended 2 days ago, and will only be reactivated in 7 days from now.
So the actual State of the Subscription NOW is Suspended. The Convergent Rating Engine will behave like with any suspended Subscription: the attempted usage events will be blocked.
10.4.4.4. Subscription States Transitions

The Subscriptions life cycle has a unique direction, starting at creation and ending at obsolescence. The only reversible state transition is the one from Active to Suspended: a Subscription can be unsuspended, i.e. reactivated. The Subscriptions state flow can be one of the following: Created > Active (> Suspended > Active)1 > Cancelled > Obsolete Created > Active (> Suspended > Active)2 > Suspended > Cancelled > Obsolete Created > Obsolete
1. The Subscription can be suspended and re-activated any number of times. 2. The Subscription can be suspended and re-activated any number of times.
11 September 2009
Page 303 of 968
Users Portfolio
SUSPENDED
on ati ell nc Ca
Reactivation
CREATED
Suspension
ACTIVE
CANCELLED
OBSOLETE
Creation
Activation
Cancellation
Obsolescence
Removal
Obsolescence
Figure 117 - Subscriptions Life Cycle The dates at which those state transitions last occurred or will occur are displayed in the Subscription GUI. Creation: see parameter Creation Date, page 293. Activation: see parameter Activation Date, page 293. Suspension: see parameter Suspension Date, page 294. Reactivation: see parameter Reactivation Date, page 294. Cancellation: see parameter Cancellation Date, page 294. Obsolescence: the date of this management operation has no functional interest. Removal: the Subscription object instance no longer exists.
10.4.4.5. Removing a Subscription

For being removed, i.e. permanently deleted from the database, a Subscription must be in Obsolete state. It is impossible to remove a Subscription with any other state.
Explanation
When a Subscription is in Obsolete state, all Scheduled Events existing for that Subscription are removed. This ensures that the removal of the Subscription is a clean operation. It guarantees that the database and the Scheduling Engines list dont contain any instances of Scheduled Events referencing Subscriptions that no longer exist.
10.4.4.6. Subscription History

In a given Subscriptions life time, there can be several suspension periods. When a Subscription is suspended, the access to the related Service Offer Group is blocked, and the specific rating features of the Subscription are not available for the Customer. Some events are not processed in real-time by the Convergent Rating Engine. Typically, these can be events of a postpaid service, or events submitted by an non-real-time external module like in case of roaming.
Page 304 of 968
11 September 2009
When processing events a posteriori, it is important to know if the Subscription was suspended or not at the time of the event. For instance, if the Friends and Family Add-on Subscription was suspended at the time of the call, the rating of that call mustnt use the special rate of the Friends and Family offer. So the Subscription History feature of the Convergent Rating Engine offers two main advantages: 1. 2. It allows the processing of non-real-time events, in compliance with the actual State of the Subscription at the time of the event. It shows the last five State changes of the Subscription in the corresponding GUI.
Limitations of the Subscription History feature

It is only available for Customer Subscriptions in the release 2.6.2 of the Convergent Rating Engine. It is limited to the last five changes. It must be activated in the RE Configuration at the time of installation. See Customer Subscription History Enabled, on page 95.
See also 27.1.4, Commercial Offer History, on page 900.
10.5. Scheduled Event Objects

The Scheduled Event object represents a non-usage event, made up for triggering the Convergent Rating Engine on a non-usage Service Offer. The Scheduled Event object contains all the information necessary for the processing of the event by the Scheduling Engine and by the Community and Rating Engines.
Important Advice
The visualization purpose is the essential reason why the Scheduled Event GUI is available through the management interface. However, keep in mind that all the scheduled events to be generated and executed for a given Subscription are automatically created and managed by the Convergent Rating Engine.
No management operation on the Scheduled Event object is required, except in some error cases. The only regular management interface is the Subscription GUI.
10.5.1.1. Standard Mode: Display Functionality

The Scheduled Event object always refers to a Subscription. A Subscription links a user to a Service Offer Group. This Service Offer Group may include a Service Offer of type non-usage, i.e. defined by a Service Offer Definition. The events triggering the CRE on that Service Offer are not initiated by the user, but by the CRE system itself - thanks to the internal module called Scheduling Engine. Whether recurring or not, the events that trigger the CRE on a Service Offer of type non-usage are scheduled, i.e. specifically defined for triggering the CRE at a particular date and time.
11 September 2009
Page 305 of 968
Users Portfolio
For more details on Service Offers of type Non-usage, see section 7.3, "Service Offer Definition object", on page 235.
When a user subscribes, he/she acknowledges his/her duty to the events scheduled by the non-usage Service Offer included in the Service Offer Group subscribed to. The Scheduled Event object shows the next event that the user has actually committed to when he created his/her Subscription. This is usually a charging event, but can also be a top-up event. In case of failure to this commitment, the Subscription will typically change state (configurable behavior defined in the Service Offer Definition object, parameter Scheduling Engine Behavior in Case of Error page 239). For example, I subscribe to the optional Service Offer Group for On-demand Video, within my Family Commercial Offer. Inside the Service Offer Group On-demand Video, there is a Service Offer defined by a Usage Rating Rule, specifying a cost for each streaming movie, and a Service Offer defined by a Service Offer Definition, specifying a monthly fee to be paid the first day of each month. When I subscribe to the On-demand Video service, I actually commit to paying that monthly fee. If I ever fail paying the monthly fee, the service access will be suspended. Since the scheduled events recurrence is clearly defined in a Service Offer Definition, it is possible to know, at any time, what the next scheduled event will be. This is what the Scheduled Event object shows.
Whereas the Scheduled Event GUI is essentially offered for providing a view on the current status of a given Subscriptions automatically generated scheduled events, expert operators can also use it for creating new scheduled events. In addition to displaying the next scheduled event to be sent by the Scheduling Engine to the Convergent Rating Engine, the Scheduled Event object can also be used as a provisioning interface, in order to create and define a scheduled event and insert it into the queue processed by the Scheduling Engine for further triggering the Convergent Rating Engine. Of course, the events directly provisioned via the Scheduled Event object still have to comply with (and hence refer to) an existing Subscription. Indeed, the amount of the fee is always defined by a Service Offer Definition, which belongs to a Service Offer Group of the Product Catalog. Therefore, the scheduled event can only be created for a user who did subscribe to that particular Service Offer Group.
10.5.1.2.1.Why Manually Creating a Scheduled Event?

Some Service Offer Groups include Service Offers of type non-usage that cannot be defined in terms of recurrence. For instance, your fixed voice Service Offer Group may define a Fee that is applied when a technician comes to your place for line installation or repair. Obviously, such a fee event is not scheduled in advance. It is a one-shot fee that is typically ordered by the customer service once the technical intervention is done. The fee event is then inserted into the list of events to be launched by the Scheduling Engine.
10.5.1.2.2.Priority of Manually Created Scheduled Events

The priority level of the event is not an available parameter in the Scheduled Event GUI. So the events created via the Scheduled Event object interface automatically get a priority level set to 0 (zero).
Page 306 of 968
11 September 2009
10.5.1.2. Advanced Mode: Provisioning Functionality
Consequently, within the Scheduling Engines job list, these manually created events will have the priority over the scheduled events directly generated by the Service Offer Definitions settings.
10.5.1.3. Customer or Account?

According to your Convergent Rating Engine configuration, your users are defined either as Customers or as Accounts. Depending on this provisioning choice, Customer Subscriptions or Account Subscriptions are created. Consequently, youll have Scheduled Customer Events (referring to Customer Subscriptions) or Scheduled Account Events (referring to Account Subscriptions). Just like for Subscriptions, the two distinct Scheduled Event objects are similar in all points, except in how they refer to the concerned user: a Customer or an Account.
10.5.2. Scheduled Customer Event Object

Figure 118 - Scheduled Customer Event Object GUI
Table 102 - Scheduled Customer Event Object - cltfee Parameter Service Retailer*
servret
Description Reference to the Service Retailer defining the current Scheduled Customer Event. Reference to the Customer to which the current scheduled event applies. Consequently, this is the Customer who subscribed to the Service Offer Group containing the Service Offer of type non-usage that provokes the scheduled event described here.
Customer*
identify
11 September 2009
Page 307 of 968
Users Portfolio
Table 102 - Scheduled Customer Event Object - cltfee Parameter Customer Community*
commun
Description Reference to the Community of the Customer in which the Subscription that the current scheduled event is about is valid. Indeed, a Customer may subscribe only to the optional Service Offer Groups of his Commercial Offer. When he/she belongs to one or more Communities, he / she has one Commercial Offer per Community, and potentially Subscriptions in each of them.
For more details about the various Commercial Offers of a Customer and which
one applies to a given event, see section 10.3.1.2, "One or more Commercial Offer(s) per Customer?", on page 288.
Figure 119 - Scheduled Customer Event Object GUI - General tab
Table 103 - Scheduled Customer Event Object - General tab Parameter Service Name*
service
Description Reference to the name of the Service that the current scheduled event is about. Reminder: When triggering the Convergent Rating Engine, any event must match a Service, for which a Service Offer needs to be found in the users portfolio. In other words, that Service Offer must be included either in a default Service Offer Group of the users Commercial Offer, or in an optional Service Offer Group of the users Commercial Offer, for which he has a Subscription.
Page 308 of 968
11 September 2009
Table 103 - Scheduled Customer Event Object - General tab Parameter Customer Subscription*
subri
Description Reference to the subscribed Service Offer Group (which contains the Service Offer of type non-usage that provokes the scheduled event described here).
Remark: Content of this Attribute You will notice that the list of available choices for the current attribute shows Service Offer Group names. However, the actual reference actually stored in the database is indeed the row ID of the Customer Subscription. It would indeed be quite complex to directly refer to a Customer Subscription instance, since a Subscription has no name. However, a Customer Subscription instance can be identified thanks to the triple key: Service Offer Group, Customer, Service Retailer - which are three parameters provided in this GUI. In conclusion, you actually see in the GUI the name of the Service Offer Group subscribed to, but the actual attribute stored in the database is the row ID of the corresponding Customer Subscription instance.
11 September 2009
Page 309 of 968
Users Portfolio
Table 103 - Scheduled Customer Event Object - General tab Parameter Status
status
Description The status information relates to 1. the next scheduled event to be processed (the next event is scheduled for the Next Fee Date, see below parameter Next Fee Date, page 312), 2. and to the management of the corresponding Subscription. The Convergent Rating Engine sets the status of the next event before posting it to the scheduled event list of the Scheduling Engine, so that the next time it receives the event, the Convergent Rating Engine knows what management operations are associated to the fee and must be performed if the scheduled event is successful. The status is set by the Convergent Rating Engine in accordance with the behavior configured in the related Service Offer Definition. See parameter Scheduling Engine Behavior in Case of Error, page 239. This status is set and used by the Convergent Rating Engine, which processes the event. It has no impact on the Scheduling Engine, which just sends the event to the Convergent Rating Engine at the appropriate time. To be activated To be reactivated
Activated Retry To be suspended Suspended To be cancelled Cancelled To be terminated Terminated
For a complete description of the 12 Statuses, see 10.5.4.1, Status List Description,
on page 314.
Page 310 of 968
11 September 2009
Table 103 - Scheduled Customer Event Object - General tab Parameter Error on Fee
error
Description If an execution error occurs while the Convergent Rating Engine attempts to process the current Scheduled Event (for instance, the Account cannot be identified), the Scheduled Event is immediately and automatically set in Error mode. Only the execution errors related to the data of the user (Customer or Account) can make the Scheduled Event switch to this error mode. The errors linked to the data of the product catalog or the configuration wont impact the status of the Scheduled Event. While the Scheduled Event is in Error mode, it cannot be executed anymore (in other words, it is blocked), and it is impossible to perform any management operation on the corresponding Subscription. If you want to do any management operation on the Subscription, you will get a message prompting you to first unblock the Scheduled Event in Error mode, which you can do only via the Scheduled Event GUI. See detailed explanations in 13.6, Error Management, on page 494.
Figure 120 - Scheduled Customer Event Object - History tab
Table 104 - Scheduled Customer Event Object - History tab Parameter First Fee Date
firstdt
Description Date and Time of the first (successful or not) scheduled event that occurred for this Subscription. Date and Time of last (successful or not) scheduled event that occurred for this subscription.
Last Fee Date

lastdt
11 September 2009
Page 311 of 968
Users Portfolio
Table 104 - Scheduled Customer Event Object - History tab Parameter Next Fee Date
nextdt
Description Date and Time of the next scheduled event to be sent to the Convergent Rating Engine by the Scheduling Engine for this Subscription.
Synchronisation Date
syncchdt
This parameter is available only if you have enabled the Align with Subscriptions Synchronization Date flag in the Service Offer Definition object.
Date and Time that the Next Fee Date must comply with, in order to be synchronized with the Forced Charging Date specified in the corresponding Subscription.
As long as the Synchronization Date is greater than the Next Fee Date, the recurring cycle is not synchronized. Once the Synchronization Date is equal to the Next Fee Date, then the recurring cycle is synchronized. For more details, see 14.2.3, Concrete Examples, on page 506.
For more details about the synchronization, see 14.2, Synchronizing Recurring
Events, on page 505.
# Execution
nb_occ
Total number of times that the Scheduled Event already occurred for this Subscription. To be accurate, this counter is incremented at each successful processing by the Convergent Rating Engine of an event sent by the Scheduling Engine. Consequently, 1. the events retried n times count for one only 2. the non-usage events defined by a Service Offer Definition of type External Triggering are not taken into account in this counter. For more details, see parameter Moment of the Non-usage Event, page 238. The value stored in this field is used for determining the end of a recurrent event, when the Service Offer Definition defines the Termination Type as based on a Maximum Number of Occurrences. See parameter Termination Type, page 243.
Last Cost
lcost
Amount debited or credited (if the non-usage event is actually a Top-up) the last time that the Scheduled Event occurred. This field only shows the amounts removed from or added to the Accounts main balance. The Accounts Bundles are not taken into account.
Page 312 of 968
11 September 2009
10.5.3. Scheduled Account Event Object

The Scheduled Account Event object is almost identical to the Scheduled Customer Event object. It implements the exact same functionality. The only difference between a Scheduled Customer Event and an Scheduled Account Event lies in the type of user they are linked to: a Customer or an Account. (see 10.5.1.3, Customer or Account?, on page 307). Consequently, in the Scheduled Account Event object, youll find a reference to an Account Identifier (instead of a reference to a Customer Identifier) and a reference to an Account Subscription (instead of a Customer Subscription). Since Accounts cannot be part of Communities, as opposed to Customers, you wont find the Community parameter in the Scheduled Account Event object. For the description of the Scheduled Account Event parameters, please refer to the Scheduled Customer Event: see page 307.
Figure 121 - Scheduled Account Event GUI
Table 105 - Scheduled Account Event - accfee Parameter Account Identifier*

identify
Description
Only in Scheduled Account Event object
Reference to the Account to which the current scheduled event applies. Consequently, this is the Account holding a Subscription to the Service Offer Group containing the Service Offer of type non-usage that provokes the scheduled event described here.
For detailed explanation about when a Subscription is created for an Account

(instead of a Customer), please see 10.5.1.3, Customer or Account?, on page 307.
Other parameters
See Scheduled Customer Event object on page 307.
11 September 2009
Page 313 of 968
Users Portfolio
10.5.4. Scheduled Events Statuses

10.5.4.1. Status List Description
The status information relates to the next scheduled event to be processed (the next event is scheduled for the Next Fee Date, see page 312). The CRE sets the status of the next event before posting it to the scheduled event list of the Scheduling Engine, so that the next time it receives the event, the CRE knows what management operations are associated to it and must be performed if the scheduled event is successful. The status is set by the CRE in accordance with the behavior configured in the related Service Offer Definition. See parameter Scheduling Engine Behavior in Case of Error, page 239. This status is set and used by the Convergent Rating Engine, which processes the event. It has no impact on the Scheduling Engine, which just sends the event to the CRE at the appropriate time.
Table 106 - Scheduled Events Statuses Status To be activated Description The next scheduled event will be the first one. It will activate the Subscription. Thanks to this status information, the Rating Engine knows that a prorata will potentially have to be calculated. To be reactivated The next scheduled event will reactivate the Subscription. So the Subscription is currently in the Suspended state, and will roll back to the Active state once the next scheduled event is successfully executed. The To be reactivated status can only be set if the Reactivation Date is known in advance, i.e. already specified in the Subscription. Activated The corresponding Subscription is currently in the Active state. The next scheduled event is a normal one, in the course of a regular ongoing recurring cycle. The previous scheduled event failed. The event scheduled for the Next Fee Date is called a Retry event. While the Scheduled Event is in status Retry, the corresponding Subscription is in the Suspended - Low Credit - Retry state. Once the Retry scheduled event succeeds, the Subscription goes back to the Active state.
Retry
Dont get confused The Retry status doesnt mean that the previous Scheduled Event (the one that failed) is going to be retried and retried again until it eventually succeeds. The failed scheduled event is considered as definitely failed for the period it was supposed to cover. The Retry event (so the next one) is the one for the next period.
Remark The Retry status is due to the failure of the previous Scheduled Event. Failure is intended here as a logical impossibility to charge the Account. So when an event is not properly processed because of a machine or system breakdown, the corresponding Scheduled Event object wont be set to status Retry.
Page 314 of 968
11 September 2009
Table 106 - Scheduled Events Statuses Status To be suspended Description The previous Scheduled Event was the last-but-one before the Subscriptions suspension. So the next Scheduled Event will be the last one until a potential reactivation occurs. After the next Scheduled Event, the Subscription will be set to the Suspended state. The To be suspended status can only be set if the Suspension Date is known in advance, i.e. already specified in the Subscription. To be cancelled The previous Scheduled Event was the last-but-one before the Subscriptions cancellation. So the next Scheduled Event will be the last one. After the next Scheduled Event, the Subscription will be set to the Cancelled state and all the scheduled events related to it will also be automatically set to the Cancelled status. The To be cancelled status can only be set if the Cancellation Date is known in advance, i.e. already specified in the Subscription.
See also 10.5.4.3, Termination Vs. Cancellation, on page 318.
Dont get confused with the Cancellation Fee The next scheduled event is not a cancellation fee, it is the last occurrence of a recurring event. A cancellation fee is a one-shot event, triggering the Rating Engine at the moment of the Subscription cancellation. See 10.6.2, Cancellation Fees, on page 320. So the flag Disable Activation and/or Deactivation Fee(s) has no effect on the next scheduled event.
To be terminated
The previous Scheduled Event was the last-but-one, according to its recurrence definition in the Service Offer Definition. So the next Scheduled Event will be the last one. After its execution, it will be set to the Terminated status. Meanwhile, the state of the Subscription related to the scheduled event is not impacted by the status of the Scheduled Event. Example Figure out a Subscription to a Service Offer Group for Voice. The duration of this Subscription is two years. Within the Service Offer Group subscribed to, a Service Offer defines a recurring non-usage event, for the payment of a monthly fee only during the first year of the Subscription. So this is a two years-long Subscription, and the second year is free. So at the end of the first year, the recurring event charging the monthly fee is Terminated, while the Subscription is still Active for one more year. The To be terminated status can only be set if the termination of the scheduled event is known in advance, i.e. specified in the Service Offer Definition via the parameter Fixed Termination Date (see page 243) or Maximum Number of Occurrences (see page 243).
11 September 2009
Page 315 of 968
Users Portfolio
Table 106 - Scheduled Events Statuses Status Created Description When a Subscription is created, if the Service Offer Group subscribed to includes a Service Offer of type non-usage implying Scheduled Events, those Scheduled Events are automatically created in the database. So when the Scheduled Event is in the Created status, only CRE-internal management operations have been performed. The Subscriptions Life Cycle is not started yet. A Scheduled Event in the Created status cannot be executed. Suspended Due to the Subscriptions suspension, the next Scheduled Event shouldnt occur. The Next Date parameter will be discarded. When a Subscription is suspended, all the related scheduled events are also automatically set to the Suspended status. A Scheduled Event in the Suspended status cannot be executed. Blocked When some management operation is performed on the related Subscription, the corresponding Scheduled Events are automatically set to the Blocked status. While they are blocked, they cannot be executed. Once the Subscription management operations are done, the corresponding Scheduled Events are automatically unblocked and set back to their previous status.
This safety lock is provided for preventing some Scheduled Events to be launched while, for instance, an operator is setting the Subscription to the Suspended state. Cancelled The Subscription to which the current Scheduled Event is related is in the Cancelled state. So all the Scheduled Events associated to it are automatically set to the Cancelled status as well. A Scheduled Event is the Cancelled status cannot be executed.

Terminated The Scheduled Event has been executed as many times as specified in the corresponding Service Offer Definition. No more occurrences of the Scheduled Event will happen. A Scheduled Event is status Terminated cannot be executed.
10.5.4.2. Scheduled Events Status Transitions

The transitions between the Scheduled Events Statuses basically depend on: 1. 2. 3. the scheduled events definition (e.g. recurring or not; all its parameters are defined in the Service Offer Definition), the result of the previous scheduled events execution (successful or not, and why), and the previous scheduled events status.
Page 316 of 968
11 September 2009
10.5.4.2.1.In case of successful execution

When a Scheduled Event is successfully executed, the Result Code sent by the Rating Engine and the Community Engine is 1. Various sub-result codes are defined.
Check out all the result codes and sub-result codes in your Convergent Rating Engine 2.0 DPE Error Codes document.
The diagram below shows all the possible status transitions for Scheduled Events, in case of successful execution.
Retry
Suspended
To be activated Activated To be reactivated To be suspended. Suspended/ To be react. To be terminated Terminated To be cancelled. Cancelled
Note: The difference between
Suspended
and
Suspended/ To be react.
lies in the fact
that a Reactivation Date of the Subscription is known in advance or not.
Figure 122 - Scheduled Event Status Transitions - Successful Execution From this diagram, you can conclude that: No successful execution can lead to the statuses Retry, To be activated, To be reactivated and Suspended. No status transition is possible from the states Suspended, Terminated and Cancelled. A Scheduled Event in one of those statuses cannot be executed.
10.5.4.2.2.In case of unsuccessful execution

When a Scheduled Event is not successfully executed, the Result Code sent by the Rating Engine and/or the Community Engine is 100. Various sub-result codes are defined. The diagram below shows all the possible status transitions for Scheduled Events, in case of unsuccessful execution.
11 September 2009
Page 317 of 968
Users Portfolio
Retry
Suspended
To be activated Activated To be reactivated To be suspended. Suspended/ To be react. To be terminated Terminated To be cancelled. Cancelled
Note: The difference between
Suspended
and
Suspended/ To be react.
lies in the fact
that a Reactivation Date of the Subscription is known in advance or not.
Figure 123 - Scheduled Event Status Transitions - Unsuccessful Execution From this diagram, you can conclude that: No unsuccessful execution can lead to the statuses To be activated, To be reactivated, To be suspended, To be terminated and To be cancelled. No status transition is possible from the states Suspended, Terminated and Cancelled. A Scheduled Event in one of those statuses cannot be executed.
10.5.4.3. Termination Vs. Cancellation

Concerning Subscriptions and Scheduled Events, it is important to clearly distinguish between the notions of Termination and Cancellation. Termination only applies to scheduled events, not to Subscriptions. A Scheduled event is in the Terminated status when its last (potentially unique) occurrence has been executed. The termination of the scheduled event has no direct impact on the Subscriptions life cycle; the Subscription remains in the same state. See example in status To be terminated, page 315. Cancellation applies to the Subscription and to all the scheduled events related to it. At the Cancellation Date, the Subscriptions state shifts to Cancelled, which is irreversible. All the related scheduled events are hence pointless and are automatically set to the Cancelled status as well (potential prorata and refund are calculated).
10.6. Subscription Times

10.6.1. Activation Fees
A non-usage Service Offer can define, within a Service Offer Group, the fee to be paid once, at the moment of the activation of the Subscription to that Service Offer Group.
Page 318 of 968
11 September 2009
Take for instance an optional Service Offer Group for music download. When subscribing to that Service Offer Group, you must pay a one-shot fee of 10 EUR. Concretely, it is the payment of the 10 EUR that actually enables the access to the music download service, for usage events (i.e. download sessions). As long as you dont pay this fee, you cannot access the services of the Service Offer Group subscribed to. This kind of fee is called an Activation Fee: once the fee has been charged, the Subscription gets the Active state. The diagram below shows the transitions of the Scheduled Events status and of the Subscriptions state when an Activation Fee is successfully executed (i.e. the charge is successfully applied to the Account): The Subscription is initially in the Created state, and gets the Active state after the execution of the scheduled event; The Scheduled Event is initially in the To be terminated status, and gets the Terminated status after being executed (see explanation below).
Successful execution of the Activation Fee
Activation Fee
Scheduled Event TO BE TERMINATED
Activation Fee
Scheduled Event TERMINATED
Subscription CREATED
Subscription ACTIVATED
Figure 124 - Activation Fee - Event status and Subscription state transitions Note: The section below explains implementation-related issues, provided for your information. However, keep in mind that the logic described here is the default behavior of the Convergent Rating Engine when you configure an Activation Fee in a Service Offer Definition. The Convergent Rating Engine requires no other management operation from you. In a normal use of the Convergent Rating Engine, you will never need to create or modify a Scheduled Event object.
Why does the Scheduled Event for activation fee have the To be terminated status?
When checking the Scheduled Event GUI, you might wonder why a scheduled event for Activation Fee is in the To be terminated status before being executed. You might rather expect To be activated. If the status were set to To be activated, the payment of the activation fee would automatically set the scheduled event to Activated. When a scheduled event is in the Activated status, you cannot have a total guarantee that it wont trigger the CRE again. Indeed, if for any reason, a Next Date is assigned to the Scheduled Event, then the scheduled event in Activated status will be launched again, at that next date. In such a case, the Activation Fee would then be charged twice! When a Scheduled Events status is set to To be terminated, its successful execution automatically generates a status transition to Terminated. When a scheduled event is in the Terminated status, it cannot be executed anymore, even though a Next Date would be assigned to it. This is typically the behavior that you expect from the CRE when implementing an Activation Fee: you want to make sure that the Fee will be charged to the user once and only once. By using the status transition from To be terminated to Terminated, the CRE adds a safety lock to the Activation Fee and ensures its unique occurrence for a given Subscription.
11 September 2009
Page 319 of 968
Users Portfolio
Constraints on Activation Fees

No prorata and no refund can be applied to Activation Fees.
10.6.2. Cancellation Fees

A non-usage Service Offer can define, within a Service Offer Group, the fee to be paid once, at the moment of the cancellation of the Subscription to that Service Offer Group. Take for instance the optional Service Offer Group for music download. When cancelling that Subscription, you must pay a one-shot fee of 5 EUR. Actually, it is the payment of the 5 EUR that concretely cancels the Subscription. As long as you dont pay this fee, the Subscription remains in its current state (Active or Suspended). This kind of fee is called a Cancellation Fee: once the fee has been charged, the Subscription gets the Cancelled state. The diagram below shows the transitions of the Scheduled Events status and of the Subscriptions state when a Cancellation Fee is successfully executed (i.e. the charge is successfully applied to the Account): The Subscription is initially in the Active or Suspended state, and gets the Cancelled state after the execution of the scheduled event; The Scheduled Event is initially in the To be cancelled status, and gets the Cancelled status after being executed.
Successful execution of the Cancellation Fee
Cancellation Fee
Scheduled Event TO BE CANCELLED
Cancellation Fee
Scheduled Event CANCELLED
Subscription ACTIVE OR Subscription SUSPENDED Subscription CANCELLED
Figure 125 - Cancellation Fee - Event status and Subscription state transitions
10.6.3. Cancelling a Suspended Subscription

When a Subscription is in Suspended state, all the scheduled events related to it are automatically set to the Suspended status as well. When such a suspended Subscription is cancelled, all the related scheduled events (that were suspended yet) are automatically set to the Cancelled status. This means that a suspension period, whatever its duration, is not charged at the moment of the cancellation od the Subscription. If you cancel your Subscription after a period of suspension, you wont pay the fees covering the suspended period.
Page 320 of 968
11 September 2009
Dont get confused
This has nothing to do with the potential Cancellation Fee defined for the Subscription. In all cases, a non-usage event can trigger the Rating Engine at the moment of the Subscription cancellation, in order to charge a fee. See 10.6.2, Cancellation Fees, on page 320. The figure 126 below details a example of cancellation of a suspended Subscription. It shows the step-bystep modifications of the Subscription and Scheduled Event objects.
11 September 2009
Page 321 of 968
Users Portfolio
Subscription Life Cycle
Time
15/08/2006: The Subscription to SOG_VoiceRoaming is created and activated.
The SOG_VoiceRoaming includes a Service Offer of type non-usage, defining a recurring event, charging 5 EUR on the Account every first day of each month. So a Scheduled Event instance is created and posted to the Scheduled Event List.
The first monthly fee will be charged on September 1st. It will make the Status evolve from To be activated to Activated.
Active
01/09/2006: The first occurrence of the monthly recurring fee (of 5 EUR) is launched by the Scheduling Engine to trigger the Rating Engine.
The Scheduled Event is now in Activated Status.
The next occurrence of the Scheduled Event is planned for October 1st.
01/10/2006: The second occurrence of the monthly recurring fee (of 5 EUR) is launched by the Scheduling Engine to trigger the Rating Engine.
The next occurrence of the Scheduled Event is planned for November 1st.
Page 322 of 968
11 September 2009
Subscription Life Cycle
Time
01/11/2006: The third occurrence of the monthly recurring fee (of 5 EUR) is launched by the Scheduling Engine to trigger the Rating Engine.
Active
The next occurrence of the Scheduled Event is planned for December 1st.
26/11/2006: The Subscription is suspended by an operator.
Suspended
The Subscription State is set to Suspended and the Suspension Date is filled in accordingly.
The Scheduled Events Status is automatically set to Suspended.
The dates in the History tab dont change. The next Scheduled Event is still planned for December 1st. It wont be launched if the Subscription is still suspended at that date, but it will be launched if the Subscription is reactivated in the meantime.
13/02/2007: The Subscription is cancelled.
Cancelled
The Subscription State is set to Cancelled and the Cancellation Date is filled in accordingly. From now on, it is impossible to ever reactivate this Subscription.
The Scheduled Events Status is automatically set to Cancelled. From now on, it is impossible to ever execute this Scheduled Event.
Figure 126 - Cancellation of a suspended Subscription
11 September 2009
Page 323 of 968
Versioning
11. Versioning
11.1. Functionality
The aim of the Versioning facility offered through the whole Product Catalog is to: Validate the objects before actually setting them in the official Product Catalog (thanks to the Test statuses); Facilitate the Product Catalog evolution, by having objects un-subscribable while still available for processing events (thanks to the Inactive status); Control the management operations by showing only the applicable version in the GUI (thanks to the Active status); Keep a historical track of the objects used by the Product Catalog, without definitely removing them from the database (thanks to the Obsolete status); Offer a clear view of the applicable version of an object at a given moment (thanks to the Active status and thanks to the time line principle).
11.2. Versioned Objects

Objects of the Product Catalog: Tariff Usage Rating Rule Service Offer Definition Top-up Rule Charging Rule Rating Plan Rule Service Rule Service Offer Service Offer Group Service Offer Link Service Offer Group Link Package Link Commercial Offer The versioning aspects of these objects are defined with the same three parameters:
Figure 127 - Versioning GUI Frame
Page 324 of 968
04 June 2009
Table 107 - Versioning GUI Frame Parameter Version

(version)
Description Name of the current Version of the object.
Start Date
(startd)
Date at which the current Version reaches the status defined below.
Status
(status)
Versioning Status that the current version of the object reaches at the Start Date. Before that date, the current Version remains in its previous Status. After that date, the current Version holds the current Status until no other Status has started. The following 7 Statuses are available: 1. Definition 2. Test - Active 3. Test - Inactive
4. Test - Obsolete 5. Active 6. Inactive 7. Obsolete For a detailed description of the Versioning life cycle induced by these Status, see section 11.3, "Versioning Life Cycle", on page 325.
Two other objects also hold a simplified Versioning status (not defined on a time line and inducing no life cycle): Account (Operator Specific Account flag) Customer (version Test or Active)
11.3. Versioning Life Cycle

The same Versioning framework applies to all objects of the Product Catalog. A given version of an object can hold one of the following seven statuses:
1.
Definition version under development, draft;
2.
Test - Active
version that can only be used for Test events, simulating the Active Status;
3. Test - Inactive
04 June 2009
Page 325 of 968
Versioning
version that can only be used for Test events, simulating the Inactive Status;
4. Test - Obsolete
version that can only be used for Test events, simulating the Obsolete Status;
5. Active
version that can be used for processing real events, if no other version reached the Active or Inactive status more recently. Only the latest Active version is available for managing the Product Catalog object relationships: linking objects via references, creating Subscriptions, for the Customers, etc.
6. Inactive
version that can be used for processing real events, if no other version reached the Active or Inactive status more recently. The Inactive versions cannot be used for the Product Catalog management: this biggest consequences is that Customers can no longer subscribe to them.
7. Obsolete
version that has been removed from the Product Catalog. It is never used for processing
an event. However, it is still present in the database for history purposes. These 7 statuses are theoretically meant to reflect all the successive statuses of a version. However, the shift from one status to another can skip one or more of the 7 steps. Rollback to a previous status is also feasible.
11.3.1. Concurrent Versions Management

When processing an event and therefore identifying the objects of the Product Catalog, the Convergent Rating Engine has to find, for each object, an Active or an Inactive version. The life cycles of the various versions of one object are defined independently for each version, thanks to the time line-based implementation of the Versioning. So, it is not a problem to have, at a given moment, several versions which the status of is Active or Inactive. The version that received that status (Active or Inactive) most recently is the only one considered as the actual active one: the one that has to be identified and used for processing the current event. The life cycles of the various Versions are not consecutive, but parallel.
Page 326 of 968
04 June 2009
Version in Active or Inactive status Version in other status
Version A
Version B
Version C
Version D
Time
moment 1 moment 2 moment 3 moment 4 moment 5
Version C
Version A
Version B
Version D
Version B
Figure 128 - Versions life cycle: independence of the version statuses definition
11.3.2. Impact of the Life Cycle on the Event Processing

The life cycle of an objects version affects two areas of the Convergent Rating Engine:
1.
Event Processing for a given event, what version of the object will be identified and taken into account?
The objects version that most recently received the status Active or Inactive (and still is in that status).
2.
Product Catalog Management at a given moment, what version of the object is displayed in the GUI and can be subscribed to by the user? The objects version that most recently received the status Active (and still is in that status). Versions of the object in Inactive status can no longer be subscribed to nor be created references to.
11.3.2.1. Object Identification Process

For processing an event, the Convergent Rating Engine only uses Active or Inactive versions. The whole Product Catalog is concerned: each object, from Commercial Offer to Tariff has to hold a version which the status of is Active or Inactive. Otherwise, the event is rejected. From the event processing standpoint, there is no difference between Active and Inactive statuses. Both versions are valid and can be identified for processing an event;
04 June 2009
Page 327 of 968
Versioning
11.3.2.2. Versioning Consistency

When processing an event, the Customer and/or Account(s) involved in the event must be in the same version status as the Product Catalog items. So performing simulations with Test versions of the Product Catalog can only be done with Test Customers (and Accounts). Conversely, the Test versions of the Product Catalog objects cannot be used for processing real events.
11.3.3. Impact on the Product Catalog Management

From the Product Catalog management standpoint, Inactive versions cannot be handled anymore, which has two consequences: they cannot be attached to other versions (e.g. attach an Inactive Tariff to an Active Usage Rating Rule) they cannot be subscribed to by users. Concretely, it means that they are no longer sold / proposed to the users, but are still available in the Product Catalog for identifying the version valid a particular moment.
Page 328 of 968
04 June 2009
12. Decision Trees

The CRE GUI has a graphic editor by means of which you can draft decision trees. Since many CRE rules are implemented as decision trees, this means that you can make up yourself these rules. Note: The following kinds of CRE rules are implemented as a decision tree: Usage Rating Rules, Top-Up Rules, Charging Rules, Rating Plan Rules, and Service Rules.

On Usage rating Rules, see section 7.2, Usage Rating Rule object, on page 232. On Top-Up Rules, see section 7.4, Top-up Rule object, on page 252. On Charging Rules, see section 8.3, Charging Rule object, on page 255. On Rating Plan Rules, see section 8.4, Rating Plan Rule object, on page 257. On Service Rules, see section 6.2, Service Rule object, on page 224.
This means also that, whenever you specify to the CRE a rule that is of one of the kinds mentioned above, you spend in fact most of your time drafting the decision tree of the rule. Here you are explained how you use decision trees to draft rules that are of the kinds listed above.
12.1. Criteria and Leaves

12.1.1. Whats a Criterion? Whats a Leaf?
The goal of a decision tree is to take a final decision by taking a series of intermediate decisions. For example, the goal of a Usage Rating Rule is to find out the Tariff1 to apply to the current network event (i.e., to the network event to which the Usage Rating Rule is being applied). Choosing a tariff to apply is thus the final decision that the decision tree that implements a Usage rating Rule has to take. Let us now have a look to the intermediate decisions to take in order to take the final decision. To go further with the example, let us suppose that the network events the Usage Rating Rule has to rate are either of type moc (Mobile Originating Call) or of type mtc (Mobile Terminating Call), and that the tariff to apply depends on whether the event being rated is a moc or an mtc one. Let us additionally suppose that the tariff to apply on a moc event depends on whether the event occurred during a weekday or not, and that the tariff to apply on an mtc event depends on whether the event occurred during peak hours or not. This can be graphically depicted as follows:
1. The goal of a Usage Rating Rule is in fact a bit broader: Its goal is to find out the information that the CRE will use to cost the quantities (either used quantities or quantities to reserve) that the current network event specifies. This usually consists in finding out which tariff to apply to the current Accounts main balance. But this is not necessarily the case: You will find more on this at section 12.3.3, Bundle Criterion, on page 387 and at section 12.4.5, Tariff Leaf, on page 474.
11 September 2009
Page 329 of 968
Decision Trees
Does event type equal moc? No Yes Is event day a week-end day? No Yes No Tariff 2 Tariff 1 Yes
Does event type equal mtc?
Is event time between 8 and 18 oclock? No Yes
Tariff 5
Tariff 4
Tariff 3
Figure 129 - Decision Tree Example The graphic above states that the Usage Rating Rule first wonders whether the type of the current network event is moc or not. If the answer to Does event type equal moc? is Yes, the Usage Rating Rule then takes the decision to check whether the current network event occurred during a week-end day or not. Otherwise, if the answer to Does event type equal moc? is No, the Usage Rating Rule decides to check whether the current network event is of type mtc or not. Let us assume that the answer the Usage Rating Rule gave to Does event type equal moc? question is Yes. In consequence of this, the Usage Rating Rule decides to check whether the current network occurred during a week-end day or not. Let us now assume that the answer the Usage Rating Rule gives to this question is Yes. The Usage Rating Rule then decides to visit the bubble called Tariff 1, which means it has decided to return Tariff 1 to the CRE, which means that the CRE will use that tariff to rate the cost of the current network event. It goes without saying that the graphic above is very like a tree (with the wrong side up), where each branch is an intermediate decision and where each leaf is a final decision. Hence such a tree is called a decision tree. The CRE names each question, together with the two branches (the two possible decisions) going out from it, a criterion. Naturally, it names each bubble (final decision) a leaf. If you have a close look to the above graphic, you will notice that two of the criteria both check whether the current network event is of some event type or not. That means that these two criteria are asking the same kind of question. Or, in other terms, these two criteria belong to the same type of criterion, which the CRE calls an Event Type Criterion. Similarly, the criterion that wonders about the day at which the current network event occurred is called a Date Criterion, because of the kind of the question it is asking, while the one that wonders about the time at which the current network event occurred is called a Time Criterion, also because of the kind of the question it is asking. We can now present the two kinds of components that make up a CRE decision tree/
Page 330 of 968
11 September 2009
12.1.2. The Kinds of Criteria - The Criteria Palette

A criterion asks a question whose answer is either Yes or No, and indicates, for each of the possible answers, what has then to be done. A criterion is always of some type, which is the type of the question it is asking. We already met Event Type criterion, Date Criterion, and Time Criterion. But the CRE offers many other ones. You use a graphic editor to draft the CRE decision trees (on this, see also section 12.2.1, Creating a Decision Tree, on page 333). In that graphic editor, a criterion type graphically corresponds to an icon that is specific to the type of the criterion. You insert a criterion into a decision tree by putting into the graphic editor, from the palette of criteria types the graphic editor makes available, the icon that corresponds to the type of the criterion. As soon as you have done that, a configuration panel appears, containing entry fields that you fill in in order to configure the criterion that is being inserted. Once the criterion has been configured (i.e., once you have confirmed the entry fields values), the criterion appears in the decision tree. One of the goals of this chapter is to document all the criteria that the CRE makes available. Note: In the CRE graphic editor that you use to draft your decision trees, which icons the palette of available criteria types shows depends on the kind of the rule you are drafting. For example, the Time Criterion is always present in the palette, but the Discount Criterion shows up in it only in case a Usage Rating Rule is being drafted.
Section 12.3, The Criteria, on page 378, exhaustively lists, and documents, the available criteria.
12.1.3. The Kinds of Leaves - The Leaves Palette

A leaf is a final decision, taken as a consequence of a series of intermediate decisions. There are three possible kinds of final decision: A final decision that is expected. For example, whenever a Usage Rating Rule is executed, it is expected it will return a Tariff. Thus, with a Usage Rating Rule, a leaf that indicates a Tariff corresponds to a final decision that is expected. Such a leaf is called a Tariff leaf. Similarly, whenever a Charging Rule is executed, it is expected it will return a Customer Account (a Charging Rule is executed in order to find out which Customer Account, of a given Customer, will pay). Thus, with a Charging Rule, a leaf that indicates a Customer Account corresponds to a final decision that is expected. Such a leaf is called a Customer Account leaf. To give another example, whenever a Top-Up rule is executed, you expect from it a go final decision. That is, you expect it to allow the corresponding Top-Up. The leaf you expect a Top-Up rule to return is called an Allowed leaf. As soon as such a leaf of the decision tree is reached, the decision tree stops executing: The CRE now knows which final decision has been taken by the decision tree. A final decision that is a refusal. If it is hard to imagine that a Usage Rating Rule can, in some cases, return no Tariff, it can make sense that a Charging Rule refuses that a Customer pays for someone else. In which case the Charging Rule will return a refusal. Similarly, if makes sense that a Top-Up rule returns a no-go.
11 September 2009
Page 331 of 968
Decision Trees
A leaf that corresponds to a final decision that is refusal is called a Forbidden Leaf. As soon as such a leaf of the decision tree is reached, the decision tree stops executing: The CRE now knows which final decision has been taken by the decision tree. A final decision that requests another tree to take the final decision. This corresponds to a leaf that refers to another tree. Such a leaf is called a Tree Reference Leaf. At time such a leaf of the decision tree is reached, the decision tree, that the leaf refers to, starts executing. Note: Only a Usage Rating Rule, a Charging Rule and a Rating Plan Rule can have a Tree Reference Leaf. For a Usage Rating Rule, such a leaf is called a Usage Rating Rule Reference leaf. For a Charging rule, such a leaf is called a Charging Rule Reference leaf. For a Rating Plan Rule, such a rule is called a Rating Plan Rule Reference leaf. One reason why you might want to use a Tree Reference Leaf in a tree is if you notice your tree has two or more identical sub-trees that can be each replaced by a leaf that refers to a tree that is identical to the sub-trees. As you will then have drafted the sub-tree once (naturally, as an independent tree), you will have saved time. In the same way the graphic editor displays a palette of available criterion types, the graphic editor also displays a palette of leaves, one icon per kind of leaf that is allowed in the tree that is being built. You also create a leaf by putting it into the graphic window, from the palette of leaves. Doing this makes a configuration panel appear, of which you update the entry fields in order to configure the leaf (for example, for a Usage rating Rule Tariff leaf, you would enter the name of the Tariff to which the leaf corresponds). Once the leaf has been configured (i.e. once you have confirmed the entry fields values), the leaf appears in the decision tree. One goal of this chapter is to document all the kinds of leaves that the CRE makes available.
Section 12.4, The Leaves, on page 468, exhaustive lists, and documents, the available leaves.
12.2. Managing a Decision Tree

This section explains how you: Create and edit a new decision tree.
On this, see section 12.2.1, Creating a Decision Tree, on page 333.
Consult and modify a decision tree.
On this, see section 12.2.2, Consulting or Modifying a Decision Tree, on page 349.
Remove a decision tree from the CRE.
On this, see section 12.2.3, Removing a Decision Tree, on page 355.
Move a decision tree from one CRE platform to the other.
On this, see section 12.2.4, Moving a Decision Tree from One CRE Platform to the Other, on page 356.
Duplicate a decision tree.
Page 332 of 968
11 September 2009
On this, see section 12.2.5, Duplicating a Decision Tree, on page 366.
and introduces you to: Nodes and branches of a decision tree. Editing a decision tree may require more than just creating/updating/removing criteria and leaves. For example, you may need to remove nodes or branches of the decision tree. But how do you know whether you need to act upon nodes or upon branches?
On this, see section 12.2.6, Nodes versus Branches, on page 376
12.2.1. Creating a Decision Tree

In this section, you are shown how you create a Usage Rating Rule decision tree. And thus, how you create a Usage Rating Rule. For that, we are going to create, using the graphic editor, the decision tree that figure 129, Decision Tree Example, on page 330, specifies. We start from the CRE main menu, which is shown below.
Figure 130 - CRE Main Menu To start creating the decision tree of a Usage Rating Rule, double-click on 08. Usage Rating Rule entry, which is part of the CRE product catalog.
11 September 2009
Page 333 of 968
Decision Trees
Note: Each kind of rule has its own entry in the main menu. For example, if you were to create the decision tree of a Charging Rule, you would double-click on (CE) Charging Rule entry. And not on 08. Usage Rating Rule entry. As soon as 08. Usage Rating Rule entry has been double-clicked on, we get the following window displayed:
Enter here the name of the Service Retailer to which the Usage Rating Rule to create will belong. Enter here the name of the Usage Rating Rule you want to create.
Enter here the name of the Calendar that the Usage Rating Rule will use. Click here to see which Usage Rating Rules already exist. You will then see a list of Usage Rating Rules, and to which Service Retailer each of them belongs.
Graphic Editor Panel
Rules Selector Panel
Figure 131 - Creating a Usage Rating Rule The panel that appears to the right, and which we hereby call the Rules Selector, lets you indicate which Usage Rating Rule you want to work with. To edit an Usage Rating Rule that already exists, just indicate in the Rules Selector the information that identifies that rule to the CRE, so that the CRE can retrieve it. To create a Usage Rating Rule, indicate in the Rules Selector the information that the CRE needs to create a new empty Usage Rating Rule. Note: You need to fill in all the entry fields of the Rules Selector. Note: The panel that appears to the left, which we hereby call the Graphic Editor, is the graphic editor that you will use to draft the Usage Rating Rule. You get into the Graphic Editor as soon as the CRE has created the new empty Usage Rating Rule. The Graphic Editor then shows the just created Usage Rating Rule, so that you can complete it. In our case, we are wanting to create a new Usage Rating Rule, which we are going to call URRVoiceUsage. For that, we fill in the entry fields of the Rules Selector as shown below, taking care not to indicate an Usage Rating Rule that already exists.
Page 334 of 968
11 September 2009
Figure 132 Note d_School calendar has been chosen. Thats because it defines a day type that is called Week-End and because we will use that day type in the Usage Rating Rule that is being created. To create the new rule, click on Create node button, which appears at the bottom of the Rules Selector.
Create node button.
Figure 133 As soon as this has been done, the new (and thus empty) Usage Rating Rule appears in the Graphic Editor and the Rules Selector disappears. The figure below illustrates this.
11 September 2009
Page 335 of 968
Decision Trees
The rule
The criteria palette. Each icon in the palette represents a criterion that is of some type. To make the rule use one of these criterion types, first select one of the green solid color squares that appear in the rule, click then, in the criteria palette, on the icon that corresponds to the criterion type you want the rule to use. This will replace the green solid color square by the clicked on icon.
A green solid color square that appears in a rule represents a piece of the rule (thus, of the decision tree) that you still need to complete. You can replace a green solid color square by either a criterion type icon, from the criteria palette, or by a leaf icon, from the leaves palette. A rule is complete as soon as it no longer shows green solid squares. To replace a green solid color square by either a criterion icon or a leaf icon, the square must first be selected.
Note that the criteria and the leaves palettes appear in grey. Thats because the currently selected item of the tree is not a green solid color square of the tree.
The leaves palette. Each icon in the palette represents a leaf that is of some type. To make the rule use one of these leaf types, first select one of the green solid color squares that appear in the rule, click then, in the leaves palette, on the icon that corresponds to the leaf type you want the rule to use. This will replace the green square by the clicked on icon.
Criteria Configuration Panel

The Criteria Configuration panel has now replaced the Rules Selector panel. You use the Criteria Configuration panel to configure/edit the rules criteria.
Figure 134 - Graphic Editor Showing an Empty Usage Rating Rule Note: A new panel has now replaced the Rules Selector pane: Its the Criteria Configuration panel, which you use to configure/edit the various criteria of the rule. Use of this latter panel is introduced further down. A green solid color square appearing in the decision tree represents a piece of the tree that still has to be completed. In the figure above, there is only one such square. It represents the whole tree we have to draft. To start completing the tree, we first need to click on that square, so that it becomes the currently selected item in the tree. The figure below shows this.
Page 336 of 968
11 September 2009
As the currently selected item in the tree is now a green solid color square, the criteria and the leaves palettes no longer appear in gray. Their icons are now available for use in the tree.
The currently selected item is indicated by a blue square drawn around the item. Thus, in this figure, the green solid color square of the rule is currently selected.
Figure 135 - Selecting a Green Solid Square Enables the Critria and Leaves Pamettes Notice that now the criteria palette and the leaves palette no longer appear in gray. We want now to place on the tree an Event Type criterion. For that, we need to click on the Event Type criterion icon in the criteria palette. To find out which icon in the criteria palettes is for the Event Type criterion, we move the mouse cursor in succession over each icon of the palette. But, whenever the cursor arrives over one icon, we let it still over the icon for a little while, until some text appears. That text indicates the type of the criterion that the icon is about. The figure below shows that for the Event Type criterion icon.
Figure 136 - To Know What a Criterion Icon Is About, Move the Mouse Cursor over the Icon In the above figure, the cursor is over the Event Type Criterion icon. As the cursor has stayed still a little while over the icon, a tooltip indicating what the icon is about has appeared. Let us now click on the Event Type Criterion icon, in order to add criterion Does event type equal moc?, which is the first criterion from the decision tree from figure 129, Decision Tree Example, on page 330. The configuration panel of the Event Type criterion then appears, so that we can indicate that moc is the network event type that the criterion has to check. The configuration panel for an Event Type criterion is shown by the figure below.
11 September 2009
Page 337 of 968
Decision Trees
Click here to get the list of the network event types that are available for the current Service Retailer.
Configuration Panel of the Event Type criterion.
Figure 137 We now configure the question the Event Type criterion is asking (Does event type equal ??? ?) by entering moc network event type in Network Event Type entry field. For that, we click on the button that is to the right of the entry field, in order to get the list of available network event types. Here is the list we get as soon as that button has been clicked on.
Page 338 of 968
11 September 2009
Figure 138 We double-click on MOC, which means the configuration panel of the Event Type criterion that is being placed on the tree, now looks as follows:
Click on Create node button in order to insert the Event Type criterion at the place of the currently selected green square.
Configuration Panel of the Event Type criterion.
Figure 139 -
11 September 2009
Page 339 of 968
Decision Trees
In the configuration panel, click now on Create node button, which appears below Network Event Type* text.
Figure 140 This makes the just configured Event Type criterion graphically appear in the tree that is being built, at the place of the currently selected green solid color square. Here is what the graphic editor now looks like.
The little key that is to the left of the square labelled moc. The little square labelled moc, along with its label, represents the criterion we have just inserted.
Figure 141 Note that, in the figure above, the square that is labelled Else is currently selected. Note also that, in the criteria palette, only Event Type criterion icon is not in gray. Note also that the complete leaves palette appears in grey. This means that the currently selected tree item can only be replaced by an Event Type criterion. If we want that the tree checks, after it has checked whether the network event type of the current network event is moc or not, whether the network event type of the current network event type is mtc, we need to click again on the Event Type criterion icon and to configure it to use mtc as the network event type to check.
Page 340 of 968
11 September 2009
But, before doing that, let us first click on the little key to the left of the square that is labeled moc. The figure below shows then what happens.
This criterion asks the following question: Does the type of the network event being processed equal moc? If the answer is yes, the Yes branch of the criterion is executed. The Yes branch of the event type criterion labelled moc. Each criterion has a Yes branch, that is represented by a vertical line from the square that represents the criterion.
Figure 142 This should be understood as follows: If the network event type is moc, then the Usage Rating Rule decides to execute the green solid color square that appears just below MOC text. Else, it decides to execute the green solid color square that appears just below Else text. Now, we have two pieces of the tree to complete. In addition, if we need that, we can replace the Else by an Event Type criterion. We need that, since we havent yet implemented the Does event type equal mtc? criterion from the example of figure 129, Decision Tree Example, on page 330.
Thus, we click on Event Type criterion icon in the criteria palette, and configure the criterion to test on mtc network event type. The figure below shows the result.
Figure 143 This needs to be understood as follows: If the type of the network event the Usage Rating Rule is rating is moc, then the rule decides to execute the green solid color square that appears under MOC text. Otherwise, the Usage Rating Rule then checks whether the type of the network event is MTC. If it is of type MTC, the rule decides to execute the green solid color square that appears under MTC text. Otherwise, the rule then decides to execute the green solid color square that appears under Else text. Note that this latter green solid color square, which appears under Else text, corresponds to a leaf of the example of figure 129, Decision Tree Example, on page 330. That leaf corresponds to Tariff 5. Let us put that leaf into the tree that is being built. For that, we first select the green solid color square, as the figure below shows.
11 September 2009
Page 341 of 968
Decision Trees
Figure 144 In the figure above, the green solid color square under Else text is currently selected. And the mouse cursor has stayed still over the Tariff leaf icon (which appears at the bottom of the above picture) for a while, since Tariff tooltip is being displayed. We now click on the Tariff leaf icon, and get a configuration panel displayed, so that we can indicate the tariff the leaf is about. The figure below shows that configuration panel, already set up with the right tariff.
Page 342 of 968
11 September 2009
Click on Create node button in order to insert the Tariff Leaf at the place of the currently selected square.
Figure 145 Click now on Create node button, in order to have the tree use the Tariff leaf. The figure below shows the result.
11 September 2009
Page 343 of 968
Decision Trees
Figure 146 This figure is saying that, if a network event is neither of type moc nor of type mtc, then the tariff that the Usage Rating Rule returns to the CRE is Tariff 5. This is the tariff that the CRE will then use to rate the network event. Note also that all icons of all palettes now appear in gray. Since we are drafting the decision tree of figure 129, Decision Tree Example, on page 330, we are now going to implement its Is event day a week-end day? criterion. For that, we select the green solid color square that is just below MOC text, and move the mouse cursor over the criteria palette icon for Date criterion. The figure below shows this.
Figure 147 -
Page 344 of 968
11 September 2009
We now click on the criteria palette icon for Date criterion. We then get the following configuration panel displayed.
Figure 148 We now click on the button to the right of Day Type entry field in order to get all the day types of the current calendar (remember, at time we created the Usage Rating Rule, we chose d_School calendar as the rules calendar). Here is the list we get.
Figure 149 Double-clicking on Week-End in the list results in the following:
11 September 2009
Page 345 of 968
Decision Trees
Figure 150 By clicking on Create node button, which appears below Day Type* parameter, we get the following Usage Rating Rule tree.
Page 346 of 968
11 September 2009
Click on Create node button in order to insert the just configured Date criterion at the place of the currently selected square.
Figure 151 Now, since we are implementing the example of figure 129, Decision Tree Example, on page 330, the green solid color squares under Week-End text and under the Else text just below that square have to be tariffs, respectively Tariff 1 and Tariff 2 of the example of figure 129, Decision Tree Example, on page 330. You should now have understood how the Graphical Editor can be used to draft a decision tree. The figure below shows the completed URRVoiceUsage Usage Rating Rule, so that you can compare it against the decision tree figure 129, Decision Tree Example, on page 330, shows.
11 September 2009
Page 347 of 968
Decision Trees
If the event date in the network event that is being processed is a week-end day, then Tariff 1 is returned, else Tariff 2 is returned.
If the event time in the network event that is being processed is between 08h00 and 18h00, then Tariff 3 is returned, else Tariff 4 is returned.
Figure 152 - Final Version of URRVoiceUsage.
Page 348 of 968
11 September 2009
If the type of the network event is neither MOC nor MTC, then Tariff 5 is returned.
12.2.2. Consulting or Modifying a Decision Tree

In this section, you are shown how the Usage Rating Rule from section 12.2.1, Creating a Decision Tree, on page 333, can be consulted and modified. We start from the CRE main menu, which is shown below.
Figure 153 To start consulting/modifying the decision tree of a Usage Rating Rule, double-click on 08. Usage Rating Rule entry, which is part of the CRE product catalog. Note: Each kind of rule has its own entry in the main menu. For example, if you were to modify/consult the decision tree of a Charging Rule, you would double-click on (CE) Charging Rule entry. And not on 08. Usage Rating Rule entry. As soon as 08. Usage Rating Rule entry has been double-clicked on, we get the following two windows displayed:
11 September 2009
Page 349 of 968
Decision Trees
Click on this little key to see what Usage Rating Rules are currently available.
Figure 154 To see what Usage Rating Rules are currently available, click, in the Rules Selector, on the little key that is to the left of Rules text (this latter text appears below Status entry field). Here is what you get.
Page 350 of 968
11 September 2009
The currently existing Service Retailers.
Figure 155 Rules now expands to the list of available Service Retailers. As we are interested by the Usage Rating Rules of sdpprov Service Retailer, we click on the little key that is to the left of sdpprov entry. The figure below shows what then happens.
11 September 2009
Page 351 of 968
Decision Trees
To edit a tree, select it and then click on Load tree button.
Figure 156 We get now displayed, under sdpprov and indented with respect to it, the list of all the decision trees, that sdpprov Service Retailer has set up for its Usage Rating Rules. Note: You only see decision trees for Usage Rating Rules here. To say things in another way, you wont see here decision trees that sdpprov has set up for other kinds of rules. For examples, you wont see in that list the decision trees sdpprov has set up for its Charging Rules. To know consult/modify URRVoiceUsage decision tree, which implements URRVoiceUsage usage Rating Rule, we first select URRVoiceUsage, which appears in the list of decision trees and then click on Load tree button, which appears at the bottom of the Rules Editor (thats the button to the far right). We then get the decision tree displayed in its graphic editor, as the figure below shows.
Page 352 of 968
11 September 2009
Figure 157 To modify or replace an item of the decision tree, navigate to that item as necessary, by clicking as necessary on the little keys the decision tree displays. Once the item to modify or replace is shown, rightclick on it. A drop-down menu then appears. In the figure below, since we were wanting to modify or replace Tariff leaf Tariff 1, we have made it appear, and then have right-clicked on it. The figure shows the drop-down menu that then appears.
11 September 2009
Page 353 of 968
Decision Trees
Figure 158 To replace Tariff 1 Tariff Leaf by another item, select Remove branch. This will make the leaf change to a green solid color square. Select then the square and click either on the criteria palette icon or on the leaves palette icon you want to substitute to the Tariff leaf. To modify Tariff 1 Tariff leaf (for example, to change the name of the tariff), select Modify branch. This will make the configuration panel of the leaf appear, so that you can change the name of the tariff.
Page 354 of 968
11 September 2009
12.2.3. Removing a Decision Tree

Make the decision tree appear in the graphic editor. To have an example of how you do that, see section 12.2.2, Consulting or Modifying a Decision Tree, on page 349. Once the rule is displayed in the graphic editor, right-click the root of the rule (in this example, that root name is URRVoiceUsage / sdpprov). A drop-down menu then appears, as shown by the figure below.
Figure 159 In the drop-down menu, select Remove branch. This will permanently remove the rule from the CRE.
11 September 2009
Page 355 of 968
Decision Trees
12.2.4. Moving a Decision Tree from One CRE Platform to the Other
Moving a decision tree from one CRE platform to another is a two steps process: First, from the CRE platform that holds the decision tree to move, export the decision tree to some text file. Note: Section 12.2.4.1, Exporting a Decision Tree, on page 356, explains how you do this. Second, on the CRE platform to which the decision tree has to be moved, import the text file that previous step produced. Note: Section 12.2.4.2, Importing a Decision Tree, on page 360, explains how you do this.
12.2.4.1. Exporting a Decision Tree

To export a decision tree into a text file: 1. 2. Log in to the CRE GUI of the CRE platform where the decision tree is defined. Make sure that the Graphic Editor is displayed and shows the decision tree to export. Next figure shows a Graphic Editor that displays a decision tree.
Figure 160 - The Graphic Editor Is Showing the Decision Tree to Export 3. In the menu bar, click on the text indicating the rules type. Note: In this example, the rule that is being edited is of type Usage Rating Rule. Therefore, we click on Usage Rating Rule text, which appears in the menu bar. As a result, a drop-down menu appears, which next figure shows.
Page 356 of 968
11 September 2009
Figure 161 - Usage Rating Rule Drop-Down Menu 4. In the drop-down menu, move the mouses cursor over Save tree to a file. As a result, a sub-menu appears, which next figure shows.
Figure 162 - Sub-menu of Save tree to a file
11 September 2009
Page 357 of 968
Decision Trees
5.
In the sub-menu, select Text (for unconnected mode) option. Note: Never select Binary (for connected mode) option, since this latter option is not supported.
Figure 163 - Selecting Text (for unconnected mode) As a result, the Save tree (unconnected mode) window appears.
Figure 164 - Save tree (unconnected mode) Window
Page 358 of 968
11 September 2009
6.
In File name parameter of Save tree (unconnected mode) window, choose a name for the text file in which the decision tree is going to be exported as text.
SAVE button
Figure 165 - File Name Parameter Now Set to ExportedDecisionTree According to the above figure, the decision tree will be saved as text into ExportedDecisionTree.utree text file. 7. 8. Using the parameters that appear above File name parameter, navigate to the directory in which the decision tree will be exported as text. Click on SAVE button. As next figure illustrates, the decision tree has now been saved into ExportedDecisionTree.utree file, which only contains text.
Figure 166 - The File into Which the Decision Tree Has Been Exported To move the decision tree to another CRE platform, move ExportedDecisionTree.utree file to that other platform and import it from the CRE GUI of that platform.
11 September 2009
Page 359 of 968
Decision Trees
12.2.4.2. Importing a Decision Tree

Before you import a decision tree, make sure: That a .utree file holding the decision tree to import is available, and That that .utree file has been buitl up either as section 12.2.4.1, Exporting a Decision Tree, on page 356, explains or as section 12.2.5.1, Exporting a Decision Tree Under a Different Name, on page 366, explains. To import a decision tree: 1. 2. Log in to the CRE GUI of the CRE platform where the decision tree is defined. Make sure that the Rules Selector for the type of rule to import is displayed. For example, if the rule to import is a Usage Rating Rule, double-click on Usage Rating Rule entry of the Main menu (you find the menu in the Views panel) in order to make the Rules Selector for Usage Rating Rules appear.
Rules Selector Figure 167 - The Rules Selector 3. In the menu bar, click on Tools. As a result, a drop-down menu appears. Next figure illustrates this.
Page 360 of 968
11 September 2009
Figure 168 - Tools Drop-Down Menu 4. In the drop-down menu, make sure that Connected is unchecked. Note: If you do not do that, you will not be able to import the .utree file that is holding the decision tree. That is, make sure Connected entry of the drop-down menu is set as next figure illustrates.
Figure 169 - Correct setup for Connected And that Connected entry of the drop-down menu is thus not set as next figure illustrates
11 September 2009
Page 361 of 968
Decision Trees
Figure 170 - Incorrect Setup for Connected 5. In the menu bar, click on the rules type (in this exemple, since the rules type is Usage Rating Rule, we click on Usage Rating Rule text, which appears in the menu bar). As a result, a drop-down menu appears. Next figure illustrates this.
Figure 171 - Usage Rating Rule Drop-Down Menu 6. In the drop-down menu, select Load a tree from file.
Page 362 of 968
11 September 2009
Figure 172 - Selecting Load a tree from file As a result, the Load tree (unconnected mode) window appears.
Figure 173 - The Load tree (unconnected mode) window 7. Navigate through the Load tree (unconnected mode) window until the name of the file holding the decision tree to import appears.
11 September 2009
Page 363 of 968
Decision Trees
Note: The file holding the decision tree to import must have been built up either as section 12.2.4.1, Exporting a Decision Tree, on page 356, explains or as section 12.2.5.1, Exporting a Decision Tree Under a Different Name, on page 366, explains.
OPEN button
Figure 174 - Navigating Towards the .utree File to Import 8. Click on OPEN button. As a result, the Load tree (unconnected mode) window disappears and the Graphic Editor reappears. But the Graphic Editor is no longer empty, since the window now shows the imported decision tree.
Page 364 of 968
11 September 2009
Graphic Editor Figure 175 - The Decision Tree to Import Now Appears in the Graphic Editor 9. Save now the decision tree into the CREs ORACLE database of the CRE platform. 9.1. In the menu bar, select Tools. 9.2. In the drop-down menu that then appears, check Connected menu entry. 9.3. In the pop-up window that appears as a result of having checked Connected and which is asking you whether you want to send the tree to the SMF?, click on YES button.
Figure 176 - Click YES to Save the Decision Tree into CREs ORACLE Database The decision tree to import is now imported.
11 September 2009
Page 365 of 968
Decision Trees
12.2.5. Duplicating a Decision Tree

To create another tree that is identical to an existing one: First, from the CRE GUI, export the decision tree into a text file and under a different name. Note: Section 12.2.5.1, Exporting a Decision Tree Under a Different Name, on page 366, explains how you do this. Second, import the text file that previous step produced. Note: Section 12.2.4.2, Importing a Decision Tree, on page 360, explains how you do this.
12.2.5.1. Exporting a Decision Tree Under a Different Name

To export under a different name a decision tree: 1. 2. Log in to the CRE GUI of the CRE platform where the decision tree is defined. Make sure that the Graphic Editor is displayed and shows the decision tree that you want to export under a different name. Next figure shows a Graphic Editor that displays a decision tree.
Figure 177 - The Graphic Editor Is Showing the Decision Tree to Export The name of the above shown decision tree is CUGCritURR/deeprov. We are going to export it to a text file under another name: TreeCopy/deeprov. If we import afterwards the text file, we will have two identical trees available: One that is called CUGCritURR/deeprov and another one called TreeCopy/deeprov.
Page 366 of 968
11 September 2009
3.
In the menu bar, click on the text indicating the rules type. Note: In this example, the rule that is being edited is of type Usage Rating Rule. Therefore, we click on Usage Rating Rule text, which appears in the menu bar. As a result, a drop-down menu appears, which next figure shows.
Figure 178 - Usage Rating Rule Drop-Down Menu 4. In the drop-down menu, move the mouses cursor over Save tree to a file. As a result, a sub-menu appears, which next figure shows.
11 September 2009
Page 367 of 968
Decision Trees
5.
In the sub-menu, select Text with new root (unconnected) option. Note: Never select Binary (for connected mode) option, since this latter option is not supported.
Page 368 of 968
11 September 2009
Figure 179 - Sub-menu of Save tree to a file
Figure 180 - Selecting Text with new root (unconnected) As a result, the Save tree (unconnected mode) window appears.
Figure 181 - Save tree (unconnected mode) Window 6. In File name parameter of Save tree (unconnected mode) window, choose a name for the text file in which the decision tree is going to be exported as text.
11 September 2009
Page 369 of 968
Decision Trees
SAVE button
Figure 182 - File Name Parameter Now Set to ExportedDecisionTreeWithNewRoot

According to the above figure, the decision tree is going to be exported to ExportedDecisionTreeWithNewRoot.utree file. 7. 8. Using the parameters that appear above File name parameter, navigate to the directory in which the decision tree will be exported as text. Click on SAVE button. The Rules Selector now appears, so that you can specify under which name (i.e., under which root) the decision tree will be saved.
Page 370 of 968
11 September 2009
Rules Selector
Figure 183 - The Rules Selector by Means of Which You Specify Under Which Name the Tree Will Be Saved into a Text File 9. Specify the new root (the new name) by filling in as necessary Service Retailer*, Rating Tree Name*, Calendar*, Version*, Start Date* and Status* parameters of the Rules selector.
11 September 2009
Page 371 of 968
Decision Trees
Figure 184 - Specyfying the Name (i.e., the Root) Under Which the Tree Will Be Saved into a Text File According to the above figure, the decision tree will be saved under the following name: TreeCopy/ deeprov. Moreover, according to the figure from step 6, the decision tree will be stored with that name into ExportedDecisionTreeWithNewRoot.utree text file. 10. Click on Use this Root button, which appears at the bottom of the Rules Selector panel.
Page 372 of 968
11 September 2009
Rules Selector Panel Figure 185 - Exporting a Decision Tree Under the New Name Previously Chosen 11. The Graphic Editor again appears. As next figure illustrates, the decision tree has now been saved into ExportedDecisionTreeWithNewRoot.utree file, which only contains text.
Figure 186 - The File into Which the Decision Tree Has Been Exported Under a New Name Opening the text file in order to take knowledge of its content would show that, in the text file, the decision tree is called TreeCopy/deeprov, while, in the CREs database, the decision tree is still called CUGCritURR/deeprov. Importing ExportedDecisionTreewithNewRoot.utree as section 12.2.5.2, Importing a Decision Tree that Was Exported Under a Different Name, on page 375, explains results in the following decision tree imported:
11 September 2009
Page 373 of 968
Decision Trees
Figure 187 - Duplicated Decision Tree Example As you can see, the decision tree shown above is identical to CUGCritURR/deeprov one (see figure 175) but has another name: TreeCopy/deeprov.
Page 374 of 968
11 September 2009
12.2.5.2. Importing a Decision Tree that Was Exported Under a Different Name
To import a decision tree that was exported under a different name, proceed exactly as section 12.2.4.2, Importing a Decision Tree, on page 360, explains.
11 September 2009
Page 375 of 968
Decision Trees
12.2.6. Nodes versus Branches

The decision trees graphic editor uses the notion of node and of branch. This is the reason why you can see, among the graphic editor menus choices, entries such as Remove node and Remove branch. What is a node? What is a branch? When do you use a command that acts on a node? When do you use a command that acts on a branch? This section attempts to make these things clearer to you. Let us first turn our attention to nodes. A node is made up of all the criteria that are connected to the same vertical line. For example, in the figure below, the date criteria labelled Daytype7, Daytype12 as well as the Else below them, are connected to the same vertical line. The set of all these criteria represents a node. As another example, in the figure below, the set of the event type criteria labelled MOC, MTC as well as the Else below them, also represent another node of the tree.
One node
Another node.
Figure 188 Now that we have seen examples of nodes, let us see some branch examples. In the figure above, the node made up of date criteria labelled Daytype7, Daytype12, and the Else below them, starts three branches: One that Daytype7 starts, one that Daytype12 starts, and a last one that the Else starts. As a result, a command that acts on a node does not do the same as one that acts on a branch. To illustrate, we first remove Daytype12 branch. For that, we right-click on the square labelled Daytype12, which makes appear the menu that the figure below shows.
Page 376 of 968
11 September 2009
Figure 189 3CL-02660-BAHA-PCZZA
Selecting Remove branch in the menu, results in the following.
Figure 190 The node is still present, since Daytype7 and the Else below it are still present. But criterion Daytype12, and the branch it was starting, and to which it belonged, have disappeared. Let us now remove the node. For that, we right-click on the uppermost criterion of the node (which is the square labelled Daytype7). This makes appear the menu that the figure below shows.
11 September 2009
Page 377 of 968
Decision Trees
Figure 191 Selecting Remove node entry of the menu results in what the figure below shows.
Figure 192 The node has disappeared, which implies none of its branches still appear. You should now have an idea of when you need to use commands that act on nodes and when you need to use commands that act on branches.
12.3. The Criteria

This section exhaustively lists the available criteria, and documents them.
Page 378 of 968
11 September 2009
12.3.1. Generalities
12.3.1.1. Used Network Event Parameters
Many criteria use one or more parameters that are stored into the current network events. This section indicates how the text refers to them. Table 108 How the Text Refers to the Network Event Item Calling user Network Event Item The user that the following network event attributes identify: ppmindex and ppmvalue. The calling user corresponds to the originator of the event that the network event is about. That event that the network event is about is not necessarily a call. Thus, it would be more suitable to use the term event originator in place of calling user. However, the term calling user is still used, but its meaning is now broader: It means event originator.

Called Party
See also Calling Customer, on page 27.
The party that the following network event attribute identifies: cld attribute of ppmreq object of network event. Although the called party might be a customer (whether it belongs to the same retailer as the calling customer or not), it might turn out he/she is not the customer of any Service retailer of your platform. Hence the term party is used, and not customer. It would have been more suitable to say event destination party, in place of saying Called party, where the event is the one that the network event being processed is about (a network event is not necessarily about a call). However, the term called party is still used, but has now a broader meaning: It refers to the destination of the event the network event that is being processed is about.

Event time Event date
See also Called Party, on page 379.
The time given by the following network event attribute: calltime. The day given by the following network event attribute: calldate.
11 September 2009
Page 379 of 968
Decision Trees
Table 108 How the Text Refers to the Network Event Item Event member type Event Type Network Event Item This is the fftype attribute of ppmreq object of the network event. The type of the event, that a network event is about, is deduced from the following attributes of the network event: calltype attribute or evt_type.
12.3.1.2. Intermediate Commit and Final Commit

Note: Its no problem you skip this section if you do not need to read the Counter criterion and/or the Counter Threshold criterion. In the sections that document the Counter criterion and the Counter Threshold criterion, the terms intermediate commit and final commit are used. This section clarifies what these terms mean. Committing consists in either charging (i.e. debiting) or crediting a given accounts balance and/or bundles.
If the commit happens in consequence of a Top-Up, the given accounts balance and/or bundles is/are credited. Otherwise, it/they are charged (i.e., debited). A CRE charging is: Either made up of a series of one or more intermediate commits (i.e., intermediate charging), followed by a final commit (i.e., a final charging that charges what has not been paid yet). This corresponds to the standard charging method of the CRE, which is hereby called Reservation / Commit charging (other possible names are: Normal Charging, Slicing Reservation). In that charging process, an intermediate commit happens when a Next Reservation RTx request is being processed by the CRE. Such an RTx request asks some quantities to be reserved and, at the same time, indicates what part of the previously reserved quantities has been effectively consumed. The intermediate commit consists in charging that part of the previously reserved quantities that has been effectively consumed. In that charging process too, the final commit happens when an End Call RTx request is being processed by the CRE. Such an RTx request does not ask to reserve some quantities, but still indicates what part of the previously reserved quantities has been effectively consumed. The final commit consists in charging that part of the previously reserved quantities that has been effectively consumed. Or made up of a final commit only. This corresponds to another charging method that the CRE provides: One-Shot Rating and Charging. In the context of One-Shot Rating and Charging only one charging (i.e., commit) is done. As that commit is unique, it is also final. It makes thus sense to call it a final commit too. On the other hand, the crediting (commit) done in consequence of a Top-Up is the unique crediting done for that Top-Up. It makes also sense to call it a final commit.
Page 380 of 968
11 September 2009
12.3.1.3. Order of Use of the Criteria

Except for the Bundle criteria, the CRE does not impose you the order in which a decision tree uses (and thus executes) its criteria. For example, executing an Event Type criterion and afterwards executing a Time criterion is a valid order of execution of these two criteria. But the other of execution is valid too. That is, executing first a Time criterion and executing afterwards an Event Type criterion is fine too. Thats because, except for the Bundle criteria, the order of execution of the criteria does not matter. For the Bundle criteria its different. To know which order constraints are imposed on Bundle criteria, see section 12.3.3.3, What Constraints Apply to a Bundle Criterion?, on page 389.
12.3.1.4. Design Guidelines

The following guidelines should help you build up well-designed decision trees: 1. Make your decision trees first execute the most discriminant criterion. After the most discriminant one has been executed, have the tree execute the next most discriminant one. And so on. This will help keeping the depth of the tree (i.e., the number of tree nodes from the root to the leaf) to a minimum. 2.
The order of execution of the criteria has no impact on the decision tree execution time. The number of tree nodes encountered from the root the root being excluded to the leaf has impact on the decision tree execution time. Each node encountered has an impact on the decision trees execution time. The figures below should give you an idea of that impact. They indicate the increase of execution time with respect to a reference execution time, which is the time it takes to execute a decision tree that has no criteria. Two encountered nodes increase the reference execution time by 5%. Four encountered nodes increase the reference execution time by 10%. Six encountered nodes increase the reference execution time by 15%.
3.
4.
The number of criteria in a node has no impact on the decision tree execution time. Thus, a node can use as much criteria as you want.
5.
The order of criteria in a node has no impact on the decision tree execution time. Thus, regarding performance, do not worry about the order in which a nodes criteria appear on the node.
6.
The order of the criteria in a node has impact on the node logic. Do not forget that the criteria of a tree node are executed from the highest criterion of the node down to the lowest one: If a criterion answers No to the question it is asking, the criterion just below on the same node starts then executing. Thus, if two or more criteria of the node answer Yes to the question they are asking, its the highest of these criteria that will decide of the remaining logic of the decision tree. The order of the criteria in a node has thus impact on the node logic as well as on the tree logic.
11 September 2009
Page 381 of 968
Decision Trees
12.3.1.5. Switching of Tariff, of Customer Account, of Service Offer, of Service

12.3.1.5.1.Whats a Switching?
Unlike the other kinds of charging, a Reservation / Commit charging is implemented by means of several RTx requests received by the CRE (typical scenario is: a First Reservation RTx request is received first, followed by zero or more related Next Reservation RTx requests, followed by one related End call RTx request received). As a result, running the same rule each time an RTx request, of the same Reservation / Commit charging, is received might result in a different leaf being returned to the CRE. In which case, it is said that a leaf switch (in short, a switch) occurs. For a Usage Rating Rule, this would mean different rating information being returned (for example, for the Accounts that have no bundles, this means a different main balance tariff returned). In which case, a so-called tariff switch occurs. For a Charging Rule, this would mean another Customer Account being returned. In which case, a socalled Customer Account switch occurs. For a Service Rule, this would mean another Service being returned. In which case, a so-called Service switch occurs. For a Rating Plan Rule, this would mean another Service Offer being returned. In which case, a so-called Service Offer switch occurs.
12.3.1.5.2.Why Would a Rule Return Another Leaf?

A rule execution can result in a switch only if one or more of the following criteria contributed to select the leaf to return: Counter Threshold criterion That is, is some counter strictly greater or not than some threshold value? Maybe it was lower at time of the previous RTx request and maybe it is now higher. Time criterion That is, is the current network event time within or outside the time band the criterion specifies? Maybe the network event of the previous RTx request had a time within the time band, and maybe the time of the current network event is outside the time band. Date criterion That is, is the current network event date about a day that is of the type the criterion specifies? Maybe the network event of the previous RTx request had a date that was of the type the criterion specifies, and maybe the date of the current network event is no longer a day of that type.
12.3.1.5.3.What Switching Does the CRE Support?

At this time, the CRE only supports tariff switching (more accurately said, it only supports rating information switching). To learn more about how the CRE supports tariff switching, see section 12.3.7.3, Tariff Switches that Are Due to a Counter Threshold Criterion., on page 410.
Page 382 of 968
11 September 2009
12.3.1.6. Which Criterion Is Available in Which Kind of Rule

Table 109 - Which Criterion Is Available in Which Kind of Rule Criterionab Association Type Criterion Bundle Criterion Closed User Group Criterion Bundle Threshold Criterion Counter Criterion Counter Threshold Criterion Date Criterion Destination Criterion Destination Zone Criterion Discount Criterion Event Type Criterion
Service Rule
Chargingc Rule x
Ratingd Plan Rule x
Usage Rating Rule
Top-Up Rule
x xe x x xf x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x
Friends and Family Criterion Generic Criterion Grant Criterion LSCE Criterion (LiteSCE Criterion) Main Balance Criterion Origin Criterion Originating Zone criterion Preferred Number Criterion Promotion Criterion Service Criterion Subscription Criterion Supervision Criterion Time Criterion Matrix Component Criteriong
a. b. c. d. e. f. g.
No x in a cell means that the corresponding criterion is not available for the corresponding rule. An x in a cell means that the corresponding criterion has to be available for the corresponding rule. Only possible for a user that is a Customer. Only possible for a user that is a Customer. If at least one of (calling user, called party) is not a Customer, the Else branch of the criterion is always chosen. If at least one of (calling user, called party) is not a Customer, the Else branch of the criterion is always chosen. From a rule that is not a Usage Rating Rule, a Matrix Component criterion is not allowed to refer to Zones..
11 September 2009
Page 383 of 968
Decision Trees
12.3.2. Association Type Criterion

12.3.2.1. Criterion Purpose
This criterion asks the following question: Does one of the customer associations, from the calling customer to the current customer and belonging to the current community, have an association type that matches the association type that the criterion specifies? If the answer is yes, the Yes branch of the criterion is executed. Note: If none of the customer associations have an association type, the answer is no. Note: If the current customer is the same as the calling customer, the answer to the question is no.
12.3.2.2. Understanding the Association Type Criterion

Association Types makes sense only in the context of communities. For that reason, this section first introduces communities, afterwards says a word about association types, and finally gives an example of the use of this criterion.
12.3.2.2.1.Whats a Community? Why a Community?

A community is a group of customers. A community provides many benefits. One of them is that a community makes it possible to have some customers pay, provided they agree, for other customers. For that, you need to build up and suitably set up a community that is made up of customers who are possible payers and of customers for whom the possible payers of the community would agree to pay. For example, a corporation community would be made up of a corporations employees, and the corporation would pay for work related calls of its employees. A family, where the father would pay for some of his children calls, is another community example. In the former example, the corporation (possible payer for the employees) as well each employee is then a Customer. In the latter example, the father (possible payer for the other members of the family) as well as each member of the family is then a Customer. You set up a community by setting so-called customer associations between the customers who have to belong to the community. To give an example, a customer association from customer EmployeeA to customer Boss in a community, that we could call MyCorporation, simply means that Boss is a possible payer for EmployeeA of MyCorporation. Beware! This does not imply that EmployeeA is a possible payer for Boss: A customer association is an oriented association. Note: Be aware that there is additional set up work to perform when setting up a community.
12.3.2.2.2.The Current Customer of a Rule Is Not Necessarily the Calling Customer.

As a result, whenever a rule is dealing with a given customer1 (that customer is then called the current customer of the rule), the rules current customer is not necessarily a calling customer. Let us illustrate this with charging Rules.
1. As is the case with Charging Rules and with rating Plan Rules.
Page 384 of 968
11 September 2009
The role of a Charging Rules is to find out some customer account that would agree to pay for the calling customer. As a customer account always belongs to some customer, the Charging Rule will do the search on the customer accounts of some customer. Such a customer is necessarily a possible payer, and we have seen that possible payers can be different from the calling customer if that latter belongs to one or more communities. Note: The CRE discovers possible payers, other than the calling customer, by following customer associations that go out from the calling customer. To conclude, the current customer of the Charging Rule is a possible payer, and that possible payer can be another customer than the calling customer.
12.3.2.2.3.Whats an Association Type?

Now that the customer associations have been introduced, we can see association types. The CRE allows to type a customer association. Why would you want to do that? Say for example that the boss of a corporation agrees to pay for work related calls of his/her employees, but he/she wants the white-collar employees calls to be charged on a given account and the blue-collar employees calls to be charged on another account. The boss would then divide the customer associations from his/her employees into two main categories: White-Collars or Blue-Collars.
With the CRE, you do that by associating a so-called association type to each customer association from an employee. For that, you first create two instances of the Association Type object, one being called White-Collar and the other one being called Blue-Collar. Afterwards, you associate to the customer association from each employee one of the two Association Types, depending on whether the employee is a white-collar or a blue-collar.
12.3.2.2.4.Typical Example
When a calling customer belongs to one or more communities, the CRE will, under certain conditions, investigate one or more of these communities in order to find a payer for the calling customer. At time it investigates one of these communities in order to find out a possible payer, other than the calling customer, in that community, the CRE follows the customer association from the calling customer in that community. If the customer to which the customer association points has also customer associations, in the community that is being investigated, the CRE will not try to use that customer as a possible payer: It will first try the other customer associations in the community that is being investigated, and these customer associations have possibly an association type too. At a moment, by following the customer associations in the community that is being investigated, the CRE will find a possible payer for which it will start executing a charging rule, in order to find out which customer account of the possible payer will pay, would the possible payer agree to pay. If the charging rule then executes an association type criterion, the criterion will check if one of the customer associations from the calling customer to the current Customer (i.e., the possible payer), in the community that is being investigated, matches the association type the criterion specifies. If one matches the association type the criterion specifies, the criterion returns yes, and the Yes branch of the criterion starts executing.
11 September 2009
Page 385 of 968
Decision Trees
Note: Thus, if none of the customer associations, in the community that is being investigated, from the calling customer to the current customer, has an association type, the criterion returns no. Note: Note that, if the Charging Rule returns a Forbidden leaf, which means the possible payer refuses to pay, the CRE will keep trying to find out a possible payer in the community that is being investigated, thus still using the customer associations in the community.
12.3.2.3. Criterion Parameter Description
Figure 193 - Association Type Criterion Configuration Panel
Table 110 - Association Type Criterion Parameter Association Type Name Description Reference to the Association Type that the criterion tries to match. This is the value of Name* parameter of the Association Type that the criterion tries to match.
12.3.2.4. Criterion Availability

Table 111 - Association Type Criterion Availability Service Rule n.a. Usage Rating Rule n.a. Charging Rule Available Rating Plan Rule Available Top-Up Rule n.a.
12.3.2.5. Criterion Context

In order for a rule to be able to use this criterion, the rule must have a: Current Customer
Page 386 of 968
11 September 2009
12.3.3. Bundle Criterion

This criterion asks the following question: Can the bundles, that the criterion specifies, pay all the currently considered quantities that none of the already encountered bundle criteria, belonging to the same tree node, could pay? If the answer is yes, the Yes branch then starts executing. Note: In the context of a commit, the currently considered quantities are those that the current network event is asking to charge to the current Account. In the context of a reservation, the currently considered quantities are those that the current network event is asking to reserve.
12.3.3.2. Understanding the Bundle Criterion

With the CRE, you can associate one or more bundles to a given Account. Whenever the CRE has to commit/reserve network event quantities and the current Account (i.e., the Account to charge) has one or more bundles, you use the Bundle criterion to make the CRE first scan, in an order that you define yourself, the bundles of the Account, so that each of these bundles contributes, to the extent it can, to the payment.
Moreover, you use also the Bundle criterion to indicate whether, in case the bundles are not able to complete the payment, the main balance of the current Account is allowed or not to pay the part of the quantities the bundles could not pay. To have that behavior, just put one or more Bundle criteria on a decision tree node of a Usage Rating Rule, in the order you want them to be scanned by the CRE, and have the Else branch of the node connected either to a Tariff leaf (i.e., the current Accounts main balance is allowed to pay the unpaid part of the payment with that tariff) or to a Forbidden leaf (i.e., the current Accounts main balance is not allowed to pay the part of the payment the bundles could not pay). The figure below shows an example:
In this example, if the communication is international (this is detected by international Zoning Matrix Criterion) and happens in the summer (this is detected by the Date criterion, which is labelled Summer): 1. SummerInternationalBundle criterion is first used. In this example, it is supposed this criterion is using a Bundle that gives 1 hour a month of international calls at a summer preferential tariff,
11 September 2009
Page 387 of 968
Decision Trees
which is called PreferentialSummerInternational. In this example, it is assumed this bundle is offered. 2. 3. If SummerInternationalBundle can pay everything, the Yes branch of the criterion gets executed. And the decision tree execution stops. If SummerInternationalBundle cannot pay everything, its No branch is executed. Which means that InternationalBundle criterion is then executed. In this example it is assumed that InternationalBundle criterion uses a Bundle that gives 200 minutes a month of international calls at another preferential tariff, which is called PreferentialInternational. It is also assumed this bundle is paid 10 EURO a month. 4. 5. If InternationalBundle can complete the payment, its Yes branch gets executed. And the decision tree execution stops. If InternationalBundle cannot complete the payment, the Else branch starts executing. As it leads to a Tariff leaf (that tariff is called StandardInternational), and thus not to a Forbidden leaf, the Accounts main balance will pay the rest at StandardInternational tariff. And the decision tree execution stops.
What has been seen until now is the main logic of this typical use of the Bundle criterion. In addition, you should also be aware of what follows: The CRE imposes that the Yes branch of a Bundle criterion never leads to a criterion. Thus, the Yes branch must lead to a leaf. Moreover, that leaf must always be a Tariff leaf.
And it is that tariff that the criterion uses to assess what currently considered quantities its bundles are able to pay. This is the way the criterion knows which tariff it has to apply to its bundles: A bundle never specifies a tariff. Whenever a Bundle criterion executes, what it does is equivalent to performing the following steps, in the order they are listed: The criterion computes what part of the not-yet-paid currently considered quantities its bundles are able to pay. It does that computation using the tariff to which its Yes branch is connected. The CRE then takes a note of which bundles are able to pay which part of the not-yet-paid currently considered quantities. It also takes a note of the tariff of the Yes branch of the criterion. If the bundles of the criterion are not able to completely pay the not-yet-paid currently considered quantities, the No branch of the criterion gets executed (that is, the Bundle criterion just below the one that is being executed starts then executing). If the bundles of the criterion are able to completely pay the not-yet-paid currently considered quantities, the Yes branch of the criterion gets executed. That is, the decision tree then stops executing. Whenever the Else branch of a node of Bundle criteria get executed, its because the bundles of the Bundle criteria of the node are not able to pay all the currently considered quantities. If the Else branch leads to a Forbidden leaf, the CRE knows it is not allowed to use the current Accounts main balance for paying the currently considered quantities that the bundles are not able to pay. The CRE then knows that it is not possible to pay all the currently considered quantities and takes a note of that. The decision tree then stops executing. On the other hand, if the Else branch leads to a Tariff, the CRE knows that it is allowed to use the current Accounts main balance for paying the currently considered quantities that the bundles are
Page 388 of 968
11 September 2009
not able to pay. It also knows that the tariff to use for making the current Accounts main balance pay these quantities is the tariff to which the Else branch leads. The CRE then takes notes of the currently considered quantities that the bundles could not pay, of current Accounts main balance and of the tariff to use for costing these currently considered quantities that the bundles could not pay. The decision tree then stops executing. Given what the previous bullets explain, at time a decision tree stops executing and this happened from a node of Bundles, the CRE has made up a list of notes. In that list, each note, with the exception of the last note in case this latter is about the nodes Else branch, indicates some RUM quantities, some bundles from which quantities/money have to be removed and some tariff (that will be used to compute how much will be removed from the bundles). Thanks to these notes, the CRE then knows how to cost the currently considered quantities, whether it is for the purpose of committing or reserving them. As a result, the CRE will then use these notes to either commit or reserve the currently considered quantities.
12.3.3.3. What Constraints Apply to a Bundle Criterion?

The CRE imposes the following constraints on a Bundle criterion: The Yes branch of a Bundle criterion cannot lead to a criterion. It must thus lead to a leaf. Moreover, that leaf must be Tariff.
The Else branch of a node of Bundles cannot lead to a criterion. It must thus lead to a leaf. Moreover, that leaf must either be a Tariff leaf or a Forbidden leaf. Note: While you are drafting a decision tree, the decision trees graphic editor does not check whether you are observing or not the Bundle criteria order constraints. Nevertheless, in case some of these constraints were not observed, a runtime error will occur during the execution of the decision tree execution.
12.3.3.4. Using a Bundle/Counter Usage Label as the Name of a Bundle

The name of a bundle has to be a Bundle/Counter Usage Label that is of type Bundle. Thanks to Bundle/Counter Usage Label mechanism, a bundle name is independent of the current account of the rule that is executing a Bundle criterion. Choose for a bundle a name that reflects its usage. SummerInternationalBundle is an example of such a name.
11 September 2009
Page 389 of 968
Decision Trees
Figure 194 - Bundle Criterion Configuration Panel
Table 112 - Bundle Criterion Parameter Criterion Description Text* Description Enter here a short and concise text that describes what the criterion is doing. This text will appear in the decision tree graphic editor, to the right of the icon of the criterion. RUM na Counter Usage Label(*) This must be a reference to a bundle. This must thus be a reference to a Bundle/Counter Usage Label that is of type Bundle. This refers to the Bundle from which either money or quantities (depending on the type of the RUM of the Bundle) will be taken in order to pay for the currently considered RUM n quantities, to the extent the Bundle can.

The RUM that the bundle uses must be compatible with the RUM n of the tariff of the Yes branch of the criterion. The same bundle can be used by more than one RUM n of the criterion. If the bundle does not exist for the current Account (i.e., if the bundle has no buckets that refer to the current Account), everything happens as if the bundle were existing and had one bucket of zero units.
Page 390 of 968
11 September 2009
Table 112 - Bundle Criterion Parameter RUM nb Profile ) Reference to a Top-Up profile. When this parameter specifies a Top-Up profile, the criterion only considers the buckets, of the bundle that RUM n Counter Bundle/Counter Usage Label parameter specifies, that have been created by means of that Top-Up profile. Description

Advance Bundle Criteria
Creation of a bucket with a given Top-Up profile is only possible with Top-Up RTx requests.
This parameter is used for the Advance Bundle Criteria.When this parameter is set, the GUI is modified in order to authorize the correlation. Only RUM1 and RUM2 can be correlated (the third RUM can not be used).
a. n is to be replaced by 1, 2, or 3. b. n is to be replaced by 1, 2, or 3.
12.3.3.6. Criterion Parameter Description for Advance Bundle Criteria
Figure 195 - Single Run
11 September 2009
Page 391 of 968
Decision Trees
Figure 196 - Multi Run Table 113 - Parameter Description Parameter Correlation Description This parameter specifies whether the correlation is required on the single RUM or multi RUMs. If single RUM is selected, then the correlation is to be performed on the RUM selected from the drop down box (Currently this feature is not supported). If multi RUM is selected, then the correlation is to be performed on the two selected RUMs
12.3.3.7. Tip: Creating and Exploiting a Bundle

1. First choose a name for that Bundle. For example, SummerInternationalBundle (this is the name of a bundle, not of a Bundle criterion). For that, make sure that the bundle name is not used yet. That is, make sure that no instance of Bundle/Counter Usage Label object has its Name* parameter set to that name (e.g. set to SummerInternationalBundle). 2. Create the new Bundle/Counter Usage Label. Create an instance of Bundle/Counter Usage Label object. Set its Name* parameter to the name you chose for the bundle (e.g., to SummerInternationalBundle), set its Type* parameter to Bundle and set its Ratable Unit Metric* parameter to the kind of RUM quantity, whether it is expressed in terms of money or not, that the Bundle has to supply. Note you might need to set other parameters. For example, you might want the bundle to be a Multiple Buckets bundle, instead of being a Single Bucket bundle.
Page 392 of 968
11 September 2009
Note: If you put a Multiple Buckets bundle in a Top-Up profile, any Top-Up RTx request on that profile (the profile that profId field of the Top-Up RTx request refers to) will create a new bucket in the bundle, filled with the quantities/money the Top-Up has allocated to the bundle. 3. Create a link between the new Bundle/Counter Usage Label object instance and the Account Profile of each Account that must have access to the new bundle. For that, for each of these accounts, ensure that there exists an instance of Account Profile and Usage Link object with its Usage Name* parameter referring to the new Bundle/Counter Usage Label object instance and with its Account Profile* parameter referring to the Account Profile of the Account. 4. For each Account that has to benefit of the new Bundle, create the necessary buckets. A bundle is made up of buckets. The quantities/money allocated to a bundle is the sum of all the quantities/money allocated to its buckets. A bucket can be created either automatically (always in consequence of a Top-Up) or by an operator. Whenever it is an operator that creates a bucket, he/she must set, as a minimum, the following parameters: Service Retailer, Account Identifier (which refers to the Account to which the bucket belongs), Usage (which refers to the bundle name, which is a Bundle/Counter Usage Label) and Remaining Units (which specifies the quantities/money allocated to the bucket). 5. Exploit the created Bundle. Have the suitable rule (it is thus a Usage Rating Rule) use one or more Bundle criteria that suitably use the just created bundle. If no such rule exists, then the bundle will never be used.
Note: Its no problem to give to a Bundle criterion the same name as a Bundle one. In particular, if the Bundle criterion only uses one bundle, it makes sense to give to both the same name. For example, its no problem to call SummerInternationalBundle a Bundle criterion that only uses SummerInternationalBundle bundle.

Table 114 - Bundle Criterion Availability Service Rule n.a. Usage Rating Rule Available Charging Rule n.a. Rating Plan Rule n.a. Top-Up Rule n.a.
12.3.3.9. Correlation supported by Advance Bundle Criteria

This feature is available only when the Advance Bundle Criteria checkbox is selected on the Bundle Criteria GUI. This feature also provides a way of splitting the charging between same or different bundles for two RUM call. This feature provides the following two options: 1. 2. Correlation on single RUM with same bundles or different bundles (currently not supported). Correlation on a two RUM call with same or different bundles.
Correlation comes into picture when the bundle used for the charging does not have enough money to be charged
11 September 2009
Page 393 of 968
Decision Trees
Example 1: For a two RUM call with requested quantity as (120,120) using two different bundles b1 and b2 for RUM1 and RUM2 respectively. In case of credit limit, with the actual behavior, with best effort mode, it is possible that we chare 99% from b1 and only 1% from b2. So a correlation is done in order to charge both the RUMs with same prorate i.e. if from b1 we are able to charge only 67% of the quantities then from b2 also we must charge only 67% of the quantities. Example 2: Bundle corelation on differnt usage B1 and B2 Money available in B1=10.00 and B2=20.00 % For RUM1 = quantities that can be given from money available in B1/ Total requested quantites * 100 =5/120*100 =4.16 % % for RUM1 = quantities that can be given from money available in B2/ Total requested quantites * 100 =10/120*100 =8.33 % Minimum % out of both will be taken and same amount of quantities will be charged for both RUMs (like in this case only 5 qty will be charged from both Bundles.) In case of same Bundle Usage, the available quantity in the bundle is divided among the two RUMs based upon the following formula:Money allocated to first rum = (estimated_quantity*weightedBundleQty_est[0])/ (weightedBundleQty_est[0] +weightedBundleQty_est[1]+weightedBundleQty_est[2]) Money allocated to second rum = (estimated_quantity*weightedBundleQty_est[1])/ (weightedBundleQty_est[0] +weightedBundleQty_est[1]+weightedBundleQty_est[2]) Where, estimated_quantity = money available in the bundle weightedBundleQty_est[0] = money to be deducted from the bundle corresponding to RUM0 weightedBundleQty_est[1] = money to be deducted from the bundle corresponding to RUM1 weightedBundleQty_est[2] = money to be deducted from the bundle corresponding to RUM2 If only 20 is available in Bundle B1 and cost is 100 for RUM0 and 50 for RUM1, Money allocated to first rum = 20 * 100 / 100+50 =13.3333 Money allocated to second rum = 20 * 50 / 100+50 =6.6666 For Example, If the Main balance has 122 units and its a 3 RUM call. The cost to be deducted is 500(taking all the three RUMs together) Since we do not have enough amount in the main balance so a reverse rating is performed. After reverse rating 40 quantities are allocated to each RUM respectively which makes a total of 120(say 1.00 for 1 units get deducted) Now if the EMPTY BALNCE feature is enabled, then the left over credit in the main balance (122-120) has to be utilized. So a reverse rating is performed again on the remaining 2 units in the main balance to get the minimum quantitites with which we can empty the main balance completely. If after the reverse rating we are able to allocate 1 quantity from 2 units, then the same number of quantitites are given to all the configured RUMs. So in this case finally the quantites allocated to each RUM would be : RUM0 41, RUM1 41, RUM2 41.
Page 394 of 968
11 September 2009
12.3.3.10.Criterion Context
In order for a rule to be able to use this criterion, the rule must have a: Current Account Current Network event (from which the considered RUM quantities are taken)
11 September 2009
Page 395 of 968
Decision Trees
12.3.4. Bundle Threshold Criterion

The Bundle Threshold Criterion answers the following question: Does the specified Bundle fulfill the condition? This condition applies to the available units of the Bundle.
What are the available units of a Bundle?

Bundle units are considered available when they can be used now for paying the ongoing event. Concretely, these are the units of valid Buckets, that are not currently blocked by a reservation. The non-available units of a Bundle are: the units of Buckets that are not in their validity period, i.e. only created or already expired. the units currently reserved for a potential other event.
How to build a decision tree branch after a Bundle Threshold Criterion?

After a Bundle Threshold Criterion, in the YES branch as well as in the ELSE branch, you can use any criterion or leaf.
This Bundle Threshold criterion (the icon that is labeled voice < 10) checks whether the Bundle with the Usage Label voice has strictly less than 10 units available. If the voice Bundle contains less than 10 units, this branch, which is the Yes branch of the criterion, starts executing. Else, it does not start executing.
Dont get confused with the Bundle Criterion
If you use a Tariff right after the Bundle Threshold Criterion, the Tariff will charge on the Main Balance, not on the tested Bundle. If you want to charge on the tested Bundle, you must add a Bundle Criterion between your Bundle Threshold Criterion and your Tariff leaf. Check out the following three examples:
Without Bundle Criterion: charge on the Main Balance

If the Bundle bdl_time contains more than 60 available units, then the ongoing event will be charged on the Main Balance, using the Tariff voice_MainBalance.
With a Bundle Criterion: charge on the same Bundle

If the Bundle bdl_time contains more than 60 available units, then the ongoing event will be charged on that same Time Bundle, using the Tariff voice_TimeBundle.
Page 396 of 968
11 September 2009
With a Bundle Criterion: charge on the another Bundle

If the Bundle bdl_time contains more than 60 available units, then the ongoing event will be charged on another Bundle (the Money Bundle), using the Tariff voice_MoneyBundle.
Figure 197 - Bundle Threshold Criterion Configuration Panel

Table 115 - Bundle Threshold Criterion Parameter Bundle Name Comparator Description Reference to the Usage Label of the Bundle to be tested. Comparison operator: < (strictly smaller) <= (smaller or equal) > (strictly greater) >= (greater or equal) This comparison operator is used to compare the available units (i.e. valid and not reserved) of the Bundle with the Threshold Value specified below. Threshold Value Value against which the Bundles available units will be compared, using the comparison operator specified above.
11 September 2009
Page 397 of 968
Decision Trees

Table 116 - Bundle Threshold Criterion Availability Service Rule n.a. Usage Rating Rule Available Charging Rule n.a. Rating Plan Rule n.a. Top-up Rule n.a.

In order for a rule to be able to use the Bundle Threshold Criterion, the rule must have a: Current Account Current Network event (from which the considered RUM quantities are taken) Usage Label of type Bundle defined for the current Service Retailer
Page 398 of 968
11 September 2009
12.3.5. Closed User Group Criterion

This criterion answers the following question: Do the calling user and the called party, of the network event that is being processed, belong to the same Closed User Group (CUG)? If the answer is yes, then the Yes branch of the criterion is executed. Note: The calling user and the called party have to be users of the same Service Retailer. Otherwise, the answer to the question will always be No. Note: Moreover, each of these users has to be a Customer of the same Service Retailer. Otherwise, the answer to the question will always be No. This is because only users that are Customers can belong to a CUG. Note: The CUG comparison is case sensitive. Thus, if the calling user belongs to CUG Ab and the called party belongs to CUG aB, they do not belong to the same CUG.
This Closed User Group criterion (the icon that is labeled Same CUG) checks whether the calling and the called customers belong to the same CUG.
If they belong to the same CUG, this branch, which is the Yes branch of the criterion, starts executing. Else, it does not start executing.
Figure 198 - Closed User Group Configuration Window
11 September 2009
Page 399 of 968
Decision Trees
Table 117 - Closed User Group Criterion Parameter Criterion Description Text* Description This is the text that will appear to the right of the icon that represents the Closed User Group criterion. This is purely descriptive text. Try to choose text that enhances the readability of the decision tree. Example Setting this parameter value to Same CUG results in the following:

Table 118 - Closed User Group Criterion Availability Service Rule Available Usage Rating Rule Available Charging Rule Available Rating Plan Rule Available Top-Up Rule n.a.

In order for a rule to be able to use this criterion, the rule must have a: Current Customer
Page 400 of 968
11 September 2009
12.3.6. Counter Criterion

A Counter criterion specifies how one or more counters of the current Account have to be updated by the CRE. The Counter criterion is the only criterion that asks no question. The Counter criterion is however like any other criterion: Like them, it has a Yes branch and a No branch. Simply, as soon as a rule has executed a Counter criterion, it is always the Yes branch of the Counter criterion that starts executing. Things happen thus as if the Counter criterion were asking a question for which the answer is always Yes. What is then the effect of executing a Counter criterion? The purpose of a Counter criterion is only to instruct the CRE how, and when, it has to update the counters the criterion specifies. In other terms, at time a Counter criterion gets executed, the CRE takes note of what Counter(s) the criterion indicates to update, and of how it has to update them. Thus, whenever a Counter criterion gets executed by a rule, none of the Counters it specifies are updated. Note: If a counter is referred to by no Counter criterion, that counter will never be updated by the CRE: The CRE needs to be instructed how it has to update which counter, and its the execution of a Counter criterion by a rule that tells the CRE how it has to update which counter.
Note: You thus define yourself how the CRE updates the counters you attach to your Accounts, simply by setting up as necessary the needed Counter criteria, and by having them used as necessary by the necessary rules. Note: Be fully aware that the execution of a Counter criterion never updates the counters that the criterion specifies. Indeed, the execution of a Counter criterion by a rule just means that the CRE gets instructed to update the counters that the criterion specifies and gets instructed how and when to update them. Thus, the value of these counters is not updated during the execution of the rule. To know when and how these counters are updated, read further this criterions explanation.
12.3.6.2. Using a Bundle/Counter Usage Label as the Name of an Accounts Counter

The fact that a Counter criterion always executes on the current Account of the criterions rule implies that the name of a counter is always a Bundle/Counter Usage Label: As a Counter criterion always works on the current Account, its necessary to give to each counter, that the criterion uses, a name that is independent of the Account to which the counter applies. This is exactly what Bundle/Counter Usage Labels bring up and are made for. Thats the reason why the CRE imposes that the name of an Counter must be a Bundle/Counter Usage Label. That way, a counter receives a name that is independent of the Account to which it applies, but that reflects what that counter is used for. That is, with a Bundle/Counter Usage Label, you give the counter a name that reflects its usage. The following are counter names (and thus, Bundle/Counter Usage Labels) examples: TotalCallTimeCounter
11 September 2009
Page 401 of 968
Decision Trees
NumberOfSMSsesCounter NumberOfPeakCallsCounter As you see, these names make sense for any Account, and simply indicate what the counter is used for. Thus, if you need to create, for some Account, a counter that calculates the number of SMSes, you just create for that account an Counter whose Usage* parameter is set to NumberOfSMSsesCounter. Be sure that latter Bundle/Counter Usage Label exists: If it does not exist, create it.
See also 12.3.6.4, Tip: Creating and Exploiting a Counter, on page 404.
Figure 199 - Counter Criterion
Page 402 of 968
11 September 2009
Table 119 - Counter Criterion Parameter Criterion Description Text Description Enter here a short and concise text that describes what the criterion is doing. This text will appear in the decision tree graphic editor, to the right of the icon of the criterion. Immediate Update Three options are available in the drop-down menu 1. Update Counter Non Immediate: - Previous value of the Counter (or more specifically the value stored in the database) will be used for calculations/decision making. New value of the Counter will be updated (i.e. Database Update) at the commit phase (Endcall Request). In case of Unsuccessful calls, rollback is possible. 2. Update Counter Immediate (for Calculations only): - New updated value of the Counter will be used for calculations/decision making). New value of the Counter will be updated (i.e. Database Update) at the subsequent commit phase (Nextreq or Endcall). In case of Unsuccessful calls, rollback is possible. 3. Update Counter Immediate (In Database and for Calculations): - New updated value of the Counter will be used for calculations/decision making). New value of the Counter will be updated (i.e. Database Update) immediately. As evident, Rollback will not be possible even for the unsucessfull calls. Currently, this option is not implimented and will be developed in future.
Table 120 - Counter Criterion - nth Counter Update GUI Frame Parameter Counter* Description Reference to a Bundle/Counter Usage Label that is of type Counter. This must be the Bundle/Counter Usage Label that refers to the counter the nth Counter Update GUI frame is about.
If the Bundle/Counter Usage Label is not used by a counter of the current Account (that is, if the current Account has no Counter that uses that Bundle/Counter Usage Label as its name), everything happens as if the nth Counter Update GUI frame were specifying no counter. This will naturally not prevent the Yes branch to start executing.
11 September 2009
Page 403 of 968
Decision Trees
Table 120 - Counter Criterion - nth Counter Update GUI Frame Parameter VALUE Description Use this parameter to indicate which parameter (from the two that can be used as a counter) of the Counter will be used as a counter. For that, you need to choose one of the following values: VAL This makes the nth Counter Update GUI frame use Current Counter Value parameter, of the Counter, as a counter. VALPER This makes the nth Counter Update GUI frame use Previous Counter Value parameter, of the Counter, as a counter. Valuen If either Incremental or Set check box is checked, you need to set this parameter to some value. To know what use is then made of this value, see Incremental and Set check boxes documentation. If either Quantity or Credit check box is checked, this parameter is not used, which means you then do not need to set it to some value. Incremental Check this parameter if you want the counter to be incremented, at the final commit done on the Account to which the counter is attached, by the value that Valuen specifies.
Section 12.3.1.2, Intermediate Commit and Final Commit, on page 380,

explains what a final commit is.
Set
Check this parameter if you want the counter to be set, at the final commit done on the Account to which the counter is attached, to the value that Valuen specifies.

explains what a final commit is.
Quantity
Check this parameter if you want the counter to be incremented, at each intermediate commit and at the final commit done on the Account to which the counter is attached, by the just committed quantities (this is the sum of all used RUMs, whether they are RUM 1, RUM2 or RUM 3).

explains what an intermediate commit and a final commit are.
Credit
Check this parameter if you want the counter to be incremented, at each intermediate commit and at the final commit done on the Account to which the counter is attached, by the cost of the just committed quantities (this is the sum of all used RUMs, whether they are RUM 1, RUM2 or RUM 3).

explains what an intermediate commit and a final commit are.
12.3.6.4. Tip: Creating and Exploiting a Counter

To create a Counter:
Page 404 of 968
11 September 2009
1.
Choose the Counters name. That is, choose a Bundle/Counter Usage Label a name (Name* parameter) that no instance of Bundle/Counter Usage Label object is already using and that reflects the purpose of that Counter. As an example, let us assume that TotalCallTimeCounter is such a name.
2.
Create the new Bundle/Counter Usage Label. Create an instance of Bundle/Counter Usage Label object, of which Name* parameter is set to the name you chose for the counter (e.g., to TotalcallTimeCounter) and of which Type* parameter is set to Counter.

3.
See also section 9.10, Bundle/Counter Usage Label Object, on page 280.
Associate the new Bundle/Counter Usage Label with the Account Profile of the Account. That is, create an instance of Account Profile and Usage Link object that refers to both the new Bundle/Counter Usage Label and to the Account Profile of the Account.

4.
See also section 20.2, Account Profile and Usage Link object, on page 804.
Create Counters that use that Bundle/Counter Usage Label. For each Account for which you would like TotalCallTimeCounter to be calculated, create an Counter object instance that refers to both the just created Bundle/Counter Usage Label and to the Account. That is, in the instance, set Usage* parameter to the name of the Bundle/Counter Usage Label, and make Account Identifier* refer to the Account of which the instance is an Counter.

5.
See also section 22.1, Counter object, on page 852.
Exploit the created Counters. Have the suitable rule (it is thus either a Usage Rating Rule or a TopUp Rule) use a Counter criterion that suitably updates the counter (e.g., that suitably updates counter TotalCallTimeCounter). If no such rule exists, then the counter will never be updated.
12.3.6.5. Tip: What If a Tariff Switch Makes A Rule Re-Execute a Counter Criterion?
On tariff switches, see section 12.3.1.5, Switching of Tariff, of Customer Account, of Service Offer, of Service,
on page 382. See also section 12.3.7.3, Tariff Switches that Are Due to a Counter Threshold Criterion., on page 410.
If a Usage Rating Rule gets executed more than once1 in the context a given Reservation / Commit Charging, it may turn out that two or more of these executions go through the same Counter criterion. In that case, its the first time that the criterion is gone through (of course, by same Reservation / Commit Charging) that counts. That is, it is only at that first time that the criterion gives Counter update instructions to the CRE. At the other times, the CRE simply sees that the update instructions had already be given for the charging and thus no Counter update instructions are given again to the CRE, since the CRE already knows them. Of course, still then, the Usage Rating Rule leaves the criterion via the criterions Yes branch.
1. Reminder: Whenever the CRE re-executes the Usage Rating Rule that is used by a given Commit / Reservation Charging, it always does that because it has detected a tariff switch. Of course, the first execution of the Usage Rating Rule of a given Commit / Reservation Charging is always done at time the CRE processes the First Reservation RTx request that starts the Commit / Reservation Charging.
11 September 2009
Page 405 of 968
Decision Trees

Table 121 - Counter Criterion Availability Service Rule n.a. Usage Rating Rule Available Charging Rule n.a. Rating Plan Rule n.a. Top-Up Rule Available

In order for a rule to be able to use this criterion, the rule must have a: Current Account
12.3.6.8. Counter Handling in various Cancel scenarios

Note: These scenarios apply to Counter Updates done using Counter criteria or Setcounter SIB via Litesce. The behaviour is generic and applies to both the scenarios. Note: If the last option is used, i.e Update Counter Immediate (In Database and for calculations both), rollback is not possible what so ever. Currently, this option is not implemented and will be developed in future. For other options, that is, for flag option 0 and 1, rollback is possible according to following cases.
Case 1:
First Req--> Cancel and qt_used > 0(This is allowed as per the south API document) Operation qty/cost: Counter updated in DB. Operation Set/Increment Flag = 0: Counter update in the DB. Flag = 1: Counter update in the DB. Flag = 2: Updated counter valueis already updatedin the DB. Note: Practically this scenario should not arise. However, as per CRE South API, cancel with non-zero qty can theoretically arrive. Hence above case is for appropriate handling at CRE.
Case 2:
First Req--> Cancel and qt_used = 0 (qt_tot = 0) At cancel: Operation qty : No counter update in the DB. Operation cost: Counter update only if apply connection cost. Operation set/increment : No counter update in the DB (only in case Update DB option is not selected in immediate option).
Case 3:
First Req -> NextRequest -> Cancel and Qt_used =0 (qt_tot > 0) At Next request (commit part): Counter update done At cancel: Operation qty/cost: Counter update only if qty/cost charged due to tick rounding Operation set/increment : Flag =0 or 1:
Page 406 of 968
11 September 2009
No counter update in DB if there is no time tariff switch or counter threshold criteria Counter update in DB incase tick rounding implies charging from tariff/balance after time tariff switch. This is applicable incase of any charging wrt new tariff after switch. The counters impacted are only the new counters applicable due to the new tariff after the switch. Flag = 2 : Updated counter value is already updated in.
Case 4: Top up (Top up Rule)/ LiteSCE(using setcounter SIB)

Flag = 0: Original counter value used. Counter updated in DB only if topup is successful. Flag = 1: Updated counter .value is used but updated in DB only if topup is successful Flag = 2: Updated counter value is used but updated in DB immediately. (No counter rollback even if call fails).
Case 5: OneShot Call

Flag = 0: Original counter value used to arrive at tariff. Counter updated in DB only if call is successful. Flag = 1: Updated counter value is used to arrive at tariff. Counter updated in DB only if call is successful. Flag = 2: Counter value is updated in Database immediately and used to arrive at tariff. (No counter rollback even if call fails).
11 September 2009
Page 407 of 968
Decision Trees
12.3.7. Counter Threshold Criterion

This criterion asks the following question: Is the counter, that the criterion specifies, strictly greater than some threshold value or not. If the answer to this question is yes, then the Yes branch of the criterion starts executing. Note: The threshold value can be either a constant value or the current value of another counter.
Figure 200 - Counter Threshold Criterion Configuration Panel Which parameters the configuration panel shows depends on whether A Constant or Another Counter check box is checked. The figures below shows, for each case, what the criterion configuration panel looks like.
Page 408 of 968
11 September 2009
Counter GUI frame specifies which counter has to be compared against the threshold value.
A Constant check box is checked. The threshold value is a constant. Threshold value parameter specifies the constant threshold value.
Figure 201 - Counter Threshold Criterion Configuration Panel When A Constant Is Checked
Counter GUI frame specifies which counter has to be compared against the threshold value.
Another Counter check box is checked. The threshold value is a counter current value.
Second Counter GUI frame specifies the counter whose current value is the threshold value of the criterion.
Figure 202 - Counter Threshold Criterion Configuration Panel When Another Counter Is Checked
Table 122 - Counter Threshold Criterion Parameter Counter Description Reference to the Bundle/Counter Usage Label of the Counter that is to be compared against the threshold value.
11 September 2009
Page 409 of 968
Decision Trees
Table 122 - Counter Threshold Criterion Parameter Val Description If Val check box is checked, the criterion compares Current Counter Value parameter, of the Counter, against the threshold value. This implies that Previous Counter Value parameter is then not compared against the threshold value. if Valper check box is checked, the criterion will compare Previous Counter Value parameter, of the Counter, against the threshold value. This implies that Current Counter Value parameter is then not compared against the threshold value. If A Constant check box is checked, the current counter value (that is, either Current Counter Value or Previous Counter value) is compared against a constant. Threshold parameter must then specify that constant. If Another Counter check box is checked, the current counter value (that is, either Current Counter Value or Previous Counter value) is compared against the current value of another counter. That other counter is specified by Second Counter GUI Frame, which must then be correctly set up. When A Constant check box is checked, this parameter specifies the threshold against which the current counter value is checked. This must be an unsigned integer value.
Valper
A Constant
Another Counter
Threshold Value
Table 123 - Counter Threshold Criterion - Second Counter GUI Frame Parameter Second Counter Description When Another Counter check box is checked, this parameter must contain the reference to the Bundle/Counter Usage Label of the Counter that is used to specify the threshold value. This parameter specifies the threshold counter. Val If Val check box is checked, current value of Current Counter Value parameter, of Second Counter Counter, defines the threshold value. This implies that Previous Counter Value parameter is then not used as the threshold value. if Valper check box is checked, current value of Previous Counter Value parameter, of Second Counter Counter, defines the threshold value. This implies that Current Counter Value parameter is then not used as the threshold value.
Valper
12.3.7.3. Tariff Switches that Are Due to a Counter Threshold Criterion.

This section uses a number of times the term intermediate commit. This term is explained at section 12.3.1.2, Intermediate Commit and Final Commit, on page 380.
Page 410 of 968
11 September 2009
Unlike a One-Shot Rating and Charging, which is processed by means of one single RTx request to the CRE, a Reservation / Commit Charging is processed by means of several RTx requests to the CRE (normal scenario of such a charging is: One First Reservation RTx request received by the CRE, followed by zero or more related Next Reservation RTx requests received by the CRE, followed by one related End Call RTx request received by the CRE). When it processes the First Reservation RTx request, the CRE identifies the tariff for the quantities to reserve (does the Account have enough money to pay for the quantities to reserve?) by identifying which Usage Rating Rule it has to use in order to find out the tariff, and by then executing that Usage Rating Rule, in order to know which tariff it has to apply. When it processes a Next reservation RTx request, the CRE also needs to identify the tariff for the quantities the Next Reservation RTx request is asking to reserve. Indeed, the tariff to be applied by the reservation (does the Account have enough money to pay for the quantities to reserve?) might be different from the one currently in use. For example, if a Counter Threshold criterion, during the Usage Rating Rule execution for the First Reservation RTx request, contributed to choose a tariff, it might happen that another tariff has to be used when a Next Reservation RTx request is being processed. Indeed, if the current tariff was chosen because the counter of the Counter Threshold criterion was below the threshold at time the Usage Rating Rule executed, and that counter has become higher than that threshold since then, running the Usage Rating Rule again is likely to yield another tariff. To find out whether a new tariff has to apply in case of reservation due to a Next Reservation RTx request, the CRE does not run the Usage Rating Rule again. This would be too inefficient. Instead, after it has executed the intermediate commit (if you have read Counter criterion documentation, you already know that only intermediate commits and final commits can update counters), the CRE executes each Counter Threshold criterion, that contributed to find the current tariff, to see whether a tariff switch has to occur in consequence of the criterion counter becoming higher than the counter threshold. If the counter value has become higher, the CRE re-executes the Usage Rating Rule in order to find out which tariff to apply to the reservation being asked by the Next Reservation RTx request currently processed. Note: During a Reservation / Commit Charging, a tariff switch (more generally, a rating information switch) can occur only if one or more of the following criteria contributed to find out the currently used tariff: Counter Threshold Criterion, if a counter goes above its threshold. If a counter goes above its threshold, the new tariff is applied from the moment the CRE sees that (which corresponds to the time at which the Next Reservation RTx request that sees that change is processed) Time Criterion, if a time band limit is crossed. If the time band limit is crossed, the new tariff applies as soon as the band limit is crossed. Date Criterion, if a date band limit is crossed. If the date band limit is crossed, the new tariff applies as soon as the band limit is crossed. Note: The Counter Threshold Criterion only supports Tariff switching. For more on this, see section 12.3.1.5, Switching of Tariff, of Customer Account, of Service Offer, of Service, on page 382.
11 September 2009
Page 411 of 968
Decision Trees

Table 124 - Counter Threshold Criterion Availability Service Rule n.a. Usage Rating Rule Available Charging Rule n.a. Rating Plan Rule n.a. Top-Up Rule Available

Page 412 of 968
11 September 2009
12.3.8. Date Criterion

This criterion asks the following question: Is the current network event date the one of a day that is of the day type that the criterion specifies? If the answer is yes, the Yes branch starts executing. Note: Naturally, the event date is from the network event. Thus, if the network event is one that is played offline, the event date that is taken into account is the one stored in the network event. Not the date at which the network event is played offline.
This Date criterion checks whether the event date in the network event being processed is the one of a holiday. If it is, the Yes branch of the criterion is executed.
Figure 203 - Date Criterion Configuration Panel
Table 125 - Date Criterion Parameter Day Type* Description This must be the name of one of the day types of the calendar that the current rule is using.
See also 4.6, Calendar Object, on page 150.

Example Setting this parameter to Holidays, which is one of the day types of d_School calendar, which is the current rule is using, results in the following.
11 September 2009
Page 413 of 968
Decision Trees
12.3.8.3. Tariff Switches that Are Due to a Date Criterion.

See section 12.3.7.3, Tariff Switches that Are Due to a Counter Threshold Criterion., on page 410. Note: The Date criterion only supports Tariff switching. For more on this, see section 12.3.1.5, Switching of Tariff, of Customer Account, of Service Offer, of Service, on page 382.

Table 126 - Date Criterion Availability Service Rule Available Usage Rating Rule Available Charging Rule Available Rating Plan Rule Available Top-Up Rule Available

In order for a rule to be able to use this criterion, the rule must have a: Current Network Event
Page 414 of 968
11 September 2009
12.3.9. Destination Criterion

This criterion asks the following question: Does the destination, of the event that the network event being processed is about, match the Area, or part of it, that the criterion specifies? If the answer is yes, the Yes branch of the criterion starts executing.
This Destination criterion checks whether the destination of the event, that the network event being processed is about, matches identifier 071, which is a part of some area. If the destination matches that identifier, this branch, which is the Yes branch of the criterion, starts executing. Else, it does not start executing.
Figure 204 - Destination Criterion Configuration Panel
Figure 205 - Destination Criterion Configuration Panel - when Area is checked
11 September 2009
Page 415 of 968
Decision Trees
Figure 206 - Destination Criterion - when Area Identifier without Type is checked
Figure 207 - Destination Criterion - when Area Identifier with Type is checked
Table 127 - Destination Criterion Parameter Description The Origin criterion and the Destination criterion work exactly the same way, except that the first criterion checks the origin and that the last criterion checks the destination. Therefore, to know more about how Destination criterion works, please take knowledge of section 12.3.18, Origin Criterion, on page 445.

Table 128 - Destination Criterion Availability Service Rule Available Usage Rating Rule Available Charging Rule Available Rating Plan Rule Available Top-Up Rule n.a.

In order for a rule to be able to use this criterion, the rule must have a:
Page 416 of 968
11 September 2009
Current Network Event
11 September 2009
Page 417 of 968
Decision Trees
12.3.10. Destination Zone Criterion

12.3.10.1.Criterion Purpose
This criterion asks the following question: Does the destination, of the event that the network event being processed is about, belong to the Zone (i.e., the Super Area) that the criterion specifies? If the answer is yes, the Yes branch of the criterion starts executing. Note: To learn more about Zones and Super Areas, see chapter 16.1.1, Purpose: Making Decisions based on Zoning features, on page 543.
12.3.10.2.Criterion Parameter Description
Figure 208 - Destination Zone Criterion Configuration Panel Table 129 - Destination Zone Criterion - zdestcri Parameter Zone (Super Area)*
zoneref
Description This must be the name of a Zone (i.e., a Super Area) of either the current Service Retailer or of its default Service Retailer. Naturally, if a Zone (i.e., a Super Area) of the current Service Retailer overrides (i.e., has the same name as) a Zone (i.e., a Super Area) of the default Service Retailer, the criterion uses the current Service Retailers Zone (i.e., Super Area)
Clicking on the HELP button to the right of the parameter lists the Zones (i.e., Super Areas) of the current Service Retailer and of the default Service Retailer. Naturally, if a Zone (i.e., super Area) of the current Service retailer has the same name as a Zone (i.e., Super Area) of the default Service Retailer, the list shows the name only once.
12.3.10.3.Criterion Availability
Table 130 - Destination Zone Criterion Availability Service Rule n.a. Usage Rating Rule Available Charging Rule n.a. Rating Plan Rule n.a. Top-Up Rule n.a.
In order for a rule to be able to use this criterion, the rule must have a:
Page 418 of 968
11 September 2009
Current Network Event
11 September 2009
Page 419 of 968
Decision Trees
12.3.11. Discount Criterion

This criterion asks the following question: Does the event date, of the current network event, fall within the period of time that the criterion specifies? If the answer is yes, then: If the Usage Rating Rule, that is executing the criterion, will return a main balance tariff1 (i.e. the tariff to apply to the current Accounts main balance), the percentage-based discount that the criterion specifies shall be applied to that tariff, and The Yes branch of the criterion starts executing. Note: Naturally, the event date is from the network event. Thus, if the network event is one that is played offline, the event date that is taken into account is the one stored in the network event. Not the date at which the network event is played offline.Discount Criteria also apply to bundle usages of Money type. Bundle usage of any other rum-type will not considered for the discount. To activate Discount criteria for bundles, Arena variable "APPLY_BDL_DISC" needs to be created in service retailer and should be set to "1" for this feature.
This Discount criterion checks whether the Event Date falls between 15 December 2005, at 0 oclock, and 14 January 2006, at midnight.
If the Event Date falls within that period of time, the CRE takes note of which discount it has to apply to which RUM at time it rates the network event. Then, it executes the Yes branch of the criterion. Of course, if the Event Date does not fall in that period of time, the Yes branch is not executed.
1. If the Usage Rating Rule is using one or more Bundle criteria, it could be that it also returns tariffs and quantities to apply to bundles. The Discount criterion does not apply to these tariffs: The Discount criterion applies to a tariff only when that tariff is applied to a main balance.
Page 420 of 968
11 September 2009
Figure 209 - Discount Criterion
Table 131 - Discount Criterion Parameter Discount on RUM 1(%) Description Enter here a percentage if you want to provide a discount on RUM 1. The RUM1 cost, as computed by the main balances tariff that is going to be applied to the network event being processed, will be lowered by the percentage this parameter specifies. This must be an integer value. Discount on RUM 2(%) Enter here a percentage if a second RUM exists for the network event being processed and if you want to provide a discount on this RUM. The RUM2 cost, as computed by the main balances tariff that is going to be applied to the network event being processed, will be lowered by the percentage this parameter specifies. This must be an integer value. Discount on RUM 3(%) Enter here a percentage if a third RUM exists for the network event being processed and if you want to provide a discount on this RUM. The RUM3 cost, as computed by the main balances tariff that is going to be applied to the network event being processed, will be lowered by the percentage this parameter specifies. This must be an integer value.
11 September 2009
Page 421 of 968
Decision Trees
Table 131 - Discount Criterion Parameter Start Date* Description Date at which the discount validity period starts. This must be a date. Example Specifying 15/12/2005 in this parameter makes the period start on 15 december 2005, at the beginning of the day (at 0 oclock). Stop Date* Date at which the discount validity period ends. This must be a date. Example Specifying 14/01/2006 in this parameter makes the period start on 14 january 2005, at the end of the day (at midnight).
12.3.11.3.How Discounts Cumulate

RUM discounts cumulate. But how do they cumulate?
The following example illustrates how they cumulate. It makes two discounts cumulate. In this example, the two discount criteria of the figure below cumulate if the event date, of the network event being processed, falls between 23/12/2005 and 03/01/2005.
Assuming that the Discount criterion for the discount valid from 15/12/2005 to 14/01/2006 indicates a 25 percent discount on RUM 1, and assuming that the Discount criterion for the discount that is valid from 23/12/2005 to 03/01/2006 specifies a 10 percent discount on RUM 1, then the total discount on RUM 1 from 23/12/2005 to 03/01/2006 will be computed as follows: 1. If the Usage Rating Rule returned a main balances tariff, the CRE uses that tariff to compute the cost on RUM 1. This cost is hereby called the full RUM 1 cost. The CRE then proceeds to next step. If the Usage Rating Rule did no return a main balances tariff, the CRE applies no discount, and thus executes none of the following steps. 2. The CRE then lowers the full RUM 1 cost by 25 percent, which gives a new cost that is hereby called the first discounted RUM 1 cost.
Page 422 of 968
11 September 2009
3.
The CRE then lowers the first discounted RUM 1 cost by 10 percent, which gives a new cost that is hereby called the second discounted RUM 1 cost. This last cost is the one that will be charged on RUM 1.
Naturally, the CRE proceeds similarly for the other RUMs whenever discounts are also specified on them. This example was about two discounts that cumulate. Naturally, it generalizes to any number of discounts that cumulate. In that case the Nth discounted RUM x cost is computed by lowering the (N-1)th discount RUM x cost by the percentage that the Nth discount criterion indicates for RUM x. Moreover, RUM discounts due to a Discount criterion do not only cumulate with each other: They also cumulate with the RUM discounts due to a Preferred Number criterion and with those due to a Promotion criterion. And vice-versa. All these RUM discounts cumulate following the logic explained above, although that logic has only been explained in the context of the RUM discounts due to a Discount criterion.
Table 132 - Discount Criterion Availability Service Rule n.a. Usage Rating Rule Available Charging Rule n.a. Rating Plan Rule n.a. Top-Up Rule n.a.
In order for a rule to be able to use this criterion, the rule must have a: Current Account Current Network Event
11 September 2009
Page 423 of 968
Decision Trees
12.3.12. Event Type Criterion

This criterion answers the following question: Does the type of the event, that the current network event is about, equal the Network Event Type that the criterion specifies? If the answer is yes, the Yes branch then starts executing. Note: The type of the event, that the current network event is about, is deduced from the following parameters of the current network event: calltype, evt_type.
This Event Type criterion (the icon that is labeled MOC) checks whether the type of the event, that the current network event is about, equals MOC or not. If it equals MOC, this branch, which is the Yes branch of the criterion, starts executing. Else, the branch does not start executing.
Figure 210 - Event Type Criterion Configuration Panel
Table 133 - Event Type Criterion Parameter Network Event Type* Description This must be the value of Event Type Name* parameter of one instance of Network Event Type object.
You should consult the documentation of parameter Event Type Name*,

page 221.
Example Setting this parameter value to MOC, which is a network event type, results in the following:
Page 424 of 968
11 September 2009
Table 134 - Event Type Criterion Availability Service Rule Available Usage Rating Rule Available Charging Rule Available Rating Plan Rule Available Top-Up Rule Available
11 September 2009
Page 425 of 968
Decision Trees
12.3.13. Friends and Family Criterion

If the network event being processed does not mention a member type (i.e., if event member type, in the network event, is set to either 0 or 1) for its called party, this criterion asks the following question: Does the called party belong to the FNF list of the calling user for the member type that the criterion specifies? Otherwise (i.e., if the network event being processed mentions a member type for its called party), this criterion asks the following question: Does the called party belong to the FNF list of the calling user for the member type that the network event specifies and does that member type match the one that the criterion specifies. If the answer to the asked question is yes, the Yes branch of the criterion starts executing.
This FNF criterion specifies a member type equal to 10. If the answer to the question it asks is yes, the Yes branch of the criterion starts executing.

Figure 211 - Friends and Family Criterion Configuration Panel
Page 426 of 968
11 September 2009
Table 135 - Friends and Family Criterion - fnfcrite Parameter Friends and Family Member Type
ptcnbr
Description Reference to the Friends and Family Member Type Identifier to which the current Criterion is restricted. 0: Any Member
All the FNF Members will fulfill the criterion.

1: Any Member Type
All the typed FNF Members will fulfill the criterion, except the FNF
Members of Type 1 (meaning no type). 2 .. x: Only Member Type x
Only the FNF Members of Type x will fulfill the criterion.

Empty parameter If the Member Type parameter of the Friends and Family Criterion is left empty, then the value taken into account will be 0 (zero). Example Setting this parameter type to 10 results in what follows:
12.3.13.3.Example
Table 136 Current Network Event Called Party 7 3 Event Member Type 7 4 9 7 0 7 4 9 Calling User FNF List User 3 5 3 3 5 3 3 Yes Type 3 Criterion FnF Type Result Yes
11 September 2009
Page 427 of 968
Decision Trees
Table 136 Current Network Event Called Party 7 3 Event Member Type 4 9 7 7 0 4 9 7 7 3 4 9 7 7 0 4 9 7 7 3 7 4 9 7 7 0 7 4 9 7 Calling User FNF List User 5 3 5 5 3 5 5 3 5 5 3 5 3 5 3 5 3 5 3 5 1 Yes 1 Yes
Criterion FnF Type 3 Result No
Type
No
No
Yes
Table 137 - Friends and Family Criterion Availability Service Rule Available Usage Rating Rule Available Charging Rule Available Rating Plan Rule Available Top-Up Rule n.a.
In order for a rule to be able to use this criterion, the rule must have a: Current Network Event Current user (i.e., either a Current Customer or a Current Account)
Page 428 of 968
11 September 2009
12.3.14. Generic Criterion

This criterion lets you specify a comparison that involves one, or two, attributes of current instances (e.g., of the current service retailer, which is an instance of Service Retailer object) of the rule that executes the criterion. At time it is executed, this criterion asks the following question: Does the comparison it specifies evaluate to True? If the answer to the asked question is Yes, the Yes branch starts then executing. Note: A rule always executes in some context. For example, it executes in the context of a given service retailer, which means that the rule is using the instance of Service Retailer object that is referring to that service retailer. That instance is hereby called the current service retailer of the rule: This is the Service Retailer object instance that is being processed by the rule. The context of a rule is thus the set of the current instances the rule is using. For example, if the rule is working on a specific Account, as is the case with Usage Rating Rules, the rules context has also a current Account and a current Account Profile. By means of the Generic criterion, you can set up comparisons that involve attributes of some current instances that the context holds. Here is an example of what you can do with such a comparison: In a Usage Rating Rule, you can compare the current Accounts admistat (which is about the Accounts administrative status) attribute against some value, in order to have the rule make a decision that is based on the Accounts administrative status. Note: In the comparisons, you can use any object attribute, whether it is an ARENA attribute or an original attribute of the data model, provided the attribute has been described in ARENA object. Note: To know which instances you can use in the comparisons, it is recommended you proceed as here below. Firstly, have a look to the left pane of the criterion configuration panel. That left pane is organized as a Windows Explorer-like tree, in which the second level of indentation corresponds to instance names. (Which means that the third level of indentation corresponds to attributes.) In that left pane, instances are referred to by means of object names: As only the current instance of each of these objects is used, referring to the object name is the same as referring to the current instance of that object. In your comparisons, you can use no other instances than those that the left pane mentions. However, it is not because an instance is in the left pane that you can use it in a comparison. Indeed, to be able to use an instance in comparison, that instance must be part of the rules context, and that latter context content depends on the type of the rule. Thus, secondly, check whether the instance that the left pane mentions and that you want to use in your comparison belongs to the context of the rule for which you build up the Generic criterion. To know which left pane instances are part of the context of which kind of rules, see Table 139, Availability of Generic Criterion Objects per Kind of Rule, on page 433. If the table indicates that the instance does not belong to the context of the kind of rule for which you are making up the comparison, then you cannot use that instance in the comparison.
11 September 2009
Page 429 of 968
Decision Trees
Object names (and thus, in this context, current instance names).
The first operand of the comparison.
The second operand of the comparison.
Figure 212 - Generic Criterion Configuration Panel
Page 430 of 968
11 September 2009
The Generic Criterion Explorer, where you can select Objects attributes.
The Comparison pane, where you specify the Generic Criterion comparison.
TO ENLARGE OR SQUEEZE THE EXPLORER , MOVE THE MOUSE CURSOR OVER RED CIRCLED DOTS, PRESS THE LEFT BUTTON OF THE MOUSE AND DRAG.
Table 138 - Generic Criterion Parameter Criterion description Description This field displays a text that summarizes the comparison. This text is displayed to the right of the Generic Criterion icon. You do not update it. The summary is built using the value of the other parameters of the current Generic Criterion. If the second operand of the comparison is a fixed value, the summary is build by the GUI as follows: [First-object-name] Logical-name-of-the-attribute Operator Constant Example [Service Retailer] servret < 3 If the second operand of the comparison is an object attribute, the summary is build by the GUI as follows: [First-object-name] Logical-name-of-the-attribute Operator [Second-object-name] Logical-name-of-the-attribute Attribute Name
Together with Attribute Object Name parameter, this parameter specifies the first operand of the comparison, which is an object attribute. Attribute Object Name specifies the object, this parameter specifies the attribute of the object. Enter thus here the DB name of an attribute of the object that Attribute Object Name parameter specifies. That attribute must be one that the Generic Criterion Explorer shows (which means that attribute must have been described to the Arena object).Attribute
To be sure you enter the correct DB name, first select Attribute Name entry field, so that it receives the focus in the Generic Criterion window, and then select the attribute in the Generic Criterion Explorer.
11 September 2009
Page 431 of 968
Decision Trees
Table 138 - Generic Criterion Parameter Attribute Object Name Description Together with Attribute Name, this parameter specifies the first operand of the comparison, which is an object attribute. Attribute Name specifies the attribute, this parameter specifies the object to which the attribute belongs. Enter here the name of one of the objects that the Generic Criterion Explorer shows, or that the entry field drop-down menu shows. Make sure that you choose an object that Table 139, Availability of Generic Criterion Objects per Kind of Rule, on page 433, allows.
You can fill in Attribute Name and Attribute Object Name in one click. For that, first select Attribute Name entry field, so that it receives the focus in the Generic Criterion window, and then select the attribute in the Generic Criterion Explorer. Configuration object refers to the unique instance of the RE configuration object. You cannot use the unique instance of CE configuration object with this criterion.
Criterion Operator
Specifies the operator (i.e., >, <, <>, =, ~) that will be used to compare the two operands of the comparison.
To specify the operator, select the black solid triangle to the right of Operator entry field. In the drop-down menu that then appears, select then the operator you want the comparison to use.
~ is the contains operator. It applies only to character string operands. Use it whenever you want to check whether Attribute Name contains or not the second value.
Second Value
Whenever the second operand of the comparison has to be an object attribute, this parameter, together with Second Object Name parameter, specifies the second operand of the comparison. Second Object Name specifies the second operands object, this parameter specifies the attribute of that second operand. Enter thus here the DB name of an attribute of the object that Second Object Name parameter specifies. That attribute must be one that the Generic Criterion Explorer shows (which means that attribute must have been described to the Arena object).

To be sure you enter the correct DB name, first select Second Value entry field, so that it receives the focus in the Generic Criterion window, and then select the attribute in the Generic Criterion Explorer. Entering a value in this parameters entry field automatically clears Constant parameters entry field. Which means that, at any time, the comparison unambiguously knows whether the second operand is an object attribute or a fixed value.
Page 432 of 968
11 September 2009
Table 138 - Generic Criterion Parameter Second Object Name Description Whenever the second operand of the comparison has to be an object attribute, this parameter, together with Second Value parameter, specifies the second operand of the comparison. Second Value specifies the second operands attribute, this parameter specifies the object of that second operand. Enter here the name of one of the objects that the Generic Criterion Explorer shows, or that the entry field drop-down menu shows. Make sure that you choose for the second operand an object that Table 139, Availability of Generic Criterion Objects per Kind of Rule, on page 433, allows.
You can fill in Second Value and Second Object Name in one click. For that, first select Second Value entry field, so that it receives the focus in the Generic Criterion window, and then select the attribute in the Generic Criterion Explorer. Configuration object refers to the unique instance of the RE configuration object. You cannot use the unique instance of CE configuration object with this criterion.
Constant
Whenever the second operand of the comparison has to be a fixed value, this parameter alone specifies the second operand of the comparison. This must be a character string.
Entering a value in this parameters entry field automatically clears Second Value parameters entry field. Which means that, at any time, the comparison unambiguously knows whether the second operand is an object attribute or a fixed value.
Information
The description and comments given in the information field are shown only when the Generic criterion is opened through URR.
12.3.14.3.Availability of the Objects the Generic Criterion Explorer Shows

As a note above has said, a rule always executes in some context. If all rules have a current Service Retailer (that is, an instance of Service Retailer object that refers to the service retailer being processed), not all kinds of rules have a current Account, or a current Customer. The following table indicates, in function of the kind of the rule that will execute the Generic Criterion, what Object instances can be part of the rules context. Table 139 - Availability of Generic Criterion Objects per Kind of Rule Name of Objectabc RE Configuration CE Configuration Service Retailer x cd x Service Rule x x x Charging Rule Rating Plan Rule x x x x x x Usage Rating Rule x Top-Up Rule
11 September 2009
Page 433 of 968
Decision Trees
Table 139 - Availability of Generic Criterion Objects per Kind of Rule Name of Objectabc Account Profile Account Client Service Offer Definition Network Events x x x ce cf cg x x ch x ci x Service Rule Charging Rule Rating Plan Rule x x Usage Rating Rule x x Top-Up Rule
a. An x in a cell means that the corresponding object instance can always be used in the corresponding rule. b. No x in a cell means that the corresponding object instance can never be used in the corresponding rule. c. A c in a cell means that the corresponding object instance can be used in the corresponding rule on the condition that some condition is true. The condition is indicated by means of a footnote next to the c. d. Only when the calling user is a Customer. e. Only when the calling user is an Account. f. Only when the calling user is an Account. g. Only when the calling user is a Customer. h. Only when the Usage Rating Rule is run by a Service Offer Definition. i. Only when the Top-Up Rule is run by a Service Offer Definition.
Table 140 - Generic Criterion Availability Service Rule Available Usage Rating Rule Available Charging Rule Available Rating Plan Rule Available Top-Up Rule Available
In order for a rule to be able to use this criterion, the rules context must have one or more of the following object instances: Current RE Configuration Current CE Configuration Current Service Retailer Current Account Profile Current Account Current Customer Current Service Offer Definition Current Network Event
Page 434 of 968
11 September 2009
12.3.15. Grant Criterion

This criterion asks the following question: Do the terms of the grant, that the criterion refers to, exist for the Account Profile of the rules current Account? If the answer is yes, the CRE checks whether the terms of the grant require some credit to be offered to the current Account. If some credit has to be offered to the current Account, the CRE first grants that credit to the Account and then starts executing the Yes branch of the criterion. On the other hand, if no credit has to be offered to the current Account, the CRE immediately starts executing the Yes branch of the Account. Of course, if the answer to the question that the criterion asks is no, there are no terms of the grant to check and there is thus no credit to grant to the current Account. Simply, whenever the answer to the question that the criterion asks is no, its the other branch of the criterion that starts immediately executing. 1) Five grant criterias can be given in topup rule object.If more than five grant crietrias are given,only first five criterias will be executed. 2)By default,the first grant will be calculated based on first grant's Terms of the Grant,subsequent grants will be calculated on previous grant. 3)More flexibility can be given by defining an arena variable "BONUS_MOD".If this variable is defined then grant will be given as follows: 0 - grant on previous value only and first time to main topup (nominal value) 1 - every time grant on main topup value (nominal value) only 2 - grant on cumulative values of grants and main topup, till the present grant. The definition of arena variable is as follows: 1)Attributes Logical Name: BONUS_MOD 2)Attributes Object Name : Account Profile 3)DB Name : BONUS_MOD 4)Attribute Type : Integer 5)Default Attribute Value = 0 Note: A Terms of the Grant always corresponds to an instance of the Grant Tool object, since the purpose of that object is to let you specify the terms by which Accounts, of specific Account Profiles, will be rewarded with some credit.
To know exactly how it is decided whether the current Account has to rewarded or not and to know exactly how the credit that is then granted, as a reward, to the Account is computed, see section 17.2, Grant Tool Object, on page 590.
11 September 2009
Page 435 of 968
Decision Trees
Figure 213 - Grant Criterion Configuration Panel
Table 141 - Grant Criterion Parameter Terms of the Grant* Description This parameter indicates which Terms of the Grant the criterion must apply whenever it is executed. This thus refers to an instance of the Grant Tool object, since such an instances purpose is to specify the terms of some grant. The value you enter here must be the value of Name parameter of an instance of the Grant Tool object.
Clicking on the button to the right of this parameter will display a window showing the list of all the Name parameter values (and thus of all the available Terms of the Grant) that the Grant Tool object instances use. Select in that list the Terms of the Grant you want this criterion to apply. Note that, even when two or more instances of Grant Tool object have the same Name value, that Name value appears only once in the list the window shows.
Make sure that the chosen Terms of the Grant applies to the various Account Profiles that the rule, that executes this criterion, will process.
That is, make sure that each Account Profile the rule will process is referred to by one instance of Grant Tool object whose Name parameter is the same as this parameter value.
If the Terms of the Grant chosen for some Grant criterion do not apply to the Account Profile of some Accounts that the criterions rule will process, these Accounts will never be granted some credit in consequence of the execution of that Grant criterion.
Keep in mind that the Grant Tool object allows more than one of its instances to have the same Name parameter value, provided these instances refer to different Account Profiles.
Page 436 of 968
11 September 2009
Table 142 - Grant Criterion Availability Service Rule n.a. Usage Rating Rule n.a. Charging Rule n.a. Rating Plan Rule n.a. Top-Up Rule Available
In order for a rule to use this criterion, the rule must have a: Current network event that is a Top-Up request Current Account Profile Current Account
11 September 2009
Page 437 of 968
Decision Trees
12.3.16. LiteSCE Criterion

This criterion asks the following question: Does the LiteSCE script, that the criterion specifies, successfully execute? If the answer is yes, then the Yes branch of the criterion starts executing? Note: Thus, at time the decision tree executes a LiteSCE criterion, the LiteSCE script that the criterion specifies starts executing. As soon as the LiteSCE script has completed its work, the criterion checks whether the LiteSCE script successfully completed or not, and then decides which branch of the criterion it will go.
Figure 214 - LiteSCE Criterion Configuration Panel
Table 143 - LiteSCE Criterion Parameter Criterion Description Text* Description This must be a character string. This parameter text is displayed to the right of the LiteSCE Criterion icon. Try thus to choose text that enhances the decision trees readability and that concisely and unambiguously reflects what the criterion does.
Page 438 of 968
11 September 2009
Table 143 - LiteSCE Criterion Parameter Script* Description Reference to the LiteSCE script that gets executed at time the criterion is started. This corresponds to Name parameter of one instance of LiteSCE Script object. Be sure that Script Owner parameter is set to Customer Name parameter of that instance.
For information about LiteSCE Script object, see the documentation of PFMLITESCE OSP service.
Parameter1
Value of the first argument of the LiteSCE script, if the LiteSCE script needs one to be passed. This must be a character string. The value for this parameter is mandatory in case one wants to use parameters attributes. If this is left empty other arguments will not be considered.
Parameter2
Value of the second argument of the LiteSCE script, if the LiteSCE script needs one to be passed. This must be a character string. You can leave this parameter empty if one or more set of consequent arguments have been specified.
Parameter3
Value of the third argument of the LiteSCE script, if the LiteSCE script needs one to be passed. This must be a character string. You can leave this parameter empty if one or more set of consequent arguments have been specified.
Parameter4
Value of the fourth argument of the LiteSCE script, if the LiteSCE script needs one to be passed. This must be a character string. You can leave this parameter empty if one or more set of consequent arguments have been specified.
Parameter5
Value of the fifth argument of the LiteSCE script, if the LiteSCE script needs one to be passed. This must be a character string. You can leave this parameter empty if one or more set of consequent arguments have been specified.
Parameter6
Value of the sixth argument of the LiteSCE script, if the LiteSCE script needs one to be passed. This must be a character string.
11 September 2009
Page 439 of 968
Decision Trees
Table 144 - LiteSCE Criterion Availability Service Rule Available** Usage Rating Rule Available Charging Rule Available* Rating Plan Rule Available* Top-Up Rule Available
Note*: To configure liteSCE criteria in Charging Rule and Rating Plan Rule, please see below: 1. To configure action "ce20-A1" for ce20 in any tree mentioned above like charging rule, using litesce criteria create an action "ce20-A1" with the same name and absolute path in the creactor service. This action could remain as "dummy" i.e. with no logic inside since it might never be used at creactor run-time. In Litesce criteria, select the action "ce20-A1" in the dropdown list and create the routing tree. Create the same action on ce20 as on creactor and deploy on all the ce20 SLEEs. Now at run time this action is available in CE20 SLEEs.
2. 3.
Note**: Service rule is available both in creactor and ce20. In creactor, if Litesce is configured through Litesce criteria then no modification required, for ce20 follow the above steps.
In order for a rule to be able to use this criterion, the rule must provide the context that the LiteSCE script of the criterion is needing.
Page 440 of 968
11 September 2009
12.3.17. Main Balance Criterion

The Main Balance Criterion answers the following question: is there enough credit on the Main Balance to charge on it as many units as rated by the finite scope Tariff? If the answer is no, the event is rejected and an error code is returned. If the answer is yes, the units up to the Tariffs limit are charged on the main balance, and the rest can be charged on Bundles. The purpose of the Main Balance Criterion is to ensure that you charge on Bundle(s) only if you have previously charged a specific amount on the main balance. So charging on Bundle(s) only is impossible.
This Main Balance Criterion requires to have the event charged on the main balance first, for a maximum amount of 2 EUR. If the first 2 EUR of the events cost can be charged on the main balance, this branch, which is the Yes branch of the criterion, starts executing. Else, the event is rejected and a result code is sent back to the RTx.
How to build a decision tree branch after a Main Balance Criterion?

After a Main Balance Criterion, In the YES branch: you can only use a Tariff leaf. In the first to last-but-one ELSE branches: you can only use a Bundle Criterion. In the last ELSE branch: you can only use a Tariff leaf or a Forbidden leaf.
Conditions for a relevant configuration

The table below explains some logical conditions for your Main Balance Criterion configuration to make sense and serve the right purpose. Table 145 - Configuring your Main Balance Criterion Item Tariff of the YES branch Characteristic must be a finite scope Tariff Why? Otherwise youll never go to the ELSE branch. Either you will charge the whole slice on the main balance, or there wont be enough credit and an error will be returned to the RTx. This is the exact same result as directly charging on the main balance, without any criterion before the Tariff leaf.
See Finite Tariff: Limit Charge on a Balance or Bundle, on

page 532.
11 September 2009
Page 441 of 968
Decision Trees
Table 145 - Configuring your Main Balance Criterion Item ELSE branch Characteristic should include at least one Bundle Criterion Otherwise, if a Tariff is used, it means that you charge on the main balance again. The only potential interest of this is to implement a 10-segments Tariff. However then you must be sure that the main balance has enough credit to pay the first 5 segments; otherwise the call will be rejected. if a Forbidden leaf is used, it means that as many units as rated by the finite scope Tariff, will be allowed and charged on the Main Balance; and then the call will be rejected. These scenario serves no relevant purpose because this may be achieved by simply applying a finite tariff without even Main Balance criteria. Why?
Example Step 1
...expands as...
Step 2
Step 3
Step 4
For a voice call rated in minutes: Step 1: The first 5 minutes are charged on the main balance. If the main balance has not enough credit for paying the cost of the first 5 minutes, then the call is rejected and an error message is sent to the RTx. Step 2: When the first 5 minutes have been charged on the main balance, the minutes from the 6th minute are charged on the Time Bundle. Step 3: When the Time Bundle is empty or when the scope of the related Tariff is reached, the next minutes are charged on the Money Bundle. Step 4: When the Money Bundle is empty or when the scope of the related Tariff is reached, the next minutes are charged on the main balance.
Page 442 of 968
11 September 2009
Figure 215 - Main Balance Criterion Configuration Panel
Table 146 - Main Balance Criterion Parameter Criterion Description Test Description Optional description of the Criterions condition. Typically, you will indicate the maximum to be charged on the Main Balance (i.e. the scope of the Tariff).
12.3.17.3.What happens in case of Tariff Switch?

If a Tariff Switch occurs while the YES branch of the Main Balance Criterion is executed, then the Usage Rating Rule is translated again, for rating the units consumed in the next time band.
For more details about Tariff Switch, see 12.3.1.5, Switching of Tariff, of Customer Account, of Service Offer, of Service, on page 382.
In the case a Usage Rating Rule is translated again because of a Tariff Switch, there are basically two different cases regarding the Main Balance Criterion: another Main Balance Criterion can be met the Main Balance Criterion met during the first Usage Rating Rule translation is met again
11 September 2009
Page 443 of 968
Decision Trees
First Main Balance Criterion met. This ELSE branch will only be taken when 5 minutes have been charged on the Main Balance in total (whatever the number of Tariff Switches).
Second Main Balance Criterion met (after Tariff Switch then). This YES branch will never be taken.
Rules
1. The first Main Balance Criterion encountered in the processing of an event wont execute its ELSE branch until all the units required to be charged on the main balance in the YES branch are actually rated and charged. So for the first Main Balance Criterion met in the execution of a Usage Rating Rule, the ELSE branch will only be taken when all the units to be charged on the main balance have been charged. This is the strict application of the feature. 2. The other Main Balance Criteria potentially met in the Usage Rating Rule during the processing of an event will never execute their YES branch. The ELSE branch will always be taken, whatever units have been actually charged on the main balance beforehand. This is a limitation to the feature.
Table 147 - Main Balance Criterion Availability Service Rule n.a. Usage Rating Rule Available Charging Rule n.a. Rating Plan Rule n.a. Top-up Rule n.a.
In order for a rule to be able to use the Main Balance Criterion, the rule must have a current Account.
Page 444 of 968
11 September 2009
12.3.18. Origin Criterion

This criterion asks the following question: Does the event, that the network event being processed is about, originate from the Area, or part of it, that the criterion specifies? If yes, the Yes branch of the criterion starts executing.
This origin criterion checks whether the event, that the network event being processed is about, originates from Shanghai area or not. If it originates from that area, this branch, which is the Yes branch of the criterion, starts executing. Else, it does not start executing.
Figure 216 - Origin Criterion Configuration Panel There are three ways to specify the criterions condition, depending on which radio button is checked. The figures below illustrate each of these ways.
Figure 217 - Origin Criterion - when Area is checked
11 September 2009
Page 445 of 968
Decision Trees
Figure 218 - Origin Criterion - when Area Identifier without Type is checked
Figure 219 - Origin Criterion - when Area Identifier with Type is checked
Table 148 - Origin Criterion Parameter Area If you check the Area button Then the criterion checks whether the event originates or not from a given Area, thus from any part of it.
An Area field is displayed at the bottom of the window.
Description
Area Identifier without Type
If you check the Area Identifier without Type button Then the criterion checks whether the event originates or not from a given part of a given area, thus not from any part of the area. Concretely, the criterion performs a check on the calling partys identifier (parameter origmc, provided in the RTx request). The criterions condition is met only if the origmc parameter is identical to the Area Identifier specified in the criterion. No check is performed on the Area Identifier Type: the parameter origtype from the RTx request is simply ignored.
An Area Identifier field is displayed at the bottom of the window.
Page 446 of 968
11 September 2009
Table 148 - Origin Criterion Parameter Area Identifier with Type Description If you check the Area Identifier with Type button Then the criterion checks whether the event originates or not from a given part of a given area, thus not from any part of the area. Concretely, the criterion performs two checks: 1. on the calling partys identifier (parameter origmc, provided in the RTx request). The criterions condition is met only if the origmc parameter is identical to the Area Identifier specified in the criterion); 2. on the calling partys identifier type (parameter origtype, provided in the RTx request). The criterions condition is met only if the origtype parameter is identical to the Area Identifier Type specified in the criterion).
An Area Identifier field and an Area Identifier Type field are displayed at the bottom of the window.
Area
Only available when Area button is checked.
Reference to the name of the Area (i.e., Simple Area) to be checked by the current criterion.
To know what a Simple Area is, see section 16.1.1, Purpose: Making Decisions
based on Zoning features, on page 543.
Clicking on the HELP button to the right of this parameter does not only list Simple Areas but additionally lists Super Areas. Since this parameter is only allowed to refer to Simple Areas, be sure you never select a Super Area in the list. Clicking on the HELP button to the right of this parameter does not only list Simple Areas and Super Areas of the current Service Retailer but also those of the default Service Retailer.
The Originating Area found on the basis of the RTx request parameters (origmc, origtype and origalgo) must exactly match the Area specified in the criterion.
See parameter Area Name*, page 556.

Example When Area button is checked, setting this parameter to Shanghai gives what follows:
11 September 2009
Page 447 of 968
Decision Trees
Table 148 - Origin Criterion Parameter Area Identifier Description
Only available when Area Identifier without/with Type button is checked
Reference to the Identifier attribute of the Area Identifier to be checked by the current criterion. The originating party provided by the RTx (parameter origmc) must match exactly the Area Identifier specified in the criterion.
Clicking on the HELP button to the right of this parameter does not only list Area Identifiers of the current Service Retailer but also Area Identifiers of the default Service Retailer.
See parameter Identifier*, page 558.

Example When Area Identifier Without Type button is checked, setting this parameter to 071 gives what follows:
Reference to the Identifier Type attribute of the Area Identifier chosen to fill in the criterion. The originating party provided by the RTx (parameter origmc) must match exactly the Area Identifier specified in the criterion. The originating partys type provided by the RTx (parameter origtype) must match exactly the Identifier Type specified in the criterion.
Clicking on the HELP button to the right of this parameter does not only list Area Identifier Types of the current Service Retailer but also Area Identifier Types of the default Service Retailer.
When origtype = 0 When origtype = 0, then the Origin Criterion (Area Identifier with Identifier Type) is never met. Indeed, no Area Identifier instance can be created with a Type zero. So the comparison of origtype with the Identifier Type of the Area Identifier will never be successful.
See parameter Identifier Type*, page 558.
Page 448 of 968
11 September 2009
Identifier Type
Only available when Area Identifier with Type button is checked
Table 149 - Origin Criterion Availability Service Rule Available Usage Rating Rule Available Charging Rule Available Rating Plan Rule Available Top-Up Rule n.a.
11 September 2009
Page 449 of 968
Decision Trees
12.3.19. Originating Zone Criterion

This criterion asks the following question: Does the origin, of the event that the network event being processed is about, belong to the Zone (i.e., Super Area) that the criterion specifies? If the answer is yes, the Yes branch of the criterion starts executing. Note: To learn more about Zones and Super Areas, see chapter 16.1.1, Purpose: Making Decisions based on Zoning features, on page 543.
Figure 220 - Originating Zone Criterion Configuration Panel

Table 150 - Originating Zone Criterion - zorigcri Parameter Zone (Super Area)*
zoneref
Description This must be the name of a Zone (i.e., Super Area) of either the current Service Retailer or of its default Service Retailer. Naturally, if a Zone (i.e., Super Area) of the current Service Retailer overrides (i.e., has the same name as) a Zone (i.e., a super Area) of the default Service Retailer, the criterion uses the current Service Retailers Zone (i.e., Super Area).
Clicking on the HELP button to the right of the parameter lists the Zones (i.e., Super Areas) of the current Service Retailer and of the default Service Retailer. Naturally, if a Zone (i.e., a Super Area) of the current Service retailer has the same name as a Zone (i.e., Super Area) of the default Service Retailer, the list shows the name only once.
Page 450 of 968
11 September 2009
Table 151 - Originating Zone Criterion Availability Service Rule n.a. Usage Rating Rule Available Charging Rule n.a. Rating Plan Rule n.a. Top-Up Rule n.a.
11 September 2009
Page 451 of 968
Decision Trees
12.3.20. Preferred Number Criterion

This criterion asks the following question: Does the called party belong to the list of Preferred Identifiers of the Account Profile used by the current Account? If the answer is yes, then: If the Usage Rating Rule, that is executing the criterion, will return a main balance tariff1, the percentage-based discount that the criterion specifies shall be applied to that tariff, and The Yes branch of the criterion starts executing.
The Preferred Number criterion checks whether the called party is one of the Preferred Identifiers of the Account Profile of the Account that is being charged. If it is one, the CRE takes note that, at time it will rate each RUM of the network event, it has to apply a 21 percent discount on each RUM of the network event. Then, it executes the Yes branch of the criterion.
Figure 221 - Preferred Number Criterion Configuration Panel
1. The discount is only applied to the main balance tariff of the current Account. Thus, it does not apply to any bundles tariff that the Usage Rating Rule would have returned to the CRE.
Page 452 of 968
11 September 2009
Table 152 - Preferred Number Criterion Parameter Discount on Event Cost (%) Enter here a percentage. This discount applies on each RUM of the network event. Thus, the cost of each RUM, as computed by the main balance tariff that is going to be applied to the network event being processed, will be lowered by the percentage this parameter specifies. This must be an integer value. Example Setting this parameter to 21 (which means a 21 percent discount on each RUM of the network event) results in the following: Description

A discount that is to be applied on a network event RUM in consequence of a Preferred Number criterion works exactly the same way as a discount to be applied on a network event RUM that is the consequence of a Discount criterion. It also works exactly the same way as a discount to be applied on a network event RUM that is the consequence of a Promotion criterion. As a result, the RUM discounts due to a Preferred Number criterion cumulate in the same way the RUM discounts due to a Discount criterion do and in the same way the RUM discounts due to a Promotion criterion do. Moreover, RUM discounts due to a Preferred Number criterion do not only cumulate with each other: They also cumulate with the RUM discounts due to a discount criterion and with those due to a Promotion criterion. And vice-versa. All these RUM discounts cumulate as explained at section 12.3.11.3, How Discounts Cumulate, on page 422, explains.
Table 153 - Preferred Number Criterion Availability Service Rule n.a. Usage Rating Rule Available Charging Rule n.a. Rating Plan Rule n.a. Top-Up Rule n.a.
11 September 2009
Page 453 of 968
Decision Trees
12.3.21. Promotion Criterion

For each RUM (of the current network event) to which it associates a promotion, the Promotion criterion applies the discount1 that the promotion, that the criterion associates with the RUM, grants to the current Account. Note: A promotion is an instance of Promotion Tool object. You always use the Promotion criterion in conjunction with one or more promotions (up to three in fact, one per RUM) that the criterion is about. Moreover, each of the promotions the criterion uses must be set up to grant a discount. Note: A promotion can be set up either to grant a credit or a discount. It is meaningless to make the promotion criterion use a promotion that is set up to grant a credit. For each promotion that a Promotion criterion refers too, there must be in some Usage Rating Rule a Supervision criterion that also refers to the promotion. Failing to ensure of that for a promotion that the Promotion uses makes it impossible for the promotion to grant any discount.

To have an in-depth explanation of how a promotion, a Promotion criterion and a Supervision criterion work, see section 17.5, Promotion Tool Object, on page 651. Section 17.5, Promotion Tool Object, on page 651, also covers in details how a promotion, the Promotion criterion and the Supervision criterion work with each other.
Since the promotion criterion always enter its Yes branch once its execution completes, the answer to the question that the promotion criterion asks is always Yes. Thus, the No branch of a Promotion criterion is never used.
12.3.21.2.When Should You Use the Promotion Criterion

You use the Promotion criterion whenever you need to grant a level of discount that depends on RUM quantities that the current Account consumed over a past period of time. Note: These RUM quantities consumptions are collected through the use, by some Usage Rating Rules, of Supervision criteria that refer to the promotions that the Promotion criterion uses. If some promotion that the Promotion criterion uses is used by no Supervision criterion, no consumed RUM quantities are computed on behalf of the promotion and thus the promotion is never able to grant a discount. Compare this behavior of the Promotion criterion with the Discount an the Preferred Number criteria, which can also be used to apply a discount to each RUM of the current network event. These criteria specify a fixed discount value for their RUMs, while the Promotion criterion makes it possible to adapt the level of the discount to RUM quantities that the current Account consumed over a past period of time.
1. The discount is only applied to the main balance tariff of the current Account. Thus, it does not apply to any bundles tariff that the Usage Rating Rule would have returned to the CRE. As a result, if the Usage Rating Rule executing a Promotion criterion returns no main balance tariff, no discount is applied, even in the case the Promotion criterion returned a discount on one or more of its RUMs.
Page 454 of 968
11 September 2009
Figure 222 - Promotion Criterion Configuration Panel Table 154 - Promotion Criterion Parameter Criterion Description Text
Description Enter here free text that gives important information about the current Promotion criterion. Indicates the name of the promotion that the current criterion uses to know which discount it has to apply to the first RUM of the current network event. Indicates the name of the promotion that the current criterion uses to know which discount it has to apply to the second RUM of the current network event. Indicates the name of the promotion that the current criterion uses to know which discount it has to apply to the third RUM of the current network event.
Promotion for RUM1 Promotion for RUM2
Promotion for RUM3
On how the promotion criterion retrieves a promotion, see How a Usage Rating Rule Retrieves a Promotion, on page 682.

A discount that is to be applied on a network event RUM in consequence of a Promotion criterion works exactly the same way as a discount to be applied on a network event RUM that is the consequence of a Discount criterion. It also works exactly the same way as a discount to be applied on a network event RUM that is the consequence of a Preferred Number criterion. As a result, the RUM discounts due to a Promotion criterion cumulate in the same way the RUM discounts due to a Discount criterion do and in the same way the RUM discounts due to a Preferred Number criterion do. Moreover, RUM discounts due to a Promotion criterion do not only cumulate with each other: They also cumulate with the RUM discounts due to a discount criterion and with those due to a Preferred Number criterion. And vice-versa. All these RUM discounts cumulate as explained at section 12.3.11.3, How Discounts Cumulate, on page 422, explains.
11 September 2009
Page 455 of 968
Decision Trees
Table 155 - Promotion Criterion Availability Service Rule n.a. Usage Rating Rule Available Charging Rule n.a. Rating Plan Rule n.a. Top-Up Rule n.a.
In order for a rule to be able to use this criterion, the rule must have a: Current Commercial Offer Current Service Retailer Current Account Profile Current Account
Page 456 of 968
11 September 2009
12.3.22. Service Criterion

This criterion asks the following question: Is the service that is being processed the same as the one that the criterion specifies? If the answer is yes, the Yes branch of the criterion then starts executing.
Figure 223 - Service Criterion Configuration Panel
Table 156 - Service Criterion Parameter Service* Description This must contain the value of the Service Name parameter of one instance of Service object.
See also section 9.2, Service Object, on page 260.
12.3.22.3.What Is the Service that is Being Processed?

In a Service Rule, the service that is being processed (i.e. the current service) is the one that Network Event Type object associates to the type of the network event that is being processed. To remember, the role of a Service rule is to translate its current service to another service, which is hereby called the computed service. Thus, the current service of the other rules depends on whether a Service rule has been run on the network event they are treating. If a Service rule has been run on the network event, their current Service is the service that the Service rule computed. Otherwise, their current Service is the one that Network Event Type object associates to the type of the network event they are treating.
11 September 2009
Page 457 of 968
Decision Trees
Table 157 - Service Criterion Availability Service Rule Available Usage Rating Rule Available Charging Rule Available Rating Plan Rule Available Top-Up Rule Available
Page 458 of 968
11 September 2009
12.3.23. Subscription Criterion

This criterion asks the following question: Is the Add-on Service Offer Group that the criterion specifies active, with respect to the current user, in the current package of the current commercial offer? If the answer is yes, the Yes branch of the criterion is executed. If the Service Offer Group does not belong to the current package, the answer to the question that the criterion asks is No.
On active Service Offer Groups, see also section 9.8.1.2, Active Service Offer Groups of a Commercial Offer, on page 276.
Figure 224 - Subscription Criterion
Table 158 - Subscription Criterion Parameter Add-On Service Offer Group* Description Reference to the Service Offer Group that the Subscription to is checked by the criterion. This Service Offer Group must be an Add-on Service Offer Group.
See 9.6.1.1, Add-On Service Offer Group, on page 270.

The criterion will check whether that referred to Service Offer Group is active or not in the current Commercial Offer. It is not required that the Service Offer Group be optional in the current Commercial Offer: an Add-on Service Offer Group may be default in the current Commercial Offer.
12.3.23.3.Whats the Current User? Whats the Current Commercial Offer?

A rule always executes in the context of some Commercial Offer and of some user. That Commercial Offer is called the current Commercial Offer of the rule. That user is the current user of the rule. When the calling user is an Account, the current commercial offer is the default Commercial Offer attached to the Account. And the current user is the Account. When the calling user is a Customer, and that Customer belongs to no community, the current commercial offer is the default Commercial Offer attached to the Customer. And the current user is the Customer.
11 September 2009
Page 459 of 968
Decision Trees
But, when the calling user is a Customer, and that Customer belongs to one or more communities, things are different. Firstly, in that case, the calling user can have several commercial offers: He/she will have one commercial offer per community to which it belongs and, it is then optional to attach him/her a default Commercial Offer (a user must have a default Commercial Offer only if it can happen it will have to pay for him/herself). Secondly, because the calling user belongs to communities, it may turn out that some people in one of these communities will pay for him/her. And the users who belong to these communities may also have several Commercial offers: One per community to which they belong and perhaps a default one (since, when a user belongs to a community, having a default Commercial Offer is optional). As a result, whenever a rule executes in consequence of a network event whose calling user belongs to one or more communities, it can be that the rule does note execute in the context of the calling user and its default Commercial Offer but in the context of a user (let us call this user a possible payer) that is belonging to some community to which the calling user belongs too. In that case, the current Commercial Offer of the rule is then the Commercial Offer that the possible payer has in the Community. In that case too, the current user of the rule is not the calling user, but the possible payer. Thus, whenever a rule executes and the calling user of the network event being processed belongs to a community: Its current user can be different of the calling user, in which case the current user is a possible payer. Its current commercial offer can be different of the default commercial offer of the calling user, in which case the current Commercial Offer is the Commercial Offer that the possible payer has in some community. While, whenever a rule executes and the calling user of the network event being processed belongs to no community: Its current user is the calling user. Its current Commercial Offer is the default Commercial Offer of the calling user. Be sure you know how the CRE decides which Commercial Offer and which user are the current ones of a rule at time the rule executes.
12.3.23.4.Whats the Current Package?

Whenever the CRE starts dealing with a Commercial Offer of an user, whether that user is the calling user or of a possible payer of the network event being processed, the CRE locates the Commercial Offers Service Offer Group that provides the current service. That Service Offer Group belongs to some package. That package is the current package of the rule. On the current service, see section 12.3.22.3, What Is the Service that is Being Processed?, on page 457.
Page 460 of 968
11 September 2009
Table 159 - Subscription Criterion Availability Service Rule n.a. Usage Rating Rule Available Charging Rule Available Rating Plan Rule Available Top-Up Rule Available
In order for a rule to be able to use this criterion, the rule must have a: Current User (i.e. Either a Current Customer or a Current Account) Current Commercial Offer Current Package
11 September 2009
Page 461 of 968
Decision Trees
12.3.24. Supervision Criterion

For each RUM to which it associates a promotion, the Supervision criterion adds the consumed RUM quantities of that RUM, that the current network event carries, to the current Accounts Counter that the promotion specifies. Note: A promotion is an instance of Promotion Tool object. You always use the Supervision criterion in conjunction with one or more promotions (up to three in fact, one per RUM) that the criterion is about.

To have an in-depth explanation of how a promotion and a Supervision criterion work, see section 17.5, Promotion Tool Object, on page 651. Section 17.5, Promotion Tool Object, on page 651, also covers in details how a promotion, the Promotion criterion and the Supervision criterion work with each other.
Since the Supervision criterion always enters its Yes branch once its execution completes, the answer to the question that the promotion criterion asks is always Yes. Thus, the No branch of a Supervision criterion is never used. Note: As stated above, a Supervision criterion only deals with consumed RUM quantities. Thus, whenever a Supervision criterion is executed by a Usage Rating Rule that is treating a network event that carries no consumed RUM quantities at all (its the case when the Usage Rating Rule is executed in the context of the processing of a fstreq RTx request), the Supervision criterion simply does nothing. Naturally, since the answer to the question that a Supervision criterion asks is always Yes, the Usage rating Rule then still leaves the Supervision criterion via its Yes branch.
Page 462 of 968
11 September 2009
Figure 225 - Supervision Criterion Configuration Panel Table 160 - Supervision Criterion Parameter Criterion Description Text
Description Enter here free text that gives important information about the current Supervision criterion. Indicates the name of the promotion that the current criterion uses to know into which Counter of the current Account it has to accumulate the consumed RUM 1 quantities that the current network event carries. Indicates the name of the promotion that the current criterion uses to know into which Counter of the current Account it has to accumulate the consumed RUM 2 quantities that the current network event carries. Indicates the name of the promotion that the current criterion uses to know into which Counter of the current Account it has to accumulate the consumed RUM 3 quantities that the current network event carries.
Promotion for RUM1 Promotion for RUM2 Promotion for RUM3
Note: You cannot chain as many Supervision criteria as you want: if, for a given RUM (e.g., for RUM n), a Usage Rating Rule encounters more than 20 Supervision criteria that associate some promotion with the RUM, the Usage Rating Rule takes into account only the first 20 promotions that are associated with the RUM. Those in excess are not taken into account by the Usage Rating Rune and thus not taken into account by the CRE.
11 September 2009
Page 463 of 968
Decision Trees
Table 161 - Supervision Criterion Availability Service Rule n.a. Usage Rating Rule Available Charging Rule n.a. Rating Plan Rule n.a. Top-Up Rule n.a.
In order for a rule to be able to use this criterion, the rule must have a: Current Commercial Offer Current Service Retailer Current Account Profile Current Account
Page 464 of 968
11 September 2009
12.3.25. Time Criterion

This criterion asks the following question: Does the event time, of the current network event, fall within the period of time that the criterion specifies? If yes, the Yes branch starts executing. Note: Naturally, the event time is from the network event. Thus, if the network event is one that is played offline, the event time that is taken into account is the one stored in the network event. Not the time at which the network event is played offline. If you have to configure tariff switch as Midnight then enter stop time as 24:00:00 in the GUI it will look like 00:00:00. If the stop time is configured as 23:59:59 then for the duration greater than 23:59:59 i.e including the time from 23:59:59 to 24:00:00 we will go in the else branch of this criteria.
This Time criterion checks whether the event time, of the network event being process, falls between 12h45 and 15h30 or not. If it does, the Yes branch of the criterion starts executing.
Figure 226 - Time Criterion Configuration Panel
Table 162 - Time Criterion Parameter Start Time* Description Time at which the period of time of the criterion starts.
11 September 2009
Page 465 of 968
Decision Trees
Table 162 - Time Criterion Parameter Stop Time* Description Time at which the period of time of the criterion stops. Example Setting Start Time parameter to 12:45:00 and Stop Time parameter to 15:30:00, results in the following:
12.3.25.3.Tariff Switches that Are Due to a Time Criterion.

See section 12.3.7.3, Tariff Switches that Are Due to a Counter Threshold Criterion., on page 410. Note: The Time criterion only supports Tariff switching. For more on this, see section 12.3.1.5, Switching of Tariff, of Customer Account, of Service Offer, of Service, on page 382.
Table 163 - Time Criterion Availability Service Rule Available Usage Rating Rule Available Charging Rule Available Rating Plan Rule Available Top-Up Rule Available
Page 466 of 968
11 September 2009
12.3.26. Matrix Component Criterion

This criterion asks the following question: Does the matrix component applicable to the network event that is being processed match the one that the criterion specifies? If yes, the Yes branch of the criterion starts executing.
Section 16.6, Zoning Parameters Identification, on page 579, explains how the CRE finds out the matrix component applicable to the network event being processed.
Figure 227 - Matrix Component criterion
11 September 2009
Page 467 of 968
Decision Trees
Table 164 - Matrix Component Criterion Parameter Matrix Component* Description This must be the value of Matrix Component Name parameter of one instance of Matrix Component object.
Clicking on the HELP button to the right of this parameter does not only list the Matrix Components (i.e., instances of MATRIX COMPONENT object) of the current Service Retailer but also those of the default Service Retailer.
Matrix Component Availability The Matrix Component parameter of the Criterion is meant to take the value of any existing Matrix Component. However, a restriction applies to the Matrix Components available for configuring the Criterion, when it is used in a Service Rule, in a Charging Rule or in a Rating Plan Rule. In these three decision trees, the Matrix Component Criterion can only refer to Matrix Components that are valid for the whole Product Catalog. In other words, Matrix Components defining intersections between Zones (as opposed to simple Areas) cannot be used in the above-mentioned rules. Indeed, Service- and/or Service Offer Group-specific settings dont make sense at these stages of the event processing.
For more details, see Identification of the Product Catalog-dependent zoning

settings, on page 568.
Table 165 - Matrix Component Criterion Availability Service Rule Available Usage Rating Rule Available Charging Rule Available Rating Plan Rule Available Top-Up Rule n.a.
12.4. The Leaves

This section exhaustively lists the available leaves, and documents them.
Page 468 of 968
11 September 2009
12.4.1. Service Leaf

12.4.1.1. Leaf Purpose
A service leaf makes a decision tree return to the CRE a reference to a Service (i.e., a reference to an instance of Service object). This is the way a Service rule indicates to the CRE to which service it has translated the service that Network Event Type object associates to the network event being processed.
12.4.1.2. Leaf Parameter Description
Figure 228 - Service Leaf Configuration Window
Table 166 - Service Leaf Parameter Services Description Reference to an instance to Service object.
Do not use Modify command of this object. Although Modify command of this object gives no error message when it is used and although everything seems to go well whenever it is used, Modify command does not work at all. Therefore, to modify the value of Service parameter of a Service leaf of a Service Rule, you must remove the leaf (by first rightclicking on the leaf and by afterwards selecting Remove branch in the menu that then appears) and afterwards re-create the leaf with the new Service parameter value.
11 September 2009
Page 469 of 968
Decision Trees
12.4.1.3. Leaf Availability

Table 167 - Service Leaf Availability Service Rule Available Usage Rating Rule n.a. Charging Rule n.a. Rating Plan Rule n.a. Top-Up Rule n.a.
Page 470 of 968
11 September 2009
12.4.2. Forbidden Leaf

A Forbidden leaf makes a decision tree indicate to the CRE that its execution is unsuccessful. For example, by returning this leaf to the CRE, a Top-Up rule decision tree indicates to the CRE that the current Top-Up RTx request is not allowed. As another example, by returning this leaf to the CRE, a Charging rule decision tree indicates to the CRE that the current customer of the rule does not agree to pay. Note: For some other rules that are implemented as a decision tree, such as the Usage Rating Rules, it does not make sense that they return a Forbidden leaf to the CRE. For example, a Usage Rating Rule should always return to the CRE information that allows it to cost the currently considered network event quantities.
Figure 229 - Forbidden Leaf Configuration Window
Table 168 - Forbidden Leaf Parameter Forbid Reason Code Description Enter here a character string of your choice. Choose a unique string. For example, in your decision trees, do not have two Forbidden leaves returning the same Forbid Reason Code string. As another example, as Allowed leaves also return a reason code (it is called an Allowed Reason Code), do not have Allowed leaves and Forbidden leaves returning the same reason code string.

Table 169 - Forbidden Leaf Availability Service Rule Available Usage Rating Rule Available Charging Rule Available Rating Plan Rule Available Top-Up Rule Available
11 September 2009
Page 471 of 968
Decision Trees
12.4.3. Allowed Leaf

The allowed leaves works same as it works in top up rule.
Figure 230 - Allowed Leaf Configuration Window
Table 170 - Allowed Leaf

Parameter Allowed Reason Code
Description Enter here a character string of your choice. Choose a unique string. For example, in your decision trees, do not have two Allowed leaves returning the same Allowed Reason Code string. As another example, as Forbidden leaves also return a reason code (it is called an Forbidden Reason Code), do not have Allowed leaves and Forbidden leaves returning the same reason code string.

Table 171 - Allowed Leaf Availability Service Rule Available Usage Rating Rule n.a. Charging Rule n.a. Rating Plan Rule n.a. Top-Up Rule Available
Page 472 of 968
11 September 2009
12.4.4. Customer Account Leaf

By returning such a leaf to the CRE, a Charging rule decision tree indicates to the CRE: That the current customer of the Charging rule agrees to pay as well as Which customer account, of the current customer, has to be charged.
Figure 231 - Customer Account Leaf Configuration Window
Table 172 - Customer Account Leaf Parameter Customer Account Description This parameter must refer to one of the Customer Accounts (i.e., one of the instances of Customer Account object) of the Charging Rules current customer. More precisely, this parameter must be set to Customer Account Name parameter value from a Customer Account instance that refers Charging Rules current customer Settlement List You do not need to set this parameter to some value.

Table 173 - Customer Account Leaf Availability Service Rule n.a. Usage Rating Rule n.a. Charging Rule Available Rating Plan Rule n.a. Top-Up Rule n.a.
11 September 2009
Page 473 of 968
Decision Trees
12.4.5. Tariff Leaf

By returning such a leaf to the CRE, a Usage Rating Rule returns to the CRE the rating information that will allow it to cost the currently considered network event quantities. Beware that the returned information is not necessarily one single tariff. Indeed, if the last executed node of the tree was a Bundle node (i.e., a tree node that is made up of Bundle criteria), the Usage Rating Rule returns the following information for each of the zero or more bundle criteria that were executed: one or more bundles, quantities that each bundle is able to pay, the tariff to apply to the quantities the bundles are able to pay. Moreover, if the Else branch of the tree node was also executed, the Usage Rating Rule also returns: the main balance tariff that the CRE will use to cost the quantities the bundles are not able to pay and that have then to be charged on the main balance of the current Account of the Usage Rating Rule.
For more on this, see also section 12.3.3, Bundle Criterion, on page 387.
Otherwise, if the last executed node of the tree was not a Bundle node, the Usage Rating Rule returns to the CRE the main balance tariff, which is the tariff to apply to the main balance of the Usage Rating Rules current Account.

Figure 232 - Tariff Leaf Configuration Windows
Table 174 - Tariff Leaf Parameter Name of Tariff Description Reference to an instance of Tariff object.
Page 474 of 968
11 September 2009

Table 175 - Tariff Leaf Availability Service Rule n.a. Usage Rating Rule Available Charging Rule n.a. Rating Plan Rule n.a. Top-Up Rule n.a.
11 September 2009
Page 475 of 968
Decision Trees
12.4.6. Service Offer Leaf

By returning such a leaf to the CRE, a Rating Plan Rule returns to the CRE the Service Offer that the leaf specifies.
Figure 233 - Service Offer Leaf Configuration Window
Table 176 - Service Offer Leaf Parameter Rating Plan Reference Description Reference to an instance of Service Offer object.

Table 177 - Service Offer Leaf Availability Service Rule n.a. Usage Rating Rule n.a. Charging Rule n.a. Rating Plan Rule Available Top-Up Rule n.a.
Page 476 of 968
11 September 2009
12.4.7. Usage Rating Rule Reference Leaf

When it reaches a reference leaf, a Usage Rating Rule starts executing the Usage Rating Rule that the reference leaf specifies. A rule that has one or more reference leaves is equivalent to the same rule, in which each reference leaf has been replaced by the reference leafs rule.
Figure 234 - Usage Rating Rule Reference Leaf Configuration Window
Table 178 - Usage Rating Rule Leaf Parameter Name Description Reference to a Usage Rating Rule.

Table 179 - Usage Rating Rule Leaf Availability Service Rule n.a. Usage Rating Rule Available Charging Rule n.a. Rating Plan Rule n.a. Top-Up Rule n.a.
11 September 2009
Page 477 of 968
Decision Trees
12.4.8. Charging Rule Reference Leaf

When it reaches a reference leaf, a Charging Rule starts executing the Charging Rule that the reference leaf specifies. A rule that has one or more reference leaves is equivalent to the same rule, in which each reference leaf has been replaced by the reference leafs rule.
Figure 235 - Charging Rule Reference Leaf
Parameter BILL_REF Reference to a Charging Rule.
Description

Table 181 - Charging Rule Leaf Availability Service Rule n.a. Usage Rating Rule n.a. Charging Rule Available Rating Plan Rule n.a. Top-Up Rule n.a.
Page 478 of 968
11 September 2009
Table 180 - Charging Rule Leaf
12.4.9. Rating Plan Rule Reference Leaf

When it reaches a reference leaf, a Rating Plan Rule starts executing the Rating Plan Rule that the reference leaf specifies. A rule that has one or more reference leaves is equivalent to the same rule, in which each reference leaf has been replaced by the reference leafs rule.
Figure 236 - Rating Plan Rule Reference Leaf Configuration Window
Table 182 - Rating Plan Rule Leaf Parameter Rating Tree Reference Description Reference to a Rating Plan Rule.

Table 183 - Rating Plan Rule Leaf Availability Service Rule n.a. Usage Rating Rule n.a. Charging Rule n.a. Rating Plan Rule Available Top-Up Rule n.a.
11 September 2009
Page 479 of 968
Decision Trees
Page 480 of 968
11 September 2009
Part IV. Scheduling Engine
11 September 2009
Page 481 of 968
Page 482 of 968
11 September 2009
13. Scheduled Events Processing
In a Nutshell...
13.1. Role of the Scheduling Engine

The Scheduling Engine is a non-optional sub-module (OSP service) of the Convergent Rating Engine. The role of the Scheduling Engine is to trigger the Community and Rating Engines with internal events, at predefined time. In particular, all the recurring tasks performed by the Convergent Rating Engine are launched by the Scheduling Engine. The figure below shows the role and positioning of the Scheduling Engine module in the Convergent Rating Engine.
11 September 2009
Page 483 of 968
Scheduled Events Processing
SCHEDULING ENGINE
events
events events events

COMMUNITY ENGINE RATING ENGINE
events
Convergent Rating Engine
events
Figure 237 - Scheduling Engine within the CRE

By sending events to the Community Engine, the Scheduling Engine enables some elementary business processes based on time. As such, the Scheduling Engine is the key component enabling the support of Subscriptions and of recurring Service Offers. The role of the Scheduling Engine is to trigger the Community and Rating Engines on time with scheduled events and to make sure they have been processed by these two modules. Nevertheless, the Scheduling Engine does not participate in the creation or in the definition of the scheduled events. The Scheduled Events are defined within the Product Catalog, as the key elements realizing a non-usage Service Offer. The scheduled events defined in the Product Catalog, made by the Rating or Community Engine and launched by the Scheduled Engine can be any kind of event: it can be a charge or a top-up, but not necessarily. For instance, a Scheduled Event could also be a management operation on the Account (like updating the Friends and Family List), involving no balance management operation.
13.2. Scheduled Events

The scheduled events are the ones that are sent to the Community and Rating Engines by the Scheduling Engine. They are expected to occur at a given date and time. The information about a Scheduled Event is materialized in the CRE by an object called Scheduled Event1. All the essential information needed for the processing of the event is included in that object, in particular: the user on behalf of which the event is taking place. the Service Offer related to that event (and to which the user has a Subscription) the next scheduled date and time of execution of that event.
1. Depending on whether the user is an Account or a Customer, the object is called Scheduled Account Event or Scheduled Customer Event. See 10.5.1.3, Customer or Account?, on page 307.
Page 484 of 968
11 September 2009
See a complete description in 10.5, Scheduled Event Objects, on page 305.
The Scheduling Engine keeps and manages a list of such scheduled events and ensures that they are processed once and only once, as close as possible to their scheduled time.
Scheduled Events Vs. User-initiated Events: Latency Issue

The Community and Rating Engines process the scheduled events (sent by the Scheduling Engine) in the same way as the user-initiated real-time events (sent by the RTx). However, scheduled events have a considerable difference with the user-initiated events. While the user-initiated events must absolutely be processed in real-time, the scheduled events can generally afford some latency. A few minutes, sometimes a few hours of delay, are most often acceptable for the non-usage scheduled events. For instance, nothing is really at stake if the monthly fee for a given service is charged at 11:00 PM instead of 10:00 PM. Thats why the Scheduling Engine works on a best effort basis: it automatically adapts the pace at which the events are sent to the Community Engine, in function of the load of the system.
13.3. Scheduled Event List

The Scheduling Engine doesnt create, configure nor manage the scheduled events. Its only duty is to launch them at the appropriate moment and in the correct order. All the events to be sent by the Scheduling Engine are already made up and listed in one single virtual queue called the Scheduled Event List.
13.3.1. Virtual Queue

The Scheduled Event List is a virtual queue comprising at any time, the list of scheduled events. Recurring events are included only once in that list, in the form of their next scheduled occurrence. When a recurring event is processed, the next occurrence is calculated by the Community and Rating Engines and placed into the Scheduled Event List. The figure below shows the flow of the Scheduled Events from and to the Scheduled Event List.
11 September 2009
Page 485 of 968
MANAGEMENT SERVER / GUI
Posting
SCHEDULING ENGINE
Event Response +next occurrence (if any)

COMMUNITY ENGINE RATING ENGINE
Scheduled Event List
Retrieving Figure 238 - Scheduled Event List
13.3.1.1. Posting Events to the Scheduled Event List

Events can be posted to the Scheduled Event List by either the Scheduling Engine or by some external management module, like a GUI. Internally, the posting of an event to the List corresponds to an Insert in an Oracle database. Regarding the posting of events in the Scheduled Event List, the main issue is the posting of recurring events. At a given moment, only one occurrence of a given recurring event is present in the Scheduled Event List: the next occurrence of the event. The next occurrence of a recurring event is posted by the Scheduling Engine, as a post-processing of the previous occurrence of the event. So the recurrence cycle is transparent to the Scheduling Engine, which receives and handles one occurrence of the event at a time. The date and time of the events next occurrence is computed by the Community and Rating Engines. Therefore, in order to start a stream of recurring events, you only have to post the first occurrence of the event to the Scheduled Event List.
Page 486 of 968
11 September 2009
The figure below illustrates the five main steps of the recurring event posting process.
2
MANAGEMENT SERVER / GUI
Posting
SCHEDULING ENGINE
Event Response
COMMUNITY ENGINE
RATING ENGINE
5
Retrieving
+next occurrence (if any)
Scheduled Event List
Step 1: The Scheduling Engine screens the Scheduled Event List and retrieves a non-usage event that is scheduled for NOW. Step 2: The Scheduling Engine triggers the Community Engine with the non-usage event. Step 3: The Community and Rating Engines process the non-usage event and compute the date and time of the events next occurrence (if the event is defined as recurring of course).
Step 4: The Community Engine sends the response back to the Scheduling Engine. This response includes: the result (successful/unsuccessful) of the processing of the events previous occurrence, the next occurrence of the non-usage event, to be posted to the Scheduled Event List. Step 5: The Scheduling Engine posts the non-usage event passed by the Community Engine into the Scheduled Event List.
13.3.1.2. Removing Events from the Scheduled Event List

The withdrawal of a scheduled event from the Scheduled Event List is only performed by the Scheduling Engine, when it receives the response from the Community Engine, confirming the successful processing of the event. Only then, the scheduled event is removed. Concretely, the Scheduled Event instance is actually not erased from the database; this is left to a periodic cleaning process. In the meantime, the Scheduled Events gets a particular status (Terminated).
13.3.1.3. Default Priority of the Scheduled Events

The events of the Scheduled Event List have 5 levels of default priority. Events scheduled at the exact same date and time will be launched according to that internal priority.
11 September 2009
Page 487 of 968
Table 184 - Scheduled Events Priority Levels Priority Level 0 1 2 3 4 Type of non-usage Event Manually created scheduled events Single, non-recurring events Recurring LiteSCE-defined events Recurring events, resulting in a charge or in a charge + a top-up Recurring events, resulting in a top-up More Info
See Priority of Manually Created Scheduled

Events, on page 306.
See Service Offer Definition - LSCE Info tab,

on page 249.
See Service Offer Definition - Charge Info

tab, on page 245.
See Service Offer Definition - Top-up Info

tab, on page 247.
Same Date and Time and Same Priority Level

If two events are scheduled for the same date and time and have the same priority level, the Scheduling Engine will launch them in a non-deterministic manner.
Priority Level 0 (zero)

The Scheduled Events created manually correspond to advanced management operations that you typically wont need in the standard Subscription management process. These events have the priority over all the others. Read more in 10.5.1.2, Advanced Mode: Provisioning Functionality, on page 306.
13.3.1.4. Past, Present or Future Events

The Scheduling Engine can be seen as a non-real-time channel to request the processing of events by the Convergent Rating Engine. Events posted in the Scheduled Event List can be scheduled for the past, the present or the future. They will be handled on a best effort basis. The possibility to schedule events in the past may seem meaningless. However, it allows the processing of (recurring) events that should have taken place in the past.
Example
Take the activation of a Subscription from a given moment in the past. Because of administrative delays, the provisioning of the CRE is done after the fact. So the service has indeed be activated for the user, who maybe already used it, but the creation of the corresponding Subscription in the CRE database has been postponed. The first non-usage event for that Subscription should have occurred at the activation of the service, so in the past! Such an activation event can be posted to the Scheduled Event List, with a scheduled date in the past.
13.3.2. Time Progression: Hourly Granularity

An essential duty of the Scheduling Engine is to ensure the processing of the scheduled events in the correct order: an event scheduled for 13:46 on the 3rd of October mustnt be processed after an event scheduled for 14:30 on that same day. Moreover, these two events should preferably occur at their scheduled time.
Page 488 of 968
11 September 2009
The Scheduling Engine guarantees the hourly granularity of the events schedule. Indeed, when the Scheduling Engine retrieves the scheduled events in the Scheduled Event List, it handles them per slice of one hour. Events of a given hour slice will always be sent to the Community Engine before the events scheduled in the next hour slice. Inside a one-hour slice, the scheduled events are ordered according to their priority level (from 0 to 4). When all the scheduled events of priority level 0 have been launched, the Scheduling Engine starts processing the scheduled events of priority level 1 of the hour slice. When all the scheduled events of priority level 1 are launched, the Scheduling Engine starts processing the scheduled events of priority level 2 of the hour slice. And so on. Within the hour-slice, the Scheduling Engine handles the events sequentially, per packets of n events (configurable, with a maximum of 250 events per packet). In this example, lets consider that the packets include 10 events. Before launching the second packet of 10 events, the Scheduling Engine waits for the responses of the Community Engine about the processing of the 10 events of the first packet. When the Scheduling Engine has the confirmation that all the events of the previous packet have been processed, it starts launching the events of the next packet. And so on. When all the packets of the hour-slice have been processed, the Scheduling Engine starts processing the event of the next hour slice the same way: ordered by priority level and grouped in packets of up to 10 events. The figure below shows the time progression followed by the Scheduling Engine, hour slices and packets of events.
Hour slice
Hour slice
NOW
events too old to be processed packets of 10 events in the same slice
scheduled events
Maximum window covered
Figure 239 - Scheduling Engines Time Progression The Scheduling Engine scans the Scheduled Event List, hour slice per hour slice, up to a maximum (configurable) past value. Events scheduled for a date before that maximum past value are simply disregarded by the Scheduling Engine. They will never be processed. When the Scheduling Engine has processed all the scheduled events until the maximum date in the past, it becomes asleep. The sleeping period is a configurable parameter expressed in minutes. At the end of the sleeping period, the Scheduling Engine automatically awakes and starts over scanning the Scheduled Event List, from now to the maximum date in the past. The Scheduling Engine uses mechanisms to fast jump over empty hour slices. The posting of events, including past events, into the Scheduled Event List is not controlled by the Scheduling Engine and can occur in total de-synchronization with it: so it can happen when the Scheduling Engine is asleep, or when the Scheduling Engine is being launching the scheduled events.
11 September 2009
Page 489 of 968
13.3.3. Time Zone Management

The appropriate date and time management is obviously an important issue for the Scheduling Engine and globally in the Convergent Rating Engine. Many features are concerned, especially the whole Product Catalog (Subscriptions, Service Offer Definitions, Scheduled Events, Date and Time criteria), the Accounts life cycle and the Versioning. The complexity of the time zone management is totally carried out internally by the system. Indeed, the Convergent Rating Engine ensures that you can configure and maintain your system via the GUIs always in local time. As a result, you dont have to care about the daylight saving time changes or the concurrence of events defined in different time zones. The Convergent Rating Engine manages those issues automatically; they will be transparent to you. For instance, if you define a recurring event to occur the 5th day of each month at 23:00, you dont have to be afraid to have it launched the 6th day at 0:00 after the switch to summer time. Your definition will always be valid in local time. In the execution of its own logic, the Convergent Rating Engine does perform date and time conversions from local time to GMT and conversely. The CRE database actually stores all dates and times in GMT. Nevertheless, you dont have to care about these implementation details; they wont impact your systems configuration or execution.
13.4. Scheduling, Community and Rating Engines Interactions

The Scheduling Engine interacts with the Community and Rating Engine in order to process the scheduled events. In this processing, we can distinguish three consecutive exchanges between the sub-modules of the Convergent Rating Engine. Interaction1: the SE sends the scheduled events to the CE. Interaction 2: the CE triggers the RE with the one-shot request. Interaction 3: the SE receives the response from the CE and RE, and post-processes it.
13.4.1. Launching the Scheduled Events

The Scheduling Engine sends the events retrieved in the Scheduled Event List to the Community Engine, at the scheduled time. These events are non-usage events, not initiated by, but sent on behalf of a given Customer (or Account). These non-usage events are transported to the Community Engine via a DPE / southbound interface.
13.4.2. Processing of the Non-usage Events by the Community and Rating Engines
For the Community Engine, processing non-usage events is equivalent to processing usage events. The Community Engine performs the validation process as usual, i.e.: the identification of the Customer, and subsequently of the Account to be charged or topped-up, the identification of the relevant Service Offer in the Customers portfolio. Once this validation is done, the Community Engine triggers the Rating Engine with the request. If the scheduled event is a charge operation, the Rating Engine will be triggered with a one-shot request (so without reservation).
Page 490 of 968
11 September 2009
For the Rating Engine, the scheduled event first implies some balance management operation: a charge, a top-up, or both. As opposed to the processing of usage events, the processing of non-usage events may additionally include specific tasks, such as prorating. The Rating Engine still has a second task to perform: updating the Scheduled Event, in function of the result of the processing just accomplished, and calculating the date and time of the next occurrence (if the scheduled event is recurrent). This information is then forwarded to the Scheduling Engine via the Community Engine, as a response.
13.4.3. Receiving the Community and Rating Engines response

The Scheduling Engine waits for responses about the processing of the scheduled events previously sent. In case of time-out, the same event will be sent again to the Community Engine. The avoidance of double processing is ensured by the Community and Rating Engines. When the Scheduling Engine receives the response of the Community and Rating Engines, several cases are possible. Keep in mind that, whether the scheduled event was successfully processed or not, the only information that really matters for the Scheduling Engine is how to update the Scheduled Event List. The table below describes some typical responses received by the Scheduling Engine, and the subsequent operation performed on the Scheduled Event List. Table 185 - Responses received by the Scheduling Engine Response
Reason Execution ok Scheduled event not defined as recurrent Execution ok Scheduled event defined as recurrent The Community Engine could not identify the requested Customer or the portfolio was not appropriate (e.g. the Customer unsubscribed in the meantime). The Rating Engine could not perform the charge or the top-up (e.g. not enough credit on the Account).
Operation on the Scheduled Event List Scheduled event withdrawn from the List (i.e. marked as processed).
Event processed ok No further event to be scheduled Event processed ok Next occurrence to be scheduled at a given date and time Event not validated
Scheduled event updated in the List with its new date and time. The info about the previous scheduled event is also updated: cost, date and time. Depends on the settings of the Service Offer Definition. If the scheduled event is recurrent, the next occurrence can still be foreseen.
Event no authorized
Depends on the settings of the Service Offer Definition. If the scheduled event is recurrent, the next occurrence can still be foreseen.
11 September 2009
Page 491 of 968
13.5. Event Data Record for Scheduled Events Processing

The Event Data Record produced when a scheduled event is processed by the Community and the Rating Engines is comprised into a single consolidated statistical ticket. This statistical ticket is sent to and only to the External Module (typically a Storage Engine). In summary, thats all you need to know about the Event Data Records reflecting the processing of the scheduled events. For a detailed explanation, read the two sections below.
13.5.1. Consolidation of the EDR

The Community Engine is the front-end module receiving the scheduled event request from the Scheduling Engine. This request message is materialized by the transient object net_evt. While it performs its part of the event processing, the Community Engine fills in a statistical ticket. The statistical ticket is materialized by the transient object statinfo, embedded in net_evt. When the Community Engine has finished processing the event, it forwards the request to the Rating Engine. So the Rating Engine receives from the Community Engine the same net_evt message. While it performs its own processing of the scheduled event, the Rating Engine also fills in the statistical ticket included in net_evt. The Rating Engine then sends the transient object net_evt back to the Community Engine. The Community Engine then appends the information filled in into statinfo.stenctkt by the Community and the Rating Engines. Then the Community Engine sends the consolidated statistical ticket to the External Module.
net_evt statinfo stext_f = 2 stlan_f = 1 stenctkt
CE EDR
Scheduling Engine
Community Engine
Rating Engine
CE EDR
RE EDR
statinfo stext_f = 2 stlan_f = 1 stenctkt
[CE+RE] EDR
External Module
Figure 240 - Scheduled events EDR: consolidation and sending to External Module
Page 492 of 968
11 September 2009
13.5.2. Destination of the EDR: always the External Module

Reminder: General Behavior of the Convergent Rating Engine
In the Convergent Rating Engine, the general system behavior as to where the EDRs are sent is set in the Configuration objects (CE Configuration and RE Configuration). See 4.1.4, Statistics Tab, on page 81. The general EDR routing settings of the CRE Configuration allow you to make two decisions: allow (or not) the sending of the EDR to the RTx (parameter stext_f) allow (or not) the sending of the EDR to the External Module (parameter stlan_f). In the Configuration, you can also decide to let the RTx decide for each transaction, if the EDR is to be forwarded to the RTx and/or to the External Module or to none of them.
Particular Case: EDRs of non-usage scheduled events

For the EDRs of the non-usage events launched by the Scheduling Engine, the behavior of the Convergent Rating Engine is a bit different. It ignores the settings of the Configuration and you cannot modify it. In the particular case of the non-usage events launched by the Scheduling Engine, the RTx (i.e. the triggering entity) is actually the Scheduling Engine. And yet the Scheduling Engine should not be receiving statistical tickets, for the following three reasons:
1.
2.
The Scheduling Engine receives a response from the Community and Rating Engines for each scheduled event launched. So it doesnt need the statistical ticket about that event.
The Scheduling Engine already manages a big database (the Scheduled Event List), which shouldnt be overloaded. The Scheduling Engine is part of the Convergent Rating Engine, which delegates the processing of its EDR information to a dedicated module: the Storage Engine. The Scheduling Engine is not designed for storing or analyzing EDRs.
3.
Embedded in net_evt, the transient object statinfo has three important attributes: stext_f, stlan_f and stenctkt.
Table 186 - Transient object statinfo Attribute stext_f stlan_f Meaning of the Attribute Should the EDRs be sent to the External Module? Should the EDRs be sent to the RTx (or any other requesting module, like the Scheduling Engine)? Contents of the statistical ticket itself. Possible Values in general Possible Values for scheduled events 2
0: read from Config 1: do not send ticket 2: send ticket list of any number of statistical events
1 list of any number of statistical events
stenctkt
This is the EDR content!
By forcing the value stlan_f to 1 in the net_evt transient object transporting the non-usage event request, the Scheduling Engine ensures that it will never get the statistical ticket back. It is a constraint in the CRE that the stext_f and stlan_f parameters must be both set to zero, or none of them. Functionally, it means that, regarding the sending of the statistical tickets, either you fully rely
11 September 2009
Page 493 of 968
on the Configuration, or you must specify all the settings in the request. You cannot partially adopt the Configurations settings. As a result, the Scheduling Engine must also specify the value of the stext_f parameter, and cannot rely on the Configuration settings as to the sending of the EDR to the External Module. So stext_f is always set to 2 by the Scheduling Engine, which forces the EDR to be sent to the External Module. So whatever your settings as to the tickets in the Configuration, you dont have the choice for the tickets related to the scheduled events: they will never be sent back to the Scheduling Engine and they will always be sent to the External Module.
13.6. Error Management

13.6.1. Errors Vs. Unsuccessful Events
The unsuccessful events are not necessarily events in error. For instance, when the Scheduling Engine sends a recurring fee to the Community Engine, and the target Account has not enough credit, the fee cannot be charged and so the scheduled event is returned as unsuccessful. In such a case, the attempted operation (charging an Account) cannot be performed, but the CREs logic is fully and normally executed. The consequence of such an unsuccessful event is generally a modification of the Subscriptions state, which will typically pass from Active to Suspended. The term error covers other cases, in which the Convergent Rating Engines logic cannot be fully executed. For instance, if the Service Offer defining the scheduled event cannot be identified, the Convergent Rating Engine is unable to know its cost, on what Account it should be charged, and so on. In such a case, the attempted operation is aborted before the complete CRE logic has been executed (the Rating Engine wont even be triggered). The unsuccessful events correspond to cases foreseen and designed in the Convergent Rating Engine (Account Life Cycle, Subscriptions, Product Catalog Management,...). The processing consecutive to unsuccessful events is taken over by the logic. The Convergent Rating Engine knows how to react to any unsuccessful event. See 10.5.4.2.2, In case of unsuccessful execution, on page 317. On the other hand, the errors correspond to cases that should logically not happen if the CRE is correctly configured and if the physical infrastructure is up and running. As such, the error cases cannot be repaired by the Convergent Rating Engine. They require an external intervention.
13.6.2. Error Management Facility at a Glance

When the Scheduling Engine launches scheduled events towards the Community Engine, there can be several reasons why these events wouldnt be successfully processed. Basically, problems could occur in the transport of the event through the Scheduling, Community and Rating Engines, or during the processing performed by one of these modules. The Scheduling Engine always receives a response from the Community Engine for each scheduled event sent. The error management facility of the Scheduling Engine is based on the continuous watching of the responses, in order to rapidly detect the problems and to locate their likely source. The Scheduling Engine can obviously not fix the problems that can occur. So the Scheduling Engine mainly adopts a defensive safety behavior, which consists in blocking the items that seem to be causing the problem. By blocking a few or a series of scheduled events, the Scheduling Engine
Page 494 of 968
11 September 2009
prevents the overload of the Community and Rating Engines if they encounter problems processing the events and protects the integrity of the scheduled events stored in the Scheduled Event List.
13.6.3. Implementation
13.6.3.1. The Error Mode
The error mode is a blocking facility available in two objects defining the components of the Scheduled Event List: the Scheduled Event GUI and the Partition GUI. The Scheduled Event GUI is equipped with an Error mode flag. When it is checked for a given Scheduled Event, there are two consequences:
1.
2.
This event cannot be processed by the Scheduling Engine. It wont be sent to the Community Engine.
The other attributes of the scheduled event cannot be modified. It is like frozen in the Scheduled Event Lists database.
When the Error mode flag is checked, the Scheduled Event is blocked.
The Partition GUI offers an Error Status. When a given Partition is set to the Error Status, there are two consequences:
1.
2.
The Scheduled Events on that Partition cannot be processed by the Scheduling Engine. They wont be sent to the Community Engine.
The Scheduled Events on that Partition cannot be modified. They are like frozen in the Scheduled Event Lists database.
11 September 2009
Page 495 of 968
When set to the Error Status, the Partition is blocked.
Interest of the Error Mode

When a Scheduled Event (or a Partition) is in Error Mode, the Scheduling Engine cannot launch them anymore. However, they are kept as such in the Scheduled Event List. Especially, their Status is not changed: for instance, they can remain Activated while they are blocked by the Error mode. Notably as well, the dates are unchanged. So the Next Date is not modified. When the Error mode is disabled on the Scheduled Event, if the Next Date is in the past, the Scheduled Event will be processed, and its potential next occurrences as well (if it is a recurring event). And so on, until all the event occurrences that should have been processed until the present date have been launched by the Scheduling Engine.
Blocking individual Scheduled Events or a complete Partition?

The complete Partition (as opposed to an individual Scheduled Event) is blocked whenever the type of error encountered is likely affecting other Scheduled Events than the one that provoked the error. For instance, if the Product Catalog could not be properly analyzed because no Service Offer could be found for the triggered Service, then the source of the error is a misconfiguration of the Product Catalog. This error will very probably re-occur for the other Scheduled Events concerning the same Service Offer. So the safety principle propels to block the whole Partition, in order to investigate and solve the problem, without overloading the Community and Rating Engines with requests impossible to process.
13.6.3.2. The Monitoring Counters

The Error Management performed by the Scheduling Engine is based on the continuous monitoring of the Result Codes received in the response from the Community and the Rating Engines. For each non-successful event, according to the Result Code received, the Scheduling Engine updates a monitoring counter and/or sets a Scheduled Event or a Partition to the Error mode. The Scheduling Engine maintains three error monitoring counters. These counters are compared to specific threshold values (set in the Scheduling Engines Configuration). When the value of a threshold is exceeded, the Scheduled Event or the Partition is set to the Error mode. 1. Local counter
The Local counter is incremented each time a DPE error occurs for a given scheduled event, i.e. in case of communication problem between the Scheduling, Community and Rating Engines. This counter is
Page 496 of 968
11 September 2009
compared to a threshold value specified in the Scheduling Engines Configuration (config.nbretry): Max # of retries in case of communication problem (see page 126).
Threshold value to which the Local counter is compared.
When the Local counter exceeds the threshold value, the Scheduling Engine sets the Partition or Scheduled Event to the Error mode, according to the exact type of error that occurred (see table 188 below). 2. Global counter 1
The Global counter 1 is incremented each time a NOK service or NOK data error occurs, i.e. in case of a bad configuration of the Community and/or the Rating Engine, especially of the Product Catalog or of the users (Accounts and Customers). This counter is compared to a threshold value specified in the Scheduling Engines Configuration (config.maxerr): Max # of errors per slice before stop host (see page 128).
Threshold value to which the Global counter 1 is compared.
When the Global counter 1 exceeds the threshold value, the Scheduling Engine sets the Partition to the Error Status. 3. Global counter 2
The Global counter 2 is incremented each time an error of type Kill occurs, i.e. if the Community or Rating Engines processing is abruptly aborted because of a severe execution error. This counter is
11 September 2009
Page 497 of 968
compared to a threshold value in the Scheduling Engines Configuration (config.errnbret): Max # of kills per refresh before stop host (see page 127).
Threshold value to which the Global counter 2 is compared.
When the Global counter 2 exceeds the threshold value, the Scheduling Engine sets the Scheduled Event to the Error mode. The table below summarizes the three error monitoring counterss features. Table 187 - Monitoring Counters and Thresholds: Summary Threshold Max # of retries in case of communication problem Counter Local counter, reset at each new Scheduled Event processing. If counter > threshold... If error = Wait and Retry, then set Scheduled Event to the Error mode.
See page 126.

Max # of errors per slice before stop host
If error = Switch and Retry, then set Partition to the Error Status. Set Partition to the Error Status.
See page 128.

Max # of kills per refresh before stop host
Global counter 1, reset at each new packet of Scheduled Events. Global counter 2, reset at each Refresh of the Scheduling Engine.
Set Scheduled Event to the Error mode.
See page 127.
13.6.3.3. Switching to Error Mode

Scheduled Events or Partitions are switched to the Error mode when one of the thresholds is exceeded (see table 187 above) or when some specific errors occur (of which a single occurrence is sufficient, no other threshold needs to be reached). The list of all the error cases that may occur is available in table 188 below.
13.6.3.4. Typology of Possible Errors

The table 188 below defines the various types of errors that may be returned to the Scheduling Engine, via some result codes. For each of these error cases, the Scheduling Engine updates some counter(s) and/ or sets the Partition or the Scheduled Event to the Error mode.
Page 498 of 968
11 September 2009
Table 188 - Typology of errors managed by the Scheduling Engine Type of error Scheduled Events status changed Cause These Result Codes dont indicate errors, but unsuccessful events. Scheduling Engine behavior The Scheduled Events Status is modified. This is a regular transition foreseen by the CRE. Result Codesa 100 101
See 13.6.1, Errors Vs.

Unsuccessful Events, on page 494.
See 10.5.4.2.2, In case of

unsuccessful execution, on page 317.
Scheduled Event switched to error
During the CRE processing of the event, a NOK data or NOK service error directly linked to the user is encountered. In other words, there is very likely a configuration problem on one or more of the following objects: Customer Account Customer Association Customer Account Top-up Profile
Scheduled Event set to the Error mode. Global Counter 1 incremented. An alarm is sent.
103 200.1 100.2 100.19 200.20 200.21 200.22 200.72 302.2 200.13
Note: In case of Forbidden leaf encountered in the URR, attached with the Service Offer Definition of the subscription; the subscription is not switched to error mode, rather results in successful free occurrence of fee. Wait and Retry Because of some overload, the CRE is very slow, and the Account triggered by the Scheduled Events is still locked, or the current Scheduled Event is actually being executed. 1. Local Counter is incremented and the Scheduled Event is retried. And so on for each unsuccessful processing of the Scheduled Event. If Local Counter > related threshold, then Scheduled Event set to the Error mode Global Counter 1 incremented.
300.40 300.157
2.
11 September 2009
Page 499 of 968
Table 188 - Typology of errors managed by the Scheduling Engine Type of error Switch and Retry Cause Because of some overload, the CRE is very slow, and some communication problems occur on the DPE bus between the Scheduling, Community and Rating Engines. 1. Scheduling Engine behavior The Community Engines SEP Group is switched and the Scheduled Event is launched again. If the problem still occurs, then Local Counter incremented The Scheduling Engine waits before retrying the Scheduled Event once again (see Error Retry Timer, page 128). 3. If Local Counter > related threshold, then Partition set to the Error Status. An alarm is sent. Kill capture During the CRE processing of the event, the execution is abruptly interrupted because of a kill, i.e. an unexpected severe execution problem. Scheduled Event set to the Error mode. Global Counter 1 incremented. Global Counter 2 incremented. If Global Counter 2 > related threshold, then Partition set to the Error Status. Block Partition During the CRE processing of the event, a NOK data or NOK service error not directly linked to the user is encountered. In other words, there is very likely a configuration problem on some objects that could affect more than the current user (e.g. in the Product Catalog).
a. For more details about the Result Codes, see your Convergent Rating Engine 2.0 DPE Error Codes document.
Result Codesa 305.10 305.11 305.12 305.13 306.8
2.
304
Partition set to the Error Status. An alarm is sent.
Other result codes.
13.6.4. Repairing Scheduled Events in Error Mode

Once the risk of error is under control, the Scheduled Events that were blocked in error mode may be processed. To do so, the operator must manually unblock, via the GUI, the objects instances that are blocked.
Page 500 of 968
11 September 2009
13.6.4.1. Scheduled Event switched to Error Mode

Step 1: The operator investigates and resolves the problem (most likely outside the Scheduling Engine). Step 2: The operator unsets the error flag in the Scheduled Event GUI.
Step 3: If the Scheduled Event didnt become obsolete in the meantime, it is launched by the Scheduling Engine towards the Community Engine. If the scheduled event became obsolete in the meantime, the only way to execute it is to use the Scheduled (Customer or Account) Event GUI from Jobs sub-menu of ARES menu.
The two GUIs available from the Jobs sub-menu of ARES menu are actually views on the Scheduled Customer Event (cltfee) and Scheduled Account Event (accfee) objects, located in the Community and Rating Engine. Via these two GUIs, you cannot create or
11 September 2009
Page 501 of 968
modify any instance of a scheduled event. On the other hand, the GUI offers an EXECUTE command. This is the only way to force the execution of an outdated scheduled event.
Remark: If the Partition is in the Error Status, you cannot execute any Scheduled Event, even manually. You must first repair the Partitions Status. Step 4: If it is a recurring event, the Scheduling Engine will launch all the consecutive occurrences (computed by the Rating Engine) of the scheduled event, until the next date is in the future.
13.6.4.2. Partition switched to Error Mode

Step 1: The operator investigates and resolves the problem (most likely outside of the Scheduling Engine). Step 2: The operator modifies the Partitions Status from Error back to Active, via the Partition GUI.
Step 3: The Scheduling Engine processes the scheduled events of that partition, provided that they are not in Error Mode. So if the scheduled event didnt become obsolete in the meantime, the Scheduling Engine launches them towards the Community Engine. Step 4: If it is a recurring event, the Scheduling Engine will launch all the consecutive occurrences (computed by the Rating Engine) of the scheduled event, until the next date is in the future.
Page 502 of 968
11 September 2009
14. Recurring Events Management
In a Nutshell... The scheduled events can be recurrent, designing a repeated cycle. All the different recurring events linked to a Subscription can be synchronized, according to a homogeneous Subscription cycle, or billing cycle. When for any reason a cycle is not complete, the CRE can adjust the scheduled events processing by prorating the fees and potentially refunding them.
14.1. Service Cycle

Recurring events occur repetitively at fixed regular intervals of time. The key parameters that define the recurrence are the period or cycle, the starting date and the termination date.
14.1.1. Cycle Definition and Granularity

The Service Cycle is the time interval between two consecutive occurrences of a Scheduled Event defined as recurrent. In the Convergent Rating Engine, the granularity of the cycle is up to the day. This means that the shortest cycle is a day. The CRE allows specifying the cycle in multiple of days, weeks, calendar months or years. So a non-usage events can be scheduled every other week on Wednesday, or every second day of each month. You will then notice that the monthly cycles wont include the same number of days each time. Although the cycle granularity is limited to the day, the time of occurrence can be distributed during the day, depending on the starting date of the cycle. For instance, a bi-weekly cycle starting a Tuesday at 16:12 will occur every two weeks on Tuesday at 16:12. The Service cycle is an attribute of the non-usage Service Offer, via its definition in a Service Offer Definition.
11 September 2009
Page 503 of 968
Recurring Events Management
14.1.2. Schedule Events at the Beginning or at the End of the Cycle

A recurring event can be scheduled at the beginning or at the end of its cycle. This does not influence the periodicity, but simply when the event needs to occur relative to the cycle. Since the end of a cycle coincides with the beginning of the next one, the choice will only affect the first and the last occurrence. The figures below show the occurrences of the events in the two different ways.
Starting Date of the non-usage Service Offer Termination Date of the non-usage Service Offer
Cycle (1st period)
Cycle (2nd period)
Cycle (3rd period)
Recurring Event (for the 1st period)
Recurring Event (for the 2nd period)
Recurring Event (for the 3rd period)

Figure 241 - Scheduling recurring events at the beginning of the cycle
Starting Date of the non-usage Service Offer
Termination Date of the non-usage Service Offer
Cycle (1st period)
Cycle (2nd period)
Cycle (3rd period)
Recurring Event (for the 1st period)
Recurring Event (for the 2nd period)
Recurring Event (for the 3rd period)
Figure 242 - Scheduling recurring events at the end of the cycle When the recurring event is a charge, scheduling it at the beginning or at the end of the cycle actually means that the user pays the recurring fees in advance (for the upcoming period) or in arrears (for the elapsed period).
Page 504 of 968
11 September 2009
14.1.3. Starting Date

The starting date is the date and time at which the first cycle is beginning. The starting date is not necessarily the date at which the first recurring event should be scheduled, since it could occur in arrears, i.e. at the end of the first cycle.
14.1.4. Termination Date

The termination date is the date and time after which the recurrence is terminated: the scheduled event wont occur anymore. It is not necessarily a cycle boundary. The cycle current at the termination date will be last one. A recurring non-usage service can cover a limited period of time or be indefinite. So there may also be no termination date. An alternative method for setting the termination of the recurring non-usage service is to specify a number of occurrences of the scheduled event. Note: A recurring non-usage service with a recurrence of 1 can be compared to a non-recurring service, but it will inherit from the behavior of the recurring services, in particular the prorating functionality. See 14.4, Prorating Fees, on page 508.
14.2. Synchronizing Recurring Events

Synchronizing means that you align the cycle of your recurring events with an external date. This date is provided in the corresponding Subscription (i.e. the Subscription to the Service Offer Group containing the Service Offer of type non-usage defining those recurring events). For instance, a Service Offer of type non-usage defines a monthly fee. If the user subscribes on the 9th of February, without synchronization then the monthly recurrence will be computed from that date on. So the recurring fee events will be scheduled on the 9th day of each month: 9th of March, 9th of April, etc. with synchronization then the users fee cycle will be brought back to a standard cycle (which can be for example the billing cycle of the postpaid accounts), set to the 28th day of each month. So the fee events will be scheduled on the 28th day of each month: 28th of February, 28th of March, etc. In other words, the first cycle is shortened (20 days for February 9 to February 28) in order to have all the following cycles stick to the standard cycle. Note: In such a case, you might want to pro-rate the fee of the first period. For information about prorata, see 14.4, Prorating Fees, on page 508.
14.2.1. Conditions for Enabling the Synchronization

There are three mandatory settings for enabling the synchronization of recurring events. If one of those conditions is not fulfilled, then the synchronization wont happen.
11 September 2009
Page 505 of 968
See also 14.2.2, Cases of Refused Synchronization, on page 506.
Table 189 - How to have your Fee events synchronized? Condition Condition 1 Object Subscription
to the Service Offer Group containing the Service Offer defined by the Service Offer Definition
Required Configuration Fill in the parameter Forced Charging Date with the synchronization date.
See description page 293.
Condition 2
Service Offer Definition
Check the Align with Subscriptions Synchronization Date flag.
See description page 242.

Condition 3 Service Offer Definition Define the Recurrence Pattern as a pure interval, without any reference to a specific date, week day or month. Therefore, fill in the fields: Recurrence Pattern Number of days/weeks/months/years and leave the following fields empty: Day of the Week Day of the Month Month of the Year
See description in table 76, Service Offer Definition Recurrence Info tab, on page 241.
14.2.2. Cases of Refused Synchronization

If a precise date, week day or month is specified in the Recurrence Pattern, then the synchronization is forbidden. If you have one of those fields filled in and you check the Synchronize Charging Date flag afterwards, you will see that the date, week day or month fields are displayed in grey; it means that they will be discarded by the CRE, which will only take the Forced Charging Date into account. Indeed, it is incompatible to have a fee to be paid the 24th day of each month according to the Recurrence Pattern, and synchronized to the 3rd of March at the same time. You can only synchronize a Recurrence Pattern defined as a pure interval. So keep in mind that the Synchronization flag overrides the settings that anchor your Recurrence Pattern to a precise moment in time.
14.2.3. Concrete Examples

For a recurring event that starts at the Subscription activation, with a monthly Recurrence Pattern, synchronized on a Subscriptions Forced Charging Date set to the 28th of March, two cases are possible:
Page 506 of 968
11 September 2009
Case 1: the Forced Charging Date is reached before the first period end
If the Subscription is activated on the 10th of March then the first cycle is shortened for ending on March 28, even if the period of one month defined by the Recurrence Pattern is not reached. From then on, the recurrence will become regular, with cycles of one month, re-starting the 28th day of each month.
March 28
April 28
Subscription Activation
March 10
January 1
February 1
March 1
April 1
May 1
First Cycle is shortened
Regular synchronized cycle
Case 2: the Forced Charging Date occurs after the first period end
If the Subscription is activated on the 3rd of January. then the first complete cycle of one month, as defined in the Recurrence Pattern, elapsed on February 3 before the Forced Charging Date was reached. The cycle is regular as to its Recurrence Pattern, but cannot be synchronized so far. When reaching March 3, a second complete one-month cycle elapsed, and the Forced Charging Date is still not reached.
On March 28, the Forced Charging Date is reached; so the ongoing cycle is shortened in order to synchronize all the next cycles to that date. From then on, the recurrence will always be regular and synchronized, with cycles of one month, re-starting the 28th day of each month.
February 3 March 3
Subscription Activation
January 3
March 28
January 1
February 1
March 1
April 1
May 1
Regular cycle
Regular cycle
Cycle is shortened
The rule can hence be worded as follows: 1. 2. The cycle duration defined by the Recurrence Pattern cannot be exceeded. When the designed period elapsed, the cycle ends and a new one starts. The Forced Charging Date has the priority over the period defined by the Recurrence Pattern. When the Forced Charging Date is reached, the ongoing cycle ends and a new one starts.
14.3. Refund Cases

Obviously, the concept of Refunding only applies to items that have already been paid. As a consequence, the Allow Refunds flag (see parameter Allow Refunds, page 246) only makes sense when
11 September 2009
Page 507 of 968
the selected payment mode is In Advance (see parameter The Non-usage Event covers the Period, page 241). Note: The case of refund applies only when you cancel from GUI. The refund is never allowed in case of Future Cancellation Date is given A Refund operation only occurs at Subscription cancellation. A prorata factor is then computed, in order to know the proportion of the fee paid for the entire period that has to be refunded. The amount paid in advance for the period is displayed in the corresponding Scheduled Event object (see parameter Last Cost, page 312). Note: Prorata flag should be checked whenever Refund case is mentioned. The Event Data Record produced by the Convergent Rating Engine contains the information of the refunded amounts. Hence, all the amounts refunded to the users can easily be retrieved by analyzing the statistical tickets. Note: Only the costs charged on the main Balance are tracked by the Scheduled Event object, in the Last Cost parameter. Fees charged on the Accounts Bundles are never refunded.
14.3.1. Prorata implied by the Refund

You have noticed that a Refund implies the notion of prorata. Indeed, the prorata is applied to any refund operation, whatever the status of the Prorata flag.
The prorata applied for refunding fees is always a simple, linear prorata, expressed as a percentage of the amount previously paid. If that amount was the result of a quantity-to-cost translation via a Tariff, the translation wont be re-done.
The formula for calculating the prorata factor is described in 14.4, Prorating Fees, on page 508.
14.3.2. Case of no Refund

When a Subscription is suspended, the Convergent Rating Engine doesnt perform any refund. Consequently, the Subscriptions suspension is postponed to the end of the ongoing period, since the user has anyway paid for the whole period. In the meantime, the Subscription remains in state Active.
14.4. Prorating Fees

Prorating fees means that the normal cost of the fees, whether provided by a fixed amount or computed thanks to a Tariff, is weighted because the period of time they are supposed to cover is shortened. The opportunity of prorating fees occurs whenever a cycle is shortened. In such a case, either the user pays the fees as if the period were complete (there is then no prorating), or the user pays the fees proportionally to the period in which the corresponding service was effectively available to him (then prorating is applied). The prorata is expressed as a percentage, which is calculated according to the following formula:
number of days effectively covered in the period ------------------------------------------------------------------------------------------------------------------- 100 number of days in the complete period
The precision of the prorata factor is the same as the precision of all money values in the Convergent Rating Engine. See Computing Precision*, on page 146.
Page 508 of 968
11 September 2009
Note: Prorata flag should be checked whenever Refund case is mentioned.
14.4.1. Granularity of the Prorata

As shown in the prorata formula, the base unit for prorating fees is the day. Any day started is due. Beware! The day taken into account for the prorating is not the calendar day, but the effective day, i.e. a period of 24 hours. Keep in mind too that, within the Convergent Rating Engine, all dates are actually Date & Time parameters.
Example 1
A monthly Fee of 10 EUR, started at Subscription activation, which occurred on July 3 at 11:00 AM, suspended on July 20 at 9:00 AM. Then the user pays for 16 days, applying the following prorata factor to the fee amount:
16 ----- 100 = 51,61% 31
Example 2
Same example, but the Subscription is suspended on July 20 at 2:00 PM.
Then the user pays for 17 days, because the day from July 20 at 11:00 to July 21 at 11:00 is included. The following prorata factor is applied to the fee amount:
17 ---- 31 100 = 54,84%
Corollary: If the Subscription is re-activated on July 20 at 4:00 PM, then that day will be paid twice.
Example 3
A monthly Fee of 10 EUR, started at Subscription activation, which occurred on February 3 at 11:00 AM, suspended on February 20 at 9:00 AM. Then the user pays for 16 days, applying the following prorata factor to the fee amount:
16 ---- 28 100 = 57,14%
14.4.2. Linear Vs. Nonlinear Prorata

If the recurring fee is defined by a fixed amount, the prorata factor is applied to weight that cost. In such a case, if half the period elapsed when prorata occurred, then only 50% of the cost is due. If 90% of the period was covered, then 90% of the cost is due. This type of prorata is linear. Some examples are developed in 14.4.1, Granularity of the Prorata, on page 509. On the other hand, if the Fee amount is computed via a Tariff (provided by a Rating Rule) rating some quantities, then the prorata factor is applied to weight those quantities. Whether the Tariff performs a quantity-to-cost translation (for charging on the Accounts main Balance) or a quantity-to-quantity translation (for charging on a Bundle) doesnt make any difference.
11 September 2009
Page 509 of 968
Since a Tariff curve is not necessarily linear, the result of the prorating operation may be nonlinear as well. The figure below shows five example Tariff curves that could be applied to fee cost calculation. Lets have a look at the various prorata results that they can lead to:
cost curve 2
10 9 8 7 6 5 4 3 2 1 10 20 30 40 50 60 70 80 90 100 110 120
curve 1 curve 4
curve 3
curve 5 quantities
Figure 243 - Examples of Nonlinear Prorata on several Fee Tariff Curves
Curve 1- linear curve

Prorating the quantities instead of the cost doesnt make any difference, because the tariff curve itself is linear. For n% of the quantities, youll pay n% of the cost.
Curve 2 - discontinuous curve

Thanks to the connection cost of 4 EUR, the Service Retailer makes sure that the fee will reach at least 4 EUR, even if the Subscription is terminated immediately after the start of the period. Terminating the Subscription between 10% and 60% of the complete period duration wont make any difference as to the cost.
Curve 3 - constant
Prorating has strictly no effect on the cost. The fee costs 3 EUR, whether the Subscription is terminated at some point of the period or not. Even if the quantities are weighted, the cost is still a constant that wont be impacted.
Curve 4
A connection cost of 1 EUR guarantees a minimal revenue to the Service Provider, even if the Subscription is terminated very early. The cost per quantity is cheaper and cheaper across time. The first quantities are the most expensive ones. So even if the Subscription is terminated after 25% of the period, 80% of the total fee cost has already been paid anyway.
Curve 5 - decreasing cost
Page 510 of 968
11 September 2009
Only the first 20% of the period covered by the fees have a cost; the remaining 80% are free. This Tariff means that you only pay fees if you terminate your Subscription within that slice of the first 20% of the total period. If your Subscription remains activated beyond that 20% limit, then the fee is free of charge. The same principles and analysis are valid for quantity-to-quantity translations, i.e. for Tariffs charging on Bundles. However, keep in mind that you cannot split a Bundle unit. The usual rounding rules of the Convergent Rating Engine apply. See Rounding Method*, on page 147.
14.4.3. Cycle Truncations

There are several situations, in the global management of Subscriptions, in which prorating the fees can be an issue. Whenever the complete period that the recurring fee covers is interrupted, the Convergent Rating Engine must make the decision on whether or not the fee amount should be prorated. Here is the list of the possible cycle truncations, as potential occasions of prorating the Fee:
1.
2. 3. 4.
when synchronization shortens a cycle

at Subscription cancellation at Subscription suspension at Subscription reactivation at any refund operation
5.
14.4.4. Typical Prorating Cases: Schematic View

The occasions in which prorating applies can be summarized in six typical cases, classified according to two factors: the scheduling of the fee events: at the beginning or at the end of the cycle; the moment of the cycle truncation: at first, last or intermediate occurrence. In the figures 244 to 249 below, you will find a visual schematic representation of those six typical cases. Table 190 - Typical Prorating Cases - Summary Cycle Shortened at First occurrence Fee event scheduled At the beginning of the cycle Intermediate Occurrence Last Occurrence
see figure 244
see figure 246
see figure 248
At the end of the cycle
see figure 245
see figure 247
see figure 249
11 September 2009
Page 511 of 968
Cycle
Cycle
Cycle
First Recurring Charge: prorated
Recurring Charge
Recurring Charge
Recurring Charge
Figure 244 - Prorata at first occurrence, charge in advance of the cycle

Cycle
Cycle
Cycle
First Recurring Charge: prorated
Recurring Charge
Recurring Charge
Figure 245 - Prorata at first occurrence, charge in arrears of the cycle
Page 512 of 968
11 September 2009
Truncated Cycle
Cycle
Cycle
Cycle
Recurring Charge
Recurring Charge
Intermediate Recurring Charge: prorated
Recurring Charge
Recurring Charge
Figure 246 - Prorata at intermediate occurrence, charge in advance of the cycle

Truncated Cycle
Cycle
Cycle
Cycle
Recurring Charge
Recurring Charge
Intermediate Recurring Charge: prorated
Recurring Charge
Figure 247 - Prorata at intermediate occurrence, charge in arrears of the cycle
11 September 2009
Page 513 of 968
Interruption Date of the non-usage Service Offer
Truncated Cycle
Cycle
Cycle
Cycle
Recurring Charge
Recurring Charge
Recurring Charge
REFUND PRORATED CHARGE
Figure 248 - Prorata at last occurrence, charge in advance of the cycle
Truncated Cycle
Cycle
Cycle
Cycle
Recurring Charge
Recurring Charge
Non-Scheduled Charge: prorated
Figure 249 - Prorata at last occurrence, charge in arrears of the cycle
14.4.5. Enabling the Prorata

For enabling the prorata on a Scheduled Event at the various potential cycle truncations, the Service Offer Definition defining the scheduled event must fulfill some configuration requirements. Five parameters are involved in the enabling of the prorata: The Non-usage Event covers the Period, defining if the scheduled event occurs in advance or in arrears of the covered period; Prorata flag, enabling prorata; at First and Immediate Occurrence flag, defining the moments where prorata is allowed; at Last Occurrence flag defining the moments where prorata is allowed;
Page 514 of 968
11 September 2009
Interruption Date of the non-usage Service Offer
Allow Refunds flag, enabling the refund functionality.

1.
See Service Offer Definition - Recurrence Info tab, on page 241. When synchronization shortens a cycle If the related Prorata flag is enabled: the Fee will be prorated. If the related Prorata flag is disabled: the user pays the complete fee, as if the period were complete. 2. At Subscription Cancellation If Fee paid in Advance: If the Refund flag is enabled: the Fee will be prorated and the over-paid portion will be refunded. The status of the Prorata flag doesnt matter in this case. If the Refund flag is disabled: no prorating nor refund will be done. The status of the Prorata flag doesnt matter in this case. If Fee paid in Arrears: If the Last Occurrence Prorata flag is enabled: the Fee will be prorated. If the Last Occurrence Prorata flag is disabled: the user pays the complete fee, as if the period were complete. 3. At Subscription Suspension If Fee paid in Advance: No prorating will be done, since the Refund is not allowed at suspension. The status of the Prorata flag and the Refund flag dont matter in this case. If Fee paid in Arrears: If the related Prorata flag is enabled: the Fee will be prorated. If the related Prorata flag is disabled: the user pays the complete fee, as if the period were complete. 4. At Subscription Re-activation If Synchronization is performed or if the Recurrence Pattern is not defined as a pure interval (see 14.2.2, Cases of Refused Synchronization, on page 506): If the First and Intermediate Occurrence Prorata flag is enabled: the Fee will be prorated. If the First and Intermediate Occurrence Prorata flag is disabled: the user pays the complete fee, as if the period were complete. If no synchronization is required and the Recurrence Pattern is a pure interval: Prorating is not an issue. The new cycle that starts will be a regular one. 5. At any Refund operation Refunded fees are always prorated. The status of the Prorata flags dont matter in this case. For more details, see 14.3.1, Prorata implied by the Refund, on page 508.
11 September 2009
Page 515 of 968
Part V. Rating Engine
Page 516 of 968
11 September 2009
15. Rating Paradigm

15.1. Ratable Unit Metric object
A Ratable Unit Metric (RUM) specifies the unit of the quantity slices processed by the Convergent Rating Engine for a particular Network Event Type. An event can be rated with up to three concomitant RUMs, of which the quantity costs are eventually cumulated, as configured in the Tariff object.
Figure 250 - Ratable Unit Metric GUI
Table 191 - Ratable Unit Metric - rum Parameter Service Retailer*

servret
Description Reference to the Service Retailer defining the current Ratable Unit Metric.
RUM Name*
name
Name of the current Ratable Unit Metric. The RUM Name is referenced in the Tariff object.
11 September 2009
Page 517 of 968
Rating Paradigm
Table 191 - Ratable Unit Metric - rum Parameter Type*

c_kind
Description Global Type of the current RUM (not to be confused with the RUM Unit). Money (c_kind = 0) Volume (byte) (c_kind = 1) Time (s) (c_kind = 2) Unit (c_kind = 3) This parameter is used for several purposes: 1) For the Notifications The RUM Type information is used for adapting the format of the notification messages (e.g. a credit notification about the Bundles). 2) For determining the lifetime of the reservation A given reservation has a limited validity period, called its lifetime. If the lifetime has elapsed without the reserved quantities to be used, these quantities are no longer blocked; they are released for being available to other reservation requests. Usually, the reservation lifetime is specified in the reservation request sent by the RTx (parameter bill_qty.lifetime). However, if it is not provided, the Convergent Rating Engine sets the reservation lifetime as follows: If the RUM Type is Time lifetime = reserved quantities + default lifetime set for the Network Event Type. If the RUM Type is not Time lifetime = default lifetime set in the Network Event Type.
For more information about the default reservation lifetime, see parameter
Default Reservation Lifetime, page 222.
RUM Unit*
unit
Unit in which the current RUM is counted. For instance: seconds, kilobytes, SMSs,... Internal row ID of the current RUM. This is a display-only parameter; the operator cannot set it. Default quantity to be reserved for events to be rated in the current RUM. This setting is used only if the RTx doesnt provide the quantity to reserve. Free text field for description and comments about the current RUM.
RUM ID
rum_typ
Default Reserved Quantity*

def_qty
Description
rum_desc
Page 518 of 968
11 September 2009
15.2. Tariff object

The Tariff holds the rating and charging curve parameters. The output of a Rating Rule is always a Tariff, according to which the Rating Engine performs the appropriate balance update for a given event to be charged. The various RUMs (up to 3 at the same time), curve segments (up to 5), application modes and configuration options allow the Service Retailer to define a very flexible rating of any event.
Figure 251 - Tariff GUI
Table 192 - Tariff - pricetab Parameter Service Retailer*

servret
Description Reference to the Service Retailer defining the current Tariff.
11 September 2009
Page 519 of 968
Rating Paradigm
Table 192 - Tariff - pricetab Parameter Tariff Name

name
Description Name of the current Tariff.
Version
version
Name of the Version of the current Tariff.
Start Date
vstartd
Date at which the Version as mentioned above for the current Tariff reaches the status defined below. Versioning Status that the current Tariff Version reaches at the Start Date. Before that date, the current Version remains in its previous Status. After that date, the current Version holds the current Status until no other Status has started.
Status
vstatus
VAT Flag*
vat_flg
This flag indicates whether the VAT is included in the current Tariff (and thus in the curve representing it). VAT Included
The Tariff includes the VAT. This is typically the case for the prepaid services. VAT Not Included The Tariff doesnt include the VAT. This type rating is rather applied to postpaid services. General Ledger Code
gl_code
Reference to the General Ledger Code to which the accounting ticket for any charging based on the current Tariff has to be directed.
VAT Rate
vat_rate
Reference to the General Ledger Code to which the accounting ticket for the VAT part of any charging based on the current Tariff has to be directed. The Rating Mode flag indicates how the current Tariff is applied. There are 4 possible modes, declined according to 2 alternatives: 1. Tapered Mode Vs. Tiered Mode related to how the Tariff segments are taken into account.
Rating Mode*
rat_mode
Fore more details, see section 15.2.3.1, "Tapered Vs. Tiered", on page 528.
2. Mode A Vs. Mode B related to how the Tariff curve is taken into account when switching from the Bundle to the balance.
For more details, see section 15.2.3.2, "Mode A Vs. Mode B", on page 529.
Page 520 of 968
11 September 2009
Table 192 - Tariff - pricetab Parameter Tariff Origin*

cxcstflg
Description This flag indicates if the Connection Cost of the current Tariff should be applied in case of event in which the used quantities = 0 (zero). Force zero Value The Connection Cost of the current Tariff wont be applied if the used quantities = 0. Apply Connection Cost The Connection Cost of the current Tariff will be applied, even if the used quantities = 0.
When are the used quantities equal to zero?
The case of an event for which zero quantities have been used could correspond to aborted events, for which the connection didnt actually occur. In that case, the Convergent Rating Engine isnt supposed to be triggered at all. So the case of an identified Tariff for which the used quantities = 0 (zero), rather refers to the situation in which a Tariff switch occurred for a given event, typically because a Bundle has been emptied. Even if eventually no quantities will be rated according to the new Tariff identified, it is possible to apply the Connection Cost of that new Tariff.
Vertical Axis*
rat_type
This parameter indicates the type of value represented on the vertical axis of the current Tariff. The horizontal axis always represents quantities. Cost The vertical axis represents a cost for the quantities used (represented on the horizontal axis). A cost is a money value. This Tariff defines a quantity-to-cost translation; so it only applies to rating and charging on the balance or on a money Bundle. Quantity The vertical axis represents the quantities rated for the quantities used (represented on the horizontal axis). The quantities rated are not necessarily of the same RUM as the used quantities. This Tariff defines a quantity-to-quantity translation; so it only applies to rating and charging on a quantity Bundle.
11 September 2009
Page 521 of 968
Rating Paradigm
Table 192 - Tariff - pricetab Parameter Display Tariff Chart without Ticks Description This flag allows selecting the type of display of the current Tariff chart, with or without the Ticks.
Tariff displayed with the Ticks
Tariff displayed without the Ticks
Page 522 of 968
11 September 2009
Figure 252 - Tariff GUI - RUM 1 tab
Table 193 - Tariff - RUM 1 tab Parameter RUM (1)*

rum_nam0
Description Reference to the Ratable Unit Metric specifying the unit of the quantities used for the current event - and hence rated thanks to the current Tariff. These quantities are represented on the horizontal axis of the curve. IMPORTANT If you use a Time criterion or Date criterion in a tree and tariff switching is permitted, it is recommended that RUM1 should be of type Time (in order to calculate correctly the time band for which the tariff switch will occur). If you want to reserve any kind of quantities instead of time, you should put time in RUM1 (tariff curve will be set to 0 and the time will only be used to compute the tariff switch) and quantities in RUM2 (and RUM2). If you do not use Time criterion or you do not allow tariff switch, it is possible to use RUM1 to reserve quantities.
11 September 2009
Page 523 of 968
Rating Paradigm
Table 193 - Tariff - RUM 1 tab (continued) Parameter Tariff Type*

trf_typ0
Description Global type of Tariff curve for the current RUM of the Tariff. This parameter sets some GUI constraints (by disabling useless fields), but its value can also be used by the RTx and by the Statistics Service of the OSP, via the statistical ticket sent by the Convergent Rating Engine. Normal The current RUM of the Tariff defines a normal quantity-to-cost or quantity-to-quantity translation, over up to 5 segments. Free The current RUM of the Tariff defines a free cost. Consequently, the Tariff chart will display a flat null curve and all the parameters will automatically be set to zero. Fixed Rate The current RUM of the Tariff defines a regular quantity-to-cost or quantity-to-quantity translation rule. In other words, the Tariff curve is actually a straight line. So only one segment of the Tariff can be configured in the GUI. Fixed Cost
The current RUM of the Tariff defines a unique cost, applicable once per event. So only one cost can be configured; it is not related to any spent quantities and is applicable at connection. Connection Cost*
cnxcost0
Fixed cost charged at connection, whatever the duration of the event or the quantities eventually used for it. Fixed cost charged once the connection cost quantity has been used.
Delta Cost*
prdcost0
Connection Quantity*
cnx_qty0
Quantity to reserve at connection.
Connection Tick*
cnxtick0
The Tick is the smallest quantity on which the charging is based.
(1)Cost*
fstcost0
This is the amount (cost or quantity) charged per use, in the first segment of the tariff, of a quantity of RUMs that equals (1)Units.

(1)Units
fstunit0
These are the RUMs the current tab is about.
The cost of using a quantity of (1)Units RUMs in the first segment of the tariff is given by the value of (1)Cost* parameter.

These are the RUMs the current tab is about. Ratio (1)Cost* / (1)Units determines the slope of segment 1 of the Tariff curve.
Page 524 of 968
11 September 2009
Table 193 - Tariff - RUM 1 tab (continued) Parameter (1) Quantity*

fst_qty0
Description Quantity of the RUM to which this cost-to-quantity translation is applied.

This parameter determines the length of the Tariff curve segment.
(1) Tick*
fsttick0
Smallest quantity slice on which the cost-to-quantity is applied for the first segment. Example If the RUM is in seconds and the tick is 60, it means that the charging will be rounded to the upper 60-second slice. Even if only 48 seconds have been used, the cost will be computed on 60 seconds.
(2)Cost*
scdcost0
This is the amount (cost or quantity) charged per use, in the second segment of the tariff, of a quantity of RUMs that equals (2)Units.

(2)Units
scdunit0
The cost of using a quantity of (2)Units RUMs in the second segment of the tariff is given by the value of (2)Cost* parameter.

(2) Quantity*
scd_qty0
Quantity of the RUM to which this cost-to-quantity translation is applied.

(2) Tick*
scdtick0
Smallest quantity slice on which the cost-to-quantity is applied for the second segment. This is the amount (cost or quantity) charged per use, in the third segment of the tariff, of a quantity of RUMs that equals (3)Units.
(3)Cost*
thicost0

(3)Units
thiunit0
The cost of using a quantity of (3)Units RUMs in the third segment of the tariff is given by the value of (3)Cost* parameter.

(3) Quantity*
thi_qty0

(3) Tick*
thitick0
Smallest quantity slice on which the cost-to-quantity is applied for the third segment.
11 September 2009
Page 525 of 968
Rating Paradigm
Table 193 - Tariff - RUM 1 tab (continued) Parameter (4)Cost*

segcost0
Description This is the amount (cost or quantity) charged per use, in the fourth segment of the tariff, of a quantity of RUMs that equals (4)Units.

(4)Units
segunit0
The cost of using a quantity of (4)Units RUMs in the fourth segment of the tariff is given by the value of (4)Cost* parameter.

(4) Quantity*
seg_qty0

(4) Tick*
segtick0
Smallest quantity slice on which the cost-to-quantity is applied for the fourth segment. This is the amount (cost or quantity) charged per use, in the fifth segment of the tariff, of a quantity of RUMs that equals (5)Units.
(5)Cost*
foucost0

(5)Units
fouunit0
These are the RUMs the current tab is about. Ratio (5)Cost* / (5)Units determines the slope of segment 5of the Tariff curve.
The cost of using a quantity of (5)Units RUMs in the fifth segment of the tariff is given by the value of (5)Cost* parameter.

(5) Quantity*
Quantity of the RUM to which this cost-to-quantity translation is applied. This parameter determines the length of the last Tariff curve segment, which can be finite or infinite. How to fill in this parameter For an infinite Tariff curve: this parameter must be set to 0 (zero). For a finite Tariff curve: this parameter indicates the maximum number of quantities rated according to the fifth and last segment of the Tariff. With a finite Tariff curve, when the maximum is reached, the CRE can no longer rate the current event with that Tariff. See What happens when the limit is reached, on page 534.
For a detailed explanation and an illustrated example, see 15.2.5, Finite Tariff:
Limit Charge on a Balance or Bundle, on page 532.
(5) Tick*
foutick0
Smallest quantity slice on which the cost-to-quantity is applied for the fifth and last segment.
Page 526 of 968
11 September 2009
Figure 253 - Tariff GUI - RUM 2 tab The RUM 2 tab defines the rating curve parameters for the second RUM used in the current Tariff. Having more than one RUM in a Tariff is not mandatory.
For the description of the RUM 2 tabs parameter, please see Tariff - RUM 1 tab (Table 193 on page 523).
11 September 2009
Page 527 of 968
Rating Paradigm
Figure 254 - Tariff GUI - RUM 3 tab The RUM 3 tab defines the rating curve parameters for the third RUM used in the current Tariff. Having more than one RUM in a Tariff is not mandatory.
For the description of the RUM 3 tabs parameter, please see Tariff - RUM 1 tab (Table 193 on page 523).
15.2.3. Tariff Application Modes

15.2.3.1. Tapered Vs. Tiered
When a Tariff curve is composed or several different segments, there are two different ways of applying the quantity-to-cost translation: either each quantity used is rated according to the Tariff segment its located in (= Tiered Mode), So, for the following Voice Tariff (RUM = minute): - Minutes [1..5] = 2.00 EUR/minute - Minutes [6..10] = 1.50 EUR/minute - Minutes [11..20] = 1.00 EUR/minute Then, for a voice event of 17 minutes, the rating will be:
(5x2.00 EUR) + (5x1.50 EUR) + (7x1.00 EUR) = 24.50 EUR

or each quantity used is rated according to the Tariff segment of the last quantity used (= Tapered Mode).
Page 528 of 968
11 September 2009
So, for the same Voice Tariff (RUM = minute), for a voice event of 17 minutes, the rating will be:
17x1.00 EUR = 17.00 EUR
15.2.3.2. Mode A Vs. Mode B

If a Tariff Switch or Balance Switch or both occurs and the new Tariff identified defines a cost to be charged on the balance, there are two different ways of taking the new Tariff curve into account - Mode A and Mode B. Balance/tariff switch includes all the following cases: Change from one bundle to another bundle Change from bundle to main balance or vice versa Tariff change due to finite tariff, even for the same balance Tariff change due to Time tariff switch, even for the same balance Tariff/Balance change due to re-eval requirement from a mediation soft counter threshold
Note 1: However, the above rule would be overriden in case of fixed cost tariff. For the fixed cost tariff definition that "Same Name of tariff can not be used to apply Fixed Cost, again in the same call", holds true for mode B & mode B2 in CRE 262. Note 2: CRE 262 also supports Virtual Mode A. It indicates that effectively Mode A will act, although the tariff is configured in Mode B or B2 on the condition that even after Tariff switch, the combination of Bundle/ Balance Tariff has not changed. That means, instead of starting from origin in the new tariff, the New Tariff applies from the point on the horizontal axis corresponding to the last unit charged on the Bundle/ Balance, which in behavior is same as Mode A (For details about Mode A, B or B2, refer the section below). Virtual Mode A applies when following conditions are met: 1. 2. 3. 4. 5. VMODE arena is non-zero AND Current tariff is same as Previous tariff AND Current Balance/Bundle is same as Previous Balance/Bundle AND Tariff type is either MODE B or B2 AND Tariff configured is not finite(Scope)
If all the above conditions are not met, then Mode B/B2 (which ever is configured in the tariff) will be executed.
11 September 2009
Page 529 of 968
Rating Paradigm
Figure 255 - Example- Virtual Mode A In the above example, if the tariff switch takes place and all the conditions (mentioned in the above section) are met, then although the new tariff might be in Mode B/B2 but effectively this tariff switch will behave as if it is a Mode A tariff. This is called Virtual Mode A. The tariff switch can be effective because of the criteria like: Date criterion Time criterion with explicit time Re-eval requirement from mediation Soft counter threshold
Bundle Criteria LiteSCE criteria The above list is only indicative. The behavior applies to all Tariff switches. Mode A New Tariff applies from the point on the horizontal axis corresponding to the last unit charged on the Bundle, (= Mode A) so, if 30 seconds have previously been taken on the Bundle, the Tariff curve applying to the balance is taken into account from the 31st second onwards. This implies that the Connection Cost of the Tariff is skipped. Mode B New Tariff applies from the origin (point zero of the horizontal axis), (= Mode B) so, as if the quantities rated were the first of the event. This implies that the Connection Cost of the Tariff is applied as well. However, when neither Balance nor Tariff changes after switch, virtual mode A or Mode applies B as per arena value configured <<VMODE>>. Refer the note below. Mode B2 Mode B2 is a variant of Mode B, with the restriction that connection cost is applied only once in the entire call. Connection cost configured in the first tariff used in the call is only charged. This mode is activated by using an arena variable. (The implementation is same as Mode B in CRE 261). <<RMODE>>. However, when neither Balance nor Tariff changes after switch, virtual mode A or Mode applies B as per arena value configured (See Note 2). Note: The arena variable, VMODE and RMODE(of type Integer) created at the service retailer level indicates the mode which is activated. VMODE=1, Virtual mode is activated VMODE=0 and RMODE =0, Mode B is activated VMODE=0 and RMODE=1, Mode B2 is activated
Page 530 of 968
11 September 2009
Example
The first 4 minutes of a voice call have been charged on Bundle, which has been emptied. A Tariff Switch occurs then, identifying the Tariff curve below. This Tariff will be used for rating and charging the next 6 minutes on the Accounts balance.
Cost
1.30 1.20 1.10 1.00 0.90 0.80 0.70 0.60 0.50 0.40 0.30 0.20 0.10
Cost of the minutes [5 to 10] in Mode A = 0.30
10
11
12
Quantities
(minutes)
Figure 256 - Tariff Application Mode A
Cost
1.30 1.20 1.10 1.00 0.90 0.80 0.70 0.60 0.50 0.40 0.30 0.20 0.10 0 1 2 3 4 5 6
Cost of the minutes [5 to 10] in Mode B = 1.15
10
11
12
Quantities
(minutes)
Figure 257 - Tariff Application Mode B
11 September 2009
Page 531 of 968
Rating Paradigm
15.2.4. Tip: Choosing a Cost/Units Ratio for a Tariff Segment

When choosing a value for Cost* and for Units parameters of a tariff segment (e.g., when choosing a value for (2)Cost* and for (2)Units* parameters of segment 2 of a tariff), make sure that the Cost/ Units ratio (e.g., (2)Cost* parameter value divided by (2)Units* parameter value) for the segment is as this section explains. In Reservation / commit charging mode, the cost of a given quantity slice to commit is computed as follows: 1. The tariff is first computed on all the quantities consumed since, and including, the first charging slice. Thus, the quantity slice to commit is included in the considered quantities. Let us call Tall consumed quantities the result of this computation. 2. The tariff is then computed on all the quantities committed since the first slice. Thus, the quantity slice to commit is not included in the considered quantities. Let us call Tall committed quantities the result of this computation. 3. The cost of the quantity slice is then computed, as follows: Cost = Tall consumed quantities - Tall committed quantities This formula generalizes to the other charging modes. Simply, these charging modes have no slices. Or, said in another way, they have only one slice, which means that the above formula still applies, with Tall committed quantities set to zero. Because the cost is computed as a subtraction, its important you make sure that the left operand of the subtraction is always greater than, or equal to, zero. Otherwise you will have negative costs. When the used tariff is working in Tapped Mode, this implies that the Cost/Units ratio of a segment has to be strictly greater than, or equal to, the Cost/Units ratio of the previous one. When the used tariff is working in Tiered Mode, this implies that the Cost/Units ratio of any segment has to be greater than, or equal to, zero.
15.2.5. Finite Tariff: Limit Charge on a Balance or Bundle

It is possible to limit the number of quantities rated by a given Tariff. A Tariff curve is composed of five segments. The segments 1 to 4 each rate a given number of RUM quantities. The difference can lie in the fifth and last segment. In an infinite Tariff: the fifth segment can rate an unlimited number of RUM quantities. In a finite Tariff: the fifth segment can only rate a maximum number of RUM quantities. With a finite Tariff, when the quantities of segments 1, 2, 3, 4 and 5 have all been rated, the event is no longer rated with this Tariff.
Page 532 of 968
11 September 2009
15.2.5.1. Defining the Scope of a Tariff

As opposed to a infinite Tariff, a finite Tariffs fifth segment only rates a limited number of quantities.
In the Quantity of the 5th segment, you set the maximum number of quantities to be rated by the 5th segment of the Tariff. For an infinite Tariff, this value is set to 0 (zero), which means that the 5th segment can rate any number of quantities.
If the value of the (5) Qty field is greater than zero, then the Tariff can be used for rating and charging at most Q RUM quantities. Q = Connection Quantity + (1) Qty +(2) Qty + (3) Qty + (4) Qty + (5) Qty We call Q the scope of the Tariff. The three RUMs of the Tariff can each have their own scope.
See also parameter (5) Quantity*, page 526.
Maximum on quantities, not on cost

By designing a Tariff with a finite scope, you dont set a maximum cost for a given event. On the Tariff curve, the maximum is set on the x-axis (quantities), not on the y-axis (cost).
11 September 2009
Page 533 of 968
Rating Paradigm
y-axis (cost, i.e. quantities taken out of the Bundle
De facto maximum cost = 60 End of the Tariff Curve
x-axis (quantities)
100+100+60+60+80 = 400
= Maximum number of rated quantities
1st
segment (100)
2nd
segment (100)
3rd
seg. (60)
4th
5th
seg. segment (60) (80)
Of course, it is possible to compute the maximum total cost: it is the cost of the maximum rated quantities. So there is indeed a total cost limit, but it is not expressed in terms of cost. In fact, you indirectly set a cost limit. In the above example, the scope of the Tariff is 400. The total cost for those 400 RUM quantities is 60 Bundle units. 60 is then the maximum cost for an event rated and charged with this Tariff.
15.2.5.2. What happens when the limit is reached

When the CRE uses a finite Tariff to rate an event, and the event contains more quantities than the scope of the Tariff allows to rate, the CRE, inside the Usage Rating Rule, attempts to find another Tariff for rating the remainder of the event. There are two possible cases: Case A: the finite Tariff applies to a Bundle, so an ELSE branch of a Bundle Criterion can be taken. Case B: the finite Tariff applies to the Main Balance, so no more ELSE branch can be logically taken in the tree. With the Rating Rule shown below, a Voice event can be charged on up to 4 balances of the Account, using each time a finite Tariff: Step 1: The Voice event is first charged on the Voice Bundle. Step 2: When the scope of the Voice Bundles Tariff is reached, the ELSE branch of the Bundle Criterion is taken, and a Promotion Bundle is found.
Page 534 of 968
11 September 2009
Step 3: When the scope of the Promotion Bundles Tariff is reached, the ELSE branch of the Bundle Criterion is taken, and a Money Bundle is found. Step 4: When the scope of the Money Bundles Tariff is reached, the last ELSE branch of the Bundle Criterion is taken, so the event is now charged on the Main Balance. Step 5: When the scope of the Main Balances Tariff is reached, there is no more ELSE branch to be taken in the Usage Rating Rule. As a consequence, there is no more Tariff for rating and charging the remainder of the Voice event.
Step 1 Case A: the CRE takes the ELSE branch of the Bundle Criterion. Case A
Step 2
Step 3
Step 4
Case A
Step 5 Case B: the Tariff cannot be used anymore, but there is not more ELSE branch to be taken. The cost beyond the Main Balances Tariff scope is From the example above, you understand that a finite Tariff applying to the Main Balance (Case B) should be used very cautiously. Indeed, the Usage Rating Rule doesnt allow to fall back on another Tariff after the Main Balance Tariff. Concretely, what happens? If the event exceeds the scope of the Main Balance Tariff, no other Tariff can be found, so the remainder of the event cannot be rated anymore. The remainder of the event has hence no cost, and is not charged. Conceptually, it is not defined as free. Nevertheless, the operational result is the same! Since this is the standard CRE behavior, the CRE wont send any alarm and wont stop the event.
How to avoid endless free events to go on beyond a finite Tariffs scope?

Typically, you will want to avoid the case B described above, and configure your CRE accordingly, which means: Either you dont use a finite Tariff applying to the Main Balance - you only use it on Bundles, so that you can always fall back on the Main Balance for the remainder of the event. Or you use the reservation-based rating and charging. Indeed, the reservation wont allow more quantities than the maximum scope of the Tariff, so that there will never be quantities to rate over the end of the fifth segment.
11 September 2009
Page 535 of 968
Rating Paradigm
15.2.5.3. In Tapered mode, the scope of the Tariff applies per slice
Keep in mind that a network event performed by an end-user can correspond, at the CRE level, to several triggers. When the RTx triggers the CRE with reservation requests, the CRE first rates the RUM quantity asked for reservation and blocks the corresponding cost on the users Account. A second RTx request asks the CRE to commit the cost of the reserved quantities - now used - and to reserve another pack of RUM quantities. So the single event performed by the end-user is actually divided, from the CRE standpoint, into so-called slices. There are two ways of rating and charging the slices of an event: Each slice of the network event is processed separately. The n slices of the event are each rated and charged independently. This way of applying a Tariff is called the Tapered Mode. In Tapered mode, the scope of the Tariff applies to each slice of the global event. The n slices of the network event are considered as a whole. All slices sum up for making one event to be rated and charged. This way of applying a Tariff is called the Tiered Mode. In Tiered mode, the scope of the Tariff applies to the global event, whatever the number of slices.
Read more in 15.2.3.1, Tapered Vs. Tiered, on page 528.
Effect on the Reservation Process

While an infinite Tariff can virtually rate and then authorize a reservation for any number of quantities, the reservation triggering a finite Tariff will never exceed the scope of the Tariff. As a consequence,
In Tapered mode: the length of the slice reserved will never be longer/greater than the scope of the Tariff. In Tiered mode: the length of the global event will never be longer/greater than the scope of the Tariff. For instance, a Tapered finite Tariff rating a maximum of 20 minutes will only allow reservation up to 20 minutes. A Voice call charged via the reservation/commit mechanism of the CRE will be split into slices of maximum 20 minutes. If the RTx requests a reservation for 30 minutes, the CRE will only allow and reserve 20. A Tiered finite Tariff rating a maximum of 20 minutes will allow reservation and commit up to a total of 20 minutes, cumulating all slices. A Voice call charged via the reservation/commit mechanism of the CRE will be rated and charged for a maximum cumulated duration of 20 minutes, whatever the number of slices in it.
Page 536 of 968
11 September 2009
No reservation possible beyond the
Scope of the Tariff
In Tiered Mode, the scope of the Tariff applies to the whole event, so the voice call will be rated and charged for a duration of maximum 20 minutes.
Summary
Table 194 - Tariff Scope Application: Tapered Vs. Tiered Modes
Mode Tapered Tiered
Scope applicable to each slice the whole event (sum of all slices)
Maximum Length of each Slice = Scope of the Tariff = Scope of the Tariff sum of quantities already committed for the previous slices
Maximum Length of the Global Event None (as many slices as requested by the RTx) = Scope of the Tariff
15.2.5.4. Example
Take a usual Tariff, infinite: it can rate any number of quantities. The cost charged by means of this Tariffs quantity-to-cost translation is virtually unlimited.
11 September 2009
Page 537 of 968
Rating Paradigm
185 units
70 units
The Tariff is infinite. Its scope is unlimited, since the 5th segment can rate any number of quantities.
minutes
15
minutes
70
As a consequence, a voice call of 15 minutes will cost 70 units (10x5+5x4) a voice call of 70 minutes will cost 185 units (10x5+10x4+15x3+15x2+20x1) a voice call of 150 minute will cost 265 units (10x5+10x4+15x3+15x2+100x1) Now if we want to limit the number of units taken out of the Voice Bundle per Voice call, we can modify the initial Tariff to make it finite. To do so, we just have to modify the Quantity field of the fifth segment. If we set the length of the fifth segment to 25, the Tariff will now only rate up to 75 quantities (for a maximal cumulated cost of 190 Bundle units).
Page 538 of 968
11 September 2009
With
the Tariff shown above, a voice call will be rated as follows: first 10 minutes = 50 units of the Voice Bundle next 10 minutes = 40 units of the Voice Bundle next 15 minutes = 45 units of the Voice Bundle next 15 minutes = 30 units of the Voice Bundle next minutes: 1 unit of the Voice Bundle per minute
1 2 3 4
With
the Tariff shown above, a voice call will be rated as follows: first 10 minutes = 50 units of the Voice Bundle next 10 minutes = 40 units of the Voice Bundle next 15 minutes = 45 units of the Voice Bundle next 15 minutes = 30 units of the Voice Bundle next 25 minutes = 25 units of the Voice Bundle next minutes: cant be rated with this Tariff, which only rates up to 75 quantities (here, minutes).
Since this Tariff charges on a Bundle, it is located in the OK branch of a Bundle Criterion. In our Usage Rating Rule, the ELSE branch of the Bundle Criterion charges on the Main Balance.
When the quantities of the voice call exceed 75, quantities over 75 cannot be rated by the Tariff_VoiceBundle_finite. So the minutes over 75 are rated by another Tariff: the one in the ELSE branch of the Bundle Criterion, where the Tariff_MainBalance is found, translating quantities into a cost to be charged on the Main Balance.
11 September 2009
Page 539 of 968
Rating Paradigm
Here is the Tariff charging on the Main Balance when the maximum units rated and charged on the Voice Bundle have been reached.
7,5 Euros
minutes
75
As a consequence, a voice call of 15 minutes will cost 70 units (10x5+5x4) a voice call of 70 minutes will cost 185 units (10x5+10x4+15x3+15x2+20x1) a voice call of 150 minutes will cost 190 units (10x5+10x4+15x3+15x2+25x1), for the first 75 minutes, + 7,5 EUR for the next 75 minutes (75x0,1 EUR).
15.3. General Ledger Code object

General Ledger Codes are used in order to differentiate various accounting operations and rubrics. In the Convergent Rating Engine, General Ledger Codes are referenced by the Tariff object, for indicating on what accounting rubric the charged amounts have to be reported.
Analogy
General Ledger Codes can be compared to the column headers in accountancy books. Thus any piece of information that is potentially interesting for financial analysis and/or billing needs to be assigned a specific Ledger Code, so that it can be retrieved and processed specifically.
Page 540 of 968
11 September 2009
Figure 258 - General Ledger Code GUI
Table 195 - General Ledger Code - gl_code Parameter

Description Reference to the Service Retailer defining the current General Ledger Code.
Service Retailer*
aservret
General Ledger Code*

gl_code
Numeric code corresponding to a specific accounting rubric (also known as general ledger code).
VAT Management
tva_flg
This parameter indicates whether the current General Ledger Code is involved in VAT management. None The current General Ledger Code indicates no VAT assignment, but just a cost. VAT Rate The current General Ledger Code indicates a VAT assignment, using a rate expressed in percentage. VAT Amount The current General Ledger Code indicates a VAT assignment, using a fixed amount expressed in currency value.
Remark
The VAT management functionality in the General Ledger Code is actually not restricted to VAT. It can be used to register any other tax or additional amount based on a rate or on a fixed value.
11 September 2009
Page 541 of 968
Rating Paradigm
Table 195 - General Ledger Code - gl_code Parameter General Ledger Code Name*
glc_name
Description Name of the current General Ledger Code.
VAT Rate (%)

tva_rate
When the VAT Management flag is set to VAT Rate:
VAT Rate, expressed in percentage.

When the VAT Management flag is set to VAT Amount:
VAT Amount
tva_val
Fixed VAT amount, expressed in currency value. Free text field for description and comments about the current General Ledger Code.
Description
gl_desc
Page 542 of 968
11 September 2009
16. Zoning Management
In a Nutshell... The Zoning Management Framework allows the network provider to determine the guiding, rating and charging of events according to the place where the caller and/or the called are located when the event is performed. Far beyond the notion of geographical zoning, it offers a string-based zoning definition up to the level of any network identifier.
Moreover, the network provider can differentiate the definition of zones per element of the Product Catalog, bringing even more flexibility to the Product Catalog Management.
16.1. Main Features

The Zoning Management framework of the Convergent Rating Engine is a set of static settings describing the zoning-related features that are relevant for the Service Retailer.
16.1.1. Purpose: Making Decisions based on Zoning features

You use the Zoning Management framework to set up your own zoning policy. That is, you use the framework to specify how the zoning information carried by a processed event affects the processing of the event. Using the framework consists in: Specifying to the CRE the zoning information it needs in order to make its zoning related processing decisions. You do that by creating the necessary instances of the various objects that the framework offers: AREA, AREA IDENTIFIER, AREA IDENTIFIER TYPE, ZONE, MATRIX COMPONENT and MATRIX objects. Setting up, as necessary, zoning criteria in the decision trees that have to make processing decisions based on zoning information found in the events they process. As a result, any zoning based processing decision is made by decision trees.
11 September 2009
Page 543 of 968
Zoning Management
The following zoning criteria are available: ORIGIN, DESTINATION, ORIGINATING ZONE, DESTINATION ZONE and MATRIX COMPONENT.
16.1.1.1. Simple Areas versus Super Areas

With the Zoning Management framework, you can define two types of region: Simple Areas and Super Areas. Note: Whatever the type of these regions, they are defined as instances of AREA object. This section introduces you to two types of region: A Simple Area is a region that is made up of one or more area identifiers. Upon reception of an event from the RTx, the Zoning Management framework attempts to match the origin (the destination) of the event onto area identifiers in order to know to which Simple Area the origin (the destination) belongs. A Simple Area is an instance of AREA object that is referred to by one or more Area Identifiers (i.e., instances of AREA IDENTIFIER object). A Simple Area is therefore made up of all the Area Identifiers that refer to the Simple Area. Note: An instance of AREA object is referred to by an instance of AREA IDENTIFIER object if, and only if, Area* parameter of the latter instance is set to the value of Name* parameter of the instance of AREA object. Unlike Super Areas, a Simple Area is always taken into account by the CRE, thus whatever the Service Offer and the Service Offer Group that applies to the event being processed. To define a Simple Area, you use AREA object, AREA IDENTIFIER object and, possibly, AREA IDENTIFIER TYPE object. A Super Area is a region that is made up of Simple Areas. The inclusion of each of these Simple Areas into the Super Area is governed by some condition. The condition attached to a Simple Area of a Super Area indicates in which cases the Simple Area is considered to be part of the Super Area and in which cases the Simple Area is not. The condition that governs the membership of a Simple Area to a Super Area is made up of a Service Offer Group and/or a Service Offer. The condition works as follows: If the event being processed is about the Service Offer Group and/or the Service Offer that governs the membership of a Simple Area to a given Super Area, then the Simple Area is considered to be part of the Super Area at the time when the originating/destination Super Area of the event is looked for. Else, the Simple Area is not considered to be part of the Super area at the time when the originating/destination Super Area is looked for. To find out the Super Area to which the origin (destination) of the event being processed belongs, the Zoning Management framework uses the Simple Areas to which the origin (destination) of the event belong. You use ZONE object to indicate membership of a Simple Area to a given Super Area as well as to indicate under which condition (i.e., in the context of which Service Offer Group and/or Service Offer) the Simple Area is considered to be part of the Super Area. Its Zone (Super Area)* parameter of ZONE object that specifies the Super Area that an instance of Zone object is about. A Super Area is therefore an instance of AREA object that is referred to by Zone (Super Area)* parameter of one or more instances of ZONE object.
Page 544 of 968
11 September 2009
Note: Contrast this definition with that of a Simple Area, which states that a Simple Area is an instance of AREA object that is referred to by one or more instances of AREA IDENTIFIER object. To define a Super Area, you use AREA object and ZONE object.
16.1.1.2. When It Is Not Preceded by Word Super, Area Means Simple Area
Unless when explicitly stated otherwise in the text, any use of word Area that is not preceded by Super refers to a Simple Area.
16.1.1.3. The Two Possible Meanings of Zone Term

Depending on the context in which the text uses it, the word Zone has one of the two following meanings: It may mean the same as instance of ZONE object. Recall that an instance of ZONE object specifies the terms of membership of a given Simple Area to a Super Area. It may mean the same as Super Area. To the extent feasible, avoid using the term Zone with this meaning.
In the text, it is not always indicated in which sense the word Zone is used. When it is so, the context should normally help you determine in which sense the word is used. However, most of the time, the text uses Zone word to refer to instances of ZONE object.
16.1.1.4. The Zoning Criteria at a Glance

Any processing decision based on zoning information an event carries is made through the execution of a zoning criterion by a decision tree. The following zoning criteria are available: The ORIGIN Criterion. To have a decision tree make a decision that depends on whether the processed event originates from a given Area (i.e., a simple Area) or not, set up in the decision tree an ORIGIN criterion that refers to the Area. The DESTINATION Criterion. To have a decision tree make a decision that depends on whether the destination of the processed event is within a given Area (i.e., a simple Area) or not, set up in the decision tree a DESTINATION criterion that refers to the Area. The ORIGINATING ZONE criterion. To have a decision tree make a decision that depends on whether the event being processed originates from a given a Super Area or not, set up in the decision tree an ORIGINATING ZONE criterion that refers to the Zone. The DESTINATION ZONE criterion. To have a decision tree make a decision that depends on whether the destination of the event being processed is within a given a Super Area or not, set up in the decision tree a DESTINATION ZONE criterion that refers to the Zone.
11 September 2009
Page 545 of 968
Zoning Management
The MATRIX COMPONENT criterion. To have a decision tree make the same decision for a number of origin/destination Areas combinations, first set up a Matrix Component (i.e., an instance of MATRIX COMPONENT object) made up of these origin/destination combinations and set up afterwards in the decision tree a MATRIX COMPONENT criterion that refers to that Matrix Component. Its true that you can achieve the same result as this criterion by suitably combining several ORIGIN (or ORIGINATING ZONE) and DESTINATION (or DESTINATION ZONE) criteria. However, using the MATRIX COMPONENT criterion enables you to achieve that result by means of one single criterion instead of several. On top of this, adding an origin/destination combination to a Matrix Component immediately affects all the decision trees that use the Matrix Component, thus without having to edit these trees. Note: In an origin/destination Areas combination, both the origin and the destination must be of the same type. In other terms, if the combinations origin is an Area (i.e., a Simple Area), the combinations destination must be an Area (i.e., a Simple Area) and if the combinations origin is a Super Area, the combinations destination must be a Super Area. You define an origin/destination by creating an instance of MATRIX object that refers to the origin and to the destination. ORIGINATING ZONE and DESTINATION ZONE criteria are only available in Usage Rating Rules. On the other hand, the other criteria of the Zoning Management framework can be used in any of the following four kinds of decision trees: Service Rule Charging Rule
Rating Plan Rule Usage Rating Rule
For more info, see Origin Criterion, on page 445, Destination Criterion, on page 415, Originating Zone Criterion, on page 450, Destination Zone Criterion, on page 418 and Matrix Component Criterion, on page 467.
16.1.2. First Level of Flexibility of the Zoning

16.1.2.1. What this Level Is - Why this Level
The flexibility of the Zoning Management framework of the Convergent Rating Engine is first ensured at the Service Retailers level. Any Service Retailer (hereby called the current Service Retailer) can indeed re-use the Zoning settings of another Service Retailer, which is called the default Service Retailer.
On how you give a default Service Retailer to a given Service retailer, see parameter Default Service Retailer, page 142, which is a parameter of SERVICE RETAILER object.
Nevertheless, the current Service Retailer can always override Zoning settings of the default Service Retailer. In MVNO implementations of the Convergent Rating Engine, i.e. hosting several Service Retailers, the default Service Retailers zoning settings are typically re-used by all Service Retailers for the basic country-based zoning definition.
Page 546 of 968
11 September 2009
16.1.2.2. How You Can Take Advantage of this Level of Flexibility

16.1.2.2.1.The Criteria May Use the Zoning Settings of the Default Service Retailer
Each criterion that the Zoning Management framework offers has a number of parameters that refer to instances of the objects of the framework. For example, the MATRIX COMPONENT criterion has a parameter that refers to a Matrix Component, which is an instance of MATRIX COMPONENT object. As another example, the DESTINATION ZONE criterion has a parameter that refers to a Super Area, which is an instance of AREA object. You can set each of these parameters so that it refers to: Either an objects instance of the default Service Retailer (unless the instance is overriden by one of the current Service Retailer), Or an objects instance of the current Service Retailer. Note: This is reflected in the list that the HELP button to the right of these parameters displays: The list does not only mention instances from the current Service retailer but also mentions instances from the default Service Retailer (if the current Service Retailer has one). Of course, zoning settings set for the current Service Retailer are allowed to override those set for the default Service Retailer. To have the current Service retailer override a Zoning Management objects instance of the default Service retailer, you create an instance of the same object that has the same name as the instance to override.
In that case, any Zoning Management criterions parameter referring to the name refers to the instance of the current Service Retailer and not to the instance of the default Service Retailer. In line with this behavior, the name is mentioned only once in the list the HELP button to the right of the parameter displays.
16.1.2.2.2.A Zones Simple Area Can Be from the Default or the Current Service Retailer
Among all the parameters of all the objects of the Zoning Management framework, only Area* parameter of ZONE object is allowed to refer to a zoning setting of the default Service Retailer of the current Service retailer. As a result, a Super Area may be made up of simple Areas of the current Service retailer and/or of simple Areas the default Service Retailer.
16.1.2.2.3.Choosing a Name for the Instances of the Zoning Management Objects

If you want to avoid that the zoning settings of the current Service Retailer fortuitously override (whether partly or fully) zoning settings of the default Service Retailer, choose a different prefix (or, if you prefer to use suffixes, a different suffix) for each Service Retailer and make sure that each Zoning Management objects instance of each service Retailer has a name that starts with the prefix (or, if you preferred to use suffixes, that ends with the suffix) you chose for the Service Retailer. Note: Moreover, in HELP buttons lists (HELP buttons are these buttons that appear to the right of some parameters and which show a list of valid values for the parameter when they are clicked on), this will help you easily distinguish between names referring to object instances of the default Service retailer and those referring to object instances of the current Service Retailer.
11 September 2009
Page 547 of 968
Zoning Management
16.1.3. Second Level of Flexibility of the Zoning

The second level of flexibility of the Zoning is within the Product Catalog. A Service Retailer can also fine-tune the zoning settings by restricting them to a particular Service and/ or Service Offer Group. With such a Product Catalog-dependent zoning configuration, the Customers of the Service Retailer are applied different zoning settings according to either their portfolio or the Service that they trigger.
Differentiating the zoning settings per Service Offer Group: Example

The standard zoning configuration defines Areas, corresponding to the geographical continents: Europe, Middle-East, Asia, Africa, Northern America, etc. The Service Retailer wants to create a new offer in the Product Catalog: the Voice Europe Service Offer Group. Voice Europe offers preferential rates when calling a country member or candidate member of the European Union. Thus, for that Service Offer Group only, the Europe Area is defined differently: it includes Turkey, but doesnt include Switzerland, Norway, Iceland and other countries that, whereas located in continental Europe, are not EU members. So depending on the Service Offer Group that the calling Customer subscribed to, when the destination of the call is identified as Switzerland, it will be considered as belonging to the Zone Europe (for standard Service Offer Groups) or to the Zone Non-Europe (for Voice Europe Service Offer Group).
Learn how to configure such a use case thanks to the Zoning Management Framework: read Example of Provisioning, on page 570.
16.1.4. More than Geographical Zoning

The Convergent Rating Engines Zoning Management framework extends the notion of Area far beyond geographical zones or network coverage. Of course, the Zoning Management framework allows to define homogeneous regions, like you draw boundaries on a map. Typically, you can configure your Zoning settings in order to identify the country of the calling/called party, based on a prefix. This is the very minimum that you can do with the Zoning Management framework, but you can do much more. The Zoning Management framework generalizes the notion of Area to a set of network identifiers called Area Identifiers, which the common point of is to lead to a similar processing in the Convergent Rating Engine. This global functionality is ensured by a major capability of the Zoning Management Framework: the string-based definition and identification of the Areas. The definition and identification of the Areas are based on character strings, enabling the usage of usual prefixes and phone numbers, but also other identifiers like URLs, e-mail addresses, etc.
Non-geographical Zoning definition: Example

The Area Identifiers customer.support@myprovider.com, www.myprovider.com/mybill/, www.myprovider.com/myprofile/, 998877665544 (phone number of the regional sales department), and 00112233445566 (phone number of the hotline) belong to the Customer Service Area.
Page 548 of 968
11 September 2009
The Service Retailer can decide that the 10 first events whose destination matches one of these Area Identifiers are free of charge every month and that the next events are charged to the Customer. As you can see, the above definition of the Customer Service Area is not bound to the geographical or physical location of the Area Identifier. Indeed: the hotlines call center can be located abroad, the regional sales department can be located in the regional offices, while the web servers can be located at some hosting premises anywhere.
16.2. Implementation at a glance

When triggered with an event sent by the RTx, the Convergent Rating Engine receives the network identifiers of both the calling and the called parties, i.e. the origin and the destination. For each event, the Convergent Rating Engine attempts to map the origin and the destination to an Area. Indeed, in the Zoning Framework, Area Identifiers are linked to specific Areas. For any network identifier received, the Convergent Rating Engine searches for the Area Identifier configured that the network identifier best matches1. The corresponding Area is then found. When the origin Area and the destination Area are known, the Convergent Rating Engine also searches whether these two Areas match some Matrix (i.e., some instance of MATRIX object). A Matrix specifies an origin Area and a destination Area. In other terms, it specifies an origin/destination Areas combination. If an event corresponds to the same origin/destination Areas combination as a Matrix, then the event matches the Matrix.
A Matrix always belongs to one, and only one, Matrix Component (i.e., instance of MATRIX COMPONENT object). As a result, a Matrix Component is nothing else than a set of Matrices (i.e., a set of origin/ destination Area combinations). Matrix Components, along with Matrices (i.e., instances of MATRIX object), make it simpler to implement rating decisions that are common to a group of origin/destination Areas combinations.
Example
An operator wants to set up three types of pricing for the Voice service: national calls (internal to the country), calls to a country that has a border with the country from which the call is originated, and calls to other european countries. In the example table below, an origin Area and a destination Area has been created for each country. Each cell in the table thus corresponds to a given origin/destination Areas combination and has been assigned one of the following types of origin-destination Areas combination: National, Border, and Europe. For each type of origin-destination Areas combination, you will set up a Matrix Component (i.e., an instance of MATRIX COMPONENT object) that has the same name as the type. Thus, you will create three Matrix Components: One called National, another one called Border and a third one called Europe. For each cell (i.e., each origin/destination Area combination in the table), you will set up a Matrix (i.e., an instance of MATRIX object) that specifies the same origin Area and the same destination Area as the cell (i.e., as the combination) and you will make the Matrix belong to the Matrix Component whose name is the same as the type that is written in the cell.
1. Various match algorithms can actually be used. See 16.6.3, Area Identification Match Algorithms, on page 583.
11 September 2009
Page 549 of 968
Zoning Management
So all calls corresponding to the Border type of zoning will lead to the same processing if a Matrix Component Criterion, referring to Border Matrix Component, is encountered in a decision tree, whether it is Portugal/Spain, or France/Germany, or Switzerland/France, etc. Table 196 - Which Origin/Destination Combination Is Part of Which Matrix Component Destination Areas Switzerland Germany
Origin Areas
France Belgium UK Spain Germany Switzerland Portugal
National Border Europe Border Border Border Europe
Border National Europe Europe Border Europe Europe
Europe Europe National Europe Europe Europe Europe
Border Europe Europe National Europe Europe Border
Border Border Europe Europe National Border Europe
Border Europe Europe Europe Border National Europe
Europe Europe Europe Border Europe Europe National
16.2.1. The Three Levels of Zoning Configuration

The Zoning Management Framework can be configured and used at three different levels of complexity.
Level 0: No Explicit Zoning Configuration

You dont define anything in your Convergent Rating Engines Zoning Management Framework. You inherit from the default Service Retailers Zoning settings. You can use them in the decision trees via the five available criteria: ORIGIN, DESTINATION, ORIGINATING ZONE, DESTINATION ZONE and MATRIX COMPONENT criteria.
Level 1: Basic Zoning Configuration

You define Areas (simple Areas) valid for the Service Retailer owning the Product Catalog. These zoning settings have the priority over the settings of the default Service Retailer. With these Service Retailer-specific settings, you can use the ORIGIN and DESTINATION criteria.
The relative priority of the Default and current Service Retailers settings is explained in 16.6.1, Default Service Retailer, on page 579 and in 16.6.2, Zoning Parameters Identification Logic, on page 580.
Level 2: Defining Origin-Destination Combinations Using MATRIX Object
Page 550 of 968
11 September 2009
According to the above table, the Matrix (i.e., the instance of MATRIX object) whose Originating Area* parameter is set to France and whose Destination Area* parameter is set to Belgium must belong to Border Matrix Component. The same is true for the Matrix (i.e., instance of MATRIX object) whose Originating Area* parameter is set to Spain and whose Destination Area* parameter is set to Portugal.
Portugal
Belgium
France
Spain
UK
You create Matrices (instances of MATRIX object) and Matrix Components (i.e., instances of MATRIX COMPONENT object). That is, you specify origin/destination combinations (i.e., Matrices) and you group them into Matrix Components. You can use the ORIGIN, the DESTINATION and the MATRIX COMPONENT criteria.
Level 3: Differentiating Zoning Settings according to the Product Catalog

You create Super Areas, different from the simple Areas in the sense that they are valid only for a particular Service and/or a particular Service Offer Group. Because a Super Area is, like any simple Area, an instance of AREA object, you can create one or more Matrices made up of Super Areas, where each Matrix specifies an origin/destination Super Area combination. Similary, you can group these Matrices into Matrix Components. From then on, the zoning settings are not the same for all the Customers of the Service Retailer. They depend on their portfolio. With these Product Catalog-specific settings, you can use the ORIGINATING ZONE, the DESTINATION ZONE and the MATRIX COMPONENT criteria, in Usage Rating Rules only.
11 September 2009
Page 551 of 968
Zoning Management
16.2.2. The Data Model
Area Identifier
1..1
1..1 0..n
Area Identifier Type
0..n
Area
0..n 0..n
Matrix Component
0..n
2..2
1..1
Matrix
2..2
Zone
0..1 0..n 0..1 0..n
Service
Service Offer Group
Figure 259 - Zoning Management Framework data model The schema in figure 259 above shows the Zoning Framework objects and the relationships that tie them with each other. What follows introduces the diagram, thereby explaining you the conventions it uses. In the above figure, an Area (i.e., an instance of AREA object) is either a simple Area or a Super Area. Let us first take the arrow that is linking the AREA IDENTIFIER object to the AREA object: The direction of the arrow indicates that the Area Identifier object makes a reference to the Area object. In other words, you must create at least one Area instance before being able to create an instance of Area Identifier. One Area Identifier refers to 1..1 Area. In other words, an Area Identifier must at least refer to one Area and to no more than one Area. An instance of AREA object can be referenced by 0..n Area Identifiers. An instance of AREA object that is referenced by one or more Area Identifiers is called a simple Area. Any number of Area Identifiers can refer to a given Simple Area. Let us now take the arrow linking the ZONE object to the AREA object:
Page 552 of 968
11 September 2009
An instance of ZONE object specifies the membership of a given simple Area to a given Super Area and under which conditions that membership is true. The diagram shows that an instance of ZONE object refers to exactly two (the cardinality shown next to ZONE object reads 2..2) instances of AREA object. In fact, one of the referred to Areas corresponds to Zone (Super Area)* parameter of ZONE object, which specifies the Super Area (instance of AREA object) that the instance of ZONE object is about. The other referred to Area corresponds to Area* parameter of ZONE object and specifies the simple Area. An instance of AREA object can be referenced by Zone (Super Area)* parameter of one or more instances of ZONE object. Such an instance of AREA object is called a Super Area and any number of instances of ZONE object can have their Zone (Super Area)* parameter refer to a given Super Area. It does not make sense for a Super Area to be referenced by one or more Area Identifiers. That it, it does not make sense for an Area to be simultaneously a Super Area and a simple Area.
16.2.3. Zoning Parameters Identification Logic

When an event occurs, the Convergent Rating Engine always identifies the zoning parameters that are applicable, by basically attempting to match the identifiers received from the RTx with the settings defined in the Zoning Management Framework. This is a sophisticated operation because an identifier could theoretically match more than one Area. Which one will be identified as the only matching Area in the context of the particular event depends on: the priority of the zoning parameter level: Default Service Retailer, Current Service Retailer, Service, Service Offer Group, the Area Identifier Types value, and the match algorithm applied.
All those issues are explained in detail in 16.6, Zoning Parameters Identification, on page 579.
16.3. Basic Zoning Configuration

A basic Zoning configuration just allows to map the network identifiers of the origin and the destination, as provided by the RTx request, to Areas. In the decision trees, the Origin Criterion performs a check on the origin Area, the Destination Criterion performs a check on the destination Area. Therefore, you need to create instances of three objects of the Zoning Management Framework: Area Identifier Type Area Area Identifier
11 September 2009
Page 553 of 968
Zoning Management
16.3.1. Area Identifier Type object

The Area Identifier Type object allows defining various types of Area Identifiers. Examples of Area Identifiers: International Numbering, Short Code,... The Area Identifier Type is one of the parameters of the Area Identification process. An Area is indeed defined (and hence identified) by 2 parameters:
1.
The Area Identifier Type, which the origtype or desttype parameter (provided by the RTx) has to match with (exact match); 2. The Area Identifier, which the origmc or destmc parameter (provided by the RTx) has to match with, according to a match algorithm provided by the RTx (via parameter origalgo or destalgo).
For a detailed explanation of the role of the Area Identifier Type in the Area Identification process, see 16.6.3.2, Role of the Area Identifier Type, on page 585.
For instance, the distinction between Area Identifier Types International Numbering and Short Code allows differentiating the same Area Identifier in two different uses: 3281 as International Numbering is an Identifier of Area Belgium Namur 3281 as Short Code is an Identifier of Area SMS Service Weather Forecast.
Figure 260 - Area Identifier Type GUI
Table 197 - Area Identifier Type - id_type Parameter Service Retailer*

aservret
Description Reference to the Service Retailer defining the current Area Identifier Type.
Name*
name
Name of the current Area Identifier Type.
Page 554 of 968
11 September 2009
Table 197 - Area Identifier Type - id_type Parameter ID*

id
Description Numeric identifier of the current Area Identifier Type, complying with the [orig/dest]type parameter sent by the RTx.
Warning: type zero (0)
The ID zero (0) cannot be created. When the RTx request sends an [orig/dest]type parameter of value zero, it allows a match with any Area Identifier Type.
16.3.2. Area object

The Area object lets you define a region that is either a simple Area or a Super Area.
Keep in mind that this region notion goes far beyond the geographical concept.
A simple area is a set of network identifiers (also called area identifiers). A simple Area is therefore an instance of AREA object that is referenced by one or more Area Identifiers (i.e., instances of AREA IDENTIFIER object). The origin/destination network identifiers an event carry are used to discover the origin simple Area and the destination simple Area of the event. A Super Area is basically a set of simple Areas. But the membership of each simple Area to the Super Area may depend on some condition. A Super Area is an instance of AREA object that is referred to by Zone (Super Area)* parameter of one or more instances of ZONE object. An instance of ZONE object lets you specify under which condition a give simple Area is member of the Super Area that Zone (Super Area)* parameter of the instance specifies. The origin simple Area of an event is used to find out the origin Super Area of the event, if any, and the destination simple Area of an event is used to find out the destination Super Area of the event, if any.
Super Areas are also sometimes called Zones. However, when referring to Super Areas, prefer to use Super Area term, since the term Zone has two possible meanings: That of a Super Area and that of an instance of ZONE object.
Whats the AREA Object used for?

The Area object is used by the Origin Criterion and Destination Criterion. These criteria can however only use simple Areas. The Area object is used by the Originating Zone Criterion and Destination Zone Criterion. These criteria can however only use Super Areas. The Area object is also used in Matrix object. A Matrix is either a combination of origin/destination simple Areas or a combination of origin/destination Super Areas. Thus, in a Matrix, you are not allowed to mix a simple Area with a Super Area, and vice-versa. See Using Matrix Object to Set Up Origin-Destination Combinations, on page 559.
11 September 2009
Page 555 of 968
Zoning Management
The Area is also used for implementing Super Areas, in cooperation with the ZONE object. See Advanced Zoning: Differentiating Zoning settings according to the Product Catalog, on page 565.
Figure 261 - Area GUI
Table 198 - Area - areas Parameter Service Retailer*

aservret
Description Reference to the Service Retailer defining the current Area.

Area Name*
name
Name of the Area, whether it is a Simple Area or a Super Area. Area names are referenced: in the Matrix object, which you use to define combinations of Originating-Destination Areas; in the Area Identifier object, where the Identifiers of an Area and the Type of those Identifiers are specified; in the Origin Criterion and the Destination Criterion, available in the decision trees of the Product Catalog. in the Originating Zone Criterion and the Destination Zone Criterion, which are only available Usage Rating Rule decision trees of the Product Catalog. in the Zone object, which is used to specify Product Catalog-dependent membership of simple Areas to Super Areas and thereby lets you set up Product Catalog-dependent zoning settings.
16.3.3. Area Identifier object

The Area Identifier object associates a string identifier (and its Identifier Type) to an Area.
Page 556 of 968
11 September 2009
In the zoning parameters identification phase, in the early logic steps of the event processing, the Convergent Rating Engine has to find what Area the origmc and destmc parameters belong to. For more details, see section 16.6, "Zoning Parameters Identification", on page 579. For identifying an Area, two matches have to be successfully performed:
1.
2.
a match between the origmc or destmc parameters with one of the Area Identifiers (according to a match algorithm provided by the RTx)
an exact match between the Area Identifier Type and the origtype or desttype parameter.
Are Area Identifiers prefixes?

An Area Identifier can of course be a usual prefix. However, the concept of Area Identifier encompasses much more than phone number prefixes, for two reasons:
1.
2.
An Area Identifier is a character string; so it is not necessarily composed of numbers. For instance, an e-mail address can be an Area Identifier.
The Area identification is not necessarily performed via a left to right match; right to left match algorithms are also offered in the Convergent Rating Engine. In that case, one would rather talk about suffixes.
Figure 262 - Area Identifier GUI Table 199 - Area Identifier - zoning Parameter Service Retailer*
aservret
Description Reference to the Service Retailer defining the current Area Identifier.
Area*
zone
Reference to the Area to be associated with the current Area Identifier (with the current Area Identifier Type).
11 September 2009
Page 557 of 968
Zoning Management
Table 199 - Area Identifier - zoning (continued) Parameter Identifier Type*

id_type
Description Reference to the Name of the Area Identifier Type representing the type of the current Area Identifier, when associated with the current Area. For identifying an Area, the Area Identifier Types ID must exactly match the origtype or desttype parameter.
Identifier*
id
Reference to the Area Identifier, representing the calling or called party, considered as belonging to the current Area. For identifying an Area, the Area Identifier has to match the origmc or destmc parameter, according to a match algorithm specified by the origalgo or destalgo parameter.
Version
version
Name of the Version of the current Area Identifier.
Default Value This parameter is not only optional, it also has a default value, which is the following string of characters: Default
Thus, the first letter of the default value is always in upper case and the other letters of the default value are always in lower case. Start date
vstartd
Date at which the Version as mentioned above for the current Area Identifier reaches the status defined below. Default Value This parameter is not only optional, it also has a default value, which is 01 Jan 2000.
Status
vstatus
Versioning Status that the current Area Identifier Version reaches at the Start Date. Before that date, the current Version remains in its previous Status. After that date, the current Version holds the current Status until no other Status has started. Default Value This parameter is not only optional, it also has a default value, which is: Active
Sep Ri*
sep_ri
This mandatory parameter is used by the Refresh method. Provides the SEP ri for which the Refresh method has to be invoked. This optional parameter is used by the Refresh method. Message Timeout parameter in seconds. The reference Service Retailer information is sent/received from the SMF. A timeout is associated with it for receiving the corresponding sep_ri from the SLEE sep.
Msg Timeout
msgtout
Page 558 of 968
11 September 2009
16.3.3.3. An additional method: Refresh

The Refresh method can be accessed by the Area Identifier menu item in the main menu bar. It refreshes the zoning information on the SEP specified by the SEP RI. Use this method when you want to immediately reflect the Area Identifier (zoning data) which you have added in the SEP, without restarting the SEP. The normal reload cycle of Area Identifier is one day. The method takes the following parameters as input: Service Retailer* (mandatory), Sep Ri* (mandatory) and Msg Timeout (optional).
16.4. Using Matrix Object to Set Up Origin-Destination Combinations

For any occurring network event, the Convergent Rating Engine attempts to identify two Areas: one Area matching the calling party and one Area matching the called party. These Areas are identified in the purpose of helping the decision making, performed by the various decision trees, by means of two criteria. The Area of the calling party can be tested in a decision tree thanks to the Origin Criterion. The Area of the called party can be tested in a decision tree thanks to the Destination Criterion. For making a decision based on the Area of the calling party and on the Area the called party, you can use a sequence of Origin and Destination Criteria. Nevertheless, this is usually not efficient, because there can be many possible combinations between the existing origin and destination Areas.
If your decision-making logic, or part of it, is the same for a number of origin-destination combinations, group these combinations (you define each of these combinations by setting up a Matrix specifying the combination) into the same Matrix Component and, in the decision trees, use MATRIX COMPONENT criteria referring to the Matrix component. The decision-making logic the criteria will apply to the Matrix Component will then apply to all of the combinations tbelonging to the Matrix Component
Why configuring a Matrix? Example

Lets go back to the example shortly presented on page 549. An operator wants to set up three types of pricing for the Voice service: national calls (internal to the country), calls to a country that has a border with the country from which the call is originated, and calls to other european countries. Seven countries are involved in the Offer: France, Belgium, UK, Spain, Germany, Switzerland and Portugal. If you dont use Matrix Components for making decisions based on origin-destination combinations, you will have to build a tree as shown in the figure below.
11 September 2009
Page 559 of 968
Zoning Management
Origin = France?
yes
Destination = Belgium?
no
yes
Tariff = Border
Destination = France?
no
yes
Tariff = National
Destination = Spain?
no no
yes
Tariff = Border
Destination = Portugal?
no
yes
Tariff = Europe
Destination = Switzerland?
no
yes
Tariff = Border
Destination = Germany?
no
yes
Tariff = Border
Destination = UK?
yes
Tariff = Europe
Origin = Spain?
yes
no
yes
Tariff = Europe
no
yes
Tariff = Border
no no
yes
Tariff = National
no
yes
Tariff = Border
no
yes
Tariff = Europe
no
yes
Tariff = Europe
Destination = UK?
yes
Tariff = Europe
Origin = Germany?
yes
no
yes
Tariff = Border
no
yes
Tariff = Border
no no
yes
Tariff = Europe
no
yes
Tariff = Europe
no
yes
Tariff = Border
no
yes
Tariff = National
Destination = UK?
yes
Tariff = Europe
Origin = Portugal?
yes
and so on...
Figure 263 - Zoning-based decision tree - without using a Matrix
Page 560 of 968
11 September 2009
The decision tree shown in figure 263 is very large, which makes it difficult to manage. Moreover, if a new Area is created - imagine that Italy needs to be inserted in the Zoning settings, the decision tree must be modified. Actually, this complex tree only leads to three different decisions: the Tariff can be either National, or Border, or Europe. We can hence consider that there are three types of origin-destination combinations: the combinations that lead to a National tariff, the combinations that lead to a Border tariff, and the combinations that lead to a Europe tariff. For each type of Tariff, you will define a Matrix Component that has the same name as the type of the Tariff. You would call as follows these Matrix Components: National, Border, Europe. For each origin-destination combination, you will define a Matrix that defines the combination and make the Matrix belong to the Matrix Component corresponding to the tariff that applies to the combination. The table below shows which origin-destination combinations belong to which Matrix Components: Table 200 - Which Origin/Destination Combination Is Part of Which Matrix Component Destination Areas Switzerland Germany
Origin Areas
France Belgium UK Spain Germany Switzerland Portugal
National Border Europe Border Border Border Europe
Border National Europe Europe Border Europe Europe
Europe Europe National Europe Europe Europe Europe
Border Europe Europe National Europe Europe Border
Border Border Europe Europe National Border Europe
Border Europe Europe Europe Border National Europe
Europe Europe Europe Border Europe Europe National
For example, any event whose caller is in France and whose called is in the UK has to be applied the Europe Tariff. You will thus set up a Matrix whose Originating Area* parameter is set to France and whose Destination Area* parameter is set to UK. Additionally, you will make that Matrix belong to Europe Matrix Component. Thanks to the MATRIX COMPONENT Criterion, which you use in conjunction with Matrix Components, the decision trees are considerably simplified, as the example below shows.
11 September 2009
Page 561 of 968
Portugal
Belgium
France
Spain
UK
Zoning Management
Matrix Component = National?
yes
Tariff = National
no yes
Matrix Component = Border?
Tariff = Border
no yes
Matrix Component = Europe?
Tariff = Europe
Figure 264 - Zoning-based decision tree - using a Matrix This decision tree is of course shorter and easier to build. It is also much more generic: if a new Area is created, only the Matrix needs to be updated. The decision tree can remain the same.
16.4.1. Matrix Component object

Ths object lets you create a Matrix Component and give it a name.
Although a Matrix Component is a grouping of instances of MATRIX object (i.e., of origin-destination Areas combinations), you do not use this object to indicate which Matrix (i.e., instance of MATRIX object) is part of the Matrix Component. You use MATRIX object to indicate which Matrix (i.e., origin-destination combination) is part of which Matrix Component. The Matrix Component is used by the Matrix Component Criterion.
Figure 265 - Matrix Component GUI
Page 562 of 968
11 September 2009
Table 201 - Matrix Component - classnam Parameter Service Retailer*

aservret
Description Reference to the Service Retailer defining the current Matrix Component.
Matrix Component Name*

name
Name of the Matrix Component. The Matrix Component Name is referenced in the Matrix Component Criterion.
16.4.2. Matrix object

Each instance of MATRIX object defines an origin-destination Areas combination and specifies to which Matrix Component the combination belongs. In terms of provisioning, the same Matrix Component should be used for all the origin-destination combinations that are meant to lead to the same processing and decision-making.
Check out a concrete example page 559.
Version* parameter Start date* parameter Status* parameter
Figure 266 - Matrix GUI
11 September 2009
Page 563 of 968
Zoning Management
Table 202 - Matrix - matrix Parameter Service Retailer*

aservret
Description Reference to the Service Retailer owning the current Matrix.
Originating Area*
orig_id
Reference to the Area (whether it is a Simple Area or a Super Area) representing the calling party of the network event.
Matrix of Super Areas
The originating Area can be a Super Area. In that case, the Destination Area must also be a Super Area, defined for the same Service and/or Service Offer Group as the Originating Area. Matrix Components associated to a pair of Super-Areas (as opposed to simple Areas) will be available for configuring the Matrix Component Criterion, only in Usage Rating Rules. In Service Rules, Charging Rules, and Rating Plan Rules, the Matrix Component Criterion can only refer to Matrix Components associated to pairs of simple Areas.
More info about Zones in Advanced Zoning: Differentiating Zoning settings

according to the Product Catalog, on page 565.
Destination Area*
dest_id
Reference to the Area (whether it is a Simple Area or a Super Area) representing the called party of the network event.
Matrix of Super Areas
The destination Area can be a Super Area. In that case, the Destination Area must also be a Super Area, defined for the same Service and/or Service Offer Group as the Originating Area. Matrix Components associated to a pair of Super Areas (as opposed to simple Areas) will be available for configuring the Matrix Component Criterion, only in Usage Rating Rules. In Service Rules, Charging Rules, and Rating Plan Rules, the Matrix Component Criterion can only refer to Matrix Components associated to pairs of simple Areas.
More info about Zones in Advanced Zoning: Differentiating Zoning settings

according to the Product Catalog, on page 565.
Matrix Component*
ptr-clna
Reference to the Matrix Component to which the Originating Area / Destination Area combination belongs. The same Matrix Component is supposed to be assigned to all the origindestination combinations that are wanted to lead to the same decision in the decision trees.
Page 564 of 968
11 September 2009
Table 202 - Matrix - matrix Parameter Version

version
Description Name of the Version of the current Matrix.
Default Value This parameter is not only optional, it also has a default value, which is the following string of characters: Default Thus, the first letter of the default value is always in upper case and the other letters of the default value are always in lower case. Start date
vstartd
Date at which the Version as mentioned above for the current Matrix reaches the status defined below. Default Value This parameter is not only optional, it also has a default value, which is 01 Jan 2000.
Status
vstatus
Versioning Status that the current Matrix Version reaches at the Start Date. Before that date, the current Version remains in its previous Status. After that date, the current Version holds the current Status until no other Status has started. Default Value This parameter is not only optional, it also has a default value, which is: Active
16.5. Advanced Zoning: Differentiating Zoning settings according to the Product Catalog
The zoning settings defined by the Areas apply to the whole Product Catalog of the Service Retailer. Nevertheless, the Service Retailer might sometimes want to draw the boundaries on the map in a totally different way, for instance in the case of a particular Service Offer Group, without modifying the zoning settings defined for the rest of the Product Catalog. The definition of different zoning settings according to the Product Catalog items (Services and/or Service Offer Groups) can be achieved thanks to the ZONE object. Without overriding the initial definition of the Areas, you can group them in new sets, called Super Areas. You can customize these groups of Areas per Service and/or per Service Offer Group of the Product Catalog. Note: In this section, unless when it is explicitly stated otherwise, the term Zone means the same as instance of ZONE object.
11 September 2009
Page 565 of 968
Zoning Management
16.5.1. Zone Object

A Zone (i.e., an instance of ZONE object) indicates membership of a simple Area to a given Area. This latter Area is called a Super Area. A Super Area is a set of simple Areas. For each simple Area that has to belong to a Super Area, you need to set up a Zone (i.e., an instance of ZONE object) that specifies the membership of the simple Area to the Super Area. Moreover, a Zone can also indicate under which conditions the simple Area it is about is member of the Super Area it is about. Indeed, a Zone can also specify a Service Offer Group and a Service Offer: The simple Area the Zone is about will then be considered to be part of the Super Area the Zone is about if, and only if, the event being processed is processed in the context of the Service Offer Group and the service Offer that the Zone specify. Thus, the Zone object allows re-grouping simple Areas, in order to make these sets of simple Areas valid only for a given Service and/or for a given Service Offer Group. If you want to understand why it can be relevant to re-define Areas per Service or per Service Offer Group, check the examples at 16.1.3, Second Level of Flexibility of the Zoning, on page 548.
Implementation
Like simple Areas, a Super Area is actually (in the database) nothing else than an instance of AREA object. The reason and advantage of this implementation is that it doesnt make any difference for the Matrix: a Matrix always defines a combination of origin-destination Areas. Whether they are simple Areas or Super Areas, the setup of the Matrix is identical. However, the consistency of provisioning requires that a Matrix must link instances of AREA object of the same type: either an originating simple Area with a simple destination Area or an originating Super Area with a destination Super Area.
Per Service and/or per Service Offer Group

For a given RTx request, several Zones (i.e., instances of ZONE object) could match the origin or the destination identifier. In that case, the origin or the destination belongs to the most restrictive matching Zone.
Page 566 of 968
11 September 2009
The table below shows the detailed priority order among the Zones matching the origin or the destination identifier. Table 203 - Matching Zones Priority Order Matching ZONE Objects Instances The instance of ZONE object that matches the origin or destination identifier is defined per... 1 2 Order of Priority 2 3 4 5 6 7 Current Service Retailer Default Service Retailer Current Service Retailer Default Service Retailer Current Service Retailer Default Service Retailer Current Service Retailer Default Service Retailer Area Area Area Area Area Area Area Area Service Offer Group Service Offer Group Service Offer Group Service Offer Group Service Service Service Service -
According to the above table, the CRE finds as follows the Zone (i.e., instance of ZONE object) that the origin (the destination) of an event matches:
Step 1: It is first tried to find out a Zone: That includes the origins Area (the destinations Area) and That refers to the Service Offer Group applying to the event and That refers to the Service applying to the event. The search is first done in the current Service Retailer. If the search in the current Service Retailer fails, it continues in the default Service Retailer, if any is defined for the current Service Retailer. Step 2: If previous step did not find the Zone, it is tried to find out a Zone: That includes the origins Area (the destinations Area) and That refers to the Service Offer Group applying to the event and That refers to no Service. As in previous step, the search is first done in the current Service Retailer. If the search in the current Service Retailer fails, it continues in the default Service Retailer, if any. Step 3: If previous step did not find the Zone, it is tried to find out a Zone: That includes the origins Area (the destinations Area) and That refers to no Service Offer Group and That refers to the Service applying to the event. As in previous step, the search is first done in the current Service Retailer. If the search in the current Service Retailer fails, it continues in the default Service Retailer, if any. Step 4: If previous step did not find the Zone, it is tried to find out a Zone: That includes the origins Area (the destinations Area) and That refers to no Service Offer Group and
11 September 2009
Page 567 of 968
Zoning Management
That refers to no Service. As in previous step, the search is first done in the current Service Retailer. If the search in the current Service Retailer fails, it continues in the default Service Retailer, if any.
Identification of the Product Catalog-dependent zoning settings

The instances of ZONE object are Product Catalog-dependent Zoning settings. It means that they are taken into account only when the Service and/or Service Offer Group for which they are defined are the ones active for the ongoing event. The logical consequence is that Super Areas (and thus the Zones, since its the Zones that indicate which simple Area is part of which Super Area) can be used by the Matrix Component Criterion only in a Usage Rating Rule. Indeed, it doesnt make sense to refer to a Service- and/or Service Offer Group-dependent Zone... ... in a Service Rule, since the definitive Service applicable to the ongoing event is not known yet; ... in a Rating Plan Rule, since the actual Service Offer Group applicable to the ongoing event is not known yet; ... in a Charging Rule, since the Service Offer that provides the Charging Rule may not be the one applicable to the ongoing event (in case of hierarchy, the Charging Rules of the potential payers can be provided by a Service Offer Group different from the one of the actual caller). In summary, Super Areas, as Product Catalog-dependent settings, only make sense in the Usage Rating Rule, i.e. at a stage where the applicable Product Catalog elements are definitively identified for the ongoing event.
As a consequence, the Matrix Component Criterion is applied restrictions in the list of possible Matrix Components, when it is used in a Service Rule, a Charging Rule or a Usage Rating Rule. See also chapter 12.3.26, "Matrix Component Criterion", on page 467.
Figure 267 - Zone GUI
Page 568 of 968
11 September 2009
Table 204 - Zone - zoneref Parameter Service Retailer* Zone (Super Area)* Description Reference to the Service Retailer defining the current Zone. Reference to the instance of AREA object meant to be a Super Area. It is highly recommended to adopt a clear naming convention for the Areas to be used as Super Areas. See also Tip: Safely Provisioning Zones, on page 570. Area* Reference to the simple Area to be included into the Super Area that Zone (Super Area)* parameter (of the current zone) specifies. This parameter is the only one, among the objects of the Zoning Management framework, that is allowed to refer to a zoning setting of the default Service Retailer of the current Service Retailer. As a result, this parameter does not necessarily hold a reference to an simple Area of the current Service Retailer, since this parameter may hold a reference to the default Service Retailer of the current Service Retailer. Service Offer Group Reference to the Service Offer Group for which the current Zone is applicable. The Service Offer Group limitation can be even more restricted, by adding a Service limitation. The most restrictive zoning settings have the priority over the more general zoning settings. For more details about the priority order of the zoning settings, see Per Service and/or per Service Offer Group, on page 566. Service Reference to the Service for which the current Zone is applicable. The Service limitation can be even more restricted, by adding a Service Offer Group limitation. The most restrictive zoning settings have the priority over the more general zoning settings. For more details about the priority order of the zoning settings, see Per Service and/or per Service Offer Group, on page 566. Version Name of the Version of the current Zone.

Start Date Status
Date at which the Version as mentioned above for the current Zone reaches the status defined below. Versioning Status that the current Zone Version reaches at the Start Date. Before that date, the current Version remains in its previous Status. After that date, the current Version holds the current Status until no other Status has started.
11 September 2009
Page 569 of 968
Zoning Management
16.5.2. Tip: Safely Provisioning Zones

When creating a Zone, you conceptually include a simple Area into a Super-Area. As described above, both Super-Areas and simple Areas have to be created as instances of the Area object. Functionally, it is important though not to mix them up. Otherwise, the risk is to create loops in the Zoning settings. A configuration in which Super-Area 1 includes Area 2, which is actually also a Super-Area, including Area 3, and so on, would just be a mess. The best strategy for a safe provisioning is probably to adopt clear naming conventions, in order to distinguish between: simple Areas, matched by Area Identifiers, and Super-Areas, meant to be configured by means of Zones, including simple Areas. For example, you could use the prefix area_ for the simple Areas and zone_ for the Super-Areas.
16.5.3. Example of Provisioning

Do you remember our example of Service Offer Group-specific zoning settings? Our use case lies in a Service Offer Group redefining Europe: a country is considered as European on the basis of their membership to the European Union, rather than on the basis of their geographical location.
Read the full story on page 548, Differentiating the zoning settings per Service Offer Group: Example.
The illustrated procedure below shows you how to configure such a use case in the Zoning Management Framework. Step 1: Simple Areas are created, one per country.
Page 570 of 968
11 September 2009
Step 2: Area Identifiers are created, in order to map the international codes with the countries.
Identifier 33 (of Type International) will match the Area Belgium.
11 September 2009
Page 571 of 968
Zoning Management
According to the same principle, each country is identified thanks to its international prefix.
Step 3: Super-Areas are created: Europe and non-Europe, using a naming convention. No Area Identifier is created for them, since they are meant to be used as Super Areas.
Step 4: Zones (i.e., instances of ZONE object) are created, mapping each country to one of the SuperAreas. No Service nor Service Offer Group is specified, because these Zones are applicable to the whole Product Catalog, unless more restrictive settings are defined for a particular Service and/or Service Offer Group.
Page 572 of 968
11 September 2009
The Area Belgium is actually included in Super Area zone_Europe. This is true for any Service and any Service Offer Group (unless more restrictive settings are defined in another Zone object).
According to the same principle, Areas France, Switzerland, Norway and Iceland are included in Super Area zone_Europe.
11 September 2009
Page 573 of 968
Zoning Management
According to the same principle, Area Turkey is included in Super Area zone_non-Europe.
So now, for the global Product Catalog, each country Area is mapped to a larger continental Super Area: Europe or non-Europe. Step 5: The new Service Offer Group VoiceEurope requires to bypass the standard continental classification of the Areas. Now only the countries member or candidate-member of the European Union will be considered as belonging to the Super Area zone_Europe. For that purpose, Service Offer Group-specific Zones are now created. They still map a country to one of the Super-Areas. However, this mapping is explicitly defined as valid only for the Service Offer Group VoiceEurope.
Areas Switzerland, Norway and Iceland are now mapped to Super Area zone_non-Europe, in the context of the Service Offer Group VoiceEurope.
These three Zones are only valid when the active Service Offer Group for the event is VoiceEurope.
Page 574 of 968
11 September 2009
According to the same principle, the simple Area Turkey is included in Super Area zone_Europe, in the context of the Service Offer Group VoiceEurope.
No new Zones need to be defined for the simple Areas Belgium and France. The standard settings including them in Super Area zone_Europe are still valid for the Service Offer Group VoiceEurope.
These Zones are valid for the whole Product Catalog (unless otherwise specified).
Step 6: Although the ORIGINATING ZONE and DESTINATION ZONE criteria could be used, we will illustrate the use of the Zones by means of the MATRIX COMPONENT criterion. Note that, in the case of External Matrix Component (i.e., the instance of MATRIX COMPONENT object whose Matrix Component Name* parameter is set to External), using the MATRIX COMPONENT criterion will enable us to save the number of ORIGINATING ZONE and DESTINATION ZONE criteria used: External Matrix Component is made up of two origin/destination combinations. We first create the Matrix Components. Next step will give the Matrix Components the origin/destination combinations of which they are made up.
11 September 2009
Page 575 of 968
Zoning Management
These Matrix Components are going to be assigned origin-destination pairs defined by MATRIX object.
Step 7: The Matrix instances, which define the various origin/destination combinations of Super Areas, can now be created. Each instance of Matrix object assigns a Matrix Component to the combination of originating and destination Super-Areas that the instance sets up.
When the Super Area identified for the origin is zone_Europe and the Super Area identified for the destination is zone_Europe, then the Matrix Component identified for that event is Internal.
Page 576 of 968
11 September 2009
Since we have 2 Super Areas, there are 4 possible origin/destination combinations. So the 4 instances of the Matrix object are created.
Step 8: Now a Usage Rating Rule can be created, using Matrix Component criteria that meet the Matrix provisioning we have just done.
The 3 possible Matrix Components are tested in the Usage Rating Rule. According to the Matrix Component Criterion that is eventually met, the Tariff applicable to the ongoing event is either Tariff Voice, or Tariff_Voice3 or Tariff_Voice2.
11 September 2009
Page 577 of 968
Zoning Management
Lets check a few cases:
A call from France to Switzerland 1. For a Customer with a VoiceBasic Service Offer Group:
2. originating Area: France, so zone_Europe destination Area: Switzerland, so zone_Europe Matrix Component: Internal Applicable Tariff: Tariff01 originating Area: France, so zone_Europe destination Area: Switzerland, so zone_non-Europe (here is the difference!) Matrix Component: Outgoing Applicable Tariff: Tariff02
For a Customer with a VoiceEurope Service Offer Group:
A call from Turkey to Switzerland 1. For a Customer with a VoiceBasic Service Offer Group:
2. originating Area: Turkey, so zone_non-Europe destination Area: Switzerland, so zone_Europe Matrix Component: External Applicable Tariff: Tariff03
For a Customer with a VoiceEurope Service Offer Group: originating Area: Turkey, so zone_Europe (here is the difference!) destination Area: Switzerland, so zone_non-Europe (here is the difference!)
Page 578 of 968
11 September 2009
Step 9: The two Service Offer Groups VoiceBasic and VoiceEurope use the same Usage Rating Rule: so the criteria are the same and the Tariffs are the same as well. The only difference lies in the way the Matrix Components are identified, because of the different Zones applicable whether the calling Customers Service Offer Group is VoiceBasic or VoiceEurope.
Matrix Component: Outgoing Applicable Tariff: Tariff02
16.6. Zoning Parameters Identification

Identifying the zoning parameters applicable to a given event is not a trivial issue. Indeed, the Zoning Management Framework offers an important flexibility: there can be zoning settings defined at multiple levels: default Service Retailer, current Service Retailer, Service and Service Offer Group; a network identifier (whether of the origin or the destination of an event) can theoretically match more than one Area, depending on how the Area Identifier Type is taken into account; a network identifier (whether of the origin or the destination of an event) can theoretically match more than one Area, depending on the match algorithms applied. The purpose of this chapter is to explain how and in what order all the possibilities are tested. After reading this chapter, you will understand, among the zoning settings, which ones have the priority over others - in general and in the context of a particular event. In this chapter, you will find the detailed explanation about the Convergent Rating Engines behavior for identifying the zoning parameters applicable to the ongoing event: 16.6.1 Default Service Retailer In what cases are the Default Service Retailers settings taken into account?
16.6.2 Zoning Parameters Identification Logic Logical flow of the identification of zoning parameters applicable in the various decision trees translated for a given event. 16.6.3 Area Identification Match Algorithms Mapping the network identifiers received in the RTx request onto the Areas (whether they are Simple Areas or Super Areas) defined in the Zoning Management Framework can be done with various methods and under various constraints.
16.6.1. Default Service Retailer

A Service Retailer configuring its own zoning settings can also specify a default Service Retailer.
On how the Service retailer specifies its default Service Retailer, see parameter Default Service Retailer, page 142, which is a parameter of SERVICE RETAILER object.
Recall that, as has been pointed out in section 16.1.2, First Level of Flexibility of the Zoning, on page 546, this chapter of the Reference Guide calls: current Service Retailer, the Service Retailer owning the Customers, Accounts and Product Catalog and defining its own zoning settings; default Service Retailer, the Service Retailer providing its zoning settings as default for the current Service Retailer. Functionally, among the various actors co-existing on one Convergent Rating Engine, there is an analogy between: the Default Service Retailer the Network Operator (current Service Retailer); the current Service Retailer the Service Providers (or MVNOs).
11 September 2009
Page 579 of 968
Zoning Management
The zoning settings of the default Service Retailer become then the default zoning settings of the current Service Retailer. This framework allows the MVNOs located on the same Convergent Rating Engine to reuse standard zoning settings, while still being able to customize or sophisticate them for their own needs, without having to re-define everything. The principle applying to the zoning settings of a current Service Retailer is that the default settings are always available, in case its specific settings dont provide a satisfactory identification of the zoning parameters. The settings of the current Service Retailer have the priority over the settings of the default Service Retailer.
16.6.2. Zoning Parameters Identification Logic

The zoning parameters of an event are identified in the early steps of the event processing by the Convergent Rating Engine. So the value against which the zoning criteria must be tested are known before analyzing the Product Catalog and translating any decision tree. That logic flow is executed along the 8 phases described below. Phase 1 - Originating Area Identification (step 1) Originating Area in current Service Retailers settings1; (step 2) (if not found) Originating Area in default Service Retailer settings. Phase 2 - Destination Area Identification (step 3) Destination Area in current Service Retailer settings; (step 4) (if not found) Destination Area in default Service Retailer settings.
Phase 3 - Matrix Component Identification (step 5) (if both Areas found in current Service Retailer) Matrix Component in current Service Retailers Matrix; (step 6) (if both Areas found in default Service Retailer) Matrix Component in default Service Retailers Matrix; (step 7) (if not found) Default Matrix Component of current Service Retailer Phase 4 - Translation of the Product Catalogs decision trees Now that previous steps identified the basic zoning settings, they can be used by the 3 Zoning criteria (Origin, Destination and Matrix Component) in the 3 decision trees that might be translated during the guiding process: Service Rule, Charging Rule and Rating Plan Rule. Once the decision trees have been translated, a request is sent by the Community Engine to the Rating Engine with the Account to be charged and most importantly: the Service Offer Group applicable to the event. Phase 5 - Originating Super Area Identification (step 8) Which Zone does the Originating Area identified in phase 1 match? The search for the Zone (hereby called the Originating Zone) is performed as section Per Service and/or per Service Offer Group, on page 566, explains. If the search succeeds, the Super Area to which the found Originating Zone belongs doesnt replace the Originating Area identified in phase 1, but it will be taken into account for identifying a Matrix Component in phase 7. Phase 6 - Destination Super Area Identification (step 9) Which Zone does the Destination Area identified in phase 2 match? The search for the Zone (hereby called the Destination Zone) is performed as section Per Service and/or per Service Offer Group, on page 566, explains. If the search succeeds, the Super Area to which the found Destination Zone belongs doesnt replace
1. For detailed logic of the Area identification process, see 16.6.3, Area Identification Match Algorithms, on page 583.
Page 580 of 968
11 September 2009
the Destination Area identified in phase 2, but it will be taken into account for identifying a Matrix Component in phase 7. Phase 7 - Zone-based Matrix Component Identification (step 10) If steps 8 and 9 are successful: is there a Matrix Component defined for the combination of the originating Super Area and of the destination Super Area? The search is first done in the current Service Retailer. If the search in the current Service Retailer fails, the search continues in the default Service Retailer. If the search finds a Matrix Component, the Matrix Component overrides the Matrix Component identified in phase 3. Phase 8 - Translation of the Usage Rating Rule In the Usage Rating Rule, the five Zoning criteria can be met and tested against the following values: Origin Criterion: tests the Originating Area identified in phase 1 Destination Criterion: tests the Destination Area identified in phase 2 Originating Zone Criterion: tests the Originating Super Area identified in phase 5 Destination Zone Criterion: tests the Destination Super Area identified in phase 6 Matrix Component Criterion: tests the Zone-base Matrix Component (if any identified in phase 7), otherwise tests the Matrix Component identified in phase 3. The figure 268 below shows a summary of the zoning parameters identification logic.
11 September 2009
Page 581 of 968
Zoning Management
In the Community Engine

Phase 1 - Identify Originating Area 1
yes no Originating Area not found
no
Phase 2 - Identify Destination Area

no
3
yes
no
no
4
yes
no
Destination Area not found
Phase 3 - Identify Matrix Component 1&3

yes ok yes no no
2&4
yes
no yes
no no
6
Matrix Component not found
yes
ok
ok
Phase 4 - Translate the Product Catalogs decision trees

Service Rule Charging Rule potentially using Origin Criterion Destination Criterion Matrix Component Criterion tested against the Originating Area found in Phase 1 tested against the Destination Area found in Phase 2 tested against the Matrix Component found in Phase 3 Rating Plan Rule
In the Rating Engine

Phase 5 - Identify Originating Super Area 8
yes no
Phase 6 - Identify Destination Super Area

no
9
yes
Page 582 of 968
11 September 2009
Phase 7- Identify Zone-based Matrix Component

no
10
yes ok New Matrix Component found (overriding the Matrix Component identified in Phase 3) no No new Matrix Component found (the Matrix Component identified in Phase 3 is still valid)
Phase 8 - Translate the Service Offers Usage Rating Rule

Usage Rating Rule potentially using Origin Criterion Destination Criterion Originating Zone Criterion Destination Zone Criterion Matrix Component Criterion tested against the Originating Area found in Phase 1 tested against the Destination Area found in Phase 2 tested against the Originating Super Area found in Phase 5 tested against the Destination Super Area found in Phase 6 tested against the Matrix component found in Phase 7, or else in Phase 3. Current Service Retailer Default Service Retailer
Figure 268 - Zoning Parameters Identification
16.6.3. Area Identification Match Algorithms

The Area identification process is identical for both the Originating and the Destination Areas. The Rating Engine executes the identification process, respecting two constraints imposed by the parameters of the RTx request. Three parameters sent by the RTx via the interface are taken into account: origmc originating cell of the event; origtype Area Identifier Type of the Originating Area; origalgo match algorithm to be applied for identifying the Originating Area. The goal of the Originating Area Identification process is to find, in the zoning settings of the Service Retailer (the current one or the default one), an Area
1.
2. 3.
which an Identifier of matches the origmc parameter of the current event, using the match algorithm specified in the origalgo parameter,
and which the Area Identifier Type of exactly matches the origtype parameter. So the parameter origtype must match the Originating Area Identifier Types ID (id_type.id). See attribute ID* of Area Identifier Type on page 555.
11 September 2009
Page 583 of 968
Zoning Management
The same logic applies to the Destination Area Identification, with the equivalent parameters:
destmc desttype destalgo
16.6.3.1. Available Match Algorithms

The table below shows the available match algorithms available in the Convergent Rating Engine for identifying the Area corresponding to the identifier sent by the RTx. Table 205 - Area Identification Match Algorithms
origalgo or destalgo
parameter 0
Match Algorithm For Originating Area, equal to origalgo = 1 For Destination Area, equal to destalgo = 3
This interpretation of the zero (0) value is supported for backward compatibility with previous versions of the Rating Engine.
1 2
Exact match. Greatest match from left to right.

Match Algorithm on page 584.
For more details about the match algorithm direction, see Left to Right
3 Greatest match from left to right, with a minimum and a maximum number of matching characters.
Left to Right Match Algorithm

The left-to-right match algorithms are to be understood as follows: the screening of the two character strings is performed from the left-most character to the right, character per character; the screening stops when 2 non-matching characters are found. OR when the maximum number of matching characters is reached1. The origmc (or destmc) character string is compared to the Area Identifiers, in order to identify the Area(s) that it could be mapped to. The table 206 below shows the result of left-to-right matching attempts of an origmc 003225556677 with various Area Identifiers.
1. See Match with Minimum and Maximum page 585.
Page 584 of 968
11 September 2009
Table 206 - Result of left-to-right match origmc Area Identifier 0032 Match Result Successful Belgium Originating Area
0031
Not successful
None
No
003225556677 00322
tch a m
Successful
Brussels
003281
Not successful
None
Match with Minimum and Maximum

The minimum and maximum values used by the match algorithm 3 are set in the Service Retailer object. See Min. Nb of Matching Characters*, on page 142, and Max. Nb of Matching Characters*, on page 143).
Case Sensitivity
Since the match is performed on string identifiers, the character case is an issue. Keep in mind that all match algorithms are case-sensitive.
16.6.3.2. Role of the Area Identifier Type

The Area Identifier Type is used to avoid confusions between potentially identical Area Identifiers.
11 September 2009
Page 585 of 968
Zoning Management
For instance, the distinction between Area Identifier Types International Numbering and Short Code allows differentiating the same Area Identifier in two different uses: 3281 as International Numbering is an Identifier of Area Namur 3281 as Short Code is an Identifier of Area SMS Service Weather Forecast. Look at the following provisioning: Two Areas have the same Identifier: 3281 is an Identifier of the Area Namur and of the Area SMS Service Weather Forecast.
The only difference between those two Area Identifiers is their Type. 3281 as InternationalNumbering is an Identifier of Area Namur 3281 as ShortCode is an Identifier of Area SMS Service Weather Forecast. These Area Identifier Types are populated as follows:
The Area Identifier Type InternationalNumbering has the numeric ID 2. The Area Identifier Type ShortCode has the numeric ID 3. When receiving the RTx request, if the destmc (or origmc) is a Short Code, it doesnt make sense to map it to an Area of type International Numbering. So the RTx request must always specify the Type of the Identifier. Therefore, the parameter desttype (or origtype) provides the numeric ID of the Area Identifier Type. In the process of identifying an Area, the exact match between the orig/desttype parameter and the Area Identifier Type is mandatory. The table 207 below shows the compared result of the Area identification process for the following two RTx requests: RTx request A RTx request B
Page 586 of 968
11 September 2009
destmc=3281 destalgo=2 desttype=2
destmc=3281 destalgo=2 desttype=3
Table 207 - Role of the Area Identifier Type destmc destalgo desttype Matching attempt with Area... Namur is successful.
2 3281 2 (= International Numbering)
match on the Identifier Type AND on the Identifier
Service SMS Weather Forecast is not successful.
the on pe h c t r Ty ma no ntifie Ide
Namur is not successful.
3281
3 (= ShortCode)
the on pe h c t r Ty ma no ntifie e Id
Service SMS Weather Forecast is successful.
match on the Identifier Type AND on the Identifier
When origtype or desttype = zero (0)

When the parameter origtype (or desttype) sent by the RTx equals zero, it means that any Area Identifier Type will be considered as matching. So only when orig/desttype = 0, the Area Identifier Type is no longer a condition.
Particular case: two identical Area Identifiers and orig/desttype = 0

We have seen in the example above that the orig/desttype match with the Area Identifier Type was the only way of discriminating
11 September 2009
Page 587 of 968
Zoning Management
3281, meaning Area Belgium Namur with the Area Identifier Type International Numbering and 3281, meaning Area SMS Service Weather Forecast with the Area Identifier Type Short Code. So what happens when origtype or desttype equals zero? Logically, it could either be Namur or SMS Service Weather Forecast. In such a case, the behavior of the Convergent Rating Engine is as follows: one of the matching Areas (the first that is found, actually) is chosen randomly.
Page 588 of 968
11 September 2009
17. Rewarding Accounts

17.1. Overview
17.1.1. The Available Rewarding Methods: Crediting and Discounting
You can reward an Account: Either by giving some credit to the Account. This consists in adding units to the Account (whether to the Accounts main balance or to one or more of the Accounts bundles). Roughly said, giving some credit to an Account allows it to buy more RUM quantities at the same price. The units added to an Accounts main balance are always money units. On the other hand, the units added to an Accounts bundle are expressed in the same units as the bundle, and can thus be other units than money units. For example, if some units are to be added to a bundle whose value is a number of SMSes, the added units are a number of SMSes. Or by granting some discount to the Account. This consists in allowing the Account to buy (e.g., to make voice calls, to send SMSes, and so on) RUM quantities at a lower price than the tariff in force. The discount is a percentage by which a price (which is computed by applying some tariff to e.g. the use of a voice call) is lowered.
17.1.2. Rewarding by Giving Some Credit

You can use any of the following objects to grant some credit to Accounts: The Grant Tool object, in conjunction with the Grant decision tree criterion. The Discount object. Note: Although the name of this object is a misnomer (this object never grants any discount), this manual keeps referring to this object by calling it the Discount object. The Promotion Tool object, in conjunction with the Supervision decision tree criterion. Any credit granted by the tool is called a Bonus Amount.
17.1.3. Rewarding by Granting Some Discount

You can grant some discount to an Account through the use of: The Discount decision tree criterion. The Preferred Number decision tree criterion. The Promotion Tool object, in conjunction with the following decision tree criteria: Supervision criterion and Promotion criterion. Any discount granted by the Promotion Tool is called an On Call Promotion.
11 September 2009
Page 589 of 968
Rewarding Accounts
In contrast to the Discount and the Preferred Number decision criteria, the Promotion Tool adapts the level (i.e., the percentage) of the granted discount to the RUM quantities that a given Account consumed over a past period of time (called the supervision period of time).
17.2. Grant Tool Object

17.2.1.1. Rewarding an Account with Some Credit
With the Grant Tool, you make the CRE reward an Account Profiles Account with some credit whenever the Account fulfills some condition. More accurately said, an instance of Grant Tool object specifies: On what conditions the Accounts, belonging to the Account Profile the instance refers to, are rewarded with some credit (whether financial or not), and How the granted credit has then to be computed. Since a Grant Tool object instance specifies the conditions that govern the granting of a credit and how the granted credit is computed, an instance of Grant Tool object specifies nothing else than the terms of a credit grant. For that reason, a Grant Tool object instance is said to specify the terms of a credit grant. Note: Currently, the Grant Tool object is only able to reward an Account for its Top-Up activity. Which means that the credit granted to an Account is computed on the basis of that Accounts Top-Up activity.
17.2.1.2. Rewarding an Account Activity/Inactivity extension

Arena Variable "GRNT_EXT" at Service Retailer Level can be used to enable/disable, activity/inactivity period extension.If its value is 1, new activity/inactivity dates are calculated based on topup profile and the new values so obtained are rewarded to the user. Otherwise, no activity/inactivity extension is given.
17.2.1.3. When You should Use the Grant Tool

New with CRE 2.0, the Grant Tool object is the new CRE approach for rewarding Accounts by granting them some credit. Although the rewarding capabilities of the Grant Tool object are currently limited to the Accounts TopUp activity, some of the capabilities it offers are already unique. For example, by means of the Grant Tool object, you can grant credit to the Accounts main balance as well as to the Accounts bundles. And in some cases, you can simultaneously credit the Accounts main balance and/or one or more Accounts bundles, each being given different credit values. As another example, with the Grant Tool object, the granted credit is not necessarily expressed in terms of money. This is useful whenever wanting to grant some credit to a bundle that does not hold money.
Page 590 of 968
11 September 2009
Because it is the new CRE approach for rewarding Accounts with some credit, the rewarding capabilities that the Grant Tool object offers are planned to expand over time. For that reason, choose to use the Grant Tool every time it is able to fulfill your Account Rewarding needs, even when you see that some other CRE objects can fulfill the same purpose. This is the safest way to protect your investment (e.g., to protect the time you spent on planning and setting up the rewarding of your Accounts).
17.2.1.4. Making the CRE Take into Account the Terms of a Credit Grant
To have the CRE taking care of the Terms of a Credit Grant that you have set up, you need to make sure that these Terms of the Credit Grant are suitably used by some Grant criterion that some Top-Up rule uses. If you never do that, the CRE will never reward Accounts in the way the Terms of the Credit Grant specify. Thus, whenever you want to reward an Account Profiles Accounts with some credit and do that by means of the Grant Tool object, proceed as follows: 1. Make up the Terms of the Credit Grant (that is, make up an instance of Grant Tool object) so that: They refer to the Account Profile of the Accounts, and They specify on what conditions the Account Profiles Accounts will be rewarded with some credit, and
They specify how the latter credit is computed. 2. In one or more Top-Up rules that process the Account Profiles Accounts, create a Grant criterion that refers to the Terms of the Credit Grant you made up. Every time one of these Top-Up rules executes and goes across some Grant criterion, the Terms of the Credit Grant associated with the Grant criterion get executed, in order to check whether some credit grant has to be performed or not. If some credit grant has to be performed, the credit to grant is calculated and granted.
11 September 2009
Page 591 of 968
Rewarding Accounts
17.2.2. How the Terms of a Credit Grant Work

17.2.2.1. Principle of Work
Basically, the Terms of a Credit Grant: Indicate some quantity to observe (hereby called the observed quantity), and Define up to five range of values, and Indicate for each defined range of values whether a credit is associated with it or not, and Indicate how the credit associated with each range has to be computed. Every time a Top-Up rule goes through a Grant criterion, the Terms of Credit Grant that the criterion refers to will be executed if and only if the current Top-Up (i.e., the current network event of the TopUp rule) is successful. At time they get executed, these Terms of Credit Grant compare the value of their quantity to observe against their range of values, in order to find out to which range the value of the quantity to observe belongs. If the value of the quantity to observe belongs to no range of values, no credit is granted. Otherwise, the value of the quantity to observe belongs to one of the ranges, and the Terms of Credit Grant then check whether some credit is associated with the range to which the value of the quantity to observe belongs. If some credit is associated with the range, the Terms of Credit Grant compute that credit and grant it. Otherwise, no credit is granted at all, since the range grants no credit. Since only a Top-Up rule can use the Grant criterion, the Terms of a Credit Grant are always executed in the context of the treatment of some Top-Up RTx request. That is, the execution of the Terms of a Credit Grant are always executed upon processing by the CRE of a Top-Up RTx request.
Page 592 of 968
11 September 2009
17.2.2.2. Key Terms You Need to Know

This sections explains the following terms: The current Terms of Credit Grant The observed value The current network event The observed range of values (in short, the observed range) The current Terms of Credit Grant correspond to the instance of Grant Tool object that a Top-Up rule is being executing (of course, via one of its Grant criteria). The observed value is the current value of the quantity that the current Terms of Credit Grant observe. The current network event of the current Terms of Credit Grant is the network event that the Top-Rule that executes the current Terms of Grant is treating. The current network event thus always corresponds to a Top-Up RTx request. The observed range is the range of values, of the current Terms of Credit Grant, to which the value of the observed quantity, of the current Terms of Credit Grant, belongs.
11 September 2009
Page 593 of 968
Rewarding Accounts
17.2.2.3. Specifying the Quantity to Observe

The quantity that the Terms of a Credit Grant have to observe is: Either the Nominal Value (Money) of the Top-Up Profile that the current network event, which is a Top-Up RTx request, refers to, Or a counter. Of course, that counter must belong to the current Account (that is, to the Account that the Top-Up rule is currently treating).
Figure 269 - Grant Tool GUI - Specifying the Quantity to Observe To indicate that the quantity to observe is the value of Nominal Value (Money) parameter of the Top-Up Profile of the current network event, check Top-Up value for Threshold Comparison check box. To indicate that the quantity to observe is a counter: Uncheck Top-Up value for Threshold Comparison check box Indicate in Counter parameter the name of the counter. In the above figure, Top-Up value for Threshold Comparison check box is checked. This means that the quantity to observe is the value of Nominal value (Money) parameter of the Top-Up profile that the current network event, which is a Top-Up RTx request, specifies.
Page 594 of 968
11 September 2009
Note: After the HF903 installation, if the Top-Up value for Threshold Comparison check box is checked the rounding of threshold values does not takes place automatically. That is, the operator has to take the responsibility of entering the threshold value with the decimal precision. Example: If the operator wants to enter 56 in the threshold field and suppose the decimal precision is 2 then, in this case the operator has to enter 5600 in the threshold field. Note: Before the HF903 installation, the behaviour of the Grant Tool is that the threshold values are automatically rounded of as per the decimal precision defined in the Service Retailer. If the Grant tool uses the counters for threshold comparisons, the said changes need not be done. Only those Grant Tool configurations, which are using Top-up value for threshold compare flag checked needs to implement the changes suggested above. For the Existing Customers who are using Grant Tool configuration already done before installation of HF903: To ensure that the grant tool objects configured before HF903 work properly, a script was introduced as part of installation procedure, which will automatically modify the Threshold Values and help avoid any problem to existing Grant Tool users. It has been taken care of in that script that the threshold values are modified only once
11 September 2009
Page 595 of 968
Rewarding Accounts
17.2.2.4. Specifying the Value Ranges

You specify a range of values by specifying the upper value of the range. That upper value is called a threshold. By giving a value to Threshold 1 parameter, you specify the first range of value, which goes from, and includes, 0 up to, and including, the value that Threshold 1 parameter specifies.
This range of value is hereby called Threshold 1 range of value.
By giving a value to Threshold N parameter (where N represents a value that is > 1 and <=5), you specify the Nth range of value, which goes from, but does not include, Threshold N-1 parameter value up to, and including, Threshold N parameter value.
This range of value is hereby called Threshold N range of value.
Figure 270 - Grant Tool GUI - Specifying the Value Ranges In the above figure, Threshold 1 is set to 10, which means it specifies a range of values from, and including, 0 up to, and including, 10. This range is referred to as Threshold 1 range. In the same figure, Threshold 2 is set to 23, which means it specifies a range of values from, but not included, the value of Threshold 1 (which is 10) up to, and including, 23. This range of values is referred to as Threshold 2 range. In the figure, Threshold 2 is set to 45, which means it specifies a range of values from, but not included, the value of Threshold 3 (which is 23) up to, and including, 45. This range of values is referred to as Threshold 3 range of value.
Page 596 of 968
11 September 2009
In this example, if the observed value is > than Threshold 3 (e.g., it equals 54), it belongs to no range of values. As a result, in that case, no credit is granted.
17.2.2.5. Specifying Whether some Credit Is Associated with a Range or Not

The current Terms of Credit Grant grant some credit only if the observed value belongs to a range of values that is associated with a Top-Up profile. A range of values that is associated with a Top-Up Profile is said to be a range of values that grant some credit. To indicate that Threshold N range (where N represents an integer value >=1 and < 5) of values grants some credit, associate a Top-Up Profile with the range by indicating in Top-Up Profile N the name of a Top-Up profile. To indicate that Threshold N range (where N represents an integer value >=1 and < 5) of values grants no credit, associate no Top-Up Profile with the range by leaving Top-Up Profile N parameter empty.
Figure 271 - Grant Tool GUI - Associating a Credit or No Credit with a Range In the above figure, if the observed value belongs to Threshold 1 range of value (which is from, and including, 0 up to, and including, 10), a credit will be granted because Top-Up Profile 1 parameter specifies a Top-Up Profile. In the above figure, if the observed value belongs to Threshold 2 range of value (which is from, but not including, 10 up to, and including, 23), no credit will be granted because Top-Up Profile 2 parameter specifies no Top-Up Profile.
11 September 2009
Page 597 of 968
Rewarding Accounts
In the above figure, if the observed value belongs to Threshold 3 range of value (which is from, but not including, 23 up to, and including, 45), a credit will be granted because Top-Up Profile 3 parameter specifies a Top-Up Profile. In the above figure, if the observed value belongs to none of the range of values specified (i.e., the observed value is > 45), no credit is granted.
17.2.2.6. Indicating How the Granted Credit Has to Be Computed

The granted credit can be either an Absolute value or calculated as a Percentage. Moreover, when the credit is calculated as a percentage, it can be calculated either in Tiered mode or in Tapered mode. There are thus three possible ways to compute a credit, which the next sections address.
Page 598 of 968
11 September 2009
17.2.2.6.1.Indicating How to Compute an Absolute Credit

To indicate that any credit granted by the Terms of a Credit Grant is absolute, you need to check Absolute radio button. You specify any Absolute credit in the form of a Top-Up profile. Granting a credit then corresponds in executing the Top-Up Profile that is associated with the range of value to which the observed value belongs.
Figure 272 - Grant Tool GUI - Specifying How to Compute an Absolute Credit In the above figure, if the observed value belongs to Threshold 1 range (i.e., the observed value is >= 0 and <= 10), a credit is granted because Top-Up Profile 1 parameter specifies a Top-Up Profile. Moreover, since Absolute radio button is selected, the credit to grant is an absolute credit. The CRE thus grants the credit by executing a Top-Up that refers to the Top-Up Profile that Top-Up Profile 1 parameter specifies. In the above figure, if the observed value belongs to Threshold 2 range (i.e., the observed value is > 10 and <= 23), no credit is granted since Top-Up Profile 2 parameter is empty. In the above figure, if the observed value belongs to Threshold 3 range (i.e., the observed value is > 23 and <= 45), a credit is granted because Top-Up Profile 3 parameter specifies a Top-Up Profile. Moreover, since Absolute radio button is selected, the credit to grant is an absolute credit. The CRE thus grants the credit by executing a Top-Up that refers to the Top-Up Profile that Top-Up Profile 3 parameter specifies.
11 September 2009
Page 599 of 968
Rewarding Accounts
Note: Because an absolute credit is specified in the form of a Top-Up profile, you can make an absolute credit refill the current Accounts main balance and one or more current Accounts bundles with different quantities.
17.2.2.6.2.Indicating How to Compute a Percentage Credit

You specify a Percentage credit: By selecting Percentage radio button in the current Terms of Credit Grant, and By indicating some percentage value in Percentage parameter of each range of values that is defined in the current Terms of Credit Grant, and By indicating whether the credit calculation has to be done in Tapered or in Tiered mode. You indicate Tapered mode calculation by selecting Tapered radio button. You indicate Tiered mode calculation by selecting Tiered radio button.
Figure 273 - Grant Tool GUI - Specifying How to Compute a Percentage Credit In the above figure, because Percentage radio button is selected, you need to specify some percentage value in the Percentage parameter of each range of values that is defined. For Threshold 1 range of value, the percentage that applies to the range amounts to 25%, since the Percentage parameter that applies to that range of values specifies 25.
Page 600 of 968
11 September 2009
For Threshold 2 range of value, the percentage that applies to the range amounts to 110%, since the Percentage parameter that applies to that range of values specifies 110. For Threshold 3 range of value, the percentage that applies to the range amounts to 37%, since the Percentage parameter that applies to that range of values specifies 37. According to the figure, the calculation of any granted credit will be done in Tapered mode, since Tapered radio button is selected.
17.2.2.6.3.What Is Tapered Mode Calculation?

By referring to the range to which the observed value belongs as the observed range, the Tapered mode calculation of any credit to grant, as performed by the CRE, could be explained as follows: 1. Do the following calculation: observed value * (value of Percentage parameter of observed range) / 100. 2. The calculation from previous step was done using the number of decimals that Computing Precision* parameter, of the Service Retailer to which the Terms of Credit Grant belong, specifies. This step rounds that calculation as Decimal Precision* and Rounding Method* parameters of the Service Retailer specify. The granted credit is the one that previous step calculated.
3.
Figure 274 - Grant Tool GUI - What Is Tapered Mode
11 September 2009
Page 601 of 968
Rewarding Accounts
In the above figure, if the observed value belongs to Threshold 1 range (say that observed value equals 7), some credit has to be granted, since Top-Up Profile 1 parameter specifies a Top-Up Profile. Because Percentage radio button is selected, the Percentage parameters of the value ranges have to be used for calculating the credit to grant. But, because Tapered mode radio button is selected, only Percentage parameter of the Threshold 1 range is used by the calculation. The credit to grant is calculated as follows: 7* 25 / 100. Because Grant Bonus to Main Balance is selected, the calculated credit is granted to the main balance of the current Account (the one of the Top-Rule that caused the execution of the current Terms of Credit Grant). On the other hand, if Grant Bonus in form of Bundle were selected, the calculated credit would have been given to the first bundle from the Top-Up Profile that Top-Up Profile 1 parameter specifies. This is of course a bundle of the current Account. In the above figure too, if the observed value belongs to Threshold 2 range (say that observed value equals 21), no credit is granted since Top-Up Profile 2 parameters specifies no Top-Up profile. In the above figure, if the observed value belongs to Threshold 3 range (say that observed value equals 29), some credit has to be granted, since Top-Up Profile 3 parameter specifies a Top-Up Profile. Because Percentage radio button is selected, the Percentage parameters of the value ranges have to be used for calculating the credit to grant. But, because Tapered mode radio button is selected, only Percentage parameter of the Threshold 3 range is used by the calculation. The credit to grant is calculated a s follows: 29* 37 / 100. Because Grant Bonus to Main Balance is selected, the calculated credit is granted to the main balance of the current Account (the one of the Top-Rule that caused the execution of the current Terms of Credit Grant). On the other hand, if Grant Bonus in form of Bundle were selected, the calculated credit would have been given to the first bundle from the Top-Up Profile that Top-Up Profile 3 parameter specifies. This is of course a bundle of the current Account. In the above figure, if the observed value belongs to no defined range (in the example of the above figure, this means that the observed value is > 45), no credit is granted at all.
Page 602 of 968
11 September 2009
17.2.2.6.4.What Is Tiered Mode Calculation?

In Tiered mode calculation (and unlike the Tapered mode calculation, in which only the observed range contributes to the credit calculation), all the ranges up to, and including, the observed range, contribute to the credit calculation.

Thus, if Threshold 3 range is the observed range (i.e., the range to which the observed value belongs), Threshold 1 range and Threshold 2 range will contribute to the calculation. But Threshold 4 and Threshold 5 ranges will not contribute to the calculation. That other ranges than the observed range can contribute to the credit calculation explains why this mode is called Tiered mode, since a range could also be viewed as a tier.
In Tiered mode, the credit calculation could be explained as follows: 1. For each Threshold N range (N represents the number assigned to the currently considered range, with 1 <= N <= 5) up to the observed range, but this latter range being excluded, calculate the contribution of the range as follows: If N equals 1, the range contribution equals: (value of Threshold 1 parameter) * (value of ranges Percentage parameter) Else the range contribution equals: (value of Threshold N parameter - value of Threshold N-11 parameter) * (value of ranges Percentage parameter)
2.
Calculate the contribution of the observed range as follows, assuming that N represents the number assigned to the observed range: If N equals 1, the observed range contribution equals: (observed value) * (value of ranges Percentage parameter) Else, the observed range contribution equals: (observed value - value of Threshold N-1 parameter) * (value of ranges Percentage parameter)
3. 4.
Add up (make the sum of) all the calculations that were done at previous steps and divide the result by 100. All the calculations done in previous step were done using the number of decimals that Computing Precision* parameter, of the Service Retailer to which the Terms of Credit Grant belong, specifies. This step rounds the calculation from previous step as Decimal Precision* and Rounding Method* parameters of the Service Retailer specify. The granted credit is the one that previous step calculated.
5.
1. Threshold N-1 is the highest Threshold parameter value that is less than Threshold N parameter value.
11 September 2009
Page 603 of 968
Rewarding Accounts
Figure 275 - Grant Tool GUI - What Is Tiered Mode In the above figure, if the observed value belongs to Threshold 1 range (say that observed value equals 7), some credit has to be granted, since Top-Up Profile 1 parameter specifies a Top-Up Profile. Because Percentage radio button is selected, the Percentage parameters of the value ranges have to be used for calculating the credit to grant. But, because Tiered mode radio button is selected, the Percentage parameter of Threshold 1 range, and of all ranges up to it (but there are no such ranges since Threshold 1 is the first range), is used by the calculation. The credit to grant is calculated as follows: 7* 25 / 100 since only one range has to be considered in this case. Because Grant Bonus in form of Bundle is selected, the calculated credit is granted to the first bundle from the Top-Up Profile that Top-Up Profile 1 parameter specifies (this is of course a bundle of the current Account). On the other hand, if Grant Bonus to Main balance were selected, the calculated credit would have been given to the main balance of the current Account. In the above figure too, if the observed value belongs to Threshold 2 range (say that observed value equals 21), no credit is granted since Top-Up Profile 2 parameters specifies no Top-Up profile. In the above figure, if the observed value belongs to Threshold 3 range (say that observed value equals 29), some credit has to be granted, since Top-Up Profile 3 parameter specifies a Top-Up Profile. Because Percentage radio button is selected, the Percentage parameters of the value
Page 604 of 968
11 September 2009
ranges have to be used for calculating the credit to grant. Moreover, because Tiered mode radio button is selected, the Percentage parameter of Threshold 3 range, and of all ranges up to it, are used by the calculation. The credit to grant is calculated as follows: (10 * 25 + (23 - 10) * 110 + (29 - 23) * 37) / 100 since Threshold 1 range and Threshold 2 range contribute to the calculation, in addition to Threshold 3 range (which is the observed range). Because Grant Bonus in form of Bundle is selected, the calculated credit is granted to the first bundle from the Top-Up Profile that Top-Up Profile 3 parameter specifies (this is of course a bundle of the current Account). On the other hand, if Grant Bonus to Main balance were selected, the calculated credit would have been given to the main balance of the current Account.
11 September 2009
Page 605 of 968
Rewarding Accounts
17.2.2.7. Indicating Which Accounts Value Sub-Repository Is Granted Credit

An Account is a value repository and that value is spread over the sub-repositories of the Account. These Accounts value sub-repositories are: The Accounts main balance, and The Accounts bundles. Whenever you set up the Terms of a Credit Grant, you need to specify which value sub-repository (or which value sub-repositories) of the current Account will receive any granted credit.
17.2.2.7.1.When Absolute Radio Button Is Checked

When Absolute radio button is checked, it is the Top-Up Profile that is associated with the observed range that indicates which sub-repositories of the current Account receive which credit. That way, you can give at the same time some credit to the current Accounts main balance and/or one or more current Accounts bundles. Moreover, the credit one sub-repository receives can be different from the one that any other sub-repository receives.
17.2.2.7.2.When Percentage Radio Button is Checked

When Percentage radio button is checked, you cannot grant at the same time credit to more than one sub-repository of the current Account.
In that case, you first need to decide whether the credit will be granted to the current Accounts main balance or to one of its bundles. To have the credit granted to the main balance of the current Account, you need to do what follows: Select Grant Bonus to Main Balance radio button. To have the credit granted to a bundle of the current Account, you need to do the following steps: Select Grant Bonus in form of Bundle radio button, For each range of values that the current Terms of Credit Grant define, make sure that the Top-Up Profile that is associated with the range mentions as its first bundle the bundle that has to receive the credit that the range of values grants. Note: As a result, each range of values can make a different bundle receive its credit, since each range of value can be associated with a different Top-Up Profile. Note: Any other bundle that a range of values Top-Up Profile specifies is ignored.
Page 606 of 968
11 September 2009
Figure 276 - Grant Tool GUI When Neither Absolute Nor Percentage Radio Buttons Are Checked
11 September 2009
Page 607 of 968
Rewarding Accounts
Figure 277 - Grant Tool GUI When Absolute Radio Button Is Checked
Page 608 of 968
11 September 2009
Figure 278 - Grant Tool GUI When Percentage Radio Button Is Checked
Table 208 - Grant Tool Parameter Service Retailer* Account Profile* Description Reference to the service retailer to which the current Terms of Credit Grant belong. The current Terms of Credit Grant need to know to which Accounts they apply. You give them that information by indicating here to which Account Profile they have to apply. Enter here the name of that Account Profile (this corresponds to Account Profile Name* parameter of the Account profile). At time a Top-Up rule executes (this always happens via a Grant criterion) the current Terms of Credit Grant, these terms are ignored by the Top-Up rule if the current Account of the rule is not associated with the Account Profile that the current Terms of Credit Grant specify.
11 September 2009
Page 609 of 968
Rewarding Accounts
Table 208 - Grant Tool Parameter Name Description Name of the current Terms of Credit Grant. When two Terms of Credit Grant do not refer to the same Account Profile, they may give the same value to their Name parameter. Else, they are not allowed to do that. This makes it possible for a Grant criterion to use the same Terms of Credit Grant name to refer to Accounts that belong to different Account Profiles. Bonus Tool GUI frame Absolute Select this radio button if you want to specify in the form of a Top-Up Profile any credit you associate with a range of values that the current Terms of Credit Grant define. As a result, whenever the observed value belongs to a range of values that specifies a Top-Up Profile, the credit that the Top-Up Profile specifies is granted. That is, the CRE then executes a Top-Up that refers to the Top-Up Profile.
On associating a Top-Up Profile with a range of values, see Top-Up Profile N, on page
615.
As any credit to be granted is specified as a Top-Up Profile and since a Top-Up Profile only specifies fixed values that are independent of any other values, this kind of credit grant is said to be absolute.
As soon as this radio button is selected, the following radio buttons are greyed out by the Grant Tool GUI, since they then do not apply: Grant Bonus to Main Balance Grant Bonus in Form of Bundle Tiered Tapered None Moreover, as soon as this radio button is selected, the following parameters are greyed out by the Grant Tool GUI, since they then do not apply: The Percentage parameters that you find in Tiers/Tapers GUI frame get greyed out.
Page 610 of 968
11 September 2009
Thus, selecting this radio button enables you to have the main balance and/or one or more bundles, of the concerned Account, simultaneously refilled upon a credit grant of the current Terms of Credit Grant. This is a feature unique to the Grant Tool object.
Table 208 - Grant Tool Parameter Percentage Description Whenever this radio button is checked, any credit granted by a range of values, that the current Terms of Credit Grant defines, must be specified in the form of percentages. That is, whenever this radio button is checked, the Percentage parameter of each defined range of values of the current terms of a Credit Grant must have a value. As soon as Percentage radio button has been selected, the two following radio buttons become ungrayed: Grant Bonus to Main Balance Grant Bonus in Form of Bundle Make then sure that you select one of these two buttons. The three following radio buttons also become ungrayed as soon as Percentage radio button is selected: Tiered Tapered None
Make then sure that you select either Tiered or Tapered. Finally, the following parameters become also ungrayed as soon as Percentage radio button is selected: The Percentage parameter of each range of values.
11 September 2009
Page 611 of 968
Rewarding Accounts
Table 208 - Grant Tool Parameter Counter Description When Top-Up Value for Threshold Comparison check box is checked, you can leave this parameter empty. When Top-Up Value for Threshold Comparison check box is unchecked, the observed value of the current Terms of Credit Grant is a counter. You then need to enter into this parameter the name of that counter.

That is, enter here the value of Name* parameter of some instance of Bundle/Counter Usage Label object that is of type Counter. Make sure that some instance of Account Profile and Usage Link object refers to both the counter and to the Account Profile that Account Profile* parameter specifies. Make also sure that the counter is set up for each Account of the Account Profile. That is, for each Account of the Account Profile, make sure that some instance of Counter object refers to both the Account and to the counter.
Therefore, whenever using a counter as the observed value of the current Terms of Credit Grant, make sure that the counter value is suitably managed by some Counter criterion that refers to the counter. Counter Reset Check this box if you want that the current Terms of Credit Grant reset the counter, that their Counter parameter specifies, every time, and just after, they have granted some credit. Uncheck this box if you want that the current Terms of Credit Grant never reset the counter. Top-Up Value for Threshold Comparison Indicate here which kind of value the current Terms of Credit Grant use as their observed value. Check this parameter if the observed value has to be Nominal Value (Money) parameter from the Top-Up Profile of the current network event (which is a Top-Up RTx request). Uncheck this parameter if the observed value has to be a counter. In this case, do not forget to specify a counter name into Counter parameter of the current Terms of Credit Grant. Grant Bonus to Main Balance
This parameter is of no use when Absolute radio button is selected.
Whenever this radio button is selected, any credit granted by the current Terms of Credit Grant is given to the main balance of the current Account, provided the current Account is associated with the Account Profile that Account Profile* parameter specifies.
Page 612 of 968
11 September 2009
Although the current Terms of Credit Grant can be configured to reset their counter just after they have granted a credit (see this objects Counter Reset parameter), the current Terms of Credit Grant do not manage the value of their counter. Updating (e.g., incrementing) the value of that counter is something that is typically done by means of some Counter criterion that some rules uses.
Table 208 - Grant Tool Parameter Grant Bonus in Form of Bundle Description
Whenever this radio button is selected, any credit granted by the current Terms of Credit Grant is given to some bundle of the currently concerned Account, provided the current Account is associated with the Account Profile that Account Profile* parameter specifies.
That bundle is specified via one of the Top-Up Profile N parameters of the current Terms of Credit Grant.
which Top-Up Profile N parameter specifies that bundle and how it specifies that bundle.
See the documentation of Top-Up Profile N parameter in this table to know
Tiered
Whenever this radio button is checked, any credit, which the current Terms of Credit Grant give, is computed in Tiered mode.
On Tiered mode computation, see 17.2.2.6.4, What Is Tiered Mode Calculation?,

on page 603 and its Tiered mode calculations examples.
Tapered
Whenever this radio button is checked, any credit, which the current Terms of Credit Grant give, is computed in Tapered mode.
On Tapered mode computation, see 17.2.2.6.3, What Is Tapered Mode

Calculation?, on page 601 and its Tapered mode calculations examples.
None
This parameter is not used.
11 September 2009
Page 613 of 968
Rewarding Accounts
Table 208 - Grant Tool Parameter Description
Threshold N Range of Value (i.e., N th Row, from the Top of Tiers/Tapers GUI Frame) Percentage
This must be an unsigned integer value. If Percentage radio button is selected and Threshold N parameter on the same row as this parameter contains a value, you need to enter a value into this parameter.
This value will be used to calculate the granted credit as section 17.2.2.6.3, What Is Tapered Mode Calculation?, on page 601, and section 17.2.2.6.4, What Is Tiered Mode Calculation?, on page 603, explain.
Threshold N
This must be an unsigned integer value. You define a range of values by entering a value into this parameter. This must be the highest value of the range. That range of values is called Threshold N range of value.
For example, if you entered a value in Threshold 2 parameter, you defined Threshold 2 range of value.
When N > 1, the range of values comprises all the values from, but not including, the value of parameter Threshold N-1 up to, and including, the value of Threshold N parameter. When N equals 1, the range of values comprises all the values from, and including, 0 up to, and including, the value of Threshold N parameter
For example, if Threshold 3 (N equals 3) parameter is set to 67 and Threshold 2 (N-1 equals 2) parameter is set to 34, Threshold 3 range of values contains all values from, but not including, 34 up to, and including, 67.
Whenever the observed value belongs to Threshold N range of value, the current Terms of Credit Grant will grant a credit to the current Account (of the Top-Up rule executing the current Terms of Credit Grant) if, and only if: Top-Up Profile N specifies a Top-Up Profile The Account is associated with the Account Profile of the current Terms of Credit Grant. The current Top-Up RTx request (i.e., the Top-Up rules current network event) could be successfully executed.
Enter the Threshold N values in increasing order. That is, if Threshold X and Threshold Y each contain a value, and X < Y, then Threshold Xs value must be less than Threshold Ys value. Naturally, X and Y have to be substituted by some value >= 1 and <= 5.
Page 614 of 968
11 September 2009
Table 208 - Grant Tool Parameter Top-Up Profile N Description If Threshold N parameter on the same row as this parameter contains a value, you need to indicate whether the range of values that Threshold N parameter defines (this is the so-called Threshold N range of values) grants some credit or not. To indicate that the range of values does not grant any credit, leave this parameter empty. To indicate that the range of values grants some credit, specify a Top-Up Profile into this parameter. If Absolute Radio Button Is Selected When Absolute radio button is selected, any credit granted by a range of values has to be indicated in the form of a Top-Up Profile. As a result, for each range of values defined, specify that Top-Up Profile into Top-Up Profile N parameter of that range. For example, if Threshold 2 parameter contains a value and Absolute radio button is selected, enter into Top-Up Profile 2 parameter the Top-Up Profile that the CRE automatically executes as a Top-Up when the observed value belongs to Threshold 2 range.
The Top-Up Profile executed as a credit grant then indicates which subrepositories of the current Account receive a credit and how much credit each of these sub-repositories receives. If Percentage and Grant Bonus to Main Balance Radio Buttons Are Selected When Percentage and Grant Bonus to Main Balance radio buttons are selected, this parameter is only used to indicate whether Threshold N range of values grant some credit or not whenever the observed value belongs to that range. That is, as the CRE then knows which sub-repository (it is the main balance) of the current Account is to be credited and as the Percentage parameters are used to compute the credit to grant, the information in the Top-Up Profile that this parameter specifies is not used. If Percentage and Grant Bonus in Form of Bundle Radio Buttons Are Selected When Percentage and Grant Bonus in form of Bundle radio buttons are selected, this parameter is not only used to indicate whether Threshold N range of values grant some credit or not in case the observed value belongs to that range. It is also used to indicate which bundle of the current Account will receive the credit granted by the range of values to which this parameter belongs. That bundle is the first bundle that is mentioned by the Top-Up profile that this parameter specifies. This is the bundle that the highest row of Bundles tab, of the Top-Up Profile, mentions. As the Percentage parameters are used to compute the credit to grant, no crediting information is taken from the Top-Up Profile, apart from the fact that the Top-Up profile indicates which bundle is to be credited.
11 September 2009
Page 615 of 968
Rewarding Accounts
17.3. Discount Object

Note: Although the name of this object is a misnomer (this object never grants any discount but only credits), this manual keeps referring to this object by calling it the Discount object.
17.3.1.1. Rewarding a Postpaid Account with Some Credit

With the Discount object, you make the CRE reward a Postpaid Accounts main balance with some credit whenever the Account fulfills some condition. More accurately said, an instance of Discount object specifies: On what conditions any Account, that is linked to the instance of Discount object, is rewarded with some credit (the credit is always expressed in terms of money), and How the granted credit has then to be computed. An instance of Discount object is said to specify the terms of a discount. If you already read section 17.2.1, Object Purpose, on page 590 (it is part of section 17.2, Grant Tool Object, on page 590), you will certainly be struck by the similarities between the Grant Tool objects purpose and the Discount objects purpose.
If you however compared the Object Purpose section of the two objects, you certainly noted the following differences: A credit that an instance of Discount object gives is always expressed in money. On the other hand, a credit granted by an instance of Grant Tool object is not necessarily expressed in terms of money. It could also be expressed as some units to grant to some bundle. A credit that an instance of Discount object grants can only be granted to a Postpaid Account. On the other hand, the Grant Tool object, although it currently only grants credit upon a Top-Up, does not make such a distinction. A credit granted by the Discount object is always given to the main balance, while a credit granted by the Grant Tool object can be given to the main balance and/or to some bundle(s).
17.3.1.2. When You Should Use the Discount Object

See Table 220, Comparing the Grant Tool, the Discount and the Promotion Tool Objects, on page 695.
Page 616 of 968
11 September 2009
17.3.1.3. Making the CRE Apply the Terms of a Discount on an Account

Whenever you need to set up some Terms of a Discount on an Account, proceed as follows: 1. 2. If the Terms of a Discount (i.e., the instance of Discount object that specifies the terms of the discount to apply) are not yet set up, set them up by suitably creating an instance of Discount object. If that is necessary, make sure that Postpaid Discount Mode parameter, of the Service Retailer to which the Account and the Terms of a Discount belong, is suitably set up.

3.
To know whether you need to choose a value for this parameter, and how to choose that value, see Postpaid Discount Mode, on page 144.
Indicate the magnitude of the regular time intervals at which the CRE checks whether the Account benefits of some credit from these Terms of a Discount. Its Billing Date Period parameter, of the Account Profile of the Account, that indicates the magnitude of these time intervals. This means that the same time interval applies to the computation of any Terms of a Discount that apply on any Account belonging to the same Account Profile. Thus, if Billing Date Period, of the Account Profile of the Account, is already set to some value and some Terms of Discount already apply to Accounts of the Account Profile, you will probably have to go with the value to which Billing Data Period parameter is already set.

4.
See also Billing Date Period, on page 722.
Indicate the date and time at which you want that the CRE checks for the first time whether the Account benefits of some credit from these Terms of a Discount. Its Next Discount DT parameter, of the Account, that indicates that date and time. Since this parameter belongs to the Account, it applies to any Terms of a Discount that applies to the Account. Thus, if Next Discount DT parameter, of the Account, is already set to some value and some Terms of Discount already apply to the Account, you will probably have to go with the value to which Next Discount DT parameter, of the Account, is already set. You can modify this parameter at any time. The CRE however recomputes Next Discount DT parameter every time it checks whether some Terms of a Discount give a credit to the Account, by adding Billing Date Period to the current value of Next Discount DT parameter. Of course, whenever you modify this parameter, the change applies to the credit computation moment of any Terms of a Discount that apply to the Account.

5.
See also Next Discount DT, on page 768.
Indicate to the CRE that it has to apply these Terms of a Discount on the Account. For that, suitably create an instance of Account Discount object that refers to both the Account and these Terms of a Discount. Note: If you want it, you can apply several Terms of a Discount to the same Account. You do that by creating one instance of Account Discount object per Terms of a Discount to apply on the Account, where each instance refers to the Account.

6.
See also 17.4, Account Discount Object, on page 650.
Make sure that the OOC is on.
11 September 2009
Page 617 of 968
Rewarding Accounts

7.
See also Out Of Call, on page 32. See also 5.2.4, Out of Call Object, on page 194.
Make sure that the OOC is set up to regularly run the macro that processes Postpaid Discounts.

See also Out Of Call, on page 32. See also 5.2.5, Out of Call TimeBand Object, on page 198.
Page 618 of 968
11 September 2009
17.3.2. How a Discount Works

Basically, the Terms of a Discount: Indicate some quantity to observe (hereby called the observed quantity), and Define up to five range of values, and Associate with each range of values some credit, and Indicate how the credit associated with each range has to be computed. If the OOC is set up to regularly run the macro that takes care of the Postpaid Discounts, the OOC regularly reviews each CRE Account in order to check whether its Next Discount DT date is already reached or not. If it is reached, the OOC computes, and gives to the Account, the credits given by the various Terms of a Discount that apply to the Account. After this, the OOC updates Accounts Next discount DT parameter by adding Billing Date Period to the current value of Next Discount DT. Note: If, at time it processes either an fstreq, a oneshot or a getandcheckppm RTx request, the CRE sees that Next discount DT, of the concerned Account, is already reached, the CRE computes and gives all the credits from the Terms of a Discount that apply to the concerned Account. It afterwards updates Next Discount DT to the date and time of the next credit computation moment of the Terms of a discount that apply to the Account.
At time some Terms of a Discount get executed on an Account, the CRE compares the value of their quantity to observe against their range of values, in order to find out to which range the value of the quantity to observe belongs. If the value of the quantity to observe belongs to no range of values, no credit is granted. Otherwise, the value of the quantity to observe belongs to one of the ranges, and the Terms of Discount then computes the credit that is associated with the range to which the value of the quantity to observe belongs. It then adds the computed credit to the Accounts main balance.
11 September 2009
Page 619 of 968
Rewarding Accounts

This section explains the following terms: The current Terms of Discount The current Account The observed value The value to reward The observed range. The current Terms of Discount correspond to the instance of Discount object that is being processed in consequence of the Next Discount DT date time of some Account being reached. The current Account is the Account to which the current Terms of Discount apply. The observed value is the current value of the quantity that the current Terms of Discount observe. The value to reward. The credit that the Terms of a Discount give is either specified in terms of absolute values or in terms of percentage values. Whenever the credit is calculated by means of percentages, the question is: On what value must these percentages be applied. That value, on which the percentages have to be applied, is called the value to reward. Traffic consumption is an example of a value that could be rewarded. Note: For the Discount object, the value to reward must always be expressed in terms of money. Note: The value to reward of an instance of Grant Tool object is always the same as the observed value of the instance. This is why the documentation of Grant Tool object never talks about the value to reward. The observed range is the range of values, of the current Terms of Discount, to which the value of the observed quantity, of the current Terms of discount, belongs.
Page 620 of 968
11 September 2009
17.3.2.3. Specifying the Quantity to Observe

You use Calculation Perimeter* GUI frame to specify the quantity that the Terms of a Discount have to observe. The quantity that the Terms of a Discount have to observe is: Either an original parameter of the Account. That is, an Accounts parameter that is not an ARENA parameter. Or an ARENA parameter of the Account. Or a counter of the Account.
Figure 279 - Discount GUI - Specifying the Quantity to Observe You use Calculation Perimeter* GUI frame, of Perimeters tab, to indicate which quantity the current Terms of Condition have to observe. If the observed value has to be an original parameter of the Account: Select Account Original Attribute radio button. Click on the black solid triangle to the right of the parameter just below Counter radio button. In the drop-down menu that then appears, select the Accounts original attribute that is to be the observed value of the current Terms of Discount. If the observed value has to be an ARENA parameter of the Account: Select Arena radio button.
11 September 2009
Page 621 of 968
Rewarding Accounts
Click on the black solid triangle to the right of the parameter below Counter radio button. In the drop-down menu that then appears, select the Accounts ARENA attribute that is to be the observed value of the current Terms of Discount. If the observed value has to be a counter of the Account: Select Counter radio button. In the parameter below Counter radio button, specify the Accounts counter that is to be used as the observed value of the current Terms of Discount.
Page 622 of 968
11 September 2009
17.3.2.4. Specifying the Value Ranges

The Discount object specifies a range of values by specifying the lower value of the range. That lower value is called a threshold. Note: Contrast this with what the Grant Tool object does: The Grant Tool object specifies a range of values by specifying the upper value of the range. Unlike the Grant Tool object, you indicate to the Discount object how many (but not more than 5) range of values you want to set up. For that, you use Number of Thresholds parameter from the Discount Options and Thresholds tab. In the figure below, Number of Thresholds parameter is set to 3. As a result, 3 rows with parameters appear in both Thresholds and Discounts GUI frames.
Threshold 1 range of values goes from 10 to 23, without 23. Threshold 1 parameter value is set to 10.
Threshold 2 range of values goes from 23 to 45, without 45. Threshold 2 parameter value is set to 23. Threshold 3 range of values is everything >= 45. Threshold 3 parameter value is set to 45. Indicate here the credit associated with Threshold 3 range of values.
This is the number of range of values you want to set up. You can specify up to 5 range of values.
Indicate here the credit associated with Threshold 1 range of values.
Indicate here the credit associated with Threshold 2 range of values.
Figure 280 - Discount GUI - Specifying the Value Ranges In the above figure, the lowest parameter in Thresholds GUI frame is set to 45. Because it is the lowest one, it specifies the range of all the values that are greater or equal to 45. Because this parameter is third from the top of the Thresholds GUI frame, it is said to specify threshold 3 range of values. And this parameter value is called threshold 3 parameter value (in short, threshold 3 value). Still in the above figure, the parameter that is second from the top of Thresholds GUI frame is set to 23. Because the parameter that is just below it contains 45, the parameter that contains 23 specifies a range of value that goes from, and including, 23 to, but not included, 45. Because this parameter is
11 September 2009
Page 623 of 968
Rewarding Accounts
second from the top of the Thresholds GUI frame, it is said to specify threshold 2 range of values. And this parameter value is called threshold 2 parameter value (in short, threshold 2 value). Finally, the parameter that appears at the top of Thresholds GUI frame is set to 10. Because the parameter that is just below it contains 23, the parameter that contains 10 specifies a range of value that goes from, and including, 10 to, but not included, 23. Because this parameter is first from the top of the Thresholds GUI frame, it is said to specify threshold 1 range of values. And this parameter value is called threshold 1 parameter value (in short, threshold 1 value). In the example of this figure, if the observed value is < 10 (e.g., it equals 7), it belongs to no range of values. As a result, in this case, no credit is granted.
17.3.2.5. Specifying Whether some Credit Is Associated with a Range or Not

Like the Grant Tool object, you associate a credit (whether it is expressed as an absolute value or as a percentage) with each defined range of values. However, unlike the Grant Tool object, the Discount object foresees nothing for indicating that no credit is to be granted whenever the observed value belongs to a given a range of values. Of course, you can always associate a zero credit value (i.e., either a zero absolute value or a zero percentage) with a given values range. But this will not prevent the granting of a credit when the other range of values can also contribute to the credit computation, which is the case when the credit is computed in tiered mode. Note: Section 17.3.2.7.5, What Is Tiered Mode Calculation?, on page 634, explains tiered mode credit computation, in which more than one range of values (i.e., tiers) can contribute to the computation of the credit. Note: You select tiered mode credit computation by selecting Continuous radio button, from Discount Options and Thresholds tab.
Page 624 of 968
11 September 2009
17.3.2.6. Enabling/Disabling VAT on the Current Terms of Discount

Depending on how VAT GL Code* parameter of the current Terms of Discount is configured, the credit granted to the Accounts main balance includes the VAT or not.
To know the details on enabling/disabling VAT on the current Terms of Discount, see VAT GL Code*, on page 638.
Whenever VAT is enabled on the current Terms of Discount, the current Terms of Discount compute the credit to grant as follows: 1. The current Terms of Discount first compute the credit without taking the VAT into Account. The result of this computation is the part of the credit to grant that is exclusive of VAT. 2. The VAT, which is expressed as a percentage, is then applied to the part of the credit to grant that is exclusive of VAT that previous step computed. The result of this computation is hereby called the VAT part of the credit to grant. 3. The credit to grant is computed by adding the part of the credit to grant that is exclusive of VAT to VAT part of the credit to grant.
Naturally, whenever VAT is disabled, only the first of the above steps is performed and the credit to grant then equals the part of the credit to grant that is exclusive of VAT.
17.3.2.7. Indicating How the Granted Credit Has to Be Computed

Like the Grant Tool object, the credit that the Terms of a Discount grant can be either an Absolute value or calculated as a Percentage. Moreover, when the credit is calculated as a percentage, it can be calculated either in Tiered mode or in Tapered mode. Note: With the Discount object, A credit that is not calculated by means of percentages is called a Rebate. The Grant Tool object calls such a credit an absolute credit. In the text, the term absolute credit is used. Tiered mode is called Continuous mode, Tapered mode is called Discontinuous mode There are thus three possible ways to compute a credit, which the next sections address.
11 September 2009
Page 625 of 968
Rewarding Accounts
17.3.2.7.1.Indicating How to Compute an Absolute Credit

To indicate that any credit granted by the Terms of a Discount is absolute, you need to do what follows in Discount Options and Thresholds tab: Select Rebate radio button, from Discount Type* GUI frame. Select Discontinuous radio button, from Computation Mode GUI frame. Associate some absolute credit value with each of the range of values defined. That is, enter a positive value into each parameter of Discounts GUI frame that is on the same horizontal line as a non-empty parameter of Thresholds GUI frame.
Figure 281 - Discount GUI - Specifying How to Compute an Absolute Credit For example, in the above figure, the credit that is associated with threshold 1 range of values amounts to 26. That value appears in the top parameter of the Discounts GUI frame, which is at the same level than Thresholds GUI frames parameter for threshold 1 range of values. Because Rebate radio button is selected, 26 is considered as an absolute credit. As another example, in the above figure, the credit that is associated with threshold 2 range of values amounts to 36. And the one that is associated with threshold 3 range of values amounts to 46. Because Rebate radio button is selected, each of these credits is considered as an absolute credit. In the above figure, if the observed value is < 10 (say the observed value equals 7), the observed value belongs to no range of values. Therefore, no credit is granted. In the above figure, if the observed value belongs to threshold 1 range (i.e., if the observed value is >= 10 and < 23), an amount of 26, expressed in the same units as the current Accounts main balance, is to
Page 626 of 968
11 September 2009
be granted to the current Account. If VAT is enabled on the current Terms of Discount, the VAT on 26 is added to the current Accounts main balance too. In the above figure, if the observed value belongs to threshold 2 range (i.e., the observed value is >= 23 and < 45), an amount of 36, expressed in the same units as the current Accounts main balance, is to be granted to the current Account. If VAT is enabled on the current Terms of Discount, the VAT on 36 is added to the current Accounts main balance too. In the above figure, if the observed value belongs to threshold 3 range (i.e., the observed value is > 45), an amount of 46, expressed in the same units as the current Accounts main balance, is to be granted to the current Account. If VAT is enabled on the current Terms of Discount, the VAT on 46 is added to the current Accounts main balance too.
11 September 2009
Page 627 of 968
Rewarding Accounts
17.3.2.7.2.Indicating How to Compute a Percentage Credit

You specify a Percentage credit: By selecting Percentage radio button, from Discount Type* GUI frame. By associating some percentage value with each of the ranges of values defined. That is, enter a positive value into each parameter of Discounts GUI frame that is on the same horizontal line as a non-empty parameter of Thresholds GUI frame. By indicating whether the credit calculation has to be done in Tapered or in Tiered mode. You indicate Tapered mode calculation by selecting Discontinuous radio button. You indicate Tiered mode calculation by selecting Continuous radio button.
Figure 282 - Discount GUI - Specifying How to Compute a Percentage Credit In the above figure, because Percentage radio button is selected, the credit associated with a given range of values will be used as a percentage. For threshold 1 range of values, the credit associated with the range amounts to 25%. It is so because the Discounts parameter that applies to that range of values specifies 25 and because Percentage radio button is selected, which means that 25 will be used as a percentage. For threshold 2 range of values, the credit associated with the range amounts to 110%. It is so because the Discounts parameter that applies to that range of values specifies 110 and because Percentage radio button is selected, which means that 110 will be used as a percentage.
Page 628 of 968
11 September 2009
For threshold 3 range of values, the credit associated with the range amounts to 37%. It is so because the Discounts parameter that applies to that range of values specifies 37 and because Percentage radio button is selected, which means that 37 will be used as a percentage. According to the figure, the calculation of any granted credit will be done in Tapered mode, since none of Discontinuous and Continuous radio buttons are selected and since the default value of Discontinuous radio button is that it is selected.
11 September 2009
Page 629 of 968
Rewarding Accounts
17.3.2.7.3.Specifying How the Value to Reward Must Be Calculated

Whenever Percentage radio button is selected, the credit to grant is computed by applying a percentage to some value. That value is the value to reward. Whenever Tiered mode is chosen (i.e., whenever Continuous radio button is selected), that value to reward must be the observed value. On the other hand, whenever Tapered mode is chosen (i.e., whenever Discontinuous button is selected), you need to specify what value is to be rewarded. That value to reward is then called the application perimeter. You use Application Perimeter* GUI frame to say how the value to reward is to be calculated whenever both Percentage and Discontinuous radio buttons are checked.
Keep in mind that the observed value is specified by means of Calculation Perimeter* GUI frame.
Figure 283 - Discount GUI - Specifying the Value to Reward To indicate how the value to reward of the current Terms of Discount has to be calculated whenever both Percentage and Discontinuous radio buttons are checked, do what follows in the Application Perimeter* GUI frame: 1. Indicate whether the value to reward is deduced from a counter or from the main balance. To indicate that the value to reward is deduced from the main balance of the current Account, select Main balance radio button. In this case, when the value of the main balance is > 0, the value to reward equals 0. Otherwise, the value to reward equals the opposite of the main balances value (i.e., if main balance value equals -24, the value to reward equals -(-24) = 24). To indicate that the value to reward is the value of a counter, select Counter radio button. In this case, the value to reward equals the value of the counter. 2. If you chose to select Counter radio button, indicate into Application Perimeter which counter gives the value to reward.
Page 630 of 968
11 September 2009
In the above figure, Counter radio button, of Application Perimeter* GUI frame, is selected. Therefore, the value to reward is the counter that Application Perimeter, of Application Perimeter* GUI frame, specifies. The name of that counter is count_stat.
11 September 2009
Page 631 of 968
Rewarding Accounts
17.3.2.7.4.What Is Tapered Mode Calculation?

In Tapered mode (which corresponds to Discontinuous radio button selected), the value to reward is specified by Application Perimeter* GUI frame. The Tapered mode calculation of any credit to grant, as performed by the CRE, could be explained as follows: 1. Do the following calculation: value to reward * (value of Discounts parameter of observed range) / 100. 2. The granted credit is the one that previous step calculated.
Figure 284 - Grant Tool GUI - What Is Tapered Mode In the above figure, if the observed value is < 10 (say the observed value equals 7), the observed value belongs to no range of values and no credit is granted to the current Accounts main balance. In the above figure, if the observed value belongs to threshold 1 range (say that observed value equals 16), what follows happens. Because Percentage radio button is selected, the Discounts parameter associated with threshold 1 range (which equals 25) is used as a percentage. Because Discontinuous radio button is checked, only the Discounts parameter that is associated with the observed range (it is threshold 1 range) is used to calculate the credit to grant. As a result, the current Terms of Discount add (value to reward) * 25 / 100 to the main balance of the current Account. Moreover, if VAT is enabled on the current Terms of Discount, the VAT on (value to reward) * 25 / 100 is added to the current Accounts main balance. In the above figure, if the observed value belongs to threshold 2 range (say that observed value equals 27), what follows happens. Because Percentage radio button is selected, the Discounts
Page 632 of 968
11 September 2009
parameter associated with threshold 2 range (which equals 110) is used as a percentage. Because Discontinuous radio button is checked, only the Discounts parameter that is associated with the observed range (it is threshold 2 range) is used to calculate the credit to grant. As a result, the current Terms of Discount add (value to reward) * 110 / 100 to the main balance of the current Account. Moreover, if VAT is enabled on the current Terms of Discount, the VAT on (value to reward) * 110 / 100 is added to the current Accounts main balance. In the above figure, if the observed value belongs to threshold 3 range (say that observed value equals 12,345), what follows happens. Because Percentage radio button is selected, the Discounts parameter associated with threshold 3 range (which equals 37) is used as a percentage. Because Discontinuous radio button is checked, only the Discounts parameter that is associated with the observed range (it is threshold 3 range) is used to calculate the credit to grant. As a result, the current Terms of Discount add (value to reward) * 37 / 100 to the main balance of the current Account. Moreover, if VAT is enabled on the current Terms of Discount, the VAT on (value to reward) * 37 / 100 is added to the current Accounts main balance.
11 September 2009
Page 633 of 968
Rewarding Accounts
17.3.2.7.5.What Is Tiered Mode Calculation?

In Tiered mode (which corresponds to Continuous radio button selected), the value to reward is specified by the observed value. In Tiered mode calculation (and unlike the Tapered mode calculation, in which only the observed range contributes to the credit calculation), all the ranges up to, and including, the observed range, contribute to the credit calculation.

Thus, if threshold 3 range is the observed range (i.e., the range to which the observed value belongs), threshold 1 range and threshold 2 range will contribute to the calculation. But threshold 4 range and threshold 5 range will not contribute to the calculation. That other ranges than the observed range can contribute to the credit calculation explains why this mode is called Tiered mode, since a range can also be seen as a tier.
In Tiered mode, the credit calculation could be explained as follows: 1. For each threshold N range of values (N represents the number assigned to the currently considered range, with 1 <= N <= 5) up to the observed range, but this latter range being excluded, calculate the contribution of the range as follows: (value of threshold N+11 parameter - value of threshold N parameter) * (value of Discounts parameter of Threshold N range) 2. Calculate the contribution of the observed range of values as follows, assuming that N represents the number assigned to the observed range: (observed value - value of Threshold N parameter) * (value of Discounts parameter of observed range) 3. 4. Add up (make the sum of) all the calculations that were done at previous steps and divide the result by 100. The granted credit is the one that previous step calculated.
1. Threshold N+1 is the lowest Threshold parameter value that is greater than Threshold N parameter value.
Page 634 of 968
11 September 2009
Figure 285 - Discount GUI - What Is Tiered Mode In the above figure, if the observed value is < 10 (say the observed value equals 7), the observed value belongs to no range of values and no credit is granted to the current Accounts main balance. In the above figure, if the observed value belongs to threshold 1 range (say that observed value equals 16), what follows happens. Because Percentage radio button is selected, the credit associated with threshold 1 range (which equals 25) is used as a percentage. Moreover, because Continuous radio button is selected, each credit associated with a range of values below Threshold 1 parameter value contribute to the calculation of the granted credit. Since these ranges of values do not exist, only Discounts parameter of threshold 1 range contributes to the calculation of the credit to grant. As a result, the current Terms of Discount add (16 - 10) * 25 / 100 to the main balance of the current Account. Moreover, if VAT is enabled on the current Terms of Discount, the VAT on (16 - 10) * 25 / 100 is added to the current Accounts main balance. In the above figure, if the observed value belongs to threshold 2 range (say that observed value equals 27), what follows happens. Because Percentage radio button is selected, the credit associated with threshold 2 range (which equals 110) is used as a percentage. Moreover, because Continuous radio button is selected, each credit associated with a range of values below Threshold 2 parameter value contribute to the calculation of the granted credit. As threshold 1 range is the only range that is so, its Discounts parameter, in addition to the one of threshold 2 range, contributes to the calculation of the credit to grant. As a result, the current Terms of Discount add (27 - 23) * 110 + (23 - 10) * 25 / 100 to the main balance of the current Account. Moreover, if VAT is enabled on the current Terms of Discount, the VAT on (27 - 23) * 110 + (23 - 10) * 25 / 100 is added to the current Accounts main balance.
11 September 2009
Page 635 of 968
Rewarding Accounts
In the above figure, if the observed value belongs to threshold 3 range (say that observed value equals 12,345), what follows happens. Because Percentage radio button is selected, the credit associated with threshold 3 range (which equals 37) is used as a percentage. Moreover, because Continuous radio button is selected, each credit associated with a range of values below Threshold 3 parameter value contribute to the calculation of the granted credit. As threshold 1 range and threshold 2 range are the only ranges that are so, their Discounts parameter, in addition to the one of threshold 3 range, contributes to the calculation of the credit to grant. As a result, the current Terms of Discount add (12,345 - 45) * 37 + (45 - 23) * 110 + (23 - 10) * 25 / 100 to the main balance of the current Account. Moreover, if VAT is enabled on the current Terms of Discount, the VAT on (12,345 - 45) * 37 + (45 - 23) * 110 + (23 - 10) * 25 / 100 is added to the current Accounts main balance.
17.3.2.8. Indicating Which Accounts Value Sub-Repository Is Granted Credit

The credit that an instance of Discount object computes is always given to an Accounts main balance. As a result, unlike the instances of the Grant Tool object, an instance of Discount object is unable to give some credit to an Accounts bundle.
Page 636 of 968
11 September 2009
17.3.3. General Parameters
Figure 286 - Discount GUI Table 209 - Discount Parameter Service Retailer* Discount Name* General Ledger Code* Description Reference to the Service Retailer to which the current Terms of discount belong. Name of the current Terms of Discount. This must be the name (i.e., the value of General Ledger Code* parameter) of an instance of General Ledger Code object. This parameter must refer to the General Ledger Code information that is to be inserted into the EDR that is being generated (e.g., in consequence of the OOC executing the current Terms of Discount, or in consequence of the processing of a fstreq, a oneshot or a getandcheckppm RTx request) while the current Terms of Discount are processed. This parameter has no impact on what the current Terms of Discount do. This is information of which the sole purpose is to be copied into EDRs.
11 September 2009
Page 637 of 968
Rewarding Accounts
Table 209 - Discount Parameter VAT GL Code* Description This must be the name (i.e., the value of General Ledger Code* parameter) of an instance of General Ledger Code object. This is the instance of General Ledger Code object that indicates, thanks to VAT Management parameter of the instance, whether the VAT is enabled on the current Terms of Discount or not: If VAT Management parameter of the instance is set to None, no VAT is enabled on the current Terms of Discount. There is thus in this case no VAT to apply on the current Terms of Discount. If VAT Management parameter of the instance is set to VAT Amount, the current Terms of Discount are ignored by the CRE. If VAT Management parameter of the instance is set to VAT Rate(%), the VAT is enabled on the current Terms of Discount. The VAT rate that then applies is given by VAT rate(%) parameter of the instance (of General Ledger Code object that this parameter refers to).
See also 17.3.2.6, Enabling/Disabling VAT on the Current Terms of Discount, on

page 625.
Begin Date
Enter here the date before which you want the current Terms of Discount to be ignored by the CRE. Enter here a date.

End Date
On dates, see also Date, on page 36.
Default value: 01/01/1970. Enter here the date after which you want the current Terms of Discount to be ignored by the CRE. Enter here a date.
On dates, see also Date, on page 36.
Default value: 01/01/1970. Therefore, you always need to specify a value into this parameter. Discount Inactive Whenever this box is checked, the CRE ignores, and thus, never executes, the current Terms of Discount. Otherwise, the current Terms of Discount are not ignored by the CRE.
Page 638 of 968
11 September 2009
17.3.4. Perimeters Tab
11 September 2009
Page 639 of 968
Rewarding Accounts
Figure 287 - Discount GUI - Perimeters Tab Table 210 - Discount - Perimeters Tab GUI Frame Application Parameter Description
This parameter is of no use when either Rebate or Continuous radio button, of Discount Options and Thresholds tab, is selected.
Whenever Percentage and Discontinuous radio buttons are selected, you use Application Parameter* GUI frame to specify how the value to reward of the current Terms of Discount has to be calculated.
See also 17.3.2.7.3, Specifying How the Value to Reward Must Be

Calculated, on page 630.
Calculation Parameter
You use Calculation Parameter GUI frame to specify the observed value of the current Terms of Discount. Moreover, whenever Percentage and Continuous radio buttons are selected, the observed value is also the value to reward.
Page 640 of 968
11 September 2009
17.3.4.1. Application Parameter GUI Frame
Figure 288 - Application Parameter GUI Frame when Counter Radio Button is Checked
Figure 289 - Application Parameter GUI Frame when Main Balance Radio Button is Checked Table 211 - Discount - Perimeters Tab - Application Parameter Frame Parameter Counter Description
Select this radio button if the value to reward has to be the value of a counter of the current Account.

11 September 2009
Page 641 of 968
Rewarding Accounts
Table 211 - Discount - Perimeters Tab - Application Parameter Frame Parameter Main Balance Description
Select this radio button if the value to reward has to be deduced from the current Accounts main balance.
On how the value to reward is deduced from the main balance, see
17.3.2.7.3, Specifying How the Value to Reward Must Be Calculated, on page 630.
Application Perimeter
This parameter appears ungrayed only when Counter radio button is selected. Specify here the counter whose value gives the value to reward. This must be a counter of money, expressed in the same units as the current Accounts main balance.

Make sure that the counter is suitably updated by the CRE. For that, make sure that the suitable decision trees use one or more Counter criteria that indicate how the counters value has to be updated.
Page 642 of 968
11 September 2009
That is, enter here the value of Name* parameter of some instance of Bundle/Counter Usage Label object that is of type Counter.
17.3.4.2. Calculation Parameter GUI Frame
Figure 290 - Calculation Parameter GUI Frame when Account Original Attribute Radio Button is Checked
Figure 291 - Calculation Parameter GUI Frame when Arena Radio Button is Checked
Figure 292 - Calculation Parameter GUI Frame when Counter Radio Button is Checked
11 September 2009
Page 643 of 968
Rewarding Accounts
Table 212 - Discount - Perimeters Tab - Application Parameter Frame Parameter Account Original Attribute Description Select this radio button if the observed value of the current Terms of discount must be an original parameter of the Accounts. That is, if the observed value must be a parameter of the Accounts that is not an Arena parameter. As soon as this radio button has been selected, one of the parameters below Counter radio button is ungrayed while the other ones below Counter radio button are greyed out. Click on the black solid triangle that appears to the right of the just ungrayed parameter. This makes a drop-down menu appear, showing the following possible observed values: Account age (months) User age (years) Main balance Select in the menu the entry that corresponds to the observed value you want the current Terms of discount to use.
Arena
Select this radio button if the observed value of the current Terms of discount must be an Arena parameter of the Accounts. As soon as this radio button has been selected, one of the parameters below Counter radio-button gets ungrayed while the other ones below Counter radio-button are greyed out. Click on the black solid triangle that appears to the right of the just ungrayed parameter. This makes a drop-down menu appear, showing a list of Arena parameters. Select in the menu the Arena parameter that corresponds to the observed value you want the current Terms of discount to use.
Counter
Select this radio button if the observed value of the current Terms of discount must be a counter. As soon as this radio button has been selected, parameter Counter Calculation Perimeter is ungrayed while the other parameters below Counter radio button are greyed out. Make sure that Counter Calculation Perimeter parameter is suitably filled in.

That is, enter here the value of Name* parameter of some instance of Bundle/Counter Usage Label object that is of type Counter. Make sure that the counter is suitably updated by the CRE. For that, make sure that the suitable decision trees use one or more Counter criteria that indicate how the counters value has to be updated.
Page 644 of 968
11 September 2009
Table 212 - Discount - Perimeters Tab - Application Parameter Frame Parameter Counter Calculation Perimeter Description Whenever Counter radio button is selected, specify in this parameter the Accounts counter that the current Terms of discount will use as their observed value.
17.3.5. Discount Options and Thresholds Tab
Figure 293 - Discount GUI - Discount Options and Thresholds Tab
11 September 2009
Page 645 of 968
Rewarding Accounts
Table 213 - Discount - Discount Options and Thresholds Tab Parameter Discontinuous Description Whenever this radio button is selected, any credit, which the current Terms of Discount grant, is computed in Tapered mode. Default value: Selected.
On Tapered mode computation, see 17.3.2.7.4, What Is Tapered Mode

Calculation?, on page 632.
Continuous
This parameter is of no use when Rebate button is selected.
Whenever this radio button is selected, any credit, which the current Terms of Discount grant, is computed in Tiered mode. Default value: Not selected.
On Tiered mode computation, see 17.3.2.7.5, What Is Tiered Mode Calculation?,

on page 634.
Percentage Rebate
Select this button if the credits associated with the defined ranges of values have to be treated as percentages. Select this button if the credits associated with the defined ranges of values have to be treated as absolute values.

Number of Thresholds
Whenever this radio button is selected, you must make sure that Continuous radio button is not selected.
Indicate here how many ranges of values you want to define for the current Terms of Discount. Since you cannot define more than 5 ranges of values, and since it does not make sense you define no range of values, this parameter value must be an unsigned integer value from, and including, 1 to, and including, 5. Default value: 1.
Page 646 of 968
11 September 2009
Table 213 - Discount - Discount Options and Thresholds Tab Parameter Threshold N Description This corresponds to the Nth parameter (1 <= N <= 5) from the top of Thresholds GUI frame. For example, Threshold 1 parameter corresponds to the highest parameter that appears in Thresholds GUI frame. This parameters value must be an unsigned integer value that is >0. You use this parameter to define a range of values. To define a range of values with this parameter, enter in it the lowest value of the range of values you want it to define. The entered value is called Threshold N value and the range of values it defines is called Threshold N range of values. When N < 5, Threshold N range of values comprises the values from, and including, Threshold N up to, but not including, Threshold N+1. When N equals 5, the corresponding range of values, which is Threshold 5 range of values, comprises all the values >= Threshold N. Whenever the observed value belongs to Threshold N range of values, the current Terms of discount use the credit that is associated with Threshold N range of values (i.e., Discount N value) for computing the credit to grant.

On how the reward to grant is then computed, see 17.5.2.11, When the Reward Is a Discount, on page 676. Enter the Threshold N values in increasing order. That is, if Threshold X and Threshold Y each contain a value, and X < Y, then Threshold Xs value must be less than Thresold Ys value. Naturally, X and Y have to be substituted by some value >=1 and <= 5.
11 September 2009
Page 647 of 968
Rewarding Accounts
Table 213 - Discount - Discount Options and Thresholds Tab Parameter Discount N Description This corresponds to the Nth parameter (1 <= N <= 5) from the top of Discounts GUI frame. For example, Discount 1 parameter corresponds to the highest parameter that appears in Discounts GUI frame. This parameters value must be a decimal value that is >= 0. Specify here the credit that you want to associate with Threshold N range of values.
On how the credit to grant is computed, see 17.3.2.7, Indicating How the Granted Credit Has to Be Computed, on page 625.
Units in Which this Parameters Value Are Expressed When Rebate radio button is selected, the CRE considers that this parameters value expresses a value that is in the same units as the Accounts main balance. When Percentage radio button is selected, the CRE considers that this parameters value expresses a percentage. Discount Objects Decimal Precision The Discount object does not use Decimal Precision* parameter, of the Service Retailer object, as its decimal precision. The decimal precision that the Discount object uses is therefore fixed. It is set to 2.
To learn more about how the CRE processes decimal precisions, see Decimal
Precision*, on page 145.
Page 648 of 968
11 September 2009
17.3.6. View Graph Tab
Figure 294 - Discount GUI - View Graph Tab
Table 214 - Discount - View Graph Tab Parameter Horizontal Axis Vertical Axis Description
11 September 2009
Page 649 of 968
Rewarding Accounts
17.4. Account Discount Object

An instance of Discount object specifies the Terms of a Discount. If you want that these terms apply to some Account, you need to associate them to the Account. You associate these Terms of a Discount by creating an instance of Account Discount object that refers to both the Account and the Terms of a Discount.
Figure 295 - Account Discount GUI
Table 215 - Account Discount Parameter Service Retailer* Account* Description Reference to the Service Retailer to which the current instance of Account Discount object belongs. Reference to the Postpaid Account that the current instance of Account Discount object has to associate with the Terms of Discount that Discount* parameter of the instance specifies.
Although the Terms of a Discount only apply to a Postpaid Account, the CRE does not prevent you to specify in this parameter a reference to a Prepaid Account. However, at time the CRE runs the Terms of a Discount on an Account, it checks whether the Account is Postpaid or not. If the Account is not Postpaid, the Terms of a Discount are not applied on the Account.
Discount*
Reference to the Terms of Discount that the current instance of Account Discount object has to associate with the Account that Account* parameter of the instance specifies.
The Terms of a Discount correspond to an instance of Discount object.
Page 650 of 968
11 September 2009
Table 215 - Account Discount Parameter Priority Description An Account may be associated with several different Terms of a Discount. In that case, the Account is referred to by several instances of Account Discount object. This parameter enables you to specify the order in which the Terms of Discount that apply to the same Account have to be executed. In other terms, you use this parameter to prioritize the order of execution of the Terms of a Discount that apply to an Account. Here is how this works. Prioritizing the Execution of the Terms of a Discount on an Account If two instances of Account Discount object refer to the same Account and time has come to execute both of them, the CRE will first execute, on the Account, the Terms of Discount that the Account Discount instance with the lowest priority value refers to. If the two Account Discount instances specify the same value for this parameter, the order of their execution on the Account is unpredictable. The lower the value of this parameter, the higher the priority of the associated Terms of Discount. This must be an unsigned integer value.
Default value: 0. This is the highest priority level. Exclusive Discount An Account may be associated with several different Terms of a Discount. In that case, the Account is referred to by several instances of Account Discount object. By checking this box in one of these instances, you will make the CRE ignore all the other instances of Account Discount object that refer to the Account. As a result, only one instance of Discount object then applies to the Account, and the CRE will only execute that instance of Discount object on the Account. Only one of the instances of Account Discount object that refer to the same Account can have this box checked. This behaviour is enforced by the CRE. Discount/Bonus This radio button is not used currently.
17.5. Promotion Tool Object

17.5.1.1. Rewarding an Account Either with Some Credit or with Some Discount
The Promotion Tool object lets you set up a promotion that grants to an Account a reward that is either a credit or a discount, on the condition that the Account fulfills some condition. Note: Naturally, you set up as many promotions as you want.
11 September 2009
Page 651 of 968
Rewarding Accounts
On the difference between a credit and a discount, see section 17.1.1, The Available Rewarding Methods: Crediting and Discounting, on page 589.
If the reward is a credit, the reward is granted by executing a Top-Up Profile. Thus, the granted credit is always an absolute credit (i.e., a credit that is not computed as the percentage of something). If the reward is a discount, the discount is granted to the Account for some period of time that is called the attribution period of time. Which Top-Up Profile is granted as well as which level of discount is granted depends on some value (hereby called the observed value) that the promotion observes over some period of time called the supervision period of time. At the end of the supervision period of time, the promotion uses the current value (which is called the value to reward) of the observed value to determine either (this is in case the reward to grant is a credit) which Top-Up Profile to execute or (this in case the reward to grant is a discount) the level of the discount. The observed value counts RUM quantities consumed by the Account over the supervision period. If you need it, you can have the promotion repeating the supervision period of times until some specific date (called the end date of the promotion) is reached. That way, every time a supervision period of time of the promotion completes (but not later than the end date), the promotion grants a reward that is determined using the current value of the observed value. Once the reward has been granted, the observed value is reset and the promotion restarts a new supervision period of time (and so on until end date is reached). Note: The processing that the CRE does upon completion (provided that the completion occurs not later than end date) of the supervision period of time of a promotion is called attribution.
Note: You never indicate to a promotion to which Account it applies. Instead of that, you indicate to a promotion to which Account Profile it has to apply. As a result, when a promotion applies to an Account, thats because the promotion applies to the Account Profile of the Account. An instance of Promotion Tool object is called a promotion. You use a promotion in conjunction with the Supervision criterion and, when the promotion is about granting a discount, with the Promotion criterion: A Supervision criterion that refers to a promotion for one of its RUMs updates the observed value of the promotion every time a Usage Rating Rule goes through the criterion. The update adds to the observed value the quantities consumed by the current network event (of the Usage rating Rule) on the RUM that the criterion associates with the promotion. A Promotion criterion that refers to a promotion for one of its RUMs calculates the discount that the promotion grants to the RUM every time a Usage Rating Rule executes the criterion.
Page 652 of 968
11 September 2009
17.5.1.2. When Should You Use the Promotion Tool?

Here are some hints: Unlike the Grant Tool and the Discount objects, any credit the Promotion Tool object grants is a fixed amount of units. That credit is thus never computed as a percentage of some observed value. In other terms, the granted credit is always an absolute credit. Like the Grant Tool object and unlike the Discount object, the Promotion Tool object grants its absolute credit by executing a Top-Up Profile, selected in function of some observed value. However, while the Grant Tool object checks the observed value only upon Top-Ups, the Promotion Tool object checks the observed value at regular time intervals (i.e., every time a supervision period of time ends). Since, like the Grant Tool object, the Promotion Tool object grants its credits by means of Top_up Profiles, more than one Accounts value sub-repository (i.e., the Accounts main balance and/or one or more Accounts bundles) can be credited at the same time. Moreover, each value sub-repository can then be credited with a different amount. Unlike the Grant Tool and the Discount objects, the Promotion Tool object is able to offer a reward that is a discount. Unlike the discounts that the Discount and the Preferred Number decision criteria grant to an Account, the level (i.e., the percentage) of the discounts the Promotion Tool grants to an Account depends on the RUM quantities that the Account consumed over a past period of time (called the supervision period of time), for its use of one or more particular services.
17.5.1.3. Making the CRE Take into Account a Promotion

To have some promotion (i.e., an instance of Promotion Tool object) taken into account by the CRE: 1. If the promotion (i.e., the corresponding instance of Promotion Tool object) is not yet set up, set it up by creating as necessary an instance of Promotion Tool object. Setting up the promotion includes doing what follows: By means of Account Profile* parameter of the promotion, you specify to which Account Profile the promotion applies. By means of Counter* parameter of the promotion, you specify which counter of any Account of the Account Profile (to which the promotion applies) accumulates the RUM quantities consumed by the Account over the current supervision period of time. By means of Commercial Offer* parameter of the promotion, you specify to which Commercial Offer the promotion applies. 2. Make sure that each Account of the Account Profile (to which the promotion applies) has a counter whose name matches the value of Counter* parameter of the promotion.

3.
Be sure you create the counters as section 12.3.6.4, Tip: Creating and Exploiting a Counter, on page 404, explains.
Set up in the concerned Usage Rating Rule a Supervision criterion that uses the promotion. Without any Supervision criterion referring to the promotion, no consumed RUM quantities will be accumulated into the Accounts counter that the promotion specifies (via the promotions Account Profile* and Counter* parameters). As a result, the computation of the reward will be wrong.
11 September 2009
Page 653 of 968
Rewarding Accounts

4.
Be sure you fully read section 12.3.24, Supervision Criterion, on page 462, which explains the Supervision criterion. See also 17.5.2.1.2, What If a Usage Rating Rule Goes Across a Supervision Criterion?, on page 657.
If the reward that the promotion grants is a discount, set up in the concerned Usage Rating Rule a Promotion criterion that refers to the promotion. Note: When a promotion is about granting a credit, it is useless to make some Promotion criterion refer to the promotion. The Promotion criterion has the exact same purpose as the Discount criterion: Like the Discount criterion, executing a Promotion criterion results in a discount on each RUM of the network event that the current Usage Rating Rule is treating. However, a Promotion criterion does not compute the discounts in the same way the Discount criterion does. While the Discount criterion specifies its discounts as a fixed percentage value, the Promotion criterion specifies each of its discounts by referring to a promotion (thus, to some instance of Promotion Tool object). It is then up to the promotion to compute the discount. Upon its execution, a criterion does what follows for each RUM (of the current network event) for which it specifies some promotion: The promotion of the RUM is retrieved and used to compute the level (the percentage) of the discount. As you can see, without any Promotion criterion referring to the promotion, none of the Accounts, belonging to the Account Profile that the promotion specifies, will benefit of the discount.

5.
Be sure you fully read section 12.3.21, Promotion Criterion, on page 454, which explains the Promotion criterion. See also 17.5.2.1.3, What If a Usage Rating Rule Goes Across a Promotion Criterion?, on page 658.
Make sure that the OOC is on.

6.
See also Out Of Call, on page 32. See also 5.2.4, Out of Call Object, on page 194.
Make sure that the OOC is set up to regularly run the macro that processes the completion of the supervision period of times of the promotions. As a standard, it is up to the OOC to detect the end of the supervision period of times and to process them. However, upon processing of a oneshot or fstreq RTx request on an Account, the CRE always detects which promotions, associated with the Account, have on the Account a current supervision period that is completed but whose completion has not yet been detected (and thus processed) by the OOC. The CRE then processes (in the same way the OOC does that) the completion of the current supervision period of these promotions.

See also Out Of Call, on page 32. See also 5.2.5, Out of Call TimeBand Object, on page 198.
Page 654 of 968
11 September 2009
17.5.2. How a Promotion Works

17.5.2.1.1.Promotion Basics
Basically, a promotion: Specifies whether its reward is a discount or an absolute credit. The reward is a discount when Attribution Type parameter, of the promotion, is set to Oncallprom. The reward is an absolute credit when Attribution Type parameter, of the promotion, is set to Bonus amount. Specifies to which Accounts the promotion applies, by associating a given Account Profile to the promotion. Its Account Profile* parameter of the promotion that specifies that Account Profile. A promotion applies to all the Accounts belonging to the Account Profile that the promotions Account Profile* parameter specifies. An Account to which a promotion applies is also said to be associated with the promotion.
Indicates which Counter of the Accounts (that are associated with the promotion) is used to hold the observed value (stored into VAL parameter of the Counter) and the value to reward that is in force (stored into VALPER parameter of the Counter). Note: On the one hand, the promotion indicates which Counter holds the observed value that the promotion keeps track of. On the other hand, you use a Supervision criterion referring to the promotion to indicate how the value that the promotion keeps track of is computed.
To have an idea on how a Supervision criterion is used by the CRE, see section 17.5.2.1.2, What If a Usage Rating Rule Goes Across a Supervision Criterion?, on page 657.
Specifies a supervision period of time and additionally indicates whether the supervision period of time repeats or not. Note: The supervision period of time does not repeat when, and only when, Supervision Type parameter of the promotion is set to Fixed. During the current supervision period of time that the promotion has on an Account, the promotion observes some quantity (which is hereby called the observed value, or observed quantity) related to RUM quantities consumed by the Account. At the time when the current supervision period of time of the promotion on the Account completes, the value of the observed quantity at that moment becomes the value to reward and is copied into VALPER parameter of the Accounts counter that Counter* parameter of the promotion specifies. Defines up to four range of values. Each range of value is specified by means of a threshold value. Using Number of thresholds parameter (from Attribution tab) of the promotion, you specify how many range of values you want to set up for the promotion.
11 September 2009
Page 655 of 968
Rewarding Accounts
In each Threshold parameter (from Attribution tab) of the promotion, you indicate a threshold value. Make sure that any Threshold parameter contains a value that is strictly higher than the value in the Threshold parameter just above. A value belongs to the range of values that a given Threshold parameter specifies if, and only if, the observed value is >= the value of that Threshold parameter and, in case there is some Threshold parameter value just below, if the observed value is < the value of the Threshold parameter just below. Associates some information to each range of values. If the reward is a discount, the information associated to each defined range is a percentage. If the reward is an absolute credit, the information associated to each defined range is a Top-Up profile. If the reward is a discount, indicates how long the value to reward remains in force. The period during which the value to reward (in other terms, the last computed value to reward) is valid (i.e., used to compute the related discount) is called the attribution period of time. When the supervision period of time repeats, the attribution period of time of the last computed value to reward is the current supervision period of time (i.e., it is the supervision period of time next to the supervision period of time at the end of which the last computed value to reward was computed). When the supervision period of time does not repeat, the attribution period of time of the value to reward starts at the end of the current supervision period of time and lasts as long as specified by the value of Period of dicounting granting parameter of the promotion. Note: The attribution period of time is not necessarily the period of time during which a level of discount (i.e., a percentage) remains in force. Indeed, a discount is applied when a Promotion criterion referring for one of its RUMs to the promotion gets executed. At that moment, the criterion looks to which range of value (of the promotion) the value to reward in force (which was thus computed at the end of the last supervision period of time that completed) belongs and uses the percentage that the promotion associates to that range as the discount to apply to the RUM. As a result, during the attribution period of time of the value to reward, you can always change the discount that is associated with the value to reward, by changing in the promotion the percentage that is associated with the range of values to which the value to reward belongs. After having done such a change, the next execution of a Promotion criterion referring to the promotion will use that changed percentage as the discount to apply to the RUM that the criterion associates to the promotion.
Page 656 of 968
11 September 2009
17.5.2.1.2.What If a Usage Rating Rule Goes Across a Supervision Criterion?

You always use a promotion in conjunction with a Supervision criterion that refers to the promotion. Otherwise, the observed value that the promotion keeps track of is never updated. A Supervision criterion lets you associate some promotion to each RUM of the current network event of a Usage Rating Rule.
Indicate here the promotion that refers to the Counter (of the current Account of the current Usage Rating Rule) in which the observed value of the promotion must be stored. As a result, the consumed RUM 1 quantities of the current network event accumulate into the Counter (of the current Account) that the promotion refers too. Indicate here the promotion that refers to the Counter (of the current Account of the current Usage Rating Rule) in which the observed value of the promotion must be stored. As a result, the consumed RUM 2 quantities of the current network event accumulate into the Counter (of the current Account) that the promotion refers too. Indicate here the promotion that refers to the Counter (of the current Account of the current Usage Rating Rule) in which the observed value of the promotion must be stored. As a result, the consumed RUM 3 quantities of the current network event accumulate into the Counter (of the current Account) that the promotion refers too.
Figure 296 - Supervision Criterion GUI When a Usage Rating Rule executes a Supervision criterion, the criterion does what follows for each RUM for which the criterion specifies some promotion: 1. The criterion first checks whether the promotion exists or not for the current Commercial Offer and for the current Service Retailer of the Usage Rating Rule. That is, the criterion checks whether the current Commercial Offer matches the one that Commercial Offer* parameter (of the promotion) specifies and whether the current Service Retailer matches the one that Service retailer* parameter (of the promotion) specifies. 2. If the promotion exists, the criterion checks whether the promotion applies or not to the current Account of the Usage Rating Rule. That is, the criterion checks whether the Account Profile of the current Account matches or not the one that Account Profile* parameter (of the promotion) specifies. 3. 4. If the promotion applies to the current Account, the criterion checks whether the current Account has a Counter whose name matches the one that Counter* parameter (of the promotion) specifies. If that Counter exists for the current Account, the criterion takes from the current network event of the Usage Rating Rule the consumed quantities for the RUM that the criterion associates with the promotion and accumulates these quantities into VAL parameter of that Counter of the current Account.
As a result, the promotion indicates which Counter, of the Accounts associated with the promotion, is used to hold the observed value while a Supervision criterion that refers to the promotion indicates how the observed value is computed.
11 September 2009
Page 657 of 968
Rewarding Accounts
17.5.2.1.3.What If a Usage Rating Rule Goes Across a Promotion Criterion?

When the reward that a promotion grants is a discount, you must use the promotion in conjunction with a Promotion criterion that refers to the promotion. Otherwise, no discount will be ever applied on behalf of the promotion. When the reward that a promotion grants is a credit, it is useless to make a Promotion criterion use the promotion. The Promotion criterion is similar to the Supervision criterion in that it lets you associate some promotion to each RUM of the current network event of a Usage Rating Rule.
Indicate here the promotion that will be used to compute the discount on RUM 1 of the current network event of the current Usage Rating Rule. Indicate here the promotion that will be used to compute the discount on RUM 2 of the current network event of the current Usage Rating Rule.
Indicate here the promotion that will be used to compute the discount on RUM 3 of the current network event of the current Usage Rating Rule.
Figure 297 - Promotion Criterion GUI You however use the Promotion criterion for a different purpose. The Promotion criterion has in fact the same purpose as the Discount criterion: It is used in a Usage rating Rule to grant some discount to each RUM of the current network event that the Usage Rating Rule is processing. The Discount criterion and the Promotion criterion however differ in the way they compute their discounts: While the Discount criterion associates a fixed percentage discount to each RUM of the current network event, the Promotion criterion computes the discount for a RUM by means of the promotion that the criterion associates with each RUM of the current network event. When a Usage Rating Rule executes a Promotion criterion, the criterion does what follows for each RUM for which the criterion specifies a promotion: 1. The criterion first checks whether the promotion exists or not for the current Commercial Offer and for the current Service Retailer of the Usage Rating Rule. That is, the criterion checks whether the current Commercial Offer matches the one that Commercial Offer* parameter (of the promotion) specifies and whether the current Service Retailer matches the one that Service retailer* parameter (of the promotion) specifies. 2. If the promotion exists, the criterion checks whether the promotion applies or not to the current Account of the Usage Rating Rule. That is, the criterion checks whether the Account Profile of the current Account matches or not the one that Account Profile* parameter (of the promotion) specifies. 3. If the promotion applies to the current Account, the criterion checks whether the promotion is about granting a discount or not.
Page 658 of 968
11 September 2009
That is, the criterion checks whether Attribution Type parameter (of the promotion) is set to Oncallprom or not. If Attribution Type parameter is not set to Oncallprom, the criterion stops processing the current RUM. Else, the criterion continues processing the RUM and thus proceed to next step. 4. The criterion checks whether the promotion is running an attribution period of time on the current Account . There are two cases to consider here: If the supervision periods of time of the promotion repeat, the promotion is running an attribution period of time on the current Account if, and only if, End date of the promotion is not yet reached and the first supervision period of time, of the promotion on the current Account, completed. If the promotion does not repeat, the promotion is running an attribution period of time if, and only if, current time is between End Date of the promotion and End Date plus Period of dicounting granting parameter of the promotion. Note: The supervision period of time of a promotion does not repeat when, and only when, Supervision Type parameter of the promotion is set to Fixed. Else, the supervision periods of time of the promotion repeat. Note: When the supervision period of time of a promotion does not repeat, the unique supervision period of time of the promotions ends at End Date of the promotion.
If the promotion is not running an attribution period of time on the current Account, the criterion stops processing the current RUM. Else, the criterion continues processing the RUM and thus proceeds to next step. 5. The criterion retrieves the value to reward. The value to reward is held in VALPER parameter of the Counter, of the current Account, whose name matches Counter* parameter. Naturally, the Counter must exist for the current Account. 6. The criterion identifies the range of values, of the promotion, to which the value to reward belongs and returns as the discount to apply to the RUM the value of VALUE parameter for that range of value.
On how the value to reward is then used to compute the discount, see 17.5.2.11.1, Specifying How the Discount Is Computed, on page 676.
As you can see, specifying for a RUM of a Promotion criterion a promotion that grants a credit, instead of a discount, is the same as specifying no promotion for that RUM of the Promotion criterion.
17.5.2.1.4.What Happens When the Current Supervision Period Completes

When the current supervision period of time of the promotion completes, the so-called attribution of the reward granted by the promotion has to be performed. In very general terms, performing the attribution of the promotion consists in calculating the new value to reward and, if the promotion is about giving some credit, in executing the Top-Up Profile that is associated with the range of values to which the new value to reward belongs. The end of a supervision period of time starts an attribution period of time if, and only if: Either the supervision periods of time of the promotion repeat and current date is strictly less than end date,
11 September 2009
Page 659 of 968
Rewarding Accounts
Or the supervision period of time of the promotion does not repeat (i.e., Supervision Type parameter of the promotion is set to Fixed). What follows describe the attribution work with some more detail. For each Account whose Account Profile matches Account Profile* parameter of the promotion, the attribution does what follows on the Accounts Counter whose name matches Counter* parameter of the promotion: 1. Compute the value to reward. That is, copy VAL parameter (which contains the observed value as filled in by the Supervision criterion over the supervision period of time that just ended) of the Counter to VALPER parameter (which always contains the value to reward in force) of the Counter. Note: Before the attribution is performed for the first time on the Counter, VALPER equals 0. 2. Reset the observed value. That is, reset VAL parameter of the Counter. 3. 4. Compute the end of the next supervision period of time and store it into DATPER parameter of the Counter as a number of seconds since 01 january 1970. If the promotion is about a credit (which is then an absolute credit), grant the credit. That is: 4.1. Identify the range of values to which the value to reward belongs. 4.2. Execute the Top-Up Profile that is associated with that range of values.
On how the value to reward is then used to find out which Top-Up Profile has to be executed in order to grant the credit, see 17.5.2.12.1, Specifying How the Credit Is Computed, on page 678.
5.
If the promotion is about a discount, then 5.1. If the supervision period of time does not repeat (i.e., if Supervision Type parameter of the promotion is set to Fixed), the new value to reward is in force from the end of the unique supervision period of time and remains in force as long as Period of discount granting parameter of the promotion specifies. That is, the attribution period of time is as long as the number of days that Period of discount granting parameter value specifies. 5.2. If the supervision period of time repeats (i.e., if the promotion is configured to execute one supervision period of time after the other), the new value to reward remains in force as long as the new current supervision period of time is not over. That is, the attribution period of time is as long as the new current supervision period of time. 5.3. If some level of discount was granted and if Notification Id parameter of the promotion is not null and is suitably set, a notification is sent to the concerned Account in order to warn the Account that it has been granted a discount. Note: Keep in mind that the promotion never grants a discount when it has no attribution period of time running.
Page 660 of 968
11 September 2009
17.5.2.1.5.Who Detects and Processes the Completion of the Current Supervision Period?
It is up to the OOC to detect, and therefore to process, the completion of the current supervision period of time that a promotion runs on a given Account. However, upon processing of a oneshot or fstreq RTx request on an Account, the CRE also detects which promotions, to which the Account is associated, have on the Account a current supervision period whose completion has not yet been detected (and thus processed) by the OOC. The CRE then processes (in the same way the OOC does that) the current supervision period that these promotions have on the Account.
17.5.2.1.6.When Does the Supervision of an Account by a Promotion Start?

The supervision of an Account by a promotion, with which the Account is associated, starts on the first oneshot or nextreq or endcall RTx request made on the Account. That RTx request thus starts on the Account the first supervision period of the promotion on the Account.
17.5.2.1.7.Do the Supervision Periods of a Promotion on Two Different Accounts Match?

The supervision periods that a promotion runs on two different Accounts do not necessarily complete at the same moment. The following example illustrates this. Assuming:
That Account1 and Account2 Accounts belong to AccountProfile1 Account Profile, and That promotion Promotion1 has set up on AccountProfile1 Account Profile a repeated supervision period that is expressed in days (Supervision Type of the promotion is set to day) and that is two days long (Period parameter of the promotion is set to 2), and That promotion Promotion1 specifies Counter Counter1 as its Counter* parameter, and That End Date parameter of the promotion specifies a date that is later than 08-june-2006, and That the first oneshot or nextreq or endcall RTx request on Account1 was made at 02-june-2006 12:23, and That the first oneshot or nextreq or endcall RTx request on Account2 was made at 03-june-2006 17:47. Then: Just after the first oneshot or nextreq or endcall RTx request on Account1 has been processed, DATPER of Counter1 of Account1 is set to 04-june-2006 12:23. In other terms, the first supervision period of Promotion1 on Account1 completes at 04-june-2006 12:23. The second one will complete at 06-june-2006 12:23. And so on. Just after the first oneshot or nextreq or endcall RTx request on Account2 has been processed, DATPER of Counter1 of Account2 is set to 05-june-2006 17:47. In other terms, the first supervision period of Promotion1 on Account2 completes at 05-june-2006 17:47. The next one will complete at 07-june-2006 17:47. And so on.
11 September 2009
Page 661 of 968
Rewarding Accounts

This section explains the following terms: Promotion Observed Value Supervision Period Completed Supervision Period Aborted Supervision Period Value to reward Attribution Attribution Period: Current Account Profile Current Commercial Offer Current Service Retailer Current Account A promotion is an instance of the Promotion Tool object. The observed value is the value that a promotion observes. It corresponds to RUM quantities consumed by an Account since the beginning of the current supervision period. A promotion observes the RUM quantities that a given Account consumes over some observation period of time (called the supervision period) and grants at the end of the observation period a reward that depends on the RUM quantities that were consumed over the period. A supervision period that a promotion runs on some Account specifies the frequency at which the promotion re-evaluates the reward that it grants to the Account. Said in another way, the supervision is the frequency at which the promotion performs the attribution on the Account. During the supervision period, the information (i.e., the observed value) that the promotion will use to re-evaluate the granted reward is collected (i.e., during the period, the promotion keeps computing the observed value). Once the supervision period completes, the promotion performs the attribution and, if the supervision periods of the promotion repeat, the promotion starts a new supervision period on the Account (provided that End date of the promotion is not reached). A completed supervision period of a promotion on an Account is a supervision period which terminated at the scheduled end date and time of the supervision period. The supervision period could terminate at its scheduled end date and time because that scheduled end date and time was not later than End date of the promotion. An aborted supervision period of a promotion on an Account is a supervision period which could not terminate at its scheduled end date and time. The supervision period terminated earlier than its scheduled end because the scheduled end date and time was later than End Date of the promotion. The supervision period was thus terminated when End Date was reached. When a supervision period is aborted, no attribution is performed. The (current) value to reward of a promotion for an Account is the value that the promotion (currently) uses to compute the reward (whether the reward is a credit or a discount) it grants to the Account. The value to reward equals the value of the observed value at the moment that the last supervision period run by the promotion on the Account completed. The attribution is a processing that is done upon completion of the current supervision period that a promotion runs on a given Account, in consequence of that completion. The goal of that processing is to
Page 662 of 968
11 September 2009
update as necessary the reward (whether it is a credit or a discount) that the promotion grants to the Account, in function of the current value of the observed value. The attribution calculates the new value to reward (its the current value of the observed value of the current supervision period when the period completes) of the promotion for the Account and afterwards resets the observed value to 0. Afterwards: If the promotion is about granting a credit, the attribution uses the new value to reward to know whether some credit has to be granted or not. If some credit has to be granted, the attribution uses the new value to reward to select the Top-Up Profile that will be used for granting that credit and then grants the credit by executing that Top-Up Profile. If the promotion is about granting a discount, the promotion uses the new value to compute the new granted discount. If the new granted discount is non null and Notification Id parameter of the promotion is non null and suitably set, the promotion issues a notification to the Account in order to warn it that it has been granted a non null discount. Afterwards, the attribution starts a new attribution period. The attribution period has only meaning in the context of a promotion that grants discounts. The attribution period that a promotion runs on some Account is the period of time during which the current value to reward (i.e., the value that is stored into VALPER parameter of the Accounts Counter in which the promotion holds its observed value for the Account) can be used to compute the level of discount granted by the promotion. As long as a promotion, that grants discounts, runs no attribution period on some Account, the promotion grants no discount to the Account.
In the context of either a Supervision criterion or a Promotion criterion, the current Account Profile is the Account Profile of the current Account of the Usage Rating Rule that executes the criterion. In the context of either a Supervision criterion or a Promotion criterion, the current Commercial Offer is the current commercial offer of the Usage Rating Rule that executes the criterion. In the context of either a Supervision criterion or a Promotion criterion, the current Service Retailer is the current service retailer of the Usage Rating Rule that executes the criterion. In the context of either a Supervision criterion or a Promotion criterion, the current Account is the Account that is being processed by the Usage Rating Rule that executes the criterion.
17.5.2.3. Indicating to Which Accounts a Promotion Applies

You indicate to which Accounts a promotion applies by indicating to which Account Profile the promotion applies. A promotion applies to all the Accounts that belong to the Account Profile that the promotion specifies. These Accounts are also said to be associated with the promotion.
11 September 2009
Page 663 of 968
Rewarding Accounts
Figure 298 - Promotion Tool: Specifying to Which Accounts a Promotion applies To indicate that some Account Profile applies to a promotion: Indicate the name of the Account Profile in Account Profile* parameter (of General tab) of the promotion.
17.5.2.4. Specifying the Observed Values Container

A promotion keeps track of some observed value on each Account that is associated with the promotion. The observed value that a promotion calculates on some Account accumulates RUM quantities that the Account consumes.
You can apply some filtering to the computation of the observed value. For example, you can have the promotion only calculating the RUM quantities that the Account consumes in consequence of its use of some type of traffic. On how you apply such a filtering, see 17.5.2.6, Applying Some Filtering to the Computation of the Observed Value, on page 666.
Whenever you set up a promotion, you need to indicate which Counter, of any Account associated with the promotion, has to hold the observed value that the promotion computes on the Account.
Page 664 of 968
11 September 2009
Figure 299 - Promotion Tool: Specifying the Container of a Promotions Observed Value To indicate in which Counter, of any Account associated with a promotion, the promotion stores the observed value of the Account: Indicate the name of the Counter in Counter* parameter (of General tab) of the promotion. Note: Make sure that the Counter exists for each Account that is associated with the promotion. Note: Make also sure that the Counter of each of these Accounts has been properly created.
On how to properly create a Counter for an Account, see section 12.3.6.4, Tip: Creating and Exploiting a Counter, on page 404, explains.
17.5.2.5. Specifying How the Observed Value Is Computed

To indicate how a promotion computes the observed value of the Accounts with which the promotion is associated: Make some Usage Rating Rule use a Supervision criterion that refers to the promotion for one of its RUMs.
On how this works, see 17.5.2.1.2, What If a Usage Rating Rule Goes Across a Supervision Criterion?, on page 657.
11 September 2009
Page 665 of 968
Rewarding Accounts
17.5.2.6. Applying Some Filtering to the Computation of the Observed Value

Because the observed value is computed by means of a decision tree criterion (i.e., by means of the Supervision criterion) used by some Usage Rating Rule and since a Usage Rating Rule makes a lot of criteria available, you can apply a wide range of filters to the computation of the observed value. For example, you can have the promotion computing the observed value (i.e., quantities consumed on some RUM) for some type of traffic only. To have the observed value computed that way by the Usage Rating Rule that uses the Supervision criterion that refers to the promotion for one of its RUMs, make sure (by means of other criteria that the Usage Rating Rule makes available) that the Usage Rating Rule goes through the criterion only for these types of traffic.
17.5.2.7. Specifying Whether a Promotions Reward Is a Credit or a Discount

You need to indicate whether the reward that a promotion grants is a credit or a discount.
Figure 300 - Promotion Tool: The Reward Is a Discount To indicate that the reward is a discount: Set Attribution Type parameter (of Attribution tab) of the promotion to Oncallprom.
Figure 301 - Promotion Tool: The Reward Is a Credit To indicate that the reward is a credit: Set Attribution Type parameter (of Attribution tab) of the promotion to Bonus mount.
Page 666 of 968
11 September 2009
17.5.2.8. Specifying When the Supervision Periods Are Allowed to Run

You use End date parameter of a promotion to indicate when the promotions supervision periods are not allowed to run. No supervision period of the promotion is allowed to run after End date of the promotion has been reached. Note: Begin date parameter is not used.
Figure 302 - Promotion Tool: When the Supervision Periods Are Allowed to Run If the current supervision period that a promotion runs on an Account completes after the End date that the promotion specifies, the current supervision period of the Account is aborted as soon as the current time is strictly greater than End date. Note: Because it has been aborted, an aborted supervision period never completes (completion of a supervision period happens when the period ends at the foreseen end date and time of the period). Therefore, upon abortion of a supervision period, no attribution is performed. As a result, abortion of a supervision period never results in some credit being granted. Note: A supervision period that does not repeat (i.e., when Supervision Type parameter is set to Fixed) always completes at End date and is therefore never aborted.
11 September 2009
Page 667 of 968
Rewarding Accounts
17.5.2.9. Specifying the Supervision Periods

For each Account associated with a promotion, the reward is always computed upon completion of the current supervision period that the promotion runs on the Account. Therefore, specifying when the reward is computed and granted is the same as specifying the supervision periods of the promotion. In this section you are explained how you specify a supervision period: That does not repeat (fixed periods).
On how to specify such a supervision period, see 17.5.2.9.1, Specifying a Supervision Period that Does Not Repeat (Fixed Period), on page 668.
That repeats and has a duration expressed in days (day periods).
On how to specify such a supervision period, see 17.5.2.9.2, Specifying a Periodic Supervision Period in Days (Day Period), on page 669.
That repeats and has a duration expressed in weeks (week periods).
On how to specify such a supervision period, see 17.5.2.9.3, Specifying a Periodic Supervision Period in Weeks (Week Period), on page 670.
That repeats and has a duration expressed in months (month periods).
On how to specify such a supervision period, see 17.5.2.9.4, Specifying a Periodic Supervision Period in Months (Month Period), on page 671.
17.5.2.9.1.Specifying a Supervision Period that Does Not Repeat (Fixed Period)

You can specify for a promotion a supervision period that does not repeat.
Figure 303 - Promotion Tool: Specifying a Supervision Period that Does Not Repeat To specify a supervision period that does not repeat: 1. 2. Set Supervision type parameter (from Supervision tab of the promotion) to Fixed . Enter into End date* (from Supervision tab of the promotion) the end of the supervision period.
Page 668 of 968
11 September 2009
The unique supervision period that the promotion runs on any Account (associated with the promotion) starts on the first oneshot or nextreq or endcall RTx request made on the Account and completes at End Date, that the promotion specifies.
See also 17.5.2.1.7, Do the Supervision Periods of a Promotion on Two Different Accounts Match?, on page 661.
17.5.2.9.2.Specifying a Periodic Supervision Period in Days (Day Period)
Figure 304 - Promotion Tool: Specifying a Supervision Period as a Number of Days To specify a supervision period that repeats every n days (where n is to be replaced by some integer value):
1. 2.
Set Supervision type parameter (from Supervision tab of the promotion) to Day. Enter the duration of the period (i.e., n), expressed in days, into Period parameter (from Supervision tab of the promotion).
The above figure specifies a supervision period that repeats every 3 days. The first supervision period that the promotion runs on any Account (associated with the promotion) starts on the first oneshot or nextreq or endcall RTx request made on the Account.
11 September 2009
Page 669 of 968
Rewarding Accounts
17.5.2.9.3.Specifying a Periodic Supervision Period in Weeks (Week Period)
Figure 305 - Promotion Tool: Specifying a Supervision Period as a Number of Weeks To specify a supervision period that repeats every n weeks (where n is to be replaced by some integer value) and that starts on a given day of the week: 1. 2. 3. Set Supervision type parameter (from Supervision tab of the promotion) to Week. Enter the duration of the period (i.e., n), expressed in weeks, into Period parameter (from Supervision tab of the promotion). Enter the day (of the week at which each supervision period of the promotion has to start) into Day parameter (from Supervision tab of the promotion). Enter a value that is not lower then 0 and that is not higher than 6. 0 means Sunday, 1 means Monday and so on. The above figure specifies a supervision period that repeats every 4 weeks and that always starts on a wednesday. Note: Keep in mind that the first supervision period that a promotion runs on an Account starts on the first oneshot or nextreq or endcall RTx request made on the Account. Therefore, if the promotion specifies a week supervision period, the first supervision period that the promotion runs on the Account is likely to start on another day than the day that the promotion specifies for its week supervision periods. In spite of that, the next supervision periods (that the promotion will run on the Account) will always start on the week day that the promotion specifies for its week supervision period.
Page 670 of 968
11 September 2009
17.5.2.9.4.Specifying a Periodic Supervision Period in Months (Month Period)
Figure 306 - Promotion Tool: Specifying a Supervision Period as a Number of Months To specify a supervision period that repeats every n months (where n is to be replaced by some integer value) and that starts on a given day of the month: 1. 2. 3.
Set Supervision type parameter (from Supervision tab of the promotion) to Month. Enter the duration of the period (i.e., n), expressed in months, into Period parameter (from Supervision tab of the promotion). Enter the day (of the month at which each supervision period of the promotion has to start) into Day parameter (from Supervision tab of the promotion). Enter a value that is not lower then 1 and that is not higher than 31. 1 means the first day of the month and so on.
The above figure specifies a supervision period that repeats every 2 months and that always starts on the 27th of the month. Note: Keep in mind that the first supervision period that a promotion runs on an Account starts on the first oneshot or nextreq or endcall RTx request made on the Account. Therefore, if the promotion specifies a month supervision period, the first supervision period that the promotion runs on the Account is likely to start on another day than the day that the promotion specifies for its month supervision periods. In spite of that, the next supervision periods (that the promotion will run on the Account) will always start on the day that the promotion specifies for its month supervision period.
17.5.2.9.5.At Which Time of the Day Does a Supervision Period Start?

Each supervision period that a promotion runs on an Account starts at the same time of the day, including the first supervision period that the promotion ran on the Account. That time of the day is the time of the day at which the promotion started the first supervision period on the Account. Note: Keep in mind that the first supervision period that a promotion runs on an Account starts upon the first oneshot or nextreq or endcall RTx request made on the Account.
11 September 2009
Page 671 of 968
Rewarding Accounts
To see an example of this, see section 17.5.2.1.7, Do the Supervision Periods of a Promotion on Two Different Accounts Match?, on page 661.
17.5.2.9.6.How Is the Completion of a Supervision Period Detected?

The current supervision period that a promotion runs on some Account is scheduled to complete at a specific date and time. Note: That date and time is stored into DATPER parameter of the Accounts Counter in which the promotion stores the observed value it computes on the Account. Note: For example, a current supervision period might be scheduled to complete on 21-july-2006 17:54. Whenever either the OOC, or a oneshot RTx request, or a fstreq RTx request, checks whether the current supervision period, that a promotion runs on the Account being processed, has completed or not, it does that by comparing NOW (i.e., the current date and time) with the date and time at which the supervision period is scheduled to complete. If NOW is not earlier and the current supervision completion was not yet detected (and thus not yet processed), the completion of the current supervision period is then processed. But if NOW is earlier, the current supervision period hasnt completed yet. To conclude, whenever checking for the completion of some current supervision period, the time of the day at which the period completes is also taken into account. Not only the date.
Page 672 of 968
11 September 2009
17.5.2.9.7.How Is the End of the First Supervision Period Computed?

Since the first supervision period that a promotion runs on an Account starts upon the first oneshot or nextreq or endcall RTx request made on the Account, the duration of the first supervision period will usually not match the value that Period parameter of the promotion specifies. Moreover, in some cases, the Promotion Tool will prefer to make sure that the first supervision period is not shorter than the duration that Period parameter of the promotion specifies. For example, assuming that the following is true for a given promotion: Supervision Type parameter is set to Week (which means that the supervision period repeats and is expressed in weeks), and Period parameter is set to 1 (which means the period is one week long), and Day parameter is set to 2 (which means that the supervision period must always start on a Tuesday), and The promotion applies to Account1 and to Account2, and The first oneshot or nextreq or endcall RTx request on Account1 is done on friday 02-June-2006 12:30, and The first oneshot or nextreq or endcall RTx request on Account2 is done on saterday 03-June2006 15:00, Then:
The end date and time of the first supervision period of the promotion on Account1, as computed by the Promotion Tool, is not necessarily Tuesday 6-june-2006 12:30. Indeed, the Promotion Tool may deem that a supervision period of 4 days is too short in case a supervision period repeats every week, and may therefore add the value of Period (i.e., 1 week) parameter to the duration of the supervision period. As a result, the Promotion Tool may then make the first supervision period end 1 week later, that is on 13-june-2006 12:30. The end date and time of the first supervision period of the promotion on Account2, as computed by the Promotion Tool, is not necessarily Tuesday 6-june-2006 15:00. Indeed, the Promotion Tool may deem that a supervision period of 3 days is too short in case a supervision period repeats every week, and therefore add the value of Period (i.e., 1 week) parameter to the duration of the supervision period. As a result, the Promotion Tool may then make the first supervision period ends 1 week later, that is on 13-june-2006 15:00.
In case you need to know exactly which rules the Promotion Tool applies in order to compute the end date of the first supervision periods, you should please contact Alcatel.
11 September 2009
Page 673 of 968
Rewarding Accounts
17.5.2.10.Specifying the Value Ranges

Like the Discount object, and unlike the Grant Tool object, the Promotion Tool object specifies a range of values by specifying the lower value of that range. That lower value is called a threshold. Note: Contrast this with what the Grant Tool object does: The Grant Tool object specifies a range of values by specifying the upper value of the range. Like the Discount object, and unlike the Grant Tool object, you indicate to the Promotion Tool object how many (but not more than 4) range of values you want to set up. For that, you use Number of Thresholds parameter (from the Attribution tab). In the figure below, Number of Thresholds parameter is set to 3. As a result, 3 rows of parameters appear below Number of Thresholds parameter. Note: The following figure is for a promotion that grants a credit. However, the explanations in the figure and in this section are also valid for promotions that grant a discount.
Threshold 1 range of values goes from 10 to 23, without 23. Threshold 1 parameter value is set to 10. Threshold 2 range of values goes from 23 to 45, without 45. Threshold 2 parameter value is set to 23. Threshold 3 range of values is everything >= 45. Threshold 3 parameter value is set to 45. This is the number of range of values you want to set up. You can specify up to 4 range of values.
Recharge ID 1 parameter
Figure 307 - Promotion Tool: Specifying the Value Ranges In the above figure, the lowest Threshold parameter (i.e., Threshold 3 parameter) is set to 45. Because Threshold 3 parameter is the lowest one, it specifies the range of all the values that are greater or equal to 45. Because Threshold 3 parameter is third from the top of the Attribution tab,
Page 674 of 968
11 September 2009
it is said to specify threshold 3 range of values. And this parameter value is called threshold 3 parameter value (in short, threshold 3 value). In the above figure, any value (e.g., 132) greater than or equal to 45 belongs to threshold 3 range of values. Still in the above figure, the Threshold parameter that is second from the top of the Attribution tab (i.e., Threshold 2 parameter) is set to 23. Because the parameter that is just below Threshold 2 parameter contains 45, Threshold 2 parameter specifies a range of value that goes from 23 (23 is in the range) to 45 (45 is not in the range). Because Threshold 2 parameter is second from the top of the Attribution tab, it is said to specify threshold 2 range of values. And this parameter value is called threshold 2 parameter value (in short, threshold 2 value). In the above figure, any value (e.g., 39) greater than or equal to 23 and that is strictly less than 45 belongs to threshold 2 range of values. Finally, the highest Threshold parameter (i.e., Threshold 1 parameter) is set to 10. Because the parameter that is just below Threshold 1 parameter contains 23, Threshold 1 parameter specifies a range of value that goes from 10 (10 is in the range) to 23 (23 is not in the range). Because Threshold 1 parameter is first from the top of the Attribution tab, it is said to specify threshold 1 range of values. And this parameter value is called threshold 1 parameter value (in short, threshold 1 value). In the above figure, any value (e.g., 14) greater than or equal to 10 and that is strictly less than 23 belongs to threshold 1 range of values. In the example of this figure, if the value to reward is < 10 (e.g., 7), it belongs to no range of values. As a result, in this case, no reward is granted.
11 September 2009
Page 675 of 968
Rewarding Accounts
17.5.2.11.When the Reward Is a Discount

17.5.2.11.1.Specifying How the Discount Is Computed
You indicate how a promotion computes its discounts by associating a percentage to each of the value ranges that you define in the promotion. Upon execution by a Usage Rating Rule of a Supervision criterion that refers for one of its RUMs to the promotion, the discount that the criterion returns for the RUM is the one that is associated with the range of values to which the value to reward in force for the Account belongs. The following figure shows an example.
Figure 308 - Promotion Tool: Specifying How the Discount Is Computed When a Usage Rating Rule goes through a Supervision criterion that refers for one of its RUMs to the promotion that the above figure describes, the discount that the criterion will return for the RUM is determined as follows: If the value to reward (i.e., the value of VALPER parameter of the Counter, of the current Account of the Usage rating Rule, that matches Counter* parameter that the promotion specifies) belongs to threshold 1 range of values (i.e., is >= 10 and < 23), the criterion returns a 25 per cent discount for the RUM. If the value to reward belongs to threshold 2 range of values (i.e., is >= 23 and < 45), the criterion returns a 110 per cent discount for the RUM. If the value to reward belongs to threshold 3 range of values (i.e., is >= 45), the criterion returns a 37 per cent discount for the RUM.
Page 676 of 968
11 September 2009
If the value to reward is < 10, the criterion returns no discount (in other words, a zero per cent discount is returned) for the RUM.
17.5.2.11.2.Specifying How Long the Discount Is Granted

Whenever a promotion grants a discount to an Account, the discount is granted to the Account for some period of time. That period of time is called the attribution period. As a rule, a promotion starts running a new attribution period on an Account upon completion of the current supervision period that the promotion runs on the Account, once the attribution due to the completion of the current supervision period has been processed. Note: One consequence of this rule is that a promotion never grants a discount on an Account before the first supervision period of the promotion on the Account has completed. However, the handling of attribution periods by promotions with a not repeatable supervision period and by promotions with repeatable supervision periods differ on: How these promotions compute the duration of their attribution period. For a promotion that has repeatable supervision periods (i.e., Attribution Type parameter of the promotion is not set to Fixed), the duration of the current attribution period is the same as that of the current supervision period, in addition to the fact that both periods start at the same moment. For a promotion that has a not repeatable supervision period (i.e., Attribution Type parameter of the promotion is set to Fixed), the duration of the unique attribution period (the period starts at End date of the promotion) of the promotion is specified by Period of discount granting parameter of the promotion. This parameter value expresses a number of days. Whether the attribution period of these promotions can exceed End date or not. The attribution period of a promotion that has repeatable supervision periods (i.e., Attribution Type parameter of the promotion is not set to Fixed) cannot exceed End date of the promotion. Thats because no supervision period of such a promotion can exceed End date of the promotion and because the current attribution period of such a promotion always matches the current supervision period of the promotion. The attribution period of a promotion that has a not repeatable supervision period (i.e., Attribution Type parameter of the promotion is set to Fixed) always exceeds End date of the promotion. Thats because the unique supervision period of the promotion only completes once End date is reached. Not allowing the attribution period of the promotion to exceed End date would simply prevent the promotion to make its Accounts benefit of its discounts. As a result, to specify how long a promotion grants a discount: When Attribution Type of the promotion is set to Fixed, you specify in Period of discount granting parameter of the promotion the number of days during which the promotion grants its discount. If Attribution Type of the promotion is not set to Fixed, you specify nothing special, since the current attribution period always matches the current supervision period.
17.5.2.11.3.Applying Some Filtering to the Discounts that a Promotion Grants

As has already been said, in order to have a promotion granting its discounts, you must set up some Usage Rating Rule that uses a Promotion criterion that refers to the promotion for one of its RUMs. It must be noted that a Promotion criterion that refers to a promotion does not need to be placed in the same Usage Rating Rule as the Supervision criterion that refers to that promotion.
11 September 2009
Page 677 of 968
Rewarding Accounts
It must be also noted that, through the appropriate use of the wide range of criteria that a Usage Rating Rule makes available, you can set up a Usage Rating Rule so that it executes a Promotion criterion only when some specific conditions are met. To give an example of the consequences, by suitably setting up the Usage Rating Rule that executes a Promotion criterion that refers to a given promotion for one of its RUMs, you can have the promotion granting its discounts for the use of that RUM by some type of traffic only.
17.5.2.12.When the Reward Is a Credit

17.5.2.12.1.Specifying How the Credit Is Computed
You indicate how a promotion computes its credits by associating a Top-Up Profile to each of the value ranges that you define in the promotion. Upon completion of a supervision period that the promotion runs on some Account, a credit is granted to the Account by executing the Top-Up profile that is associated with the range of values to which the value to reward for the Account belongs. The following figure shows an example.
Figure 309 - Promotion Tool: Specifying How the Credit Is Computed When the current supervision period that the promotion (that the above figure describes) runs on some Account completes, the credit granted to the Account is computed as follows: If the value to reward (i.e., the value of VALPER parameter of the Counter, of the current Account, that matches Counter* parameter that the promotion specifies) belongs to threshold 1 range of values (i.e., is >= 10 and < 23), a credit is granted to the Account by executing tp_profile1 Top-Up profile.
Page 678 of 968
11 September 2009
If the value to reward belongs to threshold 2 range of values (i.e., is >= 23 and < 45), a credit is granted to the Account by executing tp_profile2 Top-Up profile. If the value to reward belongs to threshold 3 range of values (i.e., is >= 45), a credit is granted to the Account by executing tp_profile3 Top-Up profile If the value to reward is < 10, no credit is granted to the Account.
17.5.2.12.2.Specifying Which Account Sub-Repository(ies) Benefit of the Credit

Since a credit is always granted to an Account by executing a Top-Up Profile, specify in the Top-Up profile which sub-repository(ies) of the Account receive how much credit upon execution of the Top-Up Profile.
On Top-Up Profiles, see 20.3, Top-Up Profile Object, on page 808.
11 September 2009
Page 679 of 968
Rewarding Accounts
17.5.2.13.Customizing a Promotion (LiteSCE Scripting)

You can have a promotion running some LiteSCE script every time it is going to add consumed RUM quantities (taken from the network event being processed) into VAL parameter of Counter Counter* of one of its associated Accounts. Just write that LiteSCE script, then indicate the name of that script in LiteSCE Script parameter (from Supervision tab) of the promotion and the owner of that script in LiteSCE Owner parameter (from Supervision tab) of the current promotion. Note: Section 17.5, Promotion Tool Object, on page 651, describes the default behaviour of a promotion. This is the behaviour of the promotion when it uses the no LiteSCE script.
17.5.2.13.1.When Does a Promotion Call Its LiteSCe Script?

A promotion starts its first supervision period on an Account upon the first oneshot or nextreq or endcall RTx request that is done on the Account and that sees that DATPER, of the Accounts Counter in which the promotion has to accumulate consumed RUM quantities, equals 0. Since the check on DATPER is made by the promotion after the LiteSCE Script has completed, the current promotion computes the value of DATPER (i.e., the end date and time of its first supervision period on the Account) for its first supervision supervision after the LiteSCE script has completed. Computation of DATPER value in case DATPER is found to be zero is the only processing that can be done by a promotion after it executed its LiteSCE script and before it adds RUM quantities to VAL (and, in case DATPER was found null, before it also updates DATPER).
DATPER computation happens only when the promotion starts its first supervision period on the Account, which means that in all the other cases, the current promotion does no particular processing after it executed its LiteSCE script and before it adds RUM quantities to VAL. Note: Because the computation of the end date and time of the first supervision period that the promotion runs on the Account is done after the LiteSCE script has run, a LiteSCE script is able to parameterize the computation of DATPER (of course when it is found equal to zero) by the promotion.
On parameterizing the computation of the end date and time of the first supervision period that a promotion runs on any of its associated Accounts, see also section 17.5.2.13.3, Customizing the Computation of the End of the First Supervision Period, on page 681.
17.5.2.13.2.Customizing the Computation of the Observed Value (i.e., of VAL Parameter)

By means of the LiteSCE Script of a promotion, you can parameterize the incrementation of VAL parameter of Counter Counter* of any Account on which the promotion runs a supervision period. At the time when the promotion calls the LiteSCE script, the promotion has already stored into INCVAL context variable the consumed RUM quantities to accumulate into VAL parameter of Counter Counter*. Once the LiteSCE script has completed, the promotion adds the value of INCVAL to VAL parameter of Counter Counter* of the Account. The LiteSCE script can thus modify the value of INCVAL (for example, by updating INCVAL to its current value multiplied by 10) before the promotion adds INCVAL value to VAL. You can thus use the LiteSCE script to accumulate into VAL parameter RUM quantities that are expressed in units other than those that the network event use for its RUM quantities.
Page 680 of 968
11 September 2009
17.5.2.13.3.Customizing the Computation of the End of the First Supervision Period

To compute the end date and time of the first supervision period it runs on an Account, a promotion must know when that first supervision period starts. If the promotion is not told when that supervision period starts, the promotion assumes that the beginning date and time of that supervision period is the date of the call. Using that beginning date, the promotion then computes the end date and time of the first supervision period it runs on the Account and stores it into DATPER parameter of the Accounts Counter that the promotion uses. Note: Keep in mind that a promotion starts running its first supervision period on an Account (and thus computes the end date and time of that period) upon the first oneshot or nextreq or endcall RTx request that is done on the Account and that sees that DATPER, of the Accounts Counter that the promotion uses, equals 0. To know whether it is told or not when the supervision period starts, the promotion checks the value of REF_DATE context variable. If REF_DATE equals 0, then the promotion knows that it is not told when the first supervision starts and the promotion thus uses the date of the call as the beginning date and time of the first supervision period it will run on the Account. Note: REF_DATE is short for reference date. When the promotion has a LiteSCE script, the check on REF_DATE is always done after the LiteSCE script execution. As a result, if the LiteSCE script did not modify REF_DATE, the promotion will use the date and time of the call as the beginning date and time of the first supervision period it will run on the Account. On the other hand, if the LiteSCE script put a date into REF_DATE, the promotion, which checks REF_DATE after the LiteSCE script has run, sees that REF_DATE is different from 0 and thus knows that it is told (by the LiteSCE script in fact) when the first supervision period begins. The promotion then uses REF_DATE as the beginning date and time (i.e., as the reference time) of the first supervision period it runs on the Account. That is, the promotion then uses REF_DATE to compute the end date and time of the first supervision period it runs on the Account. Naturally, the end of the first supervision period that the promotion runs on the Account is always a date in the future. The following example illustrates that. Assuming that: DATPER is found to equal 0, and Current date and time is 11-aug -2006 15:00, and The LiteSCE script has set REFDATE to 03-jan-2006 09:00, and The duration of the supervision periods of the promotion is expressed in months and equals 2 months. Then: Obviously, some supervision periods belonging to the past did not be run on the Account. But the first supervison period that the promotion runs on the Account will end at a date beli-onging to the future and that is stored into DATPER.
11 September 2009
Page 681 of 968
Rewarding Accounts
17.5.3. Parameters
17.5.3.1. Promotion Identification
Figure 310 - Promotion Tool GUI Table 216 - Promotion Tool Parameter Service Retailer* Description Indicate here the service retailer that makes the current promotion available.
Naturally, this is also the service retailer of the commercial offer of the current promotion and of the Account Profile of the current promotion.

Commercial Offer*
Two promotions can be about the same commercial offer and have the same name provided that they are not about the same service retailer.
Indicate here to which commercial offer the current promotion applies. To indicate that the promotion applies to any commercial offer, enter all_comoffer in this parameter.
Two promotions can be about the same retailer and have the same name provided that they are not about the same commercial offer.
How a Usage Rating Rule Retrieves a Promotion A usage rating Rule (URR) retrieves a promotion that a Supervision criterion (or a Promotion criterion) uses by first attempting to find out a promotion that matches its current commercial offer, its current service retailer and the name of the promotion as specified by the criterion. If the attempt fails, the URR then attempts to find out a promotion whose Commercial Offer* parameter is set to all_comoffer and that matches its current service retailer and the name of the promotion as specified by the criterion. Name* Enter here the name of the promotion. Choose that name freely.

Obsolete
Two promotions can be about the same retailer and the same commercial offer provided that they do not have the same name.
Not used.
Page 682 of 968
11 September 2009
17.5.3.2. General Tab
Figure 311 - Promotion Tool GUI - General Tab Table 217 - Promotion Tool - General Tab Parameter Description Description Enter here free text. You might want to enter here some important information, about the promotion, that you would like to remember.
Account Profile*
Specify here the Account Profile to which the current promotion applies. Purpose of this Parameter By means of this parameter, you indicate to which Accounts the current promotion applies: A promotion applies to all the Accounts that belong to the Account Profile of the promotion.
An Account that belongs to the Account Profile of a promotion is said to be associated with the promotion.
11 September 2009
Page 683 of 968
Rewarding Accounts
Table 217 - Promotion Tool - General Tab Parameter Counter* Description Specify here the name of a Counter that exists for each Account that belongs to the Account Profile of the current promotion.
Make sure that that Counter has been properly created for each of these Accounts.
Creating and Exploiting a Counter, on page 404, explains.
On how to properly create a Counter for an Account, see section 12.3.6.4, Tip:
Restriction When two promotions use the same Account Profile, they cannot specify the same Counter name in this parameter. Purpose of this Parameter For each Account that is associated with the current promotion, the current promotion stores the following information into the Accounts Counter whose name matches this parameter value: The current value of the observed value that the current supervision period, that the current promotion runs on the Account, is computing on the Account (the value is stored in VAL parameter of the Counter).
VAL thus contains RUM quantities (those that the current promotion observes on its Accounts) consumed by the Account from the beginning of the current supervision period until NOW. The value to reward (the value to reward is stored into VALPER parameter of the Counter) that is currently in force. This is the value that the observed value had at the end of the previous supervision period. The completion date and time of the current supervision period that the current promotion runs on the Account (that date and time is stored into DATPER parameter of the Counter).
Page 684 of 968
11 September 2009
Table 217 - Promotion Tool - General Tab Parameter Notification Id Description
Only used when the current promotion is about granting a discount (i.e., when Attribution Type is set to oncallprom).
If you want an Account to be warned that it has been granted a level (a given percentage) of discount by the current promotion, entere here the Index ID of On Call Promotion notification type of Promotion (Bonus or on Call) notification feature. Otherwise, enter 0 here.
Only the attribution can issue an On Call Promotion. Therefore, an On Call Promotion notification can only be issued upon the end of a supervision period that the current promotion runs on an Account.
page 178.
See also 5.1.5.2, Enabling a Given Notification Type on a Given Account, on On Promotion (Bonus of on Call) notification feature and on finding out the Index ID
of a CRE notification type, see section 5.1.5, Enabling a Given Notification Type on a Given Account, on page 176.
What If the Promotion Grants Credits and You Want Them to Be Notified? As already said, this parameter is not used when the current promotion is about granting a credit.
Do not despair however: If you would like an Account to be warned every time the current promotion gives it a credit, have a look at Promotion (Bonus or on call), on page 169.
11 September 2009
Page 685 of 968
Rewarding Accounts
17.5.3.3. Supervision Tab
Figure 312 - Promotion Tool GUI - Supervision Tab
Figure 313 - Promotion Tool GUI - Supervision Tab (Supervision Type = Fixed)
Page 686 of 968
11 September 2009
Figure 314 - Promotion Tool GUI - Supervision Tab (Supervision Type = Day)
Figure 315 - Promotion Tool GUI - Supervision Tab (Supervision Type = Week)
Figure 316 - Promotion Tool GUI - Supervision Tab (Supervision Type = Month)
Table 218 - Promotion Tool - Supervision Tab Parameter Begin Date* Not used. Date and time. Description
11 September 2009
Page 687 of 968
Rewarding Accounts
Table 218 - Promotion Tool - Supervision Tab Parameter End Date* Description This is the date and time after which the current promotion is not allowed to run a supervision period. When Supervision Type parameter of the current promotion is set to Fixed, this parameter indicates the date and time at which the unique supervision period of the current promotion completes. Except in the case that is mentioned below this paragraph, this parameter is also the date and time after which the current promotion stops working.
The current promotion will not stop working after its End date if its supervision period does not repeat (in which case its Supervision Type parameter is set to Fixed) and if the current promotion is about granting a discount (in which case Attribution Type of the current promotion is set to Oncallprom). In that case, the current promotion will stop working Period of discount granting days after its End date. Until then, the promotion will keep applying discounts to its Accounts.
Page 688 of 968
11 September 2009
Table 218 - Promotion Tool - Supervision Tab Parameter Supervision Type Description This parameter indicates whether a supervision period of the current promotion repeats or not. When this parameter indicates that a supervision period of the current promotion repeats, this parameter also indicates in which time units the duration of a supervision period of the current promotion is expressed. Choose for this parameter one of the following values: Fixed The supervision period of the current promotion does not repeat. The unique supervision period of the current promotion completes at the date and time that End date parameter of the current promotion specifies. Day The supervision periods of the current promotion repeat and their duration is expressed in days (that number of days is given by Period parameter of the current promotion). Week The supervision periods of the current promotion repeat and their duration is expressed in weeks (that number of weeks is given by Period parameter of the current promotion). Day parameter of the current promotion then indicates at which day of the week each supervision period of the current promotion starts. Month The supervision periods of the current promotion repeat and their duration is expressed in months (that number of months is given by Period parameter of the current promotion). Day parameter of the current promotion then indicates at which day of the month each supervision period of the current promotion starts.
The first supervision period that the current promotion runs on an Account starts upon the first oneshot or nextreq or endcall RTx request made on the Account. Therefore, the duration of the first supervision periods run by the current promotion will rarely match the duration that the current promotion specifies for its supervision periods. In addition, when the supervision periods are expressed either in weeks or in months, the first supervision period that the current promotion runs on an Account will rarely start on the day that Day parameter of the current promotion specifies. Only used when the supervision periods of the current promotion repeat (i.e, when Supervision Type is not set to Fixed).
Period
Indicates the duration of the supervision periods of the current promotion, when these supervision periods repeat. The duration is expressed in the units that Supervision Type parameter indicates.
11 September 2009
Page 689 of 968
Rewarding Accounts
Table 218 - Promotion Tool - Supervision Tab Parameter Day Description
Only used when the duration of the supervision periods of the current promotion are expressed either in weeks or in months (i.e., when Supervision Type parameter is set to either Weekor Month).
When Supervision Type Is Set to Week: Use this parameter to indicate the day of the week at which a supervision period of the current promotion has to start. This must be a value not lower than 0 and not higher than 6. 0 means Sunday, 1 means Monday and so on. When Supervision Type Is Set to Month: Use this parameter to indicate the day of the month at which a supervision period of the current promotion has to start. For example, to indicate the 27th of a month, enter 27 into this parameter. LiteSCE Owner LitesCE Script Specify here the owner of the LiteSCE script that LiteSCE Script parameter of the current promotion specifies. You can have the current promotion running some LiteSCE script every time it is going to add consumed RUM quantities (taken from the network event being processed) into VAL parameter of Counter Counter* of any one of its associated Accounts. Just write that LiteSCE script, then indicate that script name in this parameter and that script owner in LiteSCE Owner parameter of the current promotion.
To have more details, see section 17.5.2.13, Customizing a Promotion (LiteSCE Scripting), on page 680.
Page 690 of 968
11 September 2009
17.5.3.4. Attribution Tab
Threshold Threshold Threshold Threshold Recharge Recharge Recharge Recharge Value 1 parameter Value 2 parameter Value 3 parameter Value 4
Figure 317 - Promotion Tool GUI - Attribution Tab

Figure 318 - Promotion Tool GUI - Attribution Tab (Attribution Type = Oncallprom)
11 September 2009
Page 691 of 968
Rewarding Accounts
Figure 319 - Promotion Tool GUI - Attribution Tab (Attribution Type = Bonus amount)
Table 219 - Promotion Tool - Attribution Tab Parameter Attribution Type Description Indicates whether the rewards that the current promotion grant are credits or discounts. Choose for this parameter one of the following values: Bonus amount Any reward the current promotion grants is a credit. Oncallprom Any reward the current promotion grants is a discount.
Page 692 of 968
11 September 2009
Table 219 - Promotion Tool - Attribution Tab Parameter Period of Discount Granting Description
This parameter is used when, and only when, Supervision Type of the current promotion is set to Fixed.
If the supervision period of the current promotion is one that does not repeat, enter here the duration of the attribution period in terms of days. The attribution period starts as soon as End date has been reached and lasts as long as the number of days that this parameter specifies. Why this Parameter? For a promotion that has repeatable supervision periods, there is no need to specify the attribution period of the value to reward that is in force: The attribution period of the value to reward in force is the current supervision period. When a promotion has a supervision period that does not repeat, the unique supervision period of the promotion completes at the date and time that End date parameter of the promotion specifies. Since no supervision period is allowed to run after End date, and since the value to reward in that case is only known when End date is reached, there must be a way to specify the attribution period of a promotion whose supervision period is one that does not repeat.
You use this parameter to specify the attribution period of a promotion that has a supervision period that does not repeat. Number of Thresholds Indicate here how many ranges of values you want to define for the current promotion. Since you cannot define more than 4 ranges of values, and since it does not make sense you define no range of values, this parameter value must be an unsigned integer value from, and including, 1 to, and including, 4.
11 September 2009
Page 693 of 968
Rewarding Accounts
Table 219 - Promotion Tool - Attribution Tab Parameter Threshold N Description This corresponds to the Nth Threshold parameter (1 <= N <= 4) from the top of Attribution tab of the Promotion Tool object. For example, Threshold 1 parameter corresponds to the highest Threshold parameter that appears in Attribution tab. This parameters value must be an unsigned integer value that is > 0. You use this parameter to define a range of values. To define a range of values with this parameter, enter in it the lowest value of the range of values you want it to define. The entered value is called Threshold N value and the range of values it defines is called Threshold N range of values. When N < 4, Threshold N range of values comprises the values from, and including, Threshold N up to, but not including, Threshold N+1. When N equals 4, the corresponding range of values, which is Threshold 4 range of values, comprises all the values >= Threshold N. Whenever the value to reward belongs to Threshold N range of values and the current promotion grants a reward that is a discount, the granted discount equals the percentage that is specified by Value N parameter, which is the Value parameter that is associated with Threshold N range of values.
Whenever the value to reward belongs to Threshold N range of values and the current promotion grants a reward that is a credit, the granted credit corresponds to the excecution of the the Top-Up Profile specified by the Recharge ID N parameter that is associated with Threshold N range of values.

On how the reward to grant is computed when the current promotion grants a discount, see 17.3.2.7, Indicating How the Granted Credit Has to Be Computed, on page 625. On how the reward to grant is computed when the current promotion grants a credit, see 17.3.2.8, Indicating Which Accounts Value SubRepository Is Granted Credit, on page 636. Enter the Threshold N values in increasing order. That is, if Threshold X and Threshold Y each contain a value, and X < Y, then Threshold Xs value must be less than Thresold Ys value. Naturally, X and Y have to be substituted by some value >=1 and <= 4. Not used when Attribution Type parameter is set to Oncallprom.
Recharge ID N
This parameter is only used when the current promotion grants a credit. This parameter specifies the credit that is granted to a value to reward that belongs to Threshold N range of values. Indicate here the name of a Top-UP Profile.
The name of a Top-Up Profile is given by Name* parameter of the TopUp Profile.
Granting the credit that this parameter specifies consists in executing the Top-Up Profile that this parameter specifies.
Page 694 of 968
11 September 2009
Table 219 - Promotion Tool - Attribution Tab Parameter Value N Description
Not used when Attribution Type parameter is set to Bonus amount.
This parameter is only used when the current promotion grants a discount. This parameter corresponds to the Nth Value parameter (1 <= N <= 4) from the top of Attribution tab of the Promotion Tool object. For example, Value 1 parameter corresponds to the highest Value parameter that appears in Atribution tab parameter. This parameter specifies the discount that is granted to a value to reward that belongs to Threshold N range of values. Enter here a percentage, thus a value that is not lower than 0 and that is not higher than 100.
Any new value you give to Value N parameter of the current promotion applies immediately (i.e., as soon as the new value has been saved into the current promotion) to any value to reward, of the current promotion, that belongs to Threshold N range of values.
17.6. Comparing the Grant Tool, the Discount and the Promotion Tool Objects
Table 220 - Comparing the Grant Tool, the Discount and the Promotion Tool Objects Grant Tool Object Type of Account Prepaid and Pospaid Discount Object Pospaid (this is enforced by the Discount object) Yes Promotion Tool Object Prepaid and Postpaid
Able to Grant a Credit?
Yes
Yes (set Attribution Type parameter, from Attribution tab, to Bonus amount) Yes (set Attribution Type parameter, from Attribution tab, to Oncallprom) Accounts main balance Accounts bundles
Able to Grant a Discount?
No
No
To What Can You Give a Credit?
Accounts main balance Accounts bundles.
Accounts main balance.
11 September 2009
Page 695 of 968
Rewarding Accounts
Table 220 - Comparing the Grant Tool, the Discount and the Promotion Tool Objects Grant Tool Object To What Can You Apply a Discount? Discount Object Promotion Tool Object The discount can be applied to any selection of network event types. Moreover, any type of restrictions can be applied to that selection. Since the discount is granted by executing some Promotion criterion, its the place at which a Usage Rating Rule uses the criterion that indicates to which network event types the discount applies and that indicates in which cases the discount applies to these network event types. Observed value Accounts main balance Accounts counter. Accounts main balance Accounts counter Accounts Age (Months) Accounts User age (Years). Accounts ARENA parameter Absolute Credit? Yes (select Absolute radio button) Yes (select Percentage radio button) Yes (select both Rebate and Discontinuous radio buttons) Yes (select both Percentage and Continuous radio button) Yes (always) Accounts counter
Percentage Based Credit?
No
Page 696 of 968
11 September 2009
Table 220 - Comparing the Grant Tool, the Discount and the Promotion Tool Objects Grant Tool Object Value to reward Discount Object When Percentage and Discontinuous radio buttons are selected, you choose the value to reward independenly of the observed value. It is then either a counter or the main balance. Always the value that the observed value has at the moment that the credit is granted. As a result, the value to reward is either a counter or the main balance.
Promotion Tool Object
Otherwise, it is the observed value. It is then either a counter, the main balance, the Accounts Age, the Accounts User age or an Arena parameter of the Account. Yes (select Continuous option) Yes (select Discontinuous option) Only when the credit to grant is not computed in Tiered mode.
Always the value that the observed value had when the previous supervision period completed. As a result, the value to reward is always a counter.
Tiered Percentage Computed Credit? Tapered Percentage Computed Credit? Can a range of values be forbidden to grant a credit when the observed value belongs to its range?
Yes (select Tiered option) Yes (select Tapered option) Yes.
No
No
11 September 2009
Page 697 of 968
Rewarding Accounts
Table 220 - Comparing the Grant Tool, the Discount and the Promotion Tool Objects Grant Tool Object Points in Time at Which a Reward (i.e., a Credit or a discount) Can Be Granted Upon processing of a Top-Up. Discount Object By the OOC process, at regular pre-defined time intervals. Also upon execution of a, fstreq, a oneshot, or a getandcheckppm if Next discount DT, of the Account being processed, is reached. Promotion Tool Object By the OOC process, at regular pre-defined time intervals, that are called supervision periods. Also upon execution of a fstreq or a oneshot RTx request in case the OOC did not yet process the termination of the previous supervision period. Keep in mind that the granted reward is either a credit or a discount. Keep also in mind that, once a discount has been granted, the discount is applied to network events (through the execution of Promotion criteria referring to the promotion) over the attribution period that starts when the discount is granted. How You Indicate to the CRE that Some Instance of the Object Applies to some Account. Via a Grant criterion that a Top-Up rule uses. The Grant criterion must refer to an instance of Grant Tool object that refers to the Accounts Account Profile. (1 <= N <= 5) All the values equal or below Threshold N parameter value, down to the next lower threshold value (which is the value of Threshold N-1 when N > 1and which is 0 when N=1). Via one or more instances of Account Discount object that refer both to an instance of Discount object and to the Account. Via a Supervision criterion that some Usage Rating Rule uses and, in case the instance is about granting discounts, via a Promotion criterion that some Usage Rating Rule uses. Both the Supervision and the Promotion criteria must refer to an instance of Promotion Tool object that refers to the Accounts Account Profile. (1 <= N <= 4) Follows the same logic as Discount object: All the values equal or above Threshold N parameter value, up to the next higher threshold value (which is the value of Threshold N+1 when N < 4 and which is the infinite when N = 4).
What Range of Values Does a Threshold N Parameter Specify?
(1 <= N <= 5) All the values equal or above Threshold N parameter value, up to the next higher threshold value (which is the value of Threshold N+1 when N < 5 and which is the infinite when N = 5).
Page 698 of 968
11 September 2009
18. Preferred Charging

18.1. Introduction
The Preferred Charging feature consists in offering the Customers the possibility to manage a list of identifiers for which they are entitled to benefit from cheaper Tariffs. This feature is achieved thanks to the Friends and Family framework. Furthermore, the Friends and Family framework enables other features than the preferential charging. Thanks to the widely applicable Friends and Family Criterion, other decisions can be made according to the destination of the event, based on an individual list of the calling Customer: what is the Service triggered by the current event? (in the Service Rule) what account should be charged for the current event? (in the Charging Rule) what is the Usage Rating Rule to be applied for the current event? (in the Rating Plan Rule) Finally, the Friends and Family framework can be part of the Product Catalog, defined as a Service to which Fees and specific Top-ups can be associated. The typical implementation of the Friends and Family feature as a Service is via an Add-On Service Offer Group. For detailed explanation, please see section 9.6.1.1, "Add-On Service Offer Group", on page 270.
18.2. Friends and Family List object


The Friends and Family List object allows creating and naming Friends and Family Lists, which gather Friends and Family Members. Each Member of a Friends and Family List has a particular Type inside that List. The Friends and Family List is referenced in the Customer (or Account) object. The Friends and Family scheme is completed by the Friends and Family Criterion. This criterion is initially mainly intended for offering a preferential Tariff to the Customers preferred list of identifiers. Nevertheless, it is not restricted to the Usage Rating Rules; it can be used in any decision tree of the Product Catalog.
FF List Name* parameter
Figure 320 - Friends and Family List GUI
11 September 2009
Page 699 of 968
Preferred Charging
Table 221 - Friends and Family List - pchglist Parameter Service Retailer*
servret
Description Reference to the Service Retailer defining the current Friends and Family List. Name of the current Friends and Family List. The Friends and Family List is referenced in the Customer object.
FF List Name*
pclname
18.3. Friends and Family Member Type object

The Friends and Family Member Type object allows distinguishing different types among the Members of a Friends and Family List. The Friends and Family Member Type is referenced by the Friends and Family Criterion. Consequently, the Member Type parameter somehow implements the feature of sub-lists inside the unique Friends and Family List. For detailed explanation about the determining role of the Friends and Family Member Type in the fulfilment of the Friends and Family Criterion, please see parameterFriends and Family Member Type on page 427 and section 12.3.13, "Friends and Family Criterion", on page 426.
FF Member Type Name* parameter
FF Member Type Identifier* parameter
Figure 321 - Friends and Family Member Type GUI
Table 222 - Friends and Family Member Type - pchgtyp Parameter Service Retailer*
servret
Description Reference to the Service Retailer defining the current Friends and Family Member Type.
Page 700 of 968
11 September 2009
Table 222 - Friends and Family Member Type - pchgtyp Parameter FF Member Type Name*
pctname
Description Name of the current Friends and Family Member Type. This parameter is referenced in the Friends and Family Member object. Numeric identifier of the current Friends and family Member Type. The Member Type Identifier range is from 2 to n. Indeed, 0 and 1 are special values corresponding to: 0 = no Member Type 1 = any Member Type This parameter is referenced in the Friends and Family Criterion or sent by the RTx in the trigger message.
FF Member Type Identifier*

pctnbr
18.4. Friends and Family Member object

A Friends and Family Member is an element of a Friends and Family List. It is defined by three elements:
1.
2. 3.
its character string identifier;

the Friends and Family List it belongs to; the Friends and Family Member Type that it holds within that List.
In any decision tree, the Friends and Family Criterion will be met only if the called party is a member of the Friends and Family List of the calling party and if the Type of that Friends and Family Member within the List matches the type specified by the criterion or provided by the RTx.
11 September 2009
Page 701 of 968
Preferred Charging
Member Identifier* parameter Member Type* parameter
Figure 322 - Friends and Family Member GUI
Table 223 - Friends and Family Member - pchgcol Parameter Service Retailer*
aservret
Description
Reference to the Service Retailer defining the current Friends and Family Member. Identifier of the current Friends and Family Member. Since the data type is a character string, the Member Identifier can be either a regular phone number or any alphanumeric identifier, like an e-mail address for instance. Reference to the Friends and Family Member Type Name of the current Friends and Family Member, in the current Friends and Family List.
Member Identifier*
id
Member Type*
pctypnbr
Identical Member Identifiers in a List
It is possible to have the same Friends and Family Member Identifier appearing several times in on Friends and Family List. In that case, the Member Identifier Type has to differ. For instance, one of the Customers colleagues (FNF Member Type x) can also be registered as a friend of his (FNF Member Type y). List*
pclist
Reference to the Friends and Family List to which the current Identifier belongs.
Page 702 of 968
11 September 2009
Part VI. Balance Management
11 September 2009
Page 703 of 968
Creating and Provisioning Accounts
19. Creating and Provisioning Accounts

19.1. Account Profile object
Whenever you create an Account, you need to associate an Account Profile with it. Moreover, each Account is attached to one, and only one, Account Profile. You will commonly associate several Accounts to a given Account Profile. You will thus use Account Profiles to configure settings that are common to a large range of Accounts. In an Account Profile, you indicate things such as: The default type of the Accounts associated with the Account Profile. The preferred identifiers that the Accounts associated with the Profile can reach at a free or better Tariff. What notifications (e.g., warnings, confirmations, and so on) are enabled on the Accounts associated with the Account Profile.
The tuning of the life cycle that will be applied to those Accounts. Note: You can set up as many Account Profiles as you want. Note: You can think of an Account Profile as some sort of blueprint of a range of Accounts you want to supply. Thus, every time you will need to design a new type of Account that you will want to make available to your customers, you will in the first place spend time designing the Account Profile of these Accounts. While, on the other hand, any Account associated with the Account Profile will contain information that is specific to the Account.
19.1.2. Types of Account Profile Parameters

Be however aware that an Account Profile contains four types of parameters: Creation Default parameters. Such an Account Profile parameter is used as a default value upon creation of an Account, and only upon creation of an Account. Since such an Account Profile parameter is acting as a default, it goes without saying that it has a counterpart in the Account object. And that giving a value to that counterpart is optional. An Account Profile parameter that is an Creation Default works as follows: If, at time the CRE creates an Account, the counterpart, in the Account, of the parameter did not receive a value (e.g., from an operator), the value of the Account Profile parameter is copied into the Account counterpart.
Page 704 of 968
11 September 2009
On the notifications that can be enabled on an Account, see section 5.1, Notification Feature Table Object, on page 161.
From that moment on, the Account Profile parameter and its Account counterpart start living independently of one another. That is, modifying an Account Profile parameter that is an Creation default never impacts the parameters of already existing Accounts. Account Profile objects Default Language parameter is one example of Creation Default parameter. Run Time Default parameters. Such an Account Profile parameter is used as a default value at any moment of an Account life. Here too, since such an Account Profile parameter is acting as a default, it has a counterpart in the Account object. And, here too, giving a value to that counterpart is optional. However, unlike the value of an Account Creation Default parameter, the one of a Run Time Default parameter is never copied into an Account. Simply, if the CRE needs to use the value of the counterpart in the Account, and the counterpart did not receive any value, the CRE uses the value of the corresponding Run Time Default parameter from the associated Account Profile. Account Profile objects Activity Period parameter is one example of a Run Time Default parameter. It is used whenever an Account neither specifies a Begin Activity Date nor a Begin Inactivity Date (which is another name for End Activity Date, since the end of an Accounts activity period always starts its inactivity period). Shared parameters. Unlike those that specify default values, these Account Profile parameters have no counterpart in Account object.
In fact, you can see a Shared parameter as one that belongs to each Account that is attached to its Account Profile. Everything happens thus as if the Shared parameter were really belonging to each Account that is attached its Account Profile. As a result, changing the value of a Shared parameter will affect all the Accounts that are attached to its Account Profile. Own parameters. An Account Profile has parameters that none of its attached Accounts use. LiteSCE Pool Script parameter of the Account Profile object is one example of such a parameter. Although an Account has also a parameter called LiteSCE Pool Script parameter, the one of the Account Profile, of the Account, does not act as a default for the Account. Indeed, if the LiteSCE Pool Script parameter of an Account is empty, the Account has then no LiteSCE Pool Script. Which means that LiteSCE Pool Script parameter of the Account Profile, of the Account, is then not used as the LiteSCe Pool Script of the Account. Note: The tables below, which document the Account Profile parameters, also indicate the type of each Account profile parameter.
11 September 2009
Page 705 of 968
Figure 323 - Account Profile GUI
Table 224 - Account Profile - servclas Parameter Service Retailer*

servret
Description Reference to the Service Retailer defining the current Account Profile.
Account Profile Name*

name
Name of the current Account Profile.
Page 706 of 968
11 September 2009
Figure 324 - Account Profile GUI - General Tab

11 September 2009
Page 707 of 968
Table 225 - Account Profile - General Tab Parameter Default Account Type*
proftype
Description Use this parameter to indicate whether the Accounts created from this profile have to be, by default, either Prepaid or Postpaid ones. If an Account must by default be a Prepaid one upon its creation, select one of the following in its Account Profile: Prepaid Regular Prepaid This kind of Account is regular in the sense that its customer is seen as a regular customer. If an Account must by default be a Postpaid one upon its creation, select one of the following in its Account Profile: Controlled Postpaid Postpaid
Type Creation Default

The CRE makes no difference between pure Prepaid and Regular Prepaid Accounts. Indeed, its how you set the other parameters of the Account Profile (in fact, mainly its Minimum Credit Allowed and Maximum Credit Allowed parameters) that makes a Prepaid Account, attached to the Account Profile, behave as a pure Prepaid one or not. Of course, if you configured the Account Profile to make its Accounts work as a Regular Prepaid Account, it is cleaner you set this parameter to Regular Prepaid, in order to make explicit (to document) to the CRE operators that the Account Profile is one that makes its Accounts work as Regular Prepaid Accounts. The CRE makes no difference between pure Postpaid and Controlled Postpaid Accounts. Indeed, its how you set the other parameters of the Account Profile (in fact, mainly its Minimum Credit Allowed and Maximum Credit Allowed parameters) that makes a Postpaid Account, attached to the Account Profile, behave as a pure Postpaid one or not. Of course, if you configured the Account Profile to make its Accounts work as a Controlled Postpaid Account, it is cleaner you set this parameter to Controlled Postpaid, in order to make explicit (to document) to the CRE operators that the Account Profile is one that makes its Accounts work as Controlled Postpaid Accounts.
Page 708 of 968
11 September 2009
To override this default (which is applied at time an Account is created, and only then), you need to check Prepaid Account* check box in the Account to create.
Table 225 - Account Profile - General Tab Parameter Default Language*

language
Description Reference to one of the languages defined in the CRE database. This is thus a reference to an instance of Language object. If, at time an Account is being created, that Accounts Default Language parameter received no value, the Account receives the value of this parameter, from the Account Profile that the Account is specifying.
Type Creation Default
If the language you want to specify does not appear in the list that shows up when clicking on the button that is to the right of this parameter, you firstly need to make that language known to the CRE by creating an instance of Language object for it. Shared
Reset Credit During Inactivity

actcre
This parameter indicates whether the main balance of the Account has to be reset to min credit when the CRE sets the Account Inactive.
This parameter does not affect the bundles of the Account.
Thus: When the CRE sets an Account to Inactive and Reset Credit During Inactivity parameter of its Account Profile is checked, the main balance of the Account is reset according to value of 'Minimum Credit Allowed' parameter of Account Profile. i.e., it is set to the 'Minimum Credit Allowed' value. Else, When the CRE sets an Account to Inactive, the main balance of the Account is not updated. Moreover, this parameter also indicates whether a Top-Up done on the main balance of an inactive Account, attached to this Account profile, cumulates or not with the current value of that balance. More precisely: When an Account is inactive and Reset Credit During Inactivity parameter of its Account Profile is checked, doing a TopUp on the Accounts main balance sets the Accounts main balance to the Top-Up amount. That is, the CRE resets the main balance of the Account prior to doing a Top-Up on the Accounts balance. When an Account is inactive and Reset Credit During Inactivity parameter of its Account Profile is not checked, doing a Top-Up on the Accounts main balance increments the Account balance by the Top-Up amount. In other terms, the CRE does not reset the main balance of the Account prior to doing a Top-Up on the Accounts balance. Also, before reseting the credit, value of arena variable "tmc_cred" is checked.If it exists, then credit is compared with its value. If the user's credit is less than the value of this parameter, no reseting of credit is done. Else, credit is reset to "Minimum Credit Allowed" value.
11 September 2009
Page 709 of 968
Table 225 - Account Profile - General Tab Parameter General Ledger Code for Discarded Credit
rst_glc1
Description
Type
Only available when the Reset Credit During Inactivity flag is checked.
Reference to the General Ledger Code to be inserted in the EDR emitted by the CRE when the Main Balance is reset because of the Inactivity of the Account. When such a reset occurs, the General Ledger Code will be associated to the amount of money removed from the Main Balance. This ensures the consistency of the financial records. Amount of money that is initially present on the balance whenever an Account, attached to this Account Profile, is created. This must be a decimal value, whether positive or negative, expressed in the same units as the Accounts balance. What value you will put here depends on the type of the Accounts of the Account Profile. For Prepaid Accounts, you will normally want to set this parameter to a value that is greater than zero. For Postpaid Accounts, you will normally want to set this parameter to zero. Creation Default
Credit Allocation at Account Creation

initcred
On the other hand, this parameter value could be lower than Exhaustion Threshold. But it would make little sense to set the value of Credit Allocation at Account Creation so.
Default value: 0.
General Ledger Code for Credit Allocation

rst_glc3
Reference to the General Ledger Code to be inserted in the EDR emitted by the CRE when an Account is created with an initial amount of money on its Main Balance. When an Account is created using the current Account Profile, the General Ledger Code will be associated to the amount of money directly allocated to the Main Balance (see Credit Allocation at Account Creation above). This ensures the consistency of the financial records.
Page 710 of 968
11 September 2009
The value of this parameter cannot be lower than Minimum Credit Allowed. Moreover, it cannot be higher than Max Credit Allowed. These two consistency constraints are enforced by the CRE.
Table 225 - Account Profile - General Tab Parameter Maximum Credit Allowed
maxcred
Description Maximum amount of money that can be present on the main balance of any Account attached to this Account Profile.
Type Shared
Thus, the check is only made on the main balance.
This parameter value is only checked in the following cases: At time an Account is created, in order to make sure that this parameter value is greater than or equal to Credit Allocation At time of a Top-Up, in order to prevent the Accounts main balance to go beyond this parameter value. A Top-Up that attempts to make the main balance go above this parameter value will thus fail. Moreover, a failed Top-Up does not modify the main balance value.
In essence, Top-Ups are a feature that is normally not offered for a Postpaid Account (whether it is Controlled or not). As a result, although nothing in the CRE prevents a Postpaid Account (whether it is Controlled Postpaid or not) to be topped up, no Top-Ups are usually made on a Postpaid Account (whether it is Controlled Postpaid or not). Nevertheless, even when a Postpaid Account is not subject to Top-Ups (which is the normal case), you need to set this parameter value. In that case, you should set this parameter to the same value as Credit Allocation at Account Creation (which is typically equal to zero for a Postpaid Account).
This must be an decimal value, whether negative or positive, expressed in the same units as the Accounts balance. Of course, for a Prepaid Account (whether Regular or not), you will normally want this parameter value to be strictly positive. While, for a Postpaid Account (whether Controlled or not), you will normally want to set this parameter value to 0.
11 September 2009
Page 711 of 968
Table 225 - Account Profile - General Tab Parameter 1st Credit Warning Threshold
lowcredw
Description The CRE makes it possible to warn an Accounts owner that the level of the Accounts main balance has become too low. Up to two such Credit Warning Threshold warnings can be issued to the Accounts owner. Its in the Account Profile of the Account that you indicate from which levels (i.e., thresholds) of the Accounts main balance the first and the second warnings are to be issued. This parameter specifies the main balance value below which the first Credit Warning Threshold warning is to be issued. As this parameter belongs to the Account Profile, it equally applies to all the Accounts associated with the Account Profile. This parameter is expressed in the same units as the Accounts main balance. It is thus a decimal value.
Type Shared
See also Decimal Value, on page 36.

As soon as the CRE sees that the main balance value is below this parameter value, the CRE issues the first Credit Warning Threshold warning on the Account.
To have the CRE issuing such a warning notification on the Accounts associated with the Account Profile, you need to enable Credit Warning Threshold notification type, of Credit Level on Main Balance notification feature, on the Account Profile.
Level on Main Balance on an Account Profile, see Enabling a Given Notification Type on a Given Account, on page 178.
On how you enable Credit Warning Threshold notification type, of Credit
See also What Does When a Notification Feature Sees that... Means, on
page 184.
Page 712 of 968
11 September 2009
Table 225 - Account Profile - General Tab Parameter 2nd Credit Warning Threshold
lowcred2
Description
Type Shared
Please read also 1st Credit Warning Threshold, on page 712.

This parameter specifies the main balance value below which the second Credit Warning Threshold warning is to be issued. This parameter is expressed in the same units as the Accounts main balance. It is thus a decimal value.
See also Decimal Value, on page 36.

As soon as the CRE sees that the main balance value is below this parameter value, the CRE issues the second Credit Warning Threshold warning on the Account.
To have the CRE issuing such a warning notification on the Accounts associated with the Account Profile, you need to enable Credit Warning Threshold notification type, of Credit Level on Main Balance notification feature, on the Account Profile.
Level on Main Balance on an Account Profile, see Enabling a Given Notification Type on a Given Account, on page 178.
On how you enable Credit Warning Threshold notification type, of Credit
page 184.
Enable Exhaustion Threshold Check

exhausfl
You use this parameter to indicate whether detection of main balance exhaustion is enabled or not on the Accounts belonging to the Account Profile. Whenever this parameter is checked, the detection is enabled.
Shared
At time you enable the detection, make sure that Exhaustion Threshold parameter of the Account Profile is suitably filled in.
Otherwise, the detection is not enabled, whether you specified some value into Exhaustion Threshold parameter or not.
Normally, you will want to enable detection of main balance exhaustion on Controlled Postpaid Accounts only. Of course, nothing prevents you, if you want it, to enable detection of main balance exhaustion on any Account type.
Default value: Not checked.
11 September 2009
Page 713 of 968
Table 225 - Account Profile - General Tab Parameter Exhaustion Threshold (1/ 2)
lowcred
Description Whenever detection of main balance exhaustion is enabled for the Accounts of this Account Profile: The CRE uses this parameter value for deciding whether an Account, of the Account Profile, has to receive Exhausted administrative status or not. That is, as soon as the CRE sees that the main balance, of an Account of this Account Profile, gets lower than this parameter value, the CRE makes the Account enter the Exhausted administrative status. And, as soon as the CRE sees that the main balance, of an Account of this Account Profile, gets higher than this parameter value, the CRE makes the Account exit the Exhausted administrative status. Whenever detection of main balance exhaustion is not enabled for the Accounts of this Account Profile: The CRE does ignore this parameter value. There is no Exhaustion Threshold.
Type Shared
On enabling/disabling main balance exhaustion detection, see Enable

Exhaustion Threshold Check, on page 713.
When the Account receives Exhausted administrative status, its Life Cycle Status is unchanged (it remains Active). It remains active because the Account can still be used to pay, although some restrictions apply.
Choosing a Value for this Parameter You need to give this parameter a value that is greater than Minimum Credit Allowed and less than Maximum Credit Allowed. This is a decimal value, whether positive or positive, expressed in the same units as the Accounts main balance. Note that you would set up an Exhaustion Threshold for a Postpaid Account only if you want it to be a Controlled one. You would then give it a negative Exhaustion Threshold, since Postpaid Accounts initial balance is usually set to 0. For Prepaid Accounts (whether Regular or not), you would normally use no Exhaustion Threshold. Exhaustion Threshold (2/ 2) Typical Use of this Parameter
Before you read this example, you might want to read the documentation
of Exhausted, on page 772. It explains which restrictions Exhausted puts on an Accounts use.
One example of Exhaustion Thresholds use is if you want that, from some Accounts balance value, the CRE stops charging usage RTx requests, except for Direct Chargings that require no credit check ones, on the Accounts balance but still leave enough money on the balance for paying the fees. In that case, you would want to set Exhaustion Threshold and Minimum Credit Allowed such that the difference between their values still makes it possible to pay the fees.
Page 714 of 968
11 September 2009
Table 225 - Account Profile - General Tab Parameter Do Not Set Account Inactive If Min. Credit Reached Description Its up to you to decide whether the Life Cycle Status, of any Account that is associated with this Account Profile, will be set to Inactive or not whenever the main balance of the Account becomes lower than Minimum Credit Allowed parameter value (i.e. when no more credit is available on the main balance). Uncheck this parameter if you want that the Life Cycle Status of any Account, associated with the Account Profile, becomes Inactive in consequence of the Accounts Main Balance becoming lower than Minimum Credit Allowed. Check this parameter if you want that the Life Cycle Status of any Account, associated with the Account Profile, does not change when the Accounts Main Balance becomes lower than Minimum Credit Allowed. Default value: Unchecked. Minimum Credit Allowed (1/2)
Type Shared
Whenever the CRE sees that the balance of an Account, attached to this Account profile, becomes lower than this parameter value: The Accounts Administrative Status is set to No more credit administrative status, and If Do Not Set Account Inactive If Min. Credit Reached parameter of the Account Profile is checked, the Accounts Life Cycle Status remains as it is. Else, the Accounts Life Cycle Status is set to Inactive.
Shared
mincred

For a Prepaid account (whether Regular or not), you will normally want to set this parameter to zero. For a Postpaid Account (whether Controlled or not), setting this parameter value to zero means that the Minimum Credit Allowed is set to minus infinite. In other terms, setting it so means that no minimum credit is set on the Postpaid Account. For a Pure Postpaid Account (that is, a PostPaid Account that is not a Controlled one), you will normally want to set this parameter to zero, in order to indicate that no minimum credit is set on the Account. For a Controlled Postpaid Account, you will normally want to set this parameter either to zero or negative. But if you set this parameter to zero in an Account Profile for Controlled PostPaid Accounts, you should Enable Exhaustion Threshold Check and suitably set Exhaustion Threshold parameter. Indeed, if you do not do that, the Account Profiles Accounts will behave as Pure Postpaid ones. No notification is sent whenever this minimum is reached. To have a notification issued when an Accounts balance, of an Account attached to this profile, becomes lower than Minimum Credit Allowed, or is about to be lower, simply make either 1st Credit Warning Threshold or the 2nd Credit Warning Threshold match this parameter value.
11 September 2009
Page 715 of 968
Table 225 - Account Profile - General Tab Parameter Minimum Credit Allowed (2/2) Description Choosing a Value for this Parameter This must be a decimal value, whether positive or negative, expressed in terms of the Accounts balance units. What If the Accounts Life Cycle Status is set to Inactive? Because it is Inactive, the Account (and thus its balance and its bundles) can no longer be used for doing payments. Type
There is of course one exception: Direct Chargings that require no credit check (they correspond to Direct Debit RTx requests whose dirdebit parameter is set to 2). By definition, such Direct Chargings bypass the credit checks.
You can of course still do Top-Ups on the Accounts balance. And if a Top-Up makes the Accounts balance go above this parameter value, the Account Life Cycle Status then automatically goes back to the Active state. Do not cut off ongoing session
cutsess
This parameter is not used by the CRE.
Shared
First Event Bonus

fcabonus
Amount of money that is added to the main balance of an Account, that is attached to this Account Profile, at time the activation of the Account is performed in consequence of an RTx request.
Shared
Only the following connectors can perform an Account activation: oneshot connector, fstreq connector and getandcheckppm connector. These connectors perform the activation of the Account they are processing whenever they see that the Account Life cycle Status equals Valid and that the Account is still in its validity period. That is, in that case, they set the Accounts Life Cycle Status to Active, and naturally then add First Event Bonus to the Accounts balance. As this bonus is due to some RTx request, it is not added to the Accounts main balance when it is an operator that performs the activation of the Account. An operator can always manually perform an Accounts activation. The operator does by making the Accounts Life Cycle Status go from Valid to Active.
This must be a decimal value, expressed in the same units as the Accounts balance.
Page 716 of 968
11 September 2009
Table 225 - Account Profile - General Tab Parameter Duration for Termination Calls Bonus (TC bonus)
tcbonus
Description The TC bonus is granted to the account as soon as the user recieves a given number of charged terminating calls. Hence, at the end of any charged terminating call, if the total duration of the call is greater than the pre-defined threshold, the counter is incremented. The bonus is granted, as soon as this counter reaches the threshold . This bonus modifies the duration of the active and the inactive periods of the main balance as well as the last recharge date. The solution is implemented through the promotion tool and the counter that measures the TC calls received by the customer. A LiteSCE script increments the counter only if the call duration is higher than the threshold, which is configured in the account profile.
Type
Activity Period*
dactiv
Length of the activity period (in number of days) of any Account attached to this Account Profile, provided that the Account does not define its own activity period. This must be a positive integer value, limited to 4 digits. Thus, the maximum value that can be entered here is 9999.
Run Time Default

An Account defines its own activity period by specifying both a Begin Activity Date and a Begin Inactivity Date, in which case the length of the Accounts activity period is no longer this parameter value, but the length of the period of time from Begin Activity Date until Begin Inactivity Date.
please see parameter Life Cycle Status (1/2), page 762.
For more information about the 5 statuses of the Accounts Life Cycle,
Inactivity Period*
dinactiv
Length of the inactivity period (in number of days) of any Account attached to this Account Profile, provided that the Account does not define its own inactivity period. This must be a positive integer value, limited to 4 digits. Thus, the maximum value that can be entered here is 9999.
Run Time Default
An Account defines its own inactivity period by specifying both a Begin Inactivity Date and an End Inactivity Date, in which case the length of the Accounts inactivity period is no longer this parameter value, but the length of the period of time from Begin Inactivity Date until End Inactivity Date.
11 September 2009
Page 717 of 968
Table 225 - Account Profile - General Tab Parameter Validity Period*

dvalid
Description Length of the validity period (in number of days) of any Account attached to this Account Profile, provided that the Account does not define its own validity period. This must be a positive integer value, limited to 4 digits. Thus, the maximum value that can be entered here is 9999.
Type Run Time Default
An Account defines its own validity period by specifying both a Begin Validity Date and an End Validity Date, in which case the length of the validity period of the Account is no longer defined by this parameter, but the length of the period of time from Begin Validity Date until End Validity Date.
Begin Date Activation

fcabegin
Thus, the First Event Bonus of a given Account Profile is granted to an Account, associated with that Account Profile, whatever the date of the Accounts activation.
End Date Activation

fcacend
Thus, the First Event Bonus of a given Account Profile is granted to an Account, associated with that Account Profile, whatever the date of the Accounts activation.
Page 718 of 968
11 September 2009
Table 225 - Account Profile - General Tab Parameter Maximum Activity End Date Fix Date*
macend_d
Description For each Account that is attached to this Account Profile, Begin Inactivity Date of the Account cannot exceed Maximum Activity End Date Fix Date. Choose very carefully the value of this parameter: it specifies an absolute date at which all the Accounts, attached to this Account Profile, will be set Inactive, whatever the activation date of these Accounts. This must be a date. Entering a value in this parameter is mandatory. For that reason, if you do not want to set a Maximum Activity End Date - Fix Date, you need to enter here the highest date the CRE can handle. Doing that of course still sets a Maximum Activity End Date - Fix Date, but one that is very far in the future.
Type Shared
Every time a Top-Up is done on an Account, its Begin Inactivity Date is recalculated, according to the Activity Reload Algorithm that the Top-Up profile, used for doing the Top-Up, specifies. The goal is often to make the Top-Up extend the activity period (which ends at Begin Inactivity Date) of the Account, by simply increasing Begin Inactivity Date of the Account. By setting up this parameter, as well as Maximum Activity End Date Nb. Days, you impose some limitation to the activity period extensions performed. Maximum Activity End Date Fix Date* is not taken into account (during a top-up) if Maximum Activity End Date Nb. Days* is defined and not null. The only way to take into account Maximum Activity End Date Fix Date* is to set Maximum Activity End Date Nb. Days* to 0. The CRE uses Unix time. As a result, the highest feasible date falls in 2106. It is thus safe to set this parameter to 31/12/2105.
Note: when entering a date via a GUI, the display format used is dd/mm/yy, but the actual value is stored in the DB along dd/mm/yyyy format. 2105 will show as 05 but will be stored as 2105.
11 September 2009
Page 719 of 968
Table 225 - Account Profile - General Tab Parameter Maximum Activity End Date Nb. Days*
macnb_d
Description For each Account that is attached to this Account Profile, Begin Inactivity Date of the Account cannot exceed Begin Activity Date (of the Account) + Maximum Activity End Date Nb. Days.
Type Shared
Maximum Activity End Date Fix Date* is not taken into account (during a top-up) if Maximum Activity End Date Nb. Days* is defined and not null. The only way to take into account Maximum Activity End Date Fix Date* is to set Maximum Activity End Date Nb. Days* to 0. Every time a Top-Up is done on an Account, its Begin Inactivity Date is recalculated, according to the Activity Reload Algorithm that the Top-Up profile, used for doing the Top-Up, specifies. The goal is often to make the Top-Up extend the activity period (which ends at Begin Inactivity Date) of the Account, by simply increasing Begin Inactivity Date of the Account. By setting up this parameter, as well as Maximum Activity End Date Fix Date, you impose some limitation to the activity period extensions performed.
For example, say that the activity period of an Account is 6 months long, that this parameter is set to 1095 (as these are days, this implies a 3 years period of time) and that a Top-Up extends the activity period of the Account by one month. Say also that the Account was activated on 03 july 2005: From almost 03 june 2008 on, it wont be possible to extend the Accounts activity period, which in any case will elapse on 03 july 2008. Note: Entering a value in this parameter is mandatory and the value entered in this field must be greater than the value entered in the parameter Activity Period.
Page 720 of 968
11 September 2009
By means of this parameter, you can thus define a period of time that starts from the date of the Account activation and during which the activity period of the Account is allowed to be extended (a Top-Up usually extends the activity period of the Topped Up Account). Once that period of time is over, it is no longer possible to extend the Accounts activity period.
Table 225 - Account Profile - General Tab Parameter New Language Selection at First Call
newlang
Description This is an SDP parameter. As a result, this parameter is neither used nor managed by the CRE. It is an OSP service (such as an RTx), thus other than the CRE, that has to manages this parameter. When an OSP service, thus other than the CRE, handles this parameter, it must handle it such that: Whenever this flag is checked, the OSP service has to request the user to select a language at time of first call by the user. Otherwise, the OSP service must not request that to the user.
Type Shared
The CRE does not implement users selection of the language. It simply presents and stores the value of this parameter.
General Ledger Code for Discarding Operations

rst_glc4
Reference to the General Ledger Code to be inserted in the EDR emitted by the CRE when a PURGE ACCOUNT command is performed. When the Account is removed, its Main Balance and its Buckets are removed as well. When such value removal occurs, the General Ledger Code will be associated to the amount of money contained in the removed Accounts Main Balance. and to the quantities contained in the removed Accounts Buckets. This ensures the consistency of the financial records.
See also How to Cleanly Remove an Account: the Purge Account

Command, on page 794.
Figure 325 - Account Profile GUI - Charging Tab
11 September 2009
Page 721 of 968
Table 226 - Account Profile - Charging Tab Parameter Fee Period*

feeper
Description This parameter is no longer used.
Type Shared
Enable Friends and Family

fnfdeflt
Whenever this check box is checked, the Friends and Family feature is enabled for the Accounts attached to this Account Profile. Otherwise, the Friends and Family feature is disabled for these Accounts.
Shared
Naturally, if, at time this parameter becomes unchecked, some Accounts attached to this Account Profile have a Friends and Family list, everything in the CRE will happen as if these Accounts no longer had a Friends and Family list. Shared
Maximum Number of Friends and Family

ff_max
This parameter is not used.
This is thus a value that expresses a number of months.
See also section 17.3, Discount Object, on page 616. See also Next Discount DT, on page 768.
Page 722 of 968
11 September 2009
Billing Date Period
Whenever one or more instances of Discount object are associated with an Account attached to this Account Profile, the discounts, that these instances of Discount object specify, are computed and granted to the Account every Billing Date Period months.
Shared
Table 226 - Account Profile - Charging Tab Parameter Evaluation Limit (1/2)
lim_eval
Description At time the CRE rates quantities to reserve, the amount of money, available on the Accounts main balance for reservation, is compared against this parameter value. If that amount of money is higher than this parameter value, the CRE does a coarse rating of these quantities. Otherwise, the CRE does an accurate rating of these quantities. This parameter value is expressed in the same units as the Accounts main balance. It is thus a decimal value. Note it does not make sense you give a negative value to this parameter. Why this Parameter? When a tariff switch is detected on quantities to reserve, doing a coarse rating on them is more efficient than accurate rating. But, since it is inaccurate, coarse rating may lead to an over-, or an under-estimation, of the real cost that the CRE calculates at time it commits the used part of the reserved quantities. Coarse rating is thus not desirable when the above drawbacks are an issue. Not being able to commit reserved quantities is an example of when these drawbacks become an issue.
Type Shared
When this parameter is suitably tuned, you can avoid these drawbacks whenever they are an issue and still benefit of coarse rating advantages whenever these drawbacks are not an issue. Whats the Accurate Rating of Quantities to Reserve? Accurately reserving quantities means what follows: If the CRE detects that a tariff switch has to be applied when reserving quantities, it uses the old tariff (i.e., the tariff prior to the switch) to rate the part of these quantities subject to the old tariff and it rates the other part of these quantities with the new tariff (the one that the tariff switch indicates). Whats the Coarse Rating of Quantities to Reserve? Coarsely rating reserving quantities means what follows: Even if the CRE detects that a tariff switch has to be applied when reserving quantities, the CRE rates all the quantities to reserve with the old tariff, ignoring the tariff change. Thus, when a tariff switch applies, coarse rating is more efficient than accurate rating, since one tariff is computed instead of two.
11 September 2009
Page 723 of 968
Table 226 - Account Profile - Charging Tab Parameter Evaluation Limit (2/2) Description About the Amount that Is Compared Against Evaluation Limit The amount of money available on the main balance for reservation, that is compared against Evaluation Limit, equals Main balance - Minimum Credit Allowed - total cost of quantities reserved on the Account in the past and not yet committed. Thus if Main Balance = 5, Minimum Credit Allowed = -10, total cost of quantities reserved in the past on the Account and not yet committed = 3, the amount that will be compared against Evaluation Limit amounts to: 5 - (-10) - 3 = 12. Maximum Credit Amount per Top-Up
reloadmx
Type
Whenever a Top-Up is requested on an Account that is attached to this profile, the credit amount that the Top-Up is requesting cannot exceed this parameter value. This limitation applies whether the Top-Up request specifies a Top-Up Profile or not. It also applies whether the Top-Up request is a direct Top-Up RTx request or a credit update RTx request. This must be a signed integer value. Default value: 0.
Shared
Max. Failures per Top-Up Attempt (1/2)

maxbadre
This parameter indicates the maximum number of admissible failures an Account belonging to this Account Profile may have per Top-Up request.
Shared
A not binding example for a possible failure during a Top-Up attempt is when a Customer has given a wrong Scratch Card Recharge Code. He may then re-enter up to Max. Failures per Top-Up Attempt times the code before the Top-Up request is disconnected.
By default, the CRE does not count the number of retries of a Top-Up. And even if it were counting them, it would not compare the result of the counting against this parameter. As a result, if you only rely on the default behavior of the CRE, it does not make sense you enter any value in this parameter: It wont be used. Thus, if you need the failures of a Top Up attempt to be counted and compared against this parameter value, you have to choose and suitably configure one of the mechanisms that the CRE offers for that.
This flexibility enables a network operator to implement its own definition of an admissible failure during a Top-Up attempt. This is why the CRE by default neither detects nor counts such failures.
Talking of flexibility makes one think to LiteSCE scripts. And indeed, a network operator can use LiteSCe scripts for counting failures of aTopUp attempt and comparing the counting against this parameter. In this case, the LiteSCE scripts would be responsible for implementing the network operators own definition of admissible failures.
Page 724 of 968
11 September 2009
Table 226 - Account Profile - Charging Tab Parameter Max. Failures per Top-Up Attempt (2/2) Description But there other ways for a network operator to monitor Top-Up failures. One of these ways is the net_evt.fraudupd connector. In that case, its the RTx that has to implement the network operators own definition of an admissible failure during a Top-up attempt, because it is then up to the RTx to detect whether a Top-Up request is a retry of a previous one or not. And, every time the RTx detects a Top-Up retry (that thus corresponds to the RTx own definition of admissible failure), the RTx must warn the CRE of that. For that, the RTx must trigger net_evt.fraudupd connector with the suitable RTx request. The connector logic then uses the information in the RTx request to increment Bad Top-Up Attempt Counter of the Account. As soon as the counter has been incremented, the connector logic then checks whether the counter value exceeds this parameter value. If the counter value exceeds it, connectors logic sets the Account's administrative status to Scratch Card Recharge Suspended. The connector resets Bad Top-Up Attempt Counter after a successful Top-Up. This must be an unsigned integer value. Default value: 0.
Type

Using net_evt.fraudupd connector is not the only connector that an RTx can use when it implements its own definition of an admissible failure during a Top-Up attempt. Whatever the mechanism used to count the retries of a Top-Up, the result of the counting on the last Top-Up of an Account must be stored into the Accounts Bad Top-Up Attempt Counter. Thus, if LiteSCE is that mechanism, it has to observe this rule.
11 September 2009
Page 725 of 968
Table 226 - Account Profile - Charging Tab Parameter Max. Number of Failed Top-Up Attempts Description This parameter indicates the maximum number of failed Top-Up attempts an Account belonging to this Account Profile may have. Type Shared
A not binding example for a failed Top-Up request is when the maximum credit limit has been reached.
By default, the CRE does not the count the number of retries of a TopUp. And even if it were counting them, it would not compare the result of the counting against this parameter. As a result, if you only rely on the default behavior of the CRE, it does not make sense you enter any value in this parameter: It wont be used. But if you need the Top-Up retries to be counted and compared against this parameter value, you can do that by choosing and suitably configuring one of the mechanisms that the CRE offers for that. This must be an unsigned integer value. Default value: 0.

This flexibility enables a network operator to implement its own definition of a failed Top-Up attempt. This is why the CRE by default neither detects nor counts such failures.
For more on the mechanisms the CRE offers for monitoring this parameter value, in case you need that, see parameter Max. Failures per Top-Up Attempt (1/2), page 724. Whatever the way the retries of a Top-Up attempt are counted, the total number of failed Top-Up Attempts of an Account has to be stored into Bad Top-Up Attempt GL. Counter counter of the Account. When the RTx uses net_evt.fraudupd connector to monitor this parameter value, the connectors logic sets the concerned Accounts administrative status to Scratch Card Recharge Suspended as soon as it sees that Bad Top-Up Attempt GL. Counter of the Account is higher than this parameter value. The connector logic never resets this counter.
Page 726 of 968
11 September 2009
Table 226 - Account Profile - Charging Tab Parameter General Ledger Code for Discarded Bucket
rst_glc2
Description Reference to the General Ledger Code to be inserted in the EDR emitted by the CRE when the a Bucket is overridden by a Top-up operation. There are two cases in which the value contained by a Bucket is lost because of a top-up operation: 1. Single-Bucket Bundle, with Reset flag checked If the Reset Bucket value at Top-Up flag is check in the Bundle/ Counter Usage Label (see page 284), the each top-up performed on that Bundle resets the value of its unique Bucket before adding the value of the top-up. 2. Multi-Bucket Bundle, with a maximum number of Buckets If a Bundle already contains the Maximum Number of Buckets defined by the Bundle/Counter Usage Label (see page 282), then the top-up operation will reset one of the Buckets (for instance the oldest one) before adding the value of the top-up. When such a reset occurs, the General Ledger Code will be associated to the quantities removed from the Bucket. This ensures the consistency of the financial records.
Type
11 September 2009
Page 727 of 968
Table 226 - Account Profile - Charging Tab Parameter Max. Failed Password per Authentication Description This parameter indicates the maximum number of admissible failures an Account belonging to this Account Profile may have per Password Authentication attempt. Type Shared
A not binding example for a possible failure during a password authentication attempt is when a Customer has given a wrong password. He may then re-enter up to Max. Failed Password per Authentication times the password before the password authentication request is disconnected.
By default, the CRE does not count the number of retries done for a Password Authentication attempt. And even if it were counting them, it would not compare the result of the counting against this parameter. As a result, if you only rely on the default behavior of the CRE, it does not make sense you enter any value in this parameter: It wont be used. But if you need the failures of a Password Authentication attempt to be counted and compared against this parameter value, you have to choose and suitably configure one of the mechanisms that the CRE offers for that. This must be an unsigned integer value. Default value: 0.
This flexibility enables a network operator to implement its own definition of an admissible failure during a Password Authentication attempt. This is why the CRE by default neither detects nor counts such failures. For more on the mechanisms the CRE offers for monitoring this parameter value, in case you need that, see parameter Max. Failures per Top-Up Attempt (1/2), page 724. Whatever the mechanism used to count the retries that a password authentication attempt undergoes, that mechanism has to increment counter Bad Password Attempt Counter, of the concerned Account, every time a failure occurs during a password authentication attempt. Thus, if LiteSCE is that mechanism, it has to observe this rule. When the RTx uses net_evt.fraudupd connector to monitor this parameter value, the connectors logic sets the concerned Accounts administrative status to Password Blocked as soon as it sees that Bad Password Attempt Counter of the Account is higher than this parameter value. This counter is never reset. Using net_evt.fraudupd connector is not the only connector that an RTx can use when it implements its own definition of an admissible failure during a Password Authentication attempt.

Page 728 of 968
11 September 2009
Table 226 - Account Profile - Charging Tab Parameter Max. Failed Password Authentication
mxbadpwd
Description This parameter indicates the maximum number of failed password authentication attempts an Account belonging to this Account Profile may have. By default, the CRE does not the count number of password authentications that failed on an Account. And even if it were counting them, it would not compare the result of the counting against this parameter. As a result, if you only rely on the default behavior of the CRE, it does not make sense you enter any value in this parameter: It wont be used. But if you need the failed password authentication attempts to be counted and compared against this parameter value, you can do that by choosing and suitably configuring one of the mechanisms that the CRE offers for that. This must be an unsigned integer value. Default value: 0.
Type Shared

This flexibility enables a network operator to implement its own definition of a password authentication failure. This is why the CRE by default neither detects nor counts such failures. For more on the mechanisms the CRE offers for monitoring this parameter value, in case you need that, see parameter Max. Failures per Top-Up Attempt (1/2), page 724. Whatever the way the password authentications failures are counted, the total number of password authentication failures on an Account has to be stored into Bad Password Attempt Gl. Counter counter of the Account. When the RTx uses net_evt.fraudupd connector to monitor this parameter value, the connectors logic sets the concerned Accounts administrative status to Password Blocked as soon as it sees that Bad Password Attempt Gl. Counter of the Account is higher than this parameter value. The connector never resets this counter.
11 September 2009
Page 729 of 968
Table 226 - Account Profile - Charging Tab Parameter Max. Failures per PIN Attempt Description This parameter indicates the maximum number of admissible failures an Account belonging to this Account Profile may have per PIN authentication attempt. Type Shared
A not binding example for a possible failure during a PIN authentication attempt is when a Customer has given a wrong PIN. He may then re-enter up to Max. Failures per PIN Attempt times the PIN before the PIN authentication request is disconnected.
By default, the CRE does not count the number of retries done for a PIN Authentication attempt. And even if it were counting them, it would not compare the result of the counting against this parameter. As a result, if you only rely on the default behavior of the CRE, it does not make sense you enter any value in this parameter: It wont be used. But if you need the failures of a PIN authentication attempt to be counted and compared against this parameter value, you have to choose and suitably configure one of the mechanisms that the CRE offers for that. This must be an unsigned integer value. Default value: 0.
This flexibility enables a network operator to implement its own definition of an admissible failure during a PIN Authentication attempt. This is why the CRE by default neither detects nor counts such failures. For more on the mechanisms the CRE offers for monitoring this parameter value, in case you need that, see parameter Max. Failures per Top-Up Attempt (1/2), page 724. Whatever the mechanism used to count the retries that a PIN authentication attempt undergoes, that mechanism has to increment counter Bad PIN Attempt Counter, of the concerned Account, every time a failure occurs during a password authentication attempt. Thus, if LiteSCE is that mechanism, it has to observe this rule. When the RTx uses net_evt.fraudupd connector to monitor this parameter value, the connectors logic sets the concerned Accounts administrative status to PIN Blocked as soon as it sees that Bad PIN Attempt Counter of the Account is higher than this parameter value. This counter is never reset. Using net_evt.fraudupd connector is not the only connector that an RTx can use when it implements its own definition of an admissible failure during a PIN Authentication attempt.

Page 730 of 968
11 September 2009
Table 226 - Account Profile - Charging Tab Parameter Max. Number of Failed PIN Attempts Description This parameter indicates the maximum number of failed PIN authentication attempts an Account belonging to this Account Profile may have. By default, the CRE does not the count number of PIN authentications that failed on an Account. And even if it were counting them, it would not compare the result of the counting against this parameter. As a result, if you only rely on the default behavior of the CRE, it does not make sense you enter any value in this parameter: It wont be used. But if you need the failed PIN authentication attempts to be counted and compared against this parameter value, you can do that by choosing and suitably configuring one of the mechanisms that the CRE offers for that. This must be an unsigned integer value. Default value: 0. Type Shared

This flexibility enables a network operator to implement its own definition of a PIN authentication failure. This is why the CRE by default neither detects nor counts such failures. For more on the mechanisms the CRE offers for monitoring this parameter value, in case you need that, see parameter Max. Failures per Top-Up Attempt (1/2), page 724. Whatever the way the PIN authentications failures are counted, the total number of PIN authentication failures on an Account has to be stored into Bad PIN Attempt Gl. Counter counter of the Account. When the RTx uses net_evt.fraudupd connector to monitor this parameter value, the connectors logic sets the concerned Accounts administrative status to PIN Blocked as soon as it sees that Bad PIN Attempt Gl. Counter of the Account is higher than this parameter value. The connector never resets this counter.
Figure 326 - Account Profile GUI - Warning Tab
11 September 2009
Page 731 of 968
Table 227 - Account Profile - Warning Tab Parameter Days Before 1st Activity End Warning
activpwa
Description The CRE makes it possible to warn an Accounts owner that the end of the Accounts Activity period is going to be reached. Up to two such End of Active Period warnings can be issued to the Accounts owner. Its in the Account Profile of the Account that you indicate from which moment, of the Accounts Activity period, the first and the second warnings are to be issued. This parameter specifies the moment from which the first End of Active Period warning is to be issued. As this parameter belongs to the Account Profile, it equally applies to all the Accounts associated with the Account Profile. This parameter expresses a number of days before the end of the Accounts Activity period. It must thus have an unsigned integer value. As soon as the CRE sees that the number of days before the end of the Accounts Activity period gets lower than this parameter value, the CRE issues the first End of Active Period warning on the Account.
Type Shared
To have the CRE issuing such a warning notification on the Accounts associated with the Account Profile, you need to enable Warning notification type, of End of Active (Prepaid Only) notification feature, on the Account Profile.
Only) on an Account Profile, see Enabling a Given Notification Type on a Given Account, on page 176.
On how you enable Warning notification type, of End of Active (Prepaid
page 184.
Page 732 of 968
11 September 2009
Setting this parameter to zero means that the warning is to be issued from zero days before the end of the Accounts activity on.
Table 227 - Account Profile - Warning Tab Parameter Days Before 2nd Activity End Warning
actipwa2
Description
Type Shared
Please read also Days Before 1st Activity End Warning, on page 732.
This parameter specifies the moment from which the second End of Active Period warning is to be issued on an Account that is associated with the Account Profile. This parameter expresses a number of days before the end of the Accounts Activity period. It must thus have an unsigned integer value. You should enter here a value that is less than Days Before 1st Activity End Warning parameter value. As soon as the CRE sees that the number of days before the end of the Accounts Activity period gets lower than this parameter value, the CRE issues the second End of Active Period warning on the Account. This must be an unsigned integer value. Setting this parameter to zero means that the second warning is be issued from zero days before the end of the Accounts activity on.
To have the CRE issuing such a warning notification on the Accounts associated with the Account Profile, you need to enable Warning notification type, of End of Active (Prepaid Only) notification feature, on the Account Profile.
Only) on an Account Profile, see Enabling a Given Notification Type on a Given Account, on page 176.
On how you enable Warning notification type, of End of Active (Prepaid
page 184.
11 September 2009
Page 733 of 968
Table 227 - Account Profile - Warning Tab Parameter Days Before 1st Inactivity Warning
inactpwa
Description The CRE makes it possible to warn an Accounts owner that the end of the Accounts Inactivity period is going to be reached. Up to two such End of Inactivity Period warnings can be issued to the Accounts owner. Its in the Account Profile of the Account that you indicate from which moment, of the Accounts Inactivity period, the first and the second warnings are to be issued. This parameter specifies the moment from which the first End of Inactivity Period warning is to be issued. As this parameter belongs to the Account Profile, it equally applies to all the Accounts associated with the Account Profile. This parameter expresses a number of days before the end of the Accounts Inactivity period. It must thus have an unsigned integer value. As soon as the CRE sees that the number of days before the end of the Accounts Inactivity period gets lower than this parameter value, the CRE issues the first End of Inactivity Period warning on the Account. Setting this parameter to zero means that the warning is to be issued from zero days before the end of the Accounts Inactivity period on. To have the CRE issuing such a warning notification on the Accounts associated with the Account Profile, you need to enable Warning notification type, of End of Inactivity (Prepaid Only) notification feature, on the Account Profile.
Only) on an Account Profile, see 5.1.5.2, Enabling a Given Notification Type on a Given Account, on page 178.
Type Shared
On how you enable Warning notification type, of End of Inactive (Prepaid
page 184.
Page 734 of 968
11 September 2009
Table 227 - Account Profile - Warning Tab Parameter Days Before 2nd Inactivity Warning
inactpw2
Description
Type Shared
Please read also Days Before 1st Inactivity Warning, on page 734.
This parameter specifies the moment from which the second End of Inactivity Period warning is to be issued on an Account that is associated with the Account Profile. This parameter expresses a number of days before the end of the Accounts Inactivity period. It must thus have an unsigned integer value. You should enter here a value that is less than Days Before 1st Inactivity Warning parameter value. As soon as the CRE sees that the number of days before the end of the Accounts Inactivity period gets lower than this parameter value, the CRE issues the second End of Inactivity Period warning on the Account. This must be an unsigned integer value. Setting this parameter to zero means that the second warning is to be issued from zero days before the end of the Accounts Inactivity period on.

To have the CRE issuing such a warning notification on the Accounts associated with the Account Profile, you need to enable Warning notification type, of End of Inactivity (Prepaid Only) notification feature, on the Account Profile.
(Prepaid Only) on an Account Profile, see section 5.1.5.2, Enabling a Given Notification Type on a Given Account, on page 178.
On how you enable Warning notification type, of End of Inactivity
page 184.
Call Duration (in seconds)

calldurw
11 September 2009
Page 735 of 968
Table 227 - Account Profile - Warning Tab Parameter Notification Index ID*
index_id
Description You use this parameter to enable Top-Up completion warnings on each Account associated with the Account Profile. In other terms, you use this parameter to enable Reload on Main Account notification type, which belongs to Top Up notification feature, on each Account associated with this Account Profile. To enable Reload on Main Account notification type on each Account associated with the Account Profile, enter here the Index ID of Reload on Main Account notification type, which belongs to Top Up notification feature. That way, every time a Top-Up on an Account associated with the Account Profile completes, the CRE warns the customer owning the Account of that.
Type Shared
This must be the Index ID of Reload on Main Account notification type.
To disable Reload on Main Account notification type on each Account associated with the Account Profile, enter 0 here. That way, every time a Top-Up on an Account associated with the Account Profile completes, the CRE does not warn the customer owning the Account of that.
For details on enabling Reload on Main Account (i.e. Top-Up completion

warnings) notification type of Top Up notification feature, see 5.1.5.2, Enabling a Given Notification Type on a Given Account, on page 178.
On finding out the Index ID of a CRE notification type, see section 5.1.5,
Enabling a Given Notification Type on a Given Account, on page 176.
Page 736 of 968
11 September 2009
Table 227 - Account Profile - Warning Tab Parameter Activity Period Warning
actnotif
Description You use this parameter to enable End of Active Period warnings on each Account associated with this Account Profile. In other terms, you use this parameter to enable Warning notification type of End of Active Period (Prepaid Only) notification feature on these Accounts. To enable Warning notification type of End of Active Period (Prepaid Only) notification feature on each Account associated with this Account Profile, enter here the Index ID of Warning notification type of End of Active Period (Prepaid Only) notification feature.
Type Shared
This must be the Index ID of Warning notification type of End of Active (Prepaid Only) notification feature.
To disable End of Active Period notification type of End of Active Period (Prepaid Only) notification feature on each Account associated with this Account Profile, enter here 0.
For details on enabling Warning notification type of End of Active Period

(Prepaid Only), see 5.1.5.2, Enabling a Given Notification Type on a Given Account, on page 178.
Inactivity Period
inanotif
You use this parameter to enable End of Inactivity Period warnings on each Account associated with this Account Profile. In other terms, you use this parameter to enable Warning notification type of End of Inactivity Period (Prepaid Only) notification feature on these Accounts. To enable Warning notification type of End of Inactivity Period (Prepaid Only) notification feature on each Account associated with this Account Profile, enter here the Index ID of Warning notification type of End of Inactivity Period (Prepaid Only) notification feature.
Shared
This must be the Index ID of Warning notification type of End of Inactivity (Prepaid Only) notification feature.
To disable End of Inactivity Period notification type of End of Inactivity Period (Prepaid Only) notification feature on each Account associated with this Account Profile, enter here 0.
For details on enabling Warning notification type of End of Inactivity

Period (Prepaid Only), see 5.1.5.2, Enabling a Given Notification Type on a Given Account, on page 178.
11 September 2009
Page 737 of 968
Table 227 - Account Profile - Warning Tab Parameter Notify By*

notifk
Description Indicate here how the notifications, that are issued on any Account that is associated with the Account Profile, have to be sent. Choose one of the following values: SMS When this value is selected, any notification issued on an Account that is associated with the Account Profile will be sent by SMS. That notification will be sent to the MS-ISDN that is stored into Card Number* parameter of the Account. Email When this value is selected, any notification issued on an Account that is associated with the Account Profile will be sent by email. That notification will then be sent to the e-mail address that is stored into E-mail parameter of the Account. As it is mandatory to enter a value into this parameter, you will always have to enter a value here, even when no notification types are enabled on the Accounts of the Account Profile. Naturally, in this latter case, there is no need to specify any MS-ISDNs or any e-mail addresses for notification purposes.
Type Shared
Low Credit Warning

lcnotif
You use this parameter to indicate the Index ID that the CRE has to use whenever it issues Low Main Balance Level warnings on any Account associated with this Account Profile. When Low Credit warning Activation parameter of this Account Profile is set to Enable, make sure that this parameter contains the Index ID of Credit warning Threshold notification type of Credit Level on Main Balance notification feature.
Shared
This must be the Index ID of Warning notification type of Credit Level on Main Balance notification feature.
Otherwise, enter here 0.
For details on enabling Credit warning Threshold notification type of

Credit Level on Main Balance, see 5.1.5.2, Enabling a Given Notification Type on a Given Account, on page 178.
Page 738 of 968
11 September 2009
Table 227 - Account Profile - Warning Tab Parameter Welcome Announcemen t

wlcnotif
Description Index ID of the notification message to be sent for the Welcome Announcement. This is an SDP parameter. It is thus not used by the CRE. As a result, the value you enter here is determined by an OSP service (such as an RTx), thus other than the CRE, that uses this parameter value. Typically, that OSP service is an RTx. To know which value you need to enter here, please refer to that OSP services documentation.
Type Shared
Its the responsibility of the OSP service, other than the CRE, to detect that a Welcome Announcement notification is needed. Its also that OSP services responsibility to build up and issue the Welcome Announcement notification as necessary to the right recipient.
Figure 327 - Account Profile GUI - Flexibility Tab
Table 228 - Account Profile - Flexibility Tab Parameter At Each Originating Call Setup
cncsetup
Description This parameter is not used by the CRE.
Type Shared
At Each Originating Call End

snendcal
Shared
11 September 2009
Page 739 of 968
Table 228 - Account Profile - Flexibility Tab Parameter At Each Terminating Call End
cnendter
Description This parameter is not used by the CRE.
Type Shared
At Explicit Request
cninterr
LiteSCE Script Pool

lscepool
Reference to the LiteSCE Pool containing the scripts available to the Generic Connector, at Service Retailer level.
Own
To indicate that an Account Profile has no LiteSCE pool, leave this entry field empty. For Activity Period Warning
actimean
This is an SDP parameter.
For Credit Notification

credmean

For Inactivity Period Warning

inacmean
For Low Credit Warning

warnmean
Page 740 of 968
11 September 2009
Table 228 - Account Profile - Flexibility Tab Parameter Low Credit Warning Activation
lowcredn
Description You use this parameter to enable Low Main Balance warnings on each Account associated with this Account Profile. In other terms, you use this parameter to enable Credit Warning Threshold notification type of Credit Level on Main Balance notification feature on these Accounts. Choose one of the following: Enable The CRE will issue as necessary Low Main Balance warnings on the Accounts associated with this Account Profile. Disable The CRE is prevented to issue Low Main Balance warnings on the Accounts associated with this Account Profile. Default value: Disable
Type Shared
For details on enabling Credit warning Threshold notification

type of Credit Level on Main Balance, see 5.1.5.2, Enabling a Given Notification Type on a Given Account, on page 178.
During Originating Call Conversation

cwincall
During Originating Call Setup

cwcsetup
Out of Originating Call

cwoucall
Shared
11 September 2009
Page 741 of 968
Figure 328 - Account Profile GUI - Preferred Identifier Tab
Table 229 - Account Profile - Preferred Identifier Tab Parameter Number x

prefid00
Description Destination Identifier (of any type: phone call, e-mail address, URL,...) to which a preferential Tariff is applied for all the Accounts under the current Account Profile.
Type
Shared
See also section 12.3.20, Preferred Number Criterion, on page 452, which you use in a Usage Rating Rule for giving a preferential tariff that is based on a destination identifier.
Figure 329 - Account Profile GUI - ARENA Tab
Table 230 - Account Profile - ARENA Tab Parameter Logical Name Description Logical name of the ARENA attribute. This parameter is set in the ARENA object and is only available at display in the Account Profile GUI. Type Shared
Page 742 of 968
11 September 2009
Table 230 - Account Profile - ARENA Tab Parameter DB Name Description Database name of the ARENA attribute. This parameter is set in the ARENA object and is only available at display in the Account Profile GUI. Type Data Type of the ARENA attribute. This parameter is set in the ARENA object and is only available at display in the Account Profile GUI. Value Value of the ARENA attribute for the current Account Profile. This parameter receives a default value in the ARENA object. You can use this GUI (i.e., the Account Profile GUI) to give a new value to this parameter. Shared Shared Type Shared
Figure 330 - Account Profile GUI - Generic Counters Tab
Table 231 - Account Profile - Generic Counters Tab Parameter Usage Label
labelref
Description The Generic Counters tab lists all the Bundle/Counter Usage Labels of type Counter that are associated with the current Account Profile. This parameter value is thus a reference to one of these Bundle/ Counter Usage Labels: Its the name of the Bundle/Counter Usage Label. This is a read-only parameter.
Type Shared
You associate a Bundle/Counter Usage Label with an Account Profile by creating an instance of Account Profile and Usage Link that refers to both the Account Profile and the Bundle/ Counter Usage Label. To be able to create a counter (i.e., an instance of Counter object) for a given Account, the Bundle/Counter Usage Label of that counter must be listed in the Generic Counters tab of the Account Profile of that Account.
11 September 2009
Page 743 of 968
Table 231 - Account Profile - Generic Counters Tab Parameter RUM Description Currently not used. Reserved for future use. Type n.a.
Counter Type
Currently not used. Reserved for future use.
n.a.
Quantity / Money
Currently not used. Reserved for future use.
n.a.
19.2. Tips
19.2.1. About Minimum Credit Allowed and Maximum Credit Allowed
Before you start setting up Minimum Credit Allowed and Maximum Credit Allowed parameters of some Account Profile, be sure you are aware of the following: 1. 2. 3.
For any Account, the CRE constantly ensures that the Accounts balance remains between Minimum Credit Allowed and Maximum Credit Allowed. For a Postpaid Account, setting Minimum Credit Allowed to zero or setting it to no value means that the CRE will do no Minimum Credit Allowed check on the Postpaid Account. For any Account, Maximum Credit Allowed is only checked when a Top-Up is done on the Account.
Page 744 of 968
11 September 2009
19.2.2. Setting Up an Account Profile According to Its Accounts Type

It is the way you set up a number of Account Profile parameters that makes the Account Profiles Accounts behave as the Account Profiles Default Account Type* parameter setting announces. The goal of this section is to illustrate this, by drawing your attention to most of these parameters.
19.2.2.1. Summary Overview

Table 232 - Summary Overview of Account Profile Setup According to Its Accounts Type Parameter Default Account Type* Minimum Credit Allowed Maximum Credit Allowed Exhaustion Threshold
Pure Prepaid Account Prepaida >= 0 > Minimum Credit Allowed Disabled
Regular Prepaid Account Regular Prepaid <= 0 >0 Disabled

b
Pure Postpaid Account PostPaidc 0e 0 Disabled
Controlled Postpaid Account Controlled PostPaidd <=0 0 Disabledf or enabledg.
a. Indicating Regular Prepaid here would work too, but doing this will be misleading for the operators. b. Indicating Prepaid here would work too, but doing this will be misleading for the operators. c. Indicating Controlled PostPaid here would work too, but doing this will be misleading for the operators. d. Indicating PostPaid here would work too, but doing this will be misleading for the operators. e. Minimum Credit Allowed is thus infinite. f. Minimum Credit Allowed must then be <0. Otherwise, Accounts of the Account Profile will behave as Pure Prepaid Accounts. g. Exhaustion Threshold must be greater than Minimum Credit Allowed. This does not prevent Minimum Credit Allowed to be set to infinite (=0).
19.2.2.2. Detailed Overview

As Default Account Type*, on page 708, explains, you use Default Account Type* parameter to indicate whether the Accounts, of the Account Profile, will by default be either Prepaid or Postpaid ones. However, to make an Account Profiles Accounts behave either as a Pure Prepaid one, or as a Regular Prepaid one, or as a Pure Postpaid one, or a Controlled Postpaid one, you also need to suitably set up a number of other Account Profiles parameters. Its indeed the setup of these parameters that make the Account Profiles Accounts effectively behave as a Prepaid or a Postpaid one, and as Pure one or not.
11 September 2009
Page 745 of 968
The following table lists these parameters and indicates you how they should be initialized. Table 233 - Detailed Overview of Account Profile Setup According to Its Accounts Type Parameter Default Account Type* Credit Allocation at Account Creation Maximum Credit Allowed Enable Exhaustion Threshold Check Exhaustion Threshold Minimum Credit Allowed Maximum Credit Amount per Top-Up Activity Period Active Period Warning End of Inactivity Period Warning Low Credit Warning Pure Prepaid Account Prepaida 50e 60f Unchecked Value is irrelevant. 0i 60m A short period. Filled with the right Index ID. Filled with the right Index ID. Filled with the right Index ID. Regular Prepaid Account Regular Prepaid 50 60 Unchecked Value is irrelevant. -10j 70n A short period. Filled with the right Index ID. Filled with the right Index ID. Filled with the right Index ID.
b
Pure Postpaid Account PostPaidc 0 0 Unchecked Value is irrelevant. 0k 0o A very long period. 0q 0r 0s
Controlled Postpaid Account Controlled PostPaidd 0 0 Checkedg or Unchecked -100h -150l 0p A very long period. 0 0 0 or Filled with the right Index ID.
a. Indicating Regular Prepaid here would work too, but doing this will be misleading for the operators. b. Indicating Prepaid here would work too, but doing this will be misleading for the operators. c. Indicating Controlled PostPaid here would work too, but doing this will be misleading for the operators. d. Indicating PostPaid here would work too, but doing this will be misleading for the operators. e. Or any other amount. f. Any amount higher than Credit Allocation at Account Creation. g. Should be checked when Minimum Credit Allowed is set to 0. Otherwise, Account behaves as a PurePostpaid one. h. Below this amount, the main balance can only pay fees and Direct Chargings that require no credit check. i. Such an Account does not pay recurring fees. You do not trust it enough to allow its main balance to go below zero. j. A Regular Prepaid account is a Prepaid Account for which a recurring fee is set up in the CRE. Because of that you can afford its main balance to go below 0. k. Minimum Credit Allowed on the main balance is infinite. You could give it negative value, but this is not standard practice. l. Minimum Credit Allowed is below Exhaustion Threshold when this latter is enabled. m. Amount lower or equal to Maximum Credit Allowed. Must be > 0 since Prepaid Accounts are subject to regular Top-Ups. n. Amount lower or equal to Maximum Credit Allowed minus Minimum Credit Allowed. Must be > 0 too. o. As a standard, you never Top-Up a Postpaid Account. Nothing however prevents you to allow Top-Ups on a PostPaid Accounts. p. As a standard, you never Top-Up a PostPaid Account. Nothing however prevents you to allow Top-Ups on PostPaid Accounts, by giving a positive value to this parameter. q. End of Active Period Warnings make less sense for Postpaid Accounts, whether Pure or Controlled ones. r. End of Inactivity Period Warnings make less sense for Postpaid Accounts, whether Pure or Controlled ones.
Page 746 of 968
11 September 2009
Convergent Rating Engine 2.6.2 s. Low Credit Warnings make less sense for Pure Postpaid Accounts.
19.3. Account Object

19.3.1.1. Whats an Account?
In the CRE, the value repository is called an Account. As a result, whenever a charging occurs, it is always done on some Account. In that case, the value of the Account decreases. As another result, whenever a Top-Up occurs, it is always done on some Account. In that case, the value of the Account increases. An Account is made up of value sub-repositories, which are: One Balance, which is also sometimes called the Main Balance1. An Accounts Main Balance can be charged as well as Topped-Up. Zero or more Bundles, which the Accounts Bundle tab lists. Each bundle of an Account is also sometimes called a sub-balance2 of the Account.
As Accounts Main Balances, an Accounts Bundle can be charged as well as Topped-Up. An Account is also made up of: Zero or more Counters, which the Accounts Counter tab lists. Typically, Top-Ups only occur on Prepaid Accounts. However, in the CRE, nothing prevents you to allow Top-Ups on Postpaid Accounts.
19.3.1.2. Account with Customer vs. Account without Customer

With the CRE, associating one or more Accounts with one or more Customers, and vice-versa, is standard practice. Note: Except for the default Account of a Customer, you associate a Customer with an Account by setting up an instance of Customer Account object that refers to both the Account and the Customer. However, rating software prior to the CRE did not distinguish between customers and accounts and was thus merging the notion of customer and account into one single object. Because of that, the CRE still makes this behavior still available, by allowing you to create and use Accounts that are associated with no Customer at all. In that case, each such Account object also holds all the parameters of its associated Customer. To give an example: Whenever an Account is associated with no Customer, you need to give that Account a Commercial Offer. Otherwise, it wont be possible to use any Service through that Account.
1. The official name is balance. 2. The official name is bundle. Therefore, do not use sub-balance term.
11 September 2009
Page 747 of 968
Additionally, you will also enter the customer administrative information, such as last name, first name, and son on, at the level of the Account. Whenever an Account is associated with one or more Customers, you do not give a Commercial Offer to the Account: The Commercial Offer of the Accounts Customers will be used instead. Moreover, you will no longer store customer administrative information, such as last name, first name, and son on, into the Account. As that kind of information is customer specific, you will enter it at the level of each Customer that is associated with the Account. Note: To remember, a Commercial Offer is used to indicate which Services can be used. Note: Whenever the CRE is running in Gateway mode, Customers are ignored. That is, all Accounts are then considered as belonging to no Customer.
19.3.1.3. LC Charging Requests and LC Top-Up Request

The description of Life Cycle Status parameter of an Account uses the following terms: LC Charging request and LC Top-Up request. This section introduces these terms.
19.3.1.3.1.LC Charging Requests

Some kinds of charging requests bypass the life cycle of an Account (that is, these charging requests are never rejected in consequence of the Accounts Life Cycle Status having some particular value). The other kinds of charging requests do not bypass the Account life cycle. That is, these charging requests are accepted or rejected depending on the state the Account is in. These latter charging requests are called LC charging requests, where LC stands for Life Cycle. Here is the exhaustive list of these LC charging requests: Any RTx request made on oneshot connector Any RTx request made on fstreq connector Any fee charging request. Such a request is issued and triggered by the CRE in consequence of its non-usage Service Offers.
On Non-usage Service Offers, see section 7.3, Service Offer Definition object, on page 235.
19.3.1.3.2.LC Top-UP Requests.

Similarly, some kinds of Top-Up requests bypass the Accounts life cycle, while the other Top-Up kinds do not. These latter Top-Up requests are called LC Top-Up requests. Here is the exhaustive list of these LC Top-Up requests: Any RTx request made on credupdreq connector Any fee Top-Up request. Such a request is issued and triggered by the CRE in consequence of its Nonusage Service Offers.
Page 748 of 968
11 September 2009
Note: In case, the Accounts End Inactivity Date has expired and the Account is in Inactive state, if Topup is done, Accounts Life cycle State will change to Deactive state.
19.3.2. Main Parameters Description
Figure 331 - Account GUI
Table 234 - Account - ppm Parameter Service Retailer*

servret
Description Reference to the Service Retailer who is managing the current Account.
Account Profile*
servclas
Reference to the Account Profile to which the current Account belongs.
11 September 2009
Page 749 of 968
Table 234 - Account - ppm Parameter Commercial Offer

coffname
Description If the Account is associated with a Customer, specify no Commercial Offer here. Otherwise, you need to specify here a a reference to a Commercial Offer.
The CRE enforces this behavior.
Identifier (Login)
identify
Two Accounts cannot have the same Identifier (Login)* parameter value, even if they are not belonging to the same Service Retailer. In other terms, this parameter value must be unique across all the Accounts of all Service Retailers. This must be a string. It cannot be longer than 40 characters. If you enter no value here, the CRE will automatically generate one at time of Account creation. Thus, if you want to give a specific value to this parameter, you have to supply it before you request the CRE to create the Account (e.g., before either you click on Create button or you select Create in Account objects pull-down menu). Naturally, entering here a value that is already used by some other Account results in an error message from the CRE GUI. That is, the CRE ensures that this parameter value is unique across the Accounts, whatever their Service Retailer.
Although the CRE ensures of the uniqueness of this parameter across all the Accounts of all Service Retailers, the CRE does not ensure uniqueness of this parameters across all the Accounts and all the Customers of all Service retailers. Thus, the CRE will never prevent that a Customer and an Account use the same value for their Identifier (Login) parameter. Together with Service Retailer parameter, this parameter makes up the primary key of the Account. Because of that, the only way to change the Identifier (Login) parameter of an already created Account is to firstly delete the Account and secondly re-create it. This parameter value is, along with Card Number and MSID parameter, one of the values that an RTx request can use to address (i.e., in ppmvalue parameter of the RTx request) a CRE Account. This parameter is the sole way for an RTx to directly address an Account by means of a string.
Convergent Rating Engine 2.0 South API Specification, 3BL 45180 DAAA PBZZA, Edition 01 or Higher.

You will find more on RTx requests ppmvalue parameter in ALCATEL 8618
Page 750 of 968
11 September 2009
Table 234 - Account - ppm Parameter Card Number*

card_nbr
Description This parameter is typically used for storing a phone number (e.g., an MS-ISDN).
If the CRE is configured to issue notifications about this Account and these notifications have to be sent by SMS, you need to enter here the MS-ISDN to which these notifications will be sent.
This must be an integer value. It cannot be longer than 24 decimal digits. You must enter a value here. The Card Number value of a given Account must be unique across all the Accounts of the CRE, whatever the Service Retailer of these Accounts. The CRE enforces this behavior. Unlike Identifier (Login) parameter of the Account, which can no longer be changed once the Account has been created, the value of Card Number* parameter of the Account can be changed after an Account has been created.
Be very careful every time you want to change this parameter value. First of all, always first check whether this Account parameter is the one that the partition algorithm uses to select the partition that holds the Account. If that parameter is that one and the change would make the partition algorithm choose another partition for the Account, you will have to remove the Account and re-create it. On this, see also parameter Partition Attribute*, page 71.
Although the CRE ensures of the uniqueness of this parameter across all the Accounts of all Service Retailers, the CRE does not ensure uniqueness of this parameters across all the Accounts and all the Customers of all Service retailers. Thus, the CRE will never prevent that a Customer and an Account use the same value for their Card Number. This parameter value is, along with Identifier (Login) and MSID parameter, one of the values that an RTx request can use to address (i.e., in ppmvalue parameter of the RTx request) a CRE Account.
Account ID (force RI)

accounid
This is read only information. This shows the Row Id of the Account.
11 September 2009
Page 751 of 968
Table 234 - Account - ppm Parameter Forced SEP Group Description This parameter shows the SEP group that is associated with the Account. Additionally, if the CRE is set to use either the modulo Partition Algorithm or the external Routing Algorithm, you can modify this parameter. But when you do that, take care to specify a SEP group that is already associated to the partition to which the Account belongs. If the CRE is not set to use either the modulo Partition Algorithm or the external Routing Algorithm, you cannot change this parameter value.
The throughput that a SEP group can deliver is limited. When this limit is reached, you can use this parameter to relieve the SEP group of part of its work. For that, just assign to other SEP groups some of the Accounts that the SEP group is no longer able to promptly serve.
page 153.
On associating a SEP group to a partition, see 4.8, Partition Ranges Object, on See also Partition Algorithm*, on page 73, and Routing Algorithm*, on page 72.
Page 752 of 968
11 September 2009
Table 234 - Account - ppm Parameter Main Balance Description This is the amount of money that is available/due on/by the Account, not taking into account any money that would be available on the Bundles attached to the Account. This must be a decimal value.
See also Decimal Value, on page 36. See also Decimal Precision*, on page 145.
A positive main balance indicates an amount of money made available to the customer owning of the Account. Its a credit given to that customer. A negative main balance indicates an amount of money that is due by the customer owning the Account. Its a debt that is due by the owner of the Account.

Typically, the main balance of a Postpaid Account is null or negative and, initially, its main balance is set to 0. Typically too, the main balance of a Prepaid Account is positive and, initially, its main balance is set to a strictly positive value.
Entering Relative Values into the Main Balance

You can also enter relative values into this parameter. That is, you can add/ deduce some amount to/from the main balances current value without calculating yourself the resulting amount. For that, proceed as follows: 1. In some Account GUI window, display the data of the Account whose Main Balance has to be modified. Let us assume that Main Balance parameter of the Account is set to, and thus shows, 4.23. Clear Main Balance parameter so that it no longer shows any value. To add the amount (e.g., to add 12.345), type in + followed by the amount to add (e.g., type in +12.345). To subtract the amount (e.g., to subtract 12.345), type in the amount to subtract between parentheses (e.g., type in (12.345)). Click on MODIFY button, which appears to the top of the GUI window. This will make the CRE compute the new amount and save the resulting change into its database. Click on DISPLAY button to make the new amount appear in Main Balance parameter. You should now see the new amount in Main Balance parameter (i.e., if an addition had been done, you should now see 16.575. If a subtraction had been done, you should now see -8.115)
2. 3. 4. 5.
6. 7.
11 September 2009
Page 753 of 968
Table 234 - Account - ppm Parameter Credit Loss Due to Inactivity When: An Account gets Inactive and Reset Credit During Inactivity of the Account Profile of the Account is checked, the main balance of the Account is reset to zero. Moreover, doing a Top-Up on the Account also resets the Accounts main balance to zero prior to the Top-Up. This parameter indicates how much the Accounts main balance lost the last time it was reset to 0 in consequence of Reset Credit During Inactivity of the Account Profile of the Account being checked. If this parameter is set to zero, no money had been lost. This is a read-only parameter. Description
Prepaid Account*
prepaid OR uscredfl
When Prepaid Account* is checked, the Account behaves as a Prepaid one. When Prepaid Account* is unchecked, the Account behaves as a Postpaid one.
What If You Neither Checked Nor Unchecked the Check Box If, at time the CRE creates an Account, this check box is neither checked nor unchecked (i.e., the check box is still showing the question mark), the CRE gives to this parameter the value of Default account Type* parameter of the Account Profile of the Account. As soon as the Account has been created, modifying the value of Default account Type* parameter of the Account Profile has no effect on this parameter. Of course, you can modify this parameter setting at any time.
Page 754 of 968
11 September 2009
How the CRE understands Minimum Credit Allowed parameter of the Account Profile of an Account depends on whether the Account is Prepaid or Postpaid. For a Postpaid Account, setting Minimum Credit Allowed to zero means that the Account debt has no limit (i.e., cannot go below minus infinite. That is, there is no limit.). For a Prepaid Account, this means that the Accounts balance cannot go below 0.
Table 234 - Account - ppm Parameter MSID*

msid
Description One typical use of this parameter is to store an IMSI number. This must be an integer value. It cannot be longer than 24 decimal digits. You need to enter a value here. That is, if you do not enter a value here, the CRE wont generate one on your behalf. The MSID value of a given Account must be unique across all the Accounts of the CRE, whatever the Service Retailer of these Accounts. The CRE enforces this behavior. Unlike Identifier (Login) parameter of the Account, which can no longer be changed once the Account has been created, the value of MSID* parameter of the Account can be changed after an Account has been created.
Be very careful every time you want to change this parameter value. First of all, always first check whether this Account parameter is the one that the partition algorithm uses to select the partition that holds the Account. If that parameter is that one and the change would make the partition algorithm choose another partition for the Account, you will have to remove the Account and re-create it. On this, see also parameter Partition Attribute*, page 71.
Although the CRE ensures of the uniqueness of this parameter across all the Accounts of all Service Retailers, the CRE does not ensure uniqueness of this parameters across all the Accounts and all the Customers of all Service retailers. Thus, the CRE will never prevent that a Customer and an Account use the same value for their MSID. This parameter value is, along with Identifier (Login) and Card Number parameter, one of the values that an RTx request can use to address (i.e., in ppmvalue parameter of the RTx request) a CRE Account.
MSID Type*
msidtype
Choose one of the following values: MIN, if the MSID parameter contains a MIN number. IMSI, if the MSID parameter contains an IMSI number. External, otherwise.
11 September 2009
Page 755 of 968
Table 234 - Account - ppm Parameter No VAT

novat_f
Description Use this parameter to prohibit or allow VAT charging on the Accounts main balance. When this parameter is checked, the CRE charges no VAT on the Accounts main balance, even when the tariff used to charge the main balance specifies one. Otherwise, when the tariff used to charge the main balance specifies a VAT, that VAT is also charged on the main balance.

Operator Specific Account
oper_fl
This setting only applies to the main balance of the Account. In fact, the CRE never charges a VAT on the bundles of an Account.
Check this parameter if you want this Account to behave as a test account. Uncheck this parameter otherwise. Why Would You Want to Set Up a Test Account? The CRE allows you to make up versions of the instances of Product Catalog objects. Moreover, it allows you to create two categories of versioned instances: Test instances and Non-Test instances.
You will find yourself wanting to create a Test version of some object instance every time you need to verify the behavior of that instance before you put it into production. To prevent as much as possible mistakes when verifying the behavior of a Test version of some instance, the CRE obliges you to use a Test Account. That is, the CRE never uses Test instances whenever it processes an RTx request that is about an Account that is not a Test Account. Its only when an RTx request is run on a Test Account that the CRE attempts to use Test versions of objects instances in order to process the RTx request.
To take knowledge of which logic the CRE follows in order to choose the Test
versions it then uses, see chapter 11., "Versioning", on page 324.
You will most often use Test Accounts in conjunction with the Tariff Tester, in order to do simulations that you will use to test your product catalog.
On using test accounts to do simulations, see Key*, on page 207. See also chapter
Page 756 of 968
11 September 2009
19.3.3. General Tab Parameter Description
Figure 332 - Account GUI - General Tab

Table 235 - Account - General Tab Parameter Default Language

language
Description Language that is applied by default to the Account. This is an SDP parameter. Upon creation of an Account by the CRE, if the CRE sees that this parameter is empty, it copies Default Language parameter of the Account Profile, of the Account, into this parameter.
Last Name
mn30
Information that has the meaning of a last name. When the Account is not associated with any Customer, you typically indicate here the last name (i.e., the family name) of the customer (e.g., of a person) owning the Account. When the Account is associated with a Customer (i.e., with an instance of Customer object), it makes less sense that you enter a last name here, since this latter information is then normally stored into the associated Customer object instance and since an Account can be associated with several Customers. This is an SDP parameter.
11 September 2009
Page 757 of 968
Table 235 - Account - General Tab Parameter First Name

firstnam
Description Information that has the meaning of a first name. When the Account is not associated with any Customer, you typically indicate here the first name of the customer (e.g., of the person) owning the Account. When the Account is associated with a Customer (i.e., with an instance of Customer object), it makes less sense that you enter a first name here, since this latter information is then normally stored into the Customer object instance and since an Account can be associated with several Customers. This is an SDP parameter.
PIN Number
pin
PIN code of the Account. This is an SDP parameter. Information that has the meaning of a birthday date (e.g. of the birthday of the customer). When the Account is not associated with any Customer, you typically indicate here the birthday date of the customer owning the Account, if it is a person. When the Account is associated with a Customer (i.e., with an instance of Customer object), it makes less sense that you enter a birthday date here, since this latter date is already stored into the Customer object instance and since an Account can be associated with several Customers. This is an SDP parameter.
Birthday
birthday
Information
info1
Free text field, provided to store any kind of information. Note: This field is available at the SLEE level, in the SHMDB. It is present in context. So for instance, it can be used as input / output parameter in a LiteSCE script. Format: Character string (max length = 30)
Information
info2
Another free text field, provided to store any kind of information. Format: Character string (max length = 100) This is information that has the meaning of a login name. This is an SDP parameter. Format: Character string (max length = 16)
Login
login
E-mail
email
Information that has the meaning of an e-mail address (e.g., the e-mail address of the customer). If the Account is associated with a Customer (i.e., with an instance of Customer), it makes less sense that you enter an e-mail address here, since this latter information is already stored into the Customer object instance and since an Account can be associated with several Customers.
This is an SDP parameter except when some notifications are enabled on the Account and they have to be sent by e-mail. In this latter case, you need to enter here the e-mail address to which these notifications will be sent.
Page 758 of 968
11 September 2009
Table 235 - Account - General Tab Parameter Location

location
Description Information that has the meaning of a location. This is an SDP parameter.
Password
passwd
Information that has the meaning of a password. This is an SDP parameter. Reference to the LiteSCE Pool containing the scripts available to the Generic Connector, at Service Retailer level.
LiteSCE Script Pool

lscepool
To indicate that an Account has no LiteSCE pool, leave this entry field empty.
Account Creation Date

accreddt
Date at which the Account was created. This is a read-only parameter.
Comm. Off. Assignment Date

If the Account has a commercial offer, this parameter shows the date at which the current commercial offer of the Account was assigned to the Account. Else, this parameter shows no value. This is a read-only parameter.
coffdate
Begin Validity Date

validbeg
Date and time at which the Account got valid. The CRE automatically fills in this parameter at time the Account Life Cycle Status goes from Created to Valid state. That is, at time the Account gets valid. Unless some operator ever manually updated this parameter, this is really the date at which the Account became valid.
You will normally never want to enter a value in this parameter. However, as a minimum, do not enter a value into this parameter when it is empty. The CRE does not update a Begin Validity Date that is not empty, even at time the Account gets valid. An Account enters Valid state when an operator sets Life Cycle Status parameter of the Account to Valid. There is no other way for an Account to enter Valid state.
on page 793.
See also 19.3.14.1, About Begin/End Validity/Activity/Inactivity Dates,
11 September 2009
Page 759 of 968
Table 235 - Account - General Tab Parameter End Validity Date

validend
Description Date and time after which it will no longer be possible to activate the Account. The CRE automatically fills in this parameter at time the Account Life Cycle Status goes from Created to Valid state. That is, at time the Account gets valid.
You will normally never want to enter a value in this parameter. However, as a minimum, do not enter a value into this parameter when it is empty. The CRE does not update a End Validity Date that is not empty, even at time the Account gets valid.
on page 793.

The CRE computes End Validity Date by adding Validity Period* parameter value, of the Account Profile of the Account, to the Begin Validity Date of the Account. Of course, if the End Validity Date that the CRE computed does not suit you, you can always modify it afterwards. For example, in case you disagree with the Validity Period* in the Account Profile of the Account, you can extend or reduce it by modifying this parameter value accordingly.
Begin Activity Date

activbdt
Date and time at which the Account got activated. The CRE automatically fills in this parameter at time the Account Life Cycle Status goes from Valid to Active state. That is, at time the Account gets valid. Unless an operator ever manually updated this parameter, this is really the date at which the Account got activated.
You will normally never want to enter a value in this parameter. However, as a minimum, do not enter a value into this parameter when it is empty. The CRE does not update a Begin Activity Date that is not empty, even at time the Account gets activated. An Account gets activated whenever its Life Cycle Status parameter is set to Active for the first time. This happens either upon the first charging made on the Account (vie oneshot or fstreq connector) or upon triggering of getandcheckppm connector or upon update of Life Cycle Status by an operator.
on page 793.
Page 760 of 968
11 September 2009
Table 235 - Account - General Tab Parameter Begin Inactivity Date

activend
Description Date and time after which the Account will become Inactive. The CRE automatically fills in this parameter at time the Account Life Cycle Status goes from Valid to Active state. That is, at time the Account gets active.
You will normally never want to enter a value in this parameter. However, as a minimum, do not enter a value into this parameter when it is empty. The CRE does not update a Begin Inactivity Date that is not empty, even at time the Account gets valid.
on page 793.

The CRE computes Begin Inactivity Date by adding Activity Period* parameter value, of the Account Profile of the Account, to the Begin Activity Date of the Account. Of course, if the Begin Inactivity Date that the CRE computed does not suit you, you can always modify it afterwards. For example, in case you disagree with the Activity Period* in the Account Profile of the Account, you can extend or reduce it by modifying this parameter value accordingly.
11 September 2009
Page 761 of 968
Table 235 - Account - General Tab Parameter Life Cycle Status (1/2)
cyclstat
Description This parameter indicates in what phase of its life cycle the Account is. As a rule, the life cycle (i.e., the fact of going from one phase to the other) of an Account is automatically managed by the CRE. There is however an important exception to this rule: An account does not automatically enter Valid state. Typically, its an operator that makes an Account become Valid, by setting this parameter of the Account to Valid. Here below the values that this parameter can take. Created This is the life cycle phase that an Account enters as soon as it has been created. The Account is being prepared, it cannot be activated yet. Valid The Account can be activated. Typically, an Account that is Valid gets activated, and thus becomes Active, upon its first use by a user. Active The Account is activated and it can be used for making LC chargings.
If the Account has the Exhausted administrative status, its main balance can only pay LC chargings that are fees, but the Accounts bundles can still pay any kind of LC charging. If the Account has the No More Credit administrative status, its main balance is no longer allowed to pay LC chargings, including LC charging fees. But the Accounts bundles can still pay any kind of LC charging. Note that, if Do not set Account Inactive If Min. Credit Reached, of the Accounts Account Profile, is unchecked, the Account gets Inactive when it gets in No More Credit administrative status. Inactive The Account is activated but it can no longer be used for paying LC chargings. An LC Top-Up will make the Account become Active again. Deactivated The Account is no longer, and can no longer be, activated. It can no longer be used. It has reached the end of its life. The Numeric Value(The values stored for each state in the database) for the above mentioned states are as follows: Created: 0 Valid: 1 Active: 2 Inactive: 3 Deactivated: 4
Page 762 of 968
11 September 2009
Table 235 - Account - General Tab Parameter Life Cycle Status (1/2) Description
See also 19.3.13, About an Accounts Life Cycle, on page 791. On LC chargings and LC Top-Ups, see 19.3.1.3, LC Charging Requests and LC Top-Up
Request, on page 748.
See also 19.3.14.2, Making an Account Valid, on page 793. See also 19.3.14.3,
Activating an Account (i.e., Performing an Account Activation), on page 794.
End Inactivity Date

inactend
Date and time after which the Account will become Deactivated. The CRE automatically fills in this parameter at time the Account Life Cycle Status goes from Valid to Active state. That is, at time the Account gets active.
You will normally never want to enter a value in this parameter. However, as a minimum, do not enter a value into this parameter when it is empty. The CRE does not update a End Inactivity Date that is not empty, even at time the Account gets valid.
on page 793.

The CRE computes End Inactivity Date by adding Inactivity Period* parameter value, of the Account Profile of the Account, to the Begin Inactivity Date of the Account. Of course, if the End Inactivity Date that the CRE computed does not suit you, you can always modify it afterwards. For example, in case you disagree with the Inactivity Period* in the Account Profile of the Account, you can extend or reduce it by modifying this parameter value accordingly.
19.3.4. Loyalty Tab Parameter Description
Figure 333 - Account GUI - Loyalty Tab
11 September 2009
Page 763 of 968
Table 236 - Account - Loyalty Tab Parameter Last Credit Update Date
lstupcdt
Description This is the date and time at which the value of the main balance changed for the last time. The value of this parameter is automatically filled in by the CRE. This is the date and time at which a Scheduled Account Event was applied (charge or top-up) to the Account for the last time.
Last Fee Applic. Date

lstfeedt
Only Subscriptions linked to he current Account The Scheduled Events taken into account in this parameter are ONLY the ones that are generated by some Account Subscription(s) linked to the current Account. Indeed, the current Account might be charged or topped-up via scheduled events of some Customer, which would have a Customer Subscription generating a Scheduled Customer Event. Those events linked to the portfolio of some Customer, and not of the current Account, are not taken into account by this parameter.
The value of this parameter is automatically filled in by the CRE.

Note: As the fee end logic is shifted to ARES from Creactor, so now this field is no more updated. Last Top-Up Date
lstreldt
This is the date and time of the last Top-Up done on the Accounts main balance. The value of this parameter is automatically filled in by the CRE. This is the amount that the last Top-Up done on the Account put on the Accounts main balance. The value of this parameter is automatically filled in by the CRE. It is expressed in the same units as the Accounts main balance.
Last Topped Up Amount

lstrelva
Page 764 of 968
11 September 2009
Table 236 - Account - Loyalty Tab (continued) Parameter Bad Top-Up Attempt Gl. Counter
glbadrel
Description By default, the CRE does not maintain this counter. To have this counter updated as necessary by the CRE of your installation, you need to choose and suitably configure on your installation one of the mechanisms that the CRE offers for that.
The goal of these mechanisms is to enable network operators to implement their

own definition of a failed Top-Up attempt.
To learn more about these mechanisms, you need to read Max. Number of Failed
Top-Up Attempts, on page 726.
Whenever this Counter Is Maintained by the CRE. Whenever this counter is maintained by the CRE, the mechanism chosen to maintain this counter must increment this counter every time a Top-up attempt fails. By default, the chosen mechanism never resets this counter. Therefore, by default, this counter indicates the number of failed Top-Up attempts on the Account since the Account creation.
See also Max. Number of Failed Top-Up Attempts, on page 726. See also Scratch Card Recharge Suspended, on page 777
Bad Top-Up Attempt Counter

nbbadrel
By default, the CRE does not maintain this counter. To have this counter updated as necessary by the CRE of your installation, you need to choose and suitably configure on your installation one of the mechanisms that the CRE offers for that.

own definition of a failure during a Top-Up attempt.
To learn more about these mechanisms, you need to read Max. Failures per TopUp Attempt (1/2), on page 724.
Whenever this Counter Is Maintained by the CRE. Whenever this counter is maintained by the CRE, the mechanism chosen to maintain this counter must increment this counter every time a failure occurs during a Top-Up attempt. When the net_evt.fraudupd mechanism is used for managing this counter, this counter is reset to 0 upon a successful Top-Up attempt (i.e., when the last retry done by the Top-Up succeeds). As a result, when that mechanism is used, this counter indicates the number of times that failures occurred during the various Top-Up attempts made since the last successful Top-Up attempt.
See also Max. Failures per Top-Up Attempt (1/2), on page 724. See also Scratch Card Recharge Suspended, on page 777.
11 September 2009
Page 765 of 968
Table 236 - Account - Loyalty Tab (continued) Parameter Bad Password Attempt Gl. Counter
glbadpwd
Description By default, the CRE does not maintain this counter. To have this counter updated as necessary by the CRE of your installation, you need to choose and suitably configure on your installation one of the mechanisms that the CRE offers for that.

own definition of a password authentication failure.
To learn more about these mechanisms, you need to read Max. Failed Password
Authentication, on page 729.
Whenever this Counter Is Maintained by the CRE. Whenever this counter is maintained by the CRE, the mechanism chosen to maintain this counter must increment this counter every time a password authentication attempt failed on the Account. By default, the chosen mechanism never resets this counter. Therefore, by default, this counter indicates the number of times a password authentication attempt failed on the Account since the Account creation.
See also Max. Failed Password Authentication, on page 729. See also Password Blocked, on page 776.
Bad Password Attempt Counter By default, the CRE does not maintain this counter. To have this counter updated as necessary by the CRE of your installation, you need to choose and suitably configure on your installation one of the mechanisms that the CRE offers for that.

own definition of a password failure of a password authentication attempt.
Whenever this Counter Is Maintained by the CRE. Whenever this counter is maintained by the CRE, the mechanism chosen to maintain this counter must increment this counter every time a failure occurs during a password authentication attempt. By default, none of the mechanisms, that the CRE provides for managing this counter, reset this counter. Whenever this counter is never reset, which is what these mechanisms do by default, this counter simply counts the total number of password failures that all the password authentication attempts underwent since the time of the Account creation.
See also Max. Failed Password per Authentication, on page 728. See also Password Blocked, on page 776.
Page 766 of 968
11 September 2009
Table 236 - Account - Loyalty Tab (continued) Parameter Bad PIN Attempt Gl. Counter Description By default, the CRE does not maintain this counter. To have this counter updated as necessary by the CRE of your installation, you need to choose and suitably configure on your installation one of the mechanisms that the CRE offers for that.

own definition of a PIN authentication attempt failure.
Whenever this Counter Is Maintained by the CRE. Whenever this counter is maintained by the CRE, the mechanism chosen to maintain this counter must increment this counter every time a PIN authentication attempt fails. By default, the chosen mechanism never resets this counter. Therefore, by default, this counter indicates the number of times a PIN authentication attempt failed on the Account since the Account creation.
See also Max. Failed Password Authentication, on page 729. See also Password Blocked, on page 776.
Bad PIN Attempt Counter
By default, the CRE does not maintain this counter. To have this counter updated as necessary by the CRE of your installation, you need to choose and suitably configure on your installation one of the mechanisms that the CRE offers for that.

own definition of a PIN failure of a PIN authentication attempt.
Whenever this Counter Is Maintained by the CRE. Whenever this counter is maintained by the CRE, the mechanism chosen to maintain this counter must increment this counter every time a failure occurs during a PIN authentication attempt. By default, none of the mechanisms, that the CRE provides for managing this counter, resets this counter. Whenever this counter is never reset, which is what these mechanisms do by default, this counter simply counts the total number of PIN failures that all the PIN authentication attempts underwent since the time of the Account creation.
See also Max. Failures per PIN Attempt, on page 730. See also Pin Blocked, on page 778.
11 September 2009
Page 767 of 968
Table 236 - Account - Loyalty Tab (continued) Parameter Next Discount DT Description This is the next date and time at which the CRE will compute the (one or more) discount(s) that the (one or more) instance(s) of Discount object, that are associated with the Account, grant to the Account.
As you can see, that date and time applies to all the Discount object instances associated with the Account.
The first time you associate a Discount object instance with an Account, you can: Either enter a date and time into this parameter of the Account. You will do that if you want to indicate to the CRE the first date and time at which it has to compute the discount that the Discount object instance specifies. Be sure you enter a date in the future. Or leave this parameter empty. You will leave this parameter empty if you want to let the CRE decide of the first date and time at which it will compute the discount that the Discount object instance specifies. You are however recommended not to leave this parameter empty and to thus give it the date and time at which you want the discounts to be computed for the first time. Every time it computes the (one or more) discount(s) from the (one or more) instance(s) of Discount object that are associated with the Account, the CRE re-computes the value of Next Discount DT parameter of the Account. The CRE does that computation as follows: New value of Next Discount DT = current value of Next Discount DT + N times the value of Billing Date Period parameter (a number of months) of the Account Profile of the Account. N is the number of loops we have to do until "Next Discount DT" is greater than call date. If the current value of Next Discount DT is null, then 01/ 01/1970 is taken as the current Next Discount DT. Example: Billing Date Period = 5 (months) Start Date is 28.06.2006, so 1.06.2006 is taken. The call is made on 04/07/2007. It means that we should take Next Discount Date after 04/07/2007, but according to the computation algorithm: 01/06/2006 + 5 months = 01/11/2006 < calldate (04/07/2007) 01/11/2006 + 5 months = 01/04/2007 < calldate (04/07/2007) 01/04/2007 + 5 months = 01/09/2007 > calldate (04/07/2007) Next Discount Date will be 01/09/2007. You can change this parameter value at any time. Doing that will schedule the next discounts computation at the new date and time that the parameter received. This value must have the format of a Date and Time.
Page 768 of 968
11 September 2009
Table 236 - Account - Loyalty Tab (continued) Parameter Description
See Date and Time, on page 36.
See also section 17.3, Discount Object, on page 616. See also Billing Date Period, on page 722.
19.3.5. Charging Tab Parameter Description
Figure 334 - Account GUI - Charging Tab
Table 237 - Account - Charging Tab

Parameter Friends and Family List

fflist
Description Reference to the Friends and Family List that is attached to the Account.
Note that you can also attach a Friends and Family List to a Customer. Therefore, if the Account is associated with one or more Customers, you might prefer to attach a Friends and Family List to Customers that are associated with the Account. In that case, you might want to leave this parameter empty. By using the Friends Family criterion in a Usage Rating Rule, you can give a preferential tariff to the members of an Accounts Friends and Family List.
See also section 12.3.13, Friends and Family Criterion, on page 426.
11 September 2009
Page 769 of 968
19.3.6. ARENA Tab Parameter Description
Figure 335 - Account GUI - ARENA Tab
Table 238 - Account - ARENA Tab Parameter Logical Name Description Logical name of the ARENA attribute.
This parameter is set in the ARENA object and is only available at display in the Account GUI. DB Name Database name of the ARENA attribute. This parameter is set in the ARENA object and is only available at display in the Account GUI. Type Data Type of the ARENA attribute. This parameter is set in the ARENA object and is only available at display in the Account GUI. Value Value of the ARENA attribute. This parameter receives a default value in the ARENA object.
Page 770 of 968
11 September 2009
19.3.7. Status Tab Parameter Description
Figure 336 - Account GUI - Status Tab
Table 239 - Account - Status Tab Parameter

Description Whenever this flag is checked, the Account is blocked. Else, the Account is not blocked. Who Updates this Flag? Blocking an Account is typically an operators decision. For example, an operator will want to check the Blocked flag of an Account if/ she suspects that an Account is involved in a fraud. The CRE never sets this flag. What Happens When an Account Is Blocked? Whenever an Account is blocked, no user is authorized to use the Account via RTx requests. As a result, a blocked Account can neither be charged nor topped-up through RTx requests.
Blocked
admblk
11 September 2009
Page 771 of 968
Table 239 - Account - Status Tab Parameter Exhausted

admexh
Description Whenever detection of main balance exhaustion is enabled for the Account, this flag indicates whether the main balance is exhausted or not: The CRE checks this flag when the main balance of the Account gets exhausted. That is, when the value of the Accounts main balance gets below Exhaustion Threshold parameter of the Account Profile of the Account. The CRE unchecks this flag when the main balance of the Account gets no longer exhausted. That is, when the value of the Accounts main balance gets above Exhaustion Threshold parameter of the Account Profile of the Account. Whenever detection of main balance exhaustion is not enabled for the Account, this flag has no meaningful value, whether this flag appears checked or not.
On enabling/disabling detection of an Accounts main balance exhaustion, see Enable

Exhaustion Threshold Check, on page 713.
Who Updates this Flag? As explained above, the CRE automatically updates this flag, since main balance exhaustion detection is performed by the CRE.
Although nothing prevents an operator to update this flag, an operator should not do that, since the value shown might then be misleading. Of course, the CRE never uses this parameter to know whether Accounts main balance is exhausted or not, since this flag indicates an administrative status that the CRE computes. What Happens Whenever an Account Is Exhausted? Whenever an Account has the Exhausted administrative status and detection of main balance exhaustion is enabled on the Account, the Accounts main balance can no longer be charged, except for: Fees; Direct Chargings that require no credit check (they correspond to Direct Debit RTx requests whose dirdebit parameter is set to 2). That makes sense, since the credit check is then, by definition, to be bypassed. Being below this parameter value does not necessarily means that an usage RTx request, other than Direct Debit without credit check, no longer can be paid. Indeed, if bundles are associated with the Account, the CRE will attempt to use these bundles to pay such an usage RTx request. Of course, if the CRE cant make the bundles pay, it is then not possible for the Account to pay for such an usage RTx request.
See also Exhaustion Threshold (1/2), on page 714.
Page 772 of 968
11 September 2009
Table 239 - Account - Status Tab Parameter Initial Selection Done

admisl
Description This is an SDP parameter. As a result, this parameter is neither used nor managed by the CRE. If an OSP service (such as an RTx), thus other than the CRE, manages this parameter, it must handle this parameter such that: Whenever this flag is checked, the users selection of the language is already performed. Otherwise, the users selection of the language is not performed yet, whether the OSP service offers this feature or not.
The CRE does not implement users selection of the language. It simply presents the value of this parameter.
Of course, an operator can always either check or uncheck this parameter. The operator should however do that with caution, since the value displayed by this parameter could then be misleading.
11 September 2009
Page 773 of 968
Table 239 - Account - Status Tab Parameter No More Credit (1/2)

admnmcr
Description Whenever this parameter is checked, no more credit is available on the main balance of the Account. In other terms, this means that the value of the Accounts main balance is below Minimum Credit Allowed parameter, which is a parameter of the Account Profile of the Account. Whenever this parameter is checked, the main balance of the Account still has credit available.
Typically, only a Prepaid Account will receive that administrative status, since you will normally never want to impose a minimum value on the main balance of a Postpaid Account.
See also Minimum Credit Allowed, on page 715.

Who Updates this Flag? Its the CRE that updates this flag, since it is the CRE that performs the No More Credit detection on the main balance. Although nothing prevents an operator to update this flag, an operator must not do that. This could be misleading. What Happens Whenever an Account Is in No More Credit?
Whenever a main balance has no more credit, it can no longer be used for making payments. Contrast this administrative status with Exhausted. Exhausted still allows charging fees on the main balance, but No More Credit does not allow that.
However, like Exhausted, this administrative status, still allows Direct Chargings that require no credit check (they correspond to Direct Debit RTx requests whose dirdebit parameter is set to 2). The exception makes sense, since the credit check is then, by definition, bypassed.
What If the Account Does Not Then Become Inactive? If, in the Account Profile of the Account that is in No More Credit, parameter Do Not Set Account Inactive If Min. Credit Reached flag was checked at time the Account came into No more Credit, Life Cycle Status parameter of the Account does not change of value. This means that no other payment restrictions apply to the Account. As a result, it is then still possible to make payments using the bundles of the Account, since the Accounts Life Cycle Status is not set to Inactive.
Page 774 of 968
11 September 2009
Table 239 - Account - Status Tab Parameter No More Credit (2/2) Description What if the Account Then Becomes Inactive? On the other hand, if Do Not Set Account Inactive If Min. Credit Reached flag was checked when the Account came into No More Credit, the Account becomes Inactive (i.e., its Life Cycle Status parameter is set to Inactive). As a result, it is now the Account, and not only the main balance, that no longer can be used for making payments. Thus, even the bundles of the Account no longer can be used to pay.
Note however that, still here, Direct Chargings that require no credit check are allowed.
11 September 2009
Page 775 of 968
Table 239 - Account - Status Tab Parameter Password Blocked

admpblk
Description By default, this Parameter Is Not Used by the CRE. To have this administrative status updated as necessary by the CRE of your installation, you need to choose and suitably configure on your installation one of the mechanisms that the CRE offers for that.
The goal of these mechanisms is to enable network operators to implement their own
definition of password authentication failure.
Who Updates this Flag? Whatever the mechanism you choose for handling this administrative status, you need to make sure that this mechanism: Checks this parameter when Bad Password Attempt Counter of the Account becomes higher than Max. Failed Password per Authentication parameter value (this parameter is from the Account Profile of the Account), and Checks this parameter when Bad Password Attempt Gl. Counter of the Account becomes higher than Max. Failed Password Authentication parameter value (this parameter is from the Account Profile of the Account), and Never unchecks this parameter. From the CRE point of view, this parameter can only be unchecked by an operator. Naturally, nothing prevents you to write LiteSCE scripts that uncheck it. Of course, an operator can always either check or uncheck this parameter. However, as always, this is something he/she should do with caution, in order to make sure that the displayed information is not misleading. What Happens Whenever an Account Is Password Blocked? As, by default, the CRE does not use this parameter, it implements no logic that depends on any value this parameter takes. Thus, by default, even when an Account is in Password Blocked state (for example, because the operator checked this flag), the CRE puts no restriction on its use. If you want such a logic in the CRE of your installation (for example, if you want to put restrictions on the use of an Account that is Password Blocked), you need to implement that logic yourself. You can choose to do that through the use of one or more LiteSCE criteria that some of your rules, implemented as decision trees, would use. You can also choose to do that by setting up the necessary LiteSCE scripts. Periodic Fee
admpfee
Page 776 of 968
11 September 2009
Table 239 - Account - Status Tab Parameter Scratch Card Recharge Suspended
admscrs
Description By default, this Parameter Is Not Used by the CRE. To have this administrative status updated as necessary by the CRE of your installation, you need to choose and suitably configure on your installation one of the mechanisms that the CRE offers for that.
definition of an admissible failure during a Top-Up attempt as well as their own definition of a failed Top-Up attempt.
To learn more about these mechanisms, see Max. Failures per Top-Up Attempt (1/2),
on page 724, and Max. Number of Failed Top-Up Attempts, on page 726.
Who Updates this Flag? Whatever the mechanism you choose for handling this administrative status, you need to configure that mechanism such that: It checks this parameter when Bad Top-Up Attempt Counter of the Account becomes higher than Max. Failures per Top-Up Attempt parameter value (this parameter is from the Account Profile of the Account), and such that: It checks this parameter when Bad Top-Up Attempt Gl. Counter of the Account becomes higher than Max. Number of Failed Top-Up Attempts parameter value (this parameter is from the Account Profile of the Account), and such that: It never unchecks this parameter. From the CRE point of view, this parameter can only be unchecked by an operator. Naturally, nothing prevents you to write LiteSCE scripts that uncheck it. Of course, an operator can always either check or uncheck this parameter. However, as always, this is something he/she should do with caution, in order to make sure that the displayed information is not misleading. What Happens Whenever an Account Is Scratch Card Recharge Suspended? As, by default, the CRE does not use this parameter, it implements no logic that depends on any value this parameter takes. Thus, by default, even when an Account is in Scratch Card Recharge Suspended state (for example, because the operator checked this flag), the CRE puts no restriction on its use. If you want such a logic in the CRE of your installation (for example, if you want to put restrictions on the use of an Account that is Scratch Card Recharge Suspended), you need to implement that logic yourself. You can choose to do that through the use of one or more LiteSCE criteria that some of your rules, implemented as decision trees, would use. You can also choose to do that by setting up the necessary LiteSCE scripts.
11 September 2009
Page 777 of 968
Table 239 - Account - Status Tab Parameter Pin Blocked Description By default, this Parameter Is Not Used by the CRE. To have this administrative status updated as necessary by the CRE of your installation, you need to choose and suitably configure on your installation one of the mechanisms that the CRE offers for that.
definition of PIN authentication failure.
Who Updates this Flag? Whatever the mechanism you choose for handling this administrative status, you need to make sure that this mechanism: Checks this parameter when Bad PIN Attempt Counter of the Account becomes higher than Max. Failures per PIN Attempt parameter value (this parameter is from the Account Profile of the Account), and Checks this parameter when Bad PIN Attempt Gl. Counter of the Account becomes higher than Max. Number of Failed PIN Attempts parameter value (this parameter is from the Account Profile of the Account), and Never unchecks this parameter. From the CRE point of view, this parameter can only be unchecked by an operator. Naturally, nothing prevents you to write LiteSCE scripts that uncheck it. Of course, an operator can always either check or uncheck this parameter. However, as always, this is something he/she should do with caution. What Happens Whenever an Account Is PIN Blocked? As, by default, the CRE does not use this parameter, it implements no logic that depends on any value this parameter takes. Thus, by default, even when an Account is in PIN Blocked state (for example, because the operator checked this flag), the CRE puts no restriction on its use. If you want such a logic in the CRE of your installation (for example, if you want to put restrictions on the use of an Account that is PIN Blocked), you need to implement that logic yourself. You can choose to do that through the use of one or more LiteSCE criteria that some of your rules, implemented as decision trees, would use. You can also choose to do that by setting up the necessary LiteSCE scripts.
Page 778 of 968
11 September 2009
Table 239 - Account - Status Tab Parameter First Event Done

firstcal
Description The aim of this flag is to indicate whether the Account was activated via an RTx request or not.
Keep in mind that activating an Account consists in making its Life Cycle Status go from Valid to Active.
Activation), on page 794.
See also section 19.3.14.3, Activating an Account (i.e., Performing an Account

Whenever this flag is checked, activation of the Account was performed and the activation is due to some RTx request. Otherwise: Either the Account is not activated yet, Or the activation of the Account was performed but is not due to some RTx request (e.g. an operator simply updated the Accounts Life Cycle Status parameter from Valid to Active). This flag is updated by the CRE at time it performs the Account activation in consequence of an RTx request (i.e., in consequence either of the first charging on the Account or of an RTx request that triggers the getandcheckppm connector).
Although nothing prevents an operator to update this flag, an operator must not do that. It could indeed be misleading that an operator updates this flag. For example, once the CRE has checked this flag, the CRE will never check it again even if the operator decided to uncheck it.
NEIF (HLR Barring)

tcblock
For future use. Default value: Unchecked.
11 September 2009
Page 779 of 968
Table 239 - Account - Status Tab Parameter 1st Low Credit Warning Done
lcwdone
Description The CRE sets this parameter every time it issues a first Credit Warning Threshold notification on the Account. That way, it indicates that it issued a first Credit Warning Threshold notification on the Account. The CRE can also reset (i.e., uncheck) this parameter. For example, it unchecks it upon a Top-Up. An operator too can check/uncheck this parameter. Checking this parameter simply prevents the issuing of a first Credit Warning Threshold notification on the Account, even when the conditions for issuing the notification are met. Indeed, when the CRE sees that the conditions for issuing a first Credit Warning Threshold notification on the Account are met, but this Accounts parameter is checked at the moment it sees that, the CRE does not issue the first Credit Warning Threshold notification. On the other hand, unchecking this parameter again allows the issuing of a first Credit Warning Threshold notification on the Account.
For details on this type of notification, see also , Credit Level on Main Balance, on page 168.
Default value: Unchecked.
2nd Low Credit Warning Done

lcwdone2
The CRE sets this parameter every time it issues a second Credit Warning Threshold notification on the Account. That way, it indicates to the operator that it issued a second Credit Warning Threshold notification on the Account. The CRE can also reset (i.e., uncheck) this parameter. For example, it unchecks it upon a Top-Up. An operator too can check/uncheck this parameter. Checking this parameter simply prevents the issuing of a second Credit Warning Threshold notification on the Account, even when the conditions for issuing the notification are met. Indeed, when the CRE sees that the conditions for issuing a second Credit Warning Threshold notification on the Account are met, but this Accounts parameter is checked at the moment it sees that, the CRE does not issue the second Credit Warning Threshold notification. On the other hand, unchecking this parameter again allows the issuing of a second Credit Warning Threshold notification on the Account.
For details on this type of notification, see also , Credit Level on Main Balance, on page 168.
Page 780 of 968
11 September 2009
Table 239 - Account - Status Tab Parameter 1st Active Period Warning Done
lactdone
Description The CRE sets this parameter every time it issues a first End of Active Period Warning notification on the Account. That way, it indicates to the operator that it issued a first End of Active Period Warning notification on the Account. The CRE can also reset (i.e., uncheck) this parameter. For example, it unchecks it upon a Top-Up. An operator too can check/uncheck this parameter. Checking this parameter simply prevents the issuing of a first End of Active Period Warning notification on the Account, even when the conditions for issuing the notification are met. Indeed, when the CRE sees that the conditions for issuing a first End of Active Period Warning notification on the Account are met, but this Accounts parameter is checked at the moment it sees that, the CRE does not issue the first End of Active Period Warning notification. On the other hand, unchecking this parameter again allows the issuing of a first End of Active Period Warning notification on the Account.
For details on this type of notification, see also , End of Active Period (Prepaid Only), on page 172.

2nd Active Period Warning Done

lactdon2
The CRE sets this parameter every time it issues a second End of Active Period Warning notification on the Account. That way, it indicates to the operator that it issued a second End of Active Period Warning notification on the Account. The CRE can also reset (i.e., uncheck) this parameter. For example, it unchecks it upon a Top-Up. An operator too can check/uncheck this parameter. Checking this parameter simply prevents the issuing of a second End of Active Period Warning notification on the Account, even when the conditions for issuing the notification are met. Indeed, when the CRE sees that the conditions for issuing a second End of Active Period Warning notification on the Account are met, but this Accounts parameter is checked at the moment it sees that, the CRE does not issue the second End of Active Period Warning notification. On the other hand, unchecking this parameter again allows the issuing of a second End of Active Period Warning notification on the Account.
For details on this type of notification, see also , End of Active Period (Prepaid Only), on page 172.
11 September 2009
Page 781 of 968
Table 239 - Account - Status Tab Parameter 1st Inactive Period Warning Done
linactdon
Description The CRE sets this parameter every time it issues a first End of Inactivity Period Warning notification on the Account. That way, it indicates to the operator that it issued a first End of Inactivity Period Warning notification on the Account. The CRE can also reset (i.e., uncheck) this parameter. For example, it unchecks it upon a Top-Up. An operator too can check/uncheck this parameter. Checking this parameter simply prevents the issuing of a first End of Inactivity Period Warning notification on the Account, even when the conditions for issuing the notification are met. Indeed, when the CRE sees that the conditions for issuing a first End of Inactivity Period Warning notification on the Account are met, but this Accounts parameter is checked at the moment it sees that, the CRE does not issue the first End of Inactivity Period Warning notification. On the other hand, unchecking this parameter again allows the issuing of a first End of Inactivity Period Warning notification on the Account.
For details on this type of notification, see also , End of Inactivity Period Warning (Prepaid Only), on page 173.
2nd Inactive Period Warning Done

linactdo2
The CRE sets this parameter every time it issues a second End of Inactivity Period Warning notification on the Account. That way, it indicates to the operator that it issued a second End of Inactivity Period Warning notification on the Account. The CRE can also reset (i.e., uncheck) this parameter. For example, it unchecks it upon a Top-Up. An operator too can check/uncheck this parameter. Checking this parameter simply prevents the issuing of a second End of Inactivity Period Warning notification on the Account, even when the conditions for issuing the notification are met. Indeed, when the CRE sees that the conditions for issuing a second End of Inactivity Period Warning notification on the Account are met, but this Accounts parameter is checked at the moment it sees that, the CRE does not issue the second End of Inactivity Period Warning notification. On the other hand, unchecking this parameter again allows the issuing of a second End of Inactivity Period Warning notification on the Account. For details on this type of notification, see also , End of Inactivity Period Warning (Prepaid Only), on page 173. Default value: Unchecked.
Page 782 of 968
11 September 2009
Table 239 - Account - Status Tab Parameter Welcome Announcement Done

wlcdone
Description This is an SDP parameter. As a result, this parameter is neither used nor managed by the CRE. If an OSP service (such as an RTx), thus other than the CRE, manages this parameter, it must handle this parameter such that: Whenever this parameter is checked, the Welcome Announcement notification has already been issued for the Account. Otherwise, no Welcome Announcement notification was issued for the Account, whether the OSP service, other than the CRE, supports Welcome Announcement notification or not.
The CRE does not implement the issuing of the Welcome Announcement notification.
11 September 2009
Page 783 of 968
19.3.8. Bundle Tab Parameter Description

An Accounts Bundle tab gives you the list of all the buckets of all the bundles of the Account, one line of information per bucket. As a Bundle can have one or more buckets, you may see several lines of information in the tab for the same bundle, one line of information per bucket belonging to the bundle.
Figure 337 - Account GUI - Bundle Tab The table here below describes the parameters that a given line of information, that the Bundle tab displays, shows. Table 240 - Account - Bundle Tab Parameter Bundle Name Description Name of the bundle to which the bucket belongs. This refers thus to a Bundle/Counter Usage Label that is of type Bundle.
That is, this parameter must hold the value of Name* parameter of one instance of Bundle/Counter Usage Label object that has its Type* parameter is set to Bundle.
Bundle Type This is the value of Type* parameter of the bundle to which the bucket belongs.
Bucket ID This is the value of the buckets Bucket ID parameter.
See also parameter Bucket ID, page 801.

RUM Used This is the value of Ratable Unit Metric* parameter of the bucket's bundle.
See also parameter Ratable Unit Metric*, page 281.

Valid From This is the value of Valid from parameter of the bucket.
See also parameter Valid from, page 802.

Valid Until This is value of To parameter of the bucket.
See also parameter To, page 802.

Units This is the value of Remaining Units parameter of the bucket.
See also parameter Remaining Units, page 803.
Page 784 of 968
11 September 2009
19.3.9. Counter Tab Parameter Description

An Accounts Counter tab gives you the list of all Counters of the Account, one line of information per Counter.
Figure 338 - Account GUI - Counter Tab The table here below describes the parameters that a given line of information, that the Counter tab displays, shows. Table 241 - Account - Counter Tab Parameter Usage
countcol.usg_ri
Description This is the name of the Counter the line of information is about. This refers thus to a Bundle/Counter Usage Label that is of type counter. That is, this parameter must hold the value of Name* parameter of one instance of Bundle/Counter Usage Label object that has its Type* parameter is set to Bundle.
Date
countcol.datper
This is the value of Date parameter of the Counter.
See also Date, on page 854.

This is the value of Previous Counter Value parameter of the Counter.
Counter Value 1
countcol.val
See also Previous Counter Value, on page 854.

This is the value of Current Counter Value parameter of the Counter.
Counter Value 2
countcol.valper
See also Current Counter Value, on page 854.
19.3.10. Subscriptions Tab Parameter Description

The Accounts Subscriptions tab is a read-only interface giving you the list of all the Account Subscriptions (i.e., instances of ACCOUNT SUBSCRIPTION objects) of the Account, one line of information per Subscription Double-clicking on one of the shown lines of information displays the GUI of the ACCOUNT SUBSCRIPTION object, filled in with the data of the Account Subscription that the double-clicked line is about.
Figure 339 - Account GUI - Subscription Tab
11 September 2009
Page 785 of 968
The table here below describes the parameters that a given line of information, that the Subscriptions tab displays, shows. Table 242 - Account - Subscriptions Tab Parameter S.O. Group Description This is the value of Service Offer Group* parameter of the Account Subscription that the line of information is about. This is the value of State parameter of the Account Subscription that the line of information is about. Indicates whether the payment of fees upon activation or cancellation of the Account Subscription (that the line of information is about) is allowed or not. This parameter is either set to Enabled or to Disabled. Disabled Payment of fees upon activation or cancellation of the Account Subscription is disabled. Enabled Payment of fees upon activation or cancellation of the Account Subscription is enabled.
Status
Act/Can Fees
As a result, upon activation or cancellation of the Account Subscription, a fee is normally applied. Where Is this Parameter Value From? This parameter value depends on the value of Disable Activation and/ or Deactivation Fee(s) parameter of the Account Subscription: This parameter is set to Disabled when Disable Activation and/ or Deactivation Fee(s) is checked. Else, this parameter is set to Enabled. Creation DT This is the value of Creation DT parameter of the Account Subscription that the line of information is about. This is the value of Activation DT parameter of the Account Subscription that the line of information is about. This is the value of Suspension DT parameter of the Account Subscription that the line of information is about. This is the value of Reactivation DT parameter of the Account Subscription that the line of information is about. This is the value of Cancellation DT parameter of the Account Subscription that the current line of information is about.
Activation DT
Suspension DT
Reactivation DT
Cancellation DT
Page 786 of 968
11 September 2009
19.3.11. Fees Tab Parameter Description

The Accounts Fees tab is a read-only interface giving you the list of all the Fees (i.e., instances of SCHEDULED ACCOUNT EVENT object) existing for all the Subscriptions of the current Account, one line of information per Fee. Double-clicking on one of the shown lines of information displays the GUI of the SCHEDULED ACCOUNT EVENT object, filled in with the data of the Fee that the double-clicked line is about.
Figure 340 - Account GUI - Subscription Tab The table here below describes the parameters that a given line of information, that the Fees tab displays, shows. Table 243 - Account - Fees Tab Parameter S.O. Group
Description This is the value of Account Subscription parameter of the Fee (i.e., the instance of SCHEDULED ACCOUNT EVENT object) that the line of information is about. This is the value of Service Name* parameter of the Fee (i.e., the instance of SCHEDULED ACCOUNT EVENT object) that the line of information is about. This is the value of Status parameter of the Fee (i.e., the instance of SCHEDULED ACCOUNT EVENT object) that the line of information is about.
Service
Status
11 September 2009
Page 787 of 968
Table 243 - Account - Fees Tab Parameter Error Description Indicates whether the Fee (that the line of information is about) is in Error Mode or not. This parameter is either set to OK or to Error. OK The Fee is not in error mode. Error The Fee is in error mode. As long as a Fee is in error mode, the CRE ignores it.
To know more about the error mode, see 13.6.3.1, The Error Mode, on page 495 as well as parameter Error on Fee, page 311.
Where Is this Parameter Value From? This parameter value depends on the value of Error on fee parameter of the Fee (i.e., instance of SCHEDULED ACCOUNT EVENT) that the line of information is about: This parameter is set to Error when Error on fee is checked. Else, this parameter is set to OK.

#Executions
See also parameter Error on Fee, page 311.
This is the value of #Execution parameter of the Fee (i.e., the instance of SCHEDULED ACCOUNT EVENT object) that the line of information is about. This is the value of Last Cost parameter of the Fee (i.e., the instance of SCHEDULED ACCOUNT EVENT object) that the line of information is about. This is the value of First Fee Date parameter of the Fee (i.e., the instance of SCHEDULED ACCOUNT EVENT object) that the line of information is about. This is the value of Last Fee Date parameter of the Fee (i.e., the instance of SCHEDULED ACCOUNT EVENT object) that the line of information is about. This is the value of Next Fee Date parameter of the Fee (i.e., the instance of SCHEDULED ACCOUNT EVENT object) that the line of information is about. This is the value of Synchronization Date parameter of the Fee (i.e., the instance of SCHEDULED ACCOUNT EVENT object) that the line of information is about.
Last Cost
First Occ DT
Last Occ DT
Next Occ DT
Synchro DT
Page 788 of 968
11 September 2009
19.3.12. Last 10 Events Tab Parameter Description

The Last 10 Events tab provides information about the last 10 transactions performed on the Account, whatever the triggering Customer (owner of the Account, or Customer for which the Account agrees to be charged). There is one line of information per event. The list includes all transactions performed on the Account. Free call information is also taken into consideration. The impact on the credit can be of two sorts (debit or credit), and due to any triggering event (call, data session, top-up, recurring fee, operator deposit, direct debit,...). The Adjustment operations are not reported among the last 10 events, because they are pure management operations. The Account credit can be impacted on the main balance and/or on one or more Bundle(s). However, the interface doesnt display the costs charged on Bundles. So a call charged on Bundle only will be listed, but the cost displayed will be zero, since theres no impact on the main balance. The Last 10 Events information is typically dedicated to the Customer Care operators, in order to allow them to check in real time the last 10 events made on a specific Account. The feature is limited to what is displayed in the GUI. However, the Convergent Rating Engine is equipped with a full statistics framework, allowing to fine-tune the level of detail of the event data records (EDRs) produced by the CRE; filter the EDRs according to their contents; store and index the EDRs by user; query the EDRs database; generate statistics reports. For more information, see your Storage Engine documentation.
Figure 341 - Account GUI - Last 10 Events tab
11 September 2009
Page 789 of 968
Table 244 - Account - Last 10 Events tab Parameter Service Offer Description Name of the Service Offer that provided the rating of the event. It can be a Service Offer of any type: Usage, Top-up or Non-usage. If its a Top-up Service Offer, this field displays the name of the Top-up Profile that was used. Reminder - How does a Service Offer determine the events rating? If Service Offer of type Usage: A Usage Rating Rule provides a Tariff. If Service Offer of type Non-usage: In mode Charge: A Service Offer Definition provides either a fixed amount or a Usage Rating Rule giving a Tariff. In mode Top-up: A Service Offer Definition provides either a fixed amount or a Top-up Profile. If Service Offer of type Top-up: A Top-up Profile defines the amount(s) and their distribution.
Event Destination
For a Usage event: destination or called party of the event. For a Top-Up event: this field displays the Top-Up Rule. For a Fee event, i.e. a scheduled event: this field is empty (the destination is the Account itself).
Event Type Event Date
There are three possible types of events: Usage, Top-up or Fee, in compliance with the type of the Service Offer mentioned above. Date of the event. Corresponds to the parameter net_evt.calldate of the RTx request. Format: DD/MM/YYYY.
Event Time
Time of the event. Corresponds to the parameter net_evt.calltime of the RTx request. Format: HH:MM:SS.
Event Cost
Cost of the event or amount topped-up. The amount specified here only concerns the main balance of the Account. If the event impacts only Bundle(s) and not the main balance, the Call Cost displayed will be 0 (zero). The quantities removed from or added to Bundles are not shown in this interface. This field displays absolute values; there is no indication of the +/- operation performed on the Account. It is implied by the Event Type information.
Page 790 of 968
11 September 2009
Table 244 - Account - Last 10 Events tab (continued) Parameter Event Duration Description Duration of the event, whether the used quantities have been charged or not. So for a typical voice call, this field displays the real call duration, only if at least one of the RUM used for charging is of type TIME. For a non-usage event, like the charge of a recurring fee, this field will display 00:00:00. Format: HH:MM:SS.
19.3.13. About an Accounts Life Cycle

19.3.13.1.What Makes an Accounts Life Cycle Status Change of Value
Here is how the CRE manages the life cycle of an Account. Table 245 - What Makes an Accounts Change of Life Cycle Status LCS (Life cycle Status) Value
What Makes the Accounts LCS Change to that LCS Value An Accounts Life Cycle Status (LCS) is automatically set to Created upon creation of the Account. An Accounts Life Cycle Status (LCS) is never automatically set to Valid by the CRE. Typically, setting an Accounts Life Cycle Status (LCS) to Valid is an action that is performed by an operator.
Created Valid
Active
An Accounts Life Cycle Status (LCS) is automatically set to Active if, and only if, the CRE sees that the following condition is true at time it processes a oneshot, fstreq or getandcheckppm RTx request on the Account:
(LCS is Valid and Main Balance > Min Credit Allowed and Now < End Activity Date)
Thus, it is no longer possible to make an Accounts Life Cycle Status (LCS) become Active once its End Activity Date has been reached. Inactive An Accounts Life Cycle Status (LCS) is automatically set to Inactive as soon as the CRE sees that the following condition is true on the Account:
(LCS is Active and Main Balance <= Min Credit allowed and Do Not Set Account Inactive If Min. Credit reacheda is unchecked) OR (LCS is Active and Now > Begin Inactivity Date)
11 September 2009
Page 791 of 968
Table 245 - What Makes an Accounts Change of Life Cycle Status LCS (Life cycle Status) Value Deactivated What Makes the Accounts LCS Change to that LCS Value An Accounts Life Cycle Status (LCS) is automatically set to Deactivated as soon as the CRE sees that the following condition is true on the Account:
(LCS is Valid and Now > End Validity Date) OR (LCS is Inactive and Now > End Inactivity date)
a. Do Not Set Account Inactive If Min. Credit reached parameter belongs to the Account Profile that is associated with the Account.
19.3.13.2.When Does the CRE Update an Accounts Life Cycle Status?

For efficiency reasons, except for Out of Call processings, the CRE re-computes, and thus updates, an Accounts Life Cycle Status only when it needs to use it. As a result, the CRE updates an Accounts Life Cycle status at specific points in time.

On Out Of Call processings, see also OOC, on page 25, as well as Out Of Call, on page 32. This is the reason why expressions such as ... as soon as the CRE sees... are found in the text of Table 245, What Makes an Accounts Change of Life Cycle Status, on page 791. The expression refers to these specific points in time at which the CRE checks an Accounts Life Cycle Status.
This explains why, for example, an Accounts Life Cycle Status might appear Active at level of the Accounts GUI although the Account is past its Begin Inactivity Date. Naturally, as the CRE always re-computes an Accounts Life Cycle Status at time it uses it, what the CRE does with an Account is always consistent with the real Life Cycle Status of that Account. Here below you will find at which specific points in time the CRE re-computes an Accounts Life Cycle Status. Table 246 - When Does the CRE Update an Accounts Life Cycle Status? Upon... Triggering of one of ( getAndCheckPPM, oneshot, fstreq, recurring fee of type Charge or of type ChargeTopUp) The CRE Updates LCS (Life Cycle Status) of the Concerned Account as Follows:
If (LCS is Valid) and (Now < End Validity Date) Then LCS is set to Active Else LCS is set to Deactivated If (LCS is Active) and (Now > End Activity Date) Then LCS is set to Inactive If (LCS is Inactive) and (Now > End Inactivity Date) Then LCS is set to Deactivated If (LCS is Active) and (Now > End Activity Date) Then LCS is set to Inactive If (LCS is Inactive) and (Now > End Inactivity Date) Then LCS is set to Deactivated
Execution of Out Of Call
Page 792 of 968
11 September 2009
Table 246 - When Does the CRE Update an Accounts Life Cycle Status? Upon... Triggering of one of ( credupdreq, recurring fee of type TopUp) The CRE Updates LCS (Life Cycle Status) of the Concerned Account as Follows:
If (LCS is Active) and (Balance < Min Credit Allowed) and (Do Not Set Account Inactive If Min. Credit reacheda is unchecked) Then LCS is set to Inactive If (LCS is Inactive) and (Now < End Inactivity Date) Then LCS is set to Active
a. Do Not Set Account Inactive If Min. Credit reached parameter belongs to the Account Profile that is associated with the Account.
19.3.14. Tips
19.3.14.1.About Begin/End Validity/Activity/Inactivity Dates
Whenever the CRE makes an Accounts Life Cycle Status change of value, the CRE automatically fills in any Begin/End date parameter that the change affects, provided that the Begin/End date parameter is not yet filled in.
Whenever the CRE makes an Accounts Life Cycle Status change of value, the CRE does not fill in any Begin/End date parameter that the change affects and that is already filled in. The CRE ensures that the Begin/End Validity/Activity/Inactivity dates it computes are in valid time sequence. For that reason, it is safer that the operator never updates these Account parameters. Of course, the operator can always change an Accounts Begin/End Validity/Activity/Inactivity dates. But he/she needs to do that with caution. Moreover, the operator must never update any of these parameters that is empty, since this would prevent the CRE to compute and update itself, and as necessary, the parameter. Of course, the CRE can update some of an Accounts Begin/End Validity/Activity/Inactivity dates in consequence of a Top-Up made on the Account. The CRE then does that in line with the Top-Up profile used to perform the Top-Up. Apart from an operator, only a Top-Up will modify some already filled in Accounts BeginActivity and EndInactivity dates. The operator can change Begin/End Validity/Activity/Inactivity dates.
19.3.14.2.Making an Account Valid

To make an Account enter Valid state: Just set Life Cycle Status parameter of the Account to Valid. Note: This is the only way to make an Account become Valid. Whenever Life Cycle Status parameter of the Account is set to Valid: If the Accounts Begin Validity Date parameter is empty at that moment, the CRE sets it to the current date and time. Else, Accounts Begin Validity Date parameter value is unchanged.
11 September 2009
Page 793 of 968
If the Accounts End Validity Date parameter is empty at that moment, the CRE computes the end validity date and fills End Validity Date parameter in with the computed end validity date. Else, End Validity Date parameter value is unchanged.
19.3.14.3.Activating an Account (i.e., Performing an Account Activation)

Activating an Account consists in making the Account go from the Valid state (this corresponds to Life Cycle Status parameter of the Account being set to Valid) to Active state (this corresponds to Life Cycle Status parameter of the Account being set to Active). As a result, its only possible to perform an activation of an Account when it is in Valid state. An activation of an Account is performed when that Account is in Valid state and when one of the following happens: The Account gets charged either via oneshot or fstreq connector. The RTx triggering the getandcheckppm connector on the Account An operator sets Life Cycle Status parameter of the Account to Active.
19.3.15. How to Cleanly Remove an Account: the Purge Account Command

Removing an Account from the CRE database is a complex operation. Indeed, some other objects of the CRE database have a dependence relationship with the Account. For instance, a Counter always belongs to an Account. A Counter linked to no Account doesnt make sense and will never be used by the CRE logic. When you remove an Account from your CRE database, you typically want to avoid junk data to remain in the database. Cleanly removing an Account implies that all the items belonging to that Account are also removed at the same time. Any number of instances of the following objects can be linked to a particular Account instance: Main Balance (credit) Last Ten Events (tencalls) Bucket (bundlcol) Scheduled Account Events (accfee) Counter (countcol) Account Subscription (contrasr) Account Discount (accdisc) Customer Account (clientacc) Most of these object dependencies are visible in the CRE Account GUI, as shown in the diagram 342 below. An Account may also be referenced by a Customer, as default Account.
Page 794 of 968
11 September 2009
Customer Account referencing the Account
Discount referencing the Account Main Balance of the Account
Buckets referencing the Account
Counters referencing the Account
Subscriptions referencing the Account
Scheduled Events referencing the Account
Last Ten Events of the Account
Figure 342 - Objects referencing the Account
11 September 2009
Page 795 of 968
19.3.15.1.Removing an Account via the CRE GUI

You can remove an Account via the CRE GUI. Clicking on Account text in the menu bar (this implies that the Accounts management window is currently selected) displays a drop-down menu that offers a REMOVE command, which you can use to remove the Account.
If you attempt to remove an Account that is still referenced by another object instance, then the operation will be denied and you will receive an error message like this:
For a typical Account with for instance 3 Counters, 10 Buckets, 4 Subscriptions, 4 planned Scheduled Events, and belonging to one Customer, 24 object instances have to be individually removed from the database before the removal of the Account itself is possible.
19.3.15.2.Removing an Account via the Purge Account Command

As opposed to the fastidious Account removal procedure via the CRE GUI, the PURGE ACCOUNT command allows performing the clean removal of the Account at once. The Purge Account command is only accessible via the TOC (Text Oriented Client) interface. The Purge Account command automatically removes all the instances of the objects that have a reference to the Account to be removed, except the Customer. So the objects concerned are: Main Balance (credit) Last Ten Calls (tencalls) Bucket (bundlcol) Customer Account (clientacc) Scheduled Account Events (accfee) Account Discount (accdisc) Counter (countcol) Account Subscription (contrasr)
How to launch the Purge Account command?
Page 796 of 968
11 September 2009
Step 1: open the command line interface of the station where the CRE is installed. Step 2: Type toc <login> <password> <network host>. When you are logged in, the prompt TOC> is displayed. Step 3: Type the following command
<service>.ppm.purge,[ACCOUNID=<account_ID>],IDENTIFY= <identity>,SERVRET=<service retailer>;

where [] represents an optional parameter. The syntax is similar to the syntax of the REMOVE TOC command. Table 247 - Purge Account Command Parameters Parameter ACCOUNID IDENTIFY SERVRET Corresponding Element Account Row ID Account Identifier (Login) Service Retailer More details See page 751. See page 750. See page 749.
Error Cases
If the Account is referenced by a Customer (as Default Account), then the removal operation is rejected.
When an error occurs upon object deletion, the operation continues but reports the error at the end, in the ad hoc EDR (see below).
Event Data Record of a Purge Account operation

When a Purge Account is performed by the CRE, a statistical ticket containing the credit (Main balance) and Bundle value loss is sent. By tracking all values coming in and out of the system, the CRE ensures the financial records consistency. Dedicated statistical events are generated by the CRE, numbered 117.14.1.1 to 117.14.1.6 (for more details, see you Convergent Rating Engine 2.4 Event Data Record Description). So the Event Data Record is structured according to the following syntax: <start purge account> <gl_code> <main balance> <start purged bundle> <bundle name> <bundle type> <start purged bucket> <bucket to date> <bucket from date> <bucket init value> <bucket init units> <bucket remaining units> <bucket validity>
11 September 2009
Page 797 of 968
<end purged bucket> [] <end purged bundle> [] <end purge account> Note: The gl_code here is the Account Profiles General Ledger Code for Discarding Operations (see page 721).
Page 798 of 968
11 September 2009
20. Bundles
20.1. Bucket Object
Note: In what follows, bundles Bundle/Counter Usage Label is short for instance of Bundle/Counter Usage Label object that is of type Bundle and whose Name* parameter is the name of the bundle. The Bucket object is used: Either to create an Accounts bundle. An Accounts bundle gets created the first time a bucket (i.e., an instance of Bucket object), that refers to both the Account and the bundles Bundle/Counter Usage Label, gets created. Or to update a given Accounts bundle. For example, a new bucket is added to an Accounts bundle every time an instance of Bucket object, that refers to both the Account and to the bundles Bundle/Counter Usage Label, gets created. Note: An Accounts bundle cannot work properly if its Bundle/Counter Usage Label is not associated with the Account Profile of the Account.
Therefore, prior to an Accounts bundle gets created, you need to make sure that the bundles Bundle/Counter Usage Label is associated with the Account Profile of the Account. A Bundle/Counter Usage Label is associated with an Account Profile if, and only if, there exists an instance of Account Profile and Usage Link object that refers to both the Account Profile and the bundles Bundle/Counter Usage Label. As an operator, you can always create an Accounts bundle, and thus an Accounts bucket. Moreover, whenever an Accounts bundle can be topped up, you can easily avoid creating yourself the buckets of the Accounts bundle. For that, suitably set up an instance of Top-Up Profile object. You will learn more about this latter issue by having a look at next section.

See also section 20.2, Account Profile and Usage Link object, on page 804. See also section 12.3.3.6, Criterion Parameter Description for Advance Bundle Criteria, on page 391. See also section 20.3, Top-Up Profile Object, on page 808.
11 September 2009
Page 799 of 968
Bundles
20.1.2. Setting Up an Accounts Bundle

To set up an Accounts bundle, proceed as follows: 1. 2. If it does not exist yet, create an instance of Bundle/Counter Usage Label object that is of type Bundle and whose Name* parameter is the name of the bundle. Associate that instance of Bundle/Counter Usage Label object with the Account Profile of the Account. For that, make sure that there exists an instance of Account Profile and Usage Link object that refers to both the Account Profile and the instance of Bundle/Counter Usage Label object. As soon as you have done that, each Account associated with the Account Profile can receive a bundle that has the name of the instance of Bundle/Counter Usage Label object. 3. Do now one of the following: If you want the Accounts bundle to be created and updated upon Top-Up, make one Bundle(s) parameter, of Bundles tab of a Top-Up Profile that refers to the Account Profile, refer to the instance of Bundle/Counter Usage Label object. As soon as that has been done, any Top-Up done by means of the Top-Up Profile, on any Account associated with the Account Profile, will automatically create and update as necessary the Accounts bundle, and will thus create and update the necessary buckets of the Accounts bundle. Else, create the necessary Bucket instances for the Account.
See also 20.3, Top-Up Profile Object, on page 808.
Figure 343 - Bucket GUI
Page 800 of 968
11 September 2009
Table 248 - Bucket - bundlcol Parameter Service Retailer*

aservret
Description Reference to the Service Retailer of the Account to which the current bucket belongs. Reference to the Account owning the bundle to which the current bucket belongs. The exact parameter referenced is ppm.identify. Getting the List of an Accounts Buckets To get a list of the Buckets of a particular Account, have a look to Bundle tab of the Account GUI (see Figure 337, Account GUI - Bundle Tab, on page 784).
Account Identifier*
ppm_ri
Bucket ID
Read-only parameter. This is the Row Id of the bucket in the Oracle database.
Usage*
usg_ri
This is the name of the bundle to which the bucket belongs. This is in fact the value of Name* parameter of a Bundle/Counter Usage Label that is of type Bundle. All the Buckets of a Bundle of course have to refer to the same Bundle/Counter Usage Label.
Creation Date
createdt
Read-only parameter. Creation date of the current bucket. If the bucket was created by an operator via the Bucket GUI, this is the date and time at which the operator created the bucket. If the bucket was created in consequence of a Top-Up RTx request, this is the date and time at which the Top-Up created the bucket.

Validity
validity
The Creation Date can be different from the Valid From date.
Duration of the current buckets validity period (in days). This parameter has to receive a value if, only if, it is wanted that the validity period of the bucket starts with the first RTx request that gets paid by the bucket. When this parameter has a value, Valid From and To parameters must have no value. On the other hand, when this parameter has no value, Valid From and To parameters have to have a value.
When a bucket creation is governed by a Top-Up Profile whose Expiration Type (page 813) is different than Fixed Extension, the Validity of the Bucket is not specified as a number of days. Read more in 20.3.5, Setting the Expiry of Buckets, on page 818.
11 September 2009
Page 801 of 968
Bundles
Table 248 - Bucket - bundlcol Parameter Valid from

startdt
Description Start date of the current buckets validity period. This parameter has to have a value if, and only if, Validity parameter has no value. Typically, this parameter receives a value when the validity period of the bucket has to start at a fixed date.
When a bucket creation is governed by a Top-Up profile whose Activate the Bucket(s) parameter is set to At Creation, this parameter is set to the date and time at which the bucket is created.
To
limitdat
End date of the current Bundle Buckets validity period. This parameter has to have a value if, and only if, Validity parameter has no value. Typically, this parameter receives a value when the validity period of the bucket has to start at a fixed date.
Initial Units
When an operator creates a bucket via the Bucket GUI, he/she can fill in this parameter. If he/she leaves this parameter empty, this parameter will, upon creation of the bucket, be automatically filled in with the value present in Remaining Units (which is mandatory). When a bucket is created in consequence of a Top-Up RTx request, this parameters value is taken either from the Top-Up profile that the RTx request specifies or from bld_xml string in the RTx request. In case the value is taken from the Top-Up profile, this parameter is set to the value of Initial Unit(s) parameter that is specified for the buckets bundle in the Top-Up profile. The Initial Units parameter is used to store the initial units in the bucket when it was first created. Typically, this value is the same as Remaining Units when a bucket is first created. When an RTx request occurs that uses the bucket, the Remaining Units will decrease while Initial Units will not change of value. This value, together with Initial Nominal Value, enables an operator to know, even if the bucket has been used by RTx requests, the original cost per unit. It is not internally used within the CRE and only to be passed on to an external system via the CRE EDR that mentions the value of this parameter and of Initial Nominal Value parameter.
Page 802 of 968
11 September 2009
When a bucket creation is governed by a Top-Up profile whose Activate the Bucket(s) parameter is set to At Creation, this parameter is set to the date and time at which the bucket is created plus the Activity Period that the Top-Up profile specifies for the buckets bundle.
Table 248 - Bucket - bundlcol Parameter Initial Nominal Value Description When an operator creates a bucket via the Bucket GUI, he/she can fill in a value for this parameter. Otherwise, this parameter will be set to its default value, which is 0. When a bucket is created in consequence of a Top-Up RTx request, this parameters value is taken either from the Top-Up profile that the RTx request specifies or from bld_xml string in the RTx request. In case the value is taken from the Top-Up profile, this parameter is set to the value of Nominal Value parameter that is specified for the buckets bundle in the Top-Up profile. This parameters value represents the corresponding money value of the Initial Units of the bucket being created. To give an example, a bucket could be created which gives a 100 minutes of Voice calling time (= Initial Units), which corresponds to a value of 5 EURO (= Initial Nominal Value, which is equal or related to the actual amount the user pays). Remaining Units
valper1
Amount of not reserved quantities that the current bucket makes available for use. Upon creation of a bucket, you must give a value to this parameter.
General Ledger Code
20.1.4. Bundle Features

20.1.4.1. Buckets Validity Period
The Validity Period of a bundles bucket is recomputed at each top-up operation. Concretely, the validity end date of the Bucket (parameter To, page 802) is postponed in order to extend the validity period of the Bucket. The exact activity end date calculation algorithm is:
Max(existing Bucket validity end , (date today + Top-up Profile Validity Period))
So the validity period extension provided is either added to the previous validity end date of the Bucket, or added to the today date. The maximum of both possibilities is taken. Consequently, the validity period of the Bucket will never be reduced. Note: For charging a call from a bundle, only the begining date of the call is used to select the buckets, i.e., validity of a bucket is only checked at the beginning of a call.For bundle charging, tick is bypassed to empty the bucket. E.g. A fixed rate tariff with cost = 3, unit = 1, qty = 100, tick = 1. So 1 quantity to rate costs 3 money units. If a bucket contains only 1 money unit, we may charge 0.333 quantities to rate on this bucket. We bypass the tick feature only in case bucket is about to get empty.
11 September 2009
Page 803 of 968
Bundles
20.1.4.2. Reset
Some mono-Bucket Bundles are defined as resetable, via the Reset Bucket value at Top-Up option in the Bundle/Counter Usage Label object (see page 284). It means that each time that the Bundle is toppedup, it is reset before being added the quantities specified in the Top-up Profile. In other words, you loose the quantities contained in the Bundle before the top-up operation. In multi-Bucket Bundles, the Buckets are never reset. When the Maximum Number of Roll-over is reached, the oldest Bucket is removed, and a new one is created. This is not considered as a reset operation, since it is the removal of a Bucket, followed by the creation of a new Bucket. Not only the quantities of the Bucket are new, but also the creation date and the validity dates.
20.2. Account Profile and Usage Link object

To make some Account able to use a given bundle (i.e., an instance of Bundle/Counter Usage Label object that is of type Bundle), you need to first associate that bundle with the Account Profile of the Account. Note: You make an Account use a given bundle by creating one, or more if necessary, instance(s) of Bucket object that refer(s) to both the Account and the bundle (i.e., an instance of Bundle/ Counter Usage Label object that is of type Bundle). Similarly, to make some Account able to use a given counter (i.e., an instance of Bundle/Counter Usage Label object that is of type Counter), you need to first associate that counter with the Account Profile of the Account. Note: You make an Account use a given counter by creating one instance of Counter object that refers to both the Account and the counter (i.e., an instance of Bundle/Counter Usage Label object that is of type Counter). Its by means of this object that you associate a bundle/counter with a given Account Profile. For that, you just need to create an instance of Account Profile and Usage Link object that refers to both the Account Profile and the bundle/counter (i.e., an instance of Bundle/Counter Usage Label object). Note: Its not possible to create two, or more, instances of Account Profile and Usage Link that refer to both the same Account Profile and the same bundle/counter (which is an instance of Bundle/ Counter Usage Label object).

On the whole procedure to follow in order to make an Account use a given bundle, see also 12.3.6.4, Tip: Creating and Exploiting a Counter, on page 404. On the whole procedure to follow in order to make an Account use a given Counter, see also 12.3.3.6, Criterion Parameter Description for Advance Bundle Criteria, on page 391.
Page 804 of 968
11 September 2009
Figure 344 - Account Profile and Usage Link GUI
Table 249 - Account Profile and Usage Link - servusag


aservret
Description Reference to the Service Retailer to which the current instance of Account Profile and Usage Link object belongs. This must be a reference to the Account Profile that the current instance of this object associates with the Bundle/Counter Usage Label that parameter Usage Name* specifies. This must be a reference to the Bundle/Counter Usage Label that the current instance of this object associates with the Account Profile that parameter Account Profile* specifies. This is a read-only parameter. It indicates whether the Bundle/Counter Usage Label, that the current instance is referring to, is: Either of type Bundle (usgtype = 0) Or of type Counter (usgtype = 1)
Account Profile*
servclas
Usage Name*
usage
Type
usgtype
This is information taken from the instance of Bundle/Counter Usage Label object that Usage Name* parameter refers to.
11 September 2009
Page 805 of 968
Bundles
Table 249 - Account Profile and Usage Link - servusag Parameter Notification ID*
notif_id
Description
This parameter only applies when Usage Name* parameter refers to a bundle (i.e., to a Bundle/Counter Usage Label of type bundle).
You use this parameter to: Either enable one of the two Credit Level on Sub Account notification types on the current instance of this object Or to disable any notification on the current instance of this object. If Usage Name* parameter of the current instance of this object refers to a Bundle/Counter Usage Label of type counter, set this parameter to 0. Else, if you want to enable one of the two Credit Level on Sub Account notification types on the current instance of this object, enter here the Index ID of the Credit Level on Sub Account notification type that you want to enable on the current instance of this object. Else, set this parameter to 0. That way, any notification is disabled on the current instance of this object.
To know which Index ID corresponds to the Credit Level on Sub Account notification type you chose to enable on the current instance of this object, please read section 5.1, Notification Feature Table Object, on page 161.
object, see also Credit Level on Bundle, on page 180.
On setting up a Credit Level on sub Account notification type on an instance of this See also Notification Type, on page 807. See also Warning Threshold, on page 807.
Why Would You Want to Enable a Credit Level on SubAccount Notification? Whenever a Credit Level on SubAccount notification is enabled on some instance of Account Profile and Usage Link object, the owner of each Account that is associated with the instances Account Profile will receive a warning as soon as the total units available for consumption by the Account on the instances bundle get too low (i.e., gets lower than Warning Threshold parameter of the current instance of this object).
To learn more about Credit Level on SubAccount notification, please see section 5.1, Notification Feature Table Object, on page 161.
Page 806 of 968
11 September 2009
Table 249 - Account Profile and Usage Link - servusag Parameter Notification Type
not_type
Description
This parameter only applies when Usage Name* parameter refers to a bundle (i.e., to a Bundle/Counter Usage Label of type bundle). No Notification Choose this if no notification is enabled on the current instance of this object.
Choose one of the following values:
All Counters Choose this if All Counters notification type, of Credit Level on Sub Account, is enabled on the current instance of this object.
Counters Accumulated Choose this if Counters Accumulated notification type, of Credit Level on Sub Account, is enabled on the current instance of this object.
If Usage Name* parameter of the current instance of this object refers to a Bundle/Counter Usage Label of type counter, set this parameter to No Notification. Else, if one of the two Credit Level on Sub Account notification types is enabled on the current instance of this object, indicate here which notification type is enabled on that current instance. That is, select All Counters if it is enabled on the current instance else select Counters Accumulated if it is enabled on the current instance. Else, set this parameter to No Notification.
On setting up a Credit Level on sub Account notification type on an instance of this

See also Notification ID*, on page 806. See also Warning Threshold, on page 807.
Warning Threshold
warnthr
This parameter only applies when Usage Name* parameter refers to a bundle (i.e., to a Bundle/Counter Usage Label of type bundle).
If Usage Name* parameter of the current instance of this object refers to a Bundle/Counter Usage Label of type counter, you do not need to set this parameter to any value. Else, if one of the two Credit Level on Sub Account notification types is enabled on the current instance of this object, enter here the threshold value against which the total units available for consumption by the Account on the bundle will be compared in order to decide whether these total units available for consumption are too low. Else, set this parameter to 0.
On setting up a Credit Level on sub Account notification type on an instance of this

See also Notification ID*, on page 806. See also Notification Type, on page 807.
11 September 2009
Page 807 of 968
Bundles
20.3. Top-Up Profile Object

A Top-Up RTx request has the option of specifying a Top-Up Profile (via the profId parameter). If such a Top-up Profile is provided in the request, then the top-up operation is fully governed by it. Concretely, The main balance of the Account being topped up is then refilled with the amount specified in the Top-Up Profile (Amount Added on the Account Main Balance parameter). Each Bundle specified by the Top-Up Profile and present in the Account topped-up, is refilled with the quantities specified in the Top-Up Profile (Initial Unit(s) parameter). The Accounts Inactivity Begin and End Dates can also be affected, if the profile requires so.
Top-up of mono-Bucket and multi-Bucket Bundles

When a multi-Bucket Bundle is topped-up, a new Bucket, containing the quantities specified by the Topup Profile, is created. When a resetable mono-Bucket Bundle is topped-up, the unique Bucket of the Bundle is reset and then set to the quantities specified by the Top-up Profile. Note: The behavior of top-up for resetable mono-Bucket Bundles is determined by the value of the PPS_RESET Arena variable defined in the RE Configuration object (see Global Variables, on page 89). When a non-resetable mono-Bucket Bundle is topped-up, the quantities specified by the Top-up Profile are added to the units already present in the unique Bucket of the Bundle.
See parameter Initial Unit(s) on page 818.
20.3.2. Non-resetable Mono-Bucket Bundles: Constraint and Solution

Reminder
A Bundle can be either a single bucket one or a multiple buckets one. See Bundle/Counter Usage Label Object, parameter Multi Bucket Bundle on page 282. A Bundle can be defined as resetable or non-resetable when a Top-up occurs. See Bundle/Counter Usage Label Object, parameter Reset Bucket value at Top-Up on page 284. The Top-Up Profile can specify the refill of any type of Bundle, but a particular constraint applies to nonresetable mono-Bucket Bundles.
Constraint
The mono-Bucket Bundles that mustnt be reset at top-up can only be refilled via one single Top-Up Profile: the one that they have been created with. Particular Case: if the non-resetable mono-Bucket Bundle has not been created via a Top-Up Profile, but manually via the GUI, then no Top-up Profile will be valid for refilling it. The only way to refill such a Bundle is to use the available GUI tools: Operator Deposit (without Top-up Profile), or Modify command of the Bucket object,
Page 808 of 968
11 September 2009
or Balance/Bundle Adjustment. If the non-resetable mono-Bucket Bundle is refilled with a different Top-Up Profile, the top-up operation fails on that particular Bundle.
Impact
So for a Top-up Profile defining a complex top-up operation, for instance on the main Balance and on a non-resetable mono-Bucket Bundle, the main Balance could be successfully refilled, while the Bundle wouldnt be, because the Top-up Profile is not appropriate. In conclusion, the impact of the constraint is very strong, since it can lead to partially executed top-up operations. You might want to avoid such a strict behavior. Thats why the Convergent Rating Engine offers a simple way of escaping the Top-up Profile constraint.
How to bypass the constraint?

If you want to avoid any risk of partially executed top-ups, the Convergent Rating Engine offers an optional logic path, where no Top-Up Profile check is performed. You can thus be sure that all your Bundles will be refilled according to the Top-Up Profile, even non-resetable mono-Bucket ones, normally requiring another Top-Up Profile. For enabling that optional logic path, you must set the ARENA variable PPS_NOVAT (Boolean) to TRUE. If PPS_NOVAT is set to 1, then the Top-Up Profile is not checked before refilling a non-resetable monoBucket Bundle.
How to proceed for the first time?

Step 1: In your RE Configuration object, create an ARENA parameter called PPS_NOVAT, with type Boolean. See 4.1.7, ARENA Tab Parameter Description, on page 89. Step 2: Then decide what you want as default behavior of your Convergent Rating Engine, and execute either step 3 or step 4 accordingly. Step 3: If you want your Convergent Rating Engine to, by default, skip the Top-Up Profile check when refilling non-resetable mono-Bucket Bundles, then set the default value of PPS_NOVAT to TRUE. Keep in mind that you wont be able to modify the value of PPS_NOVAT online, via a Flexibility Point, because the RE Configuration object modifications always take a few seconds or minutes to be effective. Step 4: If you want your Convergent Rating Engine to keep its initial constraint, i.e. checking the TopUp Profile before topping-up a mono-Bucket Bundle, then set the default value of PPS_NOVAT to FALSE. Keep in mind that you wont be able to modify the value of PPS_NOVAT online, via a Flexibility Point, because the RE Configuration object modifications always take a few seconds or minutes to be effective.
Result Codes
When PPS_NOVAT is set to TRUE, then you will get the following result codes in all cases: rescode=1 rescsub=1
11 September 2009
Page 809 of 968
Bundles
When PPS_NOVAT is set to FALSE and the Top-Up Profile doesnt match the targeted Bundle, you will get the following result codes: rescode=1 rescsub=20
20.3.3. Modifying a Top-Up Profile: not on Bundles

An important constraint concerns the MODIFY command on a Top-Up Profile instance. When you create a Top-Up Profile, you specify which Bundles are to be refilled with it. Once the Top-Up Profile is created, the Convergent Rating Engine prevents you to add or remove the Bundles you initially specified. So the MODIFY command will have no effect on the field Bundle(s) of the Top-Up Profile object. Nevertheless, you can still modify the way you want to refill them (validity period, units to be added and nominal value). This limitation is due to the fact that some Bundles can only be topped-up by the Top-up Profile that they have been created with. So the Top-up Profile, if modified, wouldnt anyway be allowed to refill other Bundles than the ones specified at the creation of the Top-up Profile. See 20.3.2, Non-resetable MonoBucket Bundles: Constraint and Solution, on page 808.
Figure 345 - Top-Up Profile GUI
Table 250 - Top-Up Profile Parameter Service Retailer* Description Reference to the Service Retailer who owns the Top-Up profile. Be sure this is the first parameter you fill in. Account Profile* Reference to the Account Profile to which the Top-Up profile is (will be, if you are creating a new Top-Up profile) linked. Be sure this is the second parameter you fill in. Name* If you are creating a new Top-Up profile, enter here a Top-Up profiles name that does not exist yet for the Account Profile and for the Service Retailer. Otherwise, click on the button to the right of the parameter and choose one of the names the list that then appears shows. Before entering a value here, be sure that Service Retailer* and Account Profile* are already filled in.
Page 810 of 968
11 September 2009
20.3.4.1. Top-Up Definition Tab
Figure 346 - Top-Up Profile GUI - Top-Up Definition
11 September 2009
Page 811 of 968
Bundles
Table 251 - Top-Up Profile - - Top-Up Definition Tab Parameter Pricing Nominal Value (Money) This represents the total value, in money, of a Top-Up that is done via this profile. This value can be different of what the user pays for doing a Top-Up via this profile. This is the total value of the Top-Up from the Service Retailer point of view. For example, a Top-Up of 15 on a bundle of money may actually be charged 5 on the main balance, because of promotion, discount or special bargain. The cost is 5, and the nominal value is 15. One typical use of this parameter is as follows: Whenever a Top-Up profile is configured to only add money on the main balance of the Account being topped-up, this parameter should be set to the value of parameter Amount Added on the Account Main Balance. In any case, this parameter should be set to the sum of the nominal values of each bundle of this profile plus the value of parameter Amount Added on the Account Main Balance.
Description
In consequence of a Top-Up done by means of a Top-Up profile, a number of events are inserted in the CRE EDR being generated. Among these, one event will indicate the nominal value (thus, this parameter value) and the general ledger code of the Top-Up profile. Among these too, there will be for each bundle topped-up via the profile, an event mentioning the nominal value of the bundle (see Bundles tab) as well as its general ledger code. The same for the main balance. As a result, the distribution of a Top-Up profiles nominal value over the main balance and the bundles, of the Account being topped-up by means of a Top-Up profile, is available in the EDR. This enables any external system, in possession of the CRE EDR, to do calculations based on that distribution.
Apart from putting this parameter value in some EDR event in consequence of a Top-Up done via a Top-Up profile, the CRE does nothing with this parameter value. General Ledger Code Reference to the General Ledger Code for this Top-Up profile. Any bucket created via a Top-Up done via a Top-Up profile uses the same General Ledger Code as that of the Top-Up profile. This is information put in each EDR event that is about a Top-Up made via this Top-Up profile. Buckets Activation
Page 812 of 968
11 September 2009
Table 251 - Top-Up Profile - - Top-Up Definition Tab Parameter Activate the Bucket(s) Description Option determining when the Buckets created by the current Top-up Profile will be activated. There are two possibilities: If you select At Creation, then any Bucket of this Top-up Profiles Bundles is activated immediately at time it is created. So the Bucket will be usable from the moment of the topup operation, until it expires. If you select At First Use, then any Bucket of this Top-up Profiles Bundles is activated the first time that it is used. So the Bucket will be usable from the first time that a Tariff will charge an event on it, until it expires.
For more details about the expiry of a Bucket, see parameter Expiration Type,
page 813.
Default value: At Creation Setting this Parameter to At First Use Is Not Always Possible. It is not allowed for a Top-Up Profile to have at the same time: Activate the Bucket(s) parameter of the Top-Up profile set to At First Use, and Some Bundle(s) parameter of the Top-Up Profile refer to a Bundle whose Order of Bucket Usage parameter is set to either Earliest expiry date first or Latest expiry date first. Any attempt to create such a Top-Up Profile will therefore fail and result in an error message displayed (this happens upon execution of create command). Likewise, any attempt to set Activate the Bucket(s) parameter of an existing Top-Up Profile to At First Use will fail and result in an error message displayed (this happens upon execution of modify command) if some Bundle(s) parameter of the Top-Up Profile refers to a Bundle that has its Order of Bucket Usage parameter set to either Earliest expiry date first or Latest expiry date first. Buckets Expiration Expiration Type Option determining when the Buckets created by the current Top-up Profile will expire. There are up to six possibilities: FIxed extension Fixed end date Number of days Number of weeks Number of months Number of years To learn how to configure the Expiration Type parameter, see 20.3.5, Setting the Expiry of Buckets, on page 818.
11 September 2009
Page 813 of 968
Bundles
20.3.4.2. Main Balance Tab
Figure 347 - Top-Up Profile GUI - Main Balance
Table 252 - Top-Up Profile - - Main Balance Tab Parameter Amount Added on the Account Main Balance Description This specifies the amount to add to the main balance of the Account being Topped Up by means of this Top-Up profile. In case nominal values are used, this parameter also indicates how the main balance, of the Account being topped up by means of this profile, contributes to the Top-Up nominal value (which is given by Nominal Value (Money) parameter of Top-Up Definition tab).
Page 814 of 968
11 September 2009
Table 252 - Top-Up Profile - - Main Balance Tab Parameter Activity Reload Algorithm* Description Indicates how Topping Up an Active Account via this Top-Up profile affects the Begin Inactivity Date of the Account. Choose between: Cumulative Begin Inactivity Date is incremented by Activity Period Extension days. Maximum If current value of Begin Inactivity Date is less than NOW + Activity Period Extension, Begin Inactivity Date is set to NOW + Activity Period Extension. Else, Begin Inactivity Date is left unchanged.
NOW corresponds to Event Date (calldate) and Event Time (calltime) parameters from the Top-Up RTx request.
What If the Account Is Inactive Upon Its Top-Up? This parameter is taken into account only if the Account being topped up is Active. Topping up an Inactive Account however still affects the Accounts Begin Inactivity Date. Begin Inactivity Date is then always set to the following value: NOW + Activity Period Extension. Is the End Inactivity Date Affected by a Top-Up? If It Is, How? Topping up an Account (whether the Account is Active or Inactive) using the current Top-Up Profile also affects the Accounts End Inactivity Date. The way the date is affected does however not depend on this parameters setting. Here is how Accounts End Inactivity Date is calculated upon the Accounts Top-Up: 1. A new Inactivity Period is first calculated for the Account. It is computed by adding Inactivity Period Extension to the value of the current Inactivity Period. 2. End Inactivity Date is then computed by adding the new Inactivity Period from previous step to the new Begin Inactivity Date resulting from the Top-Up.
Keep in mind that the CRE prevents Begin Inactivity Date of any Account to exceed Maximum Activity End Date Fix Date* as well as to exceed Maximum Activity End Date Nb. Days*, which are parameters of the Account Profile of the Account.
Activity End Date Nb. Days* parameters, see section 19.1, Account Profile object, on page 704.
For more on Maximum Activity End Date Fix Date* and Maximum
11 September 2009
Page 815 of 968
Bundles
Table 252 - Top-Up Profile - - Main Balance Tab Parameter Activity Period Extension (days) Enter a number of days here. Default: 0 Description

Inactivity Period Extension (days)
See Activity Reload Algorithm* to know what use is made of this parameter.
Enter a number of days here. Default: 0
See Activity Reload Algorithm* to know what use is made of this parameter.
20.3.4.3. Bundles Tab
Once the Top-Up Profile is created, you cannot modify the Bundles tab.
When the Top-up Profile is created, you wont be allowed to add, remove or rename any Bundles specified in the Bundles tab. However, you will still be able to change the Nominal Value, Activity Period and Initial Unit(s) parameters.
See 20.3.3, Modifying a Top-Up Profile: not on Bundles, on page 810.
Figure 348 - Top-Up Profile GUI - Top-Up Definition - Bundles
Page 816 of 968
11 September 2009
Table 253 - Top-Up Profile - - nth Row of Bundles Tab Parameter Bundle(s) Description This must refer to a bundle name. That is, to the name of a Bundle/Counter Usage Label that is of type Bundle. This can refer to a bundle that has no buckets.
Pay attention: no Modify allowed Once the Top-up Profile is created, you wont be able to modify the Bundle(s) parameter, neither to add or remove any. Read 20.3.3, Modifying a Top-Up Profile: not on Bundles, on page 810. A Top-Up profile that has its Activate the Bucket(s) parameter set to At First Use is not allowed to have one or more of its Bundle(s) parameters refer to a Bundle whose Order of Bucket Usage parameter is set to either Earliest expiry date first or Latest expiry date first. Any attempt to create such a Top-Up Profile will therefore always fail. Moreover, if some Bundle(s) parameter of an existing Top-Up Profile refers to such a Bundle, you wont be able to have Activate the Bucket(s) parameter of the profile set to At First Use (the modify command will fail and display an error message).
Before you specify a Bundle/Counter Usage Label here (which you do by clicking on the button to the right of the parameter, and by selecting one of the Bundle/Counter Usage Labels that the list that then appears shows), be sure you have already filled in Service Retailer* and Account Profile* parameters. The list you get by clicking on the button lists the bundles that are linked to the Account Profile that Account Profile* parameter specifies. Nominal value A Top-Up profile can specify how the Top-Up nominal value, which is given by Nominal Value (Money) of Top-Up Definition tab, is distributed between the different balances (i.e. main balance and bundles) of the Account that is being topped-up. Indicate here how the bundle of the nth row contributes to the Top-Up nominal value. Apart from putting this parameter value in some EDR event in consequence of a Top-Up done via a Top-Up profile, the CRE does nothing with this parameter value.
See also parameter Nominal Value (Money), page 812, of Top-Up Definition tab.
Activity Period
Only available if Expiration Type is set to Fixed Extension
Number of days during which any Bucket of the Bundle that nth row specifies can be used. This parameter determines the activity period extension of the Bucket, which is recalculated at each top-up operation. For the detailed algorithm, see 20.1.4.1, Buckets Validity Period, on page 803. Note: For validity periods computed otherwise than via a Fixed Extension, see 20.3.5, Setting the Expiry of Buckets, on page 818.
11 September 2009
Page 817 of 968
Bundles
Table 253 - Top-Up Profile - - nth Row of Bundles Tab Parameter Initial Unit(s) Description Quantities added to the Bundle when it is topped up by means of this Top-Up Profile. When a top-up occurs, the Initial Unit(s) are added as follows: If it is a multi-Bucket Bundle A new Bucket, containing the quantity specified here, is created at each top-up operation. If it is a resetable mono-Bucket Bundle The unique Bucket of the Bundle is reset and then set to the quantities specified here. So new value = Initial Unit(s) If it is a non-resetable mono-Bucket Bundle The quantities specified here are added to the units already present in the unique Bucket of the Bundle. So new value = previous Bucket value + Initial Unit(s) Of course, if the Bundles Buckets are holding money, this quantity must indicate a money amount. Otherwise, it is indicating a RUM quantity.
When a bundle is single-bucket, you can indicate whether the bucket value (thats the value of buckets Remaining Units parameter) has to be reset or not prior to a Top-Up is done on the bundle. You indicate that by setting as appropriate Reset Bucket value at Top-Up parameter of Bundle/Counter Usage Label object.
20.3.5. Setting the Expiry of Buckets

The Buckets of a Bundle have a finite validity period, during which events can be charged on them. For each Bucket, the validity period starts at the Activation Date and ends at the Expiry Date. The Activation Date can be determined by: the creation date or the date of the first use of the Bucket. The Expiry Date can be determined by: a fixed number of days, a fixed end date, a duration in days, a duration in weeks, a duration in months or a duration in years. The Top-up Profile defines, for all the Buckets that it creates, the settings of the Activation Date and Expiry Date. All the Buckets ruled by a Top-up Profile are applied the same settings. Even though the various Buckets have independent validity periods, the way their Activation and Expiry Dates are set is identical.
Restrictions
Page 818 of 968
11 September 2009
Among the 6 methods for setting the Expiry Date of a Bucket, some are not available if the Buckets are activated at first use. Indeed, the creation date of the Bucket is always known by the user: they know when they have performed the top-up operation. Nevertheless, the date of a Buckets first use is commonly not known by the user: it depends on the multiple criteria applying to the Tariff selection, and on the validity and remaining units of the other Buckets of the Bundle. Since the Buckets first use is a factor that the user cannot manage, the Top-up Profile doesnt allow to set Expiry Dates according to computation methods that could be at the disadvantage of the user. Thats why expiry at a fixed date (or fixed day, fixed week day, fixed month) is not available in the GUI when the Activation is set to At First Use.
How to configure the Expiration Type in the Top-up Profile GUI?

The Expiration Type of the Buckets created by the Top-up Profile is specified in the Top-up Definition tab of the Top-up Profile object.
1.
Via a Fixed Extension
If you select the Expiration Type Fixed Extension, then the validity period of each Bucket is extended by the number of days that you fill in for that Bucket in the Activity Period column of the Bundles tab.
The Voice Buckets validity period will be extended by 30 days. The SMS Buckets validity period will be extended by 7 days.
For the precise algorithm of the Buckets validity period extension, see 20.1.4.1, Buckets Validity Period, on page 803.
11 September 2009
Page 819 of 968
Bundles
2.
Via a Fixed End Date
If you select the Expiration Type Fixed End Date, then all the Buckets created by the Top-up Profile will expire at the same date, which you fill in the corresponding field.
Format: The Fixed End Date is a date&time value, to be entered as DD/MM/YYYY hh:mm:ss. 3. Via a Duration in days, weeks, months or years
If you select the Expiration Type Duration in days, weeks, months or years, then all the Buckets created by the Top-up Profile will have their expiry date computed according to the same method. The duration is always computed starting at the Activation Date of the Bucket. 3.1. Duration defined as a standard time interval
The period is set in the Number of days/weeks/months/years field. Any other parameters are set to NOTFIXED. Like that, the Bucket will expire when the specified period elapsed, starting at the Activation Date.
The Buckets will end exactly 5 months after their Activation Date.
For example, if the Buckets 3.2. Duration aligned with a fixed moment in time
The period can also be aligned with a fixed moment in time. Keep in mind that the period set in the Number of days/weeks/months/years field is the maximum time window in which the expiry date will occur. The end of the validity period of a Bucket is always set to the end of the day, so DD/MM/YYYY 23:59:59. The Buckets will end maximum 1 week after their Activation Date, on Thursday. For example, if the Buckets Activation Date is Monday 9 April 2007, it will expire on Thursday 12 April 2007, at 23:59:59. Note: If you want the Buckets to expire the last day of the month (whatever the number of days in the month), you must select Day of the Month 31. The expiry date of the Buckets will be aligned on the 31 January, or 28/29 February, or 31 March, and so on.
Page 820 of 968
11 September 2009
See a few more examples below. Bucket Expiry Date if Creation Date = 3 March 2006 7 June 2006
Expiration Type Settings
3 March 2008
7 June 2008
3 May 2007
7 May 2008
5 March 2007
5 June 2008
5 May 2007
5 May 2008
20.3.6. Bucket with Warning SMS

20.3.6.1. Feature description
The Warning SMS feature: sends an SMS to the customer to warn him about the future expiration of his bucket, and sets a flag Warning SMS sent for the bucket. The feature is specified and designed to send the SMS notification per bucket, NOT per bundle. The notification is sent for each bucket regardless of the bundle where is based. This treatment is executed automatically after the Out Of Call object has been properly configured (see chapter 5.2.3, "Configuring the Out Of Call Processing", on page 192) and the feature has been activated (see Feature activation below).
11 September 2009
Page 821 of 968
Bundles
20.3.6.2. Computing the date for SMS notification

Each Bucket (bundcol) has an Expiration Date (limitdat).
To compute the date on which the notification must be sent, the Out Of Call Processing uses the nbrdayssmsendbucket ARENA variable in the Account Profile (servclass) object. The operator has to provide for this variable an integer value in days.
Page 822 of 968
11 September 2009
Common rule for computing A Warning SMS is sent when the condition bundlcol.limidat < now + X days is met. Example 1 A bucket expires on August 17th, 2008. If nbrdayssmsendbucket field is set to 3 days, a Warning SMS will be sent to the customer on August 14th. The algorythm is as follows: bundlcol.limidat = now + X days Example 2 A bucket expires on August 10th, 2008. The nbrdayssmsendbucket field is set to 3 days. If the Warning SMS logic is launched on August 14th AND no Warning SMS has already been sent for this bucket, a Warning SMS will still be sent to the customer. The algorythm is as follows: bundlcol.limidat < now + X days Note: the rationale behind the second treatment allows covering situations where the Warning SMS logic does not run due to a misconfiguration of the Out Of Call object. In this case, no SMS would be sent and the flag SMS sent would not be set on the bucket. On the next run of the Warning SMS logic, the SMS will be sent even for an expired bucket. The Out Of Call object must then be reconfigured.
20.3.6.3. Feature activation

For proper configuration of the Out Of Call Processing, see page 192.
Step 1: Check the nbrdayssmsendbucket ARENA variable in the Account Profile (servclass) object and make sure it has a proper integer value in days. Step 2: Open the Notification Feature Table GUI:
11 September 2009
Page 823 of 968
Bundles
Step 3: Fill in both Feature ID field and Rating Engine Number field with value 23. The Feature ID 23 is reserved for the Warning SMS buckets and must be filled for all Service Providers who want to use this feature.
If this value is not filled in, an alarm will be generated and no Warning SMS will be sent.
Step 4: Open the Account Profile and Usage Link GUI.
Step 5: For each Usage available and for which you want to activate the Warning SMS feature, give an integer value for the Notification ID field. The Notification ID must be filled for all Service Providers who want to use the feature.
If this value is not filled in, an alarm will be generated and no Warning SMS will be sent.
The values in Notification ID field allow selecting categories of buckets based on Usage (Voice-type buckets, MMS-type buckets, etc.) for which the Warning SMS feature will be used.
Note: This field should not be confused with the Feature ID field of the Notification Feature Table object, which only activates the feature.
20.3.6.4. Restriction: Notification Type

The Warning SMS logic does NOT take into account the Notification Type defined in Account Profile and Usage Link. Warning SMSs are always sent regardless of the bundle associated with the bucket and regardless of any other bucket based in the same bundle.
Page 824 of 968
11 September 2009
21. Updating the Accounts Credit
The network operator, managing his Accounts database, may want to modify the credit available on a given Account. In that management process, the user is not involved; he generates no event. We can distinguish two types of occasions in which the network operator wants to modify the credit of some users: 1. 2. The network operator wants to occasionally reward a particular user, retain a category of users, apologize for an error by making a commercial gift,... The network operator basically wants to correct the credit available on an Account, because of an error done by a Customer Care agent, or done in the Product Catalog configuration,...
The Convergent Rating Engine offers two ways of doing such modifications: For top-up operation on a particular Account: use the Operator Deposit. See chapter 21.1, "Operator Deposit Object", on page 825. For straightforward correction of the amount available on an Account: use the Balance/Bucket Adjustment. See chapter 21.2, "Balance / Bucket Adjustment Object", on page 833.
21.1. Operator Deposit Object

The Operator Deposit allows the Service Retailers agent to perform a Top-up operation on a given Account, using an existing Top-Up Profile or freely defining it. The Top-up operation that is performed exactly follows the usual Top-up scheme. In terms of definition and execution, there is no difference with a Top-up initiated by the user himself/herself. The only difference is indeed that its not initiated by the user. The Convergent Rating Engine is not triggered by an RTx request, but by an internal request launched directly via the Operator Deposit object.
The Top-up feature is explained in detail in section 20.3, "Top-Up Profile Object", on page 808.
21.1.1.1. Regular Top-up Operation: Implications

An Operator Deposit is a regular Top-up. So all the characteristics of a Top-up are valid for an Operator Deposit as well. The statements listed below are then only logical. Read them carefully though, in order to appropriately configure your Convergent Rating Engine for enabling the Operator Deposit functionality.
The Deposit is defined as a Service in the CRE

When triggered via the Operator Deposit, the Convergent Rating Engine receives a specific network event type. Even though matching that network event type with a particular Service is not mandatory, it allows differentiating the Operator Deposits from the other Top-ups, performed by the users. Once you have defined a Service, you can create Service Offers in the Product Catalog.
11 September 2009
Page 825 of 968
Updating the Accounts Credit
The users portfolio must contain a Deposit Service Offer

The Operator Deposit performs a regular Top-up. Like for any regular Top-up, the users Portfolio must include a Service Offer of type Top-up, for the Service Deposit.

The different Service Offer Types are described in chapter 7., "Types of Service Offers", on page 228. The notion of User Portfolio is covered in chapter 10., "Users Portfolio", on page 285.
The Operator Deposit might be blocked by the Top-up Rule

Since the Deposit Service Offer is of type Top-up, it contains a Top-up Rule, which the role of is to allow or forbid the Top-up operation. Consequently, the Operator Deposit might theoretically be blocked by the users Top-up Rule.
The Deposits definition is nothing else than a Top-Up Profile

For any Top-up, the distribution of the credit over the main Balance and/or the Bundle(s) of the Account is defined by a Top-up Profile. The request message can either refer to an existing Top-up Profile, or provide all its parameters within the message through the interface. It works exactly the same with the Operator Deposit: either it uses an existing Top-up Profile, or it defines a custom Top-up Profile directly in the graphical interface (in the three tabs).
For a complete description, see section 20.3, "Top-Up Profile Object", on page 808.
21.1.1.2. Specifying the user: an Account and potentially a Customer

For being able to access the Deposit Service, the user must have a Service Offer for that Service in his/ her portfolio.
The users portfolio is the set of Service Offers that are available to him/her, via the default settings of his/her Commercial Offer or via additional Subscriptions. For more details, see chapter 10., "Users Portfolio", on page 285.
So it works just like for any event triggering the Convergent Rating Engine: the network event type provided in the trigger message is mapped to a Service (Deposit). Once the Service is identified, the users portfolio is browsed in order to find, in the users Commercial Offer, a Service Offer for that Service. That Service Offer will be of type Top-up. For doing the Deposit, the Convergent Rating Engine needs to know:
1.
2.
the identifier of the Account on which the Deposit has to be done,

the Commercial Offer in which the Deposit Service Offer must be active (whether default or subscribed to).
In any case, the Account is a mandatory parameter.
21.1.1.3. Commercial Offer Identification Process

The Service Offer containing the Deposit Service Offer is provided by either the Customer or the Account specified in the GUI.
Page 826 of 968
11 September 2009
If a Customer is provided in the Operator Deposit GUI, then the Commercial Offer used to perform the deposit is the one of that Customer. If no Commercial Offer can be found at the Customer, then the deposit cannot be executed. The Commercial Offer of the Account wont be used. If no Customer is provided in the Operator Deposit GUI, then the Commercial Offer used to perform the deposit is the one of that Account. If no Commercial Offer can be found in the Account, then the deposit cannot be executed. The diagram below shows the steps executed for identifying the Commercial Offer used to perform the Operator Deposit.
Identify a Customer?
Identify a Commercial Offer?
ok
nok
Identify an Account?
Identify a Commercial Offer?
ok
nok
Figure 349 - Operator Deposit: Commercial Offer identificaion process
Figure 350 - Operator Deposit GUI
Table 254 - Operator Deposit Parameter Service Retailer* Description Reference to the Service Retailer that an agent of performs the current deposit.
11 September 2009
Page 827 of 968
Table 254 - Operator Deposit Parameter Account Identifier* Description Reference to the Account on which the Deposit has to be done. This parameter is mandatory.
Needed Identifiers If this Account has a Commercial Offer (optional attribute of the Account object), then the Customer Identifier is not needed. However, if the Account has no Commercial Offer, then the Commercial Offer will have to be provided by the Customer; so you must then fill in the Customer Identifier.
For more explanations, read section 21.1.1.2, "Specifying the user: an Account and
potentially a Customer", on page 826.
Customer Identifier
Reference to the Customer providing the Commercial Offer that contains the top-up Service Offer used to perform the current Operator Deposit. This parameter is not mandatory, but it is strictly needed if the Account has no Commercial Offer. If the Account has a Commercial Offer, no Customer should be provided.
For more explanations, read section 21.1.1.2, "Specifying the user: an Account and
potentially a Customer", on page 826.
Reason Code Top-up Profile
Free text field (up to 20 characters long) for indicating the reason why the deposit is done. Reference to the Top-up Profile used for adding money and/or units to the Accounts main balance and/or Bundle(s). If this field is filled in Then you use an existing Top-Up Profile, so you dont have to fill in the parameters of the 3 tabs below (Top-Up Definition, Main Balance and Bundles). If this field is left empty Then you will have to define the Top-Up yourself, in the 3 tabs below (TopUp Definition, Main Balance and Bundles).
21.1.2.1. Top-up Definition, Main Balance and Bundles tabs

The three tabs of the Operator Deposit object allow defining a Top-up Profile. If you have provided a reference to an existing Top-up Profile above, then you dont have to fill in any of the three tabs. Whatever you type in this tab, it will be of no use and Top-up Profile will be executed. If you havent provided any existing Top-up Profile above, then you have to define your custom Top-Up Profile in the three tabs.
Page 828 of 968
11 September 2009
Figure 351 - Operator Deposit GUI - Top-Up Definition tab The Top-up Definition tab of the Operator Deposit object is identical to the Top-up Definition tab of the Top-up Profile object:
You will find a complete description of its parameters in section 20.3.4.1, "Top-Up Definition Tab", on page 811.
11 September 2009
Page 829 of 968
Figure 352 - Operator Deposit GUI - Main balance tab
Page 830 of 968
11 September 2009
The Main Balance tab of the Operator Deposit object is identical to the Main Balance tab of the Top-up Profile object:
You will find a complete description of its parameters in section 20.3.4.2, "Main Balance Tab", on page 814.
Figure 353 - Operator Deposit GUI - Bundles tab
11 September 2009
Page 831 of 968
The Bundles tab of the Operator Deposit object is identical to the Bundles tab of the Top-up Profile object:
You will find a complete description of its parameters in section 20.3.4.3, "Bundles Tab", on page 816.
21.1.3. How to launch an Operator Deposit?

Step 1: Select your Service Retailer and Account. If your Account has no Commercial Offer defined, you should also select the corresponding Customer.
Step 2: Select the Top-up Profile you want to execute. If no existing Top-up Profile suits your needs, define your custom Top-up Profile in the three tabs below.
Page 832 of 968
11 September 2009
Step 3: In the menu, select Deposit.
Step 4: If you want to verify the database modification: Open the Account object. Select your Service Retailer and Account. In the menu, select Display. You can check the balance update and the deposit operation reported in the Last 10 Events tab.
21.2. Balance / Bucket Adjustment Object

The purpose of the Adjustment is to allow the operators to rapidly perform adjustment of the accounts, independently from the Product Catalogs definition of charges and top-ups. The Adjustment offers a way to immediately and easily correct an Accounts credit, for example when a human error occurred at the Customer Care center. Via the Adjustment, three operations are possible on a Balance or a Bucket:
1.
2. 3.
addition
subtraction set absolute value (= reset+addition)
Contrary to the Operator Deposit, the Adjustment doesnt use the Convergent Rating Engines logic for performing top-ups or charges. It is equivalent to a direct intervention on the databases content.
21.2.1.1. Why is the Adjustment Interface Necessary?

Why not adjusting the Accounts credit directly in the Account object and in the Bucket object? Indeed, these objects are equipped with a Modify command, allowing to change the value of the parameters. When using such a command, you do definitely modify the parameters value in the database. So why is the Adjustment interface necessary? Because it ensures a real-time update of the credit.
Convergent Rating Engine Architecture Constraints

The reason why only the Adjustment guarantees the real-time update of the credit lies in the Convergent Rating Engines architecture. The Bucket GUI is located at the SMP level, i.e. the service management level. The Convergent Rating Engines Oracle database is also located there. So when you make a Modify operation via the Bucket GUI, the database is directly updated.
11 September 2009
Page 833 of 968
The Adjustment interface works at the SCP level, i.e. the service execution level. At this level, you find the SHMDB (SHared Memory DataBase), which is the temporary database first accessed for identifying the objects instances involved in a given event. When the SMP Oracle database is updated, the SHMDB is updated accordingly. This update process, called snapshot, takes little time. But still, there is a delay for the SHMDB to get the up-to-date information from the Oracle database. In the meantime, the information in the SHMDB doesnt reflect the real-time status of the object instance. Whenever an event occurs in the Convergent Rating Engine, the object instances to be identified for its processing are first looked for in the SHMDB. If the SHMDB doesnt contain the instance to be identified, the request is sent to the Oracle database. If the SHMDB contains the requested object instance, that one will be provided, without checking in the Oracle database whether that information is really the most upto-date.
Service Management Level
Step 1
SMP
Oracle Database
Bucket GUI
When modified via the Bucket GUI, the Bucket is first updated in the Oracle database. Once updated in the Oracle database, the modified Bucket is updated in the SHMDB.
Step 2
Snapshot update process
Step 2
Service Execution Level
Once updated in the SHMDB, the adjusted Bucket is updated in the Oracle database.
SCP
SHMDB
Step 1
Via the Adjustment, the Bucket is first updated in the SHMDB.
Adjustment
Figure 354 - Credit Update via Object GUI Vs. via Adjustment Interface
Consequence
Concretely, it means that when you make a change at the SMP level, the SCP level is not updated in realtime. So if an event occurs before the snapshot process is completed, the Convergent Rating Engine will base its logic on outdated information, which can have serious consequences when the outdated information is the Accounts credit.
Page 834 of 968
11 September 2009
Example 1: Bucket updated via the Adjustment

Lets take the example of a Bucket with 10 remaining units. An Adjustment setting the remaining units to 15 occurs. The SHMDB is updated in real-time at the SCP level. The Oracle database will be updated accordingly within a short interval, thanks to a snapshot. Then a usage event occurs, to be charged on the Bucket. The cost is 9 units. The Bucket is identified at the SCP level, in the SHMDB. Its current value is 15. So the Bucket is charged as follows: 15-9 = 6. At the end, the Bucket has 6 remaining units.
Example 2: Bucket updated via the Bucket GUI

Lets take the same example as above: a Bucket with 10 remaining units. In the Bucket GUI, the remaining units are set to 15. The Modify command is executed and the Oracle database is updated immediately. At the next snapshot process execution, the SHMDB at the SCP will get the update too. However, a usage event occurs, to be charged on the Bucket, before the snapshot process is completed. So the Bucket is identified at the SCP level, in the SHMDB. At that moment, in the SHMDB, the Bucket s remaining units are still at 10. The cost is 9 units. So the Bucket is charged as follows: 10-9 = 1. After the event, the snapshot process completes and the SHMDB is updated with the Oracle database modifications: the Bucket now has 15 remaining units!
Conclusion
The Adjustment interface is offered to avoid collisions between network events and management operations. Using the Bucket GUI is not very dangerous when performing database management operations during off-peak time slots, because there is no big risk to have an event charging on the same Bucket at the same time. Nevertheless, on essential parameters like the credit, you would best avoid any risk by using the Adjustment interface.
21.2.1.2. Operator Deposit Vs. Balance/Bucket Adjustment

The table below summarizes the main features of each Account credit update tool and shows their differences. Table 255 - Deposit Vs. Adjustment Increase Credit DEPOSIT ADJUSTMENT Yes Yes Decrease Credit No Yes Set Credit No Yes Definition in Product Catalog Yes No Immediate Update No Yes
21.2.1.3. Selecting Buckets for Adjustment

Via the GUI
The Balance/Bucket Adjustement GUI allows smart Bucket selection. You can either manually pick up a particular Bucket from the list of Buckets of the Account, or define selection criteria, based on the creation and/or expiry dates of the Buckets. See Bucket Search Tab, page 841.
11 September 2009
Page 835 of 968
Via the SOAP Interface

If you want to select Buckets on more sophisticated criteria than creation and/or expiry dates, then you can use SOAP commands. Read more in 21.2.5, Bucket Selection and Adjustment via the SOAP Interface, on page 850.
Table 256 - Balance/Bucket Adjustment Parameter Service Retailer* Account Identifier* General Ledger Code Reason Code Description Reference to the Service Retailer that an agent of performs the current Adjustment. Reference to the Account that the credit of has to be adjusted. Reference to the General Ledger Code associated with the current Adjustment. Free text field (up to 20 characters long) for indicating the reason why the adjustment is done.
Page 836 of 968
11 September 2009
Figure 355 - Balance/Bucket Adjustment GUI
21.2.2.1. Balance Tab
Figure 356 - Balance/Bucket Adjustment GUI - Balance tab
11 September 2009
Page 837 of 968
Table 257 - Balance/Bucket Adjustment - Balance tab Parameter Main Balance Description This field displays the current value of the Accounts main Balance.
This is also an input field in which you can type the adjustment operation to be done on the main Balance.
Adjustment operations commands 1. Define the adjustment operation Addition - You type +X for having X added to the current value of the main Balance. Subtraction - You type (X) for having X subtracted from the current value of the main Balance. Set to a new value - You type X for having the main Balance set to X. Note that X can be a negative or a positive value. So if you type -10, you set the Balance to -10; you dont subtract 10 from the current Balance value. 2. Execute the Modify command.
See also How to Adjust the Main Balance?, on page 844.
21.2.2.2. Buckets Tab

The Buckets tab is a display-only interface, showing all the Buckets of the Bundles linked to the current Account. There is one line of information per Bucket. For adjusting a particular Bucket, select the line of that Bucket and right-click. In the pop-up menu that appears, select Adjust Bundle. The Bucket Adjustment GUI opens.

The Bucket Adjustment GUI is described in section 21.2.2.4, "Bucket Adjustment GUI", on page 843. See also How to Adjust a Bucket?, on page 846.
Page 838 of 968
11 September 2009
Figure 357 - Balance/Bucket Adjustment GUI - Buckets tab
Table 258 - Balance/Bucket Adjustment - Buckets tab Parameter ID Description Row ID of the Bucket in the database.

Usage
Corresponds, in the Bucket object, to the parameter Bucket ID (see page 801).
Usage Label of the Bundle to which this Bucket belongs.
Corresponds, in the Bucket object, to the parameter Usage* (see page 801).
11 September 2009
Page 839 of 968
Table 258 - Balance/Bucket Adjustment - Buckets tab Parameter Type Bundle Description Type of units stored in the Bucket (and in all the Buckets of the same Bundle). It can be either Money or Quantity. RUM used Valid From Ratable Unit Metric in which the quantities stored in the Bucket are expressed. Validity start date of the Bucket.

Valid Until
Corresponds, in the Bucket object, to the parameter Valid from (see page 802).
Validity end date of the Bucket.

Value
Corresponds, in the Bucket object, to the parameter To (see page 802).
Number of quantities currently available in the Bucket.
Corresponds, in the Bucket object, to the parameter Remaining Units (see page 803).
You can notice that the information displayed in the Buckets tab of the Adjustment GUI is identical to the display in the Bundle tab of the Account object:
Page 840 of 968
11 September 2009
The same information (and more) is also available, for each single Bucket, in the Bucket object GUI:
21.2.2.3. Bucket Search Tab

The Buckets Search tab is dynamic interface for selecting a particular Bucket of a given Bundle, according to several possible criteria. For adjusting a particular Bucket, define your criteria in the appropriate field and click on Search. The Bucket Adjustment GUI then opens. If more than one Bucket match the criteria entered in the Bucket Search interface, then no Bucket will be selected. In that case, you have to submit more precise criteria.

The Bucket Adjustment GUI is described in section 21.2.2.4, "Bucket Adjustment GUI", on page 843. See also How to Adjust a Bucket?, on page 846.
Figure 358 - Balance/Bucket GUI - Bucket Search tab (1)
11 September 2009
Page 841 of 968
Figure 359 - Balance/Bucket Adjustment GUI - Bucket Search tab (2)
Table 259 - Balance/Bucket Adjustment - Bucket Search tab Parameter Usage Description Reference to the Usage Label of the Bucket to be adjusted.
See parameter Usage*, page 801.

Bucket Order
Among all the Buckets with the same Usage Label, you can select the Bucket to be adjusted in function of its creation order: Last created Bucket 2nd Last Created Bucket 3rd Last Created Bucket 4th Last Created Bucket This order is based on the parameter Creation Date, see page 801.
Creation Date Creation Time
Among all the Buckets with the same Usage Label, you can select the Bucket to be adjusted in function of its Creation Date and/or Creation Time and/or Expiry Date and/or Expiry Time If the selection criteria comply with more than one Bucket, then no Bucket will be returned. You will have to refine your selection criteria. How to fill in the Creation Date and Expiry Date fields? Format: DD/MM/YYYY. If you dont want to select on the Creation or Expiry Date, use the wildcard: */*/* How to fill in the Creation Time and Expiry Time fields? Format: hh:mm:ss. If you dont want to select on the Creation or Expiry Time, use the wildcard: *:*:*
Expiry Date Expiry Time
See the corresponding Bucket attributes: Creation Date (bundlcol.createdt)

and To (bundlcol.limitdat), page 802.
Page 842 of 968
11 September 2009
21.2.2.4. Bucket Adjustment GUI

The Bucket Adjustment GUI is not accessible directly via the SMP object menu. This window only opens when right-clicking on a particular Bucket, in the Balance/Bucket Adjustment GUI.
Figure 360 - Bucket Adjustment GUI

Table 260 - Bucket Adjustment Parameter Bucket ID Service Retailer Remaining Units ID of the Bucket displayed. Service Retailer owning the Bucket displayed. This field displays the current value of the Bucket. Description
This is also the input field in which you can type the adjustment operation to be done on the Bucket.
Adjustment operations commands 1. Define the adjustment operation Addition - You type +X for having X added to the current value of the Bucket. Subtraction - You type (X) for having X subtracted from the current value of the Bucket. Set to a new value - You type X for having the Bucket set to X. Note that X mustnt be a negative value. 2. Execute the Modify command.
Any adjustment that would lead to a Bucket with a negative value will be rejected.
See also How to Adjust a Bucket?, on page 846.
11 September 2009
Page 843 of 968
Table 260 - Bucket Adjustment Parameter Valid From Description This field displays the current validity start date of the Bucket.
This is also the input field in which you can type the new validity start date to be assigned to the Bucket.
To
This field displays the current validity end date of the Bucket.
This is also the input field in which you can type the new validity end date to be assigned to the Bucket.
General Ledger Code Reason Code
General Ledger Code to be associated with the current Bucket Adjustment operation. Free text field (up to 20 characters long) for indicating the reason why the adjustment is done.
21.2.3. How to Adjust the Main Balance?

Step 1: Select your Service Retailer and Account.
Step 2: In the menu, select Display.
Step 3: In the Balance tab, you see the current credit of the Main Balance.
Page 844 of 968
11 September 2009
Step 4: Do your adjustment: Addition In the Main Balance field, delete the current amount and type +X in order to add X to the amount currently in the Balance.
Subtraction In the Main Balance field, delete the current amount and type (X) in order to subtract X from the amount currently in the Balance. Absolute Value In the Main Balance field, delete the current amount and type X, so that X is the new amount of the Balance. Note that X can be a positive or a negative value. Note: So if you type -10, the new Balance value will be [-10], and not [previous value 10]. Step 5: In the menu, select Modify.
Step 6: You see the new credit of the Main Balance.
Step 7: If you want to verify the database modification: Open the Account object. Select your Service Retailer and Account.
11 September 2009
Page 845 of 968
In the menu, select Display. You can check the Balance update.
21.2.4. How to Adjust a Bucket?

Step 1: Select your Service Retailer and Account.
Step 2: In the menu, select Display.
Page 846 of 968
11 September 2009
Step 3: In the Buckets tab, you see the available units of each Bucket of each Bundle linked to the Account.
Step 4: If you know which precise Bucket you want to adjust, then go to step 5. If you cannot identify, within the list of Buckets, the precise Bucket you want to adjust, then go to step 7. Step 5: In the list of Buckets, select the line of the Bucket that you want to modify the value of.
Step 6: Right-click on that line. A menu appears. In the menu, select Adjust Bundle.
11 September 2009
Page 847 of 968
Go to step 9.
Page 848 of 968
11 September 2009
Step 7: Go to the Bucket Search tab. Enter the Usage Label of the Bundle and your criteria for selecting the appropriate Bucket.
Step 8: Click on Search.
Step 9: A window opens, showing the current status of the selected Bucket.
In the Bucket Adjustment window, the frame Data to update holds the three parameters that can be modified by the Adjustment operation: Remaining Units Valid from To Step 10: Do your adjustment: Addition In the Remaining Units field, delete the current quantity and type +X in order to add X to the quantity currently in the Bucket.
11 September 2009
Page 849 of 968
Subtraction In the Remaining Units field, delete the current quantity and type (X) in order to subtract X from the quantity currently in the Bucket. Note that a subtraction that would lead to a negative value wont be executed; the Adjustment will be not successful.
Absolute Value In the Remaining Units field, delete the current quantity and type X, so that X is the new quantity of the Bucket. Note that X mustnt be a negative value. Step 11: In the menu, select Modify.
Step 12: In the Balance/Bucket Adjustment GUI, in the Buckets tab, you see the new number of units in the updated Bucket. Step 13: If you want to verify the database modification: Open the Account object. Select your Service Retailer and Account. In the menu, select Display. Click on the Bundle tab. Check the units of the updated Bucket.
21.2.5. Bucket Selection and Adjustment via the SOAP Interface

If you want to select Buckets on more sophisticated criteria than creation and/or expiry dates, then you can use SOAP commands. The adjustment is performed only when a single Bucket can be identified by the conditions given. Otherwise (for multiple Buckets or Bucket not found), Adjustment is rejected. Below are examples of possible commands issued via SOAP interface.
Page 850 of 968
11 September 2009
Perform adjustment of last Bucket for a particular Account

creactor.badjust.modify,CRITERIA="<CRITERIA><FIELD><NAME>CREATEDT </NAME><TYPE>ORDER</TYPE><VALUE>1</VALUE></FIELD></CRITERIA>", GLCODE="",LIMITDAT="01/01/2007 00:00:00",PPM_RI="bucketsearchaccount", REASON="11",SERVRET="sdpprov",STARTDT="",VALPER1="24";
Adjust Bucket with latest expiry date for specific Account

creactor.badjust.modify,CRITERIA="<CRITERIA><FIELD><NAME>LIMITDAT </NAME><TYPE>ORDER</TYPE><VALUE>1</VALUE></FIELD></CRITERIA>", GLCODE="",LIMITDAT="01/01/2007 00:00:00",PPM_RI="bucketsearchaccount", REASON="11",SERVRET="sdpprov",STARTDT="",VALPER1="24";
Adjust third last created Bucket for a particular Account

creactor.badjust.modify,CRITERIA="<CRITERIA><FIELD><NAME>CREATEDT </NAME><TYPE>ORDER</TYPE><VALUE>3</VALUE></FIELD></CRITERIA>", GLCODE="",LIMITDAT="01/01/2007 00:00:00",PPM_RI="bucketsearchaccount", REASON="11",SERVRET="sdpprov",STARTDT="",VALPER1="24";
Adjust Bucket created on 19/05/2006 at 12 oclock any minute any second

creactor.badjust.modify,CRITERIA="<CRITERIA><FIELD><NAME>CREATEDT </NAME><TYPE>DATETIME</TYPE><VALUE>19/05/2006 12:*:*</VALUE></FIELD> </CRITERIA>",GLCODE="",LIMITDAT="01/01/2007 00:00:00", PPM_RI="bucketsearchaccount",REASON="11",SERVRET="sdpprov",STARTDT="", VALPER1="24";
Adjust Bucket latest created on 19/05/2006

creactor.badjust.modify,CRITERIA="<CRITERIA><FIELD><NAME>LIMITDAT </NAME><TYPE>ORDER</TYPE><VALUE>1</VALUE></FIELD><FIELD><NAME>CREATEDT </NAME><TYPE>DATETIME</TYPE><VALUE>19/05/2006</VALUE></FIELD></CRITERIA>", GLCODE="",LIMITDAT="01/01/2007 00:00:00",PPM_RI="bucketsearchaccount", REASON="11",SERVRET="sdpprov",STARTDT="",VALPER1="24";
Adjust last created Bucket with specific Usage Label

creactor.badjust.modify,CRITERIA="<CRITERIA><FIELD><NAME>CREATEDT </NAME><TYPE>ORDER</TYPE><VALUE>1</VALUE></FIELD><FIELD><NAME>USG_RI </NAME><TYPE>USAGE</TYPE><VALUE>bndl_time</VALUE></FIELD></CRITERIA>", GLCODE="",LIMITDAT="01/01/2007 00:00:00",PPM_RI="bucketsearchaccount", REASON="11",SERVRET="sdpprov",STARTDT="",VALPER1="24";
11 September 2009
Page 851 of 968
Counters
22. Counters
22.1. Counter object
You use the Counter object to set up a counter for a particular Account. You can have a Counter counting any kind of quantity. A Counter is a way to flexibly keep track of the associated Accounts usage, quantities used, cost paid, etc. Be aware that it is up to you to tell to the CRE how it has to update the Counters you set up. Typically, you indicate that to the CRE by: Either suitably building up and inserting Counter criteria into one or more decision trees. A Counter criterion tells to a rule how, and when, it has to update one or more Counters you defined. Note that, in a decision tree, a Counter criterion must always be used in conjunction with some Counter Threshold criterion: A Counter Threshold criterion is used to test a Counter against some threshold value and let the rule choose the returned leaf (e.g., a tariff) in function of the result of that test.

You will find more on the Counter criterion at section 12.3.6, Counter Criterion, on page 401. You will find more on the Counter Threshold criterion at 12.3.7, Counter Threshold Criterion, on page 408.
Or building up some LiteSCE script that updates the Counter as necessary and having the CRE executing that LiteSCE script as necessary. You can have the CRE executing a LiteSCE script either by inserting in a decision tree a LiteSCE criterion that calls it or by letting the CRE execute the LitesCE script whenever it reaches some flexibility point.
You will find more on the LiteSCE criterion at section 12.3.16, LiteSCE Criterion, on page 438.
As you see, the main purpose of the CRE Counters is to implement a thresholding functionality, which is basically made up of three logical operations: 1. 2. 3. The Counter is updated with particular values, in the course of a particular kind of event processing (e.g., either because of some Counter criterion or because of some LiteSCE script). The Counter is tested against a threshold value (e.g., through the execution of either a Counter Threshold criterion of a LiteSCE script) If the Counter crosses the threshold value, a particular logic is launched (and the Counter is typically reset).
Thresholding is typically the logic principle used for Promotions, Loyalty Programs, etc.
See also section 20.2, Account Profile and Usage Link object, on page 804.
Page 852 of 968
11 September 2009
See also section 12.3.6.4, Tip: Creating and Exploiting a Counter, on page 404.
Figure 361 - Counter GUI
Table 261 - Counter - countcol Parameter Service Retailer*

Description Service Retailer defining the current Counter.
servret
Account Identifier*
ppm_ri
Reference to the Account owning the current Counter.(i.e., the current instance of Counter object). The exact parameter referenced is ppm.identify.
Display of the Counters
All the Counters of a particular Account are displayed in the Counter tab of the Account GUI (see page 785). Usage*
usg_ri
This is the name of the Accounts counter. This must the namea of a Bundle/Counter Usage Label (i.e., of an instance of Bundle/Counter Usage Label object) that is of type counter.
If the Bundle/Counter Usage Label is not associated with the Account Profile, of the Account, via one instance of Account Profile and Usage Link object, you cannot use the Bundle/Counter Usage Label in any Counter of the Account.
11 September 2009
Page 853 of 968
Counters
Table 261 - Counter - countcol Parameter Current Counter Value

val
Description You can make a Counter store up to two counter values at the same time. This parameter is one of these counter values. Since it is acting as a counter, its value must be a positive integer. This parameter gets updated only if you set up either some Counter criterion or some LiteSCE script that suitably updates it.

Previous Counter Value
valper
In other terms, you decide yourself of how this parameter is updated and of what it is used for, by setting up the suitable criteria and/or the necessary LiteSCE scripts. As this parameter is not read-only, an operator can update this parameter. This might be useful in some rare cases.
You can make a Counter store up to two counter values at the same time. This parameter is the other one of these counter values. Since it is acting as a counter, its value must be a positive integer. This parameter gets updated only if you set up either some Counter criterion or some LiteSCE script that suitably updates it.

Date
datper
In other terms, you decide yourself of how this parameter is updated and of what it is used for, by setting up the suitable criteria and/or the necessary LiteSCE scripts. As this parameter is not read-only, an operator can update this parameter. This might be useful in some rare cases.
If you want it, you can make a Counter store a date, to which you give the meaning you want. This parameter gets updated only if you set up some LiteSCE script that suitably updates it. Since it is acting as a date, this parameters value must have the form of a date.
Its not possible to use a Counter criterion for making the CRE update the date parameter of a Counter.
This means that you yourself decide of the meaning of the date of a Counter. For example, you could decide this is the date of the last update of the Counter. But you could also decide this is the date at which the Counter was updated for the first time. And you could decide to give another meaning to it. You could also decide not to update this parameter at all.
As this parameter is not read-only, an operator can update this parameter. This might be useful in some rare cases.
a. This corresponds to Name* parameter of the Bundle/Counter Usage Label.
Page 854 of 968
11 September 2009
Part VII. Flexibility
11 September 2009
Page 855 of 968
Page 856 of 968
11 September 2009
23. Arena
23.1. Introduction
The ARENA functionality allows enhancing the data model of the Rating Engine objects and events.
23.2. Arena Object

The Arena object implements the ARENA (Advanced Rating ENgine Application) tool by allowing 1. 2. The description of any existing attribute to be used as a Usage Rating Rule criterion (via the Generic Criterion). The enhancement of the original Rating Engine data model by creating new attributes (called Arena attributes)
The description of an Arena attribute de facto makes it exist and equals declaring and defining it. Once created, an Arena attribute can be used as input of the Generic Criterion and also as a variable of a LiteSCE script.
However, keep in mind that any attribute (Arena or from original data model) can be described by means of Arena object.
On the Generic Criterion, see section 12.3.14, Generic Criterion, on page 429.
23.2.2. Arena Implementation

When an Arena attribute is created in Arena object for enhancing the data model of a particular object class, it is assigned to every object instance of this class. In the database, the Arena feature is actually handled as follows: As long as its default value is not changed, the Arena attribute is actually stored at only one place: in Arena object. This is indeed more economic than storing an identical value in every database record. When the value of an Arena attribute is modified for one or several object instances, the specific value of the attribute is then stored in database, into the particular Arena field of the object instance. When an Arena attribute is removed from Arena object, the particular instances of that attribute that have been stored in the database records keep on existing. They are removed from the database only the next time that the object instance is saved. If you manage the Rating Engine via the GUIs, this implementation is totally transparent: the Arena tab of any object instance always reflects the most up-to-date status of the existing Arena attributes with their actual value (default or specific value). However, if you manage the Rating Engine directly through SOAP, or with SQL queries onto the database, you will have to keep in mind that a merge has to be done between the Arena object information and the object instances records.
11 September 2009
Page 857 of 968
Arena
23.2.3. Modification of ARENA value

You have many objects like Account Profile, RE Configuration, etc. with ARENA Tab. To modify the default value of an arena variable in the arena table, you need to press "Enter" or move cursor to another cell before pressing modify. Only then the new value is taken into account
Attributes Object Name
Description
Figure 362 - ARENA GUI Table 262 - ARENA Parameter Attribute Logical Name Description Logical name of the current Arena attribute. Recommendation This name is the one used for display in the GUIs, so make it explicit (up tot 60 characters). DB Name Database name of the current Arena attribute (name length is up to 20 characters).
Page 858 of 968
11 September 2009
Table 262 - ARENA (continued) Parameter Attributes Object Name Description Name of the object or of the event owning the current (Arena) attribute. The Arena-enabled objects in the Rating Engine are: Service Retailer Account Profile Customer Account Service Offer Definition RE Configuration CE Configuration An Arena attribute can also be assigned to a transient object, i.e. an object describing the structure of the event occurring on the network: Network Events Attribute Type Data type of the current (Arena) attribute. Integer
String Boolean Time Date Instantiated Flag Indicates whether the current attribute belongs to the original Rating Engine model and whether the current attribute is usable (in the Generic Criterion and in LiteSCE scripts) or not: Original Indicates that the current attribute already exists in the original Rating Engine data model. Once this attribute has been described in ARENA object, it can be used as input by the Generic Criterion. Undeployed Indicates that the current attribute is ARENA (i.e., doesnt belong to the original Rating Engine data model), but is not yet usable as Generic Criterion input (because it doesnt exist yet in the database). Deployed Indicates that the current attribute is ARENA (i.e., doesnt belong to the original Rating Engine data model), and is usable as Generic Criterion input (because it exists in the database).
On the Generic Criterion, see section 12.3.14, Generic Criterion, on page 429.
11 September 2009
Page 859 of 968
Arena
Table 262 - ARENA (continued) Parameter Default Value Description Default value of the current ARENA attribute. Boolean type can take the following values as default value: 0 1 true false Note: TRUE or FALSE (uppercase) are not supported and should not be used for provisioning an ARENA attribute of type boolean. This field is useless for original attributes but can do no harm if filled in. Attribute Description Description and comments about the current ARENA attribute.
Page 860 of 968
11 September 2009
24. CE Flexibility Point Management

24.1. Introduction.
24.1.1. Purpose of CE Flexibility Point Management Objects
The flexibility Point Management object Flexibility point manage the Community Engine Flexibility Points with full granularity. The logic of a Flexibility point is implemented by a LiteSCE Script. The Flexibility objects allow determining (1) where, (2) when and (3) under what condition a particular Flexibility Point has to be activated. Where: In what module of the Community Engine script When: on what connector of a call flow Under what condition: For what instance value of what object class
24.1.2. Beware! Make Sure that CE Configuration Settings Agree!

The Flexibility Point defined in Flexibility Point will be taken into account only if the three parameters of the condition (Module, Connector, Object Class) have been enabled in the corresponding tab of the CE configuration
11 September 2009
Page 861 of 968
CE Flexibility Point Management
24.2. Flexibility Point Object

Figure 363 - CE Flexibility Point GUI

Table 263 - CE Flexibility Point Parameter Service Retailer* Object Class* Description Reference to the service retailer defining the current flexibility point Object class in function of which the current Flexibility point has to be activated. Flexibility point activation can be determined in function of one of the following objects: Service retailer Configuration This choice refer to the CE configuration objects unique instance. The actual instance value of the selected Object Class is defined in Object Identifier field Module* Community Engine Module in which the current Flexibility Point has to be activated, when executed via the connector specified below. Reminder A module is a script macro representing an independent part of the service logic. In other words, a module implements a functionality of the Community Engine, like for instance Identification, authorization, and so on.
Page 862 of 968
11 September 2009
Table 263 - CE Flexibility Point Parameter Connector* Description Community Engine Connector in which the current Flexibility Point has to be activated, for the module specified above. Reminder A connector is an entry point into the script, launching the sequential execution of any number of modules. A connector corresponds to a particular event occurring in the service Object Identifier* Identifier of the selected Object Class instance for which the current Flexibility Point has to be activated. The key identifier of objects Service Retailer is name. Tip For object Class Configuration, always type configuration in the object identifier field. LiteSCE Script* Reference to the LiteSCE Script to be played at the current Flexibility Point.
24.2.2. Configuration-dependent Flexibility Point

With the Flexibility Point Object, the Community Engine offers the possibility to define a Flexibility Point per CE Configuration. Since several Service Retailers share one single CE Configuration, any modification to it will affect all service retailers. So keep in mind that this kind of changes should be made cautiously. Note: When creating a Flexibility Point for the CE Configuration, the Object Identifier field must be filled in with config
24.2.3. Module Connector Combinations

Not all modules are present in all connectors. For example, the Connector getppm doesnt use the module identification module. Consequently, some Module/Connector Combination are irrelevant.
24.2.4. Flx_reas Attribute

In the Flexibility Point Object, the Module Connector Combination defining the Flexibility point is actually one single attribute names flx_reas. This attribute is an unsigned Integer obtained by the following function: Module Number + Connector Number * 256
11 September 2009
Page 863 of 968
24.3. CE Object Class Priority Order

24.3.1. CE Priority Rule
If a Flexibility Point has been defined for more than one object, a priority order applies between the objects in order to select the parameters of only one Flexibility Point. The priority rule works as follow: Table 264 - CE Priority Rule Step 1 2 If a Flexibility Point is defined for Service Retailer Configuration a Then Play it. Otherwise go to Step 2 -2 Priority Order Number 1
a. This is the CE Configuration

Steps 1 is only relevant in call states in which the object Service Retailer have already been identified. When those objects are not identified in the context, steps 1 is skipped and the priority order starts at step 2.
Page 864 of 968
11 September 2009
24.3.2. CE Object Priority Table

The table below shows: 1. 2. the Module/Connector combinations (a cell with x represents a nonexistent combination) the Object Class Priority Order for the Flexibility Point activation applying for each combination Order 1: Service Retailer -> CE Configuration Order 2: CE Configuration 3. The Module and Connector Numbers.
11 September 2009
Page 865 of 968
Table 265 - CE Object Priority Table

Module Number
4
Compute Percentage Precision
Connector Number
Connectors
Event Receiver Authorization Identification
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19
Getppm Oneshot Estimate Getppm2 Fstreq Nextreq End Call Cancel Reset Credupdreq Generic Fraudupd Fee Estimate Fee Charge Account Update Acc_upd_Arena Getandcheckppm Getcust Getncheckcust
2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2
x 2 2 x 2 x x x x 2 x x 2 2 x x x 2 2
x 1 1 x 1 x x x x x x x 1 1 x x x x x
x 1 1 x 1 x x x x x x x x x x x x x x
x 1 1 x 1 x x x x 1 x x 1 1 x x x x x
x 1 1 x 1 x x x x 1 x x 1 1 x x x x x
x 1 1 x 1 2 2 2 x 1 x x 1 2 x x x x x
Post-processing
RE Triggering
Partitioning
Modules
Answer
2 1 1 2 1
2 2 2 2 1 2 x 1 2 2 2 2 1 1
Page 866 of 968
11 September 2009
Table 265 - CE Object Priority Table (continued)

Module Number
4
Compute Percentage Precision
Connector Number
Connectors
Event Receiver Authorization Identification
20 21 22 23
Getcustndefacc getncheckcustndefacc Direct topup Custupd
2 2 2 2
2 2 x 2
x x x x
x x x x
x x x x
x x x x
x x x x
11 September 2009
Page 867 of 968
Post-processing
RE Triggering
Partitioning
Modules
Answer
1 1 1 1
Page 868 of 968
11 September 2009
25. RE Flexibility Point Management

25.1. Introduction
25.1.1. Purpose of Flexibility Point Management Objects
The Flexibility Point Management objects Flexibility Config and Flexibility User manage the Rating Engine Flexibility Points with a full granularity. The logic of a Flexibility Point is implemented by a LiteSCE Script. The Flexibility objects allow determining (1) where, (2) when and (3) under what condition a particular Flexibility Point has to be activated. Where: In what module of the Rating Engine script When: On what connector of the call flow Under What Condition: For what instance value of what object class.
25.1.2. Beware! Make Sure that RE Configuration Settings Agree!

The Flexibility Points defined in Flexibility User / Config will be taken into account only if the three parameters of the condition (Module, Connector, Object Class) have been enabled in the corresponding tab of the RE Configuration (Modules tab, Connectors tab, Levels tab).
25.1.3. Flexibility User / Config: Same Functionality

The objects Flexibility Config and Flexibility User implement the same functionality and offer the same GUI as well. The only difference between them lies in the Object Class in function of which they allow to define a Flexibility Point. Table 266 - Differences Between Flexibility User / Config Objects Flexibility Config Available Object Classes Configurationa -> config Service Retailer -> servret Account Profile -> servclas Usage Rating Rule -> priceplan Tariff ->pricetab
a. This refers to RE configuration objects unique instance.
Flexibility User Account -> ppm
25.1.4. Why 2 Objects?

Two separated objects have been created for performance purpose.
11 September 2009
Page 869 of 968
RE Flexibility Point Management
25.2. Flexibility Config Object


To know this objects purpose, see section 25.1.1, Purpose of Flexibility Point Management Objects, on page 869, and next sections.
Note: Beware! Make Sure that RE Configuration Settings Agree! The Flexibility Points defined in Flexibility Config will be taken into account only if the three parameters of the condition (Module, Connector, Object Class) have been enabled in the corresponding tab of the RE Configuration (Modules tab, Connectors tab, Levels tab).
Figure 364 - Flexibility Config GUI Table 267 - Flexibility Config Parameter Service Retailer* Description Reference to the Service Retailer defining the current Flexibility Point.
Page 870 of 968
11 September 2009
Table 267 - Flexibility Config Parameter Object Class* Description Object Class in function of which the current Flexibility Point has to be activated. Flexibility Point activation can be determined in function of one of the following objects: Configuration This latter choice refers to RE configuration objects unique instance. Service Retailer Account Profile Account (defined in the Flexibility User object) Usage Rating Rule Tariff The actual instance value of the selected Object Class is defined in the Object Identifier field. Module* Rating Engine Module in which the current Flexibility Point has to be activated, when executed via the Connector specified below. Reminder
A Module is a script macro representing an independent part of the service logic. In other words, a Module implements a functionality of the Rating Engine, like for instance Estimating, Managing the Life Cycle, Rating, Reserving, and so on. Connector* Rating Engine Connector in which the current Flexibility Point has to be activated, for the Module specified above. Reminder A Connector is an entry point into the script, launching the sequential execution of any number of Modules. A Connector corresponds to a particular event occurring in the service. Object Identifier* Identifier of the selected Object Class instance for which the current Flexibility Point has to be activated. The key identifier of objects Service Retailer, Account Profile, Usage Rating Rule or Tariff is Name. Tip For object class Configuration: always type config in the Object Identifier field. LiteSCE Script* Reference to the LiteSCE Script to be played at the current Flexibility Point.
11 September 2009
Page 871 of 968
25.2.3. Configuration-dependent Flexibility Point

With the Flexibility Config object, the Rating Engine offers the possibility to define a Flexibility Point per RE Configuration. Since several Service Retailers share one single RE Configuration, any modification to it will affect all Service Retailers. So keep in mind that this kind of changes should be made cautiously. Note: Tip: When creating a Flexibility Point for the RE Configuration, the Object Identifier field must be filled in with config.

Not all modules are present in all connectors. For example, the Connector One Shot doesnt use the Module Get Reservation. Consequently, some Module/Connector combinations are irrelevant.
For a detailed table showing existing Module/Connector combinations, see Table 270, RE Object Priority Table, on page 877 (x represent inexistent combinations).
In the Flexibility Config object (flex_cfg), the Module Connector combination defining the Flexibility Point is actually one single attribute named flx_reas. This attribute is an Unsigned Integer obtained by the following function: Module Number + Connector Number * 256
The Module and Connector Numbers are displayed in Table 270, RE Object Priority Table, on page 877.
25.3. Flexibility User Object


To know this objects purpose, see section 25.1.1, Purpose of Flexibility Point Management Objects, on page 869, and next sections.
Note: Beware! Make Sure that RE Configuration Settings Agree! The Flexibility Points defined in Flexibility User will be taken into account only if the three parameters of the condition (Module, Connector, Object Class) have been enabled in the corresponding tab of the RE Configuration (Modules tab, Connectors tab, Levels tab).
Page 872 of 968
11 September 2009
25.2.5. flx_reas Attribute
Figure 365 - Flexibility User GUI Table 268 - Flexibility User
Parameter
Description Reference to the Service Retailer defining the current Flexibility Point. Object Class in function of which the current Flexibility Point has to be activated: this Object Class is always the Account. Flexibility Point activation can be determined in function of one of the following objects: Configuration (defined in Flexibility Config) This latter choice refers to RE configuration objects unique instance. Service Retailer (defined in Flexibility Config) Account Profile (defined in Flexibility Config) Account Usage Rating Rule (defined in Flexibility Config) Tariff (defined in Flexibility Config) The actual instance value of the Account is defined in the Object Identifier field.
Service Retailer* Object Class*
Module*
Rating Engine Module in which the current Flexibility Point has to be activated, when executed via the Connector specified below. Reminder A Module is a script macro representing an independent part of the service logic. In other words, a Module implements a functionality of the Rating Engine, like for instance Estimating, Managing the Life Cycle, Rating, Reserving, and so on.
11 September 2009
Page 873 of 968
Parameter Connector*
Description Rating Engine Connector in which the current Flexibility Point has to be activated, for the Module specified above. Reminder A Connector is an entry point into the script, launching the sequential execution of any number of Modules. A Connector corresponds to a particular event occurring in the service.
Object Identifier*
Identifier of the Account instance for which the current Flexibility Point has to be activated. The key identifier of the Account object is the Card Number. Reference to the LiteSCE Script to be played at the current Flexibility Point.
LiteSCE Script*

Not all modules are present in all connectors. For example, the Connector One Shot doesnt use the Module Get Reservation. Consequently, some Module/Connector combinations are irrelevant.
For a detailed table showing existing Module/Connector combinations, see Table 270, RE Object Priority Table, on page 877 (x represent inexistent combinations).
25.3.4. flx_reas Attribute

In the Flexibility User object (flex_usr), the Module Connector combination defining the Flexibility Point is actually one single attribute named flx_reas. This attribute is an Unsigned Integer obtained by the following function:
Module Number + Connector Number * 256

The Module and Connector Numbers are displayed in Table 270, RE Object Priority Table, on page 877.
25.4. RE Object Class Priority Order

25.4.1. RE Priority Rule
If a Flexibility Point has been defined for more than one object, a priority order applies between the objects in order to select the parameters of only one Flexibility Point.
Page 874 of 968
11 September 2009
The priority rule works as follows: Table 269 - RE Priority Rule Step 1 2 3 4 5 6 If a Flexibility Point is defined for Tariff Usage Rating Rule Account Account Profile Service Retailer Configurationa Then play it. Otherwise go to Step 2 Step 3 Step 4 Step 5 Step 6 -3 2 Priority Order Number 1
a. This is RE configuration.
25.4.2. Important Remark

Steps 1 and 2 are only relevant in call states in which the objects Tariff and Usage Rating Rule have already been identified. When those objects are not identified in the context, steps 1 and 2 are skipped and the priority order starts at step 3. This is the Priority Order number 2. In some call states, only the Configuration is known by the Rating Engine. In this case, the RE Configuration object is the only one able to define a Flexibility Point. This is the Priority Order number 3.
For a complete overview of what priority order applies in each module/connector, see Table 270, RE Object Priority Table, on page 877 (x represent inexistent combinations).
11 September 2009
Page 875 of 968
25.4.3. RE Object Priority Table

The table below shows 1. 2. the Module/Connector combinations (a cell with an x represents a nonexistent combination) the Object Class Priority Order for the Flexibility Point activation applying for each combination Order 1: Tariff -> Usage Rating Rule -> Account -> Account Profile -> Service Retailer -> RE Configuration Order 2: Account -> Account Profile -> Service Retailer -> RE Configuration Order 3: RE Configuration 3. the Module and Connector Numbers.
Page 876 of 968
11 September 2009
Table 270 - RE Object Priority Table

10 11 12 13 14 15 16 17
Identification After
Connectors
Rate Event Before Rate Event After End Call Answer Get Reservation Post Processing Notify Balance Recurrent Fee Estimate Cost
Connector Number
Notify Bundle
Identification
Authorisation
Modules
1 2 3 4 5 6 7 8
getppm oneshot estimate ppmupdate fstreq nextreq endcall cancel reset credupdreq generic fraudupd Getandcheckppm ppm. lscecreatebefore ppm. lscecreateafter ppm. lscemodifybefore ppm. lscemodifyafter ppm. lsceremovebefore ppm. lsceremoveafter Charge Fee Estimate Fee Accupd Arena Getppmallbuckets
3 3 3 x 3 3 3 3 3 3 3 3 3 3 3 2 2 2 3 3 3 x 3
3 3 3 3 3 3 3 3 3 3 3 3 3
x 2 x x 2 x x x x x x x 2
x 2 x x 2 x x x x x x x 2
x 2 x x 2 x x x x x x x x
x 2 2 x 2 x x x x x x x x
x x x x 1 2 x x x x x x x
x x x x 1 2 x x x x x x x
x 1 1 x x
2
x 1 1 x x 2 1 2 x x x x x
x x x x x x x x x 2 x x x
x 1 x x x 2 2 2 x x x x x
2 1 1 x 1 2 2 2 2 2 2 2 2
x 1 2 x 2 2 2 2 x x 2 x x
x x x x x x x x x 2 x x x x x x x x x
x x x x x x x x x 2 x x x x x x x x x 2 2 x x
2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 1
2 2 x x x x x
9 10 11 12 13 14 15 16 17 18 19 20 21 22 23
3 3 3 3
2 2 x x
2 2 x x
2 2 x x
x x x x
x x x x
2 2 x x
1 1 x x
1 1 x x
2 2 x x
2 2 x x
1 1 x 2
1 1 x x
2 2 x x
11 September 2009
Page 877 of 968
Notification
Reception
Life Cycle
End Call
reserve
Top-up
18
Module Number
x 1 x x 1 1 x x x x x x 2 x x x x x x 1 1 x x
Page 878 of 968
11 September 2009
26. RE LiteSCE Objects

26.1. If You Were Using a CRE Version Running on OSP 2.3
Apart from the LITESCE SCRIPT POOL object, the versions of the CRE like this one running on OSP 2.4 have gotten rid of all the other RE and CE LiteSCE objects offered by the CRE versions running on OSP 2.3. Indeed, with the advent of OSP 2.4, a new OSP service whose objects supersede all these objects has seen the light: PFMLITESCE service. The table here below indicates: Which RE and CE LiteSCE objects have disappeared in the CRE versions running on OSP 2.4 and For each object that has been superseded, which PFMLITESCE object supersedes it. Table 271 - Whats New with This LiteSCE Oject Is No Longer Available in CRE Versions Running on OSP 2.4... RE LITESCE SCRIPT object CE LITESCE SCRIPT object RE LITESCE PROFILE object
...and Is Now Superseded by this LiteSCE Object PFMLITESCE ACTION object PFMLITESCE ACTION object PFMLITESCE PROFILE object PFMLITESCE PROFILE object No object supersedes RE LITESCE CUSTOMER object. No object supersedes CE LITESCE CUSTOMER object.
CE LITESCE PROFILE object RE LITESCE CUSTOMER object CE LITESCE CUSTOMER object
26.2. CE and RE LiteSCE Profile Objects

See section 26.1, If You Were Using a CRE Version Running on OSP 2.3, on page 879.
26.3. CE and RE LiteSCE Customer Objects

26.4. CE and RE LiteSCE Script Objects

26.5. LiteSCE Script Pool Object

Only the RE has a LiteSCE Script Pool object, which is called LiteSCE Script Pool.
11 September 2009
Page 879 of 968
RE LiteSCE Objects
26.5.1. Object Description

A LiteSCE Script Pool is a group of up to 8 LiteSCE Scripts. These LiteSCE Scripts can be played via the Generic Connector. Only instances of the following objects can be set to refer to a LiteSCE Script Pool: Service Retailer object, Account Profile object, and Account object. When triggering the Generic Connector, the RTx passes a number of parameters, among which the two following ones: The object owning the LiteSCE Script Pool The index within the Pool of the LiteSCE Script to be played.
Page 880 of 968
11 September 2009
Figure 366 - LiteSCE Script Pool GUI Table 272 - LiteSCE Script Pool Parameter Service Retailer* LiteSCE Script Pool Name* Owner* Script 01 Description Reference to the Service Retailer defining the current LiteSCE Script Pool. Name of the current LiteSCE Script Pool. Reference to the LiteSCE Customer owning the LiteSCE Scripts constituting the Script Pool. Reference to the LiteSCE Script stored at index 1 in the current LiteSCE Script Pool. At Generic Connector trigger, reference to the script to be played is done via its index number in the LiteSCE Script Pool. Remark When triggering the Generic Connector, the RTx passes 2 parameters: The object owning the LiteSCE Script Pool The index within the Pool of the LiteSCE Script to be played. Script 02 08 (idem)
11 September 2009
Page 881 of 968
Part VIII. Community Engine
Page 882 of 968
11 September 2009
27. Creating and Provisioning Customers

27.1. Customer object
The Community Engine brings forward the notion of Customer, which is conceptually distinct from the notion of Account. The Customer can be seen as a person subscribing to a particular set of Services, using those Services by generating events, via a particular device (mobile phone, PC,...), located at a particular place when he connects to a Service, of which personal details can be listed (name, address, language,...), having a particular contractual or non-contractual relationship with the Service Provider, potentially having particular relationships with other people: other Customers of the same Service Provider, within a Community, within a Closed User Group, or any people in a Friends and Family List. As opposed to the Customer, the Account can be seen as a disincarnate entity.
For more explanation about the Customer notion, please see your Convergent Rating Engine V2.0 Product Description, chapter 13.
27.1.1.1. Trigger on Customer or Account?

When the Convergent Rating Engine is triggered, it first attempts identifying a Customer. If the Customer identification process succeeds, the Community Engine performs the Authorization, the charged Account identification and the applicable Service Offer identification. It then triggers the Rating Engine for the rating and charging process. If the Customer identification process fails, the Community Engine just plays the role of gateway and forwards the triggering event to the Rating Engine. Then the Rating Engine attempts identifying an Account with that same identifier. The remainder of the event processing is then performed in the Rating Engine, following the exact same logic as the one performed by the Community Engine: Authorization and applicable Service Offer identification. And finally, the rating and charging process.
11 September 2009
Page 883 of 968
Creating and Provisioning Customers
Figure 367 - Customer GUI
Table 273 - Customer - client Parameter Service Retailer*

aservret
Description Reference to the Service Retailer owning the current Customer.
Page 884 of 968
11 September 2009
Table 273 - Customer - client Parameter Version*

test_sta
Description Here you indicate whether the Customer is a test Customer or not. Choose one of the following value: Active By setting Version* parameter to this value, you make the Customer behave as a normal Customer. Whenever the CRE processes an RTx request that is about a normal Customer (i.e., a Customer that is not in test), it avoids using Product Catalogs instances versions that are in test. Test By setting Version* parameter to this value, you make the Customer behave as a test Customer. Whenever the CRE processes an RTx request that is about a test Customer, it prefers, when they exist, to use Product Catalogs instance versions that are in test. You will most of the time, if not always, use test Customers along with the Tariff Tester, in order to test versions of your Product Catalog instances versions.
You will most often use Test Accounts in conjunction with the Tariff Tester, in order to do simulations that you will use to test your product catalog.
On using test accounts to do simulations, see also Key*, on page 207. On the Tariff Tester, see section 5.3, Tariff Tester Object, on page 199. To take knowledge of which logic the CRE follows in order to choose the Test
versions it then uses, see chapter 11., "Versioning", on page 324.
Why Would You Want to Set Up a Test Customer? You want to set up a test customer for the same reason you want to set up an test Account. On this latter subject, see Why Would You Want to Set Up a Test Account?, on page 756.
11 September 2009
Page 885 of 968
Table 273 - Customer - client Parameter Closed User Group

ccglist
Description Closed User Group of the current Customer. This must be a character string.
You can use the Closed User Group criterion to check, from within some kinds of rules, whether the called customer and the calling customer of the network event, that is being processed, belong to the same CUG or not.
Closed User Group criterion. It also indicates which kinds of rules allow to use the criterion.
Section 12.3.5, Closed User Group Criterion, on page 399, documents the

To make two or more Customers belong to the same CUG, just make sure Closed User Group parameter of each of these Customers contain the same CUG name. The name of a CUG, which is a character string, is case sensitive. Thus, to give an example, if Closed User Group parameter of a given customer is set to Ab and Closed User Group parameter of another one is set to AB, the two customers do not belong to the same CUG.
In the CRE, there is no object for describing CUGs. As a result, assigning for the first time a character string to a Customers Closed User Group parameter is the same as creating in the CRE a CUG that has that character string as its name. A Customer cannot be associated with more than one CUG. Indeed, a Customer has only one Closed User Group parameter.

Friends and Family List
pchg_ref
Reference to the Friends and Family List of the current Customer. For detailed explanation about the Friends and Family feature, please see chapter 18., "Preferred Charging", on page 699.
Page 886 of 968
11 September 2009
Table 273 - Customer - client Parameter Status*

clt_stat
Description Administrative status of the current Customer. The four available statuses are set via an operator managing the Customer database. Note: When the Customer status changes from Valid to Active, the Commercial Offer and Default Account parameters must be have been filled, although both are not mandatory parameters: they are indeed optional at Customers creation but are needed for status switch from Valid to Active. Valid The current Customer is valid, i.e. registered in the Service Retailers database, but he is not Active yet. Active No particular limitation is applied to the current Customer. This is the standard Administrative Status of Customers. Suspended The current Customer is no longer authorized to perform any event. This status is typically meant to block Customers suspected of fraud, etc.
Terminated The current Customer is no longer a Service Retailers client.
Figure 368 - Customer GUI - Identification tab
11 September 2009
Page 887 of 968
Table 274 - Customer - Identification tab Parameter Customer External ID (Optional) Description This must be a character string. Maximum length: 20 characters. The value of this parameter is simply information stored into the database along with the data of the customers. The CRE makes no other use of it at all. You can use this parameter to correlate two or more customers with each other. That is, to make them related with each other. Example of Use of this Parameter for Correlating Customers One example of use of this parameter is when you want to indicate that some customers are related with each other and you want to be able to retrieve in one shot these related customers. To give an example, assume that the same person corresponds to a number of customers and that you would like to retrieve in one single shot all the customers corresponding to that person. Let us illustrate this by inventing some Mr. John Smith who subscribed as the following customers:
john_smith_home, john_smith_non_profit_organization, john_smith_sports_club In order to enable you to retrieve in one shot all the customers corresponding to Mr. John Smith, you will for example want to set this parameter value to john_smith in each of the above customers. You will then retrieve all customers corresponding to Mr. John Smith by doing what follows from Customer objects GUI: 1. Click on CLEAR button, which appears at the top of the GUI, in order to clear all the GUI parameters. 2. Enter into Service retailer* parameter the name of the Service Retailer to which the customers to retrieve belong. 3. Enter the following value into this parameter: john_smith. 4. Click on (CE) Customer text, which appears at the top of Customers GUI. 5. In the pull-down menu that then appears, select List command. 6. In the window that then appears, select the parameters you want to see. Afterwards, click on DONE button, which appears at the bottom of the window. 7. A new window then appears, listing all the customers that correspond to Mr. John Smith.
Page 888 of 968
11 September 2009
Table 274 - Customer - Identification tab Parameter Client Identifier*

clt_id
Description Character string identifier of the current Customer. Maximum length: 60 characters. Two Customers cannot have the same Customer Identifier* parameter value, even if they are not belonging to the same Service Retailer. In other terms, this parameter value must be unique across all the Customers of all Service Retailers.
This parameter makes up the primary key of the Customer. Because of that, the only way to change the Customer Identifier* parameter of an already created Customer is to firstly delete the Customer and secondly re-create it. This parameter value is, along with Identifier (Login), Card Number and MSID parameter, one of the values that an RTx request can use to address (i.e., in ppmvalue parameter of the RTx request) a CRE Customer.
Commercial Offer (default)
Reference to the default Commercial Offer of the current Customer.
Role of the Default Commercial Offer
If the Customer belongs to no Community, the Default Commercial Offer must be present. It is then the unique Commercial Offer of that Customer. If the Customer belongs to a Community, the Default Commercial Offer is used in any one of the following cases: The customer can be a calling customer and he/she belongs to an unnamed community. The Customer can be a calling customer, and no payer, other than the Customer, could be found in the Communities to which the Customer belongs. The Customer belongs to an unnamed Community and he/she could be the payer for other Customers belonging to that Community.
For more details about which of the Customers Commercial Offers eventually
applies to a given event, please see section 8.2, "Commercial Offer Application Order", on page 254.
Note: When the Customer status changes from Valid to Active, the Commercial Offer and Default Account parameters must be have been filled, although both are not mandatory parameters: they are indeed optional at Customers creation but are needed for status switch from Valid to Active.
11 September 2009
Page 889 of 968
Table 274 - Customer - Identification tab Parameter Account (default)

ppm_id
Description Reference to an Account. This is the Account to be charged by default. Although entering a value into this parameter is optional at the time of account creation(i.e valid state), you will want to enter a value here if the Customer has only one Account. You will also want to enter a value here if: A Customer has more than one Account and Some Service Offers of its default Commercial Offer use no charging rule and No other Customers will pay for these Service Offers (i.e., either the Customer belongs to no communities or no possible payer can be found among the communities to which the Customer belongs). Whats the Default Account of a Customer? Here you are explained the mechanism by which the CRE decides whether a Customers default Account will pay or not. To charge a given network event, the CRE needs to find out some Account to charge. If the Customer who initiated the network event belongs to one or more communities, the CRE will first try to make pay a Customer belonging to one of these communities. However, if the CRE fails to find out such a Customer in the communities, the CRE will necessarily attempt to charge some Account of the Customer who initiated the network event. For identifying that Account, the CRE then first tries to identify, in the Customers default Commercial Offer, the Service Offer that corresponds to the network event to charge. If it finds none, the CRE fails to charge the network event. But if it finds one, the way the Account to charge is discovered depends on whether the Service Offer specifies a charging rule or not. If the Service Offer specifies a charging rule, the Account to charge is the one returned by the charging rule. If the Service Offer does not specify a charging rule, the default Account of the Customer (the Account this parameter specifies) is the one that will be charged. Of course, if no default Account is specified for the Customer (entering a value into this parameter is indeed optional), the CRE then fails to charge the network event. Note: When the Customer status changes from Valid to Active, the Commercial Offer and Default Account parameters must be have been filled, although both are not mandatory parameters: they are indeed optional at Customers creation but are needed for status switch from Valid to Active.
Page 890 of 968
11 September 2009
Table 274 - Customer - Identification tab Parameter Identifier (Login)

clt_idot
Description The Identifier (Login) value of a given Customer must be unique across all the Customers of the CRE, whatever the Service Retailer of these Customers. The CRE enforces this behavior. This string of max 40 characters can be used for the Customers Login or any other useful identifier, according to the Service Retailers service offering and network needs.
Although the CRE ensures of the uniqueness of this parameter across all the Customers of all Service Retailers, the CRE does not ensure uniqueness of this parameters across all the Accounts and all the Customers of all Service retailers. Thus, the CRE will never prevent that a Customer and an Account use the same value for their Identifier (Login) parameter. This parameter value is, along with Customer Identifier*, Card Number and MSID parameter, one of the values that an RTx request can use to address (i.e., in ppmvalue parameter of the RTx request) a CRE Customer.
MSID
clt_msid
MSID of the current Customer. The MSID value of a given Customer must be unique across all the Customers of the CRE, whatever the Service Retailer of these Customers. The CRE enforces this behavior. This must be an integer value. It cannot be longer than 24 decimal digits.
Although the CRE ensures of the uniqueness of this parameter across all the Customers of all Service Retailers, the CRE does not ensure uniqueness of this parameters across all the Accounts and all the Customers of all Service retailers. Thus, the CRE will never prevent that a Customer and an Account use the same value for their MSID parameter. This parameter value is, along with Customer Identifier*, Identifier (Login) and Card Number parameter, one of the values that an RTx request can use to address (i.e., in ppmvalue parameter of the RTx request) a CRE Customer.
11 September 2009
Page 891 of 968
Table 274 - Customer - Identification tab Parameter Card Number

clt_cnbr
Description Card Number (MSISDN) of the current Customer. The Card Number value of a given Customer must be unique across all the Customers of the CRE, whatever the Service Retailer of these Customers. The CRE enforces this behavior. This must be an integer value. It cannot be longer than 24 decimal digits.
Although the CRE ensures of the uniqueness of this parameter across all the Customers of all Service Retailers, the CRE does not ensure uniqueness of this parameters across all the Accounts and all the Customers of all Service retailers. Thus, the CRE will never prevent that a Customer and an Account use the same value for their Card Number parameter. This parameter value is, along with Customer Identifier*, Identifier (Login) and MSID parameter, one of the values that an RTx request can use to address (i.e., in ppmvalue parameter of the RTx request) a CRE Customer.
Figure 369 - Customer GUI - Administrative Info tab
Table 275 - Customer - Administrative Info tab Parameter Phone Number

clt_phon
Description Phone number of the current Customer.
These are the standard identification attributes of the Customer. None of them are mandatory.
Page 892 of 968
11 September 2009
Table 275 - Customer - Administrative Info tab Parameter E-mail Address

clt_emai
Description E-mail address of the current Customer.
Language
clt_lang
Language of the current Customer.
Nationality
clt_nat
Nationality of the current Customer.
Address
clt_addr
Postal address of the current Customer.
PIN Number
pin
PIN code of the current Customer.
Fax
clt_fax
Fax number of the current Customer.
Login
clt_logi
Access login of the current Customer, to be validated with the Password.
Password
clt_pwd
Access password of the current Customer, associated with the Login.
Contract Holder
ctr_hold
This flag indicates whether the current Customer is at the same time a contract holder. The Contract Holder notion is associated to the Customer who has signed the contract with the Service Retailer for the current Customer. Some Customers are not the holders of their own contract. For instance, the Customers benefitting from a corporate scheme by which they received their mobile mobile phone from the company and their employer pays for all their calls are not the holders of the contract they benefit from. In that case, the Contract Holder is the company. The same explanation typically applies for minor children in Family schemes, where a parent is the Contract Holder.
Contract Number
ctr_nbr
For Contract Holders, reference number of the contract applying to the current Customer. Rank of the current Customer. Basic VIP
Rank
clt_rank
11 September 2009
Page 893 of 968
Figure 370 - Customer GUI - Physical Info tab

Table 276 - Customer - Physical Info tab Parameter First Name

clt_fstn
Description First Name of the current Customer.
These are the standard identity attributes of the Customer. None of them are mandatory. Some of them are however very important for the invoicing of the Postpaid Customers.
Last Name
clt_name
Last Name of the current Customer.
Place of Birth
clt_plbi
Place of Birth of the current Customer.
Date of Birth
clt_dabi
Date of Birth of the current Customer.
Passport Number
clt_pasn
Passport Number of the current Customer.
Passport Issuing Country

clt_pasc
Country from which the current Customers passport is issued.
Page 894 of 968
11 September 2009
Table 276 - Customer - Physical Info tab Parameter Type

clt_past
Description Type of the current Customers passport. Type 1 Type 2
Gender
clt_gen
Gender of the current Customer. Male Female
Marital Status
clt_msta
Marital status of the current Customer. Single Married Widowed
Figure 371 - Customer GUI - Legal Info tab
Table 277 - Customer - Legal Info tab Parameter Company Number

clt_conb
Description
This parameter is meant for Customers that arent actual physical persons, but rather legal entities or organizations, such as companies.
Number of the Company (= current Customer) in the Service Retailers database. This information can be useful for the billing process. Sector
clt_sect
Economic sector of the company.
11 September 2009
Page 895 of 968
Figure 372 - Customer GUI - Zoning tab
Table 278 - Customer - Zoning tab Parameter Home Zone

homezone
Description
Home Zone of the current Customer.
Figure 373 - Customer GUI - ARENA tab
Page 896 of 968
11 September 2009
Table 279 - Customer - ARENA tab Parameter Logical Name Description Logical name of the ARENA attribute. This parameter is set in the ARENA object and is only available at display in the Customer GUI. DB Name Database name of the ARENA attribute. This parameter is set in the ARENA object and is only available at display in the Customer GUI. Type Data Type of the ARENA attribute. This parameter is set in the ARENA object and is only available at display in the Customer GUI. Value Value of the ARENA attribute. This parameter receives a default value in the ARENA object.
Figure 374 - Customer GUI - Subscriptions tab
Table 280 - Customer - Subscriptions tab Parameter Description
The Subscriptions tab of the Customer GUI is a read-only interface allowing to check all the Subscriptions of the current Customer. Each field corresponds to a parameter of the Customer Subscription object.
For a complete description, see 10.4, Subscription Objects, on page 290. Value of the Service Offer Group* field (see page 291). Value of the State field (see page 292).
Service Offer Group Status
11 September 2009
Page 897 of 968
Table 280 - Customer - Subscriptions tab Parameter Activation / Cancellation Fees Creation Date Suspension Date Reactivation Date Cancellation Date Community Description Value of the Disable Activation and/or Deactivation Fee(s) field (see page 292). Value of the Creation Date field (see page 293). Value of the Suspension Date field (see page 294). Value of the Reactivation Date field (see page 294). Value of the Cancellation Date field (see page 294). Value of the Customer Community field (see page 293).
Figure 375 - Customer GUI - Fees tab
Table 281 - Customer - Fees tab Parameter Description
The Fees tab of the Customer GUI is a read-only interface allowing to check all the Scheduled Events existing for all the Subscriptions of the current Customer. Each field corresponds to a parameter of the Scheduled Customer Event object.
For a complete description, see 10.5, Scheduled Event Objects, on page 305. Value of the Customer Subscription* field (see page 309). Value of the Service Name* field (see page 308). Value of the Status field (see page 310). Value of the Error on Fee field (see page 311). Value of the # Execution field (see page 312). Value of the Last Cost field (see page 312).
Service Offer Group Service Status Error # Executions Last Cost
Page 898 of 968
11 September 2009
Table 281 - Customer - Fees tab Parameter First Occurrence Date Last Occurrence Date Next Occurrence Date Synchronization Date Community Description Value of the First Fee Date field (see page 311). Value of the Last Fee Date field (see page 311). Value of the Next Fee Date field (see page 312). Value of the Synchronisation Date field (see page 312). Value of the Customer Community* field (see page 308).
Figure 376 - Customer GUI - Commercial Offer History tab
Table 282 - Customer - Commercial Offer History tab Parameter From Description Start date of the period in which this specific Commercial Offer was the default one of the current Customer. Format: Date and time, i.e. DD/MM/YYYY hh:mm:ss. To End date of the period in which this specific Commercial Offer was the default one of the current Customer. Format: Date and time, i.e. DD/MM/YYYY hh:mm:ss. Commercial Offer Commercial Offer that was the default one of the current Customer during the specified period.
See parameter Commercial Offer (default), page 889.

Delete History The Delete History button allows cleaning out the Commercial Offer History of the current Customer.
11 September 2009
Page 899 of 968
27.1.3. How to Cleanly Remove a Customer: the Purge Customer Command

The customer can be linked to the following objects: Customer Account Customer Subscription Scheduled Customer Event Commercial Offer Link Partner Contract Customer Association
How to launch the Purge Customer command?

Step 1: Open the command line interface of the station where the CRE is installed. Step 2: Type toc <login> <password> <network host>. When you are logged in, the prompt TOC> is displayed. Step 3: Type the following command.
<service>.client.purge,ASERVRET=<service retailer>,CLT_ID=<client identifier>

where ASERVRET represents the name of the service retailer and CLT_ID represents the client identifier. e.g. TOC>creactor.client.purge,aservret="ARinchen",clt_id="cl_10002"; creactor.client.purge="0",RETURNCOMMENT="CUSTOMER PURGE SUCCESSFUL";
Error Cases
The customer purge command does not remove customer associations. Before running the command, the operator must manually remove the customer associations (via the GUI) involved with the current customer who will be purged. The following ERROR message may come TOC>creactor.client.purge,aservret="ARinchen",clt_id="cl_10002"; creactor.client.purge="1",RETURNCOMMENT="CUSTOMER PURGE FAILED- DELETE CUSTOMER ASSOCIATION FIRST";
Event Data Record of a Purge Customer operation

No EDRs are generated by the purge customer operation. Only a command log "creactor.client.purge" is sent to pfmcmdlog.
27.1.4. Commercial Offer History

The default Commercial Offer of a given Customer may change along time, for many reasons. Some events are not processed in real-time by the Convergent Rating Engine. Typically, these can be events of a postpaid service, or events submitted by an non-real-time external module like in case of
Page 900 of 968
11 September 2009
roaming. When processing events a posteriori, it is important to know what Commercial Offer was the default one of the Customer at the time of the event. So the Commercial Offer History feature of the Convergent Rating Engine offers two main advantages: 1. 2. It allows the processing of non-real-time events, in compliance with the effective default Commercial Offer of the Customer at the time of the event. It shows the last five changes of default Commercial Offer in the Customer GUI. This display functionality always works, whether the feature is explicitly activated or not.
Limitations of the Commercial Offer History feature

It is only available for Customers (not for Accounts). It is limited to the last five changes. It must be activated in the RE Configuration, at the time of installation or afterwards. See Customer Subscription History Enabled, on page 95.
See also 10.4.4.6, Subscription History, on page 304.
27.2. Customer Account object


The Customer Account object links an Account to a Customer and assigns that Account a generic name that can be referenced in the leaves of the Charging Rules. A Charging Rule is part of a Service Offer, within the Product Catalog. It must then be generic, and not dedicated to only one Customer. So a Charging Rule, when specifying on which Account an event has to be charged, mustnt directly provide an Account reference. Otherwise, there would be as many Charging Rules as Customers! The Customer Account object plays that intermediary role between the particular Customers and the particular Accounts, making the link between them usable in a generic Product Catalog. A Customer can be linked to as many Accounts as wanted, but of course each Account of one Customer must be named differently, or differentiated by the Community in which it is valid. For instance, you can have two Customer Accounts called MyPrepaid, only if one MyPrepaid is your valid Account in the Community MyCompany and the other MyPrepaid is your valid Account in the Community MyFamily. For a given Customer, a Customer Account is valid within a specific Community. For more details, see parameter Community, page 903.
11 September 2009
Page 901 of 968
Figure 377 - Customer Account GUI
Table 283 - Customer Account - clientac Parameter Service Retailer*

aservret
Description
Reference to the Service Retailer defining the current Customer Account.
Customer Account Name*

name
Name of the current Customer Account. This generic name is the one that will be referenced in the Customer Account Leaves of the Charging Rules valid for all the Customers subscribing to them via the Product Catalog. Reference to the Customer owning the Account defined below.
Customer*
clt_ref
Page 902 of 968
11 September 2009
Table 283 - Customer Account - clientac Parameter Community

commun_r
Description Reference to the Community for which the current Customer Account is valid. Concretely, for identifying an Account via the Customer Account provided by the leaf of a Charging Rule, 2 conditions must be fulfilled: 1. The Customer must have a Customer Account with the same name as the one provided by the Customer Account Leaf; 2. That Customer Account must be defined for the Community which the Commercial Offer of is used (the one that the Charging Rule of has provided a Customer Account).
Impact on the Provisioning
When a Customer registers to a new Community, if he wants his Account(s) to be identifiable via the Charging Rules of that Communitys Commercial Offer, he will have to provision new Customer Account instances, for those Accounts, in the context of the new Community.
Default Commercial Offer of the Customer
A Customer can be part of no Community. In that case, the Community attribute of the Customer Account doesnt make sense and should not be filled in.
A Customer belonging to one or more Communities can also have a Default Commercial Offer, in which he refers to his Accounts regardless of any Community. In that case, there can be Customer Accounts without Community attribute. These Customer Accounts will be used when the Commercial Offer used is the Default Commercial Offer of the Customer. Account*
ppm_id
Identifier of the Account which the generic name of is defined by the current Customer Account object.
11 September 2009
Page 903 of 968
Communities of Customers
28. Communities of Customers

28.1. Community object
A Community is a group of Customers structured as a hierarchy, with a top, a bottom and any number of levels in-between. For instance, a Community can be a Family (including the parents and the children The purpose of this hierarchy is the guiding of charges. Indeed, within a Community, upper Customers can specify the cases in which they agree to be charged for lower Customers, via their Charging Rule. For more information, please see chapter 8., "Guiding Rules", on page 254. The hierarchical links between Customers, building the Community, are defined in the Customer Association object.
Figure 378 - Community GUI
Table 284 - Community - comunity Parameter Service Retailer*

aservret
Description Reference to the Service Retailer defining the current Community.
Community Name*
name
Name of the current Community. The Community Name is referenced in the Customer Association object.
28.2. Customer Association object

The Customer Association object creates a vertical link, between a Customer and another Customer, inside a Community. Conceptually, the Customer Association represents the explicit affiliation of a Customer to a Community.
Page 904 of 968
11 September 2009
Youll notice that a Customer cannot just register to a Community: his affiliation can only be performed via a hierarchical link to another Customer, who already belongs to the Community. The insertion of a Customer into a Community is then a co-optation process rather than a registration: the Customer must be admitted to the Community by at least one of the members of the Community. This makes sense, since the purpose of belonging to a Community is the guiding of charges to the upper Customers. The Customer Association is the point by which a Customer is attached to a Community. A Customer can actually have more than one attach point to a given Community.
Figure 379 - Customer Association GUI
Table 285 - Customer Association - clientas Parameter Service Retailer*

aservret
Description Reference to the Service Retailer defining the current Customer Association.
Customer*
clt_ref
Reference to the Customer who is inserted into the Community via the current Association, linking him to the Upper Customer. Conceptually, the Customer is affiliated, admitted, in the Community thanks to the current Customer Association to an Upper Customer.
11 September 2009
Page 905 of 968
Table 285 - Customer Association - clientas Parameter Weight*

weight
Description Weight of the current Customer Association. The Weights value can range from 1 to 255. Role of Customer Associations Weight The Weight of a Customer Association is used for determining the priority order between the various Associations of a Customer in the Guiding of Charges step. Indeed, when a Customer belongs to at least one Community, the logic applied by the Community Engine for identifying the Account to be charged is to attempt charging another Customers Account, and then the calling Customers Account as a last resort. When the Customer belongs to more than one Community or is attached to a single Community via more than one Customer Association, the Community Engine must know in which order the various hierarchies of the Customer have to be explored. The first hierarchy explored is the one built upon the Customer Association with the lowest Weight. And so on across all the hierarchies, according the increasing order of the Customer Associations Weight. Weight Value Range
The Weight of a Customer Association can be any value between 1 and 255. The reason why the range is that wide is not to allow Customers to have up to 255 Associations - a Customer can anyway belong to maximum 5 Communities. Such a wide range allows modifying the relative order of a Customers Associations without having to modify the Weight of each Customer Association.
For more information on the role of the Customer Associations weight and the
order in which Communities are considered, please see section 8.2, "Commercial Offer Application Order", on page 254.
Customer Association Name*

name
Name of the current Customer Association.
Upper Customer*
nxcltref
Reference to the Customer holding a hierarchical position with respect to the (lower) Customer mentioned above. Conceptually, the Upper Customer affiliates the (lower) Customer to the Community via the current Customer Association.
Community*
commun_r
Reference to the Community in which the current Customer is affiliated, thanks to the current Association with the Upper Customer. Reference to the Customer Association Type specifying the status of the current Customer within the Community. This parameter is not used in the current version of the Convergent Rating Engine.
Association Type
asstyp_r
Type of Customer Association

cas_type
Page 906 of 968
11 September 2009
28.3. Association Type object

For an explanation of Association Types, see 12.3.2.2, Understanding the Association Type Criterion, on page 384.
Figure 380 - Association Type GUI
Table 286 - Association Type - asstype Parameter Service Retailer*

aservret
Description Reference to the Service Retailer defining the current Association Type.
Name*
name
Name of the current Association Type. This parameter is referenced in the Customer Association object as well as in the Association Type criterion.
11 September 2009
Page 907 of 968
Page 908 of 968
11 September 2009
29. Revenue Sharing
In a Nutshell When several actors are involved in the service provided to the Customer, the cost paid by the Customer is a revenue that all the actors have to benefit from, according to an agreement of theirs. The transaction for sharing that revenue is totally transparent for the end-Customer, which only perceives the single cost of his event, charged on his account.
The actors of the Revenue Sharing scheme are all Customers within the Convergent Rating Engine. Via a contract with the Service Retailer, such Customers become Partners. Partners can be remunerated or taxed (credited or debited) in function of the events performed by all the Customers on a given Service. The revenue sharing functionality is handled in real-time by the Convergent Rating Engine.
29.1. Feature Description

29.1.1. Types of Actors
There are typically four types of actors that can be involved in revenue sharing schemes, whereas the list below is not exhaustive. 1) the Network Operator Owner of the network on which the events are transported. Inside the Convergent Rating Engine, a network operator is typically a Service Retailer (the main one). 3. the Service Provider Rents the network to a Network Operator and provides Services on that network to the Customers, which he manages in his own Customer database. The Network Provider and the Service Provider can actually be one single actor. Inside the Convergent Rating Engine, the Service Provider is typically a Service Retailer.
11 September 2009
Page 909 of 968
Revenue Sharing
4.
the Content Provider Provides pure content to a Service Provider, but doesnt provide Services as such to endCustomers.
5.
the Reseller Sells scratch cards for top-up under his own brand, but doesnt provide any network service and hence doesnt own a Customer database.
6.
other types of partners that could be identified: Aggregators, portal editors, intermediaries,...
Some typical cases in which these actors have to share the revenues are: The Service Provider must remunerate the Network Operator for the revenues generated by his Services, on the rented network. This is what is typically named Revenue Sharing. The Service Provider must remunerate the Content Provider providing the information / material allowing to offer the Service to the end-Customer. This is what is typically named Settlement. In both cases, an actor must remunerate another actor who somehow enabled him to generate revenue through the network and the Services offered to the Customers.
29.1.2. Implementation of Revenue Sharing Schemes

Any actor who participates in a revenue sharing scheme - being either a debtor or a creditor - is defined as a Customer of a particular Service Retailer. Like any Customer, they can own one or several Accounts. A Customer involved in a revenue sharing scheme has a Partner Contract with the Service Retailer. The Partner Contract specifies 1. the cases in which the revenue sharing scheme applies: What Service does the Customer participate in the delivery of? In other words, what is the Service which the revenues of have to be shared with/by the Customer? 2. the type of settlement transaction to be done: Is the Customer remunerated or is he/she a payer in the context of this revenue sharing scheme? 3. the way of determining the settlement amount: Is the settled amount a fixed amount? Or is it somehow a function of the usage (and hence, generated revenue) of the Service that the Partner Customer participates in delivering? When a usual Customer performs a usage event of any Service, the Convergent Rating Engine detects whether one or more Partner Contracts exist for that Service. If it is the case, it basically means that the revenue generated by the usage event will have to be shared afterwards, according to the settlement agreements defined by the Partner Contract(s). The initial event is processed as usual. When it is finished, the Convergent Rating Engine is auto-triggered by a new event - a Settlement event. There is one Settlement event per existing Partner Contract. All those settlement events ensure the realization of the revenue sharing scheme for the initial Service delivered.
Page 910 of 968
11 September 2009
29.1.2.1. Terminology Clarification

From here on, when speaking about Settlement, lets distinguish End-Customer and Partner (Customer) End-Customer: Usual Customer, performing usage events on Services like Voice, SMS, Video, etc. Partner or Partner Customer: Particular Customer, owning one or more Partner Contracts with the Service Retailer, in order to participate in revenue sharing schemes. Initial event and Settlement event Initial event: Normal usage event, performed by an end-Customer, on a Service for which one or more Partner Contracts exist. Settlement event: Event generated by the CRE, after an initial event. A Settlement event impacts (credits or debits) the Account of a Partner Customer, for performing the settlement operation defined in the Partner Contract for the Service triggered by the initial event.
29.1.2.2. Example
A Weather_Forecast service is part of the Service Retailers Product Catalog. For delivering that service, the Service Retailer uses the content from Weather Worldwide Inc., acting then as a content provider. Each time that an event is performed on the Weather_Forecast service, Worldwide Weather Inc. must be remunerated as follows: their account must be receive an amount equal to 5% of the initial events cost.
Initial events processing

An end-Customer Tom Schmidt performs an event on the Weather_Forecast Service. This is a usage event, charged 0.50 EUR on his main balance. When identifying the Weather_Forecast Service, the Convergent rating Engine also detects that a Partner Contract exists for that Service, with a Partner Customer called Worldwide Weather Inc.
Settlement events processing

At the end of Tom Schmidts event on Weather_Forecast, the Convergent Rating Engine launches a new event: a Settlement event. The target Customer of that event is the Partner: Worldwide Weather Inc. In the Partner Contract, the Settlement operation is defined as a credit, so the event is sent to the appropriate connector: credupdreq. In the trigger message, the Convergent Rating Engine must also send the amount to be added to the Partners Account: it computes 5% of the initial events cost (so 0.025 EUR). The event sent to the credupdreq connector is processed like any event: the Account of the Customer Worldwide Weather Inc. is identified, and its credit is topped-up with the amount computed on the basis of the initial events cost. (+0.025 EUR). Since the Settlement event is launched immediately after the initial event, the Partners Account is updated in real-time. For more details, see 29.3, Event Flows, on page 913.
11 September 2009
Page 911 of 968
Revenue Sharing
29.1.3. Advantages of the Integrated Revenue Sharing Scheme

For all actors, the stakes of a Revenue Sharing scheme are the following: Control of revenues Each party, i.e. the remunerator and the remunerated actors, must be able to have a clear view of all the events that generated revenue sharing. It is made possible by the specific events triggering the Settlement Service, generated by the Convergent Rating Engine and tracked by the Storage Engine. Real-time status of the generated revenues A status of the generated revenues/debts must be available for the actors for financial reporting and financial budgeting purposes. Management of the revenue sharing The operational management of the revenues must be done automatically, instead of manually a posteriori.
29.2. Determining the Settlement Amount

Via the Settlement event, a particular amount will be either debited or credited. For any of these two transactions, there are four possible means for determining the settlement amount.
29.2.1. Fixed Amount

The simplest way of determining the settlement amount is to set it as a fixed value in the Partner Contract. When making up the trigger message of the Settlement event, the Community Engine uses the value specified in the Partner Contract for filling in the parameter net_evt.bill_qty (in case or debit) or net_evt.credupred (in case of credit). So each time that an initial usage event is performed, the Partners Account is credited or debited by that fixed settlement amount.
29.2.2. Percentage of the initial events cost

It is possible to implement a linear split of the revenue generated by the initial event. In such a case, the cost of the initial event is a pie to be divided into parts. The Partner Contract can define the settlement amount as a fixed percentage of the initial events cost. For making up the trigger message of the Settlement event, the Community Engine uses a parameter of the last response message of the initial event: bill_qty.totcred. This parameter represents the total cost of the event on the main balance; amounts charged on Bundles are not taken into account. The Community Engine then computes the percentage of bill_qty.totcred, as specified in the Partner Contract. This settlement amount is then inserted in the trigger message of the Settlement event, in the parameter net_evt.bill_qty (in case of debit) or net_evt.credupdreq (in case of debit). So each time that an initial usage event is performed, the Partners Account is credited or debited by an amount equal to x% of the cost paid by the end-Customer for his/her event.
Page 912 of 968
11 September 2009
29.2.3. About VAT

In the initial events cost
Two Settlement Types are based on the initial events cost: the percentage of the cost and the Service Offer which the Tariff of rates the cost of the initial event to compute the settlement amount. In those two cases, the initial events cost is the value of bill_qty.totcred, which includes the VAT (if any VAT is applied of course).
In the settlement amount

When the settlement amount is a fixed amount or a percentage of the initial events cost, it is up to the Partner Contract to specify whether the VAT should be included in it or not. When the settlement amount is a translation of the initial events cost or quantities, the handling of VAT is managed by the Tariff performing the quantity-to-cost translation that determines the settlement amount. Note that whatever the status of the VAT in the settlement event, the EDR produced for it will mention the VAT-inclusive amount and the VAT-exclusive amount. See section 29.3.4, "Event Data Records of the Settlement Events", on page 915.
Reminder
When the VAT is specified as excluded (either in the Partner Contract or in the Tariff), then the amount is a VAT-exclusive amount. A General Ledger Code providing the VAT rate to be applied (later on, by any other module or application) can be specified, but it is optional. When the VAT is specified as included (either in the Partner Contract or in the Tariff), then the amount is a VAT-inclusive amount. The General Ledger Code providing the VAT rate applied is then a mandatory parameter (of the Tariff or of the Partner Contract). The VAT-exclusive amount can be retrieved by decomposing the VAT-inclusive amount:
VAT-inclusive amount VAT-exclusive amount = ------------------------------------------------------------------- 100 100 + VAT rate
29.3. Event Flows

Any Settlement transaction is always the result, in terms of logic, of an initial event. An initial event is any usage event performed on a Service for which one or several Partner Contract(s) exist(s). When processing an event on a Service for which Partner Contracts exist, the Convergent Rating Engine detects that it will have to trigger itself afterwards with as many Settlement events as there are Partner Contracts.
11 September 2009
Page 913 of 968
Revenue Sharing
The connector to which the Settlement events are sent depends on whether the transaction type is Debit of Credit Table 287 - Connectors triggered for Settlement Events Transaction Type is Credit credupdreq connector is Debit direct debit connector
29.3.1. When Transaction Type is Debit

At the end of the initial events processing, the Community Engine detects that some Settlement event must be launched. The settlement amount is known already or the percentage of the initial events cost is computed. The settlement trigger message can then be sent to the direct debit connector. When triggered via the direct debit connector, the Rating Engine doesnt perform any rating of the event; it just charges the cost provided in the trigger message on the target Account. At the end of the settlement event, an Event Data Record is sent to the External Module.
oneshot or endcall request
normal processing oneshot or endcall response message
EDR sent
Settlement Event
EDR sent
Legend
= event happening
Page 914 of 968
11 September 2009
RTxx
Initial Event
CE
RE
29.3.2. When Transaction Type is Credit

At the end of the initial events processing, the Community Engine detects that some Settlement event must be launched. The settlement amount is known already or the percentage of the initial events cost is computed. The settlement trigger message can then be sent to the credupdreq connector. When triggered via the credupdreq connector, the Rating Engine adds the amount provided in the interface message to the target Account. At the end of the settlement event, an Event Data Record is sent to the External Module.
29.3.3. Network Event Type of the Settlement Events

Like any trigger message, the settlement request built up by the Convergent Rating Engine ate the end of the initial event must include a Network Event Type. What is the Network Event Type of a settlement event? The Convergent Rating Engine fills in the parameter with the same Network Event Type as the initial event. Actually, this Network Event Type doesnt matter, since no Service needs to be identified. Indeed, the Settlement event is either a credit update or a direct debit, which require no Product Catalog information: the amount to be credited to or debited from the Account is already provided in the request message.
29.3.4. Event Data Records of the Settlement Events

The Convergent Rating Engine produces an EDR for the initial event. This is a normal statistical ticket, like for any usage event.
Link between initial events EDR and settlement events EDRs

After the initial event, the settlement events are processed one by one. At the end of each settlement event, an EDR is produced. This EDR contains the same correlation ID as the one of the initial events EDR. Thanks to the correlation ID, the initial event that led to a particular settlement event can easily be retrieved. In the settlement events EDR, the values of the calldate and calltime parameters are the of the initial event.
Settlement-specific statistical info

The Settlement events EDR contains a sub-EDR, with all the settlement-specific info. Indeed, since the settlement logic uses the usual connectors for charging and for credit update, the statistical tickets produced for settlement events basically look like the tickets of usual usage events. Some dedicated statistical events constitute the sub-EDR, which is then embedded in the usual EDR. These dedicated events provide info on the initial event, on the Partner Contract and on the settlement operation itself. Table 288 - Settlement sub-EDRs dedicated statistical events Statistical Event 117.10.1.1 Meaning or Content Start settlement info (start of the sub-EDR).
11 September 2009
Page 915 of 968
Revenue Sharing
Table 288 - Settlement sub-EDRs dedicated statistical events Statistical Event 117.10.1.2 117.10.2.1 117.10.2.2 117.10.2.3 117.10.2.4 117.10.2.5 117.10.2.6 117.10.2.7 117.10.2.8 117.10.2.9 117.10.2.10 117.10.2.11 117.10.2.12 100.9.1.1 100.9.1.2 Meaning or Content End settlement info (end of the sub-EDR). Name of the Partner Contract. Initial events Service. Service Retailer. Customer. Settlement Service. General Ledger Code. Transaction Type. Settlement Type. VAT amount. VAT flag VAT-exclusive amount. VAT-inclusive amount. Result code. Sub-result code.
For more details, see the Convergent Rating Engines Event Data Record Description.
29.3.5. Multi-level Settlement

The multi-level settlement allows performing settlement on settlement events. This recursiveness can be implemented when the Settlement is defined by a Service. There is no limitation to the number of recursive settlements. The Convergent Rating Engine prevents potential loops in recursive settlement services by performing checks at provisioning via the GUI. So it is impossible to create a Service 1, performing settlement via Service 2, performing settlement via Service 3, performing settlement via Service 1. t
ent em l t t Se
Service 1
Set tlem ent
IMPOSSIBLE
Service 3
Settlement
Service 2
Page 916 of 968
11 September 2009
Example
The Service Retailer offers a Video Service to the Customers. The video content provider has a Partner Contract with the Service Retailer: this agreements specifies that for each Video event performed by the end-users, the content provider will be remunerated in function of the downloaded Kilo Bytes. On the other hand, the content provider will also have to pay a small amount each time that the Settlement amount is above a given value; therefore, the content provider has a second Partner Contract with the Service Retailer.
Call Flow
1. Initial event - An initial event on Service Video is performed by a given Customer. While processing it, the Community Engine detects that this Service requires 3rd party Settlement, because a Partner Contract exists for it. This Partner Contract defines the Settlement Type via a Service (based on the initial events quantities), called Video_Settlement. The corresponding Service Offer contains a Tariff with a non-linear curve, translating the used Kilo Bytes of the initial event into a cost. 2. Settlement event - So after the initial event on Service Video, a Settlement event is launched, triggering the CRE on Service Video_Settlement. By this event, the content providers Account is credited with the amount computed thanks to the Tariff. And again, a Partner Contract exists for Service Video_Settlement. This Partner Contract defines the Settlement Type via a Service (based on the initial events cost), called Video_Partnership. The corresponding Service Offer contains a Tariff with a linear curve, translating the amount received by the content provider into a cost. 3. Recursive Settlement Event - A settlement event is launched, triggering the CRE on Service Video_Partnership. By this event, the content providers Account is debited by the amount computed thanks to the Tariff.
29.4. Partner Contract Object

The Partner Contract is the object that makes a Customer be a Partner. Via the Partner Contract, a Customer asks to be triggered by a Settlement event after each usage event of a given Service. Whatever the type of Settlement operation performed, only the main balance of the Partners Account will be impacted. It is not possible to make Settlement on Bundles. The Contract can specify either a fixed settlement amount, or the way to compute it.
11 September 2009
Page 917 of 968
Revenue Sharing
Figure 381 - Partner Contract GUI V2.0.4
Table 289 - Partner Contract - setlemnt Parameter Service Retailer*

servret
Description Reference to the Service Retailer owning the current Partner Contract.
Partner Contract Name*

name
Name of the current Partner Contract.
Page 918 of 968
11 September 2009
Table 289 - Partner Contract - setlemnt Parameter Service*

serv_ri
Description Reference to the Service for which the current Partner Contract is valid. So for any initial event performed on this Service, the Settlement transaction defined by the current Partner Contract will be executed. This is the Service triggered by the initial event. The initial event is always a Usage event, i.e. triggering the CRE on a Usage Service Offer. So every time that a Usage Service Offer of this Service is triggered, the current Partner Contract is identified and once the initial event is over, a settlement event is generated for triggering the Community Engine. There is one settlement event per Partner Customer registered under the current Partner Contract.
Partner Customer*
clt_ref
Reference to the name of the Customer who becomes a Settlement partner of the Service Retailer, thanks to the current Partner Contract. This is a normal Customer, with either a single Account (his/her Default Account), or several Customer Accounts, among which a Charging Rule can make the selection. This Customer becomes a partner by registering to the current Partner Contract. After each usage event performed on the Service mentioned above, a Settlement event will be generated for performing the Settlement transaction defined below.
Transaction Type
transtyp
Type of the Settlement transaction defined by the current Partner Contract. Only the main Balance of the Account is impacted. Debit (transtyp=0) The Partner Customers Account is taxed: a certain amount of money is removed from its main Balance. Credit (transtyp=1) The Partner Customers Account is remunerated: a certain amount of money is added to its main Balance.
Pay attention to the Account Profile
The Account Profile of the Partners Account might prevent some settlement events to be processed. For making sure that your Account Profile definition doesnt harm your revenue sharing scheme, see section 29.4.3, "Settlement Accounts: Account Profile Implications", on page 922.
11 September 2009
Page 919 of 968
Revenue Sharing
Table 289 - Partner Contract - setlemnt Parameter Settlement Type

setletyp
Description The Settlement Type specifies how the amount of the settlement impacting the Partners Account is defined. There are 4 possible Settlement Types: Fixed Amount (setletyp=0) The amount settled is a constant, whatever the actual cost or quantities of the initial usage event. If you select this Settlement Type, you have to provide the actual amount in the Amount field that appears below. Percentage of the Initial Events Cost (setletyp=1) The amount settled is a percentage of the total cost of the initial usage event. Only the cost on the main balance matters here. Units taken out of Bundles are not taken into account for the settlement operation. If you select this Settlement Type, you have to provide the actual percentage in the Percentage field that appears below. Service Offer based on the Initial Events Quantity (setletyp=2) This settlement type is not available. Service Offer based on the Initial Events Cost (setletyp=3) This settelemnt type is not available.
Amount
quantity
When Settlement Type is Fixed Amount
Amount of the Settlement operation to be done on the Partner Customers Account. Percentage
quantity
When Settlement Type is Percentage of the Initial Events Cost
Percentage of the initial events cost that has to be used for the Settlement operation on the Partner Customers Account.
Page 920 of 968
11 September 2009
Table 289 - Partner Contract - setlemnt Parameter Settlement Service

settserv
Description
When Settlement Type is Service based on Quantity or Cost.
Reference to the name of the service that an event of must trigger the CRE after the intial event.
The Customer Partner must have in his/her portfolio an active Service Offer for this Service. That Service Offer will provide the Tariff alowing to convert the quantities or the cost of the initial event into a settlement amount, for debiting or crediting the Partner Customers Account. Note: When the settlement is a Service, then ofcourse a complete Product Catalog configuration is required for making that service accessable to customers. See section chapter 29.4.4, "Settlement defined as a Service: Implications", on page 922 VAT
vat_flg
The VAT option indicates whether the amount of the Settlement transaction includes the VAT or not. VAT Included (vat_flg=0) VAT Excluded (vat_flg=1) If the VAT is included, the General Ledger Code (see below) is mandatory. If the VAT is excluded, the General Ledger Code (see below) is optional.
Not available for Settlement Type Service You can see in the GUI that the VAT option is not offered when you select the Settlement Type Service (based on the initial events cost or quantities). Indeed, in these cases, the settlement amount is determined by a Tariff. And yet, the Tariff handles the VAT issues.
General Ledger Code

glcode
Reference to the General Ledger Code defining the current settlement operations VAT. This parameter is mandatory if the VAT is included in the amount settled (see above). Depending on the General Ledger Code instance referenced here, the VAT is either a fixed amount or a percentage rate.
11 September 2009
Page 921 of 968
Revenue Sharing
29.4.3. Settlement Accounts: Account Profile Implications

The settlement operations are done on the Accounts of the Partner Customers. In most cases of revenue sharing schemes, whether crediting or debiting the Partners, the Service Retailer doesnt want to apply any Account-dependent limitation to the settlement transactions performed. Therefore, a particular Account Profile is likely to be needed for the Accounts of the Partner Customers. Typically, those Accounts would be Postpaid Accounts. At a glance, here are two major parameters of the Account Profile, relevant in any case: Maximum Credit Allowed (servclas.maxcred) if >=0, then no limit is applied to the debit operations. Minimum Credit Allowed (servclas.mincred) if ==0, then no limit applies to the credit operations. With those settings, no settlement event can be blocked because of limits on the main balance of the Partners Account. Of course, you should also pay attention to the life cycles definition, etc.
See Account Profile object: parameter Maximum Credit Allowed, page 711 and parameter Minimum Credit Allowed, page 715.
29.4.4. Settlement defined as a Service : Implications

When the Settlement is defined as a Service, the usual conditions for making it accessible to Customers are still valid. First of all, the appropriate offer(s) must be created in the Product Catalog, for making the rating operation possible. Secondly, the Customers portfolio must comply with the triggered Service in order for the Customer to be authorized by the Convergent Rating Engine.

See chapter 9., "Catalog Structure", on page 259. See chapter 10., "Users Portfolio", on page 285.
29.4.4.1. Provisioning
The steps listed below describe the necessary settings for enabling the use of a Settlement Service in a Partner Contract. Step 1: You want the Settlement to be a Service. So the corresponding instance of the Service object must be created. From then on, a Service Offer can be created for it in the Product Catalog like for any Service. Step 2: The Settlement Service must be integrated in the Product Catalog, in order to eventually be part of a Commercial Offer. You must then configure all the Product Catalog levels: Commercial Offer > Package > Service Offer Group > Service Offer for Settlement Service. Step 3: That Service Offer has a Usage Rating Rule without Bundle Criterion; ending by a Tariff, providing translation of the cost or quantities of the initial event, into a settlement amount; If the settlement in based on the initial events cost, that Tariff can only be singleRUM (money) since there can only be one type of input quantities: the cost.
Page 922 of 968
11 September 2009
If the settlement is based on quantities, that Tariff can be multi-RUMs. The Tariff can rate against as many quantities as in the initial event. Step 4: That Service Offer may also have a Charging Rule, for guiding to one of the Partner Customers Accounts (if he/she has several ones). Step 5: The Partner Customer must have a Service Offer active in his/her portfolio (either default in the Commercial Offer or optional subscribed to) for the Settlement Service mentioned in the Partner Contract.
29.4.4.2. Typical Call Flow

An appropriate provisioning will allow the following typical call flow (for a credit settlement type). Step 1: Initial event At the end of the initial event, the total quantities or the total cost are taken for filling in the parameter net_evt.bill_qty of the next trigger message, which is an Estimate request. Step 2: Estimate request The Estimate request to the Convergent Rating Engine provokes the rating of the quantities (initial events cost or quantities), in order to determine the settlement amount. The Estimate trigger message contains: ID of the Customer ID of his/her default account name of the Settlement Service (as defined in the Partner Contract). Then the CRE proceeds as usual:
1.
2. 3. 4. 5. 6. 7.
Identifies the default Commercial Offer of the Customer.

Within that Commercial Offer, looks for a Service Offer dedicated to the Settlement Service indicated by the Partner Contract. This Service Offer must be either a default Service Offer of the Commercial Offer or an optional one, that the Customer has a Subscription to. In that Service Offer, a Usage Rating Rule is specified. That Usage Rating Rule is translated and hence, a Tariff is found. The Tariff is used for converting the quantities passed in the Estimate request into a cost. That cost is returned to the CRE within the Estimates answer message. That value is the settlement amount.
Step 3: Credit Update request The Convergent Rating Engine re-triggers itself with a credit update request, for adding the settlement amount to the Partners Account.
11 September 2009
Page 923 of 968
Appendix A: List of Figures

Figure 1 - The VAT GUI Frame of Tariff Window.................................................................. 29 Figure 2 - The HELP Button of Service Retailer Parameter............................................... 29 Figure 3 - Main Menu Example ....................................................................................... 30 Figure 4 - Windows Frame Example................................................................................. 35 Figure 5 - Connecting to the OSP 2.4 Management Interface................................................... 41 Figure 6 - Starting Up the OSP 2.4 Management Application ................................................... 41 Figure 7 - The Management Application Is Being Downloaded.................................................. 41 Figure 8 - The Login Window of the Management Application.................................................. 42 Figure 9 - Entering Log-In Information, Using the History or Not .............................................. 42 Figure 10 - Connecting to the Management Application in Order to Work Online ........................... 42 Figure 11 - Connecting to the Management application in Order to Work Offline .......................... 43 Figure 12 - The Management Applications Work Space ......................................................... 43 Figure 13 - The Main Components of the Management Applications Work Space........................... 44 Figure 14 - The Views Panel.......................................................................................... 45 Figure 15 - The Windows Frame ..................................................................................... 46 Figure 16 - Maximizing, Minimizing and Closing a Window that the Windows Frame Shows ............... 46 Figure 17 - The Tasks You Can Perform on the Window that Is Currently Selected in the Windows Frame 47 Figure 18 - PFMLiteSCE As Shown by the Profile View ........................................................... 49 Figure 19 - Locating the Parameters that Have a HELP Button at Their Right End.......................... 55 Figure 20 - Investigating Which Objects Top-Up Profile Object Must or May Use ........................... 56 Figure 21 - Creating an Operator group for Service Retailers .................................................. 57 Figure 22 - sdpprov Operator Group Is Used as a Provider Group by Operator ............................ 60 Figure 23 - Creating a CRE Provider Operator - Locating OPERATOR Menu Entry ........................... 61 Figure 24 - Creating a CRE Provider Operator - The Empty OPERATOR GUI Window........................ 62 Figure 25 - Creating a CRE Provider Operator - Filling In General Tab ...................................... 63 Figure 26 - Creating a CRE Provider Operator - Filling In Service Tab ...................................... 64 Figure 27 - Creating an Operator - Running Create Command ................................................ 65 Figure 28 - Creating a Service Retailer - Logging In as an Operator of the Service Retailer to Create .. 66 Figure 29 - Creating a Service Retailer - ........................................................................... 66 Figure 30 - Creating a Service Retailer - The Empty Service Retailer GUI Window ......................... 67 Figure 31 - RE Configuration GUI - General Tab .................................................................. 69 Figure 32 - RE Configuration GUI - Levels Tab .................................................................... 75 Figure 33 - RE Configuration GUI - Modules Tab .................................................................. 77 Figure 34 - RE Configuration GUI - Connectors Tab .............................................................. 78 Figure 35 - RE Configuration GUI - Statistics Tab ................................................................. 82 Figure 36 - RE Configuration GUI - SEP Groups Tab .............................................................. 85 Figure 37 - RE Configuration GUI - Fees Tab ...................................................................... 87 Figure 38 - RE Configuration GUI - ARENA Tab .................................................................... 89 Figure 39 - RE Configuration GUI - Partition Range Tab ......................................................... 91 Figure 40 - RE Configuration GUI - Advanced Tab ................................................................ 93 Figure 41 - CE Configuration GUI .................................................................................... 97 Figure 42 - CE Configuration GUI - Communication Tab ........................................................ 101 Figure 43 - CE Configuration GUI - Context Tab ................................................................. 104 Figure 44 - CE Configuration GUI - Modules Subtab of LiteSCE Tab........................................... 109 Figure 45 - CE Configuration GUI - Connectors Subtab of Lite SCE Tab ...................................... 110 Figure 46 - CE Configuration GUI - Level Subtab of Lite SCE Tab ............................................. 112 Figure 47 - CE Configuration GUI - ARENA Tab ................................................................... 113 Figure 48 - SE Configuration GUI - Services tab .................................................................. 118 Figure 49 - SE Configuration GUI - General tab .................................................................. 119 Figure 50 - SE Configuration GUI - CRE Load Thresholds Tab .................................................. 122 Figure 51 - SE Configuration GUI - Errors Handling Tab......................................................... 125 Figure 52 - SE Partition GUI - Partition Name Parameter ...................................................... 129 Figure 53 - SE Partition GUI - General Tab ....................................................................... 130
Page 924 of 968
11 September 2009
Figure 54 - SE Partition GUI - Service Tab........................................................................ 134 Figure 55 - SE Partition GUI - SEP Groups Tab ................................................................... 135 Figure 56 - SE Partition GUI - Thresholds Tab ................................................................... 136 Figure 57 - SE Partition GUI - Statistics Tab ..................................................................... 137 Figure 58 - Service Retailer GUI ................................................................................... 139 Figure 59 - Service Retailer GUI - General tab .................................................................. 142 Figure 60 - Service Retailer GUI - ARENA Tab ................................................................... 148 Figure 61 - Service Retailer - Flexibility Tab .................................................................... 149 Figure 62 - Language GUI ........................................................................................... 150 Figure 63 - Calendar GUI ............................................................................................ 151 Figure 64 - Result Code GUI ........................................................................................ 153 Figure 65 - Partition Ranges GUI ................................................................................... 155 Figure 66 - Notification Feature Table GUI ...................................................................... 164 Figure 67 - Reload on main account Notification Type Enabled ............................................ 177 Figure 68 - Out of Call GUI.......................................................................................... 194 Figure 69 - Out of Call GUI - OOC Tab ............................................................................ 195 Figure 70 - Out of Call GUI - Postpaid OOC Tab ................................................................. 196 Figure 71 - Out of Call GUI - Prepaid OOC Tab .................................................................. 197 Figure 72 - Out of Call - Session OOC Tab ........................................................................ 198 Figure 73 - Tariff Tester GUI - EXECUTE Button ................................................................. 200 Figure 74 - Tariff Tester GUI - Drop Down Menu ................................................................ 200 Figure 75 - Tariff Tester GUI ....................................................................................... 201 Figure 76 - Tariff Tester GUI - Config Tab........................................................................ 202 Figure 77 - Tariff Tester GUI - Basic Parameters Tab .......................................................... 205 Figure 78 - Tariff Tester GUI - Quantities Tab................................................................... 208 Figure 79 - Tariff Tester GUI - Zoning Tab ....................................................................... 209 Figure 80 - Tariff Tester GUI - Top Up Tab....................................................................... 211 Figure 81 - Tariff Tester GUI - Result Tab........................................................................ 212 Figure 82 - Tariff Tester GUI - Adv Result Tab .................................................................. 213 Figure 83 - Adv Result Tab Parameter Example ................................................................. 214 Figure 84 - Network Event Type GUI .............................................................................. 220 Figure 85 - Network Event Type GUI - Description tab ......................................................... 222 Figure 86 - Network Event Type GUI - RUM tab ................................................................. 223 Figure 87 - Service Rule GUI ........................................................................................ 226 Figure 88 - Service types, based on the events characteristics.............................................. 229 Figure 89 - Usage Rating Rule GUI ................................................................................. 233 Figure 90 - Service Offer Definition GUI .......................................................................... 235 Figure 91 - Service Offer Definition GUI - Version tab ......................................................... 236 Figure 92 - Service Offer Definition GUI - General tab ......................................................... 236 Figure 93 - Service Offer Definition GUI - Recurrence Info tab ............................................... 240 Figure 94 - Service Offer Definition GUI - Charge Info tab (1) ................................................ 244 Figure 95 - Service Offer Definition GUI - Charge Info tab (2) ................................................ 244 Figure 96 - Service Offer Definition GUI - Top-up Info tab .................................................... 246 Figure 97 - Service Offer Definition GUI - LSCE Info tab ....................................................... 249 Figure 98 - Service Offer Definition GUI - Arena tab ........................................................... 250 Figure 99 - Top-up Rule GUI ........................................................................................ 252 Figure 100 - Charging Rule GUI..................................................................................... 255 Figure 101 - Rating Plan Rule GUI ................................................................................. 257 Figure 102 - Service GUI............................................................................................. 260 Figure 103 - Commercial Offer GUI................................................................................ 262 Figure 104 - Package GUI ........................................................................................... 264 Figure 105 - Service Offer GUI ..................................................................................... 266 Figure 106 - Service Offer Group GUI ............................................................................. 273 Figure 107 - Service Offer Link GUI ............................................................................... 275 Figure 108 - Service Offer Group Link GUI ....................................................................... 277 Figure 109 - Package Link GUI...................................................................................... 279 Figure 110 - Bundle/Counter Usage Label GUI .................................................................. 280
11 September 2009
Page 925 of 968
Figure 111 - Bundle/Counter Usage Label GUI When Type* Is Set to Bundle ................. 281 Figure 112 - Bundle/Counter Usage Label GUI When Type* Is Set to Counter ................ 281 Figure 113 - Commercial Offer Link GUI .......................................................................... 289 Figure 114 - Customer Subscription GUI - main window ........................................................ 291 Figure 115 - Customer Subscription GUI - History tab .......................................................... 294 Figure 116 - Account Subscription GUI ............................................................................ 296 Figure 117 - Subscriptions Life Cycle ............................................................................. 304 Figure 118 - Scheduled Customer Event Object GUI ............................................................ 307 Figure 119 - Scheduled Customer Event Object GUI - General tab ........................................... 308 Figure 120 - Scheduled Customer Event Object - History tab ................................................. 311 Figure 121 - Scheduled Account Event GUI ....................................................................... 313 Figure 122 - Scheduled Event Status Transitions - Successful Execution..................................... 317 Figure 123 - Scheduled Event Status Transitions - Unsuccessful Execution.................................. 318 Figure 124 - Activation Fee - Event status and Subscription state transitions .............................. 319 Figure 125 - Cancellation Fee - Event status and Subscription state transitions ........................... 320 Figure 126 - Cancellation of a suspended Subscription ......................................................... 323 Figure 127 - Versioning GUI Frame ................................................................................. 324 Figure 128 - Versions life cycle: independence of the version statuses definition ........................ 327 Figure 129 - Decision Tree Example ............................................................................... 330 Figure 130 - CRE Main Menu......................................................................................... 333 Figure 131 - Creating a Usage Rating Rule ........................................................................ 334 Figure 132 - ........................................................................................................... 335 Figure 133 - ........................................................................................................... 335 Figure 134 - Graphic Editor Showing an Empty Usage Rating Rule ............................................ 336 Figure 135 - Selecting a Green Solid Square Enables the Critria and Leaves Pamettes.................... 337 Figure 136 - To Know What a Criterion Icon Is About, Move the Mouse Cursor over the Icon ............ 337 Figure 137 - ........................................................................................................... 338 Figure 138 - ........................................................................................................... 339 Figure 139 - ........................................................................................................... 339 Figure 140 - ........................................................................................................... 340 Figure 141 - ........................................................................................................... 340 Figure 142 - ........................................................................................................... 341 Figure 143 - ........................................................................................................... 341 Figure 144 - ........................................................................................................... 342 Figure 145 - ........................................................................................................... 343 Figure 146 - ........................................................................................................... 344 Figure 147 - ........................................................................................................... 344 Figure 148 - ........................................................................................................... 345 Figure 149 - ........................................................................................................... 345 Figure 150 - ........................................................................................................... 346 Figure 151 - ........................................................................................................... 347 Figure 152 - Final Version of URRVoiceUsage. ................................................................... 348 Figure 153 - ........................................................................................................... 349 Figure 154 - ........................................................................................................... 350 Figure 155 - ........................................................................................................... 351 Figure 156 - ........................................................................................................... 352 Figure 157 - ........................................................................................................... 353 Figure 158 - ........................................................................................................... 354 Figure 159 - ........................................................................................................... 355 Figure 160 - The Graphic Editor Is Showing the Decision Tree to Export .................................... 356 Figure 161 - Usage Rating Rule Drop-Down Menu .......................................................... 357 Figure 162 - Sub-menu of Save tree to a file .................................... 357 Figure 163 - Selecting Text (for unconnected mode)............................... 358 Figure 164 - Save tree (unconnected mode) Window ................................................... 358 Figure 165 - File Name Parameter Now Set to ExportedDecisionTree .................. 359 Figure 166 - The File into Which the Decision Tree Has Been Exported ..................................... 359 Figure 167 - The Rules Selector .................................................................................... 360
Page 926 of 968
11 September 2009
Figure 168 - Tools Drop-Down Menu ............................................................................. 361 Figure 169 - Correct setup for Connected ...........................................361 Figure 170 - Incorrect Setup for Connected .........................................362 Figure 171 - Usage Rating Rule Drop-Down Menu ......................................................... 362 Figure 172 - Selecting Load a tree from file .....................................363 Figure 173 - The Load tree (unconnected mode) window ............................................. 363 Figure 174 - Navigating Towards the .utree File to Import.................................................. 364 Figure 175 - The Decision Tree to Import Now Appears in the Graphic Editor ............................. 365 Figure 176 - Click YES to Save the Decision Tree into CREs ORACLE Database ............................ 365 Figure 177 - The Graphic Editor Is Showing the Decision Tree to Export.................................... 366 Figure 178 - Usage Rating Rule Drop-Down Menu ......................................................... 367 Figure 179 - Sub-menu of Save tree to a file ....................................368 Figure 180 - Selecting Text with new root (unconnected) ..........................369 Figure 181 - Save tree (unconnected mode) Window .................................................. 369 Figure 182 - File Name Parameter Now Set to ExportedDecisionTreeWithNewRoot........370 Figure 183 - The Rules Selector by Means of Which You Specify Under Which Name the Tree Will Be Saved into a Text File ............................................................................................... 371 Figure 184 - Specyfying the Name (i.e., the Root) Under Which the Tree Will Be Saved into a Text File 372 Figure 185 - Exporting a Decision Tree Under the New Name Previously Chosen .......................... 373 Figure 186 - The File into Which the Decision Tree Has Been Exported Under a New Name............. 373 Figure 187 - Duplicated Decision Tree Example ................................................................. 374 Figure 188 - ........................................................................................................... 376 Figure 189 - ........................................................................................................... 377 Figure 190 - ........................................................................................................... 377 Figure 191 - ........................................................................................................... 378 Figure 192 - ........................................................................................................... 378 Figure 193 - Association Type Criterion Configuration Panel.................................................. 386 Figure 194 - Bundle Criterion Configuration Panel.............................................................. 390 Figure 195 - Single Run .............................................................................................. 391 Figure 196 - Multi Run ............................................................................................... 392 Figure 197 - Bundle Threshold Criterion Configuration Panel ................................................. 397 Figure 198 - Closed User Group Configuration Window ........................................................ 399 Figure 199 - Counter Criterion ..................................................................................... 402 Figure 200 - Counter Threshold Criterion Configuration Panel ............................................... 408 Figure 201 - Counter Threshold Criterion Configuration Panel When A Constant Is Checked .......... 409 Figure 202 - Counter Threshold Criterion Configuration Panel When Another Counter Is Checked ... 409 Figure 203 - Date Criterion Configuration Panel ................................................................ 413 Figure 204 - Destination Criterion Configuration Panel ........................................................ 415 Figure 205 - Destination Criterion Configuration Panel - when Area is checked ........................... 415 Figure 206 - Destination Criterion - when Area Identifier without Type is checked....................... 416 Figure 207 - Destination Criterion - when Area Identifier with Type is checked........................... 416 Figure 208 - Destination Zone Criterion Configuration Panel ................................................. 418 Figure 209 - Discount Criterion .................................................................................... 421 Figure 210 - Event Type Criterion Configuration Panel ........................................................ 424 Figure 211 - Friends and Family Criterion Configuration Panel ............................................... 426 Figure 212 - Generic Criterion Configuration Panel............................................................. 430 Figure 213 - Grant Criterion Configuration Panel ............................................................... 436 Figure 214 - LiteSCE Criterion Configuration Panel ............................................................. 438 Figure 215 - Main Balance Criterion Configuration Panel ...................................................... 443 Figure 216 - Origin Criterion Configuration Panel............................................................... 445 Figure 217 - Origin Criterion - when Area is checked .......................................................... 445 Figure 218 - Origin Criterion - when Area Identifier without Type is checked ............................. 446 Figure 219 - Origin Criterion - when Area Identifier with Type is checked ................................. 446 Figure 220 - Originating Zone Criterion Configuration Panel .................................................. 450 Figure 221 - Preferred Number Criterion Configuration Panel ................................................ 452 Figure 222 - Promotion Criterion Configuration Panel ......................................................... 455
11 September 2009
Page 927 of 968
Figure 223 - Service Criterion Configuration Panel.............................................................. 457 Figure 224 - Subscription Criterion................................................................................. 459 Figure 225 - Supervision Criterion Configuration Panel......................................................... 463 Figure 226 - Time Criterion Configuration Panel ................................................................ 465 Figure 227 - Matrix Component criterion ......................................................................... 467 Figure 228 - Service Leaf Configuration Window ................................................................ 469 Figure 229 - Forbidden Leaf Configuration Window ............................................................. 471 Figure 230 - Allowed Leaf Configuration Window ............................................................... 472 Figure 231 - Customer Account Leaf Configuration Window ................................................... 473 Figure 232 - Tariff Leaf Configuration Windows ................................................................. 474 Figure 233 - Service Offer Leaf Configuration Window ......................................................... 476 Figure 234 - Usage Rating Rule Reference Leaf Configuration Window ...................................... 477 Figure 235 - Charging Rule Reference Leaf ....................................................................... 478 Figure 236 - Rating Plan Rule Reference Leaf Configuration Window ........................................ 479 Figure 237 - Scheduling Engine within the CRE .................................................................. 484 Figure 238 - Scheduled Event List .................................................................................. 486 Figure 239 - Scheduling Engines Time Progression ............................................................. 489 Figure 240 - Scheduled events EDR: consolidation and sending to External Module ...................... 492 Figure 241 - Scheduling recurring events at the beginning of the cycle ..................................... 504 Figure 242 - Scheduling recurring events at the end of the cycle ............................................ 504 Figure 243 - Examples of Nonlinear Prorata on several Fee Tariff Curves ................................... 510 Figure 244 - Prorata at first occurrence, charge in advance of the cycle ................................... 512 Figure 245 - Prorata at first occurrence, charge in arrears of the cycle..................................... 512 Figure 246 - Prorata at intermediate occurrence, charge in advance of the cycle ........................ 513 Figure 247 - Prorata at intermediate occurrence, charge in arrears of the cycle.......................... 513 Figure 248 - Prorata at last occurrence, charge in advance of the cycle .................................... 514 Figure 249 - Prorata at last occurrence, charge in arrears of the cycle ..................................... 514 Figure 250 - Ratable Unit Metric GUI .............................................................................. 517 Figure 251 - Tariff GUI ............................................................................................... 519 Figure 252 - Tariff GUI - RUM 1 tab ................................................................................ 523 Figure 253 - Tariff GUI - RUM 2 tab ................................................................................ 527 Figure 254 - Tariff GUI - RUM 3 tab ................................................................................ 528 Figure 255 - Example- Virtual Mode A ............................................................................. 530 Figure 256 - Tariff Application Mode A ............................................................................ 531 Figure 257 - Tariff Application Mode B ............................................................................ 531 Figure 258 - General Ledger Code GUI ............................................................................ 541 Figure 259 - Zoning Management Framework data model...................................................... 552 Figure 260 - Area Identifier Type GUI ............................................................................. 554 Figure 261 - Area GUI ................................................................................................ 556 Figure 262 - Area Identifier GUI .................................................................................... 557 Figure 263 - Zoning-based decision tree - without using a Matrix ............................................ 560 Figure 264 - Zoning-based decision tree - using a Matrix....................................................... 562 Figure 265 - Matrix Component GUI................................................................................ 562 Figure 266 - Matrix GUI .............................................................................................. 563 Figure 267 - Zone GUI ................................................................................................ 568 Figure 268 - Zoning Parameters Identification ................................................................... 583 Figure 269 - Grant Tool GUI - Specifying the Quantity to Observe............................................ 594 Figure 270 - Grant Tool GUI - Specifying the Value Ranges .................................................... 596 Figure 271 - Grant Tool GUI - Associating a Credit or No Credit with a Range.............................. 597 Figure 272 - Grant Tool GUI - Specifying How to Compute an Absolute Credit ............................. 599 Figure 273 - Grant Tool GUI - Specifying How to Compute a Percentage Credit ........................... 600 Figure 274 - Grant Tool GUI - What Is Tapered Mode ........................................................... 601 Figure 275 - Grant Tool GUI - What Is Tiered Mode ............................................................. 604 Figure 276 - Grant Tool GUI When Neither Absolute Nor Percentage Radio Buttons Are Checked . 607 Figure 277 - Grant Tool GUI When Absolute Radio Button Is Checked ..................................... 608 Figure 278 - Grant Tool GUI When Percentage Radio Button Is Checked.................................. 609 Figure 279 - Discount GUI - Specifying the Quantity to Observe .............................................. 621
Page 928 of 968
11 September 2009
Figure 280 - Discount GUI - Specifying the Value Ranges ...................................................... 623 Figure 281 - Discount GUI - Specifying How to Compute an Absolute Credit ............................... 626 Figure 282 - Discount GUI - Specifying How to Compute a Percentage Credit ............................. 628 Figure 283 - Discount GUI - Specifying the Value to Reward .................................................. 630 Figure 284 - Grant Tool GUI - What Is Tapered Mode........................................................... 632 Figure 285 - Discount GUI - What Is Tiered Mode ............................................................... 635 Figure 286 - Discount GUI ........................................................................................... 637 Figure 287 - Discount GUI - Perimeters Tab...................................................................... 640 Figure 288 - Application Parameter GUI Frame when Counter Radio Button is Checked......... 641 Figure 289 - Application Parameter GUI Frame when Main Balance Radio Button is Checked 641 Figure 290 - Calculation Parameter GUI Frame when Account Original Attribute Radio Button is Checked ............................................................................................................. 643 Figure 291 - Calculation Parameter GUI Frame when Arena Radio Button is Checked ............ 643 Figure 292 - Calculation Parameter GUI Frame when Counter Radio Button is Checked......... 643 Figure 293 - Discount GUI - Discount Options and Thresholds Tab ........................................... 645 Figure 294 - Discount GUI - View Graph Tab ..................................................................... 649 Figure 295 - Account Discount GUI ................................................................................ 650 Figure 296 - Supervision Criterion GUI ............................................................................ 657 Figure 297 - Promotion Criterion GUI ............................................................................. 658 Figure 298 - Promotion Tool: Specifying to Which Accounts a Promotion applies ......................... 664 Figure 299 - Promotion Tool: Specifying the Container of a Promotions Observed Value ............... 665 Figure 300 - Promotion Tool: The Reward Is a Discount ....................................................... 666 Figure 301 - Promotion Tool: The Reward Is a Credit .......................................................... 666 Figure 302 - Promotion Tool: When the Supervision Periods Are Allowed to Run.......................... 667 Figure 303 - Promotion Tool: Specifying a Supervision Period that Does Not Repeat ..................... 668 Figure 304 - Promotion Tool: Specifying a Supervision Period as a Number of Days ...................... 669 Figure 305 - Promotion Tool: Specifying a Supervision Period as a Number of Weeks .................... 670 Figure 306 - Promotion Tool: Specifying a Supervision Period as a Number of Months ................... 671 Figure 307 - Promotion Tool: Specifying the Value Ranges .................................................... 674 Figure 308 - Promotion Tool: Specifying How the Discount Is Computed ................................... 676 Figure 309 - Promotion Tool: Specifying How the Credit Is Computed ...................................... 678 Figure 310 - Promotion Tool GUI................................................................................... 682 Figure 311 - Promotion Tool GUI - General Tab ................................................................. 683 Figure 312 - Promotion Tool GUI - Supervision Tab ............................................................. 686 Figure 313 - Promotion Tool GUI - Supervision Tab (Supervision Type = Fixed)..................... 686 Figure 314 - Promotion Tool GUI - Supervision Tab (Supervision Type = Day) ........................ 687 Figure 315 - Promotion Tool GUI - Supervision Tab (Supervision Type = Week) ...................... 687 Figure 316 - Promotion Tool GUI - Supervision Tab (Supervision Type = Month)..................... 687 Figure 317 - Promotion Tool GUI - Attribution Tab ............................................................. 691 Figure 318 - Promotion Tool GUI - Attribution Tab (Attribution Type = Oncallprom) ............. 691 Figure 319 - Promotion Tool GUI - Attribution Tab (Attribution Type = Bonus amount).......... 692 Figure 320 - Friends and Family List GUI ......................................................................... 699 Figure 321 - Friends and Family Member Type GUI ............................................................. 700 Figure 322 - Friends and Family Member GUI .................................................................... 702 Figure 323 - Account Profile GUI................................................................................... 706 Figure 324 - Account Profile GUI - General Tab ................................................................. 707 Figure 325 - Account Profile GUI - Charging Tab ................................................................ 721 Figure 326 - Account Profile GUI - Warning Tab................................................................. 731 Figure 327 - Account Profile GUI - Flexibility Tab .............................................................. 739 Figure 328 - Account Profile GUI - Preferred Identifier Tab................................................... 742 Figure 329 - Account Profile GUI - ARENA Tab................................................................... 742 Figure 330 - Account Profile GUI - Generic Counters Tab ..................................................... 743 Figure 331 - Account GUI............................................................................................ 749 Figure 332 - Account GUI - General Tab .......................................................................... 757 Figure 333 - Account GUI - Loyalty Tab........................................................................... 763 Figure 334 - Account GUI - Charging Tab ......................................................................... 769 Figure 335 - Account GUI - ARENA Tab............................................................................ 770
11 September 2009
Page 929 of 968
Figure 336 - Account GUI - Status Tab............................................................................. 771 Figure 337 - Account GUI - Bundle Tab............................................................................ 784 Figure 338 - Account GUI - Counter Tab .......................................................................... 785 Figure 339 - Account GUI - Subscription Tab ..................................................................... 785 Figure 340 - Account GUI - Subscription Tab ..................................................................... 787 Figure 341 - Account GUI - Last 10 Events tab ................................................................... 789 Figure 342 - Objects referencing the Account ................................................................... 795 Figure 343 - Bucket GUI.............................................................................................. 800 Figure 344 - Account Profile and Usage Link GUI ................................................................ 805 Figure 345 - Top-Up Profile GUI .................................................................................... 810 Figure 346 - Top-Up Profile GUI - Top-Up Definition ............................................................ 811 Figure 347 - Top-Up Profile GUI - Main Balance ................................................................. 814 Figure 348 - Top-Up Profile GUI - Top-Up Definition - Bundles................................................ 816 Figure 349 - Operator Deposit: Commercial Offer identificaion process..................................... 827 Figure 350 - Operator Deposit GUI ................................................................................. 827 Figure 351 - Operator Deposit GUI - Top-Up Definition tab .................................................... 829 Figure 352 - Operator Deposit GUI - Main balance tab.......................................................... 830 Figure 353 - Operator Deposit GUI - Bundles tab ................................................................ 831 Figure 354 - Credit Update via Object GUI Vs. via Adjustment Interface.................................... 834 Figure 355 - Balance/Bucket Adjustment GUI.................................................................... 836 Figure 356 - Balance/Bucket Adjustment GUI - Balance tab................................................... 837 Figure 357 - Balance/Bucket Adjustment GUI - Buckets tab ................................................... 839 Figure 358 - Balance/Bucket GUI - Bucket Search tab (1)...................................................... 841 Figure 359 - Balance/Bucket Adjustment GUI - Bucket Search tab (2)....................................... 842 Figure 360 - Bucket Adjustment GUI............................................................................... 843 Figure 361 - Counter GUI ............................................................................................ 853 Figure 362 - ARENA GUI .............................................................................................. 858 Figure 363 - CE Flexibility Point GUI............................................................................... 862 Figure 364 - Flexibility Config GUI ................................................................................. 870 Figure 365 - Flexibility User GUI.................................................................................... 873 Figure 366 - LiteSCE Script Pool GUI ............................................................................... 881 Figure 367 - Customer GUI .......................................................................................... 884 Figure 368 - Customer GUI - Identification tab .................................................................. 887 Figure 369 - Customer GUI - Administrative Info tab............................................................ 892 Figure 370 - Customer GUI - Physical Info tab ................................................................... 894 Figure 371 - Customer GUI - Legal Info tab ....................................................................... 895 Figure 372 - Customer GUI - Zoning tab........................................................................... 896 Figure 373 - Customer GUI - ARENA tab ........................................................................... 896 Figure 374 - Customer GUI - Subscriptions tab ................................................................... 897 Figure 375 - Customer GUI - Fees tab ............................................................................. 898 Figure 376 - Customer GUI - Commercial Offer History tab.................................................... 899 Figure 377 - Customer Account GUI................................................................................ 902 Figure 378 - Community GUI ........................................................................................ 904 Figure 379 - Customer Association GUI ............................................................................ 905 Figure 380 - Association Type GUI.................................................................................. 907 Figure 381 - Partner Contract GUI V2.0.4......................................................................... 918
Page 930 of 968
11 September 2009
Appendix B: Index of Object Parameters

Symbols
(se) config. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118 cename . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119 cpumid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123 cpustop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123 delay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121 errnbret . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127 errtimer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128 essepg . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118 max_empt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121 maxerr . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128 nbretry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126 nbvalday . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122 refresht. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123 rename . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119 schutime . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120 waittime . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
A
accfee . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313 error. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 311 firstdt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 311 identify . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313 lastdt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 311 lcost . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 312 nb_occ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 312 nextdt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 312 service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 308 servret . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 307 status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 310 subri. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 309 syncchdt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 312 areas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 556 aservret . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 556 name . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 556 asstype . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 907 aservret . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 907 name . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 907
B
billrule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255 aservret . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255 cal_ref . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 256 name . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255 version . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 256 vstartd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 256 vstatus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 256
11 September 2009
Page 931 of 968
bundlcol aservret . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . bundlcol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . createdt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . limitdat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ppm_ri . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . startdt. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . usg_ri . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . validity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . valper1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 801 801 801 802 801 802 801 801 803
C
classnam . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 563 aservret . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 563 name. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 563 client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 884 aservret . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 884 ccglist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 886 clt_addr. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 893 clt_cnbr. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 892 clt_conb . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 895 clt_dabi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 894 clt_emai . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 893 clt_fax. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 893 clt_fstn . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 894 clt_gen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 895 clt_id . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 889 clt_idot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 891 clt_lang . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 893 clt_logi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 893 clt_msid. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 891 clt_msta . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 895 clt_name . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 894 clt_nat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 893 clt_pasc . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 894 clt_pasn. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 894 clt_past . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 895 clt_phon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 892 clt_plbi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 894 clt_pwd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 893 clt_rank . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 893 clt_sect . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 895 clt_stat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 887 ctr_hold. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 893 ctr_nbr . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 893 homezone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 896 pchg_ref . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 886 pin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 893 ppm_id . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 890 test_sta . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 885 clientac. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 902
Page 932 of 968
11 September 2009
aservret . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . asstyp_r . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . clt_ref . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . commun_r . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . name . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ppm_id . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
... ... ... ... ... ...
... ... ... ... ... ...
... ... ... ... ... ...
... ... ... ... ... ...
902 906 902 903 902 903
clientas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 905 aservret . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 905 cas_type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 906 clt_ref . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 905 commun_r . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 906 name . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 906 nxcltref. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 906 weight . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 906 cltfee . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 307 commun . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 308 error. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 311 firstdt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 311 identify . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 307 lastdt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 311 lcost . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 312 nb_occ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 312 nextdt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 312 service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 308 servret . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 307 status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 310 subri. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 309 syncchdt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 312 comoffer. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262 aservret . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262 name . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262 servrule. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262 status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263 vers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262 vstartd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263 comoflnk. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 289 aservret . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 289 clt_ref . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 289 coffname. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 290 commu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 290 comunity. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 904 aservret . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 904 name . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 904 contrasr See subsc_ce . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 291 countcol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 853 datper . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 785, 854 ppm_ri . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 853 servret . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 853 usg_ri . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 785, 853
11 September 2009
Page 933 of 968
val . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .785, 854 valper . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .785, 854 crepart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129 acesgnm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135 achost . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135 ceload . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138 cesgflg. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136 lstatus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131 lstnbs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139 maxtup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137 nbevt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139 partnm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129 ptimeout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137 reload . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138 scesgnm. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136 sepnm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134 type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
F
feeplan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235 actdays . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248 daymonth. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242 dayweek . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242 debtype . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245 every . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242 feemode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237 feemoney. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245 feetype . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 238 feevalue . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245 gl_code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246 inacdays . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248 lscepool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249 lscepos0. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249 lscepos1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249 lscepos2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 250 month . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242 name. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235 nocred. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239 notif_id . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239 notifchg . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246 notiftup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248 pertype . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241 pflg. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241 prorata1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243 prorata2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243 refund . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246 servret . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235 stopdate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243 stopocc . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243 stoptype . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243 syncfee . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242
Page 934 of 968
11 September 2009
topprof . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . topref . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . toptype . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . topvalue . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ustree . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . version . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vstartd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vstatus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
247 247 247 247 245 236 236 236
fnfcrite. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 427 ptcnbr . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 427
G
gl_code. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 541 aservret . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 541 gl_code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 541 gl_desc . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 542 glc_name. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 542 tva_flg . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 541 tva_rate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 542 tva_val . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 542
I
id_type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 554 aservret . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 554 id. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 555 name . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 554
L
lscepos2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 250
M
matrix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 564 aservret . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 564 dest_id . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 564 orig_id . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 564 ptr-clna. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 564 version . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 558, 565 vstartd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 558, 565 vstatus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 558, 565
P
package . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264 aservret . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264 name . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264 version . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264 vstartd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264 vstatus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 265
11 September 2009
Page 935 of 968
packlnk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 279 aservret . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 279 coffname . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 279 packref . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 279 version . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 279 vstartd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 279 vstatus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 279 pchgcol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 702 aservret . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 702 id . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 702 pclist. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 702 pctypnbr . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 702 pchglist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 700 pclname . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 700 servret . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 700 pchgtyp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 700 pctname . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 701 pctnbr . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 701 servret . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 700 ppm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 749 accounid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 751 accreddt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 759 activbdt. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 760 activend . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 761 admblk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 771 admexh . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 772 admisl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 773 admnmcr . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 774 admpblk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 776 admpfee . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 776 admscrs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 777 birthday. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 758 card_nbr . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 751 coffdate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 759 coffname . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 750 cyclstat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 762 email . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 758 fflist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 769 firstcal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 779 firstnam. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 758 glbadpwd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 766 glbadrel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 765 identify . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 750 inactend . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 763 info1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 758 info2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 758 lactdon2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 781 lactdone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 781 language . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 757 lcwdone. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 780 lcwdone2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 780
Page 936 of 968
11 September 2009
linactdo2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . linactdon. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . location . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . login. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . lscepool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . lstfeedt. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . lstreldt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . lstrelva . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . lstupcdt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . mn30 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . msid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . msidtype . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . nbbadrel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . novat_f . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . oper_fl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . passwd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . pin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . servclas. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . servret . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . tcblock . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . validbeg . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . validend . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . wlcdone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
782 782 759 758 759 764 764 764 764 757 755 755 765 756 756 759 758 749 749 779 759 760 783
pricetab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 519 cnx_qty0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 524 cnxcost0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 524 cnxtick0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 524 cxcstflg . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 521 foutick0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 526 fst_qty0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 525 fsttick0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 525 gl_code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 520 name . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 520 prdcost0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 524 rat_mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 520 rat_type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 521 rum_nam0 / rum_nam1 / rum_nam2 . . . . . . . . . . . . . . . . . . . . . . . . 523 scd_qty0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 525 scdtick0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 525 seg_qty0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 526 segtick0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 526 servret . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 519 thi_qty0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 525 thitick0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 525 trf_typ0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 524 vat_flg . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 520 vat_rate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 520 version . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 520 vstartd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 520 vstatus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 520
11 September 2009
Page 937 of 968
R
rescode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153 rescode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153 rum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 517 c_kind . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 518 def_qty . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 518 name. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 517 rum_desc . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 518 rum_typ. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 518 servret . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 517 unit. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 518
S
sdpcfg. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .70 sepmodul . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87 septype . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86 subact_f . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96 sdplang . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150 langid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150 mn30. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150 servclas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 706 actcre . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 709 actimean . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 740 actipwa2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 733 activpwa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 732 actnotif . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 737 calldurw . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 735 cncsetup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 739 cnendter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 740 cninterr . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 740 credmean. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 740 cutsess . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 716 cwcsetup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 741 cwincall . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 741 cwoucall . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 741 dactiv . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 717 dinactiv . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 717 dvalid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 718 exhausfl. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 713 fcabegin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 718 fcabonus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 716 fcacend . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 718 feeper . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 722 ff_max. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 722 fnfdeflt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 722 inacmean . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 740 inactpw2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 735 inactpwa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 734 inanotif . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 737 index_id . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 736
Page 938 of 968
11 September 2009
initcred . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . language . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . lcnotif. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . lim_eval . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . lowcred. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . lowcred2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . lowcredn . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . lowcredw . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . lscepool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . macend_d . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . macnb_d . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . maxbadre . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . maxcred . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . mincred . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . mxbadpwd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . name . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . newlang . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . notifk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . prefid00 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . proftype . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . reloadmx. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . rst_glc1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . rst_glc2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . rst_glc3. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . rst_glc4. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . servret . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . snendcal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . tcbonus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . warnmean . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . wlcnotif . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . services . . . . . . aservret desc . . . srvname ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... .... .... .... .... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ...
710 709 738 723 714 713 741 712 740 719 720 724 711 715 729 706 721 738 742 708 724 710 727 710 721 706 739 717 740 739 . . . . . . 260 260 261 261
servret . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140 address . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143 chgdef . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142 chgmax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143 chgmin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142 cprec . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146 crditacs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144 custid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140 disc_mod. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144 helpdesk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144 mgu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147 mngmtacs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145 name . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140 notarrws . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144 rounding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147 scratacs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145 servret . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
11 September 2009
Page 939 of 968
servusag . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 805 aservret . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 805 not_type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 807 notif_id . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 806 servclas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 805 usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 805 usgtype . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 805 warnthr . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 807 setlemnt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 918 clt_ref . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 919 glcode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 921 name. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 918 quantity. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 920 serv_ri. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 919 servret . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 918 setletyp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 920 settserv . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 921 transtyp. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 919 vat_flg. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 921 sroffgrp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273 aservret . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273 barrflg. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274 name. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273 subsrofg. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273 vstartd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274 vstatus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274 srofgrln . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 277 aservret . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 277 mandaflg . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 278 packref . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 277 srofgref . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 277 version . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 278 vstartd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 278 vstatus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 278 srvoffer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266 aservret . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266 bil_ref . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 268 name. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266 plan_ref. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 267 rat_ref . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269 serv_ri. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266 version . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269 vstartd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269 vstatus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269 srvoflnk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275 aservret . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275 srofgref . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275 srofname . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275 version . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275 vstartd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275 vstatus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275
Page 940 of 968
11 September 2009
subsc_ce . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 291 activedt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293 aservret . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 291 clt_ref . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 291 commun_r . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293 credat. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293 csstate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292 feeavail. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292 srvofgpe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 291 stopdat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294 suspdat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294 unsuspdt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294 susbc_ce syncchdt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293
T
tariftst . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201 aasrvret . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201 calldate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208 calltime . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208 calltype. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207 cld . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210 clg . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209 destalgo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210 destmc . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210 desttype . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210 fcallmgt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208 lstdate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212 msgtout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203 origalgo. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210 origmc . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209 origtype . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209 ppmindex . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206 ppmvalue . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207 qt2resv1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209 qt2resv2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209 qt2resv3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209 reqtyp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203 rescode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212 save_flg . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204 tckext . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204 topprof . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211, 215 TBD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101, 105, 113 toprule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252 aservret . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252 cal_ref . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253 name . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252 version . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253 vstartd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253 vstatus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253
11 September 2009
Page 941 of 968
U
usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 281 aservret . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 281 maxroll . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 282 name. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 281 resetflg . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284 shiftflg . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 282 usgtype . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 282 usgunit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 281 way_flg . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283
Z
zoning. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . aservret . . . . . . . . . . . . . . . . . . . . . . . . . id . . . . . . . . . . . . . . . . . . . . . . . . . . . . . id_type . . . . . . . . . . . . . . . . . . . . . . . . . zone . . . . . . . . . . . . . . . . . . . . . . . . . . . ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... . . . . . . . 557 . 557 . 558 . 558 . 557
Page 942 of 968
11 September 2009
Appendix C: Index of Object GUIs

Symbols
(SE) Configuration Error Retry Timer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Max # of errors per slice before stop host . . . . . . . . . . . . . . . . . . . . . Max # of kills per refresh before stop host . . . . . . . . . . . . . . . . . . . . . Max # of retries in case of communication problem . . . . . . . . . . . . . . . Refresh Period (min) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128 128 127 126 123
A
Account . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 749 #Executions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 788 (Counter) Counter Value 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 785 (Counter) Counter Value 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 785 (Counter) Date . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 785 (Counter) Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 785 1st Inactive Period Warning Done . . . . . . . . . . . . . . . . . . . . . . . . . . . 782 1st Limit Active Period Warning Done . . . . . . . . . . . . . . . . . . . . . . . . 781 1st Low Credit Warning Done . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 780 2nd Inactive Period Warning Done . . . . . . . . . . . . . . . . . . . . . . . . . . 782 2nd Limit Active Period Warning Done . . . . . . . . . . . . . . . . . . . . . . . 781 2nd Low Credit Warning Done . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 780 Account Creation Date . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 759 Account ID (force RI) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 751 Account Profile* . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 749 Act/Can Fees . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 786 Activation DT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 786 Bad Password Attempts Global Counter . . . . . . . . . . . . . . . . . . . . . . . 766 Bad Reload Attempts Counter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 765 Bad Reload Attempts Global Counter . . . . . . . . . . . . . . . . . . . . . . . . 765 Begin Activity Date . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 760 Begin Validity Date . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 759 Birthday . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 758 Blocked . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 771 Cancellation DT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 786 Card Number*. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 751 Commercial Offer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 750 Commercial Offer Assignment Date . . . . . . . . . . . . . . . . . . . . . . . . . 759 Creation DT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 786 E-mail. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 758 End of Activity and Begin of Inactivity. . . . . . . . . . . . . . . . . . . . . . . . 761 End of Inactivity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 763 End of Validity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 760 Error. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 788 Exhausted . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 772 First Event Done . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 779 First Name. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 758 First Occ DT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 788 Friends and Family List . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 769
11 September 2009
Page 943 of 968
Identifier* . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 750 Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 758 Initial Selection Done . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 773 Language . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 757 Last Cost . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 788 Last Credit Update Date . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 764 Last Name . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 757 Last Occ DT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 788 Last Recurring Fee Payment Date . . . . . . . . . . . . . . . . . . . . . . . . . . . 764 Last Reload Date . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 764 Last Reloaded Amount . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 764 LiteSCE Script Pool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 759 Location . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 759 Login. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 758 MSID Type* . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 755 MSID*. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 755 NEIF (HLR Barring) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 779 Next Occ DT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 788 No More Credit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 774, 775 No VAT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 756 Operator Specific Account. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 756 Password . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 759 Password Blocked . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 776 Periodic Fee . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 776 PIN Number . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 758 Prepaid Account . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 754 Reactivation DT. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 786 S.O. Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 786, 787 Scratch Card Reload Suspended . . . . . . . . . . . . . . . . . . . . . . . . . . . . 777 Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 787 Service Retailer* . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 749 Status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 786, 787 Suspension DT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 786 Synchro DT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 788 Welcome Announcement Done . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 783 Account Profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 708 General Ledger Code for Credit Allocation . . . . . . . . . . . . . . . . . . . . . 710 General Ledger Code for Discarded Bucket . . . . . . . . . . . . . . . . . . . . . 727 General Ledger Code for Discarded Credit . . . . . . . . . . . . . . . . . . . . . 710 General Ledger Code for Discarding Operations. . . . . . . . . . . . . . . . . . 721 Account Profile and Usage Link . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 805 Account Profile* . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 805 Notification ID* . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 806 Notification Type. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 807 Service Retailer* . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 805 Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 805 Usage Name* . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 805 Warning Threshold . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 807 Account Subscription Account Identifier* . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 296 see Customer Subscription . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 291
Page 944 of 968
11 September 2009
Area. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 556 Area Name* . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 556 Service Retailer* . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 556 Area Identifier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 557 Area* . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 557 Identifier. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 558 Identifier Type* . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 558 Service Retailer* . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 557 Area Identifier Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 554 ID* . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 555 Name*. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 554 Service Retailer* . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 554 Association Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 907 Name*. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 907 Service Retailer* . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 907
B
Bundle/Counter Usage Label. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 281 Direction Flag. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283 Max Number of Roll-over . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 282 Name*. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 281 Reset . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284 Service Retailer* . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 281 Shift . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 282 Type. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 282 Unit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 281
C
Calendar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151 Calendar Name* . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151 Day Type .... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151 Service Retailer* . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151 Charging Rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255 Calendar* . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 256 Charging Rule Name* . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255 Service Retailer* . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255 Start Date . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 256 Status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 256 Version . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 256 Commercial Offer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Commercial Offer Name . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Service Retailer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Service Rule Ref . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Start Date . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Version . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262 262 262 262 263 263 262
Commercial Offer Link. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 289 Commercial Offer* . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 290
11 September 2009
Page 945 of 968
Community. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 290 Customer* . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 289 Service Retailer* . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 289 Community . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 904 Community Name* . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 904 Service Retailer* . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 904 Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70, 97, 101, 105, 113 Counter. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 853 Account Identifier* . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 853 Current Counter Value . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 854 Date . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 854 Previous Counter Value. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 854 Service Retailer* . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 853 Usage* . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 853 Customer. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 884 Account* . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 890 Address . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 893 Card Number* . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 892 Company Number . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 895 Contract Holder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 893 Contract Number . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 893 Customer Identifier*. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 889 Date of Birth. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 894 DB Name . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 897 E-mail Address . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 893 Fax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 893 First Name . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 894 Friends and Family List . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 886 Gender . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 895 Home Zone. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 896 Identifier (Login)* . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 891 Last Name . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 894 Logical Name . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 897 Login. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 893 Marital Status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 895 MSID*. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 891 Nationality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 893 Passport Issuing Country . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 894 Passport Number . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 894 Password . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 893 Phone Number . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 892 PIN Number . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 893 Place of Birth . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 894 Rank . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 893 Sector . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 895 Service Retailer* . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 884 Status*. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 887 Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 895, 897 Value . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 897 Version* . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 885 Customer Account . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 902
Page 946 of 968
11 September 2009
Account* . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Community . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Customer Account Name* . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Customer* . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Service Retailer* . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
903 903 902 902 902
Customer Association . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 905 Association Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 906 Community . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 906 Customer Association Name* . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 906 Customer* . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 905 Service Retailer* . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 905 Type of Customer Association . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 906 Upper Customer*. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 906 Weight* . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 906
F
Friends and Family Criterion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 427 Friends and Family Member Type . . . . . . . . . . . . . . . . . . . . . . . . . . . 427 Friends and Family List . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 700 FF List Name* . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 700 Service Retailer* . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 700
Friends and Family Member . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 702 List* . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 702 Member Identifier* . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 702 Member Type* . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 702 Service Retailer* . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 702 Friends and Family Member Type. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 700 FF Member Type Identifier*. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 701 FF Member Type Name* . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 701 Service Retailer* . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 700
G
General Ledger Code. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 541 Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 542 General Ledger Code Name* . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 542 General Ledger Code* . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 541 Service Retailer* . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 541 VAT Amount . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 542 VAT Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 541 VAT Rate (%) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 542
L
Language . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150 Language ID* . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150 Language Name* . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150
11 September 2009
Page 947 of 968
M
Matrix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 564 Destination Area*. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 564 Matrix Component* . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 564 Originating Area* . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 564 Service Retailer* . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 564 Start date . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 558, 565 Status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 558, 565 Version . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 558, 565 Matrix Component . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 563 Matrix Component Name* . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 563 Service Retailer* . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 563
P
Package . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264 Package Name* . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264 Service Retailer* . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264 Start date . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264 Status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 265 Version . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264 Package Link . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 279 Commercial Offer* . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 279 Package* . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 279 Service Retailer* . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 279 Start Date . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 279 Status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 279 Version . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 279 Partner Contract . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 918 Amount . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 920 General Ledger Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 921 Partner Contract Name* . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 918 Partner Customer* . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 919 Percentage. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 920 Service Retailer* . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 918 Service* . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 919 Settlement Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 921 Settlement Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 920 Transaction Type. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 919 VAT. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 921
R
Ratable Unit Metric . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 517 Default Reserved Quantity* . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 518 Description. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 518 RUM ID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 518 RUM Name* . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 517 RUM Unit* . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 518 Service Retailer* . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 517 Type* . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 518
Page 948 of 968
11 September 2009
Rating Plan Rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Calendar* . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Rating Plan Rule Name* . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Service Retailer* . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Start Date . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Version . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . 257 257 257 257 258 258 258 96 85 89 92 95 85 83 86 88 88 94 89 72 87 85 73 70 70 91 73 71 72 91 83 82 92 86 89 89
RE Configuration Automatic Subscription Activation . . . . . . . . . . . . . . . . . . . . . . . . . . . Community Engine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . DB Name (Arena) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Default . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Enable Dynamic Counters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Event Scheduler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . External Module Partitioned . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . External Module SEP Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Fee Processing Time-out . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Fees Activated . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Last Ten Events Enabled. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Logical Name (Arena). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Maximum Balance Lock Time (sec)* . . . . . . . . . . . . . . . . . . . . . . . . . . Modulo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Notification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Number of Contexts per Scan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Number of Contexts per SEP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Number of Partitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Partition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Partition Algorithm* . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Partition Attribute* . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Partitioning Algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Range . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Send Back Ticket to RTx Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . Send Ticket to External Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SEP group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Type. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Type (Arena) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Value (Arena) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Result Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153, 156, 201 Result Code* . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
S
Scheduled (Customer / Account) Event Customer Subscription* . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Customer* . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Error on Fee. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . First Fee Date . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Last Cost . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Last Fee Date . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Next Fee Date . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Service Name* . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Service Retailer* . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 309 307 311 311 312 311 312 308 307
11 September 2009
Page 949 of 968
Status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 310 Synchronisation Date . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 312 Scheduled Account Event . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313 (see Scheduled Customer Event). . . . . . . . . . . . . . . . . . . . . . . . . . . . 307 Account Identifier* . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313 Scheduled Customer Event . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 307 (see also Scheduled (Customer / Account) Event) . . . . . . . . . . . . . . . . 307 Scheduled Event Customer Community* . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 308 SE Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118 ARES SEP group* . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118 CE Service Name* . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119 Delay Before Insert Fee (min) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121 Max of Empty Loops . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121 Max. CPU Threshold* . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123 Min. CPU Threshold*. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123 RE Service Name* . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119 Scheduler Timer (100 millisec)* . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120 Validity of Late Fees (days) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122 Wait Timer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121 SE Partition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129 Active . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136 Active CE SEP Group* . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135 Active Host ID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135 Additional SQL Constraint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132 CE Load (%) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138 Date of Last Executed Fee. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132 Last # Events / Sec . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139 Last # Events / Slot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139 Max. # Events Processed* . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137 Partition Name*. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129 Processing Timeout (100 ms) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137 RE Load (%) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138 SEP Name* . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134 SMF* . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134 Stand-By . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136 Stand-By CE SEP Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136 Status*. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131 User Type* . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132 Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 260 Description. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261 Service Name . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261 Service Retailer* . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 260 Service Offer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266 Charging Rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 268 Plan* . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 267 Rating Plan Rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269 Service Name*. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266 Service Offer Name*. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266 Service Retailer* . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266
Page 950 of 968
11 September 2009
Start Date . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269 Status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269 Version . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269 Service Offer Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235, 236 Activity Period Extension (days). . . . . . . . . . . . . . . . . . . . . . . . . . . . 248 Align with Subscriptions Synchronization Date . . . . . . . . . . . . . . . . . . 242 Allow Refunds . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246 Day of the Month . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242 Day of the Week . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242 Default Quantity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245 Fixed Amount (Money) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245 Fixed Termination Date . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243 General Ledger Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246 Inactivity Period Extension (days) . . . . . . . . . . . . . . . . . . . . . . . . . . 248 LiteSCE Script Pool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249 Maximum Number of Occurrences . . . . . . . . . . . . . . . . . . . . . . . . . . 243 Moment of the Non-Usage Event . . . . . . . . . . . . . . . . . . . . . . . . . . . 238 Month of the Year . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242 Name*. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235 Notification ID for Errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239 Notification ID for Warning . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246, 248 Number of days/weeks/months/years. . . . . . . . . . . . . . . . . . . . . . . . 242 Position in LiteSCE Pool for End of Treatment . . . . . . . . . . . . . . . . . . 249 Position in LiteSCE Pool for LiteSCE Fee . . . . . . . . . . . . . . . . . . . . . . 249 Position in LiteSCE Pool for Next Date and Prorata . . . . . . . . . . . . . . . 250 Prorata at First and Immediate Occurrence . . . . . . . . . . . . . . . . . . . . 243 Prorata at Last Occurrence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243 Rating Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245 Recurrence Pattern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241 Scheduling Engine Behavior in Case of Error . . . . . . . . . . . . . . . . . . . . 239 Service Retailer* . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235 Start Date . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236 Status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236 Termination Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243 The Non-usage Event covers the Period . . . . . . . . . . . . . . . . . . . . . . . 241 Top-up Amount. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247 Top-up Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247 Top-Up Profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247 Top-Up Rule. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247 Type of Non-usage Event . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237 Usage Rating Rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245 Version . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236 Service Offer Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273 Barring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274 Service Offer Group Name* . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273 Service Retailer* . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273 Start Date . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274 Status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274 Sub-Service Offer Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273 Version . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274 Service Offer Group Link . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 277
11 September 2009
Page 951 of 968
Default . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Package* . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Service Offer Group* . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Service Retailer* . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Start Date . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Version . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
278 277 277 277 278 278 278
Service Offer Link . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275 Service Offer Group* . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275 Service Offer* . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275 Service Retailer* . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275 Start Date . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275 Status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275 Version . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275 Service Retailer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140 Account Interrogation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144 Account Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145 Address . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143 Allow Tariff Switch* . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144 Computing Precision* . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146 Database Precision* . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145 DB Name . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148 Default Matrix Component. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142 Default Service Retailer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142 Help Desk. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144 LiteSCE Pool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149 Logical Name . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148 Max Number of Matching Characters . . . . . . . . . . . . . . . . . . . . . . . . . 143 Min Number of Matching Characters . . . . . . . . . . . . . . . . . . . . . . . . . 142 Minimum Granted Unit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147 Postpaid Discount Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144 Provider Group*. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141 Reload. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145 Rounding Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147 Service Retailer ID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140 Service Retailer Name* . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140 Subscriber Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141 Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148 Value . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148 Subscription . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 291 Activation Date . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293 Cancellation Date . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294 Creation Date . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293 Disable Activation and/or Cancellation Fees . . . . . . . . . . . . . . . . . . . . 292 Forced Charging Date . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293 Re-Activation Date. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294 Service Offer Group* . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 291 Service Retailer* . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 291 State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292 Suspension Date . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294 Subscription (Account)
Page 952 of 968
11 September 2009
See Susbcription (Customer) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 291 Subscription (Customer). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 291 Community . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293 Customer* . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 291
T
Tariff . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 519 (1) Quantity* . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 525 (1) Tick* . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 525 (2) Quantity* . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 525 (2) Tick* . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 525 (3) Quantity* . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 525 (3) Tick* . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 525 (4) Quantity* . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 526 (4) Tick* . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 526 (5) Tick* . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 526 Connection Cost* . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 524 Connection Quantity*. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 524 Connection Tick*. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 524 Delta Cost* . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 524 Display Tariff Chart without Ticks . . . . . . . . . . . . . . . . . . . . . . . . . . 522 General Ledger Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 520 Rating Mode* . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 520 RUM (1)* . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 523 Service Retailer* . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 519 Start Date . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 520 Status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 520 Tariff Name . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 520 Tariff Origin* . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 521 Tariff Type* . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 524 VAT Flag* . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 520 VAT Rate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 520 Version . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 520 Vertical Axis* . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 521 Tariff Tester ? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212, 213 Called* . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210 Calling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209 Destination . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210 Destination Search Algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210 Destination Type. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210 EDR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204 Event Date* . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208 Event Time* . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208 Event Type* . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207 First Call Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208 First RUM* . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209 Interface Time Out*. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203 Key Type* . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206 Key* . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207 Last Execution Date. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212
11 September 2009
Page 953 of 968
Origin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Origin Search Algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Origin Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Parameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Request Type*. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Result Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Save Result After Execution. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Second RUM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Service Retailer. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Sub Result Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Test ID. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Third RUM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Top-Up Profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Value . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . tariftst
209 210 209 214 203 212 204 209 201 212 201 209 211 214
resc_sub . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212 TBD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120, 123, 126 Top-up Rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252 Calendar* . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253 Name* . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252 Service Retailer* . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252 Start Date . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253 Status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253 Version . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253
Page 954 of 968
11 September 2009
Appendix D: Arena
The following table provides more information on Arena attributes in CRE 262.
Table 290 - CRE Arena attributes list

Sl. No. 1 Object Class Level Account Arena Variable DB Name rst_ppm Type Delivery Week HF819 Default Value 0 DDTS reference VELin81 645 Description
Integer
Bad management of First event bonus (account profile) in case of use of reset connector: negative balance. This arena variable will store the threshold value of credit which will be checked while making the account inactive and the credit will be retained if ppm credit is less than tmc_credit. This attribute (BONUS_MOD) can have three values on the basis of which we define the mode to be chosen for further grants (2nd, 3rd.). These are: 1) 0 - grant on previous value only and first time to main top up (nominal value) 2) 1 grant on main top up value (nominal value) only, every time 3) 2 grant on cumulative values of grants and main top up, till the present grant.
Account Profile
tmc_cred
Integer
HF819
VELin71 061
Account Profile
bonus_mod
Integer
HF810
VELin77 946
11 September 2009
Page 955 of 968

Sl. No. 4 Object Class Level Account Profile Arena Variable DB Name fee_ls Type Delivery Week HF839 0 Default Value DDTS reference NAMin3 6659 Description
String
If its value is 1 then, if the account is in Inactive state and Fee is executed, the subscription goes to Suspended-Retry and fee goes to retry mode. FIRST_CALL arena variable in client is used as life cycle to identify if the first call from the client has been done or not. 0 indicates first call, 1 indicates first call done. After sending the request the arena is set to 1 for all the clients for which the request is sent to scmd. Thus, it is set by CE in the customer at the first call after sending of subscription activation request
Customer
FIRST_CA LL
Integer
HF823
NAMin3 4861
CE Configurati on Network Events
DO_SETTL EMENT fillarena
UINT
DR4
NAMin2 6232 NAMin2 1427
Flag to enable or disable settlement The dmofiled of the object ppm is filled with the attributes with default values taken from the arena object, when the net_event object has arena attribute fillarena (of type string) equal to one. When the value is one, then all the default values are also filled in the dmofield. To set customized validity end date in bucket top up.
String
DR4
Network Events
lite_t
String
HF810
VELin75 992
Page 956 of 968
11 September 2009

Sl. No. 9 Object Class Level Network Events Arena Variable DB Name fee_sog Type Delivery Week HF806 Default Value On presence of variables changed behavior will be performed DDTS reference NAMin3 1503 Description
String
If the two arena variables corresponding to this CR(NAMin31503) exist then direct activation of subscription with subscription criteria and charging rule can be done immediately, with out waiting for one hour buffer time. If the two arena variables corresponding to this CR(NAMin31503) exist then direct activation of subscription with subscription criteria and charging rule can be done immediately, with out waiting for one hour buffer time. If TRUE, then if the bucket is not valid at the date of the top up (i.e., the end of validity date of the bucket is smaller than the top up date) than the value of the bucket is set to the value of the top up. The value that was contained in the bucket before the top up is lost
10
Network Events
fee_activedt
String
HF806
On presence of variables changed behavior will be performed
NAMin3 1503
11
RE Configurati on
pps_reset
Boolea n
DR4
False
NAMin2 6191
11 September 2009
Page 957 of 968

Sl. No. 12 Object Class Level RE Configurati on Arena Variable DB Name pps_novat Type Delivery Week 1 Default Value DDTS reference Description
Boolea n
In case of mono bucket bundle and the arena filed in the service retailer PPS_NOVAT is set, the check of the top-up profile is not done and the value is added and the date are managed. In the case of non-reset bundle and using different profile the top-up is possible only if PPS_NOVAT (arena attribute in the SDPCFG) is set to true. The profile used on the bucket creation is kept.
13
RE Configurati on
rtx_slice
Integer
HF833
non-zero
NAMin3 6052
if (current time)>[(Credit dynupdt time)+RTX_Slice(Are na)+120(2hrs defence on RE)] then an alarm to be thrown and resolve to be reset; The 'true' or '1' value indicates that the new subscription within 1 hour is treated in areas mode and not as an immediate mode otherwise immediately. When the Arena Variable value is not NULL new sib not_val2xml_2 is used.
14
RE Configurati on
SUBS_SCH ED(Not on script level)
Boolea n
HF827
NAMin3 0711
15
RE Configurati on
f_xml2
Integer
HF907
VELin93 857
Page 958 of 968
11 September 2009

Sl. No. 16 Object Class Level RE Configurati on Arena Variable DB Name no_delay Type Delivery Week HF851 Default Value DDTS reference NAMin3 6783 Description
Integer
if arena variable = 0 or false or not found: execute logic of VELin74234(Suspens ion occurred between current date and the date of the fee next occurrence, and the fee is to pay in advance -> delay suspension at the end of the paid period), else bypass it. This arena value would be considered at SMF level only, i.e., it will be read at SMF level for displaying of ten calls. Thus, the ten calls shall then be displayed if sdpcfg.tencalls OR arena.tencallsdisplay is set to 1. This arena variable is read at SMF and on the basis of its value it is decided whether to allow or not the modification of Account's credit and life cycle dates. It can have values from 0 to 4.
17
RE Configurati on(In PPM object)
tencallsdispl ay(Not on script level)
Boolea n
HF825
VELin81 002
18
RE Configurati on(In PPM object)
NoModifCr edit(Not on script level)
Integer
HF839
VELin87 580
19
RE Configurati on(In SIB setproponpr ofile)
ProDate(No t on script level)
Boolea n
HF842
NAMin3 6786
This arena variable is read at SMF. If its value is 1, we prorate bucket validity dates in case of top up recurrent fee. Otherwise only bucket value will be prorated & not its validity dates.
11 September 2009
Page 959 of 968

Sl. No. 20 Object Class Level RE Configurati on Service Offer definition Arena Variable DB Name SCMD_NA ME Type Delivery Week HF823 Default Value DDTS reference NAMin3 4861 Description
String
Arena variable created in re-configuration which will contain scmd service name. If we have forbidden leaf in the URR of Service Offer Definition, then subscription activation should not be done. This arena variable is used as a flag for PPT team, where the ppm/ client does not have any card_nbr or emailid and hence the notifications has to be by-passed. Extension of Life Cycle Dates of the Account based on the Grant's Top-up Profile. Arena for activating Mode B2, 0 means Mode B and 1 means Mode B2 Arena for activating Virtual mode A, 0 means not activated; 1 means Virtual mode A activated Implementation of NAMin37138 should be controlled by an arena variable defined at service retailer level Tariff switching, problem on site with bundle I-top up: Bundle creation at the time of account creation.
21
forbidden_f ee_nok
Integer
HF810
NAMin3 3295
22
Service Retailer
icc_notif
Integer
HF806
VELin69 979
23
Service Retailer
grnt_ext
Integer
HF802
VELin73 497
24
Service Retailer
RMODE
Integer
HF839
NAMin3 4425
25
Service Retailer
VMODE
Integer
HF839
NAMin3 4425
26
Service Retailer
ActvAlBkt
String
HF845
Namin37 502
27
Service Retailer Service Retailer
URR_S
Boolea n Integer
HF847
NAMin3 6662 NAMin3 6493
28
DEFBUN (not on script level)
HF851
Page 960 of 968
11 September 2009

Sl. No. 29 Object Class Level Service Retailer Arena Variable DB Name ord_bc Type Delivery Week HF849 Default Value 0 DDTS reference NAMin3 7114 Description
Boolea n
For bundle ordering consideration. If its value set to 1 then bundle ordering will be considered For retry on reload feature consideration.If its value is 1 then the feature will work for account and customer subscription Arena variable is used to activate the Retry on Reload feature for subscriptions [Account and client]. When non-zero, it activates the empty bundle feature for main balance. If 1, then money bundle discount feature is activated. I.e discount criteria will also work for money type bundles
30
Service Retailer
retry_rld
Boolea n
HF851
NAMin3 7463
31
Service Retailer
RETRY_RL D
Integer
HF851
NAMin3 7463
32
Service Retailer
EMP_BAL _261
Integer
HF916
VELin90 265
33
Servret
apply_bdl_d iscount
Integer
HF827
VELin81 843
11 September 2009
Page 961 of 968
Page 962 of 968
11 September 2009
Document References
Document Title
Alcatel-Lucent 8618 Convergent Rating Engine 2.6.2 - Reference Guide
Document Reference Number

Alcatel 3CL-02660-BAHA-PCZZA
Status
Released
Current Document Version

1.6
Date of Current Version

11 September 2009
History
Version 1.6 1.5 1.4 1.3 1.2 1.1 Date Sept 14, 2009 June 04, 2009 Jan 12, 2009 Nov 3, 2008 March 07, 2008 08 June 2007 Author Pavan Puri Pavan Puri Pavan Puri Pankaj Sharma Franz Carlier Philippe Swinnen, Stphane Wantiez, Runxia Ye Nal Khairzamanov, Alexandra Valyshkova, Runxia Ye, Nils Lian, Stphane Boyen Editor Gunashekar Rekha V Gunashekar, Manu T S Darshana Menon, Rekha V Franz Carlier Andr Kuhnmant Axel Blanckaert Axel Blanckaert Appraiser
1.0
23 May 2007
Andr Kuhnmant
Axel Blanckaert
11 September 2009 968
Page 963 of 968
History of Changes
Version 1.6 Change Notes
This version includes the changes requested in the follwoing DDTS tickets:
VELin87604: New appendix section Arena table created VELin94468: Section 13.6.3.4 Table 188 - Note added in Row2, Cloumn2 NAMin40150: Section 24.2.1 Table 263 - Object Identifier - Modified third line VILin01102: Section 4.1.9 Table 18 - Enable dynamic counters - Flag Unchecked is modified VILin02323: Section 7.3.2 Table 76 - Termination Type - Description Modified VILin01147: Section 5.2.1 Macro 7 - New Note added VILin04363: Section 19.3.1.3.2 - New Note added VILin02666: Section 14.3 and 14.4 updated with new note VIlin02425: Section 11.4 - Example of Versioning Use deleted. 1.5
This version includes the changes requested in the following DDTS tickets:
NAMin39794:Added an example in section 11.3.3.9 NAMin37141:Updated Table 117, section 12.3.6.8

VELin84457: Updated Table 117. NAMin39579: Added a note in section 18.2.2.3. VELin93786: Modified Table 64, Added a new row for the parameter Profile Ratio. VELin95231: Modified section 19.1.3. Changed the description of the parameter Duration for Termination Calls Bonus. NAMin39188: Modified Table 60. VELin92894: Updated the description of the parameter Maximum Activity End Date Nb. Days, in the Section 19.1.3. NAMin38564: Added numeric values forthe different states in the section 19.3.3, cyclstat attribute. NAMin36889: Added a new section under chapter 5. NAMin35559: Modified Note 2 in the section 15.2.3.2
Page 964 of 968
11 September 2009
1.4
NAMin33259: Changed the description of the parameters parameter1 and parameter2 in table 140 - LiteSCE Criterion. VELin89327: Chapter 5, Table 53: A sentence is added before the table. NAMin37164: Modified the parameter Scheduled Event switched to error in Table 186. NAMin37190: Modified the parameter Value in table 117. VELin89960: Modified Table 141: LiteSCE Criterion Availability, also a note is added after the table.. VELin89650: Modified the parameter Origin search algorithm and Destination search algorithm in table 63. VELin90057: Modified the description of the parameter Else Branch in Table 142 Configuring your Main Balance Criterion. VELin88387: Added new section in the Chapter 9, Section 9.11 Product catalog performance improvement. NAMin37222: Cross Reference error was fixed. VELin91428: Section 11.3.25.1, a note is added in this section. NAMin38283: Section 5.2.2.1 is modified. All the seven macros are updated according to the inputs provided.
VELin92591: Modified the parameter End of Active Period (Prepaid only) in table 52: Enabling a Given Notification Type on a Given Account. VElin90343: Added note for the parameter Last Fee Applic. Date in table 234:Account - Loyalty Tab. NAMin35559: Updated Section 15.2.3.2 Mode A v/s Mode B.
Page 965 of 968
1.3
VELin70091: New section added under heading 23 NAMin32694: Modified the parameter "Object Identifier" in "Table 261-CE Flexibility point". VELin66428: Changed the snapshot,Figure 370,Page No 945 VELin83119: Changed the description for the parameter Reset credit during inactivityin table 223,section 19.1.3 VELin82547: Modified "table 67- Network Event Type" VELin81009: Added a note in section 14.3 and a remark in the description of "Cancellation Date", Table 95, section 10.4.2.1 VELin80817: Modified the description of the parameter "Information" in Table 135 VELin80564:Updated the cross reference and inserted the new GUI screenshot in table 287, section 29.4.2. VELin80405: Modified the description of the parameter "Minimum Granted Unit" in table 40 NAMin33259: Modified the description of the parameter "Parameter1" in table 140 NAMIn34967: Replaced the snapshots in Figure 269, Figure 270, Figure 271 VELin69010: A note added for 20.1.4.1. Buckets Validity Period VELin69010 NAMin35597: modifed Section 19.1.3. Parameter Description, Table 223 - Account Profile - General Tab Parameter description of "Reset Credit During Inactivity (actcre)" NAMin35589: Added section 10.4.2.2 Automatic Customer Subscription Activation NAMin35586: Replaced the description of allowed leaf, in section 6.2.3.2 NAMin35581: New section added in section 27.1 NAMin35574: Updated section 20.1.4.1 NAMin35560: Added a note in section 11.3.11.1 NAMin34278: Updated the section 18.2.1 NAMin34277: Updated the Attribute Object Name and DB name in section 11.3.15 VELIn84457: Replaced Figure 198, In Table 117 added Criteria description Text for Immediate Update, Added a new subsection 11.3.6.8 Counter handling in various Cancel scenarios
Page 966 of 968
11 September 2009
1.2
Appendices have now titles and appear in the PDF bookmarks. This version includes the changes requested in the following DDTS tickets: VELin77850: Activity Period, Inactivity Period and Validity Period expect a positive integer with max. value 9999. (Same as NAMin23582 & NAMin23650). See page 717. VELin75380: Cut-Copy-Paste commands are not valid in routing trees. See page 47. VELin74260: Acceptable default values for ARENA variable of boolean type. See page 860. VELin69158: Real time call duration: type of RUM to be used for charging. See page 791. VELin68297: New snapshot: Community is mandatory in Customer Association object. See page 905. NAMin30765: Last 10 Events list takes free call information into account. See page 789. NAMin30577: Maximum Activity End Date Fix Date is stored as dd/mm/yyyy in the DB. See page 719. VELin66177: synch date is stored in accfee object, not in Subscription object. See page 293. VELin65941: Maximum value for Weight field of Customer Association object is 255. See page 906. NAMin29915: Constraint on Maximum Activity End Date Nb. Days of Account Profile object. See page 719. NAMin29815: New table of constraints on dates in subscription states. See page 299. VELin56664: Details on Message box after a Modify command on Bundle/Counter Usage Label object for Multi Bucket Bundle. See page 282.
NAMin26434: Conditions when a notification can be issued. See page 185. AUSin19142: in note, Supervision replaces Subscription. See page 463. AUSin17821: RUM1 should be used for time. See page 523. AUSin16679: Connector Number 24 Getppmallbuckets removed from table. See page 866. VELin64025 / CR ORO56 / NAMin31861 / NAM33007: New feature: Buckets with Warning SMS. See page 821. NAMin30543: Correction to RE Object Priority Table. See page 877. VELin75378: correct setting for Timer value in OOC - Session OOC tab. See page 198. NAMin31276: Constraint on Order of Bucket Usage. See page 283. NAMin32261: Constraint on Order of Bucket Usage. See page 283. NAMin30434: New Refresh method and parameters for the Area Identifier object. See page 559. NAMin30188: Computation of Next Discount DT in Discount object. See page 768. VELin70556: Impact of PPS_RESET Arena value on topup behavior for resetable mono-bucket bundles. See page 808 and page 89. VELin65079: Commercial Offer and Default Account parameters on Customer object. See page 887.
Page 967 of 968
1.1
Migrated the OSP 2.3 snapshots to OSP 2.4 ones, except for the following sections: Section 10.6.3, Cancelling a Suspended Subscription, on page 320, Section 16.5.3, Example of Provisioning, on page 570, Section 21.1.3, How to launch an Operator Deposit?, on page 832, Section 21.2.3, How to Adjust the Main Balance?, on page 844. The text has also been adapted to the OSP 2.4 look and feel as well as to the new snapshots. Further updated Zoning chapter.
1.0
First version. Describes the enhancements brought by CRE 2.6.2, which include: Originating Zone criterion (new) Destination Zone criterion (new) Area parameter of ZONE object can now refer to a Simple Area of the default Service retailer. PACKAGE, MATRIX and AREA IDENTIFIER objects are now versioned. Order of Bucket Usage parameter of BUNDLE/COUNTER USAGE LABEL object has now two new options, which allow to use buckets according to their expiry date.
Identification logic of Zones now also searches through the Zones of the default Service Retailer. Zoning chapter and documentation of the Zoning criteria have been updated in order to reflect these enhancements. The following has been documented or clarified: Moving a decision tree from one CRE platform to the other (see section 12.2.4, Moving a Decision Tree from One CRE Platform to the Other, on page 356). Duplicating a Decision Tree (see section 12.2.5, Duplicating a Decision Tree, on page 366). Activity Reload Algorithm parameter of TOP-UP PROFILE object.
Disclaimer
All rights reserved. Passing on and copying of this document, use and communications of its contents not permitted without written authorization from Alcatel-Lucent. The marks and product names cited are the service marks or registered trademarks of their respective owners. The information in this documentation is subject to change without notice. If you find any problem in the documentation, please report them to us in writing. Alcatel-Lucent does not warrant that this documentation is error free.
Address
Alcatel-Lucent Avenue Comte de Smet de Nayer 14 5000 Namur Belgium
Page 968 of 968
11 September 2009

CRE 2.6.2 Reference Guide Ver1.6

Загружено:

Сведения о документе

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

CRE 2.6.2 Reference Guide Ver1.6

Загружено:

Авторское право:

Доступные форматы

REFERENCE GUIDE

Convergent Rating Engine 2.6.2

Reference Guide | version 1.6

Whats New in Alcatel-Lucents OSP 2.4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

OSP Level Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

Mandatory Convergent Rating Engine Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

Convergent Rating Engine 2.6.2

4.1.3.4. Modules Tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

4.1.3.5. Connectors Tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

Convergent Rating Engine 2.6.2

Reference Guide | version 1.6

4.3.4.5. 4.3.4.6. 4.3.4.7. 4.3.4.8.

4.4. 4.5. 4.6.

Optional Convergent Rating Engine Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161

5.1.1.5. Notification Feature Table Object Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163

Convergent Rating Engine 2.6.2

5.2.2.1. OOC Macros 1-7 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188 5.2.2.2. Macro 0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192

Product Catalog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .218

Service Identification. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219

Types of Service Offers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228

Convergent Rating Engine 2.6.2

Reference Guide | version 1.6

Guiding Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254

Catalog Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259

9.4. 9.5. 9.6.

Convergent Rating Engine 2.6.2

Users Portfolio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 285

10.4.4.3. 10.4.4.4. 10.4.4.5. 10.4.4.6.

302 303 304 304

11.1. Functionality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 324

Convergent Rating Engine 2.6.2

Reference Guide | version 1.6

Decision Trees . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 329

Convergent Rating Engine 2.6.2

Convergent Rating Engine 2.6.2

Reference Guide | version 1.6

Convergent Rating Engine 2.6.2

Scheduling Engine. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .481

Scheduled Events Processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 483

Convergent Rating Engine 2.6.2

Reference Guide | version 1.6

13.3.1.1. 13.3.1.2. 13.3.1.3. 13.3.1.4.

Recurring Events Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 503

Rating Engine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 516

Rating Paradigm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 517

Convergent Rating Engine 2.6.2

Zoning Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 543

Convergent Rating Engine 2.6.2

Reference Guide | version 1.6

Rewarding Accounts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 589

............ ............ ............ ............

599 600 601 603

17.2.2.7. Indicating Which Accounts Value Sub-Repository Is Granted Credit. . . . . . . . . . . . . 606

Convergent Rating Engine 2.6.2

17.5.2.2. 17.5.2.3. 17.5.2.4. 17.5.2.5. 17.5.2.6. 17.5.2.7. 17.5.2.8. 17.5.2.9.

662 663 664 665 666 666 667 668

17.5.2.12.When the Reward Is a Credit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 678

17.5.2.13.Customizing a Promotion (LiteSCE Scripting) . . . . . . . . . . . . . . . . . . . . . . . . . . . 680

Preferred Charging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 699

Convergent Rating Engine 2.6.2

Reference Guide | version 1.6

Balance Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 703

Creating and Provisioning Accounts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 704

Convergent Rating Engine 2.6.2