Implementing GSMA Open Gateway with WSO2

The Open Gateway initiative is a shift in the way telcos expose their network capabilities to third parties. It’s a migration from proprietary implementations to standardized APIs for capabilities including network slicing, edge computing, identity verification, and device location.

This article details how WSO2's integration suite, specifically the API Platform, complemented by the Identity Platform, Moesif, and Integrator, serves as an ideal platform for building solutions compliant with the Open Gateway specification. This article explores the technical architecture, security, and operational factors that underscore WSO2's suitability for this deployment scenario.

Telcos often struggle, not with the simple exposure of APIs to third parties, but with doing so securely, with a scalable design, and in a way that allows for monetization and compliance with industry standards. WSO2's products effectively meet these complex requirements while ensuring the adaptability necessary for the constantly evolving open gateway ecosystem.

The GSMA Open Gateway challenge

Before going through the architecture of the Open Gateway, it's important to understand the challenges and what makes implementations complex for operators.

Legacy infrastructure: Telco networks were not designed for their capabilities to be exposed via APIs. Network functions are distributed across various domains including core network, radio access network, billing systems, subscriber databases and network orchestration platforms, each with proprietary protocols, interfaces and data models.

Multi-vendor environment: Operators run heterogeneous networks with equipment from multiple vendors. Each vendor will implement network capabilities differently. To present a unified API interface, these differences need to be abstracted.  

Security and privacy requirements: Network APIs could expose sensitive capabilities and data. As a result authentication, authorization, consent management, and privacy controls must be in place to ensure security of the data and compliance with regulations (GDPR, CCPA, and local telecommunications laws).

Monetization and business models: Open Gateway APIs need to support flexible monetization including pay-per-use, subscription tiers, partner-specific pricing, and potentially real-time charging integration. To support this, gateways will need the capability to manage quotas and rate limit applications and provide usage analytics.

Standardization with flexibility: While the GSMA Open Gateway provides API specifications defined by the CAMARA project, operators will need to extend these standards with their own APIs, manage versioning, and, in some cases, support both standardized and proprietary APIs.

Developer experience: Success of the GSMA Open Gateway depends on developer adoption, which in turn relies on detailed documentation, interactive API consoles, test environments, clear and simple onboarding processes, and responsive support capability. 

Architecture

This complete Open Gateway implementation utilizes WSO2 products within a reference architecture. Each product is assigned a specific role, contributing to a loosely coupled design that ensures both scalability and adaptability for future evolution.

Figure 1: High-level GSMA federated gateway architecture

API Platform remains the core component responsible for exposing APIs securely to third parties. The Identity Platform manages authentication, authorization, and consent enforcement. The Integration Platform will serve as the translation layer in this architecture and will translate RESTful API calls into protocols and data structures that the underlying network equipment will understand.

This architecture ensures that each component is able to evolve independently, while the network infrastructure can also be modernized without impacting published APIs. The strength of this architecture doesn’t lie with a single component but in how they work together, each working to their strengths while maintaining clean interfaces between each other. The architecture is robust enough for modern telco environments while being flexible enough to adapt as Open Gateway specifications evolve and business requirements change.

Figure 2: High-level GSMA Gateway architecture with WSO2 products

WSO2 API Platform

The API Platform serves as the main interface used by external parties to access network functions exposed as APIs. There are a couple of key capabilities that the Open Gateway requires.

API design and lifecycle management

The API Platform’s “design first” approach allows administrative users to import the OpenAPI definitions, published by the CAMARA project, directly and automatically generating the API proxies with the correct endpoints, schemas, and documentation. API versioning and maintaining backwards compatibility is also possible while introducing new capabilities.  

Developer portal and user onboarding

Telcos will need to treat developers as customers if the Open Gateway initiative is to be successful. The developer portal, which is a part of the API Platform, provides self service capabilities, which developers have come to expect when consuming third-party APIs. Browsing APIs, viewing interactive documentation, generating API keys and secrets, testing in production-like environments, and monitoring usage are some of the features supported by the developer portal. 

