Deep diveIoT & Smart Cities

Smart city interoperability standards and how they fit together

Smart city interoperability standards work in layers. oneM2M addresses the device and service layer, OGC SensorThings API and ETSI NGSI-LD define how observations and context are exposed through APIs, FIWARE Smart Data Models give shared vocabularies, and the OASC Minimal Interoperability Mechanisms set a minimum baseline a city can require. Used together and tested before go-live, they let a city swap a supplier at one layer without losing data at the others.

Reviewed 6 min read

On this page
  1. Three ways lock-in creeps into a city data platform
  2. Where each standard sits in a city data stack
  3. Standards and terms in the city interoperability stack
  4. NGSI-LD, SensorThings and oneM2M: what each one standardizes
  5. Identifiers, units and time: the details that decide whether data survives
  6. Testing conformance before a platform goes live
  7. What to name in a tender, plus security and privacy pointers
  8. Hypothetical: replacing a streetlight control platform without losing history
  9. Questions and answers
  10. Sources

Three ways lock-in creeps into a city data platform

The first is a proprietary data format. A streetlight vendor stores dimming schedules, faults and energy readings in its own schema, so moving to another vendor means losing history or paying for a custom migration. The second is a closed broker: applications are written against one supplier's API, so changing the platform means rewriting every dashboard and integration. The third is bundling, where devices, network and platform are sold as one contract and cannot be replaced separately.

Interoperability standards attack each of these at a different layer. None of them is sufficient on its own, which is why the useful question is not which standard to pick but which standard governs which boundary.

Where each standard sits in a city data stack

Applications and portals01Shared data models02Context and observation APIs03Device and service layer04Connectivity05Devices and controllers06
  1. Applications and portals

    Dashboards, resident services, analytics and open data portals that consume standard APIs.

  2. Shared data models

    FIWARE Smart Data Models define entity types such as streetlights, parking spots and air-quality observations.

  3. Context and observation APIs

    NGSI-LD context brokers and OGC SensorThings API servers expose current state and time series.

  4. Device and service layer

    oneM2M provides a common service layer for registering, managing and reaching devices.

  5. Connectivity

    LoRaWAN, NB-IoT, LTE-M, mesh or fiber carry data from the field.

  6. Devices and controllers

    Sensors, meters, lighting controllers and signal cabinets in the street.

Conceptual layering of a city data platform, top to bottom. Real deployments may skip or merge layers; this is not a reference to any specific city.

Standards and terms in the city interoperability stack

NGSI-LD
An ETSI API and information model, published as ETSI GS CIM 009, for managing context information as entities with properties and relationships, using JSON-LD for semantics1.
Context broker
The server that implements NGSI-LD: it stores current entity state, answers queries, supports temporal queries and notifies subscribers when values change.
Smart Data Models
An open program publishing reusable data models as JSON Schema with NGSI-LD and JSON-LD examples, plus tools to validate payloads against them2.
OGC SensorThings API
An OGC standard for IoT observations: Part 1 Sensing defines Thing, Location, HistoricalLocation, Datastream, Sensor, ObservedProperty, Observation and FeatureOfInterest, with an optional MQTT extension34.
OASC MIMs
Minimal Interoperability Mechanisms from Open & Agile Smart Cities: foundational mechanisms for accessing, interlinking, representing and exchanging data, plus application-specific ones5.
oneM2M
A global partnership standard defining a horizontal service layer between IoT devices and applications, so applications are not written to each device type7.
JSON-LD @context
The part of an NGSI-LD payload that maps short attribute names to globally defined terms, so two systems agree on what an attribute means.
Entity identifier
A stable URI for each real-world asset, such as a specific streetlight, that survives changes of device, vendor or platform.

NGSI-LD, SensorThings and oneM2M: what each one standardizes

QuestionNGSI-LDOGC SensorThings APIoneM2M
Core abstractionEntities with properties and relationshipsThings, datastreams and observationsA resource tree in a common service layer
Strongest atCurrent state and links between assetsSensor metadata and time-series observationsDevice registration and management across vendors
Query styleEntity, geo and temporal queries; subscriptionsOData-style queries over REST; optional MQTTRESTful resource operations over several protocol bindings
SemanticsJSON-LD contexts and shared data modelsObserved properties and units defined per datastreamOwn resource types, with semantic annotation options
Typical positionCity data platform coreEnvironmental and sensor data servicesBetween field devices and the platform

These standards overlap at the edges. Some platforms expose NGSI-LD for context and SensorThings for observation history, bridged by a shared data model.

Identifiers, units and time: the details that decide whether data survives

Most failed migrations break on small things. Give every asset a persistent identifier that belongs to the city, not to the device or the vendor, and keep a mapping table when a physical device is replaced. Record units explicitly with standard unit codes rather than in attribute names, and store timestamps in UTC with a clear distinction between when something was observed and when it was received.

