CAMARA Application 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

CAMARA: Application Profiles API

Description

Developers use the "Application Profiles" API to share essential information about their applications that is relevant for network and CAMARA APIs decision-making. Currently, it focuses on defining network quality thresholds and compute resource requirements needed by the application. This foundation will expand to include additional information based on requirements from other CAMARA APIs, making it a central point for capturing what the application's needs are.

Used in the context of:

This API enables defining, reading, and managing application requirements, including:

Network quality thresholds (latency, jitter, loss, throughput)
Compute resource thresholds (CPU, GPU, memory, storage)

Information: Application Profiles project page and GitHub repository

The API definitions can be obtained here: ApplicationProfiles API_definitions folder

The Application Profiles API definition (YAML) is available at: application-profiles.yaml

Operations and dependencies

Application Profiles API

POST /application-profiles with the request body containing user-defined network quality thresholds. Used to define network monitoring intents for optimal end user application experience. Response is an applicationProfileId.
PATCH /application-profiles/{applicationProfileId} - Update the complete set of network quality thresholds for an application with the new set of thresholds to ensure good end user experience
GET /application-profiles/{applicationProfileId} - Read an Application Profile
DELETE /application-profiles/{applicationProfileId} - Delete an application profile

Parameters

Network Quality Thresholds
- packetDelayBudget - the maximum allowable one-way latency between the customer's device and the gateway from the operator's network to other networks. The end-to-end or round trip latency will be about two times this value plus the latency not controlled by the operator
- targetMinDownstreamRate - the target minimum downstream rate.
- targetMinUpstreamRate - the target minimum upstream rate
- packetLossErrorRate - the exponential power of the allowable error loss rate 10^(-N). For 5G network the 3GPP specification TS 23.203 defines the packet error loss rate QCI attribute.
- jitter - this requirement aims to limit the maximum variation in round-trip packet delay for the 99th percentile of traffic, following ITU Y.1540 standards. It considers only acknowledged packets in a session, which are packets that receive a confirmation of receipt from the recipient (e.g., using TCP).
Compute Resources (the minimum compute capacity the application needs where it runs, for example at an edge site). Values are given as a number plus a unit, except CPU and GPU counts which are plain numbers:
- targetMinCPU - minimum number of CPU cores (fractional values allowed, e.g. 0.5).
- targetMinMemory - minimum working memory (value + unit, e.g. Kb).
- gpuVendorType - required GPU vendor (e.g. Nvidia).
- gpuModelName - required GPU model name.
- targetMinGPU - minimum number of GPUs.
- targetMinGPUMemory - minimum GPU memory (value + unit).
- targetMinEphemeralStorage - minimum short-lived (scratch) storage (value + unit).
- targetMinPersistentStorage - minimum persistent storage (value + unit).

The exact accepted units and value ranges are defined in the application-profiles.yaml; confirm against the version you integrate against.

Standardisation context

Application Profiles is a CAMARA sandbox/incubating API defined in OpenAPI 3.0.3 and governed by the CAMARA Commonalities rules (device object, error model, security). It is a data-management API: unlike the QoS APIs it does not, by itself, map to a 3GPP northbound operation on the Network Exposure Function (NEF). Its role is to store a reusable description of an application's requirements so that other APIs (here, Connectivity Insights) can reference it by applicationProfileId instead of repeating the thresholds on every call.

The network-quality thresholds mirror the parameters an operator uses to characterise a 5G QoS flow. packetDelayBudget, packetErrorLossRate and the guaranteed/target bit rates correspond to the attributes that, inside the 5G Core, are associated with a 5G QoS Identifier (5QI) and its QoS characteristics (the 5G successor to the 4G QoS Class Identifier, QCI). CAMARA keeps these at an application-facing level of abstraction rather than exposing 5QI values directly. The computeResources block has no 3GPP QoS equivalent; it describes edge-compute placement needs (CPU, GPU, memory, storage) for deployments where the application is hosted near the network, and is out of scope of the QoS mapping.

Because Application Profiles is the shared vocabulary for the Connectivity Insights family, its parameter set overlaps deliberately with the QoS Profiles API. The two are not identical: QoS Profiles adds duration, priority and L4S fields, while Application Profiles adds the compute block. 5G-MAG's Self-Assessment below flags harmonising the two as an open point.

