IoT interoperability standards address data format, semantic meaning, and cross-domain integration. SenML (RFC 8428) reduces sensor payload size by 70%+ through base values, JSON-LD adds semantic context via shared ontologies, W3C Web of Things enables protocol-agnostic device discovery, and oneM2M provides a horizontal platform for cross-domain enterprise integration.
Key Concepts
SenML (Sensor Markup Language): IETF RFC 8428 standard for representing simple sensor data (name, value, unit, timestamp) in JSON, CBOR, or XML with a shared measurement registry
JSON-LD (JSON for Linked Data): W3C standard extending JSON with semantic context (@context, @type, @id) enabling IoT data to be unambiguously interpreted by automated systems
W3C Web of Things Thing Description: JSON-LD document format describing IoT device capabilities, properties, actions, events, and interaction affordances in a machine-readable schema
OCF (Open Connectivity Foundation): Alliance and specification for device discovery and secure resource-oriented IoT communication based on CoAP and REST principles
IPSO Smart Objects: Object model (OMA LwM2M) standardizing how IoT devices expose sensor readings and actuator controls in a uniform resource structure
Fiware NGSI-LD: European standard for IoT context information management based on JSON-LD, providing rich entity-relationship data models for smart city applications
oneM2M: Global standards body and platform specification for IoT interoperability across telecom operators, with a common service layer supporting diverse underlying protocols
Matter: Alliance for IP home automation interoperability over Thread/Wi-Fi, using a defined data model that allows devices from different manufacturers to work together
Learning Objectives
After completing this chapter, you will be able to:
Implement SenML (Sensor Measurement Lists) for efficient IoT data representation with base-value compression
Construct JSON-LD documents that add semantic context to IoT data using shared ontologies
Differentiate the W3C Web of Things framework components (Thing Descriptions, Binding Templates, Scripting API) and their roles
Apply oneM2M standards for horizontal IoT platform integration across domains
Select appropriate standards for different interoperability scenarios based on payload size, semantic richness, and ecosystem maturity
For Beginners: Interoperability Standards
Interoperability standards are the agreed-upon rules that let different IoT devices communicate. Think of how any phone can call any other phone regardless of brand, because they all follow the same standards. Without these standards, each IoT device would be an island, unable to share data with anything from a different manufacturer.
9.1 Prerequisites
Before diving into this chapter, you should be familiar with:
Interoperability Fundamentals: Understanding the four interoperability levels is essential for knowing why these standards exist and which level each addresses
Basic JSON: Understanding JSON structure is necessary for working with SenML and JSON-LD
REST APIs: Familiarity with HTTP methods and resource-oriented design helps understand W3C WoT
Figure 9.1: Data model mapping bridges the gap between different IoT device schemas. Mapping rules define how fields correspond across schemas, handle type conversions, and resolve semantic differences like unit conversions or naming conventions.
9.2 SenML: Sensor Measurement Lists (RFC 8428)
⏱️ ~10 min | ⭐⭐ Intermediate | 📋 P10.C11.U03
SenML provides a lightweight, standardized format for sensor data that dramatically reduces payload size through base values – critical for constrained networks.
9.2.1 Why SenML Matters
Traditional JSON sensor payloads repeat metadata for every reading:
This SenML payload is approximately 175 bytes – about 40% smaller for just 3 readings. The savings increase dramatically with more readings because the base values (bn, bt, bu) are declared only once.
9.2.2 SenML Base Values
Field
Name
Description
Example
bn
Base Name
Prefix for all n values
"urn:dev:ow:10e2073a01080063:"
bt
Base Time
Added to all t values
1609459200 (Unix epoch)
bu
Base Unit
Default unit for all v values
"Cel" (Celsius)
bv
Base Value
Added to all v values
100 (offset)
bs
Base Sum
Added to all s values
0
bver
Base Version
SenML version
10
9.2.3 Payload Savings Analysis
For a sensor sending 100 readings with device name, unit, and base timestamp:
Format
Size
Savings
Plain JSON
~8,000 bytes
baseline
SenML (JSON)
~2,500 bytes
~69% smaller
SenML (CBOR)
~1,200 bytes
~85% smaller
Putting Numbers to It
SenML base values reduce payload size by eliminating repetitive metadata. Calculate compression ratio:
SenML Compression Formula: \(CR = 1 - \frac{S_{senml}}{S_{plain}}\) where \(S\) = payload size in bytes.
Worked example (temperature sensor reporting 100 readings):
For LoRaWAN (242-byte limit): Plain JSON fits ~3 readings/message (240 / 80 = 3). SenML fits ~7 readings/message ((242 - 60) / 24 = 7.6). That means roughly 2.5x fewer transmissions for the same data, translating directly to longer battery life since transmission dominates power budget on LPWAN.
This matters enormously for constrained networks: - LoRaWAN: 51-242 byte payloads - NB-IoT: Charged per byte - Sigfox: 12 byte limit
Interactive: Serialization Comparator
Interactive: Serialization Basics
Interactive: Advanced Serialization
Interactive: Serialization Scenarios
9.2.4 SenML Units
SenML defines standard unit symbols (RFC 8428 Section 12.1):
Unit
Symbol
Description
Celsius
Cel
Temperature
Percent
%
Relative humidity, battery
Lux
lx
Illuminance
Pascal
Pa
Pressure
Watt
W
Power
Meter
m
Distance
Meters/second
m/s
Velocity
9.3 JSON-LD: Linked Data for IoT
⏱️ ~10 min | ⭐⭐ Intermediate | 📋 P10.C11.U04
JSON-LD (JSON for Linked Data) adds semantic meaning to JSON by linking terms to shared vocabularies through the @context annotation.
9.3.1 The Problem JSON-LD Solves
Without shared vocabulary, different vendors use different terms:
{"temp":22.5}{"temperature":22.5}{"t":22.5}
Machines cannot know these all mean the same thing. JSON-LD fixes this:
Now any system understanding SOSA/QUDT ontologies knows exactly what “temperature” means.
9.3.2 Key JSON-LD Concepts
Keyword
Purpose
Example
@context
Maps terms to URIs
Links “temperature” to SOSA ontology
@id
Unique identifier
"urn:sensor:temp-001"
@type
Type classification
"sosa:Observation"
@value
Literal value
22.5
@language
Language tag
"en"
9.3.3 Common IoT Ontologies
Ontology
Purpose
URL
SOSA/SSN
Sensors and observations
http://www.w3.org/ns/sosa/
QUDT
Units and quantities
http://qudt.org/schema/qudt/
Schema.org
General concepts
https://schema.org/
SAREF
Smart appliances
https://saref.etsi.org/core/
Figure 9.2: Semantic interoperability with ontology-based data integration
MVU: Standard Data Formats (SenML and JSON-LD)
Core Concept: SenML (RFC 8428) reduces payload size by 70%+ through base values that eliminate repetitive metadata, while JSON-LD adds semantic context through @context annotations linking terms to shared ontologies.
Why It Matters: Constrained IoT networks (LoRaWAN, NB-IoT) have strict byte limits where every byte counts. SenML’s compression enables more readings per transmission.
Key Takeaway: Use SenML for bandwidth-constrained sensor networks (base values: bn, bt, bu). Use JSON-LD when you need machines to understand data semantics across different vendors.
9.4 W3C Web of Things (WoT)
⏱️ ~15 min | ⭐⭐ Intermediate | 📋 P10.C11.U05
The W3C Web of Things framework provides a standardized way to describe IoT device capabilities through Thing Descriptions (TD) – machine-readable documents that expose what a device can do.
9.4.1 Thing Description Structure
A Thing Description is a JSON-LD document containing:
Applications read the TD, discover available protocols, and choose based on their capabilities.
9.5 oneM2M: Horizontal IoT Platform
⏱️ ~10 min | ⭐⭐ Intermediate | 📋 P10.C11.U06
oneM2M provides a horizontal platform layer that abstracts vertical-specific implementations (smart cities, healthcare, automotive) through a common service layer.
Is network constrained (LoRa, NB-IoT)?
├─ YES → Use SenML for data payload
└─ NO → Continue
Do you need machines to understand data meaning?
├─ YES → Add JSON-LD @context
└─ NO → Plain JSON may suffice
Do devices need self-description for discovery?
├─ YES → Implement W3C WoT Thing Descriptions
└─ NO → Static API documentation may suffice
Integrating multiple vendors across domains?
├─ YES → Consider oneM2M platform layer
└─ NO → Point solutions may suffice
Choose interoperability standards based on your constraints: SenML for bandwidth-limited networks (70%+ payload reduction through base values), JSON-LD when machines must understand data semantics across vendors (links terms to shared ontologies via @context), W3C WoT for protocol-agnostic device discovery (Thing Descriptions expose properties, actions, and events), and oneM2M for enterprise cross-domain integration (horizontal platform with common service layer). Most production systems combine multiple standards at different layers.
For Kids: Meet the Sensor Squad!
“The Shrinking Message!”
Sammy the Sensor had a problem. He needed to send his temperature readings over a LoRaWAN network, but the messages could only be tiny – like fitting a whole letter onto a postage stamp!
“My message is too big!” Sammy cried. Every time he sent a reading, he had to include his name, the time, the unit, and the value. “That’s like writing my full name and address on every single line of a letter!”
Max the Microcontroller had a trick. “Use SenML! Instead of writing your name and address on every line, write it ONCE at the top. Then each reading just needs the new number and how many seconds have passed.”
“That’s 70% smaller!” Bella the Battery cheered. “Less data means less energy to transmit. I love it!”
Lila the LED raised her hand. “But what about when devices from different companies need to understand each other? Vendor A says ‘temp’ and Vendor B says ‘temperature.’”
“That’s where JSON-LD comes in,” Max explained. “It’s like adding a link to a shared dictionary. When you write ‘temp,’ JSON-LD adds a note that says ‘this means the same as temperature in the official science dictionary.’ Now ANY device can look it up and understand!”
“And what about discovering new devices?” Sammy asked.
“W3C Web of Things handles that! Each device carries a little card called a Thing Description that says: ‘Hi, I’m a smart lamp. You can read my brightness, tell me to toggle on or off, and I’ll warn you if I overheat.’ It’s like a name tag that tells you everything the device can do!”
The Sensor Squad learned: IoT standards are like different tools in a toolbox – SenML shrinks your messages, JSON-LD adds meaning, and WoT helps devices introduce themselves. Use the right tool for the right job!
Worked Example: Implementing SenML with Base Values for LoRaWAN Agricultural Sensors
A vineyard deploys 50 soil moisture sensors (LoRaWAN SF12, 51-byte payload limit). Each sensor reports temperature, moisture, EC (electrical conductivity), and battery voltage every 15 minutes. Design a SenML payload that fits multiple sensors per transmission.
Note: Because each measurement type uses a different unit (Cel, %RH, uS/cm, V), we cannot use bu (base unit) here – it only sets a single default unit for the entire pack. Instead, each record includes its own u field. The savings come from bn (base name) and bt (base time) eliminating repeated device identifiers and full timestamps.
Breakdown:
Base name (bn): “urn:dev:vineyard:C-” (common prefix, sent once) = ~25 bytes
Base time (bt): 1736424000 (sent once) = ~13 bytes
First sensor (042): 4 readings with units = ~95 bytes
Second sensor (043): time offset (t:60), 4 readings with units = ~90 bytes
Third sensor (044): time offset (t:120), 4 readings with units = ~90 bytes
Total JSON: ~313 bytes
Further compression with CBOR (binary encoding):
SenML JSON -> SenML CBOR using RFC 8428 CBOR representation
CBOR uses binary integers, shorter field names (bn -> -2, v -> 2)
Result: ~150 bytes (chunked into 3 messages at 51-byte LoRaWAN limit)
Final LoRaWAN transmission strategy:
Message 1: Base values + sensor 042 (~50 bytes compressed)
Message 2: Sensor 043 (delta from base time, ~45 bytes)
Message 3: Sensor 044 (delta from base time, ~45 bytes)
Multi-vendor enterprise platform? -> oneM2M (heavy) or FIWARE (lighter, open-source)
Just need efficient time-series format? -> SenML JSON (readable) or SenML CBOR (efficient)
Common Mistake: Over-Engineering Semantic Interoperability for Simple Systems
Developers add JSON-LD context, ontology mappings, and complex semantic annotations to simple IoT deployments where all devices are from one vendor and data never leaves the organization. This adds complexity without benefit.
What goes wrong: A small smart home startup builds a temperature monitoring system with 20 device types (thermostats, sensors, HVAC controllers). All devices are custom-designed and communicate via internal MQTT broker. An engineer, concerned about “future interoperability,” implements JSON-LD with full SOSA/SSN ontology annotations:
Gateway translates on demand: Internal -> JSON-LD for external consumption, External JSON-LD -> Internal format for device ingestion
Start simple, add semantics when needed:
Phase 1 (MVP): Plain JSON with documented schema
Phase 2 (scaling internally): Schema registry (Avro, Protobuf) for type safety
Phase 3 (external integration): Add JSON-LD context translation at API gateway
Phase 4 (multi-vendor ecosystem): Full ontology support with SOSA/SSN
Real consequence: An industrial IoT startup implemented full OWL ontology-based semantic modeling for their 500-device pilot deployment (single factory, single vendor). Engineers spent 6 months building ontology mappings, RDF triple stores, and SPARQL query interfaces. After launch, they discovered:
No external systems integrated (all internal)
RDF query performance was 50x slower than PostgreSQL for time-series queries
Triple store consumed 10x more storage than time-series database
They rewrote the entire stack using TimescaleDB + plain JSON, launching v2.0 in 2 months. The lesson: semantic standards are powerful for interoperability, but premature adoption creates complexity that may never be justified. Start simple, add semantics only when cross-vendor integration becomes real.
🏷️ Label the Diagram
💻 Code Challenge
9.8 Summary
SenML (RFC 8428) provides lightweight sensor data representation with base values (bn, bt, bu) that reduce payload size by 70%+ through eliminating repetitive metadata, critical for constrained networks like LoRaWAN and NB-IoT.
JSON-LD enables semantic interoperability by linking terms to shared vocabularies through @context annotations, allowing heterogeneous systems to understand that different terms reference the same concepts.
W3C Web of Things framework uses Thing Descriptions (JSON-LD documents) to expose device capabilities through properties (readable/writable state), actions (invocable operations), and events (push notifications), with protocol bindings enabling HTTP, CoAP, MQTT access.
oneM2M provides a horizontal platform layer with common service entity (CSE) that abstracts vertical-specific implementations, enabling cross-domain integration through a unified resource model and multiple protocol bindings.
Standard selection depends on constraints: SenML for bandwidth-limited networks, JSON-LD for semantic understanding, WoT for device discovery, oneM2M for enterprise cross-domain integration.
1. Choosing Proprietary Data Models Instead of Open Standards
Using proprietary data models (vendor-specific JSON schemas, custom binary formats) for IoT devices creates long-term lock-in to specific platforms and prevents future integration with other systems. Adopt SenML, W3C WoT Thing Descriptions, or NGSI-LD for sensor data representation to preserve integration options.
2. Implementing Standards Without Using Conformance Test Suites
Self-certifying standard compliance without running conformance test suites produces implementations that pass basic tests but fail edge cases when integrated with other vendors’ devices. Always use available conformance test suites (W3C WoT test suite, OCF certification tests) before declaring standard compliance.
3. Selecting a Standard Based on Current Requirements Only
IoT standards ecosystems evolve — a standard popular today may be deprecated or superseded in 5 years. Before adopting a standard, evaluate its governance (open community vs. single vendor), adoption trajectory (growing vs. declining), and migration path to future standards.
4. Conflating Protocol Standards With Data Model Standards
Choosing MQTT (a protocol standard) does not specify the data format of messages — that requires a separate data model standard (SenML, JSON-LD). Protocol standards and data model standards address different aspects of interoperability and must both be specified. A complete interoperability specification names both the transport protocol AND the message data model.
9.12 What’s Next
If you want to…
Read this
Study the foundational concepts of interoperability
