Skip to content

Using the Platform

This section describes how to interact with the Operator Platform: end-to-end workflows, step-by-step guides and examples for Application Providers and operators.

Quickstart

This quickstart uses a MongoDB container as the example application and walks through the minimal sequence of NBI calls to register it, deploy one instance to an Edge Cloud zone and clean up.

Prerequisites: A running Operator Platform with the OEG reachable (e.g. OEG_URL=http://localhost:32263 for a typical KIND deployment). The OEG base path used below is /oeg/1.0.0 (append to your OEG URL).

1. Discover an Edge Cloud zone

Before deploying, you need a target Availability Zone. Call the edge-cloud zones API:

GET {OEG_URL}/oeg/1.0.0/edge-cloud-zones

The response is a JSON array of zone objects. Choose a zone (e.g. one with edgeCloudZoneStatus: "active") and note its edgeCloudZoneId and edgeCloudProvider. You will also need the same zone’s edgeCloudZoneName for the instantiation request in step 3.

2. Register the application

Register the MongoDB application metadata with the platform so it can be instantiated later. Send a CAMARA-style app manifest:

POST {OEG_URL}/oeg/1.0.0/apps

Example body (you can use your own appId or omit it and use the one returned by the platform):

{
  "appId": "550e8400-e29b-41d4-a716-446655440000",
  "name": "mongodb_edge_app",
  "appProvider": "mongodb_foundation",
  "version": "7.0.0",
  "packageType": "CONTAINER",
  "operatingSystem": {
    "architecture": "x86_64",
    "family": "UBUNTU",
    "version": "OS_VERSION_UBUNTU_2204_LTS",
    "license": "OS_LICENSE_TYPE_FREE"
  },
  "appRepo": {
    "type": "PUBLICREPO",
    "imagePath": "docker.io/mongo:7.0"
  },
  "requiredResources": {
    "infraKind": "container",
    "numCPU": "500m",
    "memory": 512
  },
  "componentSpec": [
    {
      "componentName": "mongodb_server",
      "networkInterfaces": [
        {
          "interfaceId": "eth0",
          "protocol": "TCP",
          "port": 27017,
          "visibilityType": "VISIBILITY_EXTERNAL"
        }
      ]
    }
  ]
}

A successful response (HTTP 200) includes appId. Use this value in step 3.

3. Instantiate the application in a zone

Deploy one instance of the registered application to the chosen Edge Cloud zone:

POST {OEG_URL}/oeg/1.0.0/appinstances

Replace {appId} with the ID from step 2. Replace {zoneId}, {edgeCloudProvider} and {zoneName} with the values from the same zone object in step 1:

{
  "appId": "{appId}",
  "appZones": [
    {
      "EdgeCloudZone": {
        "edgeCloudZoneId": "{zoneId}",
        "edgeCloudZoneName": "{zoneName}",
        "edgeCloudProvider": "{edgeCloudProvider}",
        "edgeCloudZoneStatus": "active",
        "edgeCloudRegion": "unknown"
      }
    }
  ]
}

The response includes appInstanceId (or equivalent) for the new instance. On a minimal KIND cluster the instance record may be created while the underlying workload reports a non-ready status until resources are available; you can still list and manage the instance.

4. List and manage the instance (optional)

  • List instances for this app:
    GET {OEG_URL}/oeg/1.0.0/appinstances?appId={appId}
    The response body includes an appInstanceInfo array with each instance’s appInstanceId and status.

  • Delete the instance:
    DELETE {OEG_URL}/oeg/1.0.0/appinstances/{appInstanceId}
    A successful response is HTTP 204.

  • Remove the application from the catalogue:
    DELETE {OEG_URL}/oeg/1.0.0/apps/{appId}
    A successful response is HTTP 200.

Workflows and guides

Federate with a partner OP

PREREQUISITE: lite2edge

lite2edge is a strict prerequisite for this demo and must be running and properly configured before proceeding with federation.

Create Federation /partner

Use the following payload to create a new partner federation:

{
  "origOPFederationId": "swagger",
  "origOPCountryCode": "ES",
  "origOPMobileNetworkCodes": {
    "mcc": "002",
    "mncs": [
      "02"
    ]
  },
  "origOPFixedNetworkCodes": [
    "53"
  ],
  "initialDate": "2025-03-18T10:28:11.907Z",
  "partnerStatusLink": "string",
  "partnerCallbackCredentials": {
    "tokenUrl": "string",
    "clientId": "secret",
    "clientSecret": "secret"
  }
}

Create Federations /zones

Use the following payload to specify accepted availability zones for the federation:

{
    "acceptedAvailabilityZones": [
      "7f2c0b2f-3d57-4bb4-9c1f-8a3f1f4a2a9e"
    ],
    "availZoneNotifLink": "http://callback.local"
}

QoD sessions via the OEG

Requires NEF + CoreSim

Quality on Demand sessions require the NEF + CoreSim stack and the OOP Helm deployment to both be running. See also EURECOM NEF.

This section walks through creating, retrieving and deleting QoD sessions directly against the Open Exposure Gateway, and shows how to observe the bandwidth effect in Grafana.

Service URLs

Service URL
OEG API http://localhost:32263/oeg/1.0.0
OEG Swagger UI http://localhost:32263/oeg/1.0.0/docs/
Grafana http://localhost:3000

Monitor bandwidth in Grafana

Open http://localhost:3000 (no login required), go to Dashboards, and open the CoreSim dashboard. The UE Throughput panel shows per-UE downlink/uplink bandwidth in Mbps and is the most direct way to see QoD taking effect. Create a qos-e session for a UE — you should see the bandwidth step up. Delete the session and it returns to baseline.

Find a valid UE IP address

All QoD requests require a real UE IP from the core simulator. Using a made-up address will return an error.

Option A — Grafana: in the CoreSim dashboard, read the UE IP addresses (typically 12.1.0.x) from the connected UEs panel.

Option B — terminal: 

docker logs core-simulator 2>&1 | grep "PDU Session.*established" | tail -10

Look for lines like: 

PDU Session 1 established (dnn=intenet, snssai={Sst:1 Sd:0xc00022c00}, ip=12.1.0.20)

Note one of the IPs — it is used in all examples below.

QoS profiles

Profile Tier
qos-e Enhanced — highest priority
qos-s Standard
qos-m Medium
qos-l Low — best-effort

Profile names must be lowercase and hyphenated (qos-e, not QOS_E).

Create a QoD session

For each operation, Option A is curl and Option B is the Swagger UI at http://localhost:32263/oeg/1.0.0/docs/ → Quality on Demand Functions.

Option A — curl: 

curl -X POST http://localhost:32263/oeg/1.0.0/sessions \
  -H "Content-Type: application/json" \
  -d '{
    "device": {
      "ipv4Address": {
        "publicAddress": "12.1.0.20",
        "privateAddress": "12.1.0.20",
        "publicPort": 5060
      }
    },
    "applicationServer": {
      "ipv4Address": "198.51.100.10"
    },
    "qosProfile": "qos-e",
    "sink": "https://example.com/notifications",
    "duration": 3600
  }'

