dash7 alliance mode draft 02 release

Copyright 2013 DASH7 Alliance Confidential

DASH7 Alliance Protocol Specification

DRAFT 0.2 Release

An Advanced Communication System for Wide-Area Low

Power Wireless Applications and Active RFID

1.Overview.........................................................................................................................................7

2.Device Classes...............................................................................................................................8

2.1.Blinker Device Class..............................................................................................................8

2.2.Endpoint Class........................................................................................................................8

2.3.Subcontroller Class................................................................................................................8

2.4.Gateway Class.........................................................................................................................8

3.Physical Layer................................................................................................................................9

3.1.Spectrum Utilization and Channels......................................................................................9

3.1.1.Channel Center Frequencies............................................................................................9

3.1.2.Channel Bandwidths..........................................................................................................9

3.1.3.Spectrum IDs...................................................................................................................10

3.1.4.Channel IDs.....................................................................................................................10

3.2.Channel Classes...................................................................................................................10

3.2.1.FSK-1.8 Modulation.........................................................................................................11

3.2.2.FSK-0.5 Modulation.........................................................................................................12

3.2.3.Base Channel Class........................................................................................................12

3.2.4.Normal Channel Class....................................................................................................12

3.2.5.Hi-Rate Channel Class....................................................................................................12

3.2.6.Blink Channel Class........................................................................................................12

3.3.CCA Process.........................................................................................................................12

3.4.Symbol Encoding.................................................................................................................13

3.4.1.Endiannes........................................................................................................................13

3.4.2.PN9 Encoding Method (Mandatory)................................................................................13

3.4.3.FEC Encoding Method (Optional)...................................................................................14

3.5.Packet Structure...................................................................................................................15

3.5.1.Sync Word Classes.........................................................................................................15

4.Data Link Layer............................................................................................................................16

4.1.Hosts......................................................................................................................................16

4.1.1.Host Input........................................................................................................................16

4.1.2.Host Output.....................................................................................................................16

4.1.3.Host I/O............................................................................................................................16

1 / 87


4.2.Units, Parameters, and Data Elements...............................................................................16

4.2.1.Timing Units.....................................................................................................................16

4.2.2.Glossary of Input Parameters..........................................................................................17

4.2.3.Glossary of Input Data Elements.....................................................................................17

4.3.Data Link Filtering................................................................................................................18

4.3.1.CRC16 Validation............................................................................................................18

4.3.2.Subnet Matching..............................................................................................................18

4.3.3.Link Quality Assessment.................................................................................................18

4.4.Data Link Layer Addressing................................................................................................19

4.4.1.Device ID Structure.........................................................................................................19

4.4.2.UID (Unique ID)...............................................................................................................19

4.4.3.VID (Virtual ID)................................................................................................................20

4.4.4.Data Link Broadcasting...................................................................................................20

4.4.5.Data Link Unicasting........................................................................................................20

4.5.Top Level Frame Structure..................................................................................................20

4.5.1.Background Frames........................................................................................................20

4.5.2.Foreground Frames.........................................................................................................21

4.6.Data Link Dialog Models......................................................................................................21

4.6.1.Background Dialog..........................................................................................................21

4.6.2.Foreground Dialog...........................................................................................................21

4.7.MAC Scan Processes...........................................................................................................22

4.7.1.Scan Scheduler...............................................................................................................22

4.7.2.Background Scan............................................................................................................22

4.7.3.Foreground Scan.............................................................................................................22

4.7.4.Channel Scan Series.......................................................................................................22

4.8.MAC Reception Processes..................................................................................................23

4.8.1.Background Message Reception....................................................................................23

4.8.2.Foreground Request-Response Reception.....................................................................25

4.8.3.Bulk Data Reception........................................................................................................26

4.9.MAC Channel Guarding.......................................................................................................27

4.9.1.Persistent Guarding.........................................................................................................27

4.9.2.Non-Persistent Guarding.................................................................................................27

4.9.3.Default Channel Guard Period (TGD).............................................................................27

4.10.MAC Transmission Processes..........................................................................................28

4.10.1.CSMA Process Architecture..........................................................................................28

4.10.2.CA Process Architecture...............................................................................................29

4.10.3.Disabling CSMA on Guarded Channels........................................................................29

2 / 87


4.10.4.Data Link Layer Default CA Process.............................................................................30

4.10.5.Beacon Transmit Series................................................................................................30

4.11.Data Link Layer Host Control............................................................................................31

4.11.1.Off State.........................................................................................................................31

4.11.2.Idle State.......................................................................................................................31

4.11.3.Receive State................................................................................................................31

4.11.4.Transmit State...............................................................................................................31

4.11.5.Generic State Transition Model.....................................................................................31

4.11.6.State Transition Model for Blinkers...............................................................................32

4.12.Foreground Frame Headers and Footer...........................................................................33

4.12.1.Foreground Frame Header............................................................................................33

4.12.2.Data Link Layer Security Header..................................................................................34

4.12.3.Address Control Header................................................................................................34

4.12.4.Source ID Header..........................................................................................................35

4.12.5.Target ID Header...........................................................................................................35

4.12.6.Data Link Layer Security Authentication Data Footer...................................................35

5.Network Layer..............................................................................................................................36

5.1.D7A Background Network Protocols..................................................................................36

5.1.1.Background Frame Structure..........................................................................................36

5.1.2.Background Protocol IDs.................................................................................................36

5.1.3.D7A Advertising Protocol (D7AAdvP).............................................................................36

5.2.D7A Foreground Network Protocols..................................................................................37

5.2.1.Foreground Frame Vectoring..........................................................................................37

5.2.2.D7A Datastream Protocol (D7ADP)................................................................................37

5.2.3.D7A Network Protocol (D7ANP).....................................................................................38

5.2.3.1.D7ANP Frame Structure.....................................................................................................................38

5.2.3.2.D7ANP Addressing and Routing Models............................................................................................39

5.2.3.3.D7ANP Multihop Routing Application..................................................................................................40

5.2.3.4.D7ANP Multihop Request Usage........................................................................................................41

5.2.3.5.D7A Network Layer Security (D7ANLS).............................................................................................41

6.D7A Query Protocol Transport Layer (D7AQP).......................................................................42

6.1.Dialog Models........................................................................................................................42

6.1.1.Non-Arbitrated Two-Party Dialog (NA2P).......................................................................42

6.1.2.Arbitrated Two-Party Dialog (A2P)..................................................................................42

6.2.Transport Layer Collision Avoidance (CA) Models...........................................................45

6.2.1.Adaptive Increase No Division (AIND)............................................................................45

6.2.2.Random Adaptive Increase No Division (RAIND)...........................................................46

6.2.3.Random Increase Geometric Division (RIGD)................................................................46

6.3.Command Structure.............................................................................................................48

3 / 87


6.3.1.Command Request Template Allocation.........................................................................48

6.3.2.Command Response Template Allocation......................................................................48

6.4.Command Fields and Templates........................................................................................49

6.4.1.Command Code Structure...............................................................................................49

6.4.2.Command Extension.......................................................................................................50

6.4.3.Dialog Template..............................................................................................................50

6.4.4.Query Template...............................................................................................................51

6.4.5.ACK Template.................................................................................................................52

6.4.6.Error Template.................................................................................................................52

6.4.7.D7AQP Command Data..................................................................................................53

6.5.D7AQP Command Data Architecture..................................................................................53

6.5.1.Single File Templates......................................................................................................55

6.5.2.File Series Templates......................................................................................................55

6.5.3.Command Specific Data..................................................................................................56

6.6.D7AQP Commands Descriptions........................................................................................56

6.6.1.Announcement Commands.............................................................................................56

6.6.2.Inventory Commands......................................................................................................56

6.6.3.Collection Commands.....................................................................................................56

6.6.4.Request and Propose Datastream Commands..............................................................56

6.6.5.Acknowledge Datastream Command..............................................................................58

6.6.6.Application Shell Command............................................................................................58

6.7.Datastream Transport Method............................................................................................59

7.Session Layer...............................................................................................................................61

7.1.Wake-on Events....................................................................................................................61

7.1.1.Channel Scanning and Idle State Management.............................................................61

7.1.2.Passive Scanning for External RF Events......................................................................62

7.1.3.Wake-on via Sensor Event..............................................................................................62

7.1.4.Application Layer Events.................................................................................................62

