WSDL

Web Services Description Language

Interface →
Introduced in Rel-8

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.

Category
Interface
Introduced
Rel-8
Where
Management
Specifications
31 specs
WSDL Description Purpose Related Classification Detected Changes 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.

Classification

Part ofIRP
Related approachesSOAP

Detected Changes Across Releases

from 3GPP Change Requests

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

Studied in Rel-8, normative work from Rel-15.

Rel-15 1 change

In Release 15, the WSDL function was enhanced with the introduction of an offboarding procedure for API invokers. This addition formally extended the functional entities and reference points description to include the "Offboard API invoker" request and response operations, complementing the existing onboarding process. The offboarding mechanism allows for the managed removal of an API invoker's registration, including the provision of a reason for the action.

  • Addition of offboarding to functional entities and reference points description TS 23.222CR0004
Rel-18 2 changes

In Release 18, the WSDL function was updated to include descriptions of new functional entities and reference points, such as those supporting third-party API providers and CAPIF interconnection. Additionally, corrections were made to the API descriptions, refining the definitions and procedures for operations like service API discovery, publishing, and event subscription management. These enhancements provide a more complete and accurate technical specification for the CAPIF framework's service APIs.

  • Adding descriptions of new functional entities and reference points TS 23.222CR0106
  • API Description Correction TS 23.222CR0136
Rel-19 5 changes

In Release 19, the WSDL function was enhanced to explicitly support third-party API providers within the CAPIF functional model, correcting its previous description. The release also introduced mapping for active-inactive API states to SA5 solutions and aligned the descriptions of Service API Information. Furthermore, enhancements were made to the descriptions of both the AEF (API Exposing Function) capabilities and the CCF's (Common Core Function) functional role in managing service API information.

  • On mapping of active-inactive API states to SA5 solutions and aligning Service API Information descriptions TS 23.222CR0264
  • Enhanced AEF Capabilities Description TS 23.222CR0267
  • Enhanced the CCF's functional description for service API information TS 23.222CR0269
  • Remove the Note in Functional model description to support RNAA TS 23.222CR0271
  • Correction to Functional model description to support 3rd party API providers TS 23.222CR0325

Explore further

Broader topics and technologies where WSDL plays a role.

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 vj80 Common API Framework for 3GPP Northbound APIs Rel-19
TS 23.722 vf10 Common API Framework (CAPIF) for 3GPP Northbound APIs Rel-15
TS 28.303 vj00 LSA Controller IRP Solution Set Definitions Rel-19
TS 28.669 vj00 RPTA IRP Solution Set (SS) Rel-19
TS 29.198 v1900 OSA API Overview Specification Rel-9
TS 29.199 v1900 Multimedia Messaging Web Services Rel-9
TS 32.101 vj00 Management principles and high-level requirements Rel-19
TS 32.111 vj00 Fault Management Requirements Rel-19
TS 32.153 vj00 IRP Technology-Specific Templates Specification Rel-19
TS 32.306 vj00 Configuration Management Notification IRP Solution Set Rel-19
TS 32.307 v1920 Notification IRP SOAP Solution Set Rel-9
TS 32.316 vj00 Generic IRP Management Solution Set Definitions Rel-19
TS 32.317 v910 Generic IRP management SOAP Solution Set Rel-9
TS 32.346 vj00 File Transfer IRP Solution Set Definitions Rel-19
TS 32.347 v1900 File Transfer IRP SOAP Solution Set Rel-9
TS 32.366 vj00 EP IRP Solution Set definitions Rel-19
TS 32.367 v900 Entry Point IRP SOAP Solution Set Rel-9
TS 32.416 vj00 PM IRP Solution Set Definitions Rel-19
TS 32.417 v900 PM IRP SOAP Solution Set Rel-9
TS 32.506 vj00 Self-Configuration of Network Elements IRP Solution Set Rel-19
TS 32.507 v1910 Self-Configuration IRP SOAP Solution Set Rel-9
TS 32.536 vj00 Software Management IRP Solution Set Rel-19
TS 32.537 v910 Software Management IRP: SOAP Solution Set Rel-9
TS 32.606 vj00 Basic CM IRP Solution Set for CORBA/SOAP Rel-19
TS 32.607 v1910 CM IRP SOAP Solution Set Mapping Rel-9
TS 32.616 vj00 Bulk CM IRP Solution Set Definitions Rel-19
TS 32.617 v900 Bulk CM IRP SOAP Solution Set Rel-9
TS 32.667 v1900 Kernel CM IRP SOAP Solution Set Rel-9
TS 32.808 v1800 Common User Profile Storage Framework Rel-8
TS 32.824 v900 SOA and IRP Gap Analysis Rel-9
TS 32.866 vf00 REST, HTTP, JSON for Management Interfaces Rel-15