View source for Stentofon Data Link Layer

The '''Stentofon Data Link Layer''' protocol uses a ``Sliding Window’’ technique with ``Go Back N’’ flow control. The protocol is very similar to the protocol used in the Inter Card Cage communication (ICCL) internal to the AlphaCom exchange. As the Stentofon Data Link Layer protocol is used in a pointtopoint full duplex communication, address information is unnecessary. The address field in the header of the ICCL protocol is here used to define coding format of the Network Layer data frame.  The total length of the Stentofon Link Layer frame is limited to maximum 128 characters. 

== Transmission Control Characters ==

::<'''Stop Flag'''>	0xF1
::<'''Escape Flag'''>	0xF0
The only transmission control character is the STOP_FLAG used as terminating character of all Link Layer frames. When a STOP_FLAG is received, it indicates that a complete frame has been received. When a STOP_FLAG is sent, the link is free, and more frames may be sent.  The STOP_FLAG byte value has to be unique within the frame. 

Any other character with value 0xF1 must be replaced with an escape sequence consisting of two characters.  If the STOP_FLAG is represented in the header, user information field (payload) or check sum field, the STOP_FLAG is replaced by an ESCAPE_FLAG followed by 0x00. If the ESCAPE_FLAG byte pattern is part of the header, payload or checksum field, it is replaced by ESCAPE_FLAG followed by 0x01. 

The two byte values, if occurring in a frame, are thus transmitted in the following way: 
:0xF1 > 0xF0 0x00 (11110001 > 11110000 00000000) 
:0xF0 > 0xF0 0x01 (11110000 > 11110000 00000001)

== Frame Structure ==

The general structure of the Stentofon Link Layer frame is: 

'''<Header> <Data…..> <BCC> <STOP_FLAG>''' 

Detailed field description:

'''<Header>''' is one 8-bit byte sub-divided into: <Unused> <Encoding type> <Sequence number> <Frame type>

::<Unused>	2 bit
::<Encoding type> 	1 bit, encoding type for the payload data field: <br\>
:::::::0 = binary coded format <br\>
:::::::1 = hexadecimal coded (ASCII) format 
::<Sequence number>	3 bits, giving a sequence number 1 ... 7, starting at 1, counting up to 7, and then starting at 1 again. Used to <br\>
::::::ensure correct sequence of  messages.
::<Frame type > 	2 bits, defining 4 possible frame types: 
:::::::0 (00) = Reserved ICC protocol (Multi-module)
:::::::1 (01) = Information/Message/Idle frame 
:::::::2 (10) = ACK frame 
:::::::3 (11) = NAK frame 

'''<Data….>''' consists of a network layer frame of maximum 125 byte encoded according to <encoding type>, or may be empty.   Data is often referred to as payload.

'''<BCC>'''	Block Check Character, represented as the longitudinal parity of the frame preceding the BCC

'''<STOP_FLAG>''' 0xF1, described above.

== Frame Description ==

'''Encoding type 0''' means that the <Data> field is binary data.
:- Data needs no reformatting.  
'''Encoding type 1''' means that the <Data> field contains hexadecimal data.

:- Data is represented by ASCII characters `0’ ... `9’ and `A’ ... `F’. 

:- Each byte of original binary data is converted to 2 ASCII characters. The data are converted back to binary form before they are sent to the Network Layer. 

:- If the character ` ‘’ ‘ (double quote, 0x22) is received within a hexadecimal message, the rest of the message is uncoded (ASCII text). The ` ‘’ ‘ is stripped off, and its position is handed over to the Network Layer, so that if the message is to be retransmitted, the double quote is reinserted and the ASCII text part will not be coded to hexadecimal. 

:- When a hexadecimal encoding type is used, a CR (carriage return) character is added at the end of the <Data> field to increase readability. This character is also stripped off before the data is sent to the Network Layer.

=== Information/Message Frame ===

The Information/Message Frame type (type 1) typically will have a Network Layer Frame as payload. 

=== Idle Frame ===

A special version of the message frame is the Idle Frame, defined by a <Data> field containing a Network Layer Frame with only the address header (no payload message code and parameters).
 
When no data are ready for transmission for a given time, idle frames are transmitted at regular intervals to check the quality of the data channel, and also to detect interruption of the channel (watchdog function). Idle frames are also used for resynchronization of sequence numbers. Idle frames are acknowledged in the same way as data messages. The format of the idle frame is as follows, where the size of each field is 1 byte: 

: '''<Data> = <source node><source device><destinatin node><destination device>'''
<br\><br\>

=== Acknowledge Frame ===

The ACK frame (type 2) is used to acknowledge frames that are correctly received. The sequence number is derived from the frame it acknowledges. 

=== Negative Acknowledge Frame ===

The NAK frame (type 3) is used to request for retransmission of a given message. 

ACK and NAK frames will have priority for sending before any other messages.

== Link Control, Supervision and Error Recovery Procedures ==

As the protocol may be used on intercontinental links with long delays (up to 500  600 ms roundtrip delay on a satellite |hop), special precautions must be taken to secure transmission quality without introducing too long delay in the forward path when conditions are good. Therefore, a sliding window mechanism is used to maintain correct sequencing of messages in case of transmission errors. 

=== Sliding Window Protocol ===

A sliding window protocol with sending window size 7 is used. This means that 7 messages may be sent on the link before a response is required for any of them. At the receiving end, window size 1 is used, i.e. if a message is lost, the lost message plus all messages after the lost one must be retransmitted. 

'''At the transmitting end''', the Message Frames are numbered with a sequence number and inserted into a window buffer when sent, and removed when acknowledged. Before a new frame is sent, the previous frame must be completed (STOP_FLAG sent). When the buffer is full, transmission of new frames has to wait until an acknowledge is received. The Acknowledge Frame carries the same sequence number as the frame it acknowledges. If an acknowledge is received for a frame that is not the oldest one in the window buffer, it means that an Acknowledge Frame is lost or skipped at the receiving end, and the acknowledged frame and any older frames are removed from the buffer. If a NAK frame is received, the corresponding frame plus the newer frames (if any) are retransmitted, and the older frames are removed from the buffer. 

'''At the receiving end''', incoming frames are checked for errors, and if OK, an ACK frame with the same sequence number is transmitted back to the sender. The frame is then decoded to binary form (if necessary) and sent to the Network Router. If an error is detected, either in the current frame or if there is a frame sequence number missing, NAK frame is sent back to the sender with the sequence number of the frame with error or missing. The receiver then discards all received frames until the one with the correct sequence number is received, and normal operation is resumed.  Since an Idle Frame is only transmitted when the window buffer is empty, it is used to synchronize sequence numbering at the other end of the link. After a reset, the transmission always starts with at least one Idle Frame. 

=== Link Supervision ===

If there is no response from the other end of a link within a given time (calculated from the normal delay of the link) after the last frame is sent, the contents of the window buffer is retransmitted. If no response is obtained after 2 attempts, the window buffer is cleared, transmitter reset, and Idle frames transmitted with specific intervals. If contact with the other end is reestablished, an OKmessage is sent to the Network Router so that data communication can be resumed. 

=== Simple implementation ===

An external computer can run with a sliding window size of one, i.e. for each message you send you must wait for the acknowledge from the AlphaCom.  Sending/receiving NAKs can also be skipped as both ends always must have (fast) timeouts to handle errors.