7.2.Sessions and Network States.............................................................................................62

7.2.1.Session Random Number...............................................................................................62

7.2.2.Unassociated Network State...........................................................................................62

7.2.3.Scheduled Network State................................................................................................62

7.2.4.Promiscuous Network State............................................................................................62

7.2.5.Associated Network State...............................................................................................62

7.3.Session Scheduling via the Session Stack.......................................................................62

7.4.Power Autoscaling...............................................................................................................63

8.D7A Data Elements (Presentation Layer)..................................................................................64

4 / 87


8.1.Special Data Elements.........................................................................................................64

8.1.1.Real Time Clock (RTC)...................................................................................................64

8.1.2.Key Table.........................................................................................................................64

8.1.3.D7A Application Layer Protocol (ALP) IDs.....................................................................64

8.2.Permissions & Authentication............................................................................................65

8.2.1.Users...............................................................................................................................65

8.2.2.Permissions Code...........................................................................................................65

8.3.Indexed Short File Series Block (ISFSB)............................................................................66

8.4.Indexed Short File Block (ISFB)..........................................................................................66

8.4.1.Network Configuration Settings.......................................................................................68

8.4.2.Device Parameters..........................................................................................................69

8.4.3.Channel Configuration.....................................................................................................70

8.4.4.Real Time Scheduler (Optional)......................................................................................71

8.4.5.Sleep Channel Scan Series............................................................................................72

8.4.6.Hold Channel Scan Period List.......................................................................................72

8.4.7.Beacon Transmit Period List...........................................................................................72

8.4.8.Application Layer Protocol List........................................................................................73

8.4.9.ISFSB File ID List............................................................................................................73

8.4.10.GFB File List (Optional).................................................................................................74

8.4.11.Location Data List (Optional).........................................................................................74

8.4.12.IPv6 Addresses (Optional)............................................................................................75

8.4.13.ISO 21451-7 Sensor List (Optional)..............................................................................75

8.4.14.Root Authentication Key (Optional)...............................................................................75

8.4.15.User Authentication Key (Optional)...............................................................................76

8.4.16.Routing Code (Optional)................................................................................................76

8.4.17.User ID (Optional)..........................................................................................................76

8.4.18.HW Fault Status............................................................................................................76

8.4.19.Application Extension....................................................................................................77

8.5.Generic File Block (GFB).....................................................................................................77

9.Application Layer Protocols (ALPs)..........................................................................................78

9.1.Null ALP.................................................................................................................................78

9.2.File Data ALP.........................................................................................................................79

9.2.1.File Permissions Operands.............................................................................................80

9.2.2.File Data Operands.........................................................................................................80

9.2.3.File Headers Operands...................................................................................................81

9.2.4.Delete File Operand (optional)........................................................................................81

9.2.5.Create New File Operand (optional)...............................................................................82

5 / 87


9.2.6.File Header & Data Operands.........................................................................................82

9.2.7.Restore File Operand (optional)......................................................................................83

9.2.8.Return File Error Operand...............................................................................................83

9.3.Cryptographic Authentication Subprotocols....................................................................83

9.4.Sensor Subprotocol.............................................................................................................83

10.Application Data.........................................................................................................................84

11.Appendix A. Feature Requirements for DASH7 Certification...............................................85

12.Appendix B. Example messages..............................................................................................87

6 / 87


1. Overview

DASH7 Alliance Protocol is a wireless air interface, and system stack, operating exclusively in the 433 MHz ISM

band. It is designed and intended for extreme low power applications, such as active RFID and wireless sensor

networks.

OSI Layer D7AComponent Description

7 Application API

Crypto Exchange

Sensor Access

File Access

under draft (DASH7 DNA)

under draft

ISO 24151-7

File Access Subprotocol

6 Data Elements

(Presentation)

Crypto Table

D7A FS

A volatile data structure for storage of host-host

cryptographic key pairings

A user-driven filesystem that supports read, write,

create, delete, modify of batchable, searchable short

files and longer unstructured files.

5 Session Light Session Control A 4-state session model with adaptive idling

4 Transport D7AQP Protocol

Collision Avoidance

A data query protocol with advanced addressing,

support for upper layer protocol encapsulation, and

ability to negotiate D7ADP communication

Multiple supported flow/congestion control models

3 Network Protocols

Network Routing

Network Security

D7AAdvP, D7AResP, D7ANP, D7ADP

Optional multihop routing header

Optional Network Layer Security (NLS), that encrypts

the destination address

2 Data Link Frame Addressing

Data Link Security

Data Transmission

Data Reception

Channel Access

Unicast, Broadcast

under draft

Request-Response, Upper-layer event driven, or via

Data Link automated beacon

Configurable, sequential channel scan

CSMA-CA, with dynamic channel guarding rules

1 Physical Channel QoS

Encoding Types

Symbol Rates

Modulation

Channeling

Spectrum

Clear Channel Assessment

1/1 PN9, 1/2 Conv. Code

55.55 kb/s, 200.0 kb/s

50 kHz 2-FSK

(8 @ 216 kHz), (4 @ 432 kHz), (2 @ 648 kHz),

or combinations

433.056 - 434.784 MHz

Table 1.1: D7A Stack Overview

7 / 87


2. Device Classes

There are four standardized device classes, but others are possible and subject to future inclusion in this

standard. Moreover, a single device is permitted to switch between multiple settings as deemed necessary by the

application.

Features and capabilities described within this specification are often categorized as a function of the Device

Classes that support them. A very brief overview of device capabilities, corresponding to Device Classes, is

presented in Table 2.1.

Device Class Transmits Receives Complete

Featureset

Wake-on

Scan Cycle

Always-on

Receiver

Blinker

Endpoint

Subcontroller

Gateway

Table 2.1: Device Class Feature Overview

2.1. Blinker Device Class

The Blinker Device Class describes the most simple type of D7A device. A D7A Blinker provides only transmission

features. It may send data for others to receive (usually Gateways), but it cannot receive.

2.2. Endpoint Class

A D7A Endpoint spends most of its time in a low-power state. Once the device receives a wake-on event, it shall

engage in a process of request reception and, usually, response transmission.

2.3. Subcontroller Class

A D7A Subcontroller uses wake-on scan cycles in similar ways as Endpoints do. However, it is a full-featured device that may be configured to perform all D7 features.

2.4. Gateway Class

The Gateway Class defines a full-featured, always-on device. A D7A Gateway does not use scan cycles, and

instead it uses idle time for always-on reception. The Gateway is named as such because it is typically a device

that connects the D7A network to another type of network.

8 / 87


3. Physical Layer

3.1. Spectrum Utilization and Channels

D7A Protocol uses the 433 MHz ISM Band, occupying 433.05 to 434.79 MHz. The formal D7A spectrum extends

from 433.056 to 434.784 MHz, organized into channels. Each channel is defined by an index specifying its center

frequency and an index specifying its bandwidth. Any given device may, at any given time, permit communication

on any combination of supported channels. Optimal practice, however, is to minimize the usage of overlapping

channels within a single network.

3.1.1. Channel Center Frequencies

Channel center frequencies are indexed pursuant to Table 3.1.1.1 below. Channel identification includes the

channel frequency index.

Center

Freq. Index

Center Frequency Center

Freq. Index

Center Frequency

0x00 433.164 MHz 0x01 433.272 MHz

0x02 433.380 MHz 0x03 433.488 MHz

0x04 433.596 MHz 0x05 433.704 MHz

0x06 433.812 MHz 0x07 433.920 MHz

0x08 434.028 MHz 0x09 434.136 MHz

0x0A 434.244 MHz 0x0B 434.352 MHz

0x0C 434.460 MHz 0x0D 434.568 MHz

0x0E 434.676 MHz 0x0F

Table 3.1.1.1: Channel Center Frequency Indexes

3.1.2. Channel Bandwidths

Channel bandwidths are indexed pursuant to Table 3.1.2.1 below. Channel identification includes the channel

bandwidth index. The Channel Bandwidth Index also stipulates the type of modulation and symbol rate the

identified channel shall utilize

Bandwidth

Index

Channel Bandwidth Modulation Symbol Rate

0x00 0.432 MHz FSK-1.8 55.555 kHz

0x01 0.216 MHz FSK-1.8 55.555 kHz

0x02 0.432 MHz FSK-0.5 200 kHz

