IWF

InterWorking Function

Core Network →
Introduced in R99 Also in: Core Network, Management

IWF is a network function that enables communication between different network domains or technologies by acting as a protocol translator or gateway for seamless interworking and backward compatibility.

Category
Core Network
Introduced
R99
Where
Services › Codecs
Also touches
2 segments
Specifications
26 specs
IWF Description Purpose Related Classification Detected Changes Specifications

Description

The InterWorking Function (IWF) is a conceptual and functional entity within 3GPP architectures whose primary role is to ensure interoperability between disparate network systems. It is not a single, monolithic node but a logical function that can be implemented in various physical network elements depending on the specific interworking scenario. The IWF performs necessary adaptations, including protocol conversion, message mapping, signal translation, and media transcoding, to bridge technological gaps. It essentially hides the differences between the interconnected networks, allowing them to exchange information and deliver services as if they were part of a homogeneous system.

Architecturally, an IWF sits at the boundary between two network domains. For example, in early circuit-switched core networks, an IWF was used to interwork between GSM's MAP signaling and ISDN's DSS1 signaling. In the context of IP Multimedia Subsystem (IMS), an IWF can facilitate interworking between SIP-based IMS networks and legacy circuit-switched telephony networks, handling the conversion between SIP messages and ISUP/BICC signaling protocols. Another key instance is the Interworking IMS (IW IMS) function defined for service continuity between IMS and non-IMS domains. The IWF contains the necessary application logic and state machines to interpret incoming messages from one domain, map parameters and information elements to their equivalents in the target domain, and generate the corresponding outgoing messages.

From an implementation perspective, the IWF function may be integrated into existing nodes like a Media Gateway (MGW) for media plane interworking or a Media Gateway Control Function (MGCF) for signaling interworking in IMS. It manages critical tasks such as address translation, codec negotiation and adaptation, bearer establishment coordination, and supplementary service mapping. Its operation is defined in numerous 3GPP specifications covering areas like core network signaling, IMS, emergency services, and messaging. The IWF is a fundamental enabler for service continuity, roaming, and the phased migration from legacy networks to new 3GPP systems, ensuring that subscribers can communicate and access services across technological generations.

Purpose & Motivation

The IWF exists to solve the fundamental problem of heterogeneity in telecommunications. Networks evolve through generations (2G, 3G, 4G, 5G) and coexist with other fixed and wireless technologies. Without interworking functions, these networks would be isolated islands, unable to communicate or share services. The IWF was motivated by the need for backward compatibility during network transitions and for enabling seamless service delivery across multi-vendor, multi-technology environments.

Historically, one of the first major needs for an IWF arose with the introduction of GSM, which required interconnection with the existing global PSTN/ISDN fixed networks. This required translating between GSM-specific MAP signaling and the ISUP signaling used in fixed networks. As networks evolved to packet-switched cores and IMS, new interworking challenges emerged, such as connecting SIP-based VoIP services to the legacy circuit-switched voice network. The IWF addresses the limitations of previous siloed approaches by providing a standardized point of adaptation, defined in 3GPP specs, which allows for predictable and interoperable connectivity.

Furthermore, the IWF concept enables convergence and service innovation. It allows new network capabilities (like rich communication services in IMS) to be made available to users on legacy networks, and vice-versa. It is crucial for emergency calls, lawful interception, and roaming scenarios where a user on one network type must access services in another. By abstracting the complexity of protocol differences, the IWF reduces integration costs for operators and ensures a consistent user experience, which was a key commercial and technical driver for its pervasive use across 3GPP standards.

Classification

Part ofIMS
Related approachesMGCFMAPISUP

Release Timeline

Detected Changes Across Releases

from 3GPP Change Requests

Specific changes extracted from the „Change history“ tables of 3GPP specifications (47 CRs across 4 releases). Complements the general historical overview above with the evidence-based evolution of this function.

Rel-15 6 changes

In Release 15, the InterWorking Function (IWF) was enhanced with specific actions for handling Imminent Peril Group Calls and received fixes for its SDS (Short Data Service) functionality. Furthermore, the release introduced the mapping of the extended AccessRestrictionData parameter within the IWF. These updates improved the IWF's capability to manage specialized emergency services and user access control in interworking scenarios.

  • IWF actions on Imminent peril group calls TS 23.283CR0008
  • IWF SDS fix TS 23.283CR0017
  • IWF actions on Imminent peril group calls TS 23.783CR0008
  • IWF SDS fix TS 23.783CR0017
  • Mapping of ext-AccessRestrictionData in IWF TS 29.305CR0063
  • Mapping of ext-AccessRestrictionData in IWF TS 29.305CR0063