Replace 12.1.0.20 with the UE IP from the step above. duration is in seconds; sink is a notification webhook — a placeholder is fine for testing.

Option B — Swagger UI: click POST /sessions → Try it out, replace the body with the JSON above and click Execute.

Expected response (200 OK): 

{
  "device": {
    "ipv4Address": {
      "privateAddress": "12.1.0.20",
      "publicAddress": "12.1.0.20",
      "publicPort": 5060
    }
  },
  "applicationServer": { "ipv4Address": "198.51.100.10" },
  "qosProfile": "qos-e",
  "qosStatus": "REQUESTED",
  "sessionId": "2e3b742f-a6be-4cd1-b167-3355a86c92cc",
  "sink": "https://example.com/notifications",
  "duration": 3600
}

Save the sessionId for the next two calls.

Retrieve a QoD session

Option A — curl: 

SESSION_ID="2e3b742f-a6be-4cd1-b167-3355a86c92cc"

curl -X GET "http://localhost:32263/oeg/1.0.0/sessions/${SESSION_ID}" \
  -H "accept: application/json"

Option B — Swagger UI: click GET /sessions/{sessionId} → Try it out, enter the sessionId and click Execute.

The response is identical in structure to the create response. Note that qosStatus moves from REQUESTED to AVAILABLE once the NEF confirms the session with the core network.

Delete a QoD session

Option A — curl: 

SESSION_ID="2e3b742f-a6be-4cd1-b167-3355a86c92cc"

curl -X DELETE "http://localhost:32263/oeg/1.0.0/sessions/${SESSION_ID}" \
  -H "accept: application/json"

Option B — Swagger UI: click DELETE /sessions/{sessionId} → Try it out, enter the sessionId and click Execute. Expected response is 2xx.

Verify via NEF logs

After any operation you can confirm the NEF processed the call end-to-end:

docker logs 3gpp-as-session-with-qos --tail 20
  • After create: look for a POST request and a successful session entry, e.g. POST /3gpp-as-session-with-qos/v1/scs-test/subscriptions.
  • After retrieve: look for GET /3gpp-as-session-with-qos/v1/scs-test/subscriptions/<sessionId>.
  • After delete: look for DELETE /3gpp-as-session-with-qos/v1/scs-test/subscriptions/<sessionId>.

If these lines appear the full chain — OEG → SRM → NEF — completed successfully.

AI2 — Natural language interface

AI2 is the AI-native interface to the platform. Instead of constructing API calls manually, you describe what you want in natural language and AI2 translates it into the appropriate NBI operations. See Architecture for an overview.

Prerequisites:

  • AI2 is running (see the ai2-mcp and ai2-ai-agent pods in your deployment)
  • A Groq API key is configured in secrets.values.yaml (see Deploy on KIND and Kubernetes)

The AI Agent is reachable at http://localhost:32013.

Create a QoD session via natural language

Requires NEF

Quality on Demand sessions require a Network Exposure Function to be deployed and connected to OOP. See EURECOM NEF for setup.

Once NEF is integrated, you can create a QoD session in plain English:

curl -s -X POST http://localhost:32013/groq-mcp \
  -H "Content-Type: application/json" \
  -d '{
    "query": "create a QoD session for device 198.51.100.1, app server 198.51.100.2, profile QOS_L, duration 3600 seconds"
  }'

AI2 interprets the query, calls the appropriate CAMARA QoD API on your behalf, and returns the session details including the sessionId.

To delete the session, pass the sessionId returned above:

curl -s -X POST http://localhost:32013/groq-mcp \
  -H "Content-Type: application/json" \
  -d '{"query": "delete QoD session <sessionId>"}'

Next steps