QoS prediction along a route

The standardised interface

Public material on predictive quality of service mostly covers the model, the forecasting of throughput or latency from network analytics. ETSI GS MEC 030 [1] standardises the interface around it. It defines how a vehicle application asks for a prediction along a route and the shape of the answer. Where the number comes from stays with the implementation.

The algorithm is well covered in the literature. This sheet documents the interface a MEC application integrates against, the request it sends and the response it parses.

What the resource does

The V2X Information Service produces journey-specific predictive QoS notifications (MEC 030 [1] §5.4.5). A consumer describes a route as an ordered list of waypoints; the service returns predicted KPIs for that route, each carried with a confidence value. The request is a POST to provide_predicted_qos (§7.7), and the payload type is PredictedQos (§6.2.6).

Asking for a prediction

A request carries the route as routes, a list whose entries hold routeinfo, the ordered waypoints. A route needs at least two waypoints, an origin and a destination (§6.2.6). locationGranularity states the spatial resolution the consumer wants the answer at.

curl -sS -X POST https://mec.skyv2x.com/vis/v2/provide_predicted_qos \
  -H 'Content-Type: application/json' \
  -d '{
    "locationGranularity": "100",
    "routes": [
      { "routeinfo": [
          { "location": { "geoArea": { "latitude": 43.7228, "longitude": 10.4017 } } },
          { "location": { "geoArea": { "latitude": 43.7248, "longitude": 10.4047 } } }
      ] }
    ]
  }'

Three things that return an error

The route lives inside routes[]; routeinfo at the top level is rejected. The key is routeinfo in lower case, even though the prose of the standard writes routeInfo (a documented contradiction in the schema). A route with a single waypoint returns 400, since origin and destination are both required. A location outside the testbed edge zone returns 404.

The answer

The response repeats the requested route and adds a qos object. Its stream array carries one entry per predicted stream, each with a streamId and a set of qosKpi items, every item a KPI name, a value with its unit, and a confidence. A consumer reads the KPIs it needs and weighs the confidence alongside the value.

{
  "locationGranularity": "100",
  "routes": [
    {
      "routeinfo": [
        {
          "location": {
            "geoArea": {
              "latitude": 43.7228,
              "longitude": 10.4017
            }
          }
        },
        {
          "location": {
            "geoArea": {
              "latitude": 43.7248,
              "longitude": 10.4047
            }
          }
        }
      ]
    }
  ],
  "qos": {
    "stream": [
      {
        "streamId": "stream-1",
        "qosKpi": [
          {
            "kpiName": "latency",
            "kpiValue": "15ms",
            "confidence": "0.90"
          },
          {
            "kpiName": "UL bitrate",
            "kpiValue": "50Mbps",
            "confidence": "0.85"
          },
          {
            "kpiName": "DL bitrate",
            "kpiValue": "100Mbps",
            "confidence": "0.80"
          }
        ]
      }
    ]
  }
}

The values above are synthetic. No prediction model runs behind this endpoint. The testbed generates the numbers and holds the confidences fixed, with no measurement involved. That is enough to build and test an integration against the interface. A production deployment wires the same contract to a real analytics source, and the response shape stays the same.

Where this sits

A route-based prediction from a MEC application at the edge is one half of the picture. The other is an area-based prediction from the operator network, which a network QoS API such as CAMARA provides. The two answer different questions and work together. A separate sheet sets out the boundary.

[1] ETSI GS MEC 030 V3.2.1, V2X Information Service API. §5.4.5, §5.5.5, §6.2.6, §7.7. PDF.