1312  Interoperability Standards

Learning Objectives

After completing this chapter, you will be able to:

• Implement SenML (Sensor Measurement Lists) for efficient IoT data representation
• Use JSON-LD to add semantic context to IoT data
• Understand the W3C Web of Things framework and Thing Descriptions
• Apply oneM2M standards for horizontal IoT platform integration
• Choose appropriate standards for different interoperability scenarios

1312.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 1312.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.

1312.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.

1312.2.1 Why SenML Matters

Traditional JSON sensor payloads repeat metadata for every reading:

// Plain JSON: 240 bytes for 3 readings
[
  {"device": "sensor123", "type": "temperature", "value": 22.5, "unit": "Cel", "timestamp": 1609459200},
  {"device": "sensor123", "type": "temperature", "value": 22.7, "unit": "Cel", "timestamp": 1609459260},
  {"device": "sensor123", "type": "temperature", "value": 22.6, "unit": "Cel", "timestamp": 1609459320}
]

SenML eliminates repetition with base values:

// SenML: 120 bytes for same 3 readings (50% smaller)
[
  {"bn": "urn:dev:ow:10e2073a01080063:", "bt": 1609459200, "bu": "Cel", "n": "temp", "v": 22.5},
  {"n": "temp", "v": 22.7, "t": 60},
  {"n": "temp", "v": 22.6, "t": 120}
]

1312.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

1312.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,400 bytes	70% smaller
SenML (CBOR)	1,200 bytes	85% smaller

This matters enormously for constrained networks: - LoRaWAN: 51-242 byte payloads - NB-IoT: Charged per byte - Sigfox: 12 byte limit

1312.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

TipMVU: 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.

1312.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.

1312.3.1 The Problem JSON-LD Solves

Without shared vocabulary, different vendors use different terms:

// Vendor A
{"temp": 22.5}

// Vendor B
{"temperature": 22.5}

// Vendor C
{"t": 22.5}

Machines cannot know these all mean the same thing. JSON-LD fixes this:

{
  "@context": {
    "sosa": "http://www.w3.org/ns/sosa/",
    "qudt": "http://qudt.org/schema/qudt/",
    "temperature": {
      "@id": "sosa:hasSimpleResult",
      "@type": "qudt:TemperatureValue"
    }
  },
  "@type": "sosa:Observation",
  "sosa:observedProperty": "qudt:Temperature",
  "temperature": 22.5
}

Now any system understanding SOSA/QUDT ontologies knows exactly what “temperature” means.

1312.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"

1312.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 1312.2: Semantic interoperability with ontology-based data integration

1312.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.

1312.4.1 Thing Description Structure

A Thing Description is a JSON-LD document containing:

{
  "@context": "https://www.w3.org/2022/wot/td/v1.1",
  "id": "urn:dev:wot:com:example:smartlamp:001",
  "title": "Smart Lamp",
  "@type": "Thing",

  "properties": {
    "brightness": {
      "type": "integer",
      "minimum": 0,
      "maximum": 100,
      "forms": [{
        "href": "https://lamp.example.com/brightness",
        "op": ["readproperty", "writeproperty"]
      }]
    }
  },

  "actions": {
    "toggle": {
      "forms": [{
        "href": "https://lamp.example.com/actions/toggle",
        "op": "invokeaction"
      }]
    }
  },

  "events": {
    "overheating": {
      "data": {"type": "number"},
      "forms": [{
        "href": "https://lamp.example.com/events/overheating",
        "subprotocol": "sse"
      }]
    }
  }
}

1312.4.2 WoT Affordances

Affordance	Description	Interaction Pattern
Properties	Readable/writable device state	Poll or observe (GET/PUT)
Actions	Invocable operations	Trigger and wait (POST)
Events	Push notifications	Subscribe and receive

1312.4.3 Properties vs Events

Aspect	Properties	Events
Direction	Client pulls (query on demand)	Device pushes (notification)
Initiation	Client decides when to read	Device decides when to emit
Use Case	Current temperature, brightness	Motion detected, alarm triggered
Protocol	HTTP GET, CoAP GET	WebSocket, MQTT, SSE

1312.4.4 Protocol Bindings

WoT Thing Descriptions are protocol-agnostic. The forms array specifies how to access each affordance:

"forms": [
  {"href": "http://lamp.local/brightness", "op": "readproperty"},
  {"href": "coap://lamp.local/brightness", "op": "readproperty"},
  {"href": "mqtt://broker/lamp/brightness", "op": "observeproperty"}
]

Applications read the TD, discover available protocols, and choose based on their capabilities.

1312.5 Knowledge Check

NoteQuiz: W3C Web of Things

Question: In the W3C Web of Things framework, what is the purpose of a Thing Description (TD)?

💡 Explanation: Thing Description is a JSON-LD document describing what a device can do (its affordances). Contains: 1) Properties (readable/writable state like temperature, brightness). 2) Actions (invocable operations like turnOn, setSchedule). 3) Events (notifications like motionDetected, lowBattery). 4) Protocol bindings (how to access via HTTP, CoAP, MQTT). Key benefit: Protocol-independent discovery—applications read TD, learn capabilities, interact without hardcoding protocol details.

