CAMARA Dedicated Networks

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: Dedicated Networks API

Description

The "Dedicated Networks" APIs cover reserving network connectivity resources, selecting network capabilities, and controlling device access.

The Dedicated Networks API has four parts, normally used in this order:

Service Areas - find where coverage is offered.
Profiles - find the available capability / Quality of Service (QoS) bundles.
Networks - request a dedicated network for a time and area.
Accesses - grant specific devices permission to use it.

Each step returns an id used by the next.

This API overlaps with the Network Slice Booking API: both reserve network resources for an area and time. The main difference is that Dedicated Networks then grants access per device (via the Accesses API), whereas Network Slice Booking applies to all devices in the area for the booked window.

Information: Dedicated Networks project page and GitHub repository

The API definitions can be obtained here: DedicatedNetworks API_definitions folder

The Dedicated Networks repository contains several API definitions (YAML):

Networks: dedicated-network.yaml
Accesses: dedicated-network-accesses.yaml
Areas: dedicated-network-areas.yaml
Profiles: dedicated-network-profiles.yaml

Operations and dependencies

Dedicated Network - Network Service Areas API

POST /retrieve-service-areas - Retrieve dedicated network service areas, filtered by additional search criteria. The response includes an id with the supported network profiles and QoS profiles
GET /areas/{areaId} - Read a dedicated network service area

Dedicated Network - Network Profiles API

GET /profiles - List of available network profiles. The response includes an id, alongside the maxNumberOfDevices, aggregatedUlThroughput, aggregatedDlThroughput, qosProfiles,...
- Dependency: Requires qosProfiles which can be retrieved from a previous call to the QoS Profiles API.
GET /profiles/{profileId} - Read a dedicated network profile

Dedicated Network - Networks API

GET /networks - List of dedicated networks (the list can be empty)
POST /networks with the request body including either a networkProfileId (chosen Network Profile) or a qosProfileName, plus serviceTime (start and end) and a serviceAreaId, is used to request the creation of a dedicated network. The response includes an id and the status of the request. A sink for notifications can be optionally indicated.
GET /networks/{networkId} - get the current information about a dedicated network
DELETE /networks/{networkId} - delete a dedicated network

Dedicated Network - Accesses API

GET /accesses - List of existing device accesses to dedicated networks, optionally filtered for a given device and/or for a dedicated network (the list can be empty)
POST /accesses with the request body including the networkId received after invoking the Dedicated Network API (id), a device object, qosProfiles, this request will create a device access to a dedicated network with a given configuration. The response includes an id.
GET /accesses/{accessId} - get a device access to the dedicated network and its configuration
DELETE /accesses/{accessId} - delete a device access to the dedicated network

Standardisation context

Dedicated Networks is a multi-part CAMARA API (OpenAPI 3.0.3, Commonalities-conformant), split across four YAML definitions in the repository (Areas, Profiles, Networks, Accesses) that together describe one workflow. Its subject matter is what 3GPP frames as private or campus connectivity: a Non-Public Network (NPN) or a dedicated slice reserved for one customer within an operator's network. NPN concepts are defined in the 5G System architecture (TS 23.501); the per-device QoS applied to accesses reuses the same NEF QoS machinery (TS 29.522) as the other QoS APIs. The CAMARA YAML itself does not cite these 3GPP specifications; the correspondence is analysis, and an operator may realise a dedicated network through a slice, an isolated deployment, or a combination.

The four-part resource model

The API is designed to be walked in order, each step narrowing what the next can request:

Part	Operation(s)	Returns	Role
Service Areas	`POST /retrieve-service-areas`, `GET /areas/{areaId}`	area `id` + supported profiles	Where coverage is offered, and which profiles apply there.
Profiles	`GET /profiles`, `GET /profiles/{profileId}`	profile `id`, device limit, aggregate throughput, QoS profiles	The capability/QoS bundles available (depends on QoS Profiles).
Networks	`GET`/`POST`/`DELETE /networks`, `GET /networks/{networkId}`	network `id` + `status`	Reserve a dedicated network for a `serviceTime` and `serviceAreaId`.
Accesses	`GET`/`POST`/`DELETE /accesses`, `GET /accesses/{accessId}`	access `id`	Grant a specific device permission to use the reserved network.

