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.
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.
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.
|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)|
|Message Begins||Message Ends||Chunk Continues|
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 is the number of bytes in the record, 0-255.
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.
|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)|
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.
Each ALP (specified by ALP ID) has one or more commands (specified by ALP command), and these have various attached data payloads.
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.