Skip to main content
Connectivity Quality with Network APIs

QoS Profiles

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: QoS Profiles for Content Production & Contribution​

Find more information about QoS Profiles API.

Purpose​

A QoS Profile is a named, operator-defined bundle of network performance targets (throughput, latency, jitter, packet loss and so on). The media application does not create these profiles; it selects one that the network operator has already published to match a given application or use case, then references it by name when booking or requesting resources through the other CAMARA APIs.

Workflow and Architecture​

A QoS Profile is referenced by name in the request body of the other CAMARA QoS-related APIs, including:

The profile parameters themselves are retrieved with the QoS Profiles API. This page documents the profile structure using example values.

Example of a QoS Profile​

An example of the QoS Profile, including status (provided in the response from the Network API platform), is shown below. The values are illustrative; a production profile would carry the throughput, latency and reliability targets required by the media flow.

Key fields to note:

  • name and description: the identifier the other APIs reference, and a human-readable label.
  • status: whether the profile is currently ACTIVE.
  • targetMinUpstreamRate / maxUpstreamRate (and the downstream equivalents): the guaranteed and maximum bit rates. For contribution feeds the upstream (uplink) rates matter most.
  • minDuration / maxDuration: the allowed booking duration bounds.
  • priority: relative scheduling priority between profiles.
  • packetDelayBudget, jitter, packetErrorLossRate: the latency, timing-variation and loss targets.
  • l4sQueueType: whether Low Latency, Low Loss, Scalable throughput (L4S) queuing applies.
  • serviceClass: the traffic category, for example real_time_interactive.
note

CAMARA QoS Profiles are an abstraction over the 3GPP QoS model. In 3GPP, a standardised QoS behaviour is identified by a 5G QoS Identifier (5QI); in earlier systems the equivalent was the QoS Class Identifier (QCI). The operator maps each named CAMARA profile onto an appropriate 5QI/QCI. A profile name such as QCI_1_voice seen elsewhere in these pages is illustrative only.

For a media contribution example, a profile intended for a single uplink camera feed would set a high guaranteed upstream rate (for example several Mbps), a low packetDelayBudget and jitter, and a low packetErrorLossRate, with a serviceClass such as real_time_interactive.

// Example values — replace with actual network requirements
[
  {
    "name": "voice",
    "description": "QoS profile for voice calls",
    "status": "ACTIVE",
    "targetMinUpstreamRate": {
      "value": 128,
      "unit": "Kbps"
    },
    "maxUpstreamRate": {
      "value": 128,
      "unit": "Kbps"
    },
    "maxUpstreamBurstRate": {
      "value": 128,
      "unit": "Kbps"
    },
    "targetMinDownstreamRate": {
      "value": 128,
      "unit": "Kbps"
    },
    "maxDownstreamRate": {
      "value": 128,
      "unit": "Kbps"
    },
    "maxDownstreamBurstRate": {
      "value": 128,
      "unit": "Kbps"
    },
    "minDuration": {
      "value": 60,
      "unit": "Seconds"
    },
    "maxDuration": {
      "value": 60,
      "unit": "Seconds"
    },
    "priority": 20,
    "packetDelayBudget": {
      "value": 100,
      "unit": "Milliseconds"
    },
    "jitter": {
      "value": 30,
      "unit": "Milliseconds"
    },
    "packetErrorLossRate": 3,
    "l4sQueueType": "non-l4s-queue",
    "serviceClass": "real_time_interactive"
  }
]

5G-MAG's Self-Assessment​

  • Centralising the performance targets in a single, named QoS Profile keeps the other CAMARA QoS-family APIs simple: they only reference a profile by name rather than repeating throughput, latency and loss parameters in every booking or session request.
  • Because a profile is entirely operator-defined and published in advance, a media application cannot request arbitrary custom values; it can only pick from whatever profiles and names the operator has chosen to provision. Portability of application logic across operators therefore depends on profile names and content being comparable, which the API itself does not guarantee.
  • The mapping from a named profile onto the underlying 3GPP 5QI/QCI is deliberately hidden from the application. This keeps the application portable, but it also means the application cannot verify which underlying network treatment it is actually receiving.