Only devices with an Accesses resource can use the reserved connectivity, and each access can tailor QoS within the bounds of the applicable network profile. A network request may enter a REQUESTED and then reserved state before it becomes active, depending on the requested start time; a sink can be supplied for status notifications.

Relationship to Network Slice Booking

Dedicated Networks and Network Slice Booking both reserve network resources for an area and a time window, and the two APIs overlap. The practical difference is granularity of admission: Dedicated Networks grants access per device (through the Accesses part), so only enrolled devices consume the reservation, whereas Network Slice Booking reserves aggregate slice capacity for an area and window without an explicit per-device access step. For a production where the on-site devices are known and should be individually authorised, the per-device model fits well; for a broad "cover everyone in this area" reservation, slice booking is closer.

Workflow: Media application requesting a Dedicated Network

A user of a media application wants to reserve a dedicated network for a venue ahead of an event, then attach devices individually as they are confirmed. The following steps are executed:

Step 0: Pre-conditions

The API invoker has signed up with the API provider.
Dedicated Network Service Areas and Network Profiles have already been defined and published by the network operator.

Step 1: Discover the service area and profile

POST /retrieve-service-areas passing the desired location, returning an area id with the network and QoS profiles it supports.
GET /profiles to review the available network profiles and, optionally, the underlying QoS Profile detail via the QoS Profiles API.

Step 2: Reserve the dedicated network

POST /networks passing a networkProfileId or qosProfileName, the serviceTime and the serviceAreaId. The response returns a network id and status.

Step 3: Grant device access

POST /accesses passing the networkId, the device object and the qosProfiles the device may use. The response returns an access id. Devices can be granted and revoked access throughout the reservation window via further calls to this operation and to DELETE /accesses/{accessId}.

5G-MAG's Self-Assessment

This section records 5G-MAG's practical reading of the API and the open points it raises for media use.

Separating area discovery, reservation and device access lets the API consumer secure a venue's connectivity ahead of an event, then enrol devices individually as they are confirmed on site (for example cameras arriving one at a time), without needing to know the full device list at reservation time.
Because each device requires an explicit Access, only enrolled devices consume the reservation; the Network Profile's maxNumberOfDevices and aggregate throughput figures set the ceiling the operator dimensions the reservation for.
This API overlaps with Network Slice Booking; the choice between them is mainly whether per-device authorisation (Dedicated Networks) or a single aggregate reservation for the area and window (Network Slice Booking) fits the production.

Potential improvements:

It is unclear how a Network's REQUESTED/reserved state relates to creating Accesses against it; whether an Access can be created before the Network reaches an active status should be confirmed against the API definition.

Dedicated Network - Network Service Areas API Usage

This API allows for discovering available network service areas, which are the geographical areas offered by the network provider where consistent coverage according to indicated network profile(s) and QoS profiles is provided, and which is to be used in conjunction with the Dedicated Network API.

With POST /retrieve-service-areas a list of dedicated network service areas can be retrieved, filtered by additional search criteria. In the examples on this page, QCI_1_voice is an illustrative, operator-defined profile name (QoS Class Identifier, QCI, is the 4G/LTE QoS label that some operators reuse in profile names); the actual names come from the operator.

The request below filters service areas by location and by an optional profile name:

{
  "atLocation": {
    "latitude": 50.735851,
    "longitude": 7.10066
  },
  "overlappingArea": {},
  "coveringArea": {},
  "byName": "string",
  "byNetworkProfileId": "string",
  "byQosProfileName": "QCI_1_voice"
}

Type of response: the list of areas, each with an id (used later when requesting a network) and the network and QoS profiles it supports:

[
  {
    "id": "3fa85f64-5717-4562-b3fc-2c963f66afa6",
    "name": "string",
    "description": "string",
    "area": {},
    "networkProfiles": ["string"],
    "qosProfiles": ["QCI_1_voice"]
  }
]