0x03 0.648 MHz FSK-0.5 200 kHz

Table 3.1.2.1: Channel Bandwidth Indexes

9 / 87


3.1.3. Spectrum IDs

Channel usage and modulation type is indicated via Spectrum ID. Each Spectrum ID is a one byte concatenation

of the Channel Bandwidth Index (upper nibble) and Channel Center Frequency Index (lower nibble). D7A

supports only certain Channel IDs, as shown in the Table 3.1.3.1 below.

Notes

Spectrum IDs are grouped into Channel Classes. If a Device Class optionally supports a Channel Class, it shall

either support all or none of the included Spectrum IDs.

Spectrum ID 0x7F is reserved. It may be used as a wildcard in scan and beacon sequence lists, where it

resolves to the channel that the device has most recently completed a dialog.

Chan Class Spectrum ID

Base 00

Normal 10 12 14 16 18 1A 1C 1E

Hi-Rate21 25 29 2D

23 27 2B

Blink 32 3C

Reserved 7F

Spectrum 433.056 MHz 434.784 MHz

Table 3.1.3.1: Spectrum ID allocations per Channel Class

3.1.4. Channel IDs

The Channel ID is a logically ORed combination of the encoding option and the Spectrum ID. The value

0x80 shall be ORed with the Spectrum ID if optional FEC encoding is used.

3.2. Channel Classes

Channel Classes specify the data rates, message modulation types, passband requirements, and stopband

requirements for each D7A channel. Channels in a given class may also be required to participate in a CSMA

process in prior to transmission.

Base Class Basic Channel Class required for all D7A devices

Normal Class Multichannel variant of Base Class

Hi-Rate Class High data rate variant of Normal Class

Blink Class High data rate Beacon-only Channel Class

10 / 87


Specification Min Typ Max Units

Subcarrier Frequency Deviation 47 50 53 kHz

Carrier Frequency Deviation -15 0 +15 kHz

Data Rate Deviation -2% 0 +2%

Peak to Channel-Stopband Attenuation 30 dB

EIRP at Channel-Stopband -40 dBm

EIRP at Neighboring Channel-Stopband -60 dBm

Passband EIRP 0 dBm

Table 3.2.1: Basic Physical Requirements for all Channel Classes

Channel

Class

FEC Option CSMA Carrier Sense

Min Sensitivity

1% BER

Min Sensitivity

Passband

Max EIRP

Base Available Optional -110 dBm -90 dBm 0 dBm

Legacy N/A Optional -110 dBm -90 dBm None

Normal Available Mandatory -110 dBm -90 dBm None

Hi-Rate Available Mandatory -100 dBm -80 dBm None

Blink Available Optional -100 dBm -80 dBm 0 dBm

Table 3.2.2: Additional Physical Requirements per Channel Class

3.2.1. FSK-1.8 Modulation

Channel classes Base and Normal use a wideband FSK modulation, which in D7A is 55.555 kb/s and uses a

nominal modulation index of 1.8. Transmission filtering may be required in order to meet the stopband

requirements for a given Channel Class.

FSK-1.8 Modulation Summary

Type: 2-FSK

Frequency Deviation: 50 kHz

Symbol 0 (LOW): Carrier - 50 kHz

Symbol 1 (HIGH): Carrier + 50 kHz

Symbol rate: 55.555 kHz

FSK-1.8 Modulation Transmission Filtering Requirements

The transmission shall be receivable by 2-BFSK receivers.

The filter shall not decrease detectable SNR vs. that of 2-BFSK by more than 3 dB.

If gaussian pulse shaping is used (hence GFSK), the bandwidth-time product of the gaussian filter shall be in the

range of 0.5 to 1.0.

11 / 87


3.2.2. FSK-0.5 Modulation

Channel classes Hi-Rate and Blink use a narrowband FSK modulation, which in D7A is 200.00 kS/s and uses a

nominal modulation index of 0.5. Transmission filtering may be required in order to meet the stopband

requirements for a given Channel Class.

FSK-0.5 Modulation Summary

Type: 2-FSK

Frequency Deviation: 50 kHz

Symbol 0 (LOW): Carrier - 50 kHz

Symbol 1 (HIGH): Carrier + 50 kHz

Symbol rate: 200.0 kHz

FSK-0.5 Modulation Transmission Filtering Requirements

The transmission shall be receivable by 2-BFSK receivers.

The filter shall not decrease detectable SNR vs. that of 2-BFSK by more than 6 dB.

If gaussian pulse shaping is used (hence GFSK), the bandwidth-time product of the gaussian filter shall be in

the range of 0.5 to 1.0.

3.2.3. Base Channel Class

The Base Channel Class permits a single channel using D7A FSK-1.8 Modulation. The channel center

frequency is always 433.920 MHz, the channel bandwidth 432 kHz, and CSMA-CA is optional.

3.2.4. Normal Channel Class

The Normal Channel Class provides for up to eight concurrent channels, using D7A FSK-1.8 Modulation on even-

spaced Channel Center Frequency Indices. The Channel Bandwidth is always 216 kHz. CSMA- CA is required

prior to transmission.

3.2.5. Hi-Rate Channel Class

The Hi-Rate Channel Class permits up to four concurrent channels, using D7A FSK-0.5 Modulation on odd-

spaced Channel Center Frequency Indices. The Channel Bandwidth is always 432 kHz. CSMA-CA is required

prior to transmission.

3.2.6. Blink Channel Class

The Blink Channel Class permits up to two concurrent channels, using D7A FSK-0.5 Modulation. The Channel Bandwidth is always 648 kHz. CSMA-CA is optional, prior to transmission.

3.3. CCA Process

Certain Channel Classes require the use of a CSMA routine prior to transmission of data over the channel, and for

others it is optional. Upper layers of the specification, particularly the Data Link Layer and Transport Layers,

describe the processes that utilize CSMA and Collision Avoidance models (CSMA-CA). All CSMA-CA processes,

however, are based on the common, inner-loop CCA process shown below.

ECCA Parameter

The ECCA parameter is provided by upper layers or configured as a default within the implementation of the

Physical Layer. During CCA, the detected RSSI of the channel shall meet the following requirement in order for

CCA to be declared successful: Detected Channel RSSI ECCA. The RSSI detection for CCA must be precise to

within 6 dBm.

12 / 87


3.4. Symbol Encoding

Messages transmitted or received over D7A Channel Classes are comprised of binary symbols. The symbols

are encoded by one of two methods supported by D7A , The goal of symbol encoding in D7A is to provide a

statistically DC-Free datastream, while maximizing throughput efficiency.

Two encodings are available, one that emphasizes simplicity and data rate (PN9) and another that emphasizes

data integrity in mid-to-low SNR environments (FEC). When using the Channel Classes that support multiple

encodings, Normal and Hi-Rate, it is the duty of the upper layers to configure the encoder and decoder as

needed, to utilize whichever method is required.

3.4.1. Endiannes

Content of all the messages transmitted is sent on Big Endian format, most significant byte (MSB) first.

3.4.2. PN9 Encoding Method (Mandatory)

The first stage of all encoding methods is the use of PN9 encoding, as described below. Likewise, the last stage

of all decoding is the same PN9 method. Sometimes referred to as data whitening, PN9 encoding is a full-rate,

statistically DC-free encoding that offers no encoding gain. Encoding and decoding require the use of a Linear

Feedback Shift Register (LFSR) and a seed polynomial to produce a predictable sequence of pseudo-random

values that are XORed with the datastream. The PN9 polynomial is always initialized to the following value: x8 +

x7 + x6 + x5 + x4 + x3 + x2 + x1 + x0. All Channel Classes must support communication via PN9 Encoding.

Table 3.4.2.1: PN9 Encoder and Decoder. The initial LFSR state is 111111111.

13 / 87

Figure 3.3.1: CCA Process Diagram

Channel RSSI > ECCA

(tolerance = 6 dB)

Start Process

DetermineCCA Status

No

Yes

Channel RSSI ECCA

(tolerance = 6 dB)

ECCA

DataBitstream

8 7 6 5 4 3 2 1 06 5 4 3 2 1 0

6 5 4 3 2 1 07

Data OUT[7:0]

LFSR

1. The LFSR is initialized to the

specified polynomial.

2. 8 bits of data are shifted in.

The LFSR is also shifted 8 times.

(least significant bit is shown as 0)

