Indigresso Wiki

Open Source Stuff for DASH7

User Tools

Site Tools


Data Link Layer

The DASH7 Mode 2 Data link layer contains functionality for:

  • Basic frame architecture
  • Basic filtering
  • Channel scan control
  • Low-Level dialog control (i.e. request-response management)
  • Low-Level management of Collision Avoidance routines (CA)
  • Low-Level cryptography (Data Link Layer Security)

Design Philosophy: Soft-MAC

The DASH7 Data Link Layer (often referred-to as MAC layer) is very sophisticated, but it is also very fluid – that is, not rigid. DASH7 has been architected to run on silicon typical of 2010-2020 design themes. All radio transceivers these days are using digital demodulators and fast, small RISC cores to manage the low-level protocol. We embrace this trend through our DASH7 “Soft MAC.” We call it a “Soft MAC” because it is not easily synthesized as classic logical gates, but it can be implemented efficiently on a small CPU.

Core Concept: Integrate and Reduce

Architects may notice that the DASH7 Mode 2 is organized differently than IEEE 802 equivalents are. Due to the way 802 specifications are organized in an administrative fashion (i.e. there is a hard requirement that they only span OSI layers 1 and 2), they tend to exhibit large redundancies between layers. Redundancy is undesirable for a system like DASH7, which needs to be small, light, and efficient.

Instead, DASH7 Mode 2 is a monolithic ISO standard and not subject to the administrative requirements of the IEEE 802 group. There is no duplication of resources between MAC, Network, and Transport layers, and data is passed between them with minimal barriers. In 1970, a network interface was implemented across many computers, so it made sense to distribute resources. In 2013, it is ridiculous to be married to such primitive ideas: the transport layer (L4) is often the division line between transceiver and server.

Basic Frame Architecture

DASH7 has two kinds of frames: Background Frames and Foreground Frames. Both have some similarities in their headers, but mostly they are different. Background Frames are 7 bytes fixed length, and Foreground Frames are variable length up to 256 bytes.

Length Link Ctl TX EIRP Subnet DLL Hdr Payload DLL Footer CRC16 Codeblock
Bytes 1 1 1 1 1-21 N 4 2 K
Range 0-255 0-255 0-127 0-255 See Below (opt) (opt)
Usage FG-only All FG-Only All FG-Only All FG-only

Common Frame Elements

The following fields are available in both Background and Foreground Frames.


TX EIRP Bitfield
EXT -40 + (b6:0 / 2) = Encoded TX EIRP value in dBm
b7 b6 b5 b4 b3 b2 b1 b0

TX EIRP byte field indicates the estimated, radiated power of the transmission in dBm. The transmitter of the packet must declare this value accordingly during each frame transmission, depending on its power setting. The coding is: -40 dBm + (X/2). Thus, the maximum radiated transmit power allowed by DASH7 is: -40 + (127/2) dBm = 23.5 dBm. In order to pass DLL filtering, the difference of the TX EIRP by the calculated received signal strength (RSSI) of the incident packet must be above a linkloss threshold value stored as a DLL parameter.

The most significant bit of the TX EIRP byte field is an extension bit. In Foreground Frames, it indicates that this frame is a non-terminal frame in a multi-frame-packet (see more below). For Background Frames, it is presently ignored.


Subnet Byte Field
Subnet Specifier Subnet Mask
b7 b6 b5 b4 b3 b2 b1 b0

The DASH7 Subnet is a concatenation of two nibbles. The subnet of the transmitted packet is compared with a stored subnet value on the receiver, stored as a DLL parameter, as part of DLL filtering. The most significant nibbles (Specifiers) must match exactly. The Local (on receiver) and Remote (supplied in transmitted frame) Mask nibbles are logically and-ed. If L & R = L, then the Mask passes. Thus, when 1111 (15) is transmitted, every device will pass it. When 0000 (0) is transmitted, only devices with local subnet nibble 0000 will pass that reception.

CRC 16

