OSA

Open Services Architecture

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

OSA is a standardized framework for creating and deploying network services in a vendor-independent manner, enabling third-party providers to access network capabilities through open APIs.

Category
Services
Introduced
R99
Where
Services › IMS
Also touches
2 segments
Specifications
22 specs
OSA Description Purpose Related Classification Specifications

Description

The Open Services Architecture (OSA) is a cornerstone of the 3GPP service layer, designed to provide a standardized, secure, and scalable way for applications to interact with network capabilities. It is based on a client-server model where the Application Server (AS) acts as the client and the OSA Gateway, often implemented as part of an IP Multimedia Subsystem (IMS) Service Capability Interaction Manager (SCIM), acts as the server. The architecture defines a set of Service Capability Features (SCFs), which are abstract representations of network functionalities like call control, user location, presence, and messaging. These SCFs are exposed to applications via standardized, technology-agnostic Application Programming Interfaces (APIs), historically aligned with the Parlay specifications. The OSA Gateway maps these API calls to the underlying network protocols, such as SIP, MAP, or Diameter, providing a crucial abstraction layer that shields application developers from the complexities of the core network.

The OSA framework is built upon a robust security and management infrastructure. It includes a Framework API, which is a mandatory set of functionalities for all OSA implementations. This framework handles critical tasks such as authentication and authorization of applications, discovery of available SCFs, establishment of secure communication sessions, and integrity management. The security model ensures that only authorized applications can access specific network capabilities, often based on service level agreements. From an operational perspective, OSA facilitates the creation of a vibrant ecosystem where network operators can safely open their networks to third-party service providers, enabling a wide array of value-added services without compromising network security or stability.

Within the network, OSA plays a pivotal role in enabling the seamless integration of applications with IMS and other core network domains. It is a key enabler for the 'open network' concept, moving away from vertically integrated, vendor-proprietary service creation environments. The architecture supports both stateful and stateless interactions, allowing for complex service logic involving multiple network capabilities. Its design promotes reusability and interoperability, as applications written for one operator's OSA implementation can, in principle, be ported to another's with minimal changes. This has been fundamental in the evolution of mobile networks towards providing rich communication services, blending telecom and IT functionalities.

Purpose & Motivation

OSA was created to address the fundamental challenge of slow and costly service innovation in traditional telecom networks. Prior to its introduction, creating new network services was a complex process tightly coupled to specific vendor equipment and proprietary interfaces. This 'walled garden' approach stifled innovation, increased development time, and locked operators into single-vendor ecosystems. The primary purpose of OSA is to break down these barriers by standardizing the interface between applications and network functionality.

The historical context for OSA's development lies in the transition from circuit-switched 2G networks to the packet-switched, IP-based 3G and later 4G/5G networks. As networks became more capable and data-oriented, the demand for innovative services (beyond voice and SMS) grew exponentially. The 3GPP, in collaboration with the Parlay Group, defined OSA to provide a future-proof, technology-agnostic method for service exposure. It solves the problem of how to safely and efficiently allow external applications—from both the operator and third-party developers—to leverage intrinsic network capabilities like user authentication, location, and session control.

By solving these problems, OSA directly enables the business model of network-as-a-platform. It allows operators to monetize their network assets beyond basic connectivity, fostering partnerships with application developers and content providers. This was a strategic shift from being mere connectivity providers to becoming enablers of a broader digital services ecosystem, a principle that remains central to modern network architectures like 5G Service-Based Architecture (SBA).

Classification

Part ofAPI
Specific typesKVMVASPVHE
Related approachesIMSSCIM

Evolution Across Releases

R99 Initial

OSA was initially introduced, providing the foundational architecture and first set of Service Capability Features (SCFs) like Generic Call Control and User Interaction. It established the core client-server model with the OSA Gateway, the Framework API for lifecycle management, and the principle of abstracting network protocols behind standardized APIs to enable third-party application development.

Explore further

Broader topics and technologies where OSA plays a role.

Defining Specifications

3GPP specifications that define or reference OSA, 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
TS 22.121 v1400 Virtual Home Environment Requirements Rel-5
TS 22.127 v1900 Open Service Access (OSA) Requirements Rel-9
TS 22.228 vj00 IP Multimedia Service Requirements Rel-19
TS 22.240 vj00 3GPP Generic User Profile Requirements Rel-19
TR 22.949 vj00 Privacy Requirements Study for 3GPP Services Rel-19
TS 23.127 v1600 Virtual Home Environment Stage 2 Specification Rel-6
TS 23.171 v1300 LCS Stage 2 Specification for UMTS Rel-4
TS 23.198 v1900 Open Service Access (OSA); Stage 2 Rel-9
TS 23.218 vj00 IMS Call Model Specification Rel-19
TS 23.228 vj50 IMS Stage-2 Service Description Rel-19
TS 23.240 vj00 3GPP Generic User Profile (GUP) Architecture Rel-19
TS 23.271 vj00 LCS Stage 2 Specification Rel-19
TS 23.417 v1700 IMS Core Component for NGN Architecture Rel-7
TS 23.517 v1800 IMS Core Component for NGN Architecture Rel-8
TS 29.198 v1900 OSA API Overview Specification Rel-9
TS 29.199 v1900 Multimedia Messaging Web Services Rel-9
TS 29.864 v801 Application Server Service Data Definition for IMS Telephony Rel-8
TS 32.102 vj00 Telecom Management Physical Architecture Framework Rel-19
TS 32.140 vj00 Subscription Management (SuM) requirements Rel-19
TS 32.141 vj00 Subscription Management (SuM) Architecture Rel-19
TS 32.808 v1800 Common User Profile Storage Framework Rel-8
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.