Session Management Policy Session Communication

When a policy session is initiated, MATRIXX Engine uses the Diameter Gx Interface to communicate with the PCEF.

Figure 1 shows how MATRIXX Engine with the MATRIXX Policy Application communicates with the PCEF using Gx policy sessions.
Figure 1. MATRIXX Engine Connecting to PCEF
Showing how MATRIXX processing server connects to a PCEF using Gy (OCS) and Gx (PCRF).
MATRIXX Engine communicates with the following external entities:
MATRIXX Charging Application exchanges the following messages with the PCRF during a usage session, as shown in Figure 2:
  • Credit-Control-Request (CCR) — Carries the event-trigger parameter to MATRIXX Engine PCRF.
    The three types of CCRs are:
    • Initial — Opens a Gx session.
    • Intermediate — Updates an existing Gx session.
    • Termination — Terminates a Gx session.
  • Credit-Control-Answer (CCA) — MATRIXX Policy Application provisions the PCC rules in a CCA message.
  • Re-Auth-Request (RAR) — RARs are sent when MATRIXX Policy Application determines that a policy has changed because of changes to subscriber data or balances in MATRIXX Charging Application.
  • Re-Auth-Answer (RAA) — Acknowledges receipt of the RAR.
Figure 2. Gx Policy Messages
MATIRXX PCRF Gx messages used to connect to a PCEF.
Note: Time-of-day normalizations used in Gx policy calculations (which are themselves based on event time) use the UTC-offset from the TgppDeviceTimeZone in the CCR. When generating a Gx RAR, the UTC-offset from the TgppDeviceTimeZone in the most recent Gx CCR for the session is used.

For more information about support for the Diameter Interfaces, see MATRIXX Diameter Integration.

A policy session is deleted if a Gx RAA is not received after the Gx RAR has been sent the maximum number of times.

Policy Session Profile Selection

The policy used in a session is the result of merging all the profiles selected in the session. The policy contains the union of the PCC rules and event triggers from all of the selected profiles. For each of the other properties in the profile, if one of the properties is contained in multiple profiles and the values are not exactly the same, then the property value from one profile is chosen and the property values in the other profiles are ignored and a warning is logged. The warning indicates the conflicting property and the profile for which properties are ignored. For example: 
LM_WARN 16793|16793 2018-03-08 13:35:49.126090
[rating_tester(5060.50438)] | 
charging_task::RatingOps::addGxMiscData: Conflicting values in Gx
CC and policy profile GxPolicyProfile:50010. The conflict is
different_field_counts. Ignoring value in policy profile
GxPolicyProfile:50010

For information about the Gx Policy profile properties, see My MATRIXX Help.

Policy Session Events

Gx policy session events are generated when the following requests are processed.
  • When a Gx CCR-I is processed, an MtxPolicyChangeEvent is generated. The event type is policy_session_start.
  • When a Gx CCR-U is processed and the selected policy profile changes, an MtxPolicyChangeEvent and an MtxPolicyChangeNotification are generated. The event type is policy_change. Event triggers cause the PCEF to send a CCR-U. Event triggers are events known to the PCEF but unknown to MATRIXX Policy Application.
  • When a Gx RAR is processed and the selected policy profile changes, an MtxPolicyChangeEvent and an MtxPolicyChangeNotification are generated. The event type is policy_change.

Details for the offer that selected the policy profile are added to the AppliedOfferArray or AppliedBundleArray. The array identifies a single policy profile. UsageQuantity, UsageQuantityUnit, and tax information in the MtxEventAppliedOffer are not applicable.

For more information about MtxPolicyChangeEvent and MtxPolicyChangeNotification, see MATRIXX Integration.

Gx-Rx Session Relationships

MATRIXX Policy Application can establish multiple Gx and Rx sessions for a single device. Each Gx session provides a Framed-IP-Address or Framed-IPv6-Prefix that uniquely identifies that Gx session across all devices. If you answer n to the following question, an Rx AAR-I must include a device identifier such as the IMSI or MSISDN. If you answer y, an Rx AAR-I can omit the device identifier. Each Rx session must then specify the same address or prefix as an existing Gx session for that device.

create_config.info question: Global:Session:Policy:Index Gx session by Framed-IP-Address/Framed-IPv6-Prefix value so that initial Rx AAR with the same value can locate the device (y/n)?

After the device is located, Gx sessions are identified as follows:
  • If the addresses are IPv4, MATRIXX Policy Application selects the Gx session with the same address as the Rx session.
  • If the prefixes are IPv6, from any Gx session(s) where the Rx prefix begins with the Gx prefix (for example: 2001:db8:1111:2222::/64 begins with itself, 2001:db8:1111::/48, and 2001:dba::/32), MATRIXX Policy Application selects the Gx session with the longest prefix, with an exact match being the best possible match.

MATRIXX Policy Application then exchanges Gx and Rx data between these sessions.

Sometimes, the Gx PCEF might try to establish a new Gx session with the same address or prefix as an existing Gx session. In this case, MATRIXX Policy Application immediately terminates the old Gx session without issuing a Gx ASR to cancel that session. It then manages Rx sessions with the same address or prefix as the new Gx session as follows:
  • If all sessions were established for the same device, MATRIXX Policy Application continues to exchange data between the new Gx session and those Rx sessions.
  • If the new Gx session was established for a different device, MATRIXX Policy Application instead requests to cancel those Rx sessions (Rx ASRs) from the original device.
Note: When the PCRF receives an Rx AAR, if Gx Policy selection was unsuccessful, the PCRF returns an Rx AAA with the Experimental-Result Diameter AVP containing:
Experimental-Result-Code: REQUESTED_SERVICE_NOT_AUTHORIZED (5063)

Gx Session Support for Emergency Calls

MATRIXX allows your mobile subscribers to place emergency calls.

This is enabled through support for emergency Access Point Name (APNs) and dedicated Gx sessions. When mobile subscribers place an emergency call, the emergency AVP is sent by the Application Function (AF) over the Rx interface to the MATRIXX PCRF.

The two main aspects to handling emergency calls are:
  • Network operators decide to handle emergency calls using a dedicated IP-CAN session towards the emergency APN. A Gx session is established by the PCEF for the sole purpose of controlling policy for the emergency sessions. MATRIXX Policy Application installs static or dynamic rules, and command-level (session level) QoS, according to each operator's emergency session handling policies.
  • When an emergency call is established, the IMS (Rx interface to MATRIXX PCRF) is used. MATRIXX Policy Application uses IP flow/gating information in the Rx AAR message and the presence of the Service-URN AVP and its values (for example, sos, sos.fire, sos.police and sos.ambulance) to select an appropriate policy profile. You must configure PCC rules and policy profiles in My MATRIXX for your specific emergency call handling procedures.
The above behavior is enabled by the following:
  • The Gx CCR-I includes the Called-Station-Id AVP, which identifies the emergency APN. In My MATRIXX, you can map this AVP (and other AVPs) to fields in a private MtxPolicySessionExtension custom MATRIXX Data Container (MDC). For details, see policy session mappings in My MATRIXX Help.
  • The initial Rx AAR includes the Service-URN AVP, which identifies an emergency service. It is automatically mapped to the ServiceUrn field in the MtxApplicationSessionExtension MDC.

Both of these Gx and Rx extension objects are available for normalization to support selection of standalone or Rx-based emergency PCC rules and QoS profiles.