Rx Application Sessions

The MATRIXX Policy Application Rx interface gathers data from an external Application Function (AF), and uses it to construct and publish PCC and QoS rules over the Gx interface to an external Policy and Charging Enforcement Function (PCEF).

When an Rx policy session is initiated, it is associated with one Gx session, communicating through the MATRIXX Policy Application as a policy charging and rules function (PCRF). Internet and IMS traffic are served by separate Access Point Names (APNs). Each device usually has one Gx session per APN (2x Gx total) with PCC/QoS for each and separate Rx sessions for IMS signaling and IMS media (2x Rx total).

IMS is a concrete media application with IP flows related to 4G voice and video calls over LTE (VoLTE/ViLTE) and its Evolved Packet System (EPS). IMS is managed in part by the Proxy Call Session Control Function (P-CSCF) The P-CSCF acts as the Application Function (AF) opposite the MATRIXX PCRF on the Rx interface. It also acts as the Session Initiation Protocol (SIP) proxy to external network elements.

Figure 1 shows an Rx message flow example.
Figure 1. Rx Policy Message Flow

Rx Messages between the PCRF and AF

An external AF manages an Rx session with the PCRF by sending a series of AA-Requests (AARs) and Re-Auth-Requests (RARs), and finishes with a Session-Termination Request (STR). The authentication requests are sent from the external AF to initiate a new session or to update a session. MATRIXX Policy Application exchanges the following messages with the AF during an Rx usage session, as shown in Figure 1.
  • Rx AA-Request (AAR) — Sent from the AF to the PCRF acknowledging receipt of the AAA.
  • Rx AA-Answer (AAA) — Sent from the AF to the PCRF. Acknowledges receipt of the AA-Request (AAR).

    The initial AAR must include a Framed-IP-Address or Framed-IPv6 Prefix AVP identifying the same external IP-CAN session as an ongoing Gx session. During the session, the PCRF may send RARs with updates or an ASR to elicit an STR to terminate the session.

  • Rx Re-Auth-Request (RAR) — Sent from the PCRF to the AF to update application usage and to elicit an immediate Rx AAA or STA response.
  • Rx Re-Auth-Answer (RAA) — Acknowledges receipt of the RAR.
  • Rx Abort-Session-Request (ASR) — Sent from the PCRF to the AF to request termination of the Gx session (CCR-T) or termination of the Rx session (STR).
  • Rx Abort-Session-Answer (ASA) — Sent from the AF back to the PCRF to acknowledges receipt of the ASA.
  • Rx Session-Termination-Request (STR) — Sent from the AF to the PCRF to terminate the session.
  • Rx Session-Termination-Answer (STA) — Sent by the PCRF to the AF to acknowledges receipt of the STR.

Gx Messages between the PCRF and the PCEF

MATRIXX Policy Application exchanges the following messages with the PCEF during a Gx usage session, as shown in Figure 1.

  • Gx Credit-Control-Request (CCR) — Sent from the PCEF to the PCRF. Carries the event-trigger parameter to MATRIXX Engine PCRF that causes the Gx to publish data to the Rx. These are the CCR types:
    • Initial — Opens a Gx session.
    • Intermediate — Updates an existing Gx session.
      Note: The CCR-I must include the subscription ID AVPs identifying a device, and might include a Frame-IP-Address or Framed-IPv6-Prefix AVP identifying an external IP-CAN session assigned to the device.
    • Termination — Terminates a Gx session.
  • Gx Credit-Control-Answer (CCA) — Sent from the PCEF to the PCRF. MATRIXX Policy Application provisions the PCC rules in the CCA.
  • Gx Re-Authorization Request (RAR) — Sent from the PCRF to the PCEF update the session. Used to subscribe to Gx data. PCC rules are installed, modified, or removed based on the Rx AAR.
  • Gx Re-Authorization Answer (RAA) — Sent from the PCRF to the Rx to answer the RAR.

Rx Sessions

Internet and IMS traffic are served by separate Access Point Names (APN) or gateways to other networks. In general, the following apply:
  • Each device has one Gx session per APN (2x Gx total) with PCC/QoS for each.
  • Each device usually has separate Rx sessions for IMS signaling and IMS media (2x Rx total).
  • Rx IP data flows are arranged into components and sub-components, with one flow per sub-component.
    • For signaling, there is only one component with one sub-component/flow.
    • For media, there is one component per active media type (audio and video), each with two sub-components or flows, for a total of up to four flows:
      • Real-time transport protocol (RTP) for the actual A/V media.
      • RTP control protocol (RTCP) for out-of-band control over that media.
    • This results in upwards of 5x flows across both sessions.