Dedicated Network - Network Profiles API Usage

This API allows for discovering available network profiles, which are offered by the network provider to be used in conjunction of the Dedicated Network API. Network profiles describe the capabilities and performance targets of a dedicated network.

With GET /profiles a list of available network profiles can be retrieved. Each profile lists its device limit, aggregate throughput targets and the QoS profiles it offers:

[
  {
    "id": "string",
    "maxNumberOfDevices": 0,
    "aggregatedUlThroughput": {
      "value": 10,
      "unit": "bps"
    },
    "aggregatedDlThroughput": {
      "value": 10,
      "unit": "bps"
    },
    "qosProfiles": ["QCI_1_voice"],
    "defaultQosProfile": "QCI_1_voice"
  }
]

Dedicated Network - Networks API Usage

This API allows for requesting a Dedicated Network, which provides a set of capabilities and connectivity performance targets. The Dedicated Network may be requested for a particular geographical location and at a particular time window. Depending on the requested start time for the dedicated network, the network may first enter a reserved state.

Request the creation of a dedicated network

With POST /networks, passing either a networkProfileId or a qosProfileName, plus serviceTime and a serviceAreaId, among others.

{
  "name": "string",
  "networkProfileId": "string",
  "serviceTime": {
    "start": "2025-11-05T14:14:35.390Z",
    "end": "2025-11-05T14:14:35.390Z"
  },
  "serviceAreaId": "3fa85f64-5717-4562-b3fc-2c963f66afa6",
  "sink": "https://endpoint.example.com/sink",
  "sinkCredential": {}
}

Type of response: Information about the status of the request.

{
  "id": "3fa85f64-5717-4562-b3fc-2c963f66afa6",
  "status": "REQUESTED",
  "name": "string",
  "networkProfileId": "string",
  "serviceTime": {
    "start": "2025-11-05T14:14:35.392Z",
    "end": "2025-11-05T14:14:35.392Z"
  },
  "serviceAreaId": "3fa85f64-5717-4562-b3fc-2c963f66afa6",
  "sink": "https://endpoint.example.com/sink",
  "sinkCredential": {}
}

Dedicated Network - Accesses API Usage

This API allows for requesting network access for devices. A device is identified by the CAMARA device object, containing either an MSISDN or a Network Access Identifier. A Device Access represents the permission for a specific device to use a Dedicated Network's reserved connectivity resources. Only devices for which a Device Access resource has been created can use the connectivity resources allocated for that network. The usage of resources can be tailored to each device within the constraints of the applicable Network Profile.

With POST /accesses a device access can be created

{
  "networkId": "3fa85f64-5717-4562-b3fc-2c963f66afa6",
  "device": {
    "phoneNumber": "+123456789",
    "networkAccessIdentifier": "123456789@domain.com",
    "ipv4Address": {
      "publicAddress": "84.125.93.10",
      "publicPort": 59765
    },
    "ipv6Address": "2001:db8:85a3:8d3:1319:8a2e:370:7344"
  },
  "qosProfiles": ["string"],
  "defaultQosProfile": "string"
}

Type of response: An id for the requested device access.

{
  "networkId": "3fa85f64-5717-4562-b3fc-2c963f66afa6",
  "device": {
    "phoneNumber": "+123456789",
    "networkAccessIdentifier": "123456789@domain.com",
    "ipv4Address": {
      "publicAddress": "84.125.93.10",
      "publicPort": 59765
    },
    "ipv6Address": "2001:db8:85a3:8d3:1319:8a2e:370:7344"
  },
  "qosProfiles": ["string"],
  "defaultQosProfile": "string",
  "id": "3fa85f64-5717-4562-b3fc-2c963f66afa6"
}

Device object

This is how a device is defined:

{
  "device": {
    "phoneNumber": "123456789",
    "networkAccessIdentifier": "123456789@domain.com",
    "ipv4Address": {
      "publicAddress": "84.125.93.10",
      "publicPort": 59765
    },
    "ipv6Address": "2001:db8:85a3:8d3:1319:8a2e:370:7344"
  }
}