The MIMs approach helps here because it describes capabilities, such as interlinking data across systems with consistent identifiers, rather than mandating one product6. That leaves the city to choose which concrete standards implement each mechanism, and to write that choice down so every supplier works to the same profile. OASC reported in 2024 that ITU had adopted a Y.MIM standard based on this work8.

Testing conformance before a platform goes live

  1. Validate payloads against the agreed models

    Run sample messages from every supplier through Smart Data Models validation tools or your own JSON Schemas, and reject fields that are not in the agreed profile.

    Output
    Validation report per supplier

  2. Run API contract tests

    Test the broker or SensorThings server against the operations your applications use: creation, queries, geo filters, temporal queries and subscriptions.

    Output
    API test suite in the city's repository

  3. Exercise the export path

    Export a full dataset, including history, into a second standards-compliant platform and confirm dashboards still work against it.

    Output
    Round-trip evidence

  4. Replace a device type on paper and in test

    Introduce a second vendor's device for one entity type and confirm data lands in the same entities without application changes.

    Output
    Substitution test result

What to name in a tender, plus security and privacy pointers

Name the standards by layer, the data model profile, the identifier scheme, the export format and the conformance tests a supplier must pass, and require that the city owns the data and the models. The wider procurement process, scoring and contract clauses are covered in buying AI in government. In the EU, the Interoperable Europe Act, Regulation (EU) 2024/903, adds interoperability assessments for some public-sector systems9.

Security standards sit alongside these. ISA/IEC 62443 sets security requirements for industrial automation and control systems, which describes much of the equipment in street cabinets10. In the EU, the Cyber Resilience Act, Regulation (EU) 2024/2847, applies its manufacturer reporting duties from 11 September 2026 and most obligations from 11 December 202711; in the UK, the product security regulations for connectable products came into force on 29 April 202412. Publish a register of public sensors and run a data protection impact assessment wherever personal or location data is involved.

Hypothetical: replacing a streetlight control platform without losing history

Questions and answers

Does a city need to adopt every interoperability standard?

No. Pick one standard per boundary and write it into a city profile: for example, NGSI-LD for context, Smart Data Models for vocabularies and SensorThings where an observation service is needed. Adopting overlapping standards without a profile recreates the integration problem the standards were meant to solve.

How do these standards relate to an open data portal?

The platform standards move live data between systems; an open data portal publishes curated datasets for reuse. Portals usually describe datasets with metadata vocabularies such as W3C DCAT, and can be fed from the context broker or observation service so published data stays current without manual uploads.

Can small suppliers comply with NGSI-LD and Smart Data Models?

Generally yes. The specifications and data models are openly published, open-source brokers and validation tools exist, and a small supplier can often adapt by mapping its output to the agreed model. Cities can lower the barrier further by publishing their profile, test suite and sample payloads before the tender.

Is NGSI-LD the same as FIWARE?

Not quite. NGSI-LD is an ETSI specification. FIWARE is an open-source ecosystem whose context brokers implement NGSI-LD and whose community contributes to the Smart Data Models program. A city can use NGSI-LD with brokers from FIWARE or from other implementers.

Sources

  1. ETSI GS CIM 009: Context Information Management (CIM); NGSI-LD API — ETSI · checked 10 October 2026
  2. Smart Data Models — Smart Data Models Program · checked 10 October 2026
  3. OGC SensorThings API — Open Geospatial Consortium · checked 10 October 2026
  4. OGC SensorThings API Part 1: Sensing Version 1.1 — Open Geospatial Consortium · checked 10 October 2026
  5. Minimal Interoperability Mechanisms — Open & Agile Smart Cities · checked 10 October 2026
  6. OASC MIMs framework — Open & Agile Smart Cities · checked 10 October 2026
  7. oneM2M: standards for IoT — oneM2M · checked 10 October 2026
  8. United Nations approves Y.MIM standard for minimal interoperability — Open & Agile Smart Cities · checked 10 October 2026
  9. Regulation (EU) 2024/903 (Interoperable Europe Act) — EUR-Lex · checked 10 October 2026
  10. ISA/IEC 62443 series of standards — International Society of Automation · checked 10 October 2026
  11. Regulation (EU) 2024/2847 (Cyber Resilience Act) — EUR-Lex · checked 10 October 2026
  12. The Product Security and Telecommunications Infrastructure (Security Requirements for Relevant Connectable Products) Regulations 2023 — legislation.gov.uk · checked 10 October 2026

More in IoT & Smart Cities

Back to IoT & Smart Cities

Next step

Draft a city interoperability profile before the next tender

Send your current platform diagram and the systems you plan to procure. We will propose a layer-by-layer standards profile, an identifier scheme and the conformance tests suppliers should pass.

Request a profile draft