For example:
  • Rx Session for IMS Signaling
    • Media-Component-Number = 0
    • Media-Sub-Component
      • Flow-Number = 1
      • Flow-Usage = 2 (AF_SIGNALLING)
  • Rx Session for IMS Media
    • Media-Component-Number = 1
      • Media-Type = 0 (AUDIO)
      • Media-Sub-Component
        • Flow-Number = 1
      • Media-Sub-Component
        • Flow-Number = 2
          • Flow-Usage = 1 (RTCP)
    • Media-Component-Number = 2
      • Media-Type = 1 (VIDEO)
      • Media-Sub-Component
        • Flow-Number = 1
      • Media-Sub-Component
        • Flow-Number = 2
          • Flow-Usage = 1 (RTCP)
Each flow can be uniquely identified by its pair of component and flow numbers to track each flow throughout the session. For example:
  • C0F1 = signaling
  • C1F1 = audio RTP
  • C1F2 = audio RTCP
  • C2F1 = video RTP
  • C2F2 = video RTCP

Rx-to-Gx AVP Abort-Cause Mapping

The Gx and Rx protocols share some Abort-Cause AVP codes related to reporting failures. Answer y to this create_config.info question: Global:Session:Policy:Notify:Enable mapping of Gx Rule-Failure-Code to Rx Abort-Cause (y/n)? to configure MATRIXX Policy Application to correlate these values so that if returned, they trigger an update to the status of a session across the other interface. Gx-to-Rx Abort-Cause Value Mapping lists the mapped values.
Table 1. Gx-to-Rx Abort-Cause Value Mapping
Gx RAR/RAA and CCR/CCA Rule-Failure-Code AVP Abort-Cause Values Rx RAR/ASR Abort-Cause Values
GW_PCEF_MALFUNCTION INSUFFICIENT_BEARER_RESOURCES
RESOURCES_LIMITATION
MAX_NR_BEARERS_REACHED
MISSING_FLOW_INFORMATION
INCORRECT_FLOW_INFORMATION
NO_BEARER_BOUND
FILTER_RESTRICTIONS
AN_GW_FAILED
RESOURCE_ALLOCATION_FAILURE BEARER_RELEASED
PS_TO_CS_HANDOVER PS_TO_CS_HANDOVER

The Gx Rule-Failure-Code AVP values (TS 29.212 V12.6.0 | 5.3.38) can be received in Gx RAR/RAA and CCR/CCA messages and are correlated with the Rx Abort-Cause values (TS 29.214 V14.3.0 | 5.3.1) received in Rx RAR/ASR messages.

Rx Message Flow Relationships

The following message relationships apply to Rx message communication:
  • The PCRF may send Re-Auth-Requests (RARs) during the session, with updates or an Abort-Session Request (ASR) to elicit a CCR-T to terminate the session.
  • When an Rx sends an AAR (or STR), the Rx and Gx policy sessions are updated; an Rx AAR can update IMS IP data flows and request Gx data (such as the device location). This includes updates triggered by a change (such as a change of location). A Gx RAR is sent and the Gx RAA is sent to update the Gx session, and then the Rx AAA (or STA) is sent to update the Rx session.
  • If the associated Gx session is lost, the PCRF sends and ASR to the AF. The AF then sends an STR to the PCRF to terminate the Rx session.
  • If there are changes to Gx data that the Rx session has subscribed to by including Specific-Action AVP values, a Gx RAR must be sent to the PCEF. For information about Specific-Action AVPs, see the discussion about Rx session specific actions.

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

Passing Rx Policy Profiles to the PCRF

MATRIXX Policy Application as the PCRF logs a policy event EDR (MtxPolicyChangeEvent) each time it receives an AAR (initial or updated) from an AF over Rx. That EDR includes the MtxApplicationSessionInfo and MtxApplicationFlowInfo arrays to pass details about selected policy profile. These arrays contain the policy profile, its media components, and flows.

For details about the MtxPolicyChangeEvent EDR, see the discussion about MtxPolicyChangeEvent in MATRIXX Integration.

Handling Duplicate Rx Sessions

MATRIXX Policy Application as the PCRF identifies and handles duplicate Rx sessions for a single Gx session. Duplicate Rx sessions can occur after an AF loses its connection with the PCRF. When the AF reconnects it may start a different Rx session with repeated IP flows/QoS information and a different Rx session ID. MATRIXX Policy Application checks whether rules have already been installed for the original Gx session and are up-to-date for Rx IP flow/QoS information. If so, it returns an AAA over Rx to the AF and closes the original session by sending and ASR over Rx to the AF. MATRIXX Policy Application does not reinstall rules that are already in force.

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)

