AlphaNet Data Protocol

Introduction

To the reader

The purpose of this document is to specify the Data link, Network and Application layer of the AlphaCom Data Protocol.

• The protocol is used for communication in an AlphaCom Network that may comprise several AlphaCom and TouchLine exchanges.
• The protocol is also used between the AlphaCom exchange and external devices, such as Remote I/O boxes, PC based Control Handler systems etc.

The Data Protocol is made generally available from software version AMC 06.00. Previous AMC softwares are NOT compatible with this protocol document.

Word list

The following concepts are commonly used in the document:

• Module: One AlphaCom “card cage”, contains up to 26 circuit boards (such as ASLT, AMC, APC, AGA).
• Exchange: Up to 4 AlphaCom modules interconnected in a master/slave (MultiModule) configuration. One of the modules plays the role as a master, while the other modules are slaves. Communication with the world outside (if other devices are connected) is via the master.
• Node: The address of an Exchange. If several exchanges are interconnected (via the AlphaCom Data Protocol), then each exchange will have a unique node number.
• Device: Examples of device types are AlphaCom module, RIO, AlphaPro, Control Handler. All such devices have a unique device address when interconnected. The AlphaCom and AlphaPro have fixed device address, while the device address of e.g. a RIO is configured (inside the RIO) for the particular application.

History - the MPC protocol

The TouchLine exchanges had a simple data protocol, initially output_only to send information to Intelligent Stations (LWT). The protocol was readable ASCII, in a broadcast mode, and no checksum. It was debugged by hooking up a VT100 terminal. Later on a data command input was added (which had a different format from the output messages).

The protocol was used for several purposes:

• Station emulation, i.e. digit dialing, M-key, handset, C-key (LWT, ITS, CRM, MLH) Monitoring of events related to this station (dialing to display, conversation partner, transfer destination, call request etc.)
• Monitoring of events related to many stations in the exchange (busy, program, line errors) Presented on DAKs (ITS) or screen (CHS)
• Additional functionality for the exchange, where an external computer would look for certain station actions, and take control from there (SVM)

The exchange has some functions purely for data communication, e.g. directory numbers with DigitDataTransmission ref-info which did nothing except sending out station keypresses.

Also, the data command X re-transmitted the incoming data on the broadcast output, thus allowing different data devices to communicate via the exchange (SVM updated DCB absence info).

The AlphaCom supports a subset of the MPC protocol for backward compatibility. This allowed some TouchLine generation equipment like PNCI, MLH and CRM to be used with the AlphaCom.

The present and future - the AlphaCom / AlphaNet protocol

When the AlphaCom was designed, a decade had passed since the MPC protocol was designed, and it was decided to make a new protocol with modern properties:

• Binary format for speed. Readable ASCII hex format can be used as an alternative for easier debugging.
• Data link layer with message checksum for reliability, and with acknowledgment and re-transmission of erroneous messages.
• Network layer for routability when several exchanges are connected.
• Variable length fields and optional fields so that the protocol can be used also in future systems with different requirements regarding number of digits in addresses, station numbers etc.
• A systematic way of addressing exchange resources both as directory numbers and physical addresses.
• Addressed messages. Commands are addressed to a specific device, and response is returned to the device issuing the command only. In addition, there is a few status broadcast messages.
• Addressed messages can be routed in a network. The input and output messages have identical frame format, and thus can be sent via transit exchanges. The same protocol is used both to control a single exchange, and as the AlphaNet protocol.

Message example

Here is a HEX coded example of a message with network layer header and application data. This is basically what you send to the exchange in the “simple link layer” format. We assume that you use exchange node 01, the PC is device 01, and that there is a station 107 and 102. The message DIAL_DIGITS looks like this, with spaces between fields for clarity only:

Network        Application   Application Message 
layer header   header        parameters    _         
0101 0141 01   41 1234 0050  3201107F 20102F
Src  Dest Hop  Cl Ref  Msg   P1       P2
dev  dev  cnt  ss      id    Station  Digits to dial

Data Link Layers

A more detailed description of each link layer can be found in Appendix.

The data link layer transports data between two “boxes”. It’s not addressed as there is only one box at the other end (except when a RS485 bus is used). Most of the data link layers offered has reliable transmission, i.e. either a message is delivered error-free, or the system reports a device error.