DASH7 uses the CRC-16 Polynomial x^16 + x^15 + x^2 + x^0 (0x8005). This is the best standardized code according to recent, brute-force numerical research, matching the performance of the best theoretical 16 bit CRC code for packet lengths typical in DASH7. OpenTag contains a reference library for implementing this CRC algorithm in software, although frequently this code is available in HW as well.

Foreground Frame Elements

The following fields are available only in Foreground Frames.


Non-inclusive number of bytes in the frame, 0-255.

A bitfield containing some control and integrity information, needed by the data link layer to appropriately process Foreground Frames.

Link Ctl Bitfield
FrCont RS-Code 0 CRC5 field
b7 b6 b5 b4 b3 b2 b1 b0
  • FrCont shall be set when there is a frame following contiguously with this frame. Implementations that feature multiframe packets (an optional feature of DASH7) must honor this bit and take the necessary measures to buffer the next frame when this bit is set.
  • RS-Code shall be set when there is a “Codeblock” field present in the foreground frame. The Codeblock is indeed a Reed Solomon codeblock computed over all frame bytes prior to the Codeblock field.
  • b5 shall always be transmitted as 0.

The CRC5 field is computed over 10 bits: the Length byte (8 bits) concatenated with the FrCont and RS-Code bits. The CRC algorithm in use is CCITT G.704 standard, x^5 + x^3 + x + 1 polynomial. Reference code is available with OpenTag versions 0.5 and up, within the encoder module.

In order for frame CRC (CRC16 in DASH7) to work reliably over a variable-length byte-field, the length value must be protected by its own checksum or CRC. This is the purpose of the CRC5, and why it is used with foreground frames (variable length) but not background frames (fixed length). If the CRC5 field fails, the receiver driver can terminate the reception of a packet immediately.


The “Codeblock” is an optional Reed Solomon parity block. The bytes prior to the codeblock (n) are encoded by an RFU reed solomon code, using an 8 bit field size, to yield (k) parity bytes.

DLL Header

The DLL Header is only included in Foreground Frames. It is a dynamic length field – control fields in the header will specify the extent of the remaining fields. See the expanded section below for detailed information about the subfields of the DLL Header.

The DLL Footer is used only when Data Link Layer Security is enabled. It is always 32 bits (4 bytes), and it contains authentication information needed by AES128-CCM.

At minimum, the DLL is a single byte, just the Frame Control field. The additional, optional fields are: DLL Header, DLLS IV, Dialog Control, Source Address, Target Address.

Frame Control Field

The Frame Control Field describes attributes and subsequent fields. It applies to the Data Link Layer, Network Layer, and Transport Layer.

Frame Control Field
Listen Crypto VID EXT Route Addressing
b7 b6 b5 b4 b3 b2 b1 b0
  • “Listen” shall be set in requests when the requesting-host requires that responding devices listen for a subsequent request immediately following the response window. If the “Listen” bit is set in a response, it shall be ignored.
  • “Crypto” 2 bit field specifies how the frame uses encryption
    • 00 specifies the frame uses no encryption
    • 01 specifies the frame uses NLS (Network Layer Security) which includes the NLS header following the Source Address. In other words, the Data Link Layer treats all frames with NLS as broadcast frames.
    • 10 specifies the frame uses DLLS (Data Link Layer Security), which includes the DLLS header, and that the Root User shall be authenticated.
    • 11 specifies the frame uses DLLS, like above, but that the Main User (or simply “User”) shall be authenticated.
  • “VID” shall be set when the Foreground Frame addressing must use Virtual ID addressing (16 bit) rather than Unique ID addressing (64 bit), for the Source Address.
  • “EXT” shall be set when a Frame Control Extension Field follows immediately the Frame Control Field. At present, the Frame Control Extension Field is RFU.
  • “Route” shall be set when a Network Layer Routing Header is included in the Network Layer section.
  • “Addressing” is a 2-bit subfield that describes the type of DLL addressing, Stream, Broadcast, or Unicast. The Transport Layer implements more advanced types of addressing on top of the DLL Addressing.
    • 00 is Stream, which includes neither Source or Target Address fields. Stream frames use M2DP network protocol, and they must never be the first frame in a packet.
    • 01 is Broadcast, which includes a Source Address only.
    • 10 is Unicast, which includes a Source Address and Target Address.
    • 11 is Unicast with VID, which is the same as normal Unicast, but it uses 16 bit VID instead of 64 bit UID for the Target Address.