Dynamic PCC Rules

Gx dynamic PCC rules for an Rx policy session are based on the QoS parameters defined in My MATRIXX or from the Rx AAA message sent to initiate a session. The includes:
  • Preemption capability and preemption vulnerability allocation retention priority status.
  • Maximum guaranteed upload and download bit rate.
  • Maximum requested bandwidth upload and download speeds.

The dynamic PCC rule values defined in My MATRIXX supersede any values in the Rx AAR or Gx CCR.

When processing an Rx AAR, the Media-Component-Description AVPs are merged into composite component and sub-component MDCs within the Rx MtxApplicationSessionObject. When processing a Gx CCR/RAR for a Gx session:
  • For all Gx sessions, all components with a policy basis of Gx session are applied.
  • For the IMS Gx session, for each Rx uni-enabled or bi-enabled flow, components with policy basis of Rx media sub-component are applied. Normalizers see its component and sub-component MDCs. Any Rx Specific-Action AVPs are collected to determine the Gx Event-Trigger. For more information about Specific-Action AVPs, see the discussion about Rx session specific actions.
The policy for each Gx session and for each linked Rx IP data flow is determined. Those selected for Rx flows should produce one dynamic PCC rule each. To configure this in My MATRIXX:
  • Create Gx dynamic PCC rules for Rx IP data flows. Each flow should have at least one applicable rule, although multiple flows may share a rule if they have similar requirements (such as audio and video RTCP control flows).
  • Create Gx policy profiles. There should be an applicable profile for the Internet APN/bearer, for the IMS APN/bearer, and for each Rx flow, although these may share if they have similar requirements.
    Note:
    • Each profile for an Rx flow should include at most one dynamic PCC rule.
    • Profiles with dynamic PCC rules can be selected for a Gx session (rather than Rx flow) but are of limited utility because there is no way to control which IP flows are governed by each rule; there is a hard-coded Flow-Description of “permit in ip from any to any” that cannot be configured or replaced (for example, by TDF-Application-Identifier).
  • Create Gx policy components. Each can be configured with a policy basis of Gx session or Rx media sub-component. There should be at least one component for each. These may use normalizers and decision tables to select different profiles for each Gx APN/bearer and for each Rx flow.
  • Create product offers including these components. Each may be global or associated with a catalog item.
  • Purchase the relevant catalog items for the device, subscriber, or group.
For example:
  • Rx Media-Component-Description
    • Flow-Status = ENABLED (2)
    • Max-Requested-Bandwidth-DL = 41000
    • Max-Requested-Bandwidth-UL = 41000
    • Media-Component-Number = 1
    • Media-Sub-Component
      • Flow-Description = permit in 17 from 10.57.191.226 49158 to 10.5.236.170 56388
      • Flow-Description = permit out 17 from 10.5.236.170 56388 to 10.57.191.226 49158
      • Flow-Number = 1
    • Media-Type = AUDIO (0)
  • Gx Charging-Rule-Definition
    • Charging-Rule-Name = IMS_AudioRule092D849B
    • Flow-Information–Flow-Description = permit in 17 from 10.57.191.226 49158 to 10.5.236.170 56388
    • Flow-Information–Flow-Description = permit out 17 from 10.5.236.170 56388 to 10.57.191.226 49158
    • Flow-Status = ENABLED (2)
    • Metering-Method = VOLUME (1)
    • Offline = ENABLE_OFFLINE (1)
    • Online = DISABLE_ONLINE (0)
    • Precedence = 0
    • QoS-Information
      • Allocation-Retention-Priority
        • Pre-emption-Capability = PRE-EMPTION_CAPABILITY_ENABLED (0)
        • Pre-emption-Vulnerability = PRE-EMPTION_VULNERABILITY_DISABLED (1)
        • Priority-Level = 1
      • Guaranteed-Bitrate-DL = 41000
      • Guaranteed-Bitrate-UL = 41000
      • Max-Requested-Bandwidth-DL = 41000
      • Max-Requested-Bandwidth-UL = 41000
      • QoS-Class-Identifier = QCI_1 (1)
    • Rating-Group = 100558100
    • Reporting-Level = SERVICE_IDENTIFIER_LEVEL (0)
    • Service-Identifier = 900001000

Configuring Rx Protocol Sessions

