Introduction to the Internet-of-things - 2

Presenter Maxime Lefrançois
maxime.lefrancois@emse.fr
version 1.2, 29-05-2019

Contents

  • Generalities on the Internet of Things
  • Web and web principles
  • From the Internet of Things to the Web of Things
  • Interaction protocols for the Web of Things
  • Architectural styles for the Web of Things
  • Document formats for the Web of Things
  • Some ontologies for the Web of Things / Using RDF as a lingua franca

Web vs Internet

  • Internet = network

    • when, who?

  • Web = information space

    • when, who?

tbl

  • Internet = network

    • TCP/IP, 1973 Vinton Cerf, Robert Elliot Kahn, Louis Pouzin

  • Web = information space

    • HTTP, 1989, Sir Tim Berners Lee

tbl

Architecture of the World Wide Web

Reference: https://www.w3.org/TR/webarch/

Separation of:

  1. Content
  2. Interaction
  3. Presentation

Content

The World Wide Web (WWW, or simply Web) is an information space in which the items of interest, referred to as resources, are identified by global identifiers called Uniform Resource Identifiers (URI).

Architecture of the World Wide Web, volume 1

URIs

URL: Universal Resource Locator (RFC 1738)

url

URNs

URN: Universal Resource Name

  • urn:isbn:0-395-36341-1 (RFC 3187)
  • urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6 (RFC 4122)
  • urn:ietf:rfc:2141 (RFC 2648)

See list https://www.iana.org/assignments/urn-namespaces/urn-namespaces.xhtml

URIs

URI: Universal Resource Identifier

URI = URL ∪ URN

IRIs?

  • URI (RFC 3986, 2005) - IRI (RFC 3987, 2004)

    • RDF 1.0 uses term 'URI' (2004)
    • RDF 1.1 uses term 'IRI' (2014)

?

  • URI (RFC 3986, 2005) - IRI (RFC 3987, 2004)

    • RDF 1.0 uses term 'URI' (2004)
    • RDF 1.1 uses term 'IRI' (2014)

IRI: Internationalized Resource Identifiers

Content: Resources, identification, content

In order to communicate internally, a community agrees (to a reasonable extent) on a set of terms and their meanings. […​] the Web makes use of a single global identification system: the [IRI]. [IRIs] are a cornerstone of Web architecture, providing identification that is common across the Web. […​]

https://www.w3.org/TR/webarch/#identification

Content: Resources, identification, content

Some definitions:

  • Resources: Anything that might be identified by a IRI
  • Information resources: All of its essential characteristics can be conveyed in a message
  • Content: 'All of the essential characteristics' of an information resource
  • Fragment identifier: The part of a URI that allows identification of a secondary resource.
  • Primary vs. Secondary resource: Identified by IRIs without vs. with a hash, resp. (IRI fragment not sent to the server)

Interaction, interaction protocol

Communication between agents over a network about resources involves [IRIs], messages, and data. The Web’s protocols (including HTTP, FTP, SOAP, NNTP, and SMTP) are based on the exchange of messages.

https://www.w3.org/TR/webarch/#interaction

A message may include data as well as metadata about a resource, the message data, and the message itself. A message may even include metadata about the message metadata

Interaction, interaction protocol

Some definitions:

  • Dereference a URI: Action aiming at accessing the identified resource

    • the scheme part of a URL corresponds to the Interaction protocol
    • most URN do not define an interaction protocol (cannot interact with urn:isbn:0-395-36341-1)

See https://www.iana.org/assignments/uri-schemes

  • the semantics of accessing is defined by the interaction protocol

    • example HTTP POST: create a resource,
    • example HTTP DELETE: delete the resource.

Presentation: representation, negociation

  • A representation is data that encodes information about resource state.

  • Representations should be octet streams typed by internet media types

    • Other typing possible (e.g., language)

Mediatypes

text/plain, application/xml, application/pdf, video/3gpp, …​

See https://www.iana.org/assignments/media-types/

Media-type vs Content-type?

  • Media-types define parameters
  • Content-type is a media-type + values for the parameters