3. The XOR operation is latched to

Data Out after the 8th bit is

shifted-in.

4. Encoding and Decoding follow

this process, symmetrically.


3.4.3. FEC Encoding Method (Optional)

Forward error correction (FEC) encoding may optionally precede PN9 encoding of the byte data. The technique

used is a non-recursive convolutional code with 4x4 matrix interleaver. D7A FEC Encoding is chiefly designed to

improve bit error rates at mid-to-low SNR environments and less-so to improve decodability near the SNR limit (i.e.

communications range). By virtue of its use of the 433 MHz band, the D7A air interface already has sufficient

propagation performance for all intended applications. To this end, the interleaved convolutional code performs

better than most, if not all, other methods.

Convolutional Encoder & Decoder

The first stage of the encoder and second stage of the decoder is the computation of a convolutional code from

the non-encoded data. The code is a 1/2 rate convolutional code, using a specific algorithm of constraint length =

4. As the input to the interleaver must be 32 bit aligned, the convolutional code trellis terminator appended to the

unencoded data is 0x0B0B for even-length byte input and 0x0B for odd length byte input.

Matrix Interleaver & Deinterleaver

The second stage of the encoder and the first stage of the decoder is a matrix interleave/deinterleave process,

which is designed to separate adjacent data so that bursty data errors can be more effectively treated by the

convolutional code error corrector. The interleaving and de-interleaving operations are executed on 2 bits

symbols.

Input 32 bit Datastream

0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31

Output 32 bit Datastream

30 31 22 23 14 15 6 7 28 29 20 21 12 13 4 5 26 27 18 19 10 11 2 3 24 25 16 17 8 9 0 1

Figure 3.4.3.2: FEC interleaver rule

14 / 87

Figure 3.4.3.1: FEC convolutional code design, with constraint length 4.

S1

S2

S3

bin

Code Constraint DataBitstream

(MSB first)

S1 S2 S3 bin Output

0 0 0 0 00

0 0 0 1 11

0 0 1 0 01

0 0 1 1 10

0 1 0 0 11

0 1 0 1 00

0 1 1 0 10

0 1 1 1 01

1 0 0 0 11

1 0 0 1 00

1 0 1 0 10

1 0 1 1 01

1 1 0 0 00

1 1 0 1 11

1 1 1 0 01

1 1 1 1 10


3.5. Packet Structure

All data trafficked on D7A Channels is in the form of D7A Packets. D7A Packets contain a Preamble, Sync Word,

and a payload. The Preamble is a series of binary symbols, 10101 used for the purpose of calibrating data rate

circuits on the receiver. The Sync Word is a block of 16 binary symbols, chosen for excellent auto-correlation

properties, and it is used to align the the packet payload. The packet payload contains encoded data. The Sync

Word and payload are topics of subsequent sections of the specification.

Additionally, power ramp-up and ramp-down periods may precede and follow the packet. These periods should

be kept as short as possible, used for the purpose of meeting the channel stopband requirements.

Specification Min Typ Max Units

Preamble (Base, Normal Channel Classes) 32 32 64 Symbols

Preamble (Hi-Rate, Blink Channel Classes) 48 48 128 Symbols

Power Ramp-up Period 0 8 32 Symbols

Power Ramp-down Period 0 8 32 Symbols

Sync Word 16 16 Symbols

Table 3.5.2: Packet Requirement Specifications

3.5.1. Sync Word Classes

The Physical Layer support multiple classes of sync words, for the purpose of differentiating packets at the PHY

level. Currently, two classes exist, 0 and 1. Each class contains a standard type and an optional type to be used

when the Frame Data is encoded via FEC. The PHY layer is only required to be able to detect one value of sync

word at any given time of operation. Table 3.5.1.1 gives an overview of the values of the sync words. Since all

data in D7A is send MSB first, this means, e. g., for an Non-FEC Type, Class 0, the 0xE6 is sent first, then 0xD0.

Class Non-FEC Type FEC Type

0 0xE6D0 0xF498

1 0x0B67 0x192F

RFU

Table 3.5.1.1: Sync Word values by class and type

15 / 87

Figure 3.5.1: General structure for all packets.

Ramp-up Preamble

non-encoded

Sync Word

non-encoded

Packet Payload

encoded

Ramp-down


4. Data Link Layer

The D7A Data Link Layer includes specification for the following items:

Host I/O Relationship

Host Process Control

Frame Construction

MAC Processing

Frame field definitions

4.1. Hosts

Each D7A Device may contain a single host. Therefore, the device-host relationship is 1:1, and upper layers of

the stack will relate to each consecutive lower layer in a 1:1 fashion. The duty of the host is to manage

communications over the D7A Air Interface, per requirements of all applicable layers of the stack.

4.1.1. Host Input

A single host may receive inputs from any number of channels, simultaneously. A host that can receive

multiple channels simultaneously is described as a Multiple Input (MI) host, and one with single channel input is

described as a single input (SI) host.

4.1.2. Host Output

A single host may transmit as output on only a single channel at any given time. Therefore, the host is

Single Output (SO).

4.1.3. Host I/O

MISO and SISO D7A hosts are possible. Devices with a single Physical Layer interface (i.e. radio receiver) are

typically SISO hosts. Relevant areas of the specification will differentiate MISO and SISO host behavior.

4.2. Units, Parameters, and Data Elements

4.2.1. Timing Units

The primary unit of time utilized by the Data Link Layer is the Tick, abbreviated as ti. A Tick is 2-10 seconds

(~0.977 ms), and all functions of the Data Link Layer are resolved at periods no shorter than 1 ti.

Unit Abbrev. Min Typ Max Units

Tick ti 2-10 sec

Timing Tolerance (Gateway) 0.005 %

Timing Tolerance (Subcontroller) 0.005 %

Timing Tolerance (Endpoint) 2 %

Timing Tolerance (Blinker) 5 %

Table 4.2.1.1: Timing Units and Tolerance Requirements, per Device Class

16 / 87


4.2.2. Glossary of Input Parameters

The parameters below are provided by upper layers, programmed as constant defaults by the implementations,

or, in the case of TCA, TGD, and TL, derived by the Data Link Layer from other parameters.

Parameter Description Min Typ Max Units

CSMAEN CSMA Enable 0 1

ECCA Clear Channel Assessment Max Energy -140 -110 0 dBm

ESM Scan Minimum Energy -140 -90 0 dBm

FPP Frames Per Packet 1 255 frames

MFPP Maximum Frames Per Packet 1 255 frames

RTSM Real-Time Scheduler Mask 0 65535 sec

RTSV Real-Time Scheduler Value 0 65535 sec

TBSD Background Scan Detection Timeout 1 65535 ti

TC Contention Period (Response Timeout) 0 65535 ti

TCA Collision Avoidance Timeout 0 65535 ti

TFSD Foreground Scan Detection Timeout 1 65535 ti

TG Guard Period 0 65535 ti

TGD Default Guard Period (Derived) 2 10 ti

TL Listen Period 0 10 65535 ti

TNSE Time of Next Scan Event 0 65535 ti

Table 4.2.2.1: Glossary of Data Link Layer Input Parameters

4.2.3. Glossary of Input Data Elements

Data Description Contents Source

Beacon Transmit Series Data Ordered Parameters Stored Data

Channel Scan Series Data Ordered Parameters Stored Data

CSMA Channel Queue 1-8 Channel IDs Upper Layers

Device ID values (UID/VID) 8 byte UID, 2 byte VID Stored Data

Device Subnet Specifer/Mask (DSS/DSM) 1 byte Subnet Stored Data

Foreground Frame Header/Footer parameters (TX) Ordered Parameters Upper Layers

Foreground Frame Header/Footer parameters (RX) Frame Data Physical Layer

Table 4.2.3.1: Glossary of Data Link Layer Input Data Elements

17 / 87


4.3. Data Link Filtering

The D7A Data Link Layer uses up to three filters to qualify incoming frames for processing. The CRC16

validation should be processed first, to validate the data in the frame. The subnet and link quality filtering may

occur in either order.

4.3.1. CRC16 Validation

A frame is always terminated by a 16 bit CRC16 field. Only when the CRC16 calculation of a received frame

matches the supplied value shall the Data Link Layer continue to process the frame. The calculation of the field

shall include all previous bytes of the frame, and it shall utilize the CCITT CRC16 polynomial, or x16 + x12 + x5 + x0