Resource lifecycle

The four operations form a simple CRUD lifecycle on the applicationProfileId resource:

Step	Operation	Effect
Create	`POST /application-profiles`	Stores the thresholds and returns a new `applicationProfileId`.
Read	`GET /application-profiles/{applicationProfileId}`	Returns the stored profile.
Update	`PATCH /application-profiles/{applicationProfileId}`	Replaces the threshold set (note the description says the complete set is replaced).
Delete	`DELETE /application-profiles/{applicationProfileId}`	Removes the profile; consumers holding the id can no longer reference it.

There is no notification mechanism on this API: a profile is inert data, and it only has an effect when another API is invoked with its id.

Workflow for a media application creating an Application Profile

A user of a media application would like to create an Application Profile with the network quality thresholds for the application. The following step creates the profile.

The figure below places Application Profiles in the wider Connectivity Insights flow, so it shows more than the single creation step described here (the Application Profile is the first block; the later blocks belong to Connectivity Insights).

Application Profiles in the context of a Connectivity Insights check. This page covers only the profile-creation step; the remaining blocks are described on the Connectivity Insights page.

Step 1: Creation of Application Profile

Create an application profile using the Application Profiles API with POST /application-profiles and with the request body containing user-defined network quality thresholds.

Further steps

The applicationProfileId returned here is then passed to the APIs that consume it, namely Connectivity Insights (a one-shot quality check) and Connectivity Insights Subscriptions (continuous monitoring via notifications).

5G-MAG's Self-Assessment

What we understand:

The API is likely to be invoked well before the actual use of the network with the required values of performance and compute resources.
The Application Profile appears to be a list of parameters to be monitored on the link between the device and the Application Server (AS, the server endpoint the media flows to or from) once other APIs are invoked passing the Application Profile as body.
Once an applicationProfileId is obtained, it can be used by other APIs.

Open questions and potential improvements:

The list of parameters and their units/accuracy should be checked for typical media applications. The parameters are a subset of qosProfile with additional compute resources. Harmonize?
Is the packet delay budget defined between device and cloud server, or to the User Plane Function (UPF)? When invoking Connectivity Insights with such a profile and an indicated device and AS, how would this relate?

Application Profiles API Usage

Create a profile which represent the network demands of an application

With POST /application-profiles

The request body below declares the network quality thresholds and compute resources the application needs:

{
  "networkQualityThresholds": {
    "packetDelayBudget": {
      "value": 12,
      "unit": "Milliseconds"
    },
    "targetMinDownstreamRate": {
      "value": 10,
      "unit": "Bps"
    },
    "targetMinUpstreamRate": {
      "value": 10,
      "unit": "Bps"
    },
    "packetLossErrorRate": 3,
    "jitter": {
      "value": 12,
      "unit": "Milliseconds"
    }
  },
  "computeResources": {
    "targetMinCPU": 0.5,
    "targetMinMemory": {
      "value": 10,
      "unit": "Kb"
    },
    "gpuVendorType": "Nvidia",
    "gpuModelName": "string",
    "targetMinGPU": 1,
    "targetMinGPUMemory": {
      "value": 10,
      "unit": "Kb"
    },
    "targetMinEphemeralStorage": {
      "value": 10,
      "unit": "Kb"
    },
    "targetMinPersistentStorage": {
      "value": 10,
      "unit": "Kb"
    }
  }
}

Type of response: An applicationProfileId. The response echoes back the stored thresholds together with the new identifier to reference in later calls:

{
  "applicationProfileId": "3fa85f64-5717-4562-b3fc-2c963f66afa6",
  "networkQualityThresholds": {
    "packetDelayBudget": {
      "value": 12,
      "unit": "Milliseconds"
    },
    "targetMinDownstreamRate": {
      "value": 10,
      "unit": "Bps"
    },
    "targetMinUpstreamRate": {
      "value": 10,
      "unit": "Bps"
    },
    "packetLossErrorRate": 3,
    "jitter": {
      "value": 12,
      "unit": "Milliseconds"
    }
  }
}