Contents

  • Generalities on the Internet of Things
  • Web and web principles
  • From the Internet of Things to the Web of Things
  • Interaction protocols for the Web of Things
  • Architectural styles for the Web of Things
  • Document formats for the Web of Things
  • Some ontologies for the Web of Things / Using RDF as a lingua franca

From the Internet of Things to the Web of Things

What is the difference between the Internet of Things
and the Web of Things ?
What is the difference between the Internet of Things
and the Web of Things ?
Internet of Things = network
Web of Things = information space built with the Web architecture principles on top of the Internet of Things

Overview of interaction protocols for the Internet of Things

Request/Reponses vs Publish/Subscribe interaction paradigms

IoT Protocol: CoAP

The HTTP for constrained devices: "binarification and UDP-ization of HTTP" …​

Constrained Application Protocol (CoAP, RFC 7252, June 2014)

coap

The HTTP for constrained devices: "binarification of HTTP" …​

Constrained Application Protocol (CoAP, RFC 7252)

. 0                   1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |Ver| T |  TKL  |      Code     |          Message ID           |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |   Token (if any, TKL bytes) ...
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |   Options (if any) ...
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |1 1 1 1 1 1 1 1|    Payload (if any) ...
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  • Ver = version (1 for the current spec)
  • Code = request codes GET, PUT, POST, DELETE, …​
  • …​ 200 OK, 404 NOT FOUND, 500 INTERNAL SERVER ERROR, (25 bytes in HTTP for the latest) …​
  • …​ on 1 byte only

The HTTP for constrained devices: "binarification of HTTP" …​

Code = Binary code for verbs and response codes: 3 bits '.' 5 bits

0.X = request

Initial entries in the CoAP Method Codes sub-registry are as follows:

         +------+--------+-----------+
         | Code | Name   | Reference |
         +------+--------+-----------+
         | 0.01 | GET    | [RFC7252] |
         | 0.02 | POST   | [RFC7252] |
         | 0.03 | PUT    | [RFC7252] |
         | 0.04 | DELETE | [RFC7252] |
         +------+--------+-----------+

See https://www.iana.org/assignments/core-parameters/ for the current list of entries

The HTTP for constrained devices: "binarification of HTTP" …​

Code = Binary code for verbs and response codes: 3 bits '.' 5 bits

1.X - 5.X = response codes similar to HTTP

Initial entries in the CoAP Response Codes sub-registry are as follows:

    +------+------------------------------+-----------+
    | Code | Description                  | Reference |
    +------+------------------------------+-----------+
    | 2.01 | Created                      | [RFC7252] |
    | 2.02 | Deleted                      | [RFC7252] |
    | 2.03 | Valid                        | [RFC7252] |
    | 2.04 | Changed                      | [RFC7252] |
    | 2.05 | Content                      | [RFC7252] |
    | 4.00 | Bad Request                  | [RFC7252] |
    | 4.01 | Unauthorized                 | [RFC7252] |
    | 4.02 | Bad Option                   | [RFC7252] |
    | 4.03 | Forbidden                    | [RFC7252] |
    | 4.04 | Not Found                    | [RFC7252] |
    | 4.05 | Method Not Allowed           | [RFC7252] |
    | 4.06 | Not Acceptable               | [RFC7252] |
    | 4.12 | Precondition Failed          | [RFC7252] |
    | 4.13 | Request Entity Too Large     | [RFC7252] |
    | 4.15 | Unsupported Content-Format   | [RFC7252] |
    | 5.00 | Internal Server Error        | [RFC7252] |
    | 5.01 | Not Implemented              | [RFC7252] |
    | 5.02 | Bad Gateway                  | [RFC7252] |
    | 5.03 | Service Unavailable          | [RFC7252] |
    | 5.04 | Gateway Timeout              | [RFC7252] |
    | 5.05 | Proxying Not Supported       | [RFC7252] |
    +------+------------------------------+-----------+

See https://www.iana.org/assignments/core-parameters/ for the current list of entries

The HTTP for constrained devices: "UDP-ization" of HTTP …​

Constrained Application Protocol (CoAP, RFC 7252)

  • T = CON (0), NON (1), ACK (2), RES (3)
  • Message ID = Used to detect message duplication (UDP!)
  • Token = 'Request ID' (Concurrent requests)
  • TKL = number of bytes of the Token