Security policy enforcement

In this architecture, the API Platform acts as the policy enforcement point for all Open Gateway traffic. As the API call passes through the gateway, multiple security policies are applied.

Authentication: Integrates with the WSO2 Identity Platform, or third-party identity providers, and validates OAuth 2.0 tokens, API keys, or mutual TLS certificates. The gateway verifies token signatures, checks expiration, and validates scopes.

Authorization: The gateway also enforces fine grained authorization policies prior to granting access to the requested resource. These checks include consent as well as scopes.

Threat protection: The gateway has a number of policies to defend against attacks including injection attacks, oversized payloads, and JSON/XML threats. In telco environments, where APIs have the ability to directly trigger network functions, these protective measures prevent attacks affecting network stability.

Rate limiting and throttling: The API Platform’s throttling capabilities are used to prevent network overload and enforce complex rate limits and quotas, thereby enabling monetization.

Analytics and monetization

From an analytics perspective, an understanding of API usage is critical for a number of stakeholders including technical operations and business intelligence. Network operations teams monitor for performance degradation or capacity issues, product teams track API adoption, and business teams use usage data for billing, capacity planning, and partnership discussions.

Monetization extends analytics into business models. Moesif can be used to track usage against quotas and generate billing events. The API Platform can also act as a metering point and generate usage events to other charging systems.

Multi-gateway deployments

Larger operators often need distributed gateway deployments for diverse requirements such as latency optimization, network zone segmentation, or separating internal and external traffic. WSO2 API Platform facilitates multi-gateway architectures, enabling a single control plane to manage all policies and configurations while traffic is handled by multiple, distributed runtime gateways.

WSO2 Identity Platform

The Identity Platform provides authentication, authorization, and consent management capabilities that address several critical security requirements of the Open Gateway initiative. 

OAuth2.0 and OIDC for authentication and authorization

Open Gateway uses OAuth 2.0 as the primary security framework. In this architecture, the Identity Platform acts as the authorization server, issuing tokens and managing OAuth flows. OAuth 2.0, which is a standard supported by the platform, is capable of handling both machine-to-machine authentication and end-user authentication and also integrates seamlessly with the API Platform.

Many of the CAMARA project APIs require higher levels of security considering the data that is made available. WSO2’s Identity Platform supports FAPI compliant profiles, ensuring tokens are tamper proof. The platform also supports the CIBA (Client Initiated Backchannel Authentication), which allows apps to prompt the user for authentication.

Consent management

Many of the APIs that are exposed through the Open Gateway involve subscriber data including location and identity. From a regulatory perspective (GDPR, CCPA, local regulations, etc.) sharing this data requires explicit user consent. With the consent management capabilities included in the Identity Platform, users are able to grant, view and revoke access to their data at any given time.

When authorizing a request, the platform will check if a consent record exists for the combination of the user, the data attribute, and the calling application. If it does exist, access to the attribute will be granted. A user has the ability to revoke access to data at any given time via the consent management portal. Once a consent record is updated, the changes will affect API authorization immediately. This provides the transparency, auditability, and control that the regulations demand.

Identity federation

The ecosystem that is envisioned by the Open Gateway involves applications working across multiple operators. The federation capabilities included in the Identity Platform supports this vision by enabling trust relationships between operators and external identity providers. Tokens issued by the platform can be used to authenticate to any other entity that maintains a trusted relationship with the identity provider.

While improving the overall security posture of the environment, federation also enhances the user experience as authentication across multiple operators and services takes place transparently without breaking the user’s flow. 

WSO2 Integrator

Within an Open Gateway setup, the Integrator's key role is to manage the intricate integration with the Telco's backend systems. Serving as a mediation and abstraction layer, it supplies data to the standardized northbound APIs exposed through the API Platform, effectively concealing underlying backend system complexities from outside consumers.

Protocol and data mediation