Session Control Fields

Session Control fields include the Frame Control Extension Field, which is not specified and not existent at present, and the Dialog ID field. The Dialog ID field is an integer, 0-255, that shall be saved in each host when a session is created, and then incremented each time a session dialog is continued. A session shall continue as long as the LISTEN bit is set in each dialog request.

Session Control Fields
Frame Ctl Extension Dialog ID
8 bits (Optional) 8 bits
(RFU) 0-255

DLLS Fields

DLLS is specified entirely in the Frame Control Field. There are two main options: DLLS with authentication of Root, and DLLS with authentication of User. DLLS always uses AES128-CCM

DLLS Header
Nonce A Nonce B Nonce C
16 bits 8 bits 32 bits
Mandatory Optional Optional

The DLLS Header is a variable length field that is 2, 3, 6, or 7 bytes. Nonce B is present only when EXT in the Frame Control Field is 0. Nonce C is present only when Addressing is NOT Unicast and when the Stream bit is NOT set. These nonces are combined with other data to generate the cryptographic initialization vector (IV), and their values should be generated using cryptographic best-practices.

DLLS Footer
Frame Integrity Check
32 bits

The DLLS Footer follows the DLLS payload, and it goes right before the CRC16 field. It contains a 32 bit field generated by the AES128 CCM encryption process, and then used by AES128 CCM authentication process to assure the authenticity of the encrypted frame.

Background Frame & Protocols

Background frames are used for special notification and synchronization protocols, deeply integrated into DASH7 MAC, networking, and session management. The only presently implemented background protocol is the Advertising Protocol. (rest, todo)

Foreground Frame & Protocols

Foreground frames are used for rich protocols that transfer data to and from upper layers. (rest, todo)

Basic Filtering


Channel Scan Control


Low-Level Dialog Control


Low-Level Collision Avoidance Management


Low-Level Cryptography

Mode 2 specifies AES128-CCM as the sole provider of Data Link Layer Security (DLLS). AES128-CCM provides strong cryptography as well as authenticity – that is, making sure the encrypted data hasn't been fraudulently modified and retransmitted by a “man-in-the-middle.”


DLLS is not designed to be flexible, it is designed to provide extremely high security without incurring much data overhead. If you want a flexible security model more like the type used by ZigBee SE 2.0 or IPsec, Mode 2 offers Network Layer Security (NLS) for that purpose. Generally speaking, DLLS is more secure, though.


128 bit Keys

DLLS uses AES128 with 128bit keys. The keys could be made longer, but due to the typically short dwell time and extremely low duty cycle typically employed by Mode 2 Endpoints, there is not generally sufficient time to successfully attack a Mode 2 device using non-intrusive means. For example, due to the low duty cycle, the number of communication attempts required to crack a device's key could take years to complete even when a generous amount of a-priori knowledge is available to the malicious party.

Non-Aligned Data Support

Mode 2 uses a mostly-normal implementation of the AES128-CCM block cipher. The only difference is that it accommodates non-128bit-aligned payload fields. It does this by implicitly adding the first 16-X bytes of the encrypted payload to the last block of the message, where the last block is X bytes in length. These bytes are then stripped during decryption.

Completely Obscured Addressing

When using DLLS to encrypt a frame, the addressing information is completely encrypted. Therefore, on unicasted packets the recipient must decrypt the addressing information in order to resolve the source and target addresses. This provides a high level of confidentiality. A device may be configured during runtime to honor only DLLS encrypted frames – and not unencrypted frames – if extreme confidentiality and security are required.

Data Elements used by AES128-CCM

  • Initialization Vector
  • Frame Integrity Check


dash7_mode_2/dll.txt · Last modified: 2014/02/14 12:43 by jpnorair