. 0                   1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |Ver| T |  TKL  |      Code     |          Message ID           |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |   Token (if any, TKL bytes) ...
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |   Options (if any) ...
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |1 1 1 1 1 1 1 1|    Payload (if any) ...
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The HTTP for constrained devices: "UDP-ization" of HTTP …​

Constrained Application Protocol (CoAP, RFC 7252)

  • T = CON (0), NON (1), ACK (2), RES (3)
  • Message ID = Used to detect message duplication (UDP!)
  • Token = 'Request ID' (Concurrent requests)
  • TKL = number of bytes of the Token

Reliable vs Unreliable messages transmission

CON Confirmable, NON Non-confirmable, ACK acknowledgement

.  Client              Server           Client              Server
      |                  |                |                  |
      |   CON [0x7d34]   |                |   NON [0x01a0]   |   <- [Message ID]
      +----------------->|                +----------------->|
      |                  |                |                  |
      |   ACK [0x7d34]   |
      |<-----------------+
      |                  |

The HTTP for constrained devices: "UDP-ization" of HTTP …​

Constrained Application Protocol (CoAP, RFC 7252)

  • T = CON (0), NON (1), ACK (2), RES (3)
  • Message ID = Used to detect message duplication (UDP!)
  • Token = 'Request ID' (Concurrent requests)
  • TKL = number of bytes of the Token
.       Client              Server       Client              Server
           |                  |             |                  |
           |   CON [0xbc90]   |             |   CON [0xbc91]   |   <- [Message ID]
           | GET /temperature |             | GET /temperature |
           |   (Token 0x71)   |             |   (Token 0x72)   |   <- (Token)
           +----------------->|             +----------------->|
           |                  |             |                  |
           |   ACK [0xbc90]   |             |   ACK [0xbc91]   |
           |   2.05 Content   |             |  4.04 Not Found  |
           |   (Token 0x71)   |             |   (Token 0x72)   |
           |     "22.5 C"     |             |   "Not found"    |
           |<-----------------+             |<-----------------+
           |                  |             |                  |

The HTTP for constrained devices: "UDP-ization" of HTTP …​

Constrained Application Protocol (CoAP, RFC 7252)

  • T = CON (0), NON (1), ACK (2), RES (3)
  • Message ID = Used to detect message duplication (UDP!)
  • Token = 'Request ID' (Concurrent requests)
  • TKL = number of bytes of the Token

Reliable vs Unreliable messages transmission

.      Client              Server
         |                  |
         |   CON [0x7a10]   |   <- [Message ID]
         | GET /temperature |
         |   (Token 0x73)   |   <- (Token)
         +----------------->|
         |                  |
         |   ACK [0x7a10]   |   <- [same Message ID]
         |<-----------------+
         |                  |
         ... Time Passes  ...
         |                  |
         |   CON [0x23bb]   |   <- [different Message ID]
         |   2.05 Content   |
         |   (Token 0x73)   |   <- (same Token)
         |     "22.5 C"     |
         |<-----------------+
         |                  |
         |   ACK [0x23bb]   |
         +----------------->|
         |                  |

The HTTP for constrained devices: "binarification of HTTP" …​

Options: critical (2n+1) vs elective (2n) + more subtelties …​

Initial entries in the CoAP Option Numbers sub-registry are as follows:

     +--------+------------------+-----------+
     | Number | Name             | Reference |
     +--------+------------------+-----------+
     |      0 | (Reserved)       | [RFC7252] |
     |      1 | If-Match         | [RFC7252] |
     |      3 | Uri-Host         | [RFC7252] |
     |      4 | ETag             | [RFC7252] |
     |      5 | If-None-Match    | [RFC7252] |
     |      7 | Uri-Port         | [RFC7252] |
     |      8 | Location-Path    | [RFC7252] |
     |     11 | Uri-Path         | [RFC7252] |
     |     12 | Content-Format   | [RFC7252] |
     |     14 | Max-Age          | [RFC7252] |
     |     15 | Uri-Query        | [RFC7252] |
     |     17 | Accept           | [RFC7252] |
     |     20 | Location-Query   | [RFC7252] |
     |     35 | Proxy-Uri        | [RFC7252] |
     |     39 | Proxy-Scheme     | [RFC7252] |
     |     60 | Size1            | [RFC7252] |
     |    128 | (Reserved)       | [RFC7252] |
     |    132 | (Reserved)       | [RFC7252] |
     |    136 | (Reserved)       | [RFC7252] |
     |    140 | (Reserved)       | [RFC7252] |
     +--------+------------------+-----------+

