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 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 101 and 102. The message DIAL_DIGITS looks like this, with spaces between fields for clarity only: File:Example.jpg

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.