Potential improvements:

  • A degree of naming or content convergence across operators (or a small set of well-known reference profiles) would make the same media application logic portable between networks without hardcoding operator-specific profile names.
  • The field-name ambiguity noted above (packetErrorLossRate vs packetLossErrorRate) should be resolved so integrators do not need to check the specific API version they are targeting.

The QoS Profile as the shared vocabulary​

The QoS Profile is the pivot of the whole CAMARA QoS analysis: every other QoS-related API references a profile by name rather than carrying raw performance numbers. This keeps the operator in control of what treatments are offered (each profile is one the operator has provisioned and can police) and keeps the media application's requests portable (the same profile name can be requested through Quality on Demand at the point of use, booked in advance through QoS Booking, or bundled into a Dedicated Network). The application discovers the available profiles and their parameters through the QoS Profiles API (GET /qos-profiles and GET /qos-profiles/{name}); the profile name must be known beforehand, and operators are expected to publish the names through the Network API Platform.

Relationship to the 3GPP QoS model​

A CAMARA QoS Profile is an abstraction over the 3GPP QoS model, not a new one. In 5G a QoS Flow is characterised by a 5G QoS Identifier (5QI); the standardised 5QI values and their characteristics (resource type GBR / Delay-Critical GBR / non-GBR, priority level, packet delay budget, packet error rate) are tabulated in 3GPP TS 23.501, clause 5.7.4, Table 5.7.4-1. In earlier systems the equivalent identifier was the QoS Class Identifier (QCI), with the packet error loss rate attribute defined in TS 23.203. The operator maps each named CAMARA profile onto an appropriate 5QI (standardised or operator-specific) and enforces it through the Policy Control Function. This is why a profile name such as QCI_1_voice is illustrative only: the CAMARA layer hides whether the underlying identifier is a 5QI or a legacy QCI.

The individual profile fields relate to 3GPP concepts as follows:

CAMARA field3GPP concept
targetMinUpstreamRate / targetMinDownstreamRateGuaranteed Bit Rate (GBR) targets for a GBR QoS Flow
maxUpstreamRate / maxDownstreamRateMaximum Bit Rate (MBR) / per-flow ceiling
packetDelayBudgetPacket Delay Budget (PDB) of the 5QI
packetErrorLossRatePacket Error Rate (PER) of the 5QI (expressed as the exponent N in 10^-N)
priorityPriority Level of the 5QI
jitterDelay-variation target (not a standalone 5QI attribute; policed by the operator)
l4sQueueTypeLow Latency, Low Loss, Scalable throughput (L4S) marking, where supported
serviceClassThe service category the operator maps to a resource type / 5QI

For a contribution feed the upstream (uplink) fields dominate, because the media flows from the device to the production centre. A profile intended for a single uplink camera would set a high guaranteed upstream rate (several Mbps or more), a low packet delay budget and jitter, and a low packet error loss rate, typically as a GBR treatment. The downlink fields matter mainly for return video, intercom and control.

note

The field for error loss rate appears as packetErrorLossRate in the CAMARA QoS Profiles definition; some API definitions spell it packetLossErrorRate. Confirm the exact name against the specific .yaml you integrate against, as noted in Relevant QoS Parameters.

References to verify

These identifiers on this page were not confirmed against a primary source (the 3GPP/ETSI portals block automated access): TS 23.501 clause 5.7.4 / Table 5.7.4-1 as the exact location of the standardised 5QI table, and TS 23.203 as the QCI packet-error-loss-rate reference. Verify against the 3GPP work plan before publication.

note

Refer to the Tech repository to contribute to this documentation.