The DASH7 Mode 2 Data link layer contains functionality for:
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.
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.
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|
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|
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|
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.
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.
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|
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.
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.
The Frame Control Field describes attributes and subsequent fields. It applies to the Data Link Layer, Network Layer, and Transport Layer.
|Frame Control Field|
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|
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
|Nonce A||Nonce B||Nonce C|
|16 bits||8 bits||32 bits|
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.
|Frame Integrity Check|
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 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 frames are used for rich protocols that transfer data to and from upper layers. (rest, todo)
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.
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.
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.
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.