Note that all link layers are capable both to connect local devices, and exchanges in AlphaNet! The “payload” messages going between applications have traditional headers and trailers added by link layers. This means that the byte stream observed with a data monitor on the physical wires in principle looks like this:

 <Network header> <Application message> 

ISO 1745 Link Layer

This is an old multi-drop protocol also used e.g. by the wireless pager protocol ESPA 4.4.4 A master polls one device at a time, and messages are transmitted one at a time with checksum and timer supervision, and possibly one or more re-transmissions.

The AlphaCom have two alternative physical connections:

• Point-to-point, typically short range via RS232 to a single external device (RIO or PC).
• Multidrop, up to 1 km on RS485 to 1 to 10 devices (RIO).

The ISO protocol uses a number of reserved control characters, so the message payload is always ASCII HEX. The polled, half-duplex nature of the protocol plus the HEX coding makes it fairly slow. On point-to-point the exchange polls for input messages only once per second!

Stentofon Data Link Layer

This is a AlphaCom proprietary protocol with so-called sliding window. It’s used both internally in a multi-module exchange (called Inter Card Cage Link, ICCL), and between exchanges in AlphaNet.

Sliding window means that the transmitting box can send up to 7 messages before receiving acknowledge to the first one. If a message is lost, the lost message plus all following it in the window must be retransmitted.

The messages are normally binary coded (but if you send HEX to the exchange, it will also answer back in HEX). The full-duplex sliding-window operation means that the application can send messages very rapidly in both directions.

Note: It’s allowed for an external device to hook up to this link layer using window size 1, i.e. send only one message to the exchange and wait for response. OK messages are ACKed, else error handling can simply be timeout and re-transmission.

Stentofon Simple Link Layer

There is always someone who wants to do things simple. Binary data, timing and re-transmissions are awkward to handle in a simple near-sequential PC program. Also, testing the exchange simply by typing data commands on a terminal can be very useful.

The solution is the “simple” link layer. It’s ASCI HEX, optional checksum only, and there is a number of user friendly shortcuts which means that just the most important fields need to be typed. You can even define yourself as a device type which is not pinged (else you have to type pong every 40 seconds…)

This link layer is medium speed, as it’s full duplex, and there is no acknowledge to wait for, but quite a lot of characters to send.

It’s possible to build a fairly reliable link with this protocol also. Your PC can attach a checksum to messages to the exchange, and messages from the exchange always have checksum (but the only thing it can be used to is to ignore faulty messages). A lot of the data commands to the exchange has functional acknowledge, i.e. explicit messages reporting success or failure of the attempted operation, and these can be used to re-transmit on a the application level.

Stentofon Multidrop Master/Slave

The frequent AlphaPro user will notice that it’s possible to select Multidrop master/slave as link layer. It’s a 4-wire RS422/485 low-trafic bus concept developed for an engineering project. The audio network must still be point-to-point. If you have a special application which could use such a concept, please contact Product Support for Stentofon.

System Integration: Additional Link Layers

The AlphaCom exchange has many possibilities for (simple) data communication. They’re included here just to make the picture complete. Message formats are described in other documents.

Note that from AMC 07.60 it’s possible to send data to all of the protocols outputs described below via the AlphaCom data protocol, possibly routed via AlphaNet, reaching either a remote exchange, or a RIOC/GPU used as port expander.

MPC protocol

This is a subset of the MPC protocol used with the classic Stentofon TouchLine exchanges. As it allows control of the AlphaCom exchange by mapping MPC commands to AlphaCom commands one-to-one it can be thought of as a variant of the simple link layer, but only for single-exchange (not AlphaNet) applications.

The output is broadcast of exchange events like dialled digits, station busy/free, connection and transfers. Note that it’s possible to send additional data strings from the AlphaCom’s Event Handler on this port also.

The TouchLine messages supported by AlphaCom are described in “Appendix: TouchLine Protocol in AlphaCom”, see page 83.

EDO (External Data Out)

EDO is an user definable, output-only, ASCII HEX protocol intended for CCTV control etc.

EDO is controlled from the AlphaCom’s Event Handler where it can be configured to send free text merged with parameters for the active stations.

Log port

This is the exchange’s printer port. It will normally generate some status info, plus system error reports, all prefixed with a date/time stamp.

It’s possible to send free text to the log port from the Event Handler just like the EDO port. An external computer could receive this and analyse it. (Unsafe, but this is the way a lot of system integration has been done in practice…)

ESPA 4.4.4

