Overview of ISN Protocol

The Isotropic Sensor Network (ISN) Protocols came out as a result of embedded hardware and software development in ISOTEL company together with the Software Tools published on this page.

Initially used for internal low-level development and product quality testing protocol developed into simple basic Protocol Objects which can be combined together to form complex structures, needed per certain device.

The concept of Protocols as Objects offer quick reuse on hardware level, no-programming effort on host side, and use of established and tested pieces of protocol stacks.

The term Isotropic is the motto of the ISOTEL company that stands for development of distributed non-centric systems. From the protocol point of view it states for non-master-slave oriented protocols, state-less, distributed designs, support for protocol auto-discovery, uniqueness and must handle duplicate entries and routing paths, typical for wireless systems. Isotropic also means that a thing in the network is seen and can be accessed equally from any side.

The ISN is at the moment mostly used in wired communications, as on the top of RS-232, RS-485, USB, Bluetooth as well as proprietary applications running over 868 and 915 MHz bands. Further development is in progress to cover high efficiency over LoRa bands. ISN also nicely translates into network standard as JSON and OPC/UA.

Motivation

In the development of Isotropic Protocols, the main motivation was and is to create atomic reusable objects that can be reused at any (nested) level. Consider a typical use case of a simple UART communication, typical for every low cost micro-controller:

  1. UART lacks framing, developer must implement it’s own framing concepts either based on timeouts or preamble characters

  2. Developer needs to implement a parser and generator on the MCU side; which in most cases goes for simple printf() and much reduced scanf().

  3. Developer needs to consider background transmission of the data, which does due to textual approach consume more time than needed, and requires translation of binary data into text and vice versa.

  4. On the host side user must provide a command description and adding the interface into a test framework means development of a simple API or widgets.

  5. Such text API based monitors at the end consume significant resources and complicate development of Wireless systems.

  6. With the next project things change and re-usability is mostly dropped.

Within the ISN above is replaced first by a Frame Layers (80h+, 10h+ and 20h+) with CRC which besides error checking also provides packet resynchronization, and all the other steps are provided by the Message Layer (7Fh) which allows immediate exchange of C structures, just as they are in our code, without translation requirements. The IDM software then provides development GUI and API for web, python, and other software integration.

Protocols as Objects

In programming, a good programmer strives to avoid duplicating the code unless some extreme manual optimizations are required and cannot be handled by the compiler. A clean software code, means clean definition of API, clean objects and also re-usability.

Similar principles have been used in the design of the ISN:

  1. Protocol as a Generic Object that can be reused, nested or embeds other Objects to form more complex protocol structures

  2. Reducing the complexity of a protocol object, striving for primitives to handle many different cases for simple re-use

  3. Complexity is allowed on end-point Presentation Layers

Protocol is thus described as:

PROTOCOL(parameters){ payload }

or as expanded for given combination of parameters where applicable as:

PROTOCOL(parameters){
    param1=X: ..
    param1=Y: ..
}

where:

  • a PROTOCOL() is identified by unique Protocol IDs, to allow arbitrary nesting and mixing of other protocols,

  • its parameters are protocol specific parameters, such as payload length, port number, hand-shaking bits, and similar,

  • payload may represent another Protocol Object or final user payload.

To distinguish Objects from each other the first byte is called a Protocol ID. The ID are such that it is possible to mix text I/O (like terminal commands) and binary efficient ISN protocols.

Protocols

ISOTEL published release includes the following protocol specifications and implementations:

  • Frame Layers (80h+, 10h+ and 20h+): A generic container to carry data over error-nous or error-free media of payload size up to 64 bytes. It provides two variants:

    • with CRC, called also a Compact Frame protocol, with total overhead of 2 bytes, capable of re-synchronization in a non-packet oriented environments (like RS-232, RS-485)

    • without CRC, called also a Short Frame Protocol, with total overhead of 1 byte, to be used for nesting and packet oriented error-free transfer

  • Message Layer (7Fh): Web like presentation layer for interaction with user and other applications, with overhead of 2 bytes only. Features:

    • simple transfer of data structures between the host and target device without the need for number conversions,

    • declaration of user input, or output variables, data-structures, and text elements

    • rich math and metering support with precision and accuracy,

  • Transport Layer (7Eh) and (7Dh): Adds up to 256 logical ports and packet sequencing to serialize data over order non-predictable media, with overhead of 2 or 3 bytes. To address more logical units protocol can be nested.

  • User Streams Layers (01h-0Fh): Application specific tunnel used to transfer custom or proprietary data like fast streaming data, or to embed other protocols.

  • Null - Ping and Padding Layer (00h): A keep-alive ping protocol and padding protocol, used to align or fill empty space in packets.

IDM Pro Version in addition includes:

  • a set of proprietary protocols to support Energy Control Devices

Under development:

  • Hyper Connectivity MAC and Network Layers for use in High Speed Wireless and LoRa

  • Encryption Layer

Example of a Protocol Structure

An example of a structure from the MonoDAQ USB connected device:

MESSAGE(){}
TRANSPORT(Long){
    port=1: FRAME(Short){ USER(0x01) } Null()..
    port=2: FRAME(Short){ USER(0x02) } Null()..
}

which provides:

  • Device with web alike view provided by the Message Layer (7Fh)

  • The Transport Layer (7Eh) and (7Dh) is used to separate analog and digital streams, and provides packet sequencing as packets are transferred over multiple end-points without predictive order

  • Streaming packets provide MonoDAQ specific formats enclosed inside the User Streams Layers (01h-0Fh) where the host may identify the format by identifying the User Protocol ID, either 0x01 or 0x02 in this case. However since the length of user payload is unknown, it is embodied inside the Frame Layers (80h+, 10h+ and 20h+).

  • At the end padding bytes are used by the Null - Ping and Padding Layer (00h) to increase efficiency of the USB transfer (it is Windows specific how it treats and buffers burst transfers).

  • The last two dots mean arbitrary repetition of Null() objects

The structure of the protocol is auto-discovered by the IDM, which shows the protocol structure and it’s properties in the development view. Complete structure of the protocol may also be obtained via web and python api, see gateway.Device.get_protocols()

_images/idm-protoview.png