Question: What is the key difference between WoT Properties and WoT Events?

💡 Explanation: Properties represent current state that clients pull/query on demand. Example: GET /properties/temperature returns current reading. Events are push notifications from device when something happens. Device decides when to emit event (motion detected, threshold exceeded). Client subscribes once, receives updates asynchronously.

Question: What is the primary advantage of SenML over plain JSON for IoT sensor data?

💡 Explanation: SenML (RFC 8428) compresses data through base values. Instead of repeating full names/timestamps in every record, set once at top: "bn":"device123/temp/", "bt":1609459200, "bu":"Cel". Each measurement inherits base values. Savings: Plain JSON 100 records × 80 bytes = 8KB. SenML: 200 bytes base + 100 × 20 bytes = 2.2KB (72% smaller!).

Question: Which semantic web technology enables linking IoT data to shared vocabularies and ontologies?

💡 Explanation: JSON-LD (JSON for Linked Data) adds @context to map terms to URIs from shared vocabularies. Example: "@context": {"sosa": "http://www.w3.org/ns/sosa/"} links “temperature” to SOSA ontology definition. This creates semantic interoperability: Different systems understand “temperature” means the same physical quantity. XML Schema validates structure (syntactic) but doesn’t link meaning (semantic).

1312.6 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.

1312.6.1 oneM2M Architecture

┌─────────────────────────────────────────────────────────────┐
│                    Applications (AE)                        │
│         Smart City    Healthcare    Automotive              │
└─────────────────────────────────────────────────────────────┘
                              │
                              ▼
┌─────────────────────────────────────────────────────────────┐
│              Common Services Entity (CSE)                   │
│   Registration │ Discovery │ Data Mgmt │ Subscription       │
│   Security     │ Group Mgmt│ Device Mgmt│ Notification      │
└─────────────────────────────────────────────────────────────┘
                              │
        ┌─────────────────────┼─────────────────────┐
        ▼                     ▼                     ▼
┌───────────────┐     ┌───────────────┐     ┌───────────────┐
│  HTTP Binding │     │  CoAP Binding │     │  MQTT Binding │
└───────────────┘     └───────────────┘     └───────────────┘

1312.6.2 oneM2M Resource Model

Resource Type	Description	Example
CSEBase	Root of resource tree	Infrastructure node
AE	Application Entity	Smart meter app
Container	Data holder	Temperature readings
ContentInstance	Individual data point	{"temp": 22.5}
Subscription	Event notification	Alert on threshold

1312.6.3 Why oneM2M for Cross-Domain Integration

Scenario	Without oneM2M	With oneM2M
3 domains, 3 vendors	9 custom integrations	3 standard APIs
Add new domain	+6 integrations	+1 integration
Protocol change	Modify all integrations	Change binding only

NoteQuiz: oneM2M

Question: What challenge does the oneM2M standard primarily address?

💡 Explanation: oneM2M creates a horizontal platform layer abstracting vertical-specific implementations. Core features: Common service layer with RESTful API, hierarchical resource model (CSE → AE → Container → ContentInstance), protocol bindings (HTTP, CoAP, MQTT, WebSocket), and semantic interoperability. Example: Smart city app interacts with traffic sensors, environmental monitors, parking meters through single oneM2M API despite different manufacturers/protocols.

Question: Which scenario MOST benefits from oneM2M horizontal platform approach?

💡 Explanation: B benefits most. oneM2M designed for cross-domain horizontal integration. Provides: 1) Common service layer (RESTful API) for all vendors, 2) Resource model (CSE→Container) abstracts device differences, 3) Protocol bindings (HTTP/CoAP/MQTT) unify access. Smart city needs cross-vertical integration—exactly oneM2M’s strength.

1312.7 Choosing the Right Standard

Standard	Best For	Level Addressed	Payload Efficiency
SenML	Constrained networks, sensor data	Syntactic	Excellent (70%+ savings)
JSON-LD	Semantic linking, vocabulary mapping	Semantic	Moderate (adds (context?) overhead)
W3C WoT	Device discovery, capability exposure	Syntactic + Semantic	N/A (metadata, not data)
oneM2M	Cross-domain platform, enterprise	All four levels	Varies by binding

1312.7.1 Decision Tree

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

1312.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.

1312.9 What’s Next

Now that you understand interoperability standards:

• Integration Patterns: Learn how to implement Protocol Adapters and Gateways using these standards
• Protocol Details: Deep dive into MQTT and CoAP protocols
• Reference Models: Explore IoT Reference Models that incorporate these standards

1312.10 Resources

1312.10.1 Specifications

• RFC 8428: SenML
• JSON-LD 1.1
• W3C WoT Thing Description
• SOSA/SSN Ontology
• oneM2M Specifications

1312.10.2 Libraries

• RDFLib - Python RDF library
• WoT Scripting API
• Eclipse Leshan - LwM2M implementation