The DDT2 Protocol

Contents

The DDT2 Protocol

This page describes the protocol that D-RATS uses for all of its communication over the wire.

Introduction

D-RATS uses a single frame type for all of its communication. This provides similar functionality to an ethernet frame, in that it contains a source and destination address, a checksum, a length, etc. It is also surrounded by a header and trailer to assist in synchronization. The frame format also contains some information for multiplexing and type determination that would typically be above the physical layer. For frugality, these fields are pushed into the same frame format.

An important factor in understanding how D-RATS communicates is the notion of multiplexing the channel. Each independent data stream is assigned a "session number", which serves the same purpose as a TCP or UDP port number. Some session numbers are reserved to eliminate compulsory negotiation at startup, but most are negotiated dynamically when a session is established. More detail on this is provided later.

Frame format

The DDT2 frame contains the following fields:

Name	Length (bytes)	Purpose/Meaning
Magic	1	Frame format versioning
Sequence	2	Frame ordering
Session	1	Multiplexing
Type	1	Content type identification
Checksum	2	Error detection
Length	2	Number of bytes in data field
Source	8	Source station callsign
Destination	8	Destination station callsign
Data	Variable	Data payload

A graphical representation of the frame

Header and Trailer

To facilitate synchronization after a bitstream error, each frame is wrapped with a header and trailer. The header is [SOB] and the trailer is [EOB].

Field Descriptions

Magic

The Magic field can have one of the following values and associated meanings:

Value	Meaning
`0x22`	The data field is not compressed
`0xDD`	The data field is compressed with zlib

Frames should be transparently decompressed if their magic number indicates that this is appropriate. If decompression is not available, that frame should be dropped.

Sequence

The Sequence field contains ordering information for data reassembly at the receiver. Reordering may be required when one block of a multiple-block transmission must be re-transmitted. Not all frame types are required to have constantly-increasing sequence numbers. The sequence number may also be relevant within the scope of a single Type as well.

Session

The Session field contains information on how the frame must be demultiplexed by the receiver. See the Session section for more information on how D-RATS uses this field.

Type

The Type field is used by the session management (or higher) layer to determine the data type present in a frame. Some uses for this are to differentiate control and data frames. The meaning depends on the session type, and new session protocols are free to use this field as needed.

Checksum

The Checksum field is the 16-bit CRC checksum of the entire frame. The value is computed with the checksum field set to zero. The algorithm for this can be found in the code, but it is the widely-used XMODEM/KERMIT CRC-16 variant. For more information, see http://homepages.tesco.net/~rainstorm/crc-catalogue.htm and search for "XMODEM" (and skip "X-XMODEM").

Length

The Length field is an unsigned 16-byte count of the number of bytes in the data field.

Source

The Source field contains the uppercase ASCII callsign of the sending station. This may contain a space, such as KK7DS M. The callsign is right-padded with tilda characters (~, ASCII 0x7E). Punctuation and special characters (anything other than A-Z and 0-9) are reserved for special meanings, yet to be defined. Some example callsigns are:

KK7DS~~~
KK7DS M~
N9DN~~~~

Destination

The Destination field has the same formatting requirements as the Source field. A special callsign of CQCQCQ is reserved for use in this field, indicating that the frame should be received by all stations that received it.

Sessions

An important part of D-RATS is the Session Manager. This component provides multiplexing of the channel, as well as session negotiation on behalf of passive session implementation modules. At startup, the following compulsory sessions are assumed to be established with the specified session numbers:

Session Name	Number	Purpose
Control	0	Session negotiation, and ping
Chat	1	General purpose multicast unreliable text exchange

The simplest of these two is the Chat session, which provides a clear text channel for exchange of chat messages and GPS position reports. Although not required, D-RATS does not compress or otherwise encode the data portion of chat session frames. This ensures that the GPS beacons are readable by ICOM radios, and also that the text messages are readable by other applications and terminals which may be listening, but which have no understanding of the rest of the DDT2 protocol.

The Control session is more complex and is covered in the following subsections.