Actions

Network Object Reference

From Zenitel Wiki

Revision as of 15:19, 21 June 2007 by Asle (talk) (Format)

All exchange resources can be referenced either by directory numbers, or “physical numbers”. This is a challenge for the data protocol, as directory numbers can vary in size, and some resources have physical addresses with multiple parts. The NET_OBJ_REF is a “variant record” which has a header with byte count plus a type field. The rest of the information is then according to the type field and length. The total length can vary from 1 to 16 bytes.


NOTE:  AlphaCom 08.00 have a fixed size internally of 6 bytes for NET_OBJ_REF fields!

Format

<header> <contents….>

Where:

  • <header> UINT1 defines both the length and the format:
    • <length> 4 bits. The length of the representation not including the first byte itself.
    • <format> 4 bits. The format of the representation. See the table below.
  • <contents> See the table below.

<Hege: Sett inn tabell her>

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! 1.4.2 Stentofon Data Link Layer This is a Stento 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. 1.4.3 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.

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! 1.4.2 Stentofon Data Link Layer This is a Stento 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. 1.4.3 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.

Entity Classes

Used when referring to an intercom object with internal binary (“physical”) identification.

<Hege: Sett inn tabell her>

Entity Subclasses

Used when very specific information is given, e.g. during error reporting. Subclasses are defined so that they can be used also for future exchange types working in AlphaNet.


<Hege: Sett inn tabell her>

  • Different Schemes should use non­overlapping value sets as long as there are enough available values --- Except for the NULL value that is shared by all schemes.
  • NULL is represented by missing Entity SubClass field in NET_OBJ_REF value. The value 0 is reserved for representing this value in separate subclass variables internally in software.