The Integrator plays a crucial role in adapting the strictly RESTful API standards defined by CAMARA to the often non-uniform Telco backends. This involves "protocol bridging," which means converting incoming REST calls into the necessary formats for legacy core network systems, such as SOAP, Diameter, SMPP, and proprietary RPC calls. Furthermore, the Integrator is responsible for data transformations, mapping the complex data retrieved from backend systems into the simplified structures mandated by the CAMARA specification.

Service chaining and orchestration

Implementing the GSMA Open Gateway often requires collating and manipulating data from various backend systems for a single API call's response. WSO2 Integrator's service chaining capabilities allow developers to orchestrate calls to multiple backend services, process responses and return an aggregated response to the consuming application. The use of Integrator as an abstraction layer also gives developers an opportunity to gracefully handle backend failures and errors while orchestrating these complex operations.

Managing complexities of legacy systems

Telco OSS/BSS systems are often outdated, a situation that persists because of the complex nature of the environment, making replacement difficult. WSO2's Integrator facilitates the implementation of modern capabilities, such as support for CAMARA APIs, by front-ending these legacy platforms and de-risking the environment. It achieves this through a variety of techniques, including direct database integration and mechanisms like request buffering or throttling to safeguard sensitive or vulnerable backend systems.

Moesif

Moesif is an API analytics and monetization platform that is part of the WSO2 product suite. The integration of Moesif with the API Platform transforms the solution into an intelligence engine that converts API traffic data into a format that can be used for business level decision making. By introducing Moesif into this architecture, the operator gains the ability to treat network capabilities as metered digital assets, facilitating sophisticated monetization strategies and deep behavioral insights that are essential in today’s competitive markets.

Moesif's key function in this setup is to deliver Product Analytics that offer deeper insights than conventional monitoring. While standard tools focus on metrics like "uptime" and "latency," Moesif illuminates the "API User Journey" with a granular perspective. It enables product managers to conduct funnel analysis, pinpointing the exact points of friction third-party developers encounter during onboarding. For example, Moesif can flag developer groups that register for an API like "SIM Swap" but fail to execute a successful call within the initial 24 hours. This information enables the Telco to proactively take steps to rectify issues and improve conversion rates.

Advanced monetization and usage-based billing

Moesif acts as the high precision metering engine that captures every billable event  across the network without introducing latency to the communication flow. It can support a wide range of commercial models ranging from pay-as-you-go plans to complex tiered pricing and feature based billing.

From a technical perspective, the integration between the API gateway and Moesif relies on an agent within the gateway. This agent captures metadata from APIs and securely transmits it to Moesif for processing. Moesif has the ability to link the data with application identities and integrate with billing platforms to create a fully automated billing cycle.  

Operational governance

Moesif's behavioral analytics tools offer insights into user interaction with the API Platform. This is accomplished by structuring raw event data, such as API calls, into a chronological timeline of each user's activities. By establishing a baseline for the "normal" behavior of each developer and application, the system can automatically identify anomalies. These deviations may signal API abuse, fraud, or credential theft. These capabilities add another layer of protection across the environment ensuring that Telcos revenue generating assets are protected from exploitation while maintaining the highest possible levels of service for legitimate partners. 

Behavioural segmentation

By analyzing behavioural patterns over time, the platform has the ability to identify at-risk developers where usage is declining, often an indicator of churn. Similarly, the same tools can be used to identify power users and provide sales teams with data driven leads to upsell premium tiers. This ensures the Open Gateway is managed not as a technical service but as a growing business unit with clear visibility into customers, their behaviours and market trends. 

Security architecture

The Open Gateway initiative opens up new revenue streams for both telcos and developers. However, because these APIs provide access to critical infrastructure, it is essential that security, trust, and compliance are central to the platform's design. The proposed security architecture delivers a telecom-grade, identity-centric and federated security model that aligns with the GSMA Open Gateway principles.

This design embeds security into every layer of the Open Gateway implementation.

• Identity-first access control: Ensures that every API call is authenticated, authorized and auditable.
• Least-priviledge enforcement: Ensures that applications only access permitted network capabilities.
• Network Isolation: Ensures that no external party has direct access to the core network functions.

