MARS-A

MARS-A protocol for MORSE

(MARS rev.4)

version 7.45

10/10/2008

1. Introduction

MARS-A is a full duplex protocol with 32bit long addresses, with
error detection (based on 16 bit checksum or 16 bit CRC) and with error
correction. MARS-A could perhaps be characterised as the most user
friendly of the network protocols in the MORSE system. With simplicity on
the user interface, it offers access to all services in the MORSE data
network system. Of course, the user has the option to choose whichever
subsets to work with from the protocol.

The obsolete MARS-U (MARS rev.2) protocol (equipped with 16bit long
address) is replaced by this new protocol. Longer address space is needed
mainly for mobile applications in the MORSE network. The difference
between this protocol and the obsolete mars-u protocol is that of longer
address and different frame type.

H2N bitset to 1 if the transmitter is DTE=Host,
A/32 is the destination addressset to 0 if the
transmitter is DCE, A/32 is the source address

L/1

local mode

R/3

reserve

N/3

net number

A/32

destination or source address according to the parameter
H/1

DATA

user data, length is S – 6 [byte]

F/8

stuffing used to achieve an even size of the frame

BCW/16

checksum

The detailed description of the format follows.

2.1. The physical layer

The physical layer is given within the possibilities of the
hardware in the MORSE system. In principle, MARS-A can operate in any
arbitrary channel configuration. The standard assumption is for
asynchronous communication between DTE-DCE on a duplex V.24 interface,
using only data signals RXD, TXD, and ground (3-wire communication).
Communication at higher speeds and at greater distances can use the
RS422 interface. Synchronous communication is only possible on the V.24
interface.

2.2. The link layer

The link layer protocol can operate on an arbitrary physical
interface enabling full duplex asynchronous communication with 8 data
bits. It is fully transparent for data transfer, consequently
flow-control Xon/Xoff cannot be used. It is also not necessary to use a
hardware handshake as control of data flow is secured by the protocol
itself. Due to its simplicity, this link layer protocol is useful for
links with a negligible rate of error. The frame always has an even
number of bytes. A set it is composed of a 16 bit label, a data block
(always an even number of bytes), and a 16 bit control word
(BCW).

Data Frame

Stuffing – byte with an arbitrary value used to achieve an
even size of the frame. This supplementary byte is included in
the BCW.

BCW/16

Block Control Word – Checksum mode is counted as
lengthwise parity along 16 bit words in the whole frame (using
XOR), default state. CRC-16 mode done according to RFC 1662 (the
same as in PPP protocol) can be configured in the protocol
parameters.

Label – 16 bits (1 Word) divided as follows:

| FT/2 | FN/2 | R/1 | S/11 |
11 00 0 000 0000 1001 ( = 0xC009 )

FT/2

Frame Type

11 – User Frame (normal mode).

10 – Control Frame (ACK…).

01 – Reserved for internal use.

00 – Link Layer Service Frame.

FN/2

Frame Number. Numbers are not incremented for repeated
frames.

R/1

Repeat bit

0 – the frame transmitted for the first time

1 – repeated frame

S/11

Link layer data size (LLD), length of data field in bytes,
not counting the label, stuffing and the BCW.

Packet numbering is not compulsory. Only the lowest three bits
from the number are transmitted. The entered number is transported
to the address, and can serve to control the order of the delivered
packets (the MORSE network does not guarantee a perfect order for
packets).

The address is the source address (Host receives a packet) or
the destination address (Host transmits a packet). The packet goes
in the CU through the CNI (Channel to Node Interface), which maps
the user address space to the MORSE address space e.g. by a
mask.

The maximum allowable length of data in the MORSE network
layer is 1626 bytes. Longer packets are not defined within the
system. The optimum packet size for MORSE system is 200-400
bytes.

2.4. Packet Types

The Packet type composition:

|U/1|B/1|R/1|subt/5|

U/1

link security bit

B/1

broadcast (multicast) bit

R/1

reserved

subt/5

subtype

The subtypes of packets can be divided into 5 groups:

User packets

Request for services

Service reports

System reports

Special packets

Here we describe the most important MORSE packet subtypes:

09h – USER DATA

The basic type of packet for transporting data from source
to destination.

0Ah – PROT DATA

This type of data is designed for data flow control in the
user protocol. The service of both preceding types of packets in
the MORSE network is equivalent. Packets are sent to the
destination with the path and priority settings at the
participants addresses. An error message is sent to the original
sender if a packet is lost, but the packet carrying this error
message can of course be lost as well, and in this case
silently.

10h – SERVICE REQUEST

Request for a MORSE service.

12h – SERVICE REPORT

Report from a MORSE service.

0Ch – PACK ERROR REPORT

MORSE error message. First word is the Error Number, the
rest of the message holds more detailed information about the
network error. Generation of these errors can be turned off and on
for the whole network.

Some of these Error Numbers are here:

1 – PACKET_NOT_CONFIRMED

2 – STORE_TIMEOUT

3 – NO_CHANNEL_ASSIGNED

4 – ACCESS_TIMEOUT_ERROR

6 – WRONG_PACKET_FORMAT

7 – DEST_PROT_MISSING

8 – WRONG_PATH

9 – WIRE_LINK_FAIL

2.5. Byte order

All 2-byte and 4-byte values are transferred in normal order. The
highest byte is transmitted first, and then the lower ones (beware, as
the Intel processor format is typically the opposite).

The repeatedly transmitted packet from SCC3, because the ACK
on SCC3 is missing.

3.3. Next examples.

