Service Types

Each network message received for subscriber usage is associated with a service type, and each category of usage within the network message is associated with a service context.

Each service type and its service contexts control how that category of usage is authorized, charged for, and aggregated. Additionally, the service type controls the product offers that are applicable for rating the usage and the type of Event Detail Record (EDR) that is put in the MATRIXX Event File (MEF) file. The price components in a product offer all must be of the same service type, but a bundle can contain product offers associated with different service types.

You can create new service types and service contexts as part of application configuration by using My MATRIXX. The definitions are stored as objects in the Pricing database and the service names are displayed in My MATRIXX as nodes in the Price Components tab as descendants of the Usage service. Each service type can have its own child service types. For example, a usage service type can be the parent of a Mobile service type, which can be the parent of Satellite, Cellular, and Wi-Fi service types.

A service type can be the parent of any number of service contexts, which support the Diameter Multiple-Services-Credit-Control (MSCC) AVP. They allow you to define information about a per-context basis, including event usage aggregation and Adaptive Quota Management (AQM).

A service context is similar in many ways to a service type, but is different in the following important ways:
  • Each network message is associated with exactly one service type and all network messages in a session must use the same service type. (If a single network message or session carries multiple categories of usage, each category might be associated with its own service context.)
  • Offers are selected based on the service type and ancestor service types of the network message. If a service type has categories of usage of different quantities (for example, voice-over-IP versus data), offers for that service type might have separate usage components for each quantity. If the service type has multiple categories of usage of the same quantity, its offers must normalize on category-specific fields in the network message to discriminate based on category.
  • MEF event types and event-field mappings are selected by service type, not service context.
Each service type or service context inherits event-type mappings from its ancestor service types. In the following examples illustrating the differences between service types and service contexts, Voice, Data, and SMS (whether defined as service types or service contexts) inherit mappings from Cellular, which inherits mappings from Mobile, which inherits mappings from usage.
Note: Quota management parameters are not inherited.
  • A service type named Cellular with service contexts Voice, Data, and SMS allows a single Cellular session to carry all three categories of usage. Offers for usage, Mobile, or Cellular service types might apply different pricing for Voice and Data either by charging for one in seconds and the other in bytes or by normalizing on fields in the network message to determine which category is being rated.
  • A service type Cellular with child service types Voice, Data, and SMS requires a separate session for each of these three categories of usage. However, each service type could have its own offers, event types, event-field mappings, and even context types (for example, the Data service type could have context types Email, Video, and web).

You can query information about a service type's context using the MtxRequestPricingQueryServiceContext SubMan API. For more information about the service APIs, see MATRIXX Subscriber Management API.

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.

Rating and Session Field Mapping

During session field mapping, you must specify the data in each rating group (the service context) that is copied and used during rating (in normalizers). The Charging Server performs session field mapping to copy this data to the session object and context data.

After creating a session object, MATRIXX Charging Application uses the session field mapping that you define in My MATRIXX to copy fields at the message level only and sets the fields in the Attr field in MtxChargingSessionObject. When a new message is received for the session, session field mapping for the session object is performed to update the message-level data in MtxChargingSessionObject.Attr.

When a Requested-Service-Unit (RSU) is received, session field mapping occurs for the session context object of the rating group:
  • Fields are copied from MtxChargingSessionObject.Attr to MtxSessionContextData.Attr.
  • Context-level data (fields for a rating group) is copied to the session context object (MtxSessionContextData.Attr).

The data in MtxSessionContextData.Attr is used for rating (normalizers) and event generation (event field mapping for aggregated and non-aggregated events).

When a Used-Service-Unit (USU) is received, message and context-level data in the session context object of the rating group (MtxSessionContextData.Attr) is used for rating.

The following differences exist for offline and online charging:
  • Online Charging — USUs are always processed before RSUs. The session context object for processing a USU has the same message and context-level data used for prior authorization.
  • Offline Charging — When the USU does not have prior authorization, or when an RSU for a rating group is not sent before the USU, session field mapping for the session context object is performed before processing the USU. In this case:
    • The message-level data is copied from MtxChargingSessionObject.Attr to MtxSessionContextData.Attr.
    • The context-level data (fields for a rating group) is copied to MtxSessionContextData.Attr.
    • The data in MtxSessionContextData.Attr is used for rating and event generation.