Governed access

The “triple-lock mechanism” is used to ensure that only authorised entities can access sensitive network capabilities and data. This framework ensures that every interaction is validated through three distinct, interdependent layers of verification: Application Identity, Developer Trust, and Subscriber Consent. By implementing this tiered defense, the organization can mitigate the risks of unauthorized data exposure, fraudulent network manipulation, and identity spoofing.

• Lock 1 - Application identity: Every third-party application must be registered, vetted, and assigned a unique, cryptographically secured identity. OAuth 2.0 and FAPI profiles are used to ensure that the communication between the developer’s app and the gateway is tamper proof. This lock ensures that only registered software can initiate a request toward the core network. This layer of defence is enforced via the API Platform as it is the point of entry into the environment.
• Lock 2 - Developer trust and governance: The ecosystem has the ability to federate with the developer’s corporate identity system. This ensures that if a developer leaves  their company, their access to the network APIs is revoked immediately. In addition to effectively being a “kill switch”, this prevents "orphan access" where dormant accounts could be exploited to probe network vulnerabilities. This layer of defence is enforced via the Identity Platform.
• Lock 3 - Consent validation: The final and most critical lock is the verification of the subscriber’s intent. The CIBA flow is used to decouple the API request from the user’s current digital session. Triggered by the platform, the user gets an out of band notification to grant consent when the calling application requests sensitive data, thereby ensuring that the user is the gatekeeper of their own data. 

Privacy by design

In this environment, privacy by design is a fundamental structural principle that ensures network operators remain a trusted custodian of subscriber data. This architecture utilises the Identity Platform to secure personal identifiable information (PII), including network capabilities like location and sim status, and make sure it is never exposed to third parties without the user’s explicit consent. This architecture centralises the identity and consent management functions within the platform and decouples it from the high-traffic API Gateway, thereby allowing the network to scale without compromising subscriber confidentiality.

The consent management capability within the Identity Platform gives users the ability to create, view, manage, and delete consent records at any time via the consent management portal. Every API request is then validated against the consent records, in real time. The consents are purpose bound, which means a user can grant an application access to data for a specific transaction without granting the same application access to use the data for any other purpose.

The platform also supports Client Initiated Back-channel Authentication (CIBA), which allows the privacy handshake to take place out of band, on the user’s device. When a request is initiated by a third-party developer, the system triggers a push notification or a native prompt to the handset requiring an action (PIN, biometric verification) to authorise the specific data exchange.

Infrastructure resilience

The resilience of the underlying infrastructure is what differentiates the experimental PoC from a mission critical telco service. Resilience in this context is operational continuity, ensuring that a surge in traffic or a hardware failure  does not degrade the performance or availability of the core network. This architecture achieves this level of resilience by using WSO2’s distributed capabilities. 

Distributed high availability

This architecture is designed to be multi-data center and working as an active-active deployment. The API and Identity Platforms have the ability to run concurrently across multiple geographic zones with a Global Load Balancer routing traffic to healthy nodes. With this design, even if an entire data center goes off-line, the Open Gateway will remain operational without requiring manual intervention, maintaining the “five-nines” availability standard expected in the industry.

Core network isolation

A significant risk with opening up network APIs is the “thundering herd” effect where a third party app generates a spike in requests that overwhelms legacy core networks. WSO2 Integrator uses request buffering and circuit breaker patterns to safeguard backend systems from being flooded with requests. With these patterns, Integrator provides an immediate error response to the developer when a particular service appears sluggish or unavailable, instead of sending the request through to a backend that is saturated or runs the risk of crashing the core network.

Auto-scaling and auto-healing

The architecture can be containerized and managed via Kubernetes. The use of Kubernetes allows horizontal autoscaling where WSO2 gateways will be automatically spun up quickly as traffic grows and then scaled down as traffic reduces. Furthermore, if specific instances fail or become unresponsive, Kubernetes will automatically terminate those instances and replace it with a fresh healthy instance. This ensures that technical glitches never result in service outages for consumers.

