Product Data Model (4.3)
- Jenni Wallin
The UDRs in PCC.Products stores product related data. A product controls the behavior of a bucket.
See APL - PCC Runtime Support - Buckets (4.3) for further information about how to use the PCC.Products UDRs with APL and REST HTTP Interface - Products (4.3) for information on how to access the PCC.Products UDRs from the REST HTTP interface.
The main parts of PCC.Products are:
| Object | Description |
|---|---|
Product | The product holds information about the capacity of the counters, the enforcements and notifications that should be triggered at specific capacity levels, the interval at which the counters should be reset, how many counters to retain at reset, and, if the product stops, fallthrough in the usage recording process. Since a product is used by buckets it is important not to remove products in use. |
ProductMapping | A flexible mapping table used to map from an external representation to a list of products. The external representation can be, for instance, a rating group, or a combination of rating group and time period classification. The mapping should not include any information related to a specific subscriber. |
SubscriberProfile | Subscriber profiles are used for associating different products to different profiles. The subscribers will then have access to the products associated with their subscriber profile. |
Overview of the Product Data Model
The different UDRs within the Product Data Model are connected as follows:
Overview of the Product Data Model
ProductMapping UDR
In the ProductMapping UDR you set up the priority for the product mapping, the rating groups, etc that the product mapping should use, and the products that should be applied.
Field | Description |
|---|---|
| The unique ID of the product mapping table. |
| The priority of the mapping object, a low value indicates a high priority. Determines the order in which the matched mapping objects are returned. |
| The arguments of a mapping object, e g the rating group. |
| The different products used by the mapping object. |
Below is a screenshot of the UDR Assistance displaying the ProductMapping UDR:
ProductMapping UDR
Example - ProductMapping UDR
The following values:
ID=101 Priority=1 Arguments=[4] Targets=[100,110] ID=102 Priority=3 Arguments=[8] Targets=[100]
will give the following setup:
The first product mapping, with ID 101, has a higher priority than the second, with ID 102.
The first product mapping refers to rating group 4, while the second product mapping refers to rating group 8.
The first product mapping references product 100 and 110, while the second product mapping references product 100.
Product UDR
The Product UDR holds information about the capacity of the counters, the enforcements and notifications that should be triggered at specific capacity levels, the interval at which the counters should be reset, and how many counters to retain at reset. If StopFallthrough is set to yes, counting for this product should prevent counting in buckets connected to lower priority products. Since a product is used by buckets it is important not to remove products in use.
Field | Description |
|---|---|
| The unique product ID. |
| The name of the product. |
| Defines the capacities for all counter items relevant for this product. A capacity is used to measure threshold values for enforcements and notifications. For unlimited capacity ignore this field. |
| Optional price information. |
| Currency of price, e g USD, EUR, etc. |
| When creating a bucket this field can be used to set the value for the bucket stop time. |
| The unit of the duration, for instance day, week, or month. 1 = minute, 2 = hour, 3 = day, 4 = week, 5 = month and 6 =year. ResetType (int) The type of reset, reset from start (1) or reset from date (2). |
| Holds a list of enforcement definitions, see the section below, Enforcement UDR. |
| Holds a list of notification definitions, see the section below, Notification UDR. |
| The type of reset; reset from start (1), which means that if the reset interval is set to "Month", for example, then the buckets connected to the product in question will be reset at the start of the month, even if the day and time in the bucket's StartTime is something else, or reset from date (2), which means that the bucket will be reset at StartTime plus ResetInterval . Note! This is just an example configuration which may be changed in the Workflow template. |
| The interval with which this product is reset. Resetting a product involves clearing the bucket associated with this product. If set to 0 the product is never reset. |
| The unit of the reset interval, for instance day, week, or month. 1 = minute, 2 = hour, 3 = day, 4 = week, 5 = month and 6 =year. |
| Controls the number of counters that are retained in the bucket counters list at reset. For example, if the product has an hourly reset interval and RetainedCounters is 24 the bucket will hold discrete usage counter statistics for the last 24 hours. |
| Determines the list of periods during which the product should be active. The periods in the stated list can contain one or several sub periods, which means that you can combine different time settings in one period. See Periods Data Model Buckets (4.3) for further information. |
| The start time for the product. |
| The stop time for the product. |
| Used in the product selection process. When usage is reported, the first step is to determine the products associated with the reported usage. This results in a product priority list. The next step is to iterate the list and report usage in the associated bucket. If StopFallthrough is true on the product then iteration stops with this. |
| Determines if the counter for a bucket should continue to count or not when 100% capacity for the bucket has been reached. If set to false, the counter will continue counting. If set to true, the counter will stop once 100% capacity for the bucket is reached. |
| See Misc Field (4.3) for more information. |
Below is a screenshot of the UDR Assistance displaying the Product UDR:
Product UDR
Example - Products UDR
The following values:
ID=100 Name='GOLD' Capacitites=[101, 102] Duration=7 DurationUnit=3 Enforcements=[605] Notifications=[1,3,5] ResetType=2 ResetInterval=1 ResetIntervalUnit=3 RetainedCounters=10 Periods=[503] StartTime='2011-06-01 00:00:00' StopTime='2011-09-01 00:00:00' StopFallthrough=true StopAtCapacity=true ID=110 Name='SILVER' Capacitites=[101] Duration=24 DurationUnit=2 Enforcements=[605] Notifications=[2,4] ResetType=2 ResetInterval=1 ResetIntervalUnit=4 RetainedCounters=2 Periods=[504] StartTime='2011-01-01 00:00:00' StopTime='2012-01-01 00:00:00' StopFallthrough=true StopAtCapacity=true
will give the following setup:
The two products have the IDs 100 and 110, which are used by both PCC Rules and PCC Buckets, and have the names Gold and Silver .
The Gold product uses capacities 101 and 102, while the Silver product only uses capacity 101.
The Gold product will be available for 7 days from the time you start to use it, while the Silver product will be available for 24 hours from the time you start to use it.
Both products use the enforcement 605.
The Gold product will receive notifications 1, 3 and 5, while the Silver product will receive notifications 2 and 4.
The reset and retained counters settings for the Gold product will reset the product once every day, based on date, and discreet usage counter statistics will be kept for 10 days.
The reset and retained counters settings for the Silver product will reset the product once every week, based on date, and discreet usage counter statistics will be kept for 2 weeks.
The Gold product will be active during the time periods stated in the Periods list 503, while the Silver product will be active during the time periods stated in the Periods list 504.
The Gold product will start on the 1st of June and end on the 1st of September, 2011, while the Silver product will start on the 1st of January, 2011 and end on the 1st of January, 2012.
For both products, counting will stop once the bucket for the respective product is full.
SubscriberProfile UDR
In the SubscriberProfile UDR you can configure different subscriber profiles. The profiles associate subscriber types with certain products, and many subscribers can share the same profile.
Field | Description |
|---|---|
| The unique id of the subscriber profile. |
| The name of the subscriber profile. |
| The products that should be associated with the profile. |
| See Misc Field (4.3) for more information. |
Below is a screenshot of the UDR Assistance displaying the SubscriberProfile UDR:
SubscriberProfile UDR
Example - SubscriberProfile UDR
The following values:
ID=10 Name='STAR' Products=[100,110,120] ID=20 Name='MEDIUM' Products=[110]
will give the following setup:
The two subscriber profiles with IDs 10 and 20 has the names Start and Medium .
The subscribers belonging to the Start profile will have access to products 100, 110 and 120, while the subscribers belonging to the Medium profile will only have access to product 110.
Capacity UDR
In the Capacity UDR you define the capacity for counter items. A capacity is used for measuring threshold values for enforcements and notifications.
Field | Description |
|---|---|
| The unique capacity ID. |
| The name of the capacity. |
| This parameter can be used for specifying the capacity of the counter type. |
| This parameter can be used for specifying the unit of the capacity; 0 - bytes, 1 - kB, 2 - MB, 3 - GB, 4 - Event, 5 - Hour, 6 - Minute, or 7 - Other. |
| This parameter can be used for specifying the type of counter this capacity applies to; 0 - input, 1 - output, or 2 - total. |
| This parameter can be used for specifying the unit of the counter; 0 - bytes, 1 - kB, 2 - MB, 3 - GB, 4 - Event, 5 - Hour, 6 - Minute, or 7 - Other. |
| This parameter can be used in the APL code for setting a default quota that will be reserved for a request. If this quota is not available, you can configure the minimum amount of quota, specified by the QuotaMinimum field, to be tried instead. |
| This parameter can be used in the APL code for specifying the minimum amount of quota that needs to be available to grant a request. If this quota is not available, you can configure the request to be denied. |
| See Misc Field (4.3) for more information. |
Below is a screenshot of the UDR Assistance displaying the Capacity UDR:
Capacity UDR
Example - Capacity UDR
The following values:
ID=101 Capacity=400000 CapacityUnit=0 CounterType=2 ID=102 Capacity=100000 CapacityUnit=1 CounterType=1
will give the following setup:
The two capacities have the IDs 101 and 102, which are used by the Product UDR.
The first capacity refers to the total amount of bytes, while the second capacity refers to the output bytes.
The first capacity has a limit of 400000 bytes (unit=0), while the second capacity has a limit of 100000 kB (unit=1).
Enforcement UDR
The Enforcement UDR sets a threshold for when an enforcement should be triggered, and is used by both the Product UDR and PCC Rules. A Product can use one or several enforcements. When the usage exceeds enforcement threshold, the enforcement will be applied. When a new enforcement is triggered a new PCC rule should be applied.
Field | Description |
|---|---|
| The unique enforcement ID. |
| The type of counter this enforcement refers to; input (0), output (1) or total (2). |
| The level at which this enforcement is triggered. Can be a percentage or absolute. Levels that are less than, or equal to 1, will be interpreted as a percentage value. |
| The name of this enforcement. |
| See Misc Field (4.3) for more information. |
Below is a screenshot of the UDR Assistance displaying the Enforcement UDR:
Enforcement UDR
Example - Enforcement UDR
The following values:
ID=605 CounterType=1 Level=0.75 Name='LEVEL_75' ID=607 CounterType=1 Level=0.5 Name='LEVEL_50'
will give the following setup:
The two enforcements have the IDs 605 and 607, which are used by the Products UDR.
Both enforcements refers to output traffic.
The first enforcement is triggered at 75 %, while that second enforcement is triggered at 50 %.
The name of the first enforcement is LEVEL_75 , while the name of the second enforcement is LEVEL_50 , and these names can be used in attributes in RulesMapping, for example.
Notification UDR
With the Notification UDR you can configure notifications to be sent out at different usage levels. Each product can use several notifications.
Field | Description |
|---|---|
| The unique ID for this notification. |
| The name of this notification. |
| The type of counter this notification refers to; input (0), output (1) or total (2). |
| The usage level at which this notification is triggered. Can be a percentage or absolute. Levels that are less than, or equal to 1, will be interpreted as a percentage value. |
| Indicates whether the notification should be required or not. If this field is set to false, the notification will not be sent unless it has been stated in the Subscriber UDR, see Subscriber UDR in Buckets Data Model (4.3). If this field is set to true, the notification will always be sent regardless of what is stated in the Subscriber UDR. |
| The type of notification, for instance SMS or email. |
| The address the notification should be sent to. |
| The message to be sent as part of the notification. |
| This field can contain information about product ID or product name, for instance. See Misc Field (4.3) for more information. |
Below is a screenshot of the UDR Assistance displaying the Notification UDR:
Notification UDR
Example - Notification UDR
The following values:
ID=700 Name='FIRST' CounterType=2 Level=0.60 Required=false Type='SMS' Address='10.10.10.700' Message='PCC Notification: 60% reached' ID=702 Name='SECOND' CounterType=2 Level=0.90 Required=true Type='SMS' Address='10.10.10.700' Message='PCC Notification: 90% reached' ID=703 Name='THIRD' CounterType=2 Level=1.00 Required=true Type='SMS' Address='10.10.10.700' Message='PCC Notification: 100% reached'
will give the following setup:
The three notifications with IDs 700, 702 and 703 have the names First , Second and Third .
All three notifications will trigger based on the total number of bytes.
The First notification will be triggered at 60 %, the Second at 90%, and the Third at 100 %.
The First notification is not required, while the Second and Third> are required.
All three notifications will be sent as SMSs.
All three notifications will be sent to IP address
10.10.10.700.