In the next example we send a request for the software version in
a radio modem and we receive answers. Packet type is 10h or12h, request for system software version is formulated as
three bytes E0277600 (or E027 followed by the binary coded software
version in the case of the answer). Address of the radio modem690F0501 serves here as destination and source
also. The protocol is configured in checksum mode.

3.5. Support for dial-up on GSM or telephone modems

The transfer is designated to occasional use, e.g. for the
configuration changings in the distant communication unit (CU).

HW arrangement and the parameter setting is similar, like at the
connection with async. link, see the example
in the MORSE Guide 1. The full RS232 cable for connection between SCC
and the phone modem is recomended. In the case of using 3-wires cable
connect the DTR and DSR pins on the phone modem. In the telephone modem,
there is necessary set the parameter AT&K0 (the data flow control
off) and ATQ0, ATV1. The autoanswer function can be ON, however it is
executed from CU also. Considering the various characteristic of the
phone modems it is necessary to test the configuration in
advance.

The speed 19200 bit/sec is sufficient for fixed lines (can be to
57600), for GSM set max 9600. It should be in any case equal to the
speed of telephone modem.

With help of SPe 0t set the parameters of protocol
MARS-A on both CU equal:

in calling CU activates the function of phone connection, in
called CU activates AA (autoanswer)

t(i)meout:30

switches out the phone connection at longer dellay, than 30
seconds

It can be set either to 0 (the function is off) or the time longer
then 30 sec, because after beginning of connection the holding packets
are send every 20 sec and this at normal circumstances prevents the
termination of connection.

STARTING OF CONNECTION:

Fulfil the telephone number (t)el. :
to the parameters MARS-A protocol in the same form, like at telephone
call:

The telephone modem makes the connection, which is visible in this
way:

the LED named OH (Off Hook) is on, the modem started
work

the modem dial the number (audible)

if the start of connection with the opposite modem was
succesful, takes place the connection parameter negotiation, which
looks like the variable tone for pair of seconds. After succesful
parameter negotiation the LED CD (Carrie Detect) is on

from this moment it is possible to comunicate between both
radio modems through phone line, e.g. send the ! command and change
the configuration in the opposite CU

After the automatical sending of the holding packet, the address
of opposite CU appears in the MARS-A parameters like “Opposite
retranslation address”. When we need cancel the connection, we do
Init with empty string(t)el.: in
MARS-A parameters.

Check the cancel of connection, which shows like switching off CD
and OH. In case of any problem we stop the connection by phone modem
switching off and on. We choose from main menu SPe0t and
check, if the parameter (t)el.: is
empty. In other case the phone number would be dialled at next start of
CU.

3.6. (R)emote dial-up access

This remote access via the telephone modem replaces the connection
using the service cable. Configuration:

PC -- TM ---telephone network --- TM -spec.cable- CU

PC

PC with OS Linux and programrr_setrdial

TM

telephone modem

spec.cable

RS232 crossed cable, in which pin CD is connected to pin DTR
at the opposite end of the cable

CU

MR400 series CU, fw 746 or higher, default configuration
with the exception of parameter(R)emote
dial-up :ON

A remote CU is connected via the serial port to the telephone
modem using a “Special dial-up cable”. The CU can be set up with default
configuration, the SCC used has protocol MARS-A set up with parameter(R)emote dial-up:ON . It is a good idea to set up the
parameter idle to a higher value, for example SPe
2i RX (i)dle:100.

Set up parameters containing the telephone number and port in
program rr_setrdial. After starting the program sets up a
connection with the destination TM and then starts
rr_setr.

After connection TM-spec.cable-CU the CU starts to send on wires
each 30 sec the ASCII command autoanswer ATS0=1. The TM sets the
communication speed according to CU. When PC through rr_setrdial calls
the distant TM, then TM accepts the call, sets CD=1 and in this way
appears DTR=1 on CU. Only now at DTR=1, the CU can send data via
it’s TM into distant application rr_setr.

Now we can work with Setr in the destination CU in the same way as
if connected via the service cable. We are not connected via SCC0, as is
the case with the service cable, but via SCC used for “special dial-up
cable”. Connection of the cable:

Opposite retranslation address:00000000 This is
used in the store and forward relaying mode when two CU are
connected by wires, the opposite CU address appears automatically
after establishing the connection.

(l)

OFF = normal state

ON = local retranslation mode for the service purposes, the
communication with a remote unconfigured CU via the
MARS-A protocols, see the MORSE Guide 2, chapter Local
mode connection

(a) – ACK timeout – the time after transmitting a data frame in
which the transmitting station waits for an ACK frame. If the ACK does
not arrive, the frame is repeated.

(r) – number of repeats – if the number of repeats is exhausted
and the ACK timeout expires, the network layer is informed that the
packet is lost.

The state diagram on the transmitting side of the link layer
protocol has only two states:

The “quiet” state, and the “waiting” state
while expecting an ACK frame. Immediately after receiving a demand to
transmit a data frame, the “quiet” state passes into the
“waiting” state in order to receive the ACK. After receiving
the ACK, or if the timeout expires after the last repeat, the link layer
protocol goes back to the quiet state. While in the waiting state, the
protocol declines all requests to send a frame.

The receiving side reacts instantly after receiving a correct data
frame by sending an ACK frame. For a correct frame, the ACK is sent
immediately after it is finished, so the ACK timeout must be set at least
equal to the time for transmitting the longest frame. An incorrect frame
is silently discarded.

Between two characters in the frame, there cannot be a greater delay
than is set in the idle parameter. A split frame is evaluated as an error,
even if this occurred due to the hardware handshake.