(1021) with initial value 0xFFFF. Using this algorithm correctly, the value 0x29B1 shall result from computation of

the nine character ASCII reference string 123456789 (Note: the numbers of the reference string are ASCII

encoded, not binary).

4.3.2. Subnet Matching

The Subnet is an 8 bit value that allows configurable, data-based filtering of incoming frames. Each device

contains an internal subnet value (the Device Subnet) that is compared with the value of the incoming frame (Frame

Subnet). The upper 4 bits of the Subnet contain a specifier, which must be matched exactly, or be valued 0xF,

which is universally accepted. The lower 4 bits of the Subnet ID form a self-referential bitmask. The device and

frame subnet masks are logically anded, and compared. The process for accepting a frame via Subnet value is

shown in Table 3.4.2.1.

Specifier Mask

b7 b6 b5 b4 b3 b2 b1 b0

Table 4.3.2.1: Subnet ID Construction

4.3.3. Link Quality Assessment

Frames may contain a data field parameter indicating the EIRP (equivalent isotropic radiated power) the transmitter

uses to transmit the packet and frame. When a frame containing this EIRP field is received, the receiver may

subtract the value of detected energy of the reception (i.e. packet RSSI) from the provided EIRP field value to

derive the value of link budget utilization. If Link Quality Filtering is enabled, and the Link Quality Threshold is lower

than the derived value for link budget utilization, then the frame shall be discard and Data Link Layer processing

terminated.

18 / 87


4.4. Data Link Layer Addressing

D7A hosts keep a set of addresses, stored at the Data Link Layer, also accessible by all upper layers.

4.4.1. Device ID Structure

D7A uses a Device ID structure compliant with ISO 15963, manifested in a fixed-value Unique ID (UID)

and a dynamic-value Virtual ID (VID).

4.4.2. UID (Unique ID)

The UID is a 64 bit EUI-64 value that shall be unique to every D7A Host and device.

D7A

OUI-24/36 - Manuf ID

Serial Number

24/36 bits 40/28 bits

Table 4.4.2.1: D7A UID Structure

EUI-64 compliant ID:

The upper 24 bits of the UID are the OUI-24 value, allocated by IEEE. This identifier uniquely identifies the

manufacturer of the Dash7 alliance device.

The upper 36 bits of the UID are the OUI-36 value, allocated by IEEE. This identifier uniquely identifies the

manufacturer of the Dash7 alliance device.

The serial number is a 40/28 bit integer, assigned by the manufacturer. When the serial number is combined

with the manufacturer ID this creates an unique ID among all other Dash7 alliance devices.

19 / 87

Figure 4.3.3.1: Subnet Filtering Process

Start Process

FSS = 0xF

FSS = DSS

FSM & DSM = DSM

Success:Frame Valid

Failure:Frame Invalid

No

No

No

Yes

Yes

Yes

Abbreviations

FSS: Frame Subnet SpecifierDSS: Device Subnet SpecifierFSM: Frame Subnet MaskDSM: Device Subnet Mask


4.4.3. VID (Virtual ID)

The Virtual ID, also compliant with ISO 15963, is a 16 bit ID that may be dynamically supplied to a device by a

network administrator. VID usage is application dependent, but best practice is to ensure that any Hosts VID is

unique to the network it is on. The VID is not required to be unique to all D7A Hosts and devices.

4.4.4. Data Link Broadcasting

If a frame processed by the Data Link Layer does not contain a data field representing a target address Device ID,

or if the target address otherwise cannot be read by the Data Link Layer, this frame shall be processed as

broadcast data. Data Link Broadcast address resolution is always successful, and the frame processing is always

continued into the next, upper layers.

4.4.5. Data Link Unicasting

If a frame processed by the Data Link Layer does contain a data field representing a target address Device ID,

this frame shall be processed as unicast data. The Data Link Unicast address resolution is successful only when

the target address Device ID in the received frame matches exactly the Device ID stored on the Host that

receives it. On failure, frame processing shall cease, and the next, upper layers shall not be invoked.

4.5. Top Level Frame Structure

There are two types of frames used by the D7A Data Link Layer, Background Frames and Foreground Frames.

Background Frames and Foreground Frames use different Sync Word Classes (as defined in the Physical Layer).

4.5.1. Background Frames

Background frames are fixed length, of 6 bytes, preceded by a Sync Word of Class 0 (defined in Physical

Layer). The final two bytes are the CRC16 field. Background frames exist always as one frame per packet.

Sync 0 Subnet Payload CRC16

1 Byte 3 Bytes 2 Bytes

Table 4.5.1.1: Background Frame Structure

20 / 87


4.5.2. Foreground Frames

Foreground frames are of variable length, up to 255 bytes, preceded by a Sync Word of Class 1 (defined in

Physical Layer). The first data byte of the Foreground frame is a length parameter, which measures the total

number of bytes in the frame, including the length byte itself and the CRC.

Sync 1 Length Headers Payload Footer CRC16

1 Byte 3-38 bytes 0-249 Bytes 0-20 Bytes 2 Bytes

Table 4.5.2.1: Top Level Foreground Frame Structure

Foreground frames may exist individually, with one frame per packet, or in series with multiple frames per packet.

Support for multiframe packets is optional. The number of frames-per-packet a Host can support is a Data Link

Layer parameter, MFPP (Max Frames per Packet), and the range is 1-255.

Sync 1 Frame 1 Frame 2 Frame N

255 Bytes 255 Bytes 255 Bytes

Table 4.5.2.2: Multiframe Packet, using Foreground Frames

4.6. Data Link Dialog Models

The D7A Data Link Layer utilizes two basic dialog models, one for Background Frames and one for

Foreground Frames, that form the basis of all communication and transport methods.

4.6.1. Background Dialog

The Background Dialog commences when a Background Frame is transmitted, and it ends as soon as the frame

is finished transmitting. If a Host detects (by Sync Word), validates (by CRC), and filters (by Subnet) the

Background Frame, the data it contains is sent to upper layers for additional processing.

4.6.2. Foreground Dialog

The Foreground Dialog commences when a Foreground Request Frame is transmitted, and it continues

through a sequence of response and listening.

Contention Period TC

Between the conclusion of the request and the commencement of TL is the response contention period, TC. The

value for TC must be defined in the request payload, by upper layers, and passed as a parameter to the Data Link

Layer.

21 / 87

Figure 4.6.1: Background and Foreground Frame dialog model overview (not to scale)

Frame Detected

Background Dialog

Frame Detected Request Filtered & Addressed

TC TL

TL enabled

Foreground Dialog

Background Broadcast

Foreground Response(s)Foreground Request


Dialog Termination

The dialog immediately terminates if filtering or addressing of the request fails, or if it is terminated for any

reason by an upper layer. If filtering and addressing succeeds, and no upper layer termination occurs, it ends

after listen period TL expires without containing a follow-up request. Thus, dialog may be extended indefinitely

by supplying a subsequent request within each subsequent TL period.

Listen Period TL

The listen period TL is by default disabled r (TL = 0), but may be enabled by the Data Link Layerand assigned

a value by an upper layer process. If enabled and not otherwise assigned, the Data Link layer assigns a default

value for TL (10 ti).

4.7. MAC Scan Processes

There are two types of MAC scanning: scanning for Background Frames and a scanning for Foreground Frames.

Both types use sync word detection and a sync word detection timeout. If a running Host is not actively receiving,

transmitting, or otherwise processing frame data, it shall engage itself in a parameterized, iterative scanning

process.

4.7.1. Scan Scheduler

Hosts may optionally use a Real-Time Clock (RTC) scheduling mechanism to key channel scans to specific times.

The RTC shall be configured as a 32 bit binary value with a one-second resolution. Two parameters are used with

the RTC value to trigger the scan.

Real-Time Scheduler Mask (RTSM), a 16 bit value logically anded with the lower 16 bits of the RTC Value.

Real-Time Scheduler Value (RTSV), a 16 bit value compared with the result of the RTSM and RTC Value.

When RTSV = RTSM & RTC Value, the scan cycle shall begin. If the Scan Scheduler is not enabled or

otherwise not available, the Host shall begin the scan cycle immediately upon turn-on.

4.7.2. Background Scan

The Background Scan searches for a Sync Word of Class 0. It also requires a sufficient level of energy to be