If the PCRF identifies a stale Rx policy session, the PCRF time to wait and retry attempts for an Rx RAR are specified in these create_config.info global system parameters:
  • Diameter Rx Notification Attempts — Sets the maximum number of notification attempts to try and obtain an answer. The default value is 1 attempt, which is also the minimum setting. There is no maximum setting. An Rx RAR is only considered successful if the AF responds with the return code success. A value of 0 disables retries and the session is removed immediately.

    create_config.info question: Global:Session:Application:Notify:How many attempts?

  • Diameter Rx Session Open Interval — Sets a time interval, in seconds, for how long a session remains idle until a notification is sent. The default is 172800 (48 hours), and the acceptable range is 1 to 2419200.
    create_config.info question: Global:Session:Application:Notify:How long (in seconds) to wait after the most recent activity before the first attempt?
    Note: This question is not applicable when using an external PCRF.
  • Diameter Rx Unanswered Notification Interval — Sets an interval, in seconds, for how long to wait before sending another notification if the most recent notification was not answered. The default is 15; the minimum is 1, and the maximum is 86400. If the AF fails to respond to an Rx RAR, this sets the number of seconds to wait before resending the Rx RAR.

    create_config.info question: Global:Session:Application:Notify:How long (in seconds) to wait after each attempt?

For details about these questions, see the discussion about global system configuration in MATRIXX Configuration.

Rx Policy Session Events

Processing the following events generates Rx policy session events:
  • When a Gx CCR-I is processed, an MtxPolicyChangeEvent is generated. It has an event type of policy_session_start.
  • When a Gx CCR-U is processed and the selected policy profile is changed, and 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 the MATRIXX Policy Application.
  • When an Rx RAR is processed and the selected policy profile changes, and MtxPolicyChangeEvent and an MtxPolicyChangeNotification are generated. The even 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.

SIP Forking

SIP forking can occur when UserA’s phone calls UserB, who can pick up on a phone or laptop. For example:
  1. Rx AAR to establish UserA's IMS media session with SIP-Forking-Indication = 1 (SEVERAL_DIALOGUES) and with each flow (as identified by component + flow number) repeated but with a different Flow-Description, QoS, and so forth, for each of UserB’s devices.
  2. Gx RAR to UserA's IMS Gx session with a single PCC rule per forked flow. This includes a Flow-Description and maximum QoS for that flow across all UserB’s devices.
  3. When one of UserB’s devices answers, receive an Rx AAR for UserA that repeats all flows, but only for that device.

Rx Media AAR 1

In this example, UserB's phone and laptop ring.
  • SIP-Forking-Indicator = 1 (MULTIPLE_DIALOGUES)
  • Media-Component
    • Media-Type = 0 (AUDIO)
    • Media-Component-Number = 1
    • Requested QoS for phone
    • Media-Sub-Component (RTP)
      • Flow-Number = 1
      • Flow-Description = permit
      • RTP from UserA to UserB (phone)
    • Media-Component
      • Media-Type = 0 (AUDIO)
      • Media-Component-Number = 1
      • Requested QoS for laptop
      • Media-Sub-Component (RTP)
        • Flow-Number = 1
        • Flow-Description = permit
        • RTP from UserA to UserB (laptop)
The following describes the Rx media AAR 1 as presented to the normalizer.
  • Media-Component
  • Media-Type = 0 (audio)
  • Media-Component-Number = 1
  • Union of requested QoS for phone and laptop
  • Media-Sub-Component (RTP)
    • Flow-Number = 1
    • Flow-Description = permit RTP from UserA to UserB (laptop)
    • Flow-Description= permit RTP from UserA to UserB (phone)
  • Resulting Gx RAR
    • Charging-Rule-Install for audio RTP:
    • Charging-Rule-Name = audio_rtp...
    • Flow-Description = permit RTP from UserA to UserB (phone)
    • Flow-Description = permit RTP from UserA to UserB (laptop)
    • Effective QoS for phone and laptop
Note: This example shows the audio RTP flow only. There would be RTCP flow and possibly video flows, too.

Rx Signaling AAR 2

In this example, UserB's phone answers.
  • No SIP-Forking-Indicator
  • Media-Component
    • Media-Component-Number = 1
    • Requested QoS for phone
    • Media-Sub-Component
      • Flow-Description = permit RTP from UserA to UserB (phone)
      • Flow-Number = 1
  • Resulting Gx RAR
  • Charging-Rule-Install for audio RTP
    • Charging-Rule-Name = audio_rtp...
    • Flow-Description = permit RTP from UserA to UserB (phone)
    • Effective QoS for phone
Note: This example shows the audio RTP flow only. There would be RTCP flow and possibly video flows, too.