Indigresso Wiki

Open Source Stuff for DASH7

User Tools

Site Tools


dash7_mode_2:applayer

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

dash7_mode_2:applayer [2011/10/03 18:39]
jpnorair created
dash7_mode_2:applayer [2012/03/01 14:28] (current)
jpnorair
Line 1: Line 1:
 ====== Application Layer ====== ====== Application Layer ======
-DASH7 Mode 2 specifies a loose wrapper format, based on NFC NDEFthat standardized or proprietary ​application layer protocols ​may use to integrate themselves into automated ​lower level Mode 2 features (such as 5-way M2QP handshaking)  ​Additionally, there is an Application Shell option within M2QP that allows any sort of application ​payload to be encapsulated into a DASH7 Mode 2 frame.+Various types of application layer protocols can be used with [[dash7_mode_2:​main|DASH7 Mode 2]].  Most notably[[http://​en.wikipedia.org/​wiki/​User_Datagram_Protocol|UDP]]-based application layer protocols can be layered ​on top of M2QP UDP-shell command formatted framesand [[http://​en.wikipedia.org/​wiki/​Transmission_Control_Protocol|TCP]]-based ​application layer protocols ​can be layered on top of M2QP datastream command formatted frames. ​  
 + 
 +=== Built-in Application Protocols === 
 +Additionally,​ there is an [[http://​www.nfc-forum.org/​specs/​|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:​alpapi|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 messageelse 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:​alpapi&#​m2alp_design|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     | [[alp_null|Null Protocol]] ​       | ACK/​NACK ​               | Does nothing, can be used as means of ACK         | 
 +|  0x01     | [[alp_file|Filesystem Protocol]] ​ | Veelite Functions ​      | File Read/​Write/​Modify commands ​                    | 
 +|  0x02     | [[alp_sensor|Sensor Protocol]] ​   | ISO 21451-7 based       | Sensor configuration via ISO 21451-7 ​               | 
 +|  0x03-0F ​ | Implementation-defined ALPs       ​| ​                        | e.g. defined in [[opentag:​main|OpenTag]] ​           |                                 
 +|  0x10-1F ​ | [[alp_crypto|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 14:28 by jpnorair