See https://www.iana.org/assignments/core-parameters/

The HTTP for constrained devices: "binarification of HTTP" …​

Content-Format: also binary

Initial entries in this sub-registry are as follows:

   +--------------------------+----------+----+------------------------+
   | Media type               | Encoding | ID | Reference              |
   +--------------------------+----------+----+------------------------+
   | text/plain;              | -        |  0 | [RFC2046] [RFC3676]    |
   | charset=utf-8            |          |    | [RFC5147]              |
   | application/link-format  | -        | 40 | [RFC6690]              |
   | application/xml          | -        | 41 | [RFC3023]              |
   | application/octet-stream | -        | 42 | [RFC2045] [RFC2046]    |
   | application/exi          | -        | 47 | [REC-exi-20140211]     |
   | application/json         | -        | 50 | [RFC7159]              |
   +--------------------------+----------+----+------------------------+

See https://www.iana.org/assignments/core-parameters/

The HTTP for constrained devices: "binarification of HTTP" …​

We will come back to some of them …​

Overview of interaction protocols for the Internet of Things

Request/Reponses vs Publish/Subscribe interaction paradigms

IoT Protocol: MQTT

Message Queue Telemetry Transport Protocol (MQTT, Oasis Standard)

  • Clients connect to a Server, which acts as a broker and distributes Messages
  • Clients can publish a Message with a Topic Name with a Quality of Service QoS
  • Clients can subscribe to some Topic Filter and receive the associated messages

Over TCP/IP

mqtt overview

Message Queue Telemetry Transport Protocol (MQTT, Oasis Standard)

Control Packet type (4 bits)

Examples:

  • CONNECT, CONNACK, DISCONNECT,
  • SUBSCRIBE, SUBACK, UNSUBSCRIBE, UNSUBACK
  • PUBLISH, PUBACK, PUBREC, PUBREL, PUBCOMP

Message Queue Telemetry Transport Protocol (MQTT, Oasis Standard)

Clients publish at Topic Names

  • UTF-8 encoded list of tokens separated by '/' (possibly empty or containing ' ')

    • example: room/15/temperature/17 (four topic levels)
    • example: /robot (two topic levels)

Message Queue Telemetry Transport Protocol (MQTT, Oasis Standard)

Clients subscribe to Topic Filters

  • Topic Names with wildcards

    • Multi level wildcard room/15/#
    • Single level wildcard room/+/temperature/+

room/+/temperature/17 is valid, room/1+/temperature/17 is not valid

Message Queue Telemetry Transport Protocol (MQTT, Oasis Standard)

Quality of Service (QoS):

  • QoS 0: At most once delivery

    • sender sends PUBLISH message, and that’s it.

  • QoS 1: At least once delivery

    • sender sends PUBLISH message,
    • receiver responds with PUBACK

Message Queue Telemetry Transport Protocol (MQTT, Oasis Standard)

Quality of Service (QoS):

  • QoS 2: Exactly once delivery

    • sender sends PUBLISH message,
    • receiver responds with PUBREC (received)
    • sender sends PUBREL (released)
    • receiver reponds with PUBCOMP (completed)

Message Queue Telemetry Transport Protocol (MQTT, Oasis Standard)

Since v5.0 (07 March 2019), PUBLISH messages have an option Content Type.

Is this sufficient for MQTT to be consider
a Web of Things interaction protocol?

Response: NO. Resources are not identified by URIs

Contents

  • Generalities on the Internet of Things
  • Web and web principles
  • From the Internet of Things to the Web of Things
  • Interaction protocols for the Web of Things
  • Architectural styles for the Web of Things
  • Document formats for the Web of Things
  • Some ontologies for the Web of Things / Using RDF as a lingua franca

