Menu
Latest
12 meetings · Prague, Jeju · 12–16 Oct
Reports
RAN1#126-bis · SA2#177

Glossary term · Interface

WSDL

Web Services Description Language

Interface →

WSDL is an XML-based interface description language used in 3GPP to define the operations, data types, and endpoints of web services, serving as a machine-readable contract for automated client generation and interoperability.

Introduced
Rel-8
Where
Management
Specifications
31 specs
WSDL Description Purpose What changed Neighbours Specifications

Description

The Web Services Description Language (WSDL) is a fundamental technology within 3GPP for defining the technical interface of network-exposed web services. It is an XML schema that provides a formal, machine-readable description of how a service can be called, what parameters it expects, and what data structures it returns. In 3GPP architectures, WSDL documents are used to specify the northbound and southbound Application Programming Interfaces (APIs) for numerous network functions, particularly in the domains of Operations, Administration, and Maintenance (OAM), Policy and Charging Control (PCC), and network element provisioning.

Architecturally, a WSDL 1.1 document (the version predominantly referenced in 3GPP) is composed of several key sections. The 'types' section defines the complex data structures (using XML Schema - XSD) that are exchanged in messages. The 'message' section defines the abstract content of a communication, grouping parts into input and output messages. The 'portType' (akin to an interface in programming) groups related operations, each specifying an input and/or output message. The 'binding' section concretely specifies the protocol (e.g., SOAP over HTTP) and data format (e.g., document/literal) for a portType. Finally, the 'service' section defines the network address (URL) where the bound interface can be accessed.

How it works in practice is that a network function acting as a Web Service Provider (e.g., a Home Subscriber Server - HSS for provisioning) publishes its WSDL document. A client system, or Web Service Consumer (e.g., a Network Management System - NMS), retrieves this WSDL. Using standard development tools, the consumer can automatically generate client-side code (stubs) that knows exactly how to construct a valid SOAP request, which endpoint to send it to, and how to parse the SOAP response. This automation drastically reduces integration effort and errors. Its role in the 3GPP network is as the cornerstone of a contract-first, service-oriented design for network interfaces, enabling multi-vendor interoperability, dynamic service discovery, and the alignment of telecom network management with mainstream IT integration practices.

Purpose & Motivation

WSDL was adopted by 3GPP to solve the critical problem of precisely and unambiguously defining the programmatic interfaces for network functions exposed as web services. Prior to its use, interface definitions were often conveyed through lengthy textual documents (human-readable specs), which led to interpretation errors, inconsistent implementations across vendors, and manual, error-prone integration work. This increased costs, delayed deployments, and created fragile multi-vendor networks.

The historical driver was the 3GPP's move towards all-IP networks and the desire to leverage widely adopted IT technologies for network management (starting in Release 8 with SAE). Web services offered a standardized communication framework, but a service is only as interoperable as its definition. WSDL, as a W3C standard, provided the missing piece: a formal, platform-neutral contract. Its creation was motivated by the need for a language that could be processed by machines to automate the generation of client and server code, ensuring that both sides of the communication adhered to the same data formats and procedural rules.

It addressed the limitations of previous approaches like proprietary APIs or protocols described only in prose. By using WSDL, 3GPP could specify interfaces in a way that was both human-readable (as XML) and directly consumable by software development kits (SDKs). This enabled a 'design by contract' methodology, where the interface is defined first and implementations are built to conform. This was essential for achieving the plug-and-play interoperability required for modern, automated, and virtualized networks, supporting key initiatives like Network Functions Virtualization (NFV) and Management and Orchestration (MANO) where dynamic service composition relies on standardized, discoverable interfaces.

What changed in its specifications

The latest release-to-release comparison of specifications that define WSDL. Each summary describes the whole specification, not only this term.

TS 23.222Rel-18 → Rel-19

Rel-19 adds CAPIF Phase 3 procedures for unpublishing service APIs between interconnected core functions, revoking API invoker and resource owner authorization, open discovery of service APIs, and UE-hosted API invoker access to resources owned by other UEs.

Full comparison in TS 23.222 →

Evolution Across Releases

An overview written from the defining specifications, not a verified change history. For the exact text, open the specifications listed below.

Rel-8 Initial

WSDL 1.1 was extensively adopted across 3GPP specifications, particularly for OAM interfaces (IRPs in TS 32-series) and service exposure interfaces. It established the standard method for defining web service contracts, enabling automated code generation and ensuring interoperability for the new IP-based management and provisioning frameworks introduced with the System Architecture Evolution (SAE).

Defining Specifications

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

SpecificationTitleRelease
TS 23.222 vk10 Common API Framework (CAPIF) Rel-20 read
TS 23.722 vf10 Common API Framework (CAPIF) for 3GPP Northbound APIs Rel-15 read
TS 28.303 vj00 LSA Controller IRP Solution Set Definitions Rel-19 read
TS 28.669 vj00 RPTA IRP Solution Set (SS) Rel-19 read
TS 29.198 v340 OSA R99 API Stage 3 Specification R99 read
TS 29.199 3GPP TS 29.199 Rel-8 read
TS 32.101 vj00 PLMN Management Principles and Requirements Rel-19 read
TS 32.111 vj00 Fault Management Alarm IRP Solution Sets Rel-19 read
TS 32.153 vj00 IRP Technology-Specific Templates Specification Rel-19 read
TS 32.306 vj00 Configuration Management Notification IRP Solution Set Rel-19 read
TS 32.307 v920 Notification IRP SOAP Solution Set (TS 32.307) Rel-9 read
TS 32.316 vj00 Generic IRP Management Solution Set Definitions Rel-19 read
TS 32.317 v910 Generic IRP management SOAP Solution Set Rel-9 read
TS 32.346 vj00 File Transfer IRP Solution Set Definitions Rel-19 read
TS 32.347 v900 FT IRP SOAP Solution Set Rel-9 read
TS 32.366 vj00 EP IRP Solution Set definitions Rel-19 read
TS 32.367 v900 Entry Point IRP SOAP Solution Set Rel-9 read
TS 32.416 vj00 PM IRP Solution Set Definitions Rel-19 read
TS 32.417 v900 PM IRP SOAP Solution Set Rel-9 read
TS 32.506 vj00 Self-Configuration of Network Elements IRP Solution Set Rel-19 read
TS 32.507 v910 Self-Configuration of NE IRP SOAP SS Rel-9 read
TS 32.536 vj00 Software Management IRP Solution Set Rel-19 read
TS 32.537 v910 Software Management IRP SOAP Solution Set Rel-9 read
TS 32.606 vj00 Basic CM IRP Solution Set for CORBA/SOAP Rel-19 read
TS 32.607 v910 Basic CM IRP SOAP Solution Set Rel-9 read
TS 32.616 vj00 Bulk CM IRP Solution Set Definitions Rel-19 read
TS 32.617 v900 Bulk CM IRP SOAP Solution Set Rel-9 read
TS 32.667 v900 Kernel CM IRP SOAP Solution Set Rel-9 read
TS 32.808 v800 Common Profile Storage Framework for User Data Rel-8 read
TS 32.824 v900 SOA and IRP Gap Analysis Rel-9 read
TS 32.866 vf00 REST, HTTP, JSON for Management Interfaces Rel-15 read