top button
Flag Notify
    Connect to us
      Site Registration

Site Registration

SS7 - Diameter Interworking Function i.e. IWF

+1 vote

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

High Level IWF Network Overview

IWF use cases

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 -
Squire Technologies -
Jinny Software -
Diametriq Software -
Dialogic -
Broad Forward -

(Hiding my Identity)

posted Nov 4, 2014 by anonymous

  Promote This Article
Facebook Share Button Twitter Share Button LinkedIn Share Button

Related Articles

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.

enter image description here

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)
enter image description here

  1. 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
  2. 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.
  3. 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.

enter image description here

  1. 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.
  2. 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.