SkyV2X · Open Testbed Public · Section 3 · Surface Rate limited · 120 req/min
TLA-VIS-001  v0.2.0  ·  2026-06-21
3 Surface

The eight resources

The V2X Information Service exposes eight resources under one API root. Errors follow RFC 7807 ProblemDetails per ETSI GS MEC 009 [2].

3.1Resources

Resource map

ETSI GS MEC 030 [1] defines the V2X Information Service as eight resources under /vis/v2/. Talaia maps them one-to-one.

MethodPathResource
GET/vis/v2/queries/uu_unicast_provisioning_infoUu unicast provisioning · LTE/NR cells
GET/vis/v2/queries/uu_mbms_provisioning_infoUu MBMS provisioning
GET/vis/v2/queries/pc5_provisioning_infoPC5 sidelink provisioning
GET/vis/v2/subscriptionsSubscription registry
POST/vis/v2/subscriptionsCreate subscription
POST/vis/v2/provide_predicted_qosPredicted QoS along a route
POST/vis/v2/provide_v2x_msg_distribution_server_infoBroker discovery · MQTT v5
POST/vis/v2/publish_v2x_messagePublish a V2X message
3.2Provisioning

Radio access provisioning

The provisioning queries inform a MEC application of the radio layer reachable from the local edge. Talaia serves real Uu unicast data from the SkyV2X testbed cell. MBMS and PC5 are declared mocks until the real sources land.

Listing 3.2-1 — Uu unicast provisioning

curl -sS https://mec.skyv2x.com/vis/v2/queries/uu_unicast_provisioning_info

Listing 3.2-2 — Uu MBMS and PC5 (declared mocks)

curl -sS https://mec.skyv2x.com/vis/v2/queries/uu_mbms_provisioning_info
curl -sS https://mec.skyv2x.com/vis/v2/queries/pc5_provisioning_info
3.3Subscriptions

Subscriptions and broker fan-out

A subscription scopes which V2X messages an integrator wants to receive. The platform matches by message type, geographic area and station type, then fans out via MQTT v5. The response carries the subscription body and the topic to consume.

Talaia V2X subscription lifecycle — create, store, fan-out, notify, expire Sequence diagram of a V2X subscription lifecycle on the Talaia MEC platform. Step 1: an integrator POSTs a V2xMsgSubscription to /vis/v2/subscriptions. Step 2: Talaia stores the subscription in Redis with a TTL derived from expiryDeadline. Step 3: incoming V2X messages match against the filter criteria (msgType, location, stationType). Step 4: matching messages are fanned out via the Mosquitto MQTT v5 broker on the topic returned in the response. Step 5: consumer applications subscribed to that topic receive the notification. Step 6: on TTL expiry the subscription is removed automatically. INTEGRATOR TALAIA REDIS / MQTT v5 CONSUMER 1. POST /vis/v2/subscriptions V2xMsgSubscription + filterCriteria 2. store sub · TTL = expiryDeadline namespace sub: + UUID 201 Created · Location: ... 3. match incoming V2X · publish topic /vis/ue/v2x_msg · msgProtocol=2 4. notify · MQTT v5 fan-out CAM / DENM / CPM / VAM payload 5. TTL expire → sub removed (or DELETE on demand)
Figure 3.3-1. V2X subscription lifecycle: POST /vis/v2/subscriptions → Redis store with TTL → match against incoming V2X messages → publish to /vis/ue/v2x_msg on the MQTT v5 broker (msgProtocol = 2) → notify consumer.

Listing 3.3-1 — List active subscriptions

curl -sS https://mec.skyv2x.com/vis/v2/subscriptions

Listing 3.3-2 — Create a V2X message subscription

curl -sS -X POST https://mec.skyv2x.com/vis/v2/subscriptions \
  -H 'Content-Type: application/json' \
  -d '{
    "subscriptionType": "V2xMsgSubscription",
    "callbackReference": "mqtt://your-client/talaia/cpm",
    "filterCriteria": { "msgType": ["denm", "cpm"] }
  }'
3.4Errors

Error surface · RFC 7807

Per ETSI GS MEC 009 [2], every error response carries an RFC 7807 ProblemDetails body with media type application/problem+json. No HTML error pages and no plain text. The same shape applies on every 4xx and 5xx.

ProblemDetails error surface — RFC 7807 + ETSI MEC 009 §6.15 Schema of the Talaia error response surface. Every 4xx and 5xx HTTP status returns a single shape: an application/problem+json body with five fields. type is a URI identifying the problem type or about:blank when unspecified. title is a short human-readable summary. status is the HTTP status code as integer. detail is the specific cause for this occurrence. instance is the URI of the failed request. The shape applies uniformly to all five MEC services on the platform: V2XIS, Location, RNIS, App Support. ANY 4xx / 5xx · ANY MEC SERVICE Content-Type: application/problem+json type URI of problem type · "about:blank" if unspecified title short human summary · "Bad Request" status HTTP status code as integer · 400 detail specific cause of this occurrence instance URI of the failed request IETF RFC 7807 · ETSI GS MEC 009 §6.15
Figure 3.4-1. ProblemDetails shape returned by every Talaia error response. Five fields under application/problem+json; same envelope across all five MEC services, on every 4xx and 5xx. Defined by IETF RFC 7807 and adopted by ETSI GS MEC 009 §6.15.

Listing 3.4-1 — Sample 400 response

HTTP/1.1 400 Bad Request
Content-Type: application/problem+json

{
  "type": "about:blank",
  "title": "Bad Request",
  "status": 400,
  "detail": "filterCriteria.msgType: must contain at least one value",
  "instance": "https://mec.skyv2x.com/vis/v2/subscriptions"
}
3.5Discovery

Discovery surface

Three machine-readable summaries make integration without documentation viable.

GET /vis/v2/capabilities declares what Talaia claims to implement, version-pinned. GET /vis/v2/status.json exposes the live operational state. GET /vis/v2/conformance returns the conformance audit verdict.

3.6Limits

Rate limits

The API is metered per client address at 120 requests a minute, with a burst of 40. Past that the platform answers 429 Too Many Requests carrying the same application/problem+json body as any other error, and the allowance refills as the window moves. The pages you are reading are not metered.

The figure is the current setting on a shared testbed, not a service level.

3.7Caveat

Testbed caveat

Talaia is open for integrators and researchers. The provisioning data describes the SkyV2X internal cell, adequate for spec-strict integration testing, not for production radio attachment. The testbed runs without authentication; a deployment handling real traffic sits behind a token-validating gateway, and the V2X it relays is signed at the source, with trust anchored to Castell.

3.8Reference

Reference sheets

Three parts of this surface have a sheet of their own. The QoS prediction API with its request and response, the boundary with operator network QoS APIs such as CAMARA, and receiving V2X at the roadside over the network.