Observability

In an Open Gateway environment, observability must extend beyond server monitoring to provide a view of both network reliability and commercial success. In this architecture, the integration of Moesif insights directly into the API Platform removes the traditional data silo between engineers and  product owners allowing the real-time tracking of critical metrics including request patterns, latency trends and errors.

Operational maturity model

When working through the implementation of the Open Gateway environment, you need to consider both the setup of the platform, as well as continued, sustainable ROI. This maturity model uses 4 stages to track progress from basic technical setup to revenue generating platform.

Maturity Level	Focus	Technical State	Business Outcome
Level 1	Connectivity	Basic APIs exposed, manual onboarding of developers. High manual effort and potential security gaps due to manual work.	Proof of concept.
Level 2	Security and Compliance	IS enforcing OIDC, OAuth 2.0 and CIBA/Consent flows. Integration handling protocol mediation. Centralized logging, basic rate limiting.	Regulatory compliance, controlled access.
Level 3	Scalability	Automated CI/CD, proactive monitoring with analytics. Faster recovery times. Increased uptime. HA setup in place.	Operational efficiency, predictable  performance, resilient platform.
Level 4	Ecosystem growth	Automated monetization is in place.  AI-driven insights. Platform is a profit center.	Revenue growth and business decisions based on data.

Table 1: Operational maturity model
 

Conclusion and roadmap

The implementation of the Open Gateway using the WSO2 stack marks a shift in the organization from that of a connectivity provider to a modern “network as a service” leader. By establishing a secure, observable and monetized gateway, the telco is positioned to unlock a global market for network-aware applications.

Formal executive sponsorship needs to be secured at a group ExCo level as the CAMARA APIs cut across network, IT, enterprise, finance and regulatory domains. Without clear ownership, initiatives of this nature risk fragmentation and de-prioritizations.

A formal API product management function needs to be created. APIs need to be governed as digital products with a defined pricing model, SLAs, lifecycle policies and revenue targets. This ensures long term sustainability and prevents CAMARA from being treated as a one-off  technology deployment.

The organization should define clear success metrics from the outset. These should include API transaction volumes, enterprise adoption rates, digital revenue contribution, SLA performance, and time-to-onboard partners. Establishing measurable outcomes ensures that CAMARA is evaluated as a revenue platform rather than a compliance exercise.

The final recommendation is to adopt a phased rollout model beginning with high-demand, low-complexity APIs. Start with a focused set of APIs with minimal integration complexity, faster time to market and generate early revenue to build internal confidence. A high level phased implementation plan is documented below.

Phase 1: Foundation and market entry (0-6 months)

Currency the highest demand can be seen for the “anti-fraud” family of APIs. During this phase the focus should be on setting up stable CAMARA compliant production endpoints for services including SIM swap, number verification and device status. The Moesif metering engine needs to be activated to capture traffic and build a baseline. The phase concludes with partners being successfully onboarded and generating billable events.

Phase 2: Growth and service diversification (6-18 months)

During this phase the roadmap shifts towards high-performance capabilities focusing on “Quality on Demand” and advanced location based services. There will be reliance on Integrator’s orchestration capabilities to manage 5G and edge computing resources. The commercial focus  gets more sophisticated and moves from a simple per-call billing mechanism to a more complex value-based pricing model that is managed within Moesif. Self service capabilities for onboarding and user management will be needed as the developer community continues to grow. Hyperscalers will also need to be engaged to resell network capabilities to their own developer communities. 

Phase 3: Ecosystem leadership (18+ months)

The Open Gateway becomes a central pillar for the company’s digital strategy enabling APIs to be seamlessly consumed across international borders through other global operators. AI driven insights from Moesif dictate real-time network resource allocation and pricing.  This phase completes the transformation of the Telco preparing it for the next wave of immersive gaming, smart mobility, IoT devices and decentralised digital identity.