Skip to main content
Connectivity Quality with Network APIs

Using CAMARA APIs

warning

This documentation is currently under development and subject to change. It reflects outcomes elaborated by 5G-MAG members. If you are interested in becoming a member of the 5G-MAG and actively participating in shaping this work, please contact the Project Office

Using CAMARA APIs (and Network Services) for Live Segmented Media Distribution​

note

This page is an early skeleton. The mapping below is drafted from the Workflows and Requirements for Live Media Distribution and from the CAMARA API reference pages. Endpoint and parameter details should be confirmed against the current CAMARA specifications before being relied upon.

This section maps CAMARA APIs to the Live Segmented Media Distribution context. The candidate APIs are drawn from the list of Network API Initiatives under analysis, and the mapping follows the phases identified in Workflows and Requirements.

This analysis reuses the more detailed CAMARA API analysis from Content Production and Contribution and is at an earlier, less mature stage; the differences specific to distribution (large device populations, geofencing) are highlighted where relevant.

Unlike Content Production and Contribution (where the focus is on contributing content from a small number of devices), Live Media Distribution concerns delivery of segmented media (for example MPEG-DASH) to a potentially large population of client applications running on end-user devices across one or more service areas. Two needs dominate the workflow:

  • Quality of Service for reliable, interruption-free segment delivery (see the QoS requirements in Workflows).
  • Information monitoring, logging and network assistance, both in real time (for runtime decisions) and after the session (for troubleshooting and post-processing).

The Workflows also identify a Geofencing need (verifying whether a UE is inside a target service area, and notifications when UEs enter or leave it). The APIs covering Geofencing are not part of the CAMARA APIs documented in this portal section; they are noted here as a requirement only and are not detailed below.

Candidate CAMARA APIs​

The following APIs from the Content Production analysis are the most relevant to Live Media Distribution. Each links to its reference page in this portal.

API Role in Live Media Distribution
Quality on Demand Requests stable latency or prioritised throughput for the connection used to deliver media segments to a device.
QoS Profiles Provides the predefined network performance profiles referenced by the other APIs.
Application Profiles Defines the application's network quality thresholds, referenced by Connectivity Insights for monitoring.
Connectivity Insights On-demand check of whether the network can currently meet an application profile's thresholds for a connected device.
Connectivity Insights Subscriptions Event-subscription variant of Connectivity Insights, for regular network-quality notifications during a session.

Mapping to the workflow phases​

The Workflows describe four phases. The candidate APIs map to them as follows.

Phase A: Preparing the streaming application​

Phase A (installing and preparing the client application on user devices) involves no CAMARA API interaction; it is a content-provider and application concern. It is included for completeness only.

Phase B: Network capability pre-booking​

The content provider requests network services (for example Quality-on-Demand) for client applications in one or more geographical areas, on a given schedule.

  • The Quality on Demand API can request a QoS session for a device-to-application-server connection. The QoS session is created with POST /sessions, referencing a qosProfile from the QoS Profiles API.
note

The Quality on Demand API does not let the service area be specified in advance; it is created at the location of use. This limitation is discussed for Content Production in the corresponding Using CAMARA APIs page and applies here as well. Whether a reservation-style API is needed for the distribution case is open.

Phase C: Setup and configuration, and monitoring during the session​

The content provider configures its client applications and then monitors that they are using the requested network capabilities, receiving notifications about potential issues (throughput, delay, and so on).

  • One-shot check. Create an Application Profile with the Application Profiles API (POST /application-profiles) carrying the network quality thresholds, then call the Connectivity Insights API (POST /check-network-quality) to obtain a qualitative confidence assessment for a connected device.
  • Regular notifications. Using the same Application Profile, the Connectivity Insights Subscriptions API can be used to subscribe to recurring network-quality notifications during runtime.

Phase D: Teardown​

  • The content provider releases the booked network capabilities. For a Quality on Demand session this is DELETE /sessions/{sessionId}, or the session is torn down by the operator when its duration expires.

