Description
Universal Description, Discovery and Integration (UDDI) is a platform-independent, XML-based registry specification for listing and discovering web services. Within the 3GPP architecture, particularly from Release 15 onwards, it is adopted as a mechanism for service discovery within the framework of network exposure. The primary architectural components involved are the Network Exposure Function (NEF) in the 5G Core and the Service Capability Exposure Function (SCEF) in the 4G Core. These functions act as gateways, securely exposing network capabilities and events to authorized third-party Application Functions (AFs). UDDI provides a standardized way for these AFs to discover what services or APIs are available.
Technically, a UDDI registry contains information modeled in a specific data structure. This includes 'businessEntity' (information about the service provider, which could be the network operator), 'businessService' (a logical grouping of related web services), 'bindingTemplate' (technical details on how to invoke a service, including the network API endpoint), and 'tModel' (technical models, specifications, or classifications, such as the 3GPP-defined API specifications like 'Nnef_' interfaces). When an NEF or SCEF publishes a new network capability as a service, it creates entries in the UDDI registry with these structured details.
The discovery process works through UDDI Inquiry APIs. An application developer or an AF can query the UDDI registry using search criteria (e.g., find all services of a certain category, or from a specific provider). The registry returns the binding information, including the endpoint URL and the required tModel references. The AF can then use this information to bind to the actual service endpoint (the NEF) and start invoking the network APIs, such as requesting quality of service for a specific user or subscribing to location event notifications. This decouples the service description from its implementation, enabling dynamic and automated integration.
UDDI's role is critical in enabling a developer-friendly ecosystem. It moves beyond static API documentation to a machine-discoverable directory. This is especially important in multi-vendor and multi-operator environments, allowing for interoperability and reducing integration overhead. The registry can be hosted by the operator, a third party, or in a federated manner. Security is paramount, with access to the UDDI registry typically protected by authentication and authorization mechanisms to ensure only authorized entities can publish or discover sensitive network APIs.
Purpose & Motivation
UDDI was created to solve the fundamental problem of service discovery in a distributed, web services-based world. Before such registries, finding and integrating with a web service required manual processes, out-of-band communication, and hard-coded endpoint URLs, which were brittle and non-scalable. The original motivation for UDDI (outside 3GPP) was to create a global 'yellow pages' for web services, facilitating business-to-business (B2B) e-commerce.
3GPP adopted and specified UDDI to address the specific challenge of network API exposure and ecosystem development. With the rise of network programmability and open APIs (exemplified by initiatives like GSMA's Open Gateway), operators needed a standardized way for third-party application providers to discover available network capabilities. The limitation of simply publishing API specifications on a website is the lack of automation. UDDI provides a machine-readable, queryable interface that enables automated client configuration and dynamic binding, which is essential for scalable cloud-native architectures and DevOps practices.
Its integration into 3GPP, starting in Release 15, was motivated by the need to fully realize the service-based architecture (SBA) of 5G. In an SBA, network functions offer services to each other. Extending this principle to external applications requires a robust discovery mechanism. UDDI solves this by providing a well-understood standard for building a catalog of exposed network services (like device location, network status, QoS control), thereby lowering the barrier to entry for developers and fostering innovation in vertical applications for IoT, enterprise, and consumer services.
Key Features
- XML-based registry for publishing and discovering web services.
- Defined data structures: businessEntity, businessService, bindingTemplate, and tModel.
- Provides Inquiry and Publishing API sets for programmatic interaction.
- Enables dynamic binding of service consumers to service providers.
- Supports categorization and taxonomy of services via tModels.
- Facilitates the creation of federated registries across administrative domains.
Evolution Across Releases
Initially introduced in 3GPP specifications within the context of the Service Capability Exposure Function (SCEF) for CIoT and the Network Exposure Function (NEF) for 5G. The specification (TS 23.222) defined how UDDI v3 is used as the service discovery mechanism for 3GPP northbound APIs, establishing the framework for external applications to discover available network exposure capabilities.
Enhancements focused on alignment with the matured 5G SBA and the Common API Framework (CAPIF). UDDI's role was further clarified within the CAPIF architecture, which provides a common framework for publishing, discovering, and consuming APIs across different administrative domains, strengthening its position as the core discovery enabler.
Refinements and additional use cases for service discovery, particularly supporting edge computing and vertical-specific applications. Work continued on ensuring UDDI registry interactions are secure and scalable, supporting the increased granularity and number of exposed services in advanced 5G deployments.
Defining Specifications
| Specification | Title |
|---|---|
| TS 23.222 | 3GPP TS 23.222 |