Frame Layer (80h+)¶

Isotropic Sensor Network Specifications, Frame Layer

OSI: Transport Layer

Keywords: framing, error detection, CRC, PHY, encapsulation, low communication overhead, sensors, internet of things, embedded systems, sensor networks

Isotropic Network Specifications: The Sensor Frame Layer 1.2 by Isotel is licensed under a Creative Commons Attribution-NoDerivatives 4.0 International License.
Permissions beyond the scope of this license may be available at http://isotel.net/ref/ISN-Permissions.

Note: Any adaptations to this specifications made by groups, individuals or companies are according to the license not allowed for general publication, but we strongly encourage you to send your modifications back to us for further consideration for the next releases.

Scope¶

The scope of this project is to define the Isotropic Sensor Network Frame layer for broadcast and peer to peer connection in distributed sensor area network, wired or wireless, low and high data rate devices, battery powered devices, short-range devices with short operational space, low-cost devices to support trivial sensors, besides the fully featured devices.

Purpose¶

The purpose of this specifications is to provide a standard for low complexity, low cost, and low power (aware) consumption devices (sensors) to encapsulate higher level protocols.

Typical use:

Low-level transmissions, to define basic packet length with CRC
Payloads inside nested layers without CRC

Key features¶

Basic Frame Layer for Short Payloads
Error Detection using with CRC
For use in PHY Transmission as well as Encapsulation of Other Layers
Low-Cost and Compact Implementation

Definitions, Acronyms and Abbreviations¶

CRC: Cyclic Redundancy Check
device: An entity containing this protocol implementation. Also referred as sensor device or just sensor or device.
frame: The format of aggregated bits that are transmitted together in time.
packet: The format of aggregated bits that are transmitted together in time across the physical medium.
LSB: least significant byte/bit
MSB: most significant byte/bit

Packet Formats¶

Frame layer defines two packet formats:

Short Frame Format, with a single preamble (protocol identification byte) and up to 64 B of user payload data for transmission in error-free channels,
Compact Frame Format, which adds a 8-bit CRC for transmission in error-nous channels

Short Frame Format¶

Fields	Protocol ID	Length	Payload
Bits	2	6	length x 8
Value	0b11	0..63	data

Protocol ID:: defines the unique protocol identification number
Length:: the last 6 L-bits of first byte represent payload length. Value from 0..63 defines 1..64 payload bytes.
Payload:: embedded data

Compact Frame Format¶

Fields	Protocol ID	Length	Payload	CRC
Bits	2	6	length x 8	8
Value	0b10	0..63	data	8-bit CRC

Protocol ID:

defines the unique protocol identification number

Length:

the last 6 L-bits of first byte represent payload length. Value from 0..63 defines 1..64 payload bytes.

Payload:

embedded data

CRC:

protected by the 8-bit CRC polynomial 0x4D as per Philip Koopman found the best for packets up to 64 bytes. Code Example:

/**
 * Calculates 8-bit CRC using module-2 Division on a bit (slow) basis
 *
 * Usage:
 *   uint8_t crc = isn_frame_crc8( first_byte );
 *   crc = isn_frame_crc8( second_byte ^ crc );
 *   crc = isn_frame_crc8( third_byte ^ crc );
 *   ...
 *   crc = isn_frame_crc8( final_byte ^ crc ); // result is the final CRC
 *
 * \arg remainder to be chained and final value represents the crc.
 */
static uint8_t isn_frame_crc8(uint8_t remainder)
{
    uint8_t bit;
    for (bit = 8; bit > 0; --bit) {
        if (remainder & 0x80) {
            remainder = (remainder << 1) ^ 0x4D;
        } else {
            remainder = (remainder << 1);
        }
    }
    return remainder;
}

Document Changes¶

Date	Release	Changes
January 29, 2012	0.1	Draft Specifications, Evaluation
February 14, 2016	1.0	Public version of Renewed Sensor Frame Layer
February 25, 2017	1.1	Removed 0x00 as termination, added CRC8 code example
September 15, 2018	1.2	Added Short Frame, Long Frame is to be revised

References¶

Philip Koopman, Tridib Chakravarty, “Cyclic Redundancy Code (CRC) Polynomial Selection For Embedded Networks”, Preprint: The International Conference on Dependable Systems and Networks, DSN-2004.

Disclaimer¶

Use of an ISOTEL specification is wholly voluntary. The ISOTEL disclaims liability for any personal injury, property or other damage, of any nature whatsoever, whether special, indirect, consequential, or compensatory, directly or indirectly resulting from the publication, use of, or reliance upon this, or any other ISOTEL specification document.

The ISOTEL does not warrant or represent the accuracy or content of the material contained herein, and expressly disclaims any express or implied warranty, including any implied warranty of merchantability or fitness for a specific purpose, or that the use of the material contained herein is free from patent infringement. ISOTEL specifications documents are supplied AS IS.

The existence of an ISOTEL specification does not imply that there are no other ways to produce, test, measure, purchase, market, or provide other goods and services related to the scope of the ISOTEL specification. Furthermore, the viewpoint expressed at the time a specification is approved and issued is subject to change brought about through developments in the state of the art and comments received from users of the specification. Every ISOTEL specification is subjected to review at least every five years for revision or reaffirmation. When a document is more than five years old and has not been reaffirmed, it is reasonable to conclude that its contents, although still of some value, do not wholly reflect the present state of the art. Users are cautioned to check to determine that they have the latest edition of any ISOTEL specification.

In publishing and making this document available, the ISOTEL is not suggesting or rendering professional or other services for, or on behalf of, any person or entity. Nor is the ISOTEL undertaking to perform any duty owed by any other person or entity to another. Any person utilizing this, and any other ISOTEL specifications document, should rely upon the advice of a competent professional in determining the exercise of reasonable care in any given circumstances.

Interpretations: Occasionally questions may arise regarding the meaning of portions of specifications as they relate to specific applications. When the need for interpretations is brought to the attention of ISOTEL, the ISOTEL will initiate action to prepare appropriate responses. Since ISOTEL specifications represent a consensus of concerned interests, it is important to ensure that any interpretation has also received the concurrence of a balance of interests. For this reason, ISOTEL and the members of its societies are not able to provide an instant response to interpretation requests except in those cases where the matter has previously received formal consideration.

Comments for revision of ISOTEL specifications are welcome from any interested party, regardless of membership affiliation with ISOTEL. Suggestions for changes in documents should be in the form of a proposed change of text, together with appropriate supporting comments. Comments on specifications and requests for interpretations should be addressed to Isotel d.o.o., Slovenia.

Attention is called to the possibility that implementation of this specification may require use of subject matter covered by patent rights. By publication of this specification, no position is taken with respect to the existence or validity of any patent rights in connection therewith. The ISOTEL shall not be responsible for identifying patents for which a license may be required by an ISOTEL specification or for conducting inquiries into the legal validity or scope of those patents that are brought to its attention.