detectable on the channel, prior to detection of the sync word. This is known as the Scan Minimum Energy (ESM),

and its value for is passed down from upper layers as a signed RSSI value in dBm units. The practical minimum

value for ESM is -140 dBm, roughly the noise floor energy level of the 433 MHz band.

The Host shall terminate the scan immediately upon failure to detect RSSI energy on the channel, equal to or

greater than the value for ESM.

Beginning from when the scan starts, the Host has a finite amount of time to successfully detect the sync word.

The Background Scan Detection Timeout parameter (TBSD) is optionally passed down from upper layers. The

range of TBSD is 1 - 65535 ti.

If TBSD is below the duration of one Background Frame Packet, the Data Link Layer replaces the TBSD with this

duration, rounded up to the nearest ti. This value is known as the Default TBSD.

4.7.3. Foreground Scan

The Foreground Scan is similar to the Background scan. The differences are that the Foreground Scan searches

for a Sync Word of Class 1, and it is does not terminate immediately upon failure to detect RSSI at a level ESM or

greater, although only a sync word at or above ESM shall be accepted as valid. Additionally, the Foreground Scan

has its own Foreground Scan Detection Timeout parameter (TFSD), with the same requirements that TBSD has.

4.7.4. Channel Scan Series

The Data Link Layer performs the task of Foreground and Background Scan automation. A scan series is an

ordered list of scan parameters, which the Data Link Layer will use, one-by-one, until the list is done, until a frame

is successfully received or stopped by an upper layer. After the scan series completes, it will not continue unless

reset. The following actions cause the scan series to reset:

A frame is successfully received, and passed to upper layers

22 / 87


An RTCScheduler event occurs

No RTC Scheduler is enabled, and the scan series completes (auto-reset)

Parameter Value Description

Channel ID 0-255 Physical Layer Channel ID to use for scan

Scan Type F/B Foreground or Background Scan Type

Scan detect timeout (TSD) 0-65535 ti Value for TBSD or TFSD parameter, per Scan Type

Time until next scan event

(TNSE)

0-65535 ti Following Scan Termination, the number of Ticks

until the next scan begins, using the next datum

Table 4.7.4.1: Channel Scan Datum Parameters

Datum 1 Datum 2 Datum 3 Datum 4

Chan 0x12 Chan 0x14 Chan 0x12 Chan 0x2D

Type B Type B Type F Type F

TBSD 2 TBSD 2 TFSD 30 TFSD 30

TNSE 100 TNSE 400 TNSE 200 TNSE 400

Table 4.7.4.2: Example Channel Scan Series

Hosts that are intended to constantly monitor channels can be accommodated by setting the Next Scan

Event values to 0 ti, and the Scan Type to Foreground.

4.8. MAC Reception Processes

The Data Link Layer supports three reception models: Background Message reception, Request-Response

reception, and Bulk-Data Reception.

4.8.1. Background Message Reception

A Background Message is a one-way transmission of a Background Frame. Background Message detection and

reception may occur after the success of a Background Scan. The Background Scan and Background Message

Reception processes are interlinked, and they are presented together in Figure 4.8.1.1. Following the Background

Scan, once the 7 byte packet is successfully decoded, the CRC16 field is processed. On success, the data from

the Background Message shall be made available to upper layers.

23 / 87


24 / 87

Figure 4.8.1.1: Background Frame Reception and Validation Process

Start Process

Background Scan Process

Success:Frame Received

Failure:Reception Error

No

No

No

No

Yes

Yes

Yes

Physical Layer:Wait for receiver

stabilization

TerminateProcess

Yes

Carrier SenseAbove Esm

Sync WordDetected

Sync Timeout(TBSD)

Receive FrameBytes

Frame FilteringSucceeds


4.8.2. Foreground Request-Response Reception

The default communication model for Foreground Frames is the Request-Response Dialog. In this model, a Host

transmits a single Request, containing a single Foreground Frame, and it is optionally followed by one or more

responses from one or more other Hosts. Responses contain only a single Foreground Frame.

Most of the guiding parameters are the responsibility of the upper layers.

The number of Hosts available to respond (addressing) is a feature of the upper layers.

The number of times a Host should consecutively respond (redundancy) is a Data Link Layer feature.

25 / 87

Figure 4.8.2.1: Request/Response Reception Process

Start Process

Sync Timeout(TFSD)

Success:Frame Received

Failure:Reception Error

Yes

Yes


stabilizationForeground Scan Process

Sync Word AboveESM Detected

Receive FrameBytes (255)

Yes

No

TerminateProcess

No

Frame FilteringSucceeds

No


4.8.3. Bulk Data Reception

Bulk data reception is the negotiated reception of a multiframe packet. The number of frames a Host can receive

as part of a single packet is taken from its MFPP parameter. This parameter shall be negotiated via upper layers,

prior to bulk data reception, and the two parties shall agree on a value for Frames Per Packet (FPP) of the resulting

packet(s). The Data Link Layer is not required to process data errors for Bulk Data reception, instead, Bulk Data

reception errors may be handled by upper layers.

26 / 87

Figure 4.8.3.1: Multiframe, Bulk Data reception

Start Process

Sync Timeout(TFSD)

TerminateProcess

Upper Layer:Record

Frame Error

Final FrameReceived

Yes

Foreground Scan Process


stabilization

Sync Word AboveESM Detected

Yes

No

No

Receive FrameBytes (255)

NoFrame Filtering

Succeeds

Yes

Upper Layer:Log/Process

Frame

Yes

No

Success:All FramesProcessed


4.9. MAC Channel Guarding

D7A Channels that do not require CSMA are described as Non-Guarded Channels (NGCs), and transmission on

the channel may occur at any point without prior negotiation. Channels that do require CSMA are described as

Guarded Channels (GCs), and access to these channels must be negotiated by a CSMA-CA process. The CSMA-

CA process must ensure that transmission only knowingly occurs when a channel is unguarded,

The channel guarding process is managed as a parameter the Data Link Layer passes down to the Physical

Layers CSMA process, and in some cases the parameter is based on values passed down to the Data Link Layer

by upper layers. The main parameter is the Guard Period, noted in Fig 4.9.1 as TG. The treatment of the Guard

Period is illustrated in Fig 4.9.1 below.

4.9.1. Persistent Guarding

If the first transmission duration is greater than or equal to the Guard Period, and the silent period between

transmissions is less than the Guard Period (or non-existent), then the channel is guaranteed to be guarded for a

period of time following the last transmission, equal to one Guard Period. This is called Persistent Guarding, and it

is a function of parameters passed into the Physical Layer the CSMA routine by the Data Link Layer.

4.9.2. Non-Persistent Guarding

If a transmissions does not meet the requirements for Persistent Guarding, the channel is under Non- Persistent

Guarding. In this model, the channel is only guaranteed to be guarded during the transmission itself. Following

the transmission, the channel is not deemed as guarded.

4.9.3. Default Channel Guard Period (TGD)

When a value for the Guard Period is not explicitly provided by the Data Link Layer or upper layers, the value is

based on the data rate of the channel. It is equal to the duration of 32 frame bytes, rounded up to the nearest ti.

Channel Symbol Rate TGD TGD (FEC)

55.55 kb/s 5 ti 10 ti

200.0 kb/s 2 ti 3 ti

Table 4.9.3.1: Example Values for TGD

27 / 87

Figure 4.9.1: Channel guarding behavior is based on the transmission duration and the Guard Period (TG)

Guarded Unguarded

Silent

TG

Transmission

Persistent Guarding: Transmission Duration TG

TG

Unguarded UnguardedGuarded

Non-Persistent Guarding: Transmission Duration < TG

TG

Silent Transmission

Unguarded Guarded

Persistent Guarding: First Transmission TG, Silent Interval(s) < TG

Unguarded

Silent

Unguarded

SilentSilent

Transmission

Transmission SilentSilent


4.10. MAC Transmission Processes

Transmission on Guarded Channels requires the use of a collision avoidance (CA) process in all circumstances,

which may also feature a CSMA component. The Data Link Layer manages the CSMA-CA process, which is

comprised of elements from other layers.

Collision Avoidance Timeout Period (TCA)

The MAC transmission process must be supplied directly with a value for TCA, or derive it based on TC. TCA is the

period during which a transmission must be initiated, before the CA process is terminated in failure. TCA is derived