ESPA is a protocol controlling wireless pagers. It uses ISO 1745, point-to-point on RS232 as data link layer. The AlphaCom can use this in two ways:

• Output: Sends a “start paging” message either due to manual or automatic action.
• Input: The AlphaCom can be set up to look like a pager transmitter. The AlphaCom inspects the display text and generates events to the Event Handler which do a range of actions. (“Fire Alarm protocol”).

AlphaPro link layer

The AlphaCom AMC’s port 0 is a dedicated port for the configuration PC running AlphaPro. AlphaPro uses a dedicated link layer which is effective for transport of address/memory-value information.

The AlphaPro link layer also allows “tunnelling” of standard AlphaCom data protocol messages. This is used by AlphaPro for service operations like setting the clock and reseting the exchange. AlphaPro (or another program using port 0) is a regular device, and can both send and receive data protocol messages via tunnelling. But the protocol design requires that the PC always knows when to expect a message from the exchange, and how many messages will come, so it’s not suited as a general bi-directional DP port.

Using the AlphaPro link layer is not recommended except for pure service tools where it’s natural to use a port which is not blocked by the customer’s equipment.

(No protocol…)

In the old days, we often used an external computer to look for certain data messages from the exchange, and fired a command back in return.

Such functionality is from AMC 07.60 possible inside the exchange, using the Event Handler to look for events, and the full data protocol as actions. Actions use the same syntax as the “simple link layer” described below, which means that the messages can be routed via AlphaNet to remote exchanges, or to devices like RIOs and PCs.

Message Formats - Grouped by Function

Common notes

• NET_OBJ_REF parameters: Where an entity class is given (Example: {ECL_ABSENT}), the parameter must be either a LOCAL_ENTITY format reference of the correct class or a directory number that maps to an entity of the correct class, or a Null value, if allowed.

Except: ECL_USER and ECL_STATION can be used interchangeably, and will be converted to the other type when needed. As a side effect of this, the returned directory number reference for a ECL_STATION type object may be different from the one in the command message, or even invalid, if the directory number or user reference in the command message is not the one of the default user of the station.

• NET_OBJ_REF parameters are by default output in the LOCAL_DIRNO format by AlphaCom and TouchLine. Exceptions are noted in each case.
• For the reason above and other reasons, NET_OBJ_REF parameters in command messages can not be relied upon to match the corresponding NET_OBJ_REF parameters in response messages. If one need to sort responses of the same message type from each other, the message reference field in the application header should be used.

Explanation of table format, explanations are in italic font:

• Over time, more parameters will be added to existing messages. These parameters are often marked “(optional)”, and the AMC version which introduced them is shown to the right in the explanation of each parameter.

- Note that it’s the exchange that processes the DP message that adds default values when it creates an internal representation of the message. If you send a “short” message to a remote node in AlphaNet, all default fields will be filled in in that exchange. Example: SEND_MAIL without A station name will get the name from the same dir.no in the remote exchange (if existing). See comment under Simple Link Layer, page 70.

• In general, NULL is not allowed as NET_OBJ_REF parameter.

It’s described explicitly when it can be used, e.g. to switch call forwarding OFF. Hint: Some DP messages works correctly only if you leave the NET_OBJ_REF parameter out, rather than supplying an explicit NULL field.

• Note that all messages may cause the response message ILLEGAL_PARAM, indicating that the exchange has problems recognizing either the message number, or a parameter value of a message. In these cases the documented response message will NOT be returned.

- ILLEGAL_PARAM refers to the problem parameter using a number from 1 and up. This is the number you will find in to the left of each parameter in the table.

- In AlphaNet, if you get an ILLEGAL_PARAM from a remote node indicating that an optional parameter is required, remember that the AMC versions indicated for optional parameters refers to the receiving node, not the local node generating the message.

• Some messages may seem to have too few parameters. Keep in mind that:

- the network layer header contains node and device address for both a source and a destination

- the reference field is always identical in a “command” and the returned “response”.

• AlphaNet: To control a station in a network you must address the DP message to that station’s node. Messages are in general ONLY routed according to the network layer header. If you send a message to an exchange, and use a node number as part of the (A) Subscriber field which is different from the addressed node, the command will be ignored or cause an error response. The messages which deviates from this rule is documented explicitly!

Station Connect Operations