The monitoring path in detail​

Monitoring is the centre of gravity for distribution, because the whole work area exists to close the visibility gap described in the Introduction. The CAMARA path has two steps and two flavours:

  1. Declare the requirement once. The content provider creates an Application Profile with the Application Profiles API (POST /application-profiles), carrying the network-quality thresholds the streaming app needs (for example a target packet delay budget and minimum downstream rate consistent with interruption-free segment playback). The profile is declared once and reused.
  2. Ask whether the network meets it.
    • One-shot: the Connectivity Insights API (POST /check-network-quality) returns a qualitative assessment of the network's confidence in meeting the profile's thresholds for a connected device, at that moment.
    • Recurring: the Connectivity Insights Subscriptions API delivers the same assessment as periodic notifications during a session.

This gives the content provider a network-side view it otherwise lacks. Combined with the app-side measurements it already has (time to last byte per segment, radio indicators, error events), it lets the provider attribute a degraded experience to the network rather than lumping it into "The Cloud". The exchange is inherently two-way: the provider contributes app-side data (via the Application Profile thresholds and, potentially, richer measurement feedback), and the operator contributes its confidence assessment back. Standardising this feedback is what would make the collaboration practical at scale.

Why the fit is imperfect at population scale​

Connectivity Insights checks a single connected device against a profile. Distribution concerns a population of clients across service areas, so applying the per-device model to every client does not obviously scale, and the API gives no aggregate, area-level view. Whether distribution needs an aggregate or sampled variant, and whether a reservation-style API (rather than the point-of-use Quality on Demand) is appropriate for a population, are open questions. The QoS side inherits every limitation noted for Content Production: no pre-booking availability lookup, no service area in Quality on Demand, and monitoring against a separate Application Profile rather than the booked QoS Profile.

Geofencing: identified but out of scope here​

The Workflows require verifying whether a UE is inside a target service area and being notified when UEs enter or leave it, because live media rights and editorial variants are region-specific. CAMARA does address this, in the DeviceLocation repository (Location Verification, Location Retrieval and Geofencing Subscriptions APIs, with scope limited to 4G and 5G networks), but those APIs are not among the CAMARA APIs documented in this portal section. They are therefore recorded as a requirement and an open point rather than mapped in detail. Any use of location data also carries privacy and consent obligations: under the CAMARA security model, location APIs process personal data, so they require an end-user-consent flow (CIBA) rather than a two-legged client-credentials token.

Underlying 3GPP mechanisms​

The QoS requests map to network capability exposure through the Network Exposure Function (NEF, TS 29.522) and Policy Control Function (TS 29.514), exactly as on the contribution side. The monitoring and information-sharing capability corresponds to network capability exposure through the NEF and, at the application-enabling layer, to the Service Enabler Architecture Layer for Verticals (SEAL), 3GPP TS 23.434 (also published as ETSI TS 123 434), whose enabling services (including network resource management and location management) are candidates for carrying the shared data. See Network API Initiatives.

Open points​

  • Geofencing (UE location verification and enter/leave notifications) is required by the workflow but is not covered by the CAMARA APIs documented here. The relevant API needs to be identified.
  • The distribution case targets a large population of devices rather than a single contributing device; the per-device session model of Quality on Demand may not map cleanly to this scale. This needs further analysis.
  • As with Content Production, monitoring relies on a separate Application Profile rather than the QoS Profile used to request resources. Harmonising the two would be more coherent.
References to verify

These identifiers on this page were not confirmed against a primary source (the 3GPP/ETSI portals block automated access): the applicability of the SEAL (TS 23.434) network-resource-management and location-management enabling services to media-distribution monitoring, and the mapping of the QoS requests to the NEF (TS 29.522) and PCF (TS 29.514) service operations. Verify against the 3GPP work plan and the current CAMARA specifications before publication.

note

Refer to the Tech repository to contribute to this documentation.