[API Proposal] <Network Outage API>

[JoelDouglas-BT]

Description
The Network Outage API provides a standard way for authorised devices, apps and support channels to check whether a customer is affected by a known mobile network outage, service degradation or planned maintenance event.
It helps explain poor or lost connectivity using operator network data, so customers can be given clearer information instead of being pushed through unnecessary troubleshooting or support journeys.

Use cases

Check if a device/location is affected by a known outage
Show clear customer messaging during network issues
Support planned maintenance notifications
Update customers when an issue is resolved
Keep outage information consistent across device, app, web and care channels
Help OEMs and digital channels respond better when a device detects poor service

Related to
No related public pull request or issue at this stage.

Pull request to follow

[albertoramosmonagas]

Hi @JoelDouglas-BT,

Thank you for the submission. Before this proposal can be scheduled for Backlog WG discussion, three things are needed:

1. Missing artefacts (blocking): Please submit a PR with the completed API proposal template linked to this issue

2. Scope clarification needed: The current description mixes a northbound developer API with internal operator support tooling ("care channels," "support channels"). The latter falls outside CAMARA scope (Operate API, TM Forum territory). Please confirm: who is the API consumer — an independent developer/aggregator, or the operator's own support systems?

3. Overlap with existing APIs: The following APIs already cover adjacent capabilities and must be addressed in the template:

• Device Reachability Status — whether a device is currently connected/offline
• Device Reachability Status Subscriptions — push notification when connectivity changes
• Connectivity Insights — network quality metrics for diagnostics

Please explain what this proposal adds that cannot be addressed via these existing APIs, or whether a scope enhancement to one of them would be the right path.

Happy to discuss before the next WG session if useful.

[JoelDouglas-BT]

Hi @albertoramosmonagas

1. working on the PR.

2. Scope clarification
   The intended consumer of this API is external developers, aggregators, OEMs, and enterprise applications.
   It is designed as a northbound, developer-facing API that can be used within digital journeys such as authentication, payments, and customer experience flows.
   It is not intended for internal operator support or care tooling.

3. Overlap with existing APIs
   The existing APIs focus on device-level connectivity or network performance, but they do not provide visibility of network outages themselves.
   Device Reachability Status indicates whether a device is reachable or not, but does not explain why. It cannot distinguish between a device issue and a wider network problem.
   Device Reachability Status Subscriptions notify when a device’s connectivity changes, but remain limited to a device view and do not provide information on broader network conditions or incidents.
   Connectivity Insights provides network quality metrics such as performance or latency, but does not explicitly identify outages, service disruptions, or provide information on their lifecycle, severity, or cause.

This proposal adds a different capability by exposing network-level outage information. It enables applications to understand when connectivity issues are caused by an outage or service problem, rather than just observing the effect at device or network performance level.
It introduces visibility of outage events themselves, including status, severity, type, impacted services, and expected resolution, along with the ability to receive notifications when these events occur or change.

This is not something that can be derived from the existing APIs alone, and therefore is better delivered as a separate, complementary API rather than an extension of the current ones.

[albertoramosmonagas]

Hi @JoelDouglas-BT,

Thanks for the clarification — the scope question is resolved. The consumer profile (developers, aggregators, OEMs) is consistent with CAMARA scope as a Service Management API.

One additional overlap to address in the template: the NetworkInsights Sub Project (https://github.com/camaraproject/NetworkInsights), currently in Sync26, includes network-health-assessment and network-traffic-analysis. Please review its scope and explain how your proposal differentiates from or complements those APIs.

Once the PR with the completed template is submitted — including that analysis — the proposal can be scheduled for WG discussion.

[JoelDouglas-BT]

no problem, thanks @albertoramosmonagas

Network Insights is about overall performance and trends. It looks at how healthy the network is and how traffic is behaving over time.
It doesn’t tell you when there is an actual outage.

This proposal focuses on that gap. It gives a clear signal when there is a network issue, along with what is happening, how serious it is, and what is affected.

Instead of trying to work it out from performance data or device behaviour, an application can see directly that there is an outage and act on it.

That is why it makes more sense as a separate API rather than extending the existing ones.

[albertoramosmonagas]

Understood, the distinction is clear. Looking forward to the PR with the ppt