Indigresso Wiki

Open Source Stuff for DASH7

User Tools

Site Tools


dash7_mode_2:applayer

Application Layer

Various types of application layer protocols can be used with DASH7 Mode 2. Most notably, UDP-based application layer protocols can be layered on top of M2QP UDP-shell command formatted frames, and TCP-based application layer protocols can be layered on top of M2QP datastream command formatted frames.

Built-in Application Protocols

Additionally, there is an NDEF-based application layer protocol that can be layered on-top of datastream command formatted frames. This final type is the “built-in” Mode 2 Application Layer Protocol (M2ALP). DASH7 Mode 2 defines several M2ALPs.

M2ALPs

As mentioned, M2ALP's are designed from NDEF, so they have relaxed requirements for the lower layers. Mode 2 Application Layer Protocols are used primarily via the Datastream functionality of Mode 2, but they may also be used in a device API layer (consider, for example, OpenTag's MPipe). New ALPs may be added in the future to address new features.

All Application Layer Protocols abide by a data structure based on records, shown below. Records may be transmitted individually or in a batch series. ALPs typically use explicit data-movement language rather than an implicit request-response methodology. The format is based on the NFC NDEF format, although simplified.

M2ALP Record Structure

Record Flags Record Length ALP ID ALP Command ALP Record Data
1 Byte 1 Byte 1 Byte 1 Byte (N-4 Bytes)
(see flags spec) (N) (see ALP ID list) (see ALP spec) (see ALP spec)

Record Flags

Message Begins Message Ends Chunk Continues
b7 b6 b5 b4 b3 b2 b1 b0

M2ALP record flags are a subset of the flags specified by NDEF. The M2ALP/NDEF spec can accept multi-frame data exchange. It uses the following fields to manage the data fragmentation aspects.

Message Begins (MB) is 1 at the first frame of the message, else 0.
Message Ends (ME) is 1 at the last frame of the message, else 0.
Chunk Continues (CC) is 1 when there is fragmentation of the data payload across two or more frames.

Record Length

Record Length is the number of bytes in the record, 0-255.

ALP ID

ALP ID refers to a specific ALP. There are up to 255 supported ALPs. Only a few exist presently within the DASH7 Mode 2 spec, although many are implementation specific. Check also the OpenTag list of ALPs, which specifies some ALPs used as device APIs. When interpreting M2ALP as a subset of NDEF, the ALP ID is the first of two ID bytes.

ID Name Commands Include: Description
0x00 Null Protocol ACK/NACK Does nothing, can be used as a means of ACK
0x01 Filesystem Protocol Veelite Functions File Read/Write/Modify commands
0x02 Sensor Protocol ISO 21451-7 based Sensor configuration via ISO 21451-7
0x03-0F Implementation-defined ALPs e.g. defined in OpenTag
0x10-1F Security Protocols Key Exchange Steps Security Key Exchange Protocols (in development)
0x20-7F Reserved for Future Use (RFU)
0x80-FE Implementation-defined ALPs
0xFF Reserved

ALP Command

ALP command is a feature specifier of a given ALP. For example, the Filesystem ALP has commands for read, write, create, delete, etc. When interpreting M2ALP as a subset of NDEF, the ALP ID is the first of two ID bytes.

ALP Record Data

Each ALP (specified by ALP ID) has one or more commands (specified by ALP command), and these have various attached data payloads.

Non-Built-in Application Protocols

As mentioned, most types of UDP or TCP-based application protocols can technically be layered on top of DASH7 Mode 2 transport and network layer protocols. Additionally, some other types of application layer protocols could be used, as well. The protocol's addressing requirements must be met by the abilities of DASH7 Mode 2 lower layers, but often this is possible directly or via some type of frame translation at a gateway.

dash7_mode_2/applayer.txt · Last modified: 2012/03/01 20:28 by jpnorair