Rel-16 37 changes

In Release 16, the IWF function was enhanced with new capabilities for managing group communications, including the introduction of preconfigured groups, temporary group calls, and preconfigured broadcast group calls. Key procedural additions allowed for dynamic user regrouping with these preconfigured groups and the addition of implicit floor requests to group call and imminent peril group call requests. Furthermore, location information was integrated into floor control messaging, with specific alignments made for talker location in group call, chat group, private call, and imminent peril group procedures.

  • IWF preconfigured groups TS 23.283CR0038
  • IWF add user to temporary pre-configured group regroup TS 23.283CR0039
  • IWF temporary group calls TS 23.283CR0041
  • IWF user regroup with pre-configured group TS 23.283CR0042
  • IWF preconfigured broadcast group calls TS 23.283CR0044
  • IWF preconfigured broadcast group calls TS 23.283CR0045

+ 31 more changes

Rel-17 3 changes

In Release 17, the key updates for the IWF included the restoration of the IWF functional alias and the addition of a Conference Event Package capability to the IWF. These changes enhanced the IWF's interoperability and service support, though the grounding context does not provide specific technical details on these new procedures.

  • IWF functional alias restoration TS 23.283CR0046
  • IWF functional alias restoration TS 23.783CR0046
  • Add Conference Event Package to IWF TS 29.379CR0010
Rel-19 1 change

In Release 19, the primary update for the InterWorking Function (IWF) was a correction to its participating role procedures specifically for Adhoc group calls. This refinement ensures proper operational behavior within the defined procedures for this call type. The change focuses on the IWF's function in managing the air interface and fixed network user rates for these communications.

  • Correction to IWF participating role procedures for Adhoc group call TS 29.379CR0033

Explore further

Broader topics and technologies where IWF plays a role.

Defining Specifications

3GPP specifications that define or reference IWF, with the latest known release. Sourced from the 3GPP document catalog — see methodology.

SpecificationTitleRelease
TR 21.905 vj00 3GPP Technical Terms and Definitions Rel-19
TR 22.945 v1300 Fax Services Guidance for GSM/UMTS Rel-4
TS 23.054 v1300 Shared Interworking Function (SIWF) Stage 2 Rel-4
TS 23.146 vj00 3G Facsimile Group 3 Technical Realization Rel-19
TS 23.228 vj50 IMS Stage-2 Service Description Rel-19
TS 23.231 vj00 SIP-I based CS core network stage 2 Rel-19
TS 23.283 vk00 Mission Critical Communication Interworking Rel-20
TS 23.782 vf00 Interworking between LTE MC and non-LTE MC systems Rel-15
TR 23.783 vi00 Technical Report on Mission Critical Services over 5GS Rel-18
TR 23.910 v1400 UMTS Circuit Switched Bearer Services Overview Rel-5
TR 23.976 vj00 Push Service Requirements Analysis Rel-19
TS 24.229 vj50 IMS call control protocol based on SIP and SDP Rel-19
TS 24.523 vj00 NGCN-NGN Interconnection Scenarios Rel-19
TS 24.525 vj00 Business Trunking Architecture & Requirements Rel-19
TS 24.883 vg00 MCPTT Interworking with LMR Systems Rel-16
TS 25.424 vj00 UTRAN Iur Interface Data Transport & Signalling Rel-19
TR 26.930 vj00 WebRTC Enhancements for Immersive RTC over 5G Rel-19
TS 28.702 vj00 Core Network NRM IRP Information Service Rel-19
TS 29.305 vj00 Interworking Functions for EPS-Legacy Systems Rel-19
TS 29.368 vj00 Tsp Reference Point Stage 3 Specification Rel-19
TS 29.379 vj00 MCPTT call control interworking with LMR systems Rel-19
TS 29.421 v810 IMS Interworking with External IP Networks Rel-8
TS 29.805 v800 IWF for MAP-Diameter Interworking Rel-8
TS 32.632 vb00 Core Network Resources IRP: Network Resource Model Rel-11
TS 32.732 vb00 IMS Network Resource Model IRP: Information Service Rel-11
TS 33.180 vk00 Security of Mission Critical (MC) Service Rel-20
Patrick Zandl

About the author: Patrick Zandl (b. 1974)

Telecommunications specialist, technology journalist (founder of the Mobil server), and developer who has been running since 2025 — the largest Czech-language resource on AI-assisted programming. Formerly Chief Wizard Architect at Prusa3D and head of development for Turris at CZ.NIC; currently a consultant and instructor on AI implementation in companies.