Diameter Multiple-Service Credit Control (MSCC)

A single network message using the Diameter Credit Control Application (DCCA) can include usage for multiple service contexts in one session. In such cases, the MATRIXX Charging Application rates usage for each service context individually and creates a separate Event Detail Record (EDR) for each one.

Service contexts offer a way to individually rate different types of usage within a single session. For example, a subscriber might use a mobile device to send an SMS, watch a streaming video, and download an mp3. Although each context corresponds to a different type of usage within a session, all service contexts must be within the same overall service type, as defined in the pricing plan configuration. The service type determines which product offers are applied, so the same set of product offers applies to all service contexts. This allows you to set up pricing for each service context based on the used quantity type, rather than charging a set rate regardless of the usage. A Diameter Credit Control message can report multiple types of used quantity for each context type, and request multiple types of quantities.

The MATRIXX Charging Application uses one of these quantity types for charging and authorization. The quantity to use and the quantity type unit can be different for each service context. The DCCA does not specify which quantity type units a subscriber consumes and which currencies or assets to charge. This is left to the service context. Each one must be specified individually for that context.

Examples of units consumed:
  • Time
  • Upload/download bytes
  • SMS
Examples of balances charged:
  • United States dollars
  • Gaming points
  • SMS

The MATRIXX Charging Application also handles sessions that report multiple unit types used against a single balance. For example, a subscriber might pay during a session and the volume downloaded in a session with the same currency balance.

To support multiple service contexts, the MATRIXX Charging Application individually tracks the used quantity, authorized quantity, and balance reservations for each service context within a session, and stores the requested quantity, used quantity, and granted quantity (authorized amount) for each service context. This provides credit control capabilities throughout the duration of the session. In addition, services that rate usage based on beats can have a beat group defined for it. The beat group identifies two or more service contexts that can share the rounded up amount that is charged to handle the beat. For example, say a data service definition includes a beat of 10k and a beat group that has context A and context B. During rating, if context A uses 3k, 10k is charged to the balance and the unused 7k is reserved for further usage by that service context or by context B. If context B then uses 3k, the 3k is subtracted from the beat reservation rather than being charged to the balance. When the remaining beat reservation is consumed completely, the next usage amount is rounded up to the beat amount, if necessary, and the unused amount reserved for further usage by any service context defined for that beat group.

You define service contexts for a service type when configuring a pricing plan. The service type definitions contain the service context information, including quantity type, quantity unit, and minimum authorization amount.
Note: If a service context is received but is not identified by its ServiceId in the service type definition, the quantity type and quantity unit defined for the service type are applied.

For more information about defining service types, see the discussion about creating service types in My MATRIXX Help.

Identifying Services and Contexts in a Network Message

Each Diameter message must be associated with exactly one service type. The service type is identified by the ServiceTypeObjectId field of the MtxDiamRoMsg MATRIXX data container (MDC). This field must have a value, and the value must correspond to the ID of a service type object in the Pricing database. Typically, a selective update is configured to assign a value to ServiceTypeObjectId based on the value of the Diameter Service-Context-Id AVP.

Each category of usage in a Diameter message is represented by an MtxMultiServiceData MDC in the MultiServiceList of the MtxDiamRoMsg MDC. For multiple-category (MSCC) messages, one MtxMultiServiceData MDC is generated for each Multiple-Services-Credit-Control AVP in the message. For single-category (non-MSCC) messages, one MtxMultiServiceData MDC is generated for the message itself. Each MtxMultiServiceData MDC is associated with a context type ID whose value comes from one of the following, in order of precedence:
  1. MSCC Service-Identifier AVP
  2. MSCC Rating-Group AVP
  3. External Service-Identifier AVP

If there are multiple MSCC contexts, the ServiceId is determined by the first AVP to arrive in the Diameter packet (the MSCC Rating-Group AVP or the MSCC Service-Identifier AVP). If the MSCC Service-Identifier AVP and the external Service-Identifier AVP both have values, the MSCC Service-Identifier AVP value is used.

If the context type ID for a category of usage corresponds to the ID of a context type object in the Pricing database, that context type determines how usage is handled. Otherwise, the service type determines how that usage is handled.

For single-category (non-MSCC) messages, assignment of the ServiceTypeObjectId can be determined by both Service-Context-Id and Service-Identifier to place each category of usage into its own service type, rather than as multiple contexts within a single common service type.

Important: If a CREDIT-CONTROL REQUEST (CCR) is received with two MSCC AVPs with the same Service-Identifier AVP value or a CCR is received with two MSCC AVPs with the same Rating-Group AVP value and at least one of the MSCC AVPs does not have a Service-Identifier value, the Charging Server logs an error message and rejects the CCR.
A CCR can include the Multiple-Services-Indicator AVP with a value of 0 (MULTIPLE_SERVICES_NOT_SUPPORTED) or 1 (MULTIPLE_SERVICES_SUPPORTED) to indicate whether the client is capable of handling multiple services independently.
  • If the CCR indicates that it supports multiple services, its Credit-Control Answer (CCA) includes one Multiple-Services-Credit-Control AVP for each requested service with the Result-Code AVP and additional AVPs for that service.
  • If the CCR indicates that it does not support multiple services, its CCA includes one Multiple-Services-Credit-Control AVP for the single requested service. It also uses the Result-Code AVP at the message/command level to indicate if the request failed, which results in termination of the underlying session.

If the CCR does not include the Multiple-Services-Indicator AVP, its CCA uses the Result-Code AVP and additional AVPs only at the message/command level.