Normalization

MATRIXX Engine uses a process called normalization to condense large sets of discrete field values into a manageable set of parameters. Each single normalizer parameter value represents an aggregate value set, so that assigning a result to every possible field value is not required.

Figure 1 shows how a normalizer uses a specific algorithm to take a large data set and condenses it into discrete values that can be used as rating parameters.
Figure 1. Normalization Process
Figure 2 illustrates how normalization condenses large or continuous sets of data, including balance information, usage information, and customer data, and creates discrete values that can be used for rating.
Figure 2. Normalization Example
Normalizers are used during rating and policy processing to compare one or more parameters to a value and when it finds a match, it selects an index in a matrix. A matrix is a multi-dimensional array where each dimension corresponds to an individual normalizer parameter that is a factor in selecting a result. For each dimension of the matrix, there is a normalizer that produces an index for that dimension. A normalizer can be associated with any of the following matrices (decision table implementations).
  • Balance filters — The index leads to a balance or meter to update or, if a match is not found, the filter does not apply.
  • Balance state update tables — The index leads to a balance state update profile or a skip operation.
  • Final unit indicator tables — The index leads to a final unit indicator profile or a skip operation.
  • General ledger account tables — The index leads to a general ledger account or a skip operation.
  • General ledger transaction type tables — The index leads to a transaction type or a skip operation.
  • Offer priority generators — The index leads to a product offer to select, a skip operation, or a deny operation.
  • Policy tables — The index leads to a policy profile to use or, if a match is not found, a default to use.
  • Rate tables — The index leads to a rating formula or a skip operation.
  • Rollover tables — The index leads to a rollover profile to use a skip operation.
Note: When using Boolean normalizers, rating treats index 0 as false and index 1 as true.
A normalizer can select an index into a matrix based on a balance quantity, usage quantity, or field value. For field values, the field can be of any data type and can be located in or descendant from the following MATRIXX Data Containers (MDCs):
  • MtxMsg
  • MtxProductOfferExtension
  • MtxBalanceAdjustNormalizationInfo
  • MtxBundleExtension
  • MtxPurchasedOffer
  • MtxPurchasePackageExtension
  • MtxMultiServiceData
  • MtxApplicationSessionExtension
  • MtxChargingSessionExtension
  • MtxPolicySessionExtension
  • MtxDiamMediaComponentDescriptionData
  • MtxDiamMediaSubComponentData
  • MtxEventChargeNormalizationInfo
  • MtxRateTagNormalizationInfo
  • MtxSubscriberObject
  • MtxUserObject
  • MtxUserExtension
Note: When configuring normalization, normalization inputs should come from MDC fields with one of the following characteristics:
  • MDC fields that are not altered within rating (for example, through data modify actions or normalizer chaining).
  • Workspace MDC fields, which never have their results cached.

The MDC field cannot be a BLOB or a field key. If the field is a list or array, the first element is used. For more information about working with workspace MDC fields, see the discussion about message workspaces in MATRIXX Pricing and Rating.

For example, you can normalize on the StatusValue field in the MtxSubscriberObject to charge differently based on a subscriber's life cycle status, or on the EventTime field in the MtxDiamRoMsg MDC to charge differently based on the time the event occurred. In this case, you can use a time normalizer to create Peak, Off-Peak, and Weekend parameters that represent time ranges. The value received in the EventTime field gets mapped into one of these ranges to select an index in the matrix.

Fields can only be used within the context of a specific purchased offer, product offer, bundle, or catalog item. Post-rating generators and FUI generators are not in such a context and normalizers with fields from purchased offers, product offers, bundles, or catalog items cannot be used.

After getting a normalization result for each dimension, the results are used as an index to look up a specific cell in the matrix. The cell either references a rating formula, policy profile, balance or meter, or product offer, or it indicates that the matrix is not to be used and the next matrix in the list should be tried. Sometimes, no matrix from a component can be used. When this happens during authorization, it indicates that the maximum authorization amount has been reached, and no further usage can be authorized. If it happens when charging (when processing a stop-accounting message), the component is skipped for the segment.
Note: Normalizers have a size limit of 65535 rows. This limit also applies to decision tables, rate tables, and policy tables.
Figure 3 illustrates a time normalizer. In this example:
  • The Peak parameter represents all time points between 8 AM and 5 PM on weekdays.
  • The Off-Peak parameter represents all time points between 5 PM and 8 AM on weekdays.
  • The Weekend parameter represents all time points between 12 AM Saturday to 11:59 PM Sunday.
Figure 3. Peak, Off-Peak, and Weekend Time Normalizer

When a network message is received, the event's timestamp value and the event duration are used to map the usage to one of the normalizer parameters and that index is used. For example, if the normalizer is attached to a decision table and a subscriber makes a phone call from 8:00 AM to 8:20 AM on a weekday, the index associated with the Peak parameter is used. Depending on conditions during rating, such as credit limits and available balance amounts, the rating formula associated with that index might be used to charge for the call.

Normalizers enable you to set up one pricing structure and reuse it with any number of pricing items to get different results for the same structure. This is possible because the parameter values defined for the normalizers are independent from the result values you assign to them. For example, you can set up a time-of-day normalizer like the one in the example above, and attach it to a balance filter to determine which balance to impact, to a policy table to determine which policy profile to use, and to a decision table, to determine which rating formula to use.

In addition, any balance filter, policy table, decision table, or offer priority generator can contain multiple normalizers to introduce additional conditions that must be true for a result to be used. For example, a decision table for a 3G charge might be based on 3 factors:
  • Session Duration — First 60 Seconds and Remaining Time.
  • Access Type — On Network and Off Network.
  • Subscriber's Birthday — Yes and No.

Define one row for each possible combination of values that get assigned to a result. So in this example, the decision table would contain 8 rows: 2 × 2 × 2 or 2 Data Access Duration parameter values × 2 On Network parameter values × 2 Subscriber's Birthday parameter values.

Figure 3 shows an example of this rate table.
Figure 4. Rate Table with 3 Normalizers

The reusability of normalizers reduces pricing configuration time and speeds rating. The same data does not have to be loaded multiple times and the equations associated with each normalizer do not require recompilation.

In addition, if your installation includes both MATRIXX Charging Application and MATRIXX Policy Application, both rating and policy decisions can be set up with the same set of normalizers to define the metrics on which to base the decisions. For example, you can set up rates and policy profiles based on any combination of the following normalization values.
  • Balance quantity
  • Device type
  • Device, subscriber, or group life cycle status
  • service context
  • Service type
  • Subscriber ID
  • Subscriber email address
  • Subscriber IP address
  • Subscriber location
  • Time-of-day
  • Time zone
  • Usage quantity
  • Life cycle state of a subscriber, group or device
  • Tax location, tax status, and tax certificate

Normalization on the life cycle state allows pricing administrators to charge differently or to deny service based on the life cycle state. For example, pricing can be set up to charge subscribers with an active life cycle state a discounted rate and subscribers with an inactive life cycle state a regular rate.

For information about life cycles, see the discussion about status life cycles in MATRIXX Pricing and Rating. For information about MDCs that are valid for normalization, see the discussion about defining normalizer templates in MATRIXX Pricing and Rating. For information about dynamic tax selection, see the discussion about taxes in MATRIXX Pricing and Rating.