from TC when transmitting responses. TC is common to all Hosts fielding responses, but TCA is derived by each

Host based on the duration of its queued response transmission. TCA = TC - response duration. If TCA 0, no

response will be attempted.

4.10.1. CSMA Process Architecture

The Data Link Layer manages a CSMA process that is used for every transmission. The process of engaging

CCA at the physical layer can be disabled, thus effectively disabling the CSMA aspect of the process, but the

I/O relationship of the CSMA Process, as shown in Figure 4.10.1.1, shall always be the same.

28 / 87

Figure 4.10.1.1: CSMA Process

TCAStatus

TCATG

ChannelQueue

ECCA

Enable

CSMA Process

No

No

No

Yes

ECCA

TCA > 0Wait for TG(Guard Period)

Enable = On

Start Process

Use Channel atfront of the

Channel Queue

Yes

DetermineCCA Status

(Physical Layer)

Circular Shift Channel Queue

Subtract TCA byprocess duration

ECCA

DetermineCCA Status

(Physical Layer)

Yes

Yes

Failure:TransmissionNot Permitted

Success:Transmission

Permitted

Start Process

Enable = On

Wait for Tg(Guard Period)

Tca > 0

CSMA Process

No


4.10.2. CA Process Architecture

The Data Link Layer Collision Avoidance (CA) architecture glues together the CSMA process with Flow and

Congestion Control Processes defined in the Transport Layer. The CSMA process element can be disabled, but

the CA process will remain.

4.10.3. Disabling CSMA on Guarded Channels

By default, the Data Link Layer will apply the CSMA process to all transmission attempts on a guarded channel.

However, it can be disabled by upper layers in cases where disabling CSMA does not cause a guarding violation.

In these cases, the CA process will still occur. One application for disabling CSMA is for point-to-point (unicast)

responses. These can be initialized within the guard duration, TG, that follows adequately long Request

transmissions, and, as such, disabling CSMA often will not cause a guarding violation.

29 / 87

Figure 4.10.2.1: CA Process Architecture.

Start Process

Congestion Ctrl Process(Transport Layer)

InitialValues

EnableECCA

ChannelQueue

TG TCA

Status/TCA

CSMA Process

Status TCA

Flow Control Process

(Transport Layer)

TCA

TransmitStatus

Transmit Frame

TerminateProcess

No

Yes


4.10.4. Data Link Layer Default CA Process

The Transport Layer manages sophisticated flow and congestion control processes. Transmissions initiated below

the Transport Layer will use a rudimentary CA Process, shown in Figure 4.10.4.1. The process repeatedly checks

the available channels at TG intervals until TCA expires or a channel passes CSMA.

4.10.5. Beacon Transmit Series

The Data Link Layer performs the task of beacon transmission automation. The Beacon Transmit Series is

conceptually almost identical to the Channel Scan Series in concept, however, as Hosts are limited to single-

output the series cannot be divided across multiple transmission facilities. The following actions cause the

Beacon Transmit Series to reset:

A Scheduler event occurs

No Scheduler is enabled, and the scan series completes (auto-reset)

Redundant beacon transmissions will be transmitted as quickly as possible, following the prior transmission,

dependent on channel guarding rules, supplied CSMA-CA parameters, and Physical Layer capabilities.

30 / 87

Figure 4.10.4.1: Data Link Layer Base CA Process

Data Link Layer Base CA Process

Initial Values

Initialize

Congestion Control Process

Yes

TCA

TG

ChannelQueue

TG TCA TerminationStatus

Flow Control Process

Status

Status TCA

FeedbackStatus/TCA TCA

Needs Inititialization

No

NoStatus is

TrueYes

Load initialCSMA params

TCA = TCA

TCA = TCATCA = 0

ChannelQueue

Pass updated params to CSMA TCA 0


Parameter Value Description

Channel ID 0-255 Physical Layer Channel ID for transmission

CSMA-CA Parameters Parameters required for CSMA-CA, including

references to the transport layer flow & congestion

control methods to be used.

Frame Data Reference The Data Link Layer must be supplied with compliant

frame data, to transmit as the beacon

Response Contention

Period Timeout (TC)

0-65535 ti The Data Link Layer will attempt to receive a

response to the beacon, for this amount of time

following the transmission.

Redundancy Count 0-255 Number of redundant times to transmit the beacon.

The Data Link Layer automatically zeros this count if

it receives a qualified response to the beacon.

Next Beacon Event 0-65535 ti Following Beacon termination, the number of Ticks

until the next beacon begins, using the next datum

Table 4.10.5.1: Beacon Transmission Datum Parameters

4.11. Data Link Layer Host Control

The Data Link Layer interacts with other layers through four basic states: Off, Idle, Receive, and Transmit.

4.11.1. Off State

During Off State, the host is either powered-down or deactivated. The Application Layer is required to put

Hosts into and bring them out of the Off State.

4.11.2. Idle State

Upper layer processes may configure the Data Link Layer during the Idle State. During the Idle State, the Data

Link Layer itself may use a Channel Scan to monitor the medium, and it may initiate a Beacon Transmit Series

which is sent in the transmit state - to supply the medium.

4.11.3. Receive State

During the Receive State, symbols are being extracted from the Physical Layer, organized into frames by

the Data Link Layer, and transferred to upper layers. The Receive State begins once a suitable Frame Sync Word

is detected, during an Idle State Channel Scan. The Receive State is exited once a packet is completely received,

successfully or not, and status is passed to the upper layers. The Receive State transitions to the Idle State once

the final frame of a packet is completely received.

4.11.4. Transmit State

The Transmit State runs the CSMA-CA process to completion, and on success it begins the process of supplying

data to the Physical Layer. The symbols are generated from frames assembled by the Data Link Layer, using data

provided by upper layers. The Transmit State begins once invoked by an upper layer. The Transmit State is exited

once a packet is completely passed to the Physical Layer, which causes the status

to be passed to the upper layers. The Transmit State transitions to the Idle State once the final frame of a packet

is completely passed to the Physical Layer, or when the CSMA-CA process exits due to the channel being

guarded.

4.11.5. Generic State Transition Model

The Blinker Class lacks a Receive State, which all other device classes have. Data Link Layer state

transitions for device classes that enable the Receive State shall follow the model shown in Figure 4.11.5.1.

31 / 87


1. Application Layer activates/enables Host operation

2. (A) Beacon Transmit Series event occurs, causing

transmission of frame(s).

(B) An upper layer triggers a transmission. This could be a

Response to a Request, or something like a sensor alarm.

3. A Frame Sync Word is detected via a Channel Scan.

4. The host handled an upper layer event that did not cause it to

leave the Idle State.

5. Application Layer deactivates/disables Host operation

6. Following the cessation of the Transmit State, the Data Link

Layer immediately issues another transmission. This can

happen by transmission of a redundant beacon, immediately

following the previous beacon.

7. Transmit state ceases, due to CSMA-CA failure or because no

remaining frames require transmission.

8. The final frame of a packet is received completely

9. A frame is completely received, and it is propagated to

upper layers, but it is not the final frame of a packet.

4.11.6. State Transition Model for Blinkers

For Blinker Class operation, state transitions shall follow the model shown in Figure 4.11.6.1.

1. Application Layer activates/enables Host operation

2. (A) Beacon Transmit Series event occurs, causing

transmission of frame(s).

(B) An upper layer triggers a transmission event. An

example is a sensor alarm.

3. The host handled an upper layer event that did not cause it

to leave the Idle State.

4. Application Layer deactivates/disables Host operation

5. Following the cessation of the Transmit State, the Data Link

Layer immediately issues another transmission. This can

happen by transmission of a redundant beacon, immediately

following the previous beacon.

6. Transmission state ceases, due to CSMA-CA failure or

because no remaining frames require transmission.

32 / 87

Figure 4.11.5.1: Generic State Transition Model

Off

Idle

ReceiveTransmit

1

2

5

4

3

6

7 8

9

Figure 4.11.6.1: State Transition Model for Blinkers

Off

Idle

Transmit

1

2 3

4

5

6


4.12. Foreground Frame Headers and Footer

Foreground Frames contain a sequence of headers and a footer, that together provide a scope of Data Link

Layer functionality.

Frame

Header

DLLS

Header

Address Ctl

Header

Source ID

Header

Target ID

Header

Payload DLLS