Web architectural styles for the Web of Things

webapis

Web architectural styles for the Web of Things

REST: Representational State Transfer

Loosely coupled services that can be easily reused and use

  • URIs to identify resources
  • Standardized media typed formats to represent (and retrieve and manipulate) resource state
  • Interaction protocols HTTP or CoAP a standard set of methods

Application programming interface (API) to interact with Things

See: https://datatracker.ietf.org/doc/draft-irtf-t2trg-rest-iot/

REST: Representational State Transfer

Loosely coupled services that can be easily reused and use

  • URIs to identify resources such as:

    • <coap://192.168.0.5/sensor>
    • <coap://192.168.0.5/sensor/14>
    • <coap://192.168.0.5/sensor/14/temperature>

REST: Representational State Transfer

  • Interaction protocols HTTP or CoAP a standard set of methods

Create Read Update Delete (CRUD) operations

  • 0.01 GET /sensor/14/temperature : Read temperature value of sensor 14

    • typical response 2.05 (Content)

  • 0.02 POST /sensor : Create new temperature sensor

    • typical response 2.01 (Created)

  • 0.03 PUT /heater/14 : Update the status of heater 14

    • typical response 2.04 (Changed)

  • 0.04 DELETE /sensor/14 : Delete resource sensor 14

    • typical response 2.02 (Deleted)

REST: Representational State Transfer

  • Interaction protocols HTTP or CoAP a standard set of methods

Create Read Update Delete (CRUD) operations

  • 0.01 GET: safe and idempotent
  • 0.02 POST: neither safe nor idempotent
  • 0.03 PUT: not safe but idempotent
  • 0.04 DELETE not safe but idempotent

Web architectural styles for the Web of Things

HATEOAS: Hypermedia As The Engine Of Application State

  • REST constraints
  • + hypermedia controls in the header or the representation:

A way for machines to understand APIs and navigate them without having any information about them beforehand

Hypermedia links and forms to tell the client "what he can do next"

  • "the canonical URI of this representation is x"
  • "link to the next 10 values is x"
  • "to create a new value, do POST at y"
  • "to turn on the light, do POST at y"

HATEOAS: Hypermedia As The Engine Of Application State

  • REST constraints
  • + hypermedia controls in the header or the representation:

Improves key non-functional API requirements:

  • simplicity: interfaces are easier to understand
  • visibility: messages are self-descriptive
  • portability: known representation formats
  • modifiability: uniform interfaces allow clients and servers to evolve independently

HATEOAS: Hypermedia As The Engine Of Application State

Example with links in the retrieved messages

  1. from the GitHub API v3 entrypoint https://api.github.com/

  2. replace https://api.github.com/repos/{owner}/{repo}

  3. go to contributors https://api.github.com/repos/gradle/gradle/contributors

HATEOAS: Hypermedia As The Engine Of Application State

Example with Links in the HTTP header

  1. …​
  2. …​
  3. go to contributors https://api.github.com/repos/gradle/gradle/contributors
  4. see HTTP Response Link header for next and last pages (inspecting the HTTP call with your browser) 
Link: <https://api.github.com/repositories/302322/contributors?page=2>; rel="next",
 <https://api.github.com/repositories/302322/contributors?page=13>; rel="last"

RFC 8288 Web Linking

Link: <targetURL>; rel="typeOfRelation"; someAttribute="someValue someOtherValue" ,

      <otherTarget>; rel="relation"; someAttribute="someValue http://someURL/value" ,

      <otherTarget>; rel="relation"; someAttribute="someValue" ; anchor=<URLOfStartOfRelation>

See https://www.iana.org/assignments/link-relations/

RFC 8288 Web Linking

Open Question: What would be a RDF representation?

Response:. See td:Link in W3C Thing Description https://w3c.github.io/wot-thing-description/

Contents

  • Generalities on the Internet of Things
  • Web and web principles
  • From the Internet of Things to the Web of Things
  • Interaction protocols for the Web of Things
  • Architectural styles for the Web of Things
  • Document formats for the Web of Things
  • Some ontologies for the Web of Things / Using RDF as a lingua franca

Document formats for the Web of Things: CoRE Link Format