Message	Description
CALL_SETUP	Sets up a coversation between two users
CONN_REQUEST	Sets up a coversation between two users
CONN_REFERENCE	Positive response from the exchange to CONN_REQUEST
CONN_REF_ACK	The external application acknowledges the CONN_REFERENCE
STATION_BUSY	Negative response to CONN_REQUEST
RESOURCE_BUSY	Negative response to CONN_REQUEST
NO_ACCESS	Negative response to CONN_REQUEST
STATION_DOWN	Negative response to CONN_REQUEST
DISCON_ST	Disconnect station from ongoing feature
DISC_REQ	Conversation established with CONN_REQUEST: The external application disconnects a conversation.
DISC_REQ_ACK	Conversation established with CONN_REQUEST: The AlphaCom acknowledges the DISC_REQ message
DISCONNECTED	Conversation established with CONN_REQUEST: Conversation was disconnected, e.g. the user pressed C-key
DISCONNECTED_ACK	Conversation established with CONN_REQUEST: Acknowledge of the DISCONNECTED message
CALL_STATUS_BC	Broadcast message telling the status of a call
CONN_STATUS_BC	Broadcast message telling that a connection is established
DISCON_STATUS_BC	Broadcast message telling that a connection is disconnected
PARK_INQ_BROKER	Park station from conversation, enter Inquiry call state
UNPARK	Unpark station from Inquiry call state station, return to conversation
REQ_TRANSF_CALL	Transfer call in an Inquiry Call situation.

Station Keyboard & Display emulation

Message	Description
DIAL_DIGITS	Simulate digit dialing from a station
DIAL_DAK	Dial DAK on a station
SINGLE_DIGIT	Dial one digit on a station
DIGIT_RELEASE	The station has released a digit press
M_KEY	Order station to press M-key
M_KEY_RELEASE	Order station to release M-key
HANDSET_OFF	Order station to lift handset
HANDSET_ON	Order station to replace handset
C_KEY	Order station to press C-key
DISPLAY_TEXT	Send text and control characters to a station
ST_BUSY_BC	Broadcast message: Intercom station is busy
ST_FREE_BC	Broadcast message: Intercom station is free

Station Mail Operations

SET MAIL TIMEOUT

Appendix: Link layers in detail

ISO Data Link Layer

Transmission Control Characters used

The following control characters are used in the protocol: The first 32 characters, ASCII 0 ­ 31 (0x00 ­ 0x1F) is not allowed in the payload of an message. Note that the message’s Block Check Character can have any value, including the reserved transmission control characters!

STX ­ Start of text

STX is a transmission control character which precedes a text and which is used to terminate a heading. STX is transmitted by the Master Device.

ETX ­ End of text

ETX is a transmission control character which terminates a text. ETX is only transmitted by the Master Device and calls for a reply from the Slave Device. ETX is followed by a BCC, “block check character”.

EOT ­ End of transmission

EOT is a transmission control character used to indicate the conclusion of the transmission of one text. EOT may be transmitted by a Control, Master or Slave Device. The Control Device transmits EOT to anticipate the reception of a forward supervisory sequence. The Master Device in the system transmits EOT to relinquish its right to transmit in favor of the Control Device.

ENQ ­ Enquiry

ENQ is a transmission control character used as a request for a response from a remote device. ENQ is transmitted by the Control Device during polling and by the Master Device during selecting.

ACK ­ Acknowledge

ACK is the transmission character transmitted by a receiver as an affirmative response to the sender.

NAK ­ Negative acknowledge

NAK is a transmission control character transmitted by a receiver as a negative response to the sender.

Device Id

The Device Id is an UINT1 value which is unique within an exchange.

Selecting a device in another exchange (Routing)

If the Master Device has a message to a device in another exchange, the Router is selected. The Router has device id 204 (0xCC) and answers the enquiry, and receives the message, on behalf of the destination device. This means that each device has to know which AlphaCom module they belong to. The Master Device has completed its transmission upon receipt of ACK from the Router. Acknowledgment / handshake between devices on different modules must be handled at the application layer.

Broadcast

The Master Device uses a broadcast id when selecting for a broadcast message. It is the responsibility of the Master Device to ACK the selecting supervisory by transmitting the positive acknowledge character ACK.

Stentofon Data Link Layer

Frame Description

Encoding type 0 means that the field is binary data. - Data needs no reformatting. Encoding type 1 means that the 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 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 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:

 = <source node><source device><destinatin node><destination device> 

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 re­established, an OK­message 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.