Footer

3 Bytes 1-17 Bytes 2 Bytes 2/8 Bytes 2/8 Bytes 0-249 bytes 12-20 Bytes

Optional Optional Optional Optional Optional

DLLS Encryptable

Table 4.12.1: Foreground Frame Structure

4.12.1. Foreground Frame Header

The Foreground Frame Header is a four byte data field that defines the nature of the foreground frame, as well

as simple frame filtering options.

Subnet TX EIRP Frame Ctl

1 Byte 1 Byte 1 Byte

Table 4.12.1.1: Foreground Frame Header fields

Subnet 1 Byte Standard frame Subnet fieldTX EIRP 1 Byte The estimated radiated power of the transmission (TX EIRP), an unsigned

integer of the units (-40 + 0.5n) dBm, provided by the frame transmitter.

Frame Control 1 Byte Contains bitfields that specify frame attributes.

Listen DLLS En Addr Fr Cont RFU RFU D7A Frame Type

b7 b6 b5 b4 b3 b2 b1 b0

Table 4.12.1.2: Bitfields of Frame Control field from Foreground Frame Header

Listen 0/1 When set, TL is set to 10 ti by default, and it may be further altered by upper

layers. When clear, TL is set to 0.

DLLS 0/1 (Data Link Layer Security) When set, DLLS Header is present

En Addr 0/1 (Enable Addressing) When set, Address Control and Source Headers are present

Fr Cont 0/1 (Frame Continuity) When set, a frame follows directly after the current frame.

RFU 0 Reserved for future use

D7A Frame Type

00: Dialog Frame (vectors to D7ANP)

01: Dialog NACK (vectors to D7ANP)

10: Stream Frame (vectors to D7ADP)

11: RFU

33 / 87


4.12.2. Data Link Layer Security Header

The DLL Security Header contains a code and initialization data. The DLL Security will be defined in a

future version of the spec.

DLLS Code DLLS Initialization Data

1 Byte 0-16 Bytes

Table 4.12.2.1: Foreground Frame DLLS Header fields

DLLS Code 1 Byte A container for bitfields, that define the usage of

DLLS Initialization Data and the DLLS Authentication Data footer.

DLLS Init Data 0-16 Bytes Initialization data for the security process, defined by the DLLS Code

4.12.3. Address Control Header

The address control header contains some information reserved for upper layers, as well as source addressing

parameters that are directly usable by the Data Link Layer.

Dialog ID Flags

1 Byte 1 Byte

Table 4.12.3.1: Foreground Frame Source Header fields

Dialog ID 1 Byte A pseudo-random 8 bit value that persists throughout the dialog. The value is initially defined (or redefined) by upper layers and maintained by the DataLink Layer.

Flags 1 Byte Identifies the source and target address type, the usage of Network Layer

Security, and contains other upper layer flags

Addressing Option VID NLS Application Flags

b7 b6 b5 b4 b3 b2 b1 b0

Table 4.12.3.2: Address Control Flags

Addressing Option

00: Unicast

01: Broadcast

10: Anycast (treated by Data Link Layer as broadcast)

11: Multicast (treated by Data Link Layer as broadcast)

VID 0/1 (Virtual ID) When set, the 2 byte VID shall be used for Source and Target

Addresses, instead of the 8 byte UID.

NLS 0/1 (Network Layer Security) When set, NLS is used, which encrypts the Target Address

and the Payload. Therefore, the Data Link Layer shall treat all Frames using NLS as

broadcasted frames.

Application Flags

xxxx: Flags set by the Application Layer, which, depending on the implementation, may impact low level host

behavior. The values are defined in the D7A Application Layer.

34 / 87


4.12.4. Source ID Header

The Source ID Header is present if the En Addr bitfield is set. Its sole content is the Device ID of the Host that

transmits the frame. The usage of VID or UID is based on the VID bitfield in the Flags field.

4.12.5. Target ID Header

The Target ID Header is only present if the NLS bitfield = 0 and the Addressing Option is Unicast. If it is present,

the Data Link Layer shall perform Unicast addressing using the Device ID, which is the headers sole content.

The usage of VID or UID is based on the VID bitfield in the Flags field.

4.12.6. Data Link Layer Security Authentication Data Footer

The only footer present in the Data Link Layer Frame is optional, for DLLS. The usage, size, and value of

the DLLS Authentication Data field is based on the value of the DLLS Code in the DLLS Header. If the DLLS

Header is not present, in no case will be the DLLS Authentication Data Footer, either.

35 / 87


5. Network Layer

5.1. D7A Background Network Protocols

The D7A Networking layer supports one background protocol: D7A Advertising Protocol (D7AAdvP).

Background network protocols are contained solely in Background Frames, as described by the Data Link Layer.

They are receivable via Background Scan, also described by the Data Link Layer. Background Protocol Frames are

of fixed length and contain the following data elements. The Background Protocol Identifier (BPID) field is not

available at the Data Link Layer.

BPID 1 byte Background Protocol Identifier

Payload 2 bytes Protocol Data

5.1.1. Background Frame Structure

Subnet ID BPID Protocol Data

1 byte 1 byte 2 Bytes

Table 5.1.1.1: Data Link Layer fields shown alongside Background Frame Structure

5.1.2. Background Protocol IDs

Background Protocol IDs

ID Name Description

0xF0 D7A Advertising Protocol Used for rapid ad-hoc group synchronization

Table 5.1.2.1: Background Protocol IDs

5.1.3. D7A Advertising Protocol (D7AAdvP)

The D7A Advertising Protocol (D7AAdvP) is a broadcast, transmission-only protocol used exclusively for rapid, ad-

hoc group synchronization. Only Gateway and Subcontroller device classes are permitted to transmit D7AAdvP

protocol frames, but all device classes other than Blinker are required to receive them. This is a process designed

to feed information about a request, that will occur in the future, to Hosts engaged in periodic Channel Scan

Series. Thus, the Advertising Protocol is used most productively when it floods packets onto the network during

the moments before the advertised request occurs. The D7AAdvP must respect guarded/non-guarded channel

rules.

36 / 87


Advertising Protocol Data

ETA

2 Bytes

Number of ti until event, 2 ti

(Big Endian, MSB-first)

Table 5.1.3.1: Advertising Protocol Data Fields and Values

5.2. D7A Foreground Network Protocols

Foreground network protocols are contained solely in Foreground Frames, as described by the Data Link Layer,

and as such they are receivable via Foreground Scan. Foreground Frames are of variable length and contain

different data depending on the protocol. Two Foreground Protocols are currently defined and specified.

Name Description En Addr bit

D7A Mode Network Protocol A fast-querying request-response protocol 1

D7A Mode Datastream Protocol An encapsulation protocol 0

Table 5.2.1: Foreground Protocol IDs

5.2.1. Foreground Frame Vectoring

When transferring frames from the Data Link Layer, the value of the Frame Type field determines which

network layer protocol is used to continue processing the frame.

1. In the D7A Datastream protocol (D7ADP), the En Addr bit of the Frame Type field is clear.

2. In the D7A Network protocol (D7ANP), the En Addr bit of the Frame Type field is set.

5.2.2. D7A Datastream Protocol (D7ADP)

The D7A Datastream Protocol (D7ADP) is a generic data encapsulation protocol designed for maximum upper-

layer flexibility. D7ADP contains no routing or addressing information, so communication must be negotiated by

upper layers or by other protocols (such as the D7A Query Protocol, D7AQP). D7ADP supports datastream

fragmentation and in-order transfer. The maximum size of a single datastream is 63488 bytes, as beyond this

point defragmentation of the datastream cannot be guaranteed.

D7ADP Frame Structure

D7ADP uses a minimally defined Data Link Layer Foreground frame, containing only the Frame Header and

optionally the Data Link Layer Security fields. D7ADP adds a single field of its own, Frame ID, a one byte,

incrementing identifier beginning at 0 and used for datastream fragmentation ordering. The value of the Frame ID

continues to increment until the datastream is completed, regardless of how many packets are required to

transport the datastream (as such, the max datastream size is 63488 bytes).

37 / 87

Figure 5.1.3.1: Example of flooding advertising packets prior to request

Foreground RequestBackground AdvertisingBackground AdvertisingBackground Advertising

Info0

ETA500

Info0

ETA2

Info0

E

dash7 alliance mode draft 02 release

Documents