Enabling hypermedia control with the CoRE link format (RFC 6690, August 2012)

Simply HTTP header parameter Link: …​ in a document

  • media type application/link-format, extension .wlnk
  • default 'rel' value is "hosts"

  • defines three new Link Target Attribute:

    • "rt": Resource Type, ex. "outdoor-temperature", "rel-humidity", "https://w3id.org/seas/TemperatureProperty"
    • "if": Interface Description, ex. "outdoor-temperature", "rel-humidity", "http://ex.org/myapp#sensor"
    • "sw": Maximum Size Estimate

</sensors/temp>;rt="temperature-c";if="sensor",
</sensors/light>;rt="light-lux";if="sensor"

Enabling hypermedia control with the CoRE link format (RFC 6690, August 2012)

Simply HTTP header parameter Link: …​ in a document

  • also a new "/.well-known/core" well-known interface where one may discover resources hosted by the server.
REQ: GET /.well-known/core

RES: 2.05 Content
</sensors>;ct=40

REQ: GET /sensors

RES: 2.05 Content
</sensors/temp>;rt="temperature-c";if="sensor",
</sensors/light>;rt="light-lux";if="sensor"

Document formats for the Web of Things: CoRAL

The Constrained RESTful Application Language

Under development, latest version March 2019

  • Link describe relations between resources on the Web
  • Forms describe possible operations on these resources…​

https://tools.ietf.org/html/draft-hartke-t2trg-coral-08

Document formats for the Web of Things: JSON > CBOR

Concise Binary Object Representation (CBOR, RFC 7049, Oct 2013)

Very good Wikipedia page https://en.wikipedia.org/wiki/CBOR

The goal is not to reduce the files, but to reduce the implementations.

  • Many text: small compression

    • Mostly because there is no "dictionnary" for strings

  • Many numbers: good compression
  • Many libraries to use CBOR.

Concise Binary Object Representation (CBOR, RFC 7049, Oct 2013)

Main Idea: data item start with one byte X.YY

X = 3 bits Major Type

  • Major type 0.YY: an unsigned integer
  • Major type 1.YY: a negative integer

Y = 5 bits Additional Information

  • X.00-X.23 = the value
  • X.24 = the value is encoded on 1 byte
  • X.25 = the value is encoded on 2 bytes
  • X.26 = the value is encoded on 4 bytes
  • X.27 = the value is encoded on 8 bytes
  • X.31 = indefinite value length, ends with the "break" stop code 7.31

Concise Binary Object Representation (CBOR, RFC 7049, Oct 2013)

Main Idea: data item start with one byte X.YY

X = 3 bits Major Type

  • Major type 2.YY: a byte string
  • Major type 3.YY: a text string (UTF-8)

Y = 5 bits Additional Information

  • X.00-X.23 = the length (number of bytes)
  • X.24 = the length (number of bytes) is encoded on 1 byte
  • X.25 = the length (number of bytes) is encoded on 2 bytes
  • X.26 = the length (number of bytes) is encoded on 4 bytes
  • X.27 = the length (number of bytes) is encoded on 8 bytes
  • X.31 = indefinite length, ends with the "break" stop code 7.31

Concise Binary Object Representation (CBOR, RFC 7049, Oct 2013)

Main Idea: data item start with one byte X.YY

X = 3 bits Major Type

  • Major type 4.YY: an array of data items
  • Major type 5.YY: a map of pairs of data items

Y = 5 bits Additional Information

  • X.00-X.23 = the number of items/pairs
  • X.24 = the number of items/pairs is encoded on 1 byte
  • X.25 = the number of items/pairs is encoded on 2 bytes
  • X.26 = the number of items/pairs is encoded on 4 bytes
  • X.27 = the number of items/pairs is encoded on 8 bytes
  • X.31 = indefinite length, ends with the "break" stop code 7.31

  • Major type 6.YY: optional semantic tagging of other major types

    • bignum, bigfloat, uris, base64urls, base64

  • Major type 7.YY: floating-point numbers and simple data types that need no content, as well as the "break" stop code

    • 7.00 - 7.23 = simple value 0..23
    • 7.24.000 - 7.23.019 = not used
    • 7.24.021 - 7.24.022 = False, True, Null
    • 7.24.023 - 7.24.031 = not used
    • 7.24.032 - 7.23.255 = Simple value (value 32..255 in following byte)
    • 7.25 = IEEE 754 Half-Precision Float (next 2 bytes)
    • 7.26 = IEEE 754 Single-Precision Float (next 4 bytes)
    • 7.27 = IEEE 754 Single-Precision Float (next 8 bytes)
    • 7.31 = "break" stop code

Document formats for the Web of Things: XML > EXI

Efficient XML Interchange (EXI, W3C REC, Feb 2014)

https://www.w3.org/TR/exi-primer/ Main Idea:

  • EXI stream = EXI header (options) + EXI body (sequence of EXI events)

    • grammar encodes the most likely next tag/attribute names in fewer bits

  • each XML Datatype defines specific encoding rules

    • usually length (unsigned integer) + content

  • Datatype of the item defined by the grammar, or unspecified

Efficient XML Interchange (EXI, W3C REC, Feb 2014)

<?xml version="1.0" encoding="UTF-8"?>
<notebook date="2007-09-12">
 <note category="EXI" date="2007-07-23">
  <subject>EXI</subject>
  <body>Do not forget it!</body>
 </note>
 <note date="2007-09-12">
  <subject>Shopping List</subject>
  <body>milk, honey</body>
 </note>
</notebook>
exi body stream

Efficient XML Interchange (EXI, W3C REC, Feb 2014)

Built In Grammar Note

Efficient XML Interchange (EXI, W3C REC, Feb 2014)

exi events

Comparison EXI vs CBOR ?

Not the same design choices

  • CBOR = less compression, simpler encoder/decoder
  • EXI = more compression, complex encoder/decoder, better to use schema-specific grammar
exi cbor comparison

Example: https://calhoun.nps.edu/bitstream/handle/10945/45196/15Mar_Hill_Bruce.pdf

Document formats for the Web of Things: SenML

Sensor Measurement Lists (SenML) (SenML, STF8428, Aug 2018)

  • To represent simple sensor measurements and device parameters
[
 {"n":"urn:dev:ow:10e2073a01080063","u":"Cel","t":1.276020076e+09,
  "v":23.5},
 {"n":"urn:dev:ow:10e2073a01080063","u":"Cel","t":1.276020091e+09,
  "v":23.6}
]

Sensor Measurement Lists (SenML) (SenML, STF8428, Aug 2018)

  • Regular Fields
.      +---------------+-------+-----------+
       |          Name | Label | JSON Type |
       +---------------+-------+-----------+
       |          Name | n     | String    |
       |          Unit | u     | String    |
       |         Value | v     | Number    |
       |  String Value | vs    | String    |
       | Boolean Value | vb    | Boolean   |
       |    Data Value | vd    | String    |
       |           Sum | s     | Number    |
       |          Time | t     | Number    |
       |   Update Time | ut    | Number    |

Sensor Measurement Lists (SenML) (SenML, STF8428, Aug 2018)

  • Regular Fields and and Base Fields
.      +---------------+-------+-----------+
       |          Name | Label | JSON Type |
       +---------------+-------+-----------+
       |     Base Name | bn    | String    |
       |     Base Time | bt    | Number    |
       |     Base Unit | bu    | String    |
       |    Base Value | bv    | Number    |
       |      Base Sum | bs    | Number    |

(this is a IANA registry)

https://www.iana.org/assignments/senml/

Sensor Measurement Lists (SenML) (SenML, STF8428, Aug 2018)

  • Regular Fields and and Base Fields
  • Units

IANA Registry for SenML Units

https://www.iana.org/assignments/senml/

Sensor Measurement Lists (SenML) (SenML, STF8428, Aug 2018)

  • Regular Fields and and Base Fields
  • Units
  • representations in JSON, CBOR, XML, EXI.

Contents

  • Generalities on the Internet of Things
  • Web and web principles
  • From the Internet of Things to the Web of Things
  • Interaction protocols for the Web of Things
  • Architectural styles for the Web of Things
  • Document formats for the Web of Things
  • Some ontologies for the Web of Things / Using RDF as a lingua franca Dedicated presentation
← →

/