SS7 - Diameter Interworking Function i.e. IWF

What is IWF

Despite a lot of LTE deployment in major part of the word there is still a good amount of legacy network exist which is based on SS7 i.e. CAP for charging and MAP for HLR functions. For reducing a risk of network outage lot of operators feels to have a requirement of Interworking Function which can convert the SS7(CAP/MAP) signalling to Diameter Signalling or vice-versa which created the milestone for IWF requirement and increases the ROI of existing network.

Network Overview

Use Case of IWF

LTE-EPC uses Diameter to access the core nodes like HSS, EIR for the network and OCS for charging. When EPC is interworking with legacy PLMN, there is a need to use existing legacy elements like the HLR, EIR and Prepaid SCP with SS7 with TDM or Sigtran with IP. Also when HSS, EIR and OCS are deployed or upgraded to use Diameter there may be a need for them to be used by legacy elements using SS7. In above cases we need a node which can convert the SS7 signalling to diameter signaling or vice-versa.
Standard: The 3GPP defines an IWF between Diameter and MAP in the spec 29.305 whereas there is no corresponding standard for Diameter to CAP.

Variants of IWF

Diameter to MAP
Diameter to CAP
Diameter to Radius
Diameter IPv4 to Diameter IPv6
Diameter TCP to Diameter SCTP

Vendors for IWF

F5 Technologies - http://www.f5.com/pdf/solution-profiles/ss7-interworking-solution-profile.pdf
Squire Technologies - http://www.squire-technologies.co.uk/products/ss7-map-to-diameter-interworking-function-functionality
Jinny Software - http://www.jinnysoftware.com/operator-challenges/managing-the-transition-to-4g-networks/diameter-signalling-management/diameter-gateway-iwf/
Diametriq Software - http://diametriq.com/diameter-interworking/
Dialogic - http://www.dialogic.com/en/products/diameter-signaling-controller/bordernet-diameter-services-helix.aspx
Broad Forward - http://www.broadforward.com/bfx-for-ss7/

(Hiding my Identity)

Interface between PCRF and PCEF i.e. Gx and the procedures involved there.

Gx Interface:

It is being used for exchange of signaling data. The Gx reference point is located between the PCRF (Policy Control and Charging Rules Function) and PCEF (Policy and Charging Enforcement Function).

The Gx reference point is used for provisioning and removal of Policy and Charging Control (PCC) rules from the PCRF to the PCEF and the transmission of traffic plane events from the PCEF to the PCRF. The Gx reference point can be used for charging control, policy control or both by applying AVPs relevant to the application.

Procedures over Gx interface:

The PCRF shall indicate via Gx interface PCC rules to be applied at the PCEF. This may be using one of the following procedures:

PULL procedure (Provisioning solicited by PCEF):

In response to a request for PCC rules being made by the PCEF, the PCRF shall provision PCC rules in the CCA (Credit Control Answer)

When an event-trigger event occurs, the PCEF sends a Credit Control Request (CCR-I in our case, because it's "Initial_Request") message that carries an event-trigger parameter to the PCRF, requesting to deliver PCC rules
The PCRF judges whether to update the PCC rules (namely, old PCC rules) according to the event-trigger, and returns a Credit Control Answer (CCA-I) message to the PCEF. If the PCC rules need update, the retuned CCA-U (CCR-U and CCA-U stand Credit Control Request/Answer Update_Request) message carries the updated PCC rules (namely, new PCC rules), and the PCRF stores both the old PCC rules and the new PCC rules.
After receiving the CCA message, the PCEF executes the PCC rules. If the returned CCA message carries the new PCC rules, the PCEF executes the new PCC rules; if the returned CCA message carries no new PCC rules, the PCEF executes the old PCC rules. When the PCEF executes the PCC rules unsuccessfully, the PCEF sends a new CCR message.

PUSH procedure (Unsolicited provisioning):

The PCRF may decide to provision PCC rules without obtaining a request from the PCEF, e.g. in response to information provided to the PCRF via the Rx interface, or in response to an internal trigger within the PCRF. To provision PCC rules without a request from the PCEF, the PCRF shall include these PCC rules in an RAR (Re-Auth-Request) message. No CCR/CCA (Credit Control Request/Credit Control Answer) messages are triggered by this RA-Request.

When an event-trigger event occurs, the PCRF updates the PCC rules, and sends a Re-Auth Request (RAR) message to the PCEF. The RAR message carries new PCC rules, and the PCRF does not store the old PCC rules.
The PCEF executes the new PCC rules delivered through the RAR message. After completion of the execution, the PCEF sends a Re-Auth Answer (RAA) message to the PCRF.

For each request from the PCEF or upon the unsolicited provision the PCRF shall provision zero or more PCC rules. The PCRF may perform an operation on a single PCC rule by one of the following means:
• To activate or deactivate a PCC rule that is predefined at the PCEF, the PCRF shall provision a reference to this PCC rule within a Charging-Rule-Name AVP and indicate the required action by choosing either the Charging-Rule-Install AVP or the Charging-Rule-Remove AVP.
• To install or modify a PCRF-provisioned PCC rule, the PCRF shall provision a corresponding Charging-Rule-Definition AVP within a Charging-Rule-Install AVP.
• To remove a PCC rule which has previously been provisioned by the PCRF, the PCRF shall provision the name of this PCC rule as value of a Charging-Rule-Name AVP within a Charging-Rule-Remove AVP.
• If, for certain accesses, the PCRF performs the bearer binding, the PCRF may move previously installed or activated PCC rules from one IP CAN bearer to another IP CAN bearer.