Virtual Fields

You use virtual fields to avoid creating multiple pricing configurations if your MATRIXX environment accepts multiple rating message types, for example, messages from Diameter and 5G networks.

Virtual fields enable you to create a single pricing configuration for different message types. For example, this is useful for creating event field mappings. Without virtual fields, you would have to create two different mappings, for example, one for Diameter messages and one for 5G messages. Instead, you can define a virtual field with two different field values for the different message types. When the Charging Server processes an incoming message, it determines the message type and selects the appropriate field to use for rating.

Each virtual field includes:
  • A unique name.
  • A list of containers, such as MtxDiamRoMsg, MtxMultiServiceData, or Mtx5GChargingDataRequest.
  • A list of field names corresponding with the container, such as the SessionMessageId field of the MtxDiamRoMsg container, RatingGroupId field of the MtxMultiServiceData container, or the CalledStationId field of the Mtx5GChargingDataRequest container.
  • Optionally, a list of parameter definition IDs corresponding with the catalog item parameters.
Note: The fields in a virtual field must use the same data format, but they do not have to list the same values.
You can specify virtual fields using the list of containers and the list of field names. During rating, the Charging Server gets the value for the virtual field from one of the MATRIXX Data Container (MDC) fields in the defined list by going through the list and using the value of the first MDC field that is available. The supported Diameter data containers are:
  • MtxDiamRoMsg and its descendants.
  • MtxMultiServiceData and its descendants.
The supported 5G data containers are:
  • Mtx5GMsg and its descendants.
  • Mtx5GChargingDataRequest and its descendants.
  • Mtx5GChargingDataResponse and its descendants.
  • Mtx5GMultiUnitUsageData and its descendants.
  • Mtx5GMultiUnitInfoData and its descendants.
Other supported data containers include:
  • Descendants of the MtxChargingSessionObject.
  • Descendants of the MtxPolicySessionObject.
  • Descendants of MtxPurchasedOffer.

MtxMultiServiceData, Mtx5GMultiUnitUsageData, and Mtx5GMultiUnitInfoData are available during usage rating only when the Charging Server processes each rating group (or service context) in the Diameter Ro or 5G messages.

You can also specify virtual fields using a list of parameter definitions IDs from a list of catalog item parameters as the potential source for the value of the virtual field. If the Charging Server does not get a value from the list of MDC fields, and there are catalog item parameters that were used to purchase the applied catalog item, then the Charging Server goes through the list of catalog item parameters and picks the first matching parameter to get the value for the virtual field.

You can select multiple data container and field pairs and multiple catalog item parameters to derive a virtual field.

When you specify a field name for the virtual field definition, if a list of array fields is used in the field name, the first element in the list or array is used. The Charging Server does not support indexes to specific elements in a list or array. If a virtual field is specified from a catalog item parameter, the parameters are stored in an array, so the parameter definition ID is used to match the correct parameter with the virtual field.

You create virtual fields in My MATRIXX. Once created, the fields can be selected in My MATRIXX container/field menus in pricing configurations.

If the value for the virtual field is obtained from an MDC field, you can use virtual fields in these pricing objects:
  • MtxEventFieldMap:
    • As the source of event field mapping for an event type object.
    • As the source of event field mapping and aggregation for a service type object.
    • As the source of audit data field mapping for a service type object.
  • MtxSessionFieldMap — As the source of session field mapping for a service type object.
  • MtxMatrix — The scale basis in a rate table.
  • MtxNormalizerRev — Comparand fields in a normalizer.
  • MtxCalledStationSearch — Callee (that is, the B party) search field in a normalizer.
  • MtxAttrDefn — Field specified in attribute definition.
  • MtxAggregationFieldDefn — For a composite meter aggregation group.

If the value for the virtual field is obtained from a catalog item parameter, you can use virtual fields in these pricing objects:

  • MtxMatrix — The scale basis in a rate table.
  • MtxNormalizerRev — Comparand fields in a normalizer.
  • MtxCalledStationSearch — Callee (that is, the B party) search field in a normalizer.
Note: Virtual fields are not supported for other MATRIXX capabilities, such as selective updates or REST filters. Also, for some pricing object types (for example, normalizers and scale bases), the values for virtual fields can be derived from MDC fields or catalog parameters. However, for other pricing objects, the value can be derived only from MDC fields. This is because virtual field values can be derived from catalog item parameters only for the listed pricing objects.