COLLISION ELIMINATION MUL TIPLE A CCESS CEMA REFERENCE MANUAL · CEMA Reference Manual Œ Getting Started Sec 1 Ł Pg 1 11/98, III - 3 1.1 -A bout this Manual The CEMA SYSTEM IIIﬁ

COLLISION ELIMINATION MULTIPLE ACCESS"CEMA"

REFERENCE MANUAL

11/98, III - 3

CEMA System III Reference ManualTOC � Pg 111/98, III - 3

Section 1 -Getting Started Page #

1.1 About This Manual

1.2 CEMA DescriptionFeatures .................................................................................... 2CEMA Sample of Metropolitan Area Network ........................ 2CEMA protocol ........................................................................ 3User Access ............................................................................. 3Packet Sizes.............................................................................. 3Error Checking .......................................................................... 3The CEMA Advantage ............................................................. 3Multiple Hosts ........................................................................... 3Fault Tolerance ......................................................................... 3Collision Free Data Transfer ..................................................... 3Efficient Data Transfer ............................................................. 3Low Latency ............................................................................ 4Reliable Data Transfer ............................................................. 4Automatic Responder Queuing ................................................. 4Multicast Messages .................................................................. 4Network Management .............................................................. 4Optimal Performance ................................................................ 4User Application Software ........................................................ 4Flexible Baud rates ................................................................... 5Polling Emulation ....................................................................... 5Acknowledgment Timing .......................................................... 5Multiple Protocols ..................................................................... 5Data Compression and Security ................................................ 5Multiprotocol Capability ............................................................ 6Quadrupled the Address Capability ........................................... 6Node Capability ........................................................................ 6Enhanced Contention Mode ...................................................... 6Improved Configuration ............................................................ 6Remote Configuration and Download ....................................... 6

1.3 For CEMA 1.7 UsersEnhancements Made by CEMA System III ............................. 7Efficient Use of CEMA Addresses .......................................... 7Built In ...................................................................................... 7

Section 2 - How CEMA Works

2.1 How CEMA WorksPeer to Peer Contention ............................................................ 1Protocol..................................................................................... 1Initialization ............................................................................... 2

Table Of Contents

CEMA System III Reference ManualTOC � Pg 2

11/98, III - 3

Table Of ContentsPage #

New CEMA System III Feature .............................................. 3Network Startup Sequence ....................................................... 3

2.2 Network OperationPackets ..................................................................................... 4Packet Types ............................................................................ 4

Section 3 - Network Design

3.1 Network DesignDesigning a CEMA Network .................................................... 1Configuring a Port ..................................................................... 3

3.2 CEMA AddressingCEMA Addressing ................................................................... 4

3.3 Port to Port AddressingPort to Port Addressing ............................................................ 6Multicast Capability ................................................................... 6

3.4 Protocol SelectionProtocol Selection ..................................................................... 7

3.5 CompressionData Compression .................................................................... 8

3.6 EncryptionData Encryption ........................................................................ 9Encoding and Decoding Messages............................................ 9Random Numbers ..................................................................... 9Synchronization ....................................................................... 10

3.7 Network Tuning ParametersNetwork Tuning Parameters ................................................... 1 1

Section 4 - User Applications

4.1 User Applications IntroductionIntroduction to the User Applications Section ........................... 1

4.2 Network ManagerNetwork Manager Application .................................................. 3The Program ............................................................................. 3The Protocol ............................................................................. 3Selectable Port Baud Rate ........................................................ 3Network Manager Protocol Parameters Menu ......................... 4LED Display ............................................................................. 4

CEMA Reference Manual � Getting StartedSec 1 � Pg 111/98, III - 3

1.1 - About this ManualThe CEMA SYSTEM III®Manual is a Reference Guide

This book is the third in a series of four manu-als for Users, Installers and Service Techni-cians. This manual covers the System IIIsoftware in two parts:

CEMA Software (Section 1-3)

� Description of CEMA and its features

� How CEMA Works

� How to design a CEMA network

� Diagnosing a CEMA network

User Applications, (Section 4-8)describes:

�Each user Protocol available

�The protocol's features and limitations

�How to configure each protocol

�How to install and interface eachprotocol

This manual is intended for use by System IIInetwork designers and network operatorswho need a detailed understanding of theCEMA network's system, and how to interfacethe System III equipment.

It Does NOT Contain

Operation of any of the component equipment -

this information is contained in:

Book# Name

1 IRM Reference Manual

2 Repeater Reference Manual

4 Network Manager Reference Manual

Notes, Warnings and Tables

NOTE

Text in a white box emphasizesinformation pertinent to asequential order, or the possibilityof damage to the IRM networksystem.


1.2 - CEMA Description

NETWORKMANAGER

PWR ❤ CEMA P1 P2

ARIA WIRELESS SYSTEMSA Bison/Comptek Company

PWR ❤ CEMA P1 P2


IRM

IRM

HOST

ATM

REPEATER

TERMINAL

PWR ❤ CEMA P1 P2


IRM

HOSTSERVER

TERMINALSERVER

PWR ❤ CEMA P1 P2


TERMINALSERVER

IRMHOSTORTERMINALSERVER

NETWORK MANAGER

Collision-Eliminating MultipleAccess (CEMA) Network

CEMA (SEE-MAH) is a patented,slotted Aloha, multiple accesscontention protocol withreservation lists. It is specificallydesigned for radio transmissionof transaction oriented data.

CEMA Sample Metropolitan Area Network

Features

� Reliable error-checked data transfer

� Supports multiple users and terminalprotocols

� Highly efficient

� Peer-to-peer communications

� Fault tolerant

� Low latency

� Built-in Network management

functions


CEMA Protocol

The patented Collision-Eliminating MultipleAccess (CEMA) network protocol providesefficient and reliable data transfer from multipleusers across a metropolitan area network(MAN). Operating with System II IntelligentRadio Modem (IRM), Repeater and NetworkManager Products, CEMA software combinesnon-polled channel access with user terminalprotocol processing to carry data packetsefficiently within a wireless MAN.

User Access

In the ISO layered model CEMA performs MACand Data Link layer functions including reliableerror checked data transfer.

Users access the network by submitting a requestduring contention slot intervals which arereserved at the end of each packet transmission.This mechanism insures uninterrupted datatransfer because collisions between simultaneousrequest-ers can only occur during the contentioninterval hence the Collision-Eliminating feature ofthe protocol.

Packet Sizes

CEMA transmissions can hold up to eight datapackets of 256 bytes each or a total of 2048 bytesof data. This size is optimal for most transactionapplications (credit card authorization, remotedatabase access, E-Mail) since these typicallycontain less than 256 bytes of data.

Error Checking

Error checking is provided by use of a 16 bit CRC(Cyclic Redundancy Code) with positiveacknowledgment to the sender of the results ofeach transmission.

The CEMA Advantage

CEMA provides the network user withsignificant advantages over other wireless datanetworks:

Multiple Hosts

A single network may be configured with two ormore host computers each communicating withterminals or other host computers over the net.This allows two or more types of financialtransactions with different protocols to be carriedon the same network.

Fault Tolerance

A dedicated master station is not required.Instead, network control functions are continuallyhanded off from one active remote unit to another.Thus any IRM can come on and off the networkwhen required, and the failure of a single remoteunit has no effect on other network traffic.

Collision Free Data Transfer

Unlike CSMA (Carrier Sense Multiple Access)networks, no collisions can occur during transferof data packets. Instead, CEMA reserves a specialcontention time period after each packettransmission for nodes to request access to thenetwork. Once nodes successfully contend fornetwork access, their request is placed in a FIFO(First in-first out) queue and interruption freedata transmission will occur once the sender�srequest reaches the top of the queue.

Efficient Data Transfer

CEMA encapsulates user data in a simple packetlayout which requires minimal overhead fields. Inaddition up to eight 256 byte data fields can becombined together into a single transmission.These features can yield transmitted efficiencies of85% or more compared with less than 50% for



other wireless networks. High efficiency translatesinto high data throughput and a large capacity ofusers that a single network can support.

Low Latency

Because of the high network throughput andrapid access time to the network , a CEMAnetwork handles typical financial transactionswith very low latency. Any delay imposed by thenetwork is a function of the data packet size,frequency of transactions and the number ofnetwork participants.

Reliable Data Transfer

The CEMA protocol supports acknowledgmentto the sender of every received packet. Thisguarantees that every transmitted packet isdelivered error free to its intended destinationand provides insurance to the user of reliabledata transfer. To minimize the effect ofacknowledgments on network efficiency, CEMAprovides an acknowledgment mechanismcombined with the data packet returned to theoriginator.

Automatic Responder Queuing

When a node successfully contends for access tothe network, the recipient node is automaticallyqueued so that it can send its response withoutwaiting for the contention process.

Multicast Messages

CEMA allows a sending node to address itspackets to multiple recipient nodes. Thiscapability allows a host computer to transmitcommon initialization information or other data

simultaneously to more than one remote terminalsite. This reduces the amount of network capacityneeded for such transmissions.

Network Management

CEMA carries the control and status messagesrequired for effective management of networkoperation from the PC-based Network Manager.The network management functions supportnetwork diagnostics, node configuration anderror reporting. These functions are compatiblewith the industry standard Simple NetworkManagement Protocol (SNMP).

Optimal Performance

These features effectively distinguish CEMAfrom other wire based and radio networkprotocols. Moreover, by using features likeresponse with acknowledgment combination andautomatic responder queuing, a CEMA networkperforms optimally when carrying typicalfinancial transactions, which generally consist ofa terminal-to-host request followed by a host-to-terminal response message.

User Application Software

Working in conjunction with CEMA are userapplication modules that interface directly withspecific commercially available protocols. Protocolmodules are optimized for commonly used terminalprotocols such as IBM SDLC (Synchronous DataLink Control) and 3270 Bisync, ISO Poll Select, andX.25. They are integrated into the IRM to allowCEMA to efficiently carry the protocol data on theRF network.



APPLICATION #2

USEREQUIPMENT

RADIONETWORK

DATAPACKETS

Software Block Diagram

USEREQUIPMENT

CEMANETWORKSEGMENT

APPLICATION #1


Some of the important attributes of the protocolsoftware are:

Flexible Baud Rates

The terminal baud rate may be different from thenetwork rate to accommodate different speeduser devices.

Polling Emulation

Protocol poll commands are never broadcast onthe network, but are emulated by the protocolsoftware. If polls were to be broadcast they couldeasily consume 90% of the network capacity.

Acknowledgment Timing

In order to meet host computer timingrequirements, message acknowledgments areoften handled by the host IRM. This occurs prior

to receiving the real acknowledgment from theremote node.

Multiple Protocols

User protocol frames are interfaced to CEMAsuch that the CEMA processing of the messagedata may be independent of the type of protocol.This enables multiple types of protocols to besimultaneously carried on the network.

Data Compression and Security

Compression and encryption (scrambling thedata for security) of the incoming data messagemay be customer-enabled to transfer dataefficiently and secure important data.

SECTIONS 1-3 OF THIS MANUAL SECTIONS 4-8 OF THIS MANUAL


1.3 - For CEMA 1.7 Users

There are several major changes that distinguishCEMA System III software from CEMA 1.7:

Multiprotocol Capability

Prior to CEMA System III, only a single protocolcould be loaded onto a single set of EPROMs;thus each IRM CPU board could execute one (andonly one) protocol. CEMA System III eliminatesthis limitation, providing a mechanism wheremulti-protocol capability can be obtained withina single IRM CPU.

Quadrupled the Addressing Capacity

CEMA System III separates �node� addressesfrom �port� addresses. This gives us the ability toincrease the network virtual address space from amaximum of 254 addresses to 1016 addresses. Inaddition, multi-dropped ports (ports that need toaddress several nodes) can be set up indepen-dently from other ports on the same unit; thismeans that the other ports will not have unusedaddresses because of the multi-dropped port.These two features change the way nodes andport addressed which is explained further in 3.2.

Node Compatibility

Nodes running CEMA System III can operate onnetworks containing CEMA 1.7 nodes; CEMASystem III is backward compatible with CEMA1.7, although a node running CEMA System IIIcannot be paired with a node running CEMA 1.7(they cannot directly communicate).

Enhanced Contention Mode

CEMA System III has an optional "enhanced"contention mode. In the enhanced mode, theaverage number of contention slots is reduced to4, resulting in a 40% reduction in networkoverhead. This produces a comparable improve-ment in data throughput over the network fornodes that are configued as "enhanced". There isno effect on older (CEMA 1.7) nodes on thenetwork

Improved Configuration

CEMA System III and the protocols it supportshave their own configuration and networkmonitoring software. All System III units areconfigured with the Network Manager.

Remote Configuration and Download

All configurable parameters can be remotelyprogrammed over the radio network using theNetwork Manager. In addition, software updatescan be sent over the CEMA network, loaded intonon-volatile Flash RAM and then activatedwithout a site visit.


Enhancements Made by CEMASystem III

Efficient use of CEMA addresses:

� 1016 port -to port connections

� 508 link possible

� True broadcast and multi-cast capability

� Multiple protocols per CPU - affordsany combination to any port.

� Integrated encryption - for secure data

� Integration Compression - uses lessband width per transmission

� Increased data throughput

Built-in:

� Diagnostics

� Network Monitoring

� Network Management

� Remote control capability

� Extensive error checking and lost datarecovery

1.3 - For CEMA 1.7 Users

Sec 2 � Pg 111/98,III - 3 CEMA Reference Manual � How CEMA Works

2.1 - How CEMA Works

How CEMA Works

CEMA (SEE-MAH) is a patented, slottedAloha, multiple access contention protocolwith reservation lists. It is specifically de-signed for radio transmission of transactionoriented data.

Peer-to-Peer Contention

A peer-to-peer contention network operates in amanner similar to a group of people conducting ameeting.

Protocol

When people conduct a meeting, there are severalways to communicate efficiently. If all membersspeak at the same time, the messages becomescrambled. Instead, each member waits for apause in the conversation and then speaks,"contending" for the floor.

If all the other members stay quiet, the speaker issuccessful. If not, he tries again later. That's how acontention network operates.

Using this contention scheme, there is no masterstation (Chairman of the Board). All membershave equal access and the failure of any one unitdoes not bring down the network.

The contention process can be time consuming, soCEMA limits their occurrences to brief time slots,saving more of the time for data transmission.

When a network is first started, the time slotperiod must be established. This is done by usingthe standard Aloha (hello) contention network(named after the first network of its kind createdat the University of Hawaii many years ago).After the Aloha network is established, theCEMA network synchronization is formed.

Sec 2 � Pg 211/98,III - 3CEMA Reference Manual � How CEMA Works

Initialization

You can see the initialization process by experi-menting with two IRMs. With two units prop-erly configured to link to each other, monitor theinitialization and network activity with theNetwork Manager.

1. Turn On each IRM.2. Each unit will first listen to hear if there is

a CEMA network operating. If not, theyknow they must establish one. Afterseveral seconds of not hearing anynetwork activity, the IRM will send anAloha packet.

3. When a unit hears an Aloha packet withits address, it responds with a corre-sponding Aloha. The IRMs are now timesynchronized and can establish a CEMAconnection.


4. The IRMs then form a link by sending asequence of Initiate and Connect packets.When complete, The CEMA network isestablished and ready to send data.

To maintain CEMA network synchronization,packets will always be sent. If there is no data tobe sent, the IRMs will exchange Arbitration andVersion packets. These are just filler to maintaintiming. Once data becomes available, it willreplace the filler.

?

ALOHA

ALOHA

ALOHA

CONNECTPACKETS

CONNECTPACKETS


New CEMA System III feature

After forming the link and establishing theCEMA network, each port of the IRM will ex-change Locate/HereIAM packets with its remotepartners. The process allows each port to beindividually addressed without using a CEMAaddress. This increases the number of ports youcan have on each network. Multiple port address-ing allows for more efficient use of addressingspace, while maintaining compatibility with oldernetworks.

Network Startup Sequence

NETWORK ACTIVITY RESULT

1. ALOHA exchange Network synchronization established2. Send Initiate/Connect packets Node-to-node link is established3. Send Locate/Here I AM packets Port-to-port link is established4. Send protocol startup information Polling emulation begins (if applicable)5. Send or receive data message6. Send arbitration packets (filler) Maintains network synchronization



Packets

The IRM uses packets to insure accurate transmission of user data. Data from the user Data TerminalEquipment (DTE) is bundled prior to transmission into units called packets. When the packet arrives atthe destination IRM, it is verified for accuracy and sequence and is then unbundled to be passed on tothe destination user DTE.

Packet Types

The following table lists all different CEMA packet types and describes how they are used.

2 BYTE UP TO 255BYTES

2 BYTE INFO

PacketType

2 BYTES

FLAG BYTE: UNIQUEIDENTIFIER (0 II II II 0) THATDEFINES PACKETBOUNDARIES.

CRC

DataLink

ID

IRM Radio Packet Format

2.2 - Network Operation

F

L

A

G

F

L

A

GCYCLIC REDUNDANCY CODEFOR ERROR CHECKING

CONTAINS CEMAADDRESSES


Used to pass network control from one node to another. Also called a"handoff" packet.

A class of messages destined for simultaneous transmission totwo or morenodes. CEMA messages LOCATE, HEREIAM, CHOKE, UNCHOKE,UNCHOKE_ACKNOWLEDGED and NODE_STATUS belong to this class.

The response to a CEMA initiate message, which is used to connect a pair ofnodes to the network.

Message type used to pass non-broadcast "user" data from one node toanother. Init Data packets are always sent as a first frame of a data transmis-sion, while Data packets are always sent if there are subsequent frames inthe same transmission.

Used when a link partner fails to respond to arbitration transmission.

This is a connection request to a partner node (or nodes). If the partner isfunctional, it will send a connect message in response to the initiate, causingthe two nodes to logically link up.

Displayed by Network Manager when it receives a unrecognized messagetype. This message type is never intentionally transmitted over the network.

The message types sent when an IRM powers up, and, after listening for 15seconds, determines that there is no active network. The IRM will send an"Aloha Init" and expects its partner to send an Aloha response. If thisoccurs, the two IRMs will begin the standard Initiate/connect sequence.

Used to send information messages to the Network Manager. This class willalso be used to send messages from the network manager to one or morenodes. "Broadcast" Messages are a subclass of this type.

Used to send a disconnection notice - some node is being disconnectedbecause of its failure to respond (or to take control of the network).

Message types used to reestablish communications with a partner. In somecases (typically when reception has been blocked for only a few seconds) afull session Initiate/Connect is not necessary to reestablish a connection; oneof these message types is used instead.

Message Type Meaning

Arbitration

Broadcast

Connect

Data/Init Data

Retransmission Delay

Initiate

Unknown

Aloha Init/Aloha Re-sponse

Management Service

Network Controls

Reconnect/Recover/Reinit



The acknowledgment to a Data/Data Init message. CEMA guaranteesdelivery of every data packet by sending an acknowledgment of thereceipt of each packet back to the sender. If that acknowledgment cannotbe "piggybacked" onto a return data packet, it is sent in a SNAC packetinstead.

Used by different protocol emulations to send commands (rather than data)across the network. This message type is typically used to send flow controland mode changing commands. It is used only by CEMA 1.7 nodes.

Used by Async protocol for flow and modem control.

This is an "idle" packet. It is sent by a node when that node has nothingelse to transmit.

Used to send CEMA link-level commands to a partner node. Currently,none are defined.

SNAC Packet

User Controls

Transport Controls

Version Packet

DataLink Controls

Message Type Meaning


CEMA Reference Manual � ConfigurationSec 3 � Pg 111/98, III - 3

NOTECEMA System III EPROMs are not compatiblewith the CPU boards that execute CEMA 1.7software. A CEMA System III digital CPU boardmust be used with CEMA 2.0 EPROMs.

Once the software is installed and the IRM ispowered up, configure your network using theNetwork Manager. From the Network window:

1. Specify the radio transmit andreceive frequencies.

3.1 - Network Design

Designing a CEMA Network

Because the IRM is a relatively complex combina-tion of hardware and software subsystems, it isimportant to follow an orderly procedure bywhich the unit is powered up, configured andconnected to the network. This manual assumesthat the IRM hardware subsystems have beenassembled and properly configured, and that theCEMA System III EPROMs have been installed onthe IRM CPU card.

FROM THE MAINCONFIGURATIONMENU, CLICK ONNETWORK TAB TOCALL UP THENETWORKCONFIGURATIONPAGE .



2. Specify port and node addresses foreach unit on the network

3. Specify the individual port



parameters. These depend on thechosen user protocol (i.e: IBM,SDLC, X.25). This will is discussed in the Network Manager(Book #4) Reference Manual.

There are two methods ofconfiguration:

� Local - PC connects directly to the IRM� Remote - modifications are made over the radionetwork

Local is recommended for initial installation or

when a change is necessary and the CEMAnetwork is not up.

Remote configuration is for minor modificationon an operational unit. It has the advantage ofsaving a trip to the remote site. Performing aConfiguration:Configuring a Port

Local - physically connecting the COM port of theNetwork Manager PC, to an IRM port. Thismethod is recommended for installation.Remote - configurations are transmitted throughRF on an operating CEMA network. Use remoteconfiguration for minor changes, not installation.

Configure only those ports that are actually goingto be used; the other ports should be set to disabled(this will be discussed later in the manual).Alternatively, if spare ports are available, one canbe configured as a diagnostic message port, andone can be configured as a Network Manageroutput port - this will aid field engineering andtroubleshooting, should problems arise.

PWR ❤ CEMA P1 P2


LOCAL CONFIGURATION - DIRECTCONNECTION BETWEEN PC AND IRM.


3.2 - CEMA AddressingCEMA Addressing

CEMA allows for a maximum of 254 addresses.However, instead of using a pair of CEMAaddresses to connect one port to its partner port(as does CEMA 1.7), CEMA System III uses a pairof addresses to connect one unit to a partner unit.The distinction here is that CEMA 1.7 would take4 pairs of addresses (8 total) to multidrop a singleport on a single DataMover to 4 ports on someother DataMover. Using CEMA System III, onlyone pair of addresses (2 total) are required.

In the following example, Figure 1 represents theaddressing scheme used by CEMA 1.7. Each portis identified by a unique CEMA address. Figure 1shows unit 1 on the left (the host) connected tounits 2 and 3 on the right (the remotes); port 1 ofthe host connects to ports 1 and 2 of the firstremote and to ports 1 and 2 of the second remote.CEMA 1.7 requires that 4 pairs of addresses beused: Address 02 is linked to address 03, address04 is linked to address 05, and so on.

Figure 1: CEMA 1.7 Addressing


3.2 - CEMA Addressing

Now look at Figure 2. Since CEMA System IIIconnects nodes to nodes (not ports to ports), onlytwo pairs of addresses are needed: Address 02 ispaired with address 03 (connecting node 02 tonode 03) and Address 04 is paired with address05 (connecting node 04 to 05). Unit 1 utilizes twoCEMA addresses (02 and 04), while units 2 and 3utilize one CEMA address each.

IRM UNIT 1

PWR ❤ CEMA P1 P2


PWR ❤ CEMA P1 P2


PWR ❤ CEMA P1 P2


IRM UNIT 2

IRM UNIT 3

PORT 1PORT 2

PORT 1PORT 2

0203

04

05

PORT 1

Figure 2 : CEMA System III Addressing


Port to Port Addressing

So how are port-to-port connections made usingCEMA System III? In addition to CEMA-leveladdressing, individual ports must be assignedunique �source� and �target� names. The�source� name is the name that you assign toeach specific port on the IRM. The �target� nameis the name that you assign to the other end of theconnection. These names can be any combinationof printable characters up to 3 characters inlength. When a IRM is powered up (or reset), thenames given to each port are broadcast over thenetwork. Each �source� name is specified withone or more �target� names to which it wants toconnect. As individual IRMs receive them, theport names are examined to determine if thereceiving IRM contains a matching name and ifso, then the source and target ports are logicallyconnected.

The source and target names are assigned auto-matically by the Network Manager. It uses theconvention of "llp" for the port name where:

ll = CEMA Node/Link numberp = port number

For example, host server node 02, PORT 1 wouldhave source mode "021".

3.3 - Port to Port Addressing

In summary, port-to-port addressing is now atwo-step process in CEMA System III. First,nodes are paired by unique, consecutive numericaddress. Then ports are paired by unique name.

Multicast Capability

Beginning with CEMA System III, multicasttransmission capability can be utilized on theIRM network. Multicasting gives an IRM theability to send (broadcast) a single message thatcan be addressed to more than one node. Prior toCEMA System III, multicasting was emulated byretransmitting a multicast message to eachindividual node in the multicast group. This ledto computational and memory loading problemsand made for inefficient use of the network.

Although not used by any of the currently-supported protocols, multicasting will be used bymultidrop protocols such as IBM 3270 and SDLC,when they become available on the CEMASystem III baseline.


3.4 - Protocol Selection

Protocol Selected per port


3.5- Compression

Data Compression

Data compression can now be configured on aport-by-port basis. The IRM�s compressionalgorithm is a simple repeating character com-pression (called run-length encoding); strings offour or more repeating characters are replaced bya three-byte code. This significantly reduces thesize of data packets feeding display terminals andprinters, which tend to contain strings of blanksand nulls, respectively. We also observe a smallreduction in the size of a typical financial transac-tion packet, since such packets generally containshort strings of blanks or zeroes.

Depending on the size of the data frame, it maytake from 0.7 to 30 milliseconds to perform datacompression. We recommend that data compres-sion be used, since it helps conserve radio net-work bandwidth (albeit at the CPU�s expense).


3.6 - Encryption

Data Encryption

Like data compression, data encryption can nowbe configured on a port-by-port basis. The IRM�sencryption algorithm converts the data receivedfrom customer terminals into an encryptedcharacter stream (ciphertext) prior to transmis-sion over the radio network. This feature effec-tively provides IRM users with privacy andsecurity for their sensitive financial transactionsand textual data.

The encryption scheme utilizes a symmetricprivate key technique based on a method origi-nally described in 1918 by AT&T Bell Laborato-ries engineer Dr. Gilbert S. Vernam1. The algo-rithm was further refined in 1949 by AT&Tscientist Claude Shannon2. Vernam�s methodutilizes the simple algorithm:

Ciphertext = Random CipherXOR Data Stream where the samealgorithm is used to both encryptand decrypt the data stream.

Vernam proved that the Exclusive OR (XOR) of arandom character stream and a fixed data streamis also a random character stream, hence denyinguseful information to the casual observer of theencrypted data. The method also removes fromthe ciphertext all of the frequency information,inter-symbol correlation and periodicity whichexperienced code breakers use to decipherencrypted data encoded with fixed keys. Toinsure the continued random nature of succes-sively transmitted data, the random cipher iscontinually updated throughout the duration of asession between a given terminal and hostcomputer port.

Encoding and Decoding Messages

The IRM employs the Vernam algorithm to bothencode and decode messages. In order to success-fully decrypt the received messages, the receivermust utilize the same randomly varying key asused to encrypt the data stream. To accomplishthis key synchronization, each IRM employsidentical pseudo-random number generators togenerate the random cipher bits. Provided it isinitialized with the same seed, each pseudo-random number generator will generate the samepseudo randomly varying key values. Thus tomaintain data protection the random numbergenerator seed must be passed in a secure man-ner between transmitter and receiver.

Random Numbers

At the beginning of a session between two IRMs,identical random number generator seeds areindependently derived by the IRMs at each endof the link. Using random parameters unique toeach IRM, different initialization keys are gener-ated by the receiver and transmitter. Then using asecure transfer method, a derivative of the key isexchanged between each IRM. Following thisexchange, each IRM independently calculates theseed from which the initial random cipher isderived.

By employing the Vernam cipher together withthe secure initial key passing technique, a robust,difficult to break data protection is obtained. Thealgorithm is estimated to require in excess of 2112

(1033) attempts to randomly break the code.Further information about the Vernam and otherencryption techniques can be found in a 1979article by Gustavas Simmons3.

1 VERNAM, G.S. "Cipher Printing Telegraph System for Secret Wire and Radio Telegraphic Communications", J. AIEE 45, Feb

1926, pp 109-1152 SHANNON, C.E. "Communications Theory of Secrecy systems", Bell Systems Technical Journal, October 1949, pp 623-656.3 Simmons, G.S. "Symmetric and Asymmetric Encryption", ACM Computer Surveys, December 1979, pp 305-330.

CEMA Reference Manual � ConfigurationSec 3 � Pg 10

11/98, III - 3

Synchronization

Data encryption requires synchronization be-tween the sending and receiving IRMs. Shouldsynchronization be lost (because of either hard-ware or software failure), the IRMs will logicallydisconnect from each other and reconnect, forcingresynchronization. Under normal operatingconditions you will not observe synchronizationproblems, but under extreme conditions (poorradio reception, extremely high data rates) it isanticipated that some synchronization problemscould occur.

3.6 - Encryption

Depending on the size of the data frame, it maytake from 0.7 to 30 milliseconds to perform dataencryption. This additional processing load onthe CPU must be considered before enablingencryption, although noticeable system degrada-tion will occur only in the most extreme loadingconditions.


3.7 - Network Tuning Parameters

The following table lists each network parameterand its meaning. These can be changed only via aspecial purpose Network Manager window.

Network Tuning Parameters

There are several parameters that can be changedto optimize the CEMA network performance.

NOTEThese parameters can severely effect networkoperation. They should not be changed withoutconsulting the factory first!

The amount of time (in seconds) that a flow control condition is allowed topersist at the CEMA level before the box is reset. Chronic flow controlconditions typically arise when the IRM starts running out of memory. Forexample, if the IRM cannot complete a buffer-releasing operation becausesome transaction has not yet completed, yet that transaction needs to receivemore data frames before it can complete, a chronic flow control condition willarise if there is not enough memory left to receive the data frames.

This timeout is used as a last resort to prevent the IRM from locking up. Thedefault value is 60 seconds.

Once a port transmission or reception has been started, a timer is maintainedto determine if subsequent bytes are being written to or read from the port. Ifthe port stalls for any reason, the port (not the IRM) will be reset after thistimeout expires. The default value is 10 seconds.

The number of times a LOCATE message is broadcast over the CEMAnetwork. LOCATE messages are sent by each IRM as part of the algorithmused to logically connect two ports. Since these messages are broadcast,there is no guarantee that they will be delivered. To provide an extremely highprobability that all nodes receive the LOCATE message, this parameter isused to determine the number of times that the message will be transmitted.The default value is 3. On CEMA networks with poor radio reception, it may benecessary to raise this value.

Flow Control Timeout

Stalled Port Timeout

Locate Message Tries

Description Meaning

CEMA Reference Manual � ConfigurationSec 3 � Pg 12

11/98, III - 3

Description Meaning


Locate Message Timeout

HEREIAM Message Tries

HEREIAM MessageTimeout

Choke Message Tries

Choke Message Timeout

Unchoke Message Tries

Unchoke MessageTimeout

Node Status MaxTimeout

The minimum period (in seconds) between LOCATE message transmissions.The default value is 8 seconds.

The number of times a HEREIAM message is broadcast over the CEMAnetwork. HEREIAM messages are sent in response to a LOCATE message(and also whenever the IRM is powered up or reset) as part of the algorithmused to logically connect two ports. These messages are broadcast over thenetwork. This parameter is used to determine the number of times that themessage will be transmitted. The default value is 2.

The minimum period (in seconds) between HEREIAM messagetransmissions. The default value is 2 seconds.

The number of times a CEMA-level CHOKE message is broadcast over theCEMA network. Sending this message a number of times provides a highdegree of certainty that the CHOKE (flow control) will be received by allnodes. The default value is 2.

The minimum period (in seconds) between CHOKE message transmissions.The default value is 2 seconds.

The number of times a CEMA-level UNCHOKE message is broadcast overthe CEMA network. Sending this message a number of times provides a highdegree of certainty that an UNCHOKE (flow control disable) will be receivedby all nodes. The default value is 2.

The minimum period (in seconds) between UNCHOKE messagetransmissions. The default value is 2 seconds.

The maximum period during which an IRM may idle without transmitting amessage on the network. If the IRM has not transmitted anything for thisperiod, the NODE STATUS message will be transmitted. The node's "health"can be determined by observing this message on the Network Manager. Thedefault is 900 seconds (15 minutes).


Description Meaning

Max Chars/Encryption Attempt

Max Chars/CompressionAttempt

Maximum BroadcastDelay

This parameter specifies the maximum number of bytes in a data frame thatwill be encrypted during a single pass through the encryption algorithm.Specifying a small number of bytes spreads the encryption effort out overtime, which minimizes CPU overhead but takes the encryption longer tocomplete. Specifying a larger number of bytes allows encryption to completerapidly, but takes considerable CPU overhead during that period (and maycause other critical events to be delayed or missed). The default value of 28will cause a typical 100-byte data packet to be encrypted over 4 passes, withroughly 10 msec between passes (total delay: 40 msec). For thoseapplications where encryption is required and the processing load is light, it ispossible to raise this value (the maximum is 99).

This parameter specifies the maximum number of bytes in a data frame overwhich compression will take place during a single pass through thecompression algorithm. The default is 28 bytes. For those applications wherethe processing load is light, it is possible to raise this value to a maximum of 99.

The average delay period (in seconds) between broadcasts. Manybroadcasted messages are in response to another broadcast; to preventthese broadcasts from occurring simultaneously across all nodes (andoverloading the network) each broadcast is delayed a random amount of timebetween 0 and the Maximum Broadcast Delay. The default value is 3seconds.


CEMA Reference Manual � User ApplicationsSec 4 � Pg 111/98, III - 3

Introduction to the UserApplications Section

CEMA software as it applies to the user will beaddressed in the following sections (SEC 4through SEC 8). CEMA software allows multipleapplication modules to run as interfaces to the

specific equipment. Two application modules areprovided to interface to specific System III compo-nents: The Network Manager and the DiagnosticMonitor.

The application module designed to interfacewith user equipment is sometimes called a userprotocol. These interface modules provide protocolemulation or some other intelligent means to:

� Provide a seamless connection of user equip-ment to the system III network.

� Reduce data traffic on the radio network bycompressing the data, eliminating polling andacknowledgments.

� Maintain flow control and re-transmit data onerrors.

Any port on an IRM can be configured to run anyapplication module.

APPLICATION #1

APPLICATION #2

CEMA

USEREQUIPMENT

USEREQUIPMENT

DATAPACKETS

SEC 1-4 OF THIS MANUAL SEC 4-8 OF THIS MANUAL

RADIONETWORK

4.1 User Applications - Introduction


Each Application module is explained in thefollowing sections:

Section Application

4 Network Manager Application -provides the interface between thePC-based Network Managerutility and the System III radionetwork; and Diagnostic Monitor -provides insight to the innerworkings of the software.

5 X.25 - CCITT compliant emulationsoftware for the internationallystandard packet switching system.

6 ISO Poll/Select - provides pollingemulation for a variety of poll/select protocols, includingBurroughs Poll/Select and 3201.

4.1- User Applications Introduction

7 3270 Bisync - provides the pollingemulation for older IBM Bisyncequipment.

Section Application


Network Manager Application

Prior to CEMA System III, the Network Managerapplication was available only as a separate set ofEPROMS requiring a dedicated IRM. NetworkManager can now be configured onto any spareport of a CEMA System III IRM.

Network Manager gives you the capability toobserve all radio network activity. All receivedradio packets are formatted and transmitted outthe selected port. When received by the PC-basedNetwork Manager program (via the PC�s COMport), these packets can be displayed and ana-lyzed to determine network performance.

The Program

The PC-based Network Manager program is aseparate program used to capture and displaynetwork messages received from the IRM�sNetwork Manager protocol. A complete descrip-tion of this program�s operation and capabilitiescan be found in Book #4, Network ManagerReference Manual.

4.2 - Network Manager

The Protocol

The Network Manager Application can be config-ured to output a subset of the available networkpacket types. For example, �idle� packets (such asthe Version and Arbitration packet types) do notnormally provide information about networkperformance; output of these packet types can bedisabled in order to reduce both IRM processingoverhead and the data traffic between the IRMand PC. Any or all packet types can be disabledor enabled.

Selectable Port Baud Rate

Port baud rate is selectable, so that NetworkManager can be connected directly to a PC�s COMport (at high baud rates 19,200) or to a modem (atlow baud rates up to down to 1200) for remoteNetwork Managing. When selecting a port baudrate less than the network baud rate, you will beforced to output only a subset of all networkmessages (otherwise, the IRM will simply bufferthem until it runs out of memory and then itdrops messages). For these situations werecommendedusing message filters.


Network Manager Protocol Parameters Menu

SETUP WINDOW

LED Display

When the Network Manager Application is selected for a particular port, that port's LED will flash at a2Hz rate, or at twice the CPU LED rate. When a port LED has this indication, it means the port is ready toaccept Network Manager commands and send Net Activity Messages.

4.2 - Network Manager


Parameter Description

4.3 Diagnostic Monitor

Purpose of the Diagnostic Monitor

The purpose of the Diagnostic Monitor is to provide field service engineering with information regard-ing the internal operation of the IRM. Many internal error conditions can arise that are caused by eitherhardware or software anomalies. Some of these will cause the unit to be reset (in the hopes of clearingthe problem) while others are simply noted in order to allow processing to continue as best as possible.Still other conditions arise that are not necessarily errors but may indicate that the IRM is not performingas expected.

IRM Configuration

The Diagnostic Monitor can be configured onto any spare IRM port; it will output any diagnostic mes-sages to this port, to be received by any terminal connected to it. In the lab, we connect the DiagnosticMonitor to a PC running a standard communications program such as ProComm®, so that we cancapture the information, save it to disk and analyze it should we observe any errors.

Once a minute (this is the default time period, which is configurable) the Diagnostic Monitor outputs aline of text consisting mostly of numbers, that looks like this:

aaa:bb MEM: cema|ccc appl ddd|eee rsys (L) fff|(S) ggg

The meaning of these numbers (moving from left to right) is on the following table.

aaa:bb

cema|ccc

appl ddd|eee

rsys (L) fff|(s) ggg

Diagnostic Monitor Periodic Output

Elapsed time (in hours:minutes) since the IRM was last powered up orreset.

The number of available CEMA Network-level buffers. These buffers areused only by CEMA.

First Item: The number of protocol-level memory packets available to allprotocols. One packet is used per message, regardless of the protocol.Second Item: The number of protocol-level memory buffers available toall protocols. A buffer has room for 28 bytes of data. One or more buffersare used per message (depending on message size), regardless of proto-col. The buffers are used by all protocols.

The number of available buffers in the ring buffer system. This is used inthe X.25 and SDLC type protocols only. fff is the number of large buffersavailable and ggg is the number of small buffers.


4.3 - Diagnostic Monitor

Other diagnostic messages are displayed as an erroror anomaly occurs. A complete list of all generaldiagnostic messages can be found on the followingpages of this section. Diagnostic message descrip-tions for the specific protocols are found in theindividual protocol sections.

Diagnostics will change as IRM protocol softwareis modified and as new protocols are added toCEMA System III.

Diagnostic Error Messages

There are about 300 diagnostic messages that havebeen added to System III in order to provide theservice technicians with some information wheninternal problems arise. While we strive to offer aperfect product, it is unreasonable not to expectsome programming errors. If and when they dooccur, the diagnostic messages provide us a windowinto the software and give us clues as to the causeof the problem. This, in turn, helps us to morequickly correct the problem.

Diagnostic messages are sent to any IRM portconfigured with the Diagnostic protocol. The defaultoutput from this port is 9600 baud asynchronous, 8bits no parity, 1 stop bit. Any terminal that conformsto VT100 emulation can be used to display theoutput. A PC running a communications packagesuch as ProComm can also be used (although youwill have to configure ProComm to force CR/LF,and translate LF characters (10 hex) to CR charac-ters (13 hex).

You are not required to reserve a port for thediagnostic monitor. However, if one is available, it isuseful to configure it as a diagnostic port, since thiswill aid field engineering should a problem ariselater.

Fatal Error Messages - KnownCauses

The following table describes fatal error messages(from a known cause) that are sent to the diagnosticport. These messages are also sent over the net-work so that they can be displayed using the Net-work Manager.

Non-Fatal Error Messages

Most of the messages that are displayed on thediagnostic monitor are non-fatal. However, theymay be symptomatic of some underlying problemthat eventually results in a catastrophic failure. Forthis reason, we usually output, whenever possible, adiagnostic message at the first sign of trouble. Manyof these messages simply indicate that a scheduledoperation could not be performed (because thenetwork was down, IRM memory was unavailable,and so on), while others indicate that anunresolvable problem occurred and that the IRMwill try to continue in spite of it.

Because of the sheer volume of the messages andthe limited amount of ROM available, most mes-sages are very brief (and often cryptic). Thefollowing table lists all non-fatal diagnostic errormessages and offers a brief explanation of whatthey mean.


4.3 - Diagnostic Monitor

Message Description

Chronic Applications Choke

Chronic CEMA Choke

I_BMON:Out of MemoryIX25_InitializeDOPEALLOC Failure 1DOPEALLOC Failure 2I_FRMLVL INIT FailureFRINITIALIZET_CREATE: OUT OF MEMORYDOPE VECTORSR_INIT: OUT OF MEMORY

***CRASH:[Followed by a screen of informa-tion]

Fatal Error Messages Sent to the Diagnostic Port

Protocol emulation software was in a persistent flowcontrol position caused by some internal problem (typi-cally, the IRM has run out of available memory. When thiscondition persists for a long period of time (about 90seconds), the IRM is reset.

The CEMA software was in a persistent flow controlposition caused by some internal problem (typically, theIRM has run out of available memory. When this conditionpersists for a long period of time (about (about 90 seconds),IRM is reset.

The X.25 Protocol has signalled one of several fatal errors,all due to lack of available memory at initialization. As atemporary solution, reduce the number of ports runningX.25 and see if the problem disappears.

A fatal error has occurred and the IRM has been reset. The"crash dump" provides information about the state of thehardware and software at the time of the crash. If a persis-tent fatal error occurs, we recommend using PROCOMMor some other terminal emulation program to capture thescreen image to disk and send it to ARIA Wireless Systemsfor review.


The IRM was unable to append data to a message beingbroadcast to the network. Most likely cause: out of memory.

The IRM could not broadcast a LOCATE message to thenetwork. Most likely cause: network is down or choked.

The IRM could not broadcast a LOCATE message to thebroadcast queue. Most likely cause: programming error. Thiserror indicates that the broadcast queue is probably corrupted.

Could not find the handle to a timer being used to periodicallysend LOCATE messages. Most likely cause: no more timersavailable.

Could not broadcast a timed message. Most likely cause:network is down or choked. An attempt will be made tobroadcast the message at some later time.

Number of bytes in received LOCATE message does not matchthe expected number of bytes. Most likely cause: versionmismatch between paired IRMs.

Could not broadcast HEREIAM message. Most likely cause:network is down or choked.

Could not add a HEREIAM message to the broadcast queue.Most likely cause: programming error. This error indicates thatthe broadcast queue is probably corrupted.

Could not find the handle to a timer being used to periodicallysend HEREIAM messages. Most likely cause: no more timersavailable.

Number of bytes in received HEREIAM message does notmatch the expected number of bytes. Most likely cause: versionmismatch between paired IRMs.

APP_MSG Error # 1 nn(On this and subsequent messages,the value nn is a status further detail-ing the error)

APP_MSG Error #2 nn

APP_MSG Error #4 nn

APP_MSG Error #5 nn

APP_MSG Error #6 nn

APP_MSG Error #7 nn

APP_MSG Error #10 nn


APP_MSG Error #14nn


Message Description

Non-Fatal Error Messages Sent to the Diagnostic Port




Could not broadcast CHOKE message. Most likely cause: networkis down.

Error while trying to send a message to the network. Most likelycause: network is down.

Could not broadcast UNCHOKE message. Most likely cause:network is down or choked.

Could not broadcast a timed UNCHOKE message. Most likelycause: network is down or choked. An attempt will be made tobroadcast the messages at some later time.

Could not broadcast NODE STATUS message. Most likely cause:network is down or choked.

Unknown message type received from the network and put on thegeneral applications queue. Most likely cause: version mismatchbetween paired IRMs.

Unable to close packet that was removed from the general applica-tions queue. Most likely cause: programming error.

Could not read message from general applications queue Mostlikely cause: version mismatch between paired IRMs.

Invalid message handle found on general applications queue. Mostlikely cause: programming error - previous memory managementoperation was not handled properly, resulting in a cascaded errorhere.

Mismatched application numbers. The application expected toreceive the current message is not the same as the actual applica-tion. Most likely cause: programming error.

The IRM packet utilization count does not match the actual count ofpackets in use. Most likely cause: programming error - previousmemory management operation was not handled properly, result-ing in a lost (or double-linked) packet.

Message Description

Non-Fatal Error Messages Sent to the Diagnostic Port





APP_MSG Error #36 nnAPP_MSG Error #39nn

APP Error # 1 nn aaaaaa

APP Error # 2 nn nn aaaaaa

APP Error # 3 nn nn

APP Error # 4 nn nn

APP Error # 5 nn nn nn

Missing nn packets

CEMA Reference Manual � User ApplicationsSec 4 � Pg 10

11/98, III - 3


APP_QUE Error 1 nn

Decryption Failure...resynchronizing

Output Queue Port nn,(stalled port?)...resetting

NET MSG # 1 nn

Network Manager hasdisabled this node

Aloha lock...

Aloha unlock!

In Circuit INIT

RING= nn

Message Description

Non-Fatal Error Messages Sent to the Diagnostic Port - (Continued)

An indecipherable message was received on an inbound (from thenetwork) queue. Most likely cause: version mismatch between pairedIRMs.

The encryption engines used by two linked IRMs have gotten out ofsync, resulting in an encrypted message than can no longer be de-crypted. The message will be passed on to the higher layers in thehopes that some action can be taken to retransmit the message. Mostlikely cause: erratic network behavior causing one IRM (but not theother) to undergo a state change.

Could not append a message to the network broadcast queue. Mostlikely cause: network is down or choked.

Handle attached to message being sent to network is invalid. Mostlikely cause: programming error.

The Network Manager program has shut down transmissions by thisnode. This capability will be available to network managers to pre-vent illegal use of the network by non-subscribing customers.

The IRM has lost contact with the network and is now in "aloha"mode, waiting for a network startup command.

The IRM has timed out waiting for a network startup command andhas successfully initiated the network itself.

The IRM has transitioned from an "aloha" mode to CEMA mode,hearing and responding to network commands. This is not an errorbut rather an indication that normal network operations have re-sumed.

The X.25 task scheduler has reached its queue limit, and subsequentrequests for X.25 processing will not be honored until the queue sizehas decreased. Most likely cause: X.25 is being saturated by manysmall frames from two or more ports. A temporary solution would beto decrease the number of ports running X.25, and/or to reduce theport baud rate.



Message Description


nwl received reconnect forcircuit that is down

nwl forcing disconnect

ACP:RX error on channel nn -Error in parity

ACP:RX error on channel nn -Framing error

ACP:RX error on channel nn -Receiver overrun

ACP:RX error on channel nn -UNKNOWN status interrupt

ACP: break received fromchannel nn

(!AVAILBUF !SOME)

(AVAILBUF < SOME)

A "reconnect" request was received by a IRM that had beenpreviously disconnected. This is not logical (CEMA requires thatan "initiate" or "aloha" request precede the "re-connect"). Mostlikely cause: programming error.

The CEMA network layer is out of sync with its partner, and canrecover. It will force a disconnect, followed by a reconnect, to getboth IRMs back into sync. Most likely cause: programming error.

The Asynchronous Comm Port module got a parity error whiletrying to receive asynchronous data from a port. Most likelycause: noise on a data line or a broken connection.

The Asynchronous Comm Port module got a byte framing errorwhile trying to receive asynchronous data from a port. Mostlikely cause: noise on a data line or an incorrect port baud rate.

The IRM could not keep up with an asynchronous input datastream. Most likely cause: the port's baud rate is too high to besupported along with all other IRM operations going on.

The Asynchronous Comm Port module got some kind of un-known error while reading asynchronous data.

An unexpected break signal was received by the AsynchronousCOM Port module.

CEMA requested a data buffer when none were available. Mostlikely cause: a programming error prior to the request formemory has locked up (or used up) available memory.

CEMA requested more data buffers than were available, and therequest could not be honored. Most likely cause: the IRM cannotkeep up with the network activity. If this happens, it is mostlikely to happen to a host IRM that is supporting several remoteIRMs.

CEMA Reference Manual � User ApplicationsSec 4 � Pg 12

11/98, III - 3

Message Description


_MTM_Start_Multi_Timer - Timer Valueis nn in aaa (nn)

!nnn/[filename]:line

A timer was requested with an invalid time period.Most likely cause: programming error.

A diagnostic message preceded by an exclamationpoint always takes the form on the left, wherennn is the elapsed time (in sixteenths of a second) sincethe IRM was last reset;[filename] is the name of the submodule in which theerror occurred;This diagnostic message type is used throughout thesoftware, typically where critical tasks are running(examples would include I/O subsystem errors, likeFCS or receiver overrun). The IRM will usually (but notalways) fully recover from these types of errors. If anerror like this persists, you should copy it down andnotify Aria Wireless Systems.

Line is the line number in the source code where theerror occurred.




Network Manager Error Messages

Where appropriate, some error messages are sentover the CEMA network to Network Manager,where they can be displayed (and logged) forsubsequent analysis. These messages appear as

text after the Network Manager descriptor for"Network Debug Message". See the NetworkManager Manual for details.

Sec 5 � Pg 111/98, III - 3 CEMA Reference Manual � Protocol Applications

5 - LAP-B Protocol Application

Protocol Emulation

The IRM LAP-B protocol emulation implementsthe 1984 CCITT (Blue Book) Link Access Proce-dure - Balanced (LAPB) standard. This gives theIRM the same point-to-point capability as anHDLC link, but with the addition of protocolemulation to minimize network traffic. The level 3traffic is transparent to LAPB and is sent across

the network as data or information frames (I-Frames). The IRM will perform both pollingemulation and data acknowledgments locally,sending only I-Frames and control informationacross the network.

LAP-B Parameter Configurable? Min Value Max Value

Baud Rate Yes 50 192000

Extended Control Yes normal (mod 8) extended (mode 127)

T1 (Response Timeout) Yes 0 msec 9,999,999 msec

T2 (Acknowledgment Delay) Yes 0 msec 9,999,999 msec

T3 (Channel Timeout) No (IRM supplies its own timeout)

N1 (Maximum Frame Length) Yes 1 4096

N2 (Retransmission Tries) Yes 1 99

k (Max acknowledged Frames Yes 1 50/# LAP-B Ports

Multilink Operation No (Not Supported)

Supported LAP-B Frame Types

SABM/SABME

RR/RNR/REJ

DISC

UA

DM

FRMR

IFrame

Set Asynchronous Balanced Mode/Set Asynchronous Balanced Mode Extended

Receive Ready/Receive Not Ready/Reject

Disconnect

Unnumbered Acknowledge

Disconnect Mode

Frame Reject

Information Frame

The CCITT standard allows modifications to thevalues of several LAP-B parameters, in order toprovide flexibility to developers of equipment.The following table lists these parameters,whether or not the IRM supports modifications to

them, and the maximum and minimum values towhich they can be set.

Standard LAP-B Parameters

CEMA Reference Manual � Protocol ApplicationsSec 5 � Pg 211/98, III - 3


NOTELAP-B does not guarantee acceptable perfor-

mance if the DCE and DTE aren't exactlymatched.

LAP-B Physical Layer

An LAP-B terminal is usually wired to be DataTerminal Equipment (DTE), while the LAP-Bnetwork interface is usually wired to be DataCircuit-terminating Equipment (DCE). Electri-cally, an IRM is always DCE. This means that evenif the IRM port is configured as a DCE Server(emulating a LAP-B DTE and connected directly tothe LAP-B DCE), it is still a DCE at the RS-232connection. If the customer equipment cannot beconfigured as a DCE (logically) and a DTE (physi-cally), then a custom cable will be needed thatswaps the data and clocking lines between theIRM and the LAP-B DCE.

Refer to the IRM Reference Manual, Sec 2.3, forconnecting DCE to IRMs.

IRM LAP-B Capacities

The IRM has been tested running LAP-B on one,two, three and four ports simultaneously. At 9600baud, four ports can be supported at moderatedata rates. At 19200 baud, at least two ports (andpossibly three) can be supported at moderate datarates. Bear in mind that the combined averageport data rate cannot exceed the average radionetwork data rate for more than a brief period oftime. The IRM will attempt to buffer data forthose periods when input is occurring on two ormore ports simultaneously; however, IRMmemory is limited and data buffering can besustained only for about 16 Kbytes of data. TheIRM will attempt to flow control the user equip-ment (replying RNR to a poll or data) when databuffering nears its limit.

Memory limitations also force the IRM to limit themaximum number of unacknowledged IFramesthat can be buffered. This limit is 50 per IRM,regardless of the number of LAP-B ports that havebeen configured. If the number of unacknowl-edged frames grows too large, the IRM willattempt to flow control the user equipment bysending RNRs. If the unacknowledged pool isfilled, the IRM will send REJ frames to the userequipment until pool space is freed up. Thislimitation can be avoided by keeping the(configurable) LAP-B parameter k (Max Unac-knowledged Frames) small. The default is 7.

The largest LAP-B IFrame that the IRM willsupport is 4096 bytes. The IRM can buffer up to16K bytes of data; flow control will be appliedwhen roughly 60% of the available buffering isutilized.


ConfigurationThe user selectable parameters for LAP-B Protocolare grouped into three categories:

1. Active Session Parameters2. Inactive Session Parameters3. Physical Parameters

The distinction between �active� and �inactive�settings is related to parameters that affect opera-tion while the session is established (i.e., after aSABM/UA has occurred) and parameters thataffect operation while no session is established(i.e., after a DISC or DM has occurred).There is no processing of X.25 Packet Layer (Layer 3)items, so there are no Packet Layer parameters. TheLAP-B only operate to level 2 (LAPB), so these arethe only configurable parameters you need to set.Level 3 is completely transparent to the IRM.

Active Session Parameters

Frame Window SizeThe maximum number of outstanding dataframes (�IFrames�) allowed before an acknowl-edgment is required. The range is 1 to 7 (7 is thedefault value). Under most circumstances thisparameter should not be modified. If it is set to avalue less than what the user�s equipment ex-pects, the LAPB software will send frame rejects(FRMR) whenever it receives more unacknowl-edged packets than allowed. This will result inloss of session.

Min Receive Window SizeIf the number of unacknowledged data frames isless than this parameter, then LAPB will auto-matically send a reply (RR) to the port withoutwaiting for T2 (or a return Iframe) to expire. Therange is 1 to Frame Window Size (the default is 2).The result of setting this parameter smaller thanthe Frame Window Size is that it speeds up dataframe acknowledgments, leading to more efficientuse of the port. Under most circumstances thisparameter should not be modified.

Active PollingThis item controls the IRM�s ability to poll theuser equipment with RRs. Having the IRMactively poll will allow it to know if the userequipment goes down. If this is set to False, thenthe IRM will not do any polling, and only IFrameswill be transmitted between the router and theIRM. In cases where the user equipment does notrespond to polls, set Active Polling to False,because after N2 timeouts (see below) the IRMwill disconnect the session because of a lack ofactivity on the router�s part.

Server TypeThe �Primary� side of the connection is usuallyassociated with an X.25 router or switch, and isregarded as the LAP-B �network� side of theconnection. The �Secondary� side of the connec-tion is usually associated with an LAP-B terminal,but the terminal could also be another LAP-Brouter or switch. It is regarded as the LAP-B�terminal� side of the network.What makes this confusing is that LAP-B is reallya peer-to-peer link, and the names given to thedevices can become arbitrary. In general, how-ever, the following rules must apply when usingIRMs as the access medium:

One LAP-B device must be configurableas a logical DCE, and the other must beconfigurable as a logical DTE.

The LAP-B emulation (the IRM) con-nected to the logical DCE must be config-ured as the Primary Server while theemulation connected to the logical DTEmust be configured as the SecondaryServer.



NOTEIt makes no difference which Node Type (Host orTerminal) is associated with a Primary or Second-

ary Server.

Maximum Frame LengthNormally, the LAP-B session layer arbitrates themaximum size of the data packets that can be sentfrom unit to unit. The IRM emulation has an upperlimit of 4096 bytes (the default) but can be setlower to provide an additional source of errorchecking. Under most circumstances this param-eter does not need to be modified.

T1 TimerThe T1 Timer (also called the Response Timeout orRetry Timeout) is the amount of time (in msec) thatthe LAP-B logic will wait for a response beforeretransmitting a frame. This parameter should beset identically to the value used by the customer�sequipment.

T2 TimerThe amount of time that LAP-B will withholdemulated acknowledgments in the hopes of receiv-ing a reply from the other end of the connection.Judicious use of this parameter allows moreefficient use of the port, since fewer port transmis-sions will occur if a real reply (i.e., a data frame) isreceived prior to an emulated acknowledgment.However, because CEMA network delays tend tobe the overriding factor in data throughput, tryingto make the port connection more efficient has littlereal impact on performance.This parameter is normally configured to be nomore than 2/3 T1. Its default value is 200 msec. Itis not allowed to be greater than T1; setting thisvalue larger than T1 will cause the user equipment

to retransmit frames whenever T1 expires and anacknowledgment has not been received.

Num N2 TimeoutsSometimes called N2 or Retry Count, this parameterdetermines the maximum number of times a framewill be transmitted before the LAP-B logic changesstate. If N2 timeouts occur while attempting totransmit a data frame, LAP-B will force a discon-nect sequence to occur. If N2 timeouts occur whenalready disconnected or trying to reconnect, aDisconnect Mode (DM) frame will be transmitted.This parameter should be set identically to thevalue used by the user equipment.

Inactive Session ParametersThese parameters are necessary to determinebehavior while in a disconnected state. Some userequipment connections demand a very specificdisconnect/connect sequence; if the disconnect/connect handshaking does not occur in exactly thecorrect order, one or both user units will fail toconnect.

Should Auto Start [Connection]This parameter, when set Yes, allows the LAP-Bsoftware to initiate a connect sequence whenever asession disconnect has occurred. It has the advan-tage of not relying solely on the user equipment toestablish the session. The default for this value isYes. If after a session disconnect the customerequipment has trouble reconnecting, then it may beadvisable to set this parameter to No in order tominimize any interference from the LAP-B emula-tion.



Here is an example of when it is a problem to have the Auto Start function enabled:

Host Router Host Server Term Server Term RouterDISC-> (Send DISC to CEMA)->

<-UA DISC-> <-SABM

UA--> <--UA <-Send SABM to CEMA ,-(send DISC to CEMA) <--DISC UA-->

UA-->DISC--> (send DISC to CEMA) -->(and everything repeates like this forever !!)

If this condition occurs, disable Auto Start.

Use Explicit UAIf a unit has sent a disconnect notification to theLAP-B emulation and LAP-B has acknowledgedthe disconnect, LAP-B will normally wait for adisconnect notification to come from the remoteside of the connection before changing state.(Receipt of the remote disconnect indicates thatboth sides of the connection are in a disconnectedstate.) If this parameter is set to FALSE and theuser equipment tries to start the connection prior toLAP-B�s receipt of a remote disconnect, LAP-B willnot acknowledge the connect and will instead senda connect of its own, expecting the user equipmentto acknowledge. This behavior is consistent withthe X.212 protocol standard.However, some user equipment will not toleratethe lack of a reply to its connect request. If UseExplicit UA is set to TRUE, LAP-B will alwaysacknowledge the user equipment�s SABM. Thiswill satisfy the user equipment but has the possibleeffect of getting the two sides of the connection outof sync with each other.The default value for this parameter is FALSE,although careful analysis of the user equipmentconnection is required to determine if this valueshould be set to TRUE.Setting this to True will force the IRM to respond

UA to any SABM and to follow it with its ownSABM, causing both sides to SABM/UA eachother. If this is set to False, then when the IRM getsthe router�s SABM it will ignore sending a UA andinstead send its own SABM, expecting a UA fromthe router. It looks like this:

“Use Explicit UA” set to FALSE

Active DisconnectIf set to TRUE (this is the default), then the LAP-Blogic will initialize a connection by sending adisconnect request (DISC) prior to sending aconnect request (SABM). If Should Start Connectionis FALSE, then this parameter has no impact onLAP-B processing.

No Initial RRIf this parameter is set to TRUE (the default) then aSABM/UA is all that is needed for the LAP-Bemulation to be considered active. If FALSE, thenat least one poll or data acknowledgment must bereceived before the link is declared active.From a connection point of view, it is safer to setthis parameter to FALSE. However, some user



equipment may expect to be able to send dataimmediately after the SABM/UA handshake. If NoInitial RR is FALSE, at least one poll will have tooccur first before LAP-B accepts any data from theuser equipment. This could lead to communica-tions failure since the data will be ignored. For thisreason, No Initial RR should normally be set toTRUE.

Disconnected Phase TimerThis parameter is used to prevent LAP-B fromleaving the disconnected state until after the timerexpires. It is meant to provide some time for userequipment to recover and reinitialize itself after adisconnect.This parameter is normally disabled, which indi-cates to LAP-B that it should wait for the terminalto reconnect. A value of 0 msec indicates that LAP-B should try to reconnect immediately. The maxi-mum legal value is 65.534 sec.

Physical Parameters

In addition to the standard RS-232 physicalparameters (baud rate, CD and RTS control,etc.), there are a few important items thatmust be set.

Enable Clk Btwn FramesSome user equipment may require that the idleperiod between frames be flag-filled (and notmark-filled). To do this, make sure this item is setto TRUE and the configuration item �IDLE Condi-tion� is set to FLAGS.

Enable Active Idle [future]Setting this parameter to TRUE will force thetransmission of idle characters during the periodbetween frame transmissions. Some user equip-ment requires this. The default value is TRUE. Ifset to FALSE, the I/O chip will transmit nothing(the �marking� state) during the period betweenframe transmissions.

Idle Character [future]This parameter can set so that either flags(01111110) or marks (11111111) are transmittedduring the idle period between frames. It is notrelevant if the Enable Active Idle parameter is set toFALSE.This parameter is dependent on the expectations ofthe customer equipment. Idle Flags is the default.

Example: Configuring LAP-B on RoutersLike other protocols, LAP-B requires a primary/secondary or host/terminal connection. Eventhough you�re going to be hooking up two routers,one will effectively be set up as a logical DTE andthe other will be a logical DCE. If the two routerswere hooked directly together, they�d look like thisat the physical and datalink levels:

(Unlike SDLC or 3270, LAP-B is actually a full-duplex peer-to-peer protocol. It therefore uses twological addresses - 01 and 03 - to differentiate fromcommands/responses coming from both direc-tions.)When using IRMs for this link, use the followingconfiguration:

A tail circuit cable may be needed on the hostrouter if it is a physical DCE. Refer to section 2.3 ofthe IRM Reference Manual for details on how tointerconnect two physical DCEs.



Config Parameters - Physical Layer Settings

Carrier Detect: Always OnClear To Send: Always OnCD Anded with Radio: FalseCTS Anded with Radio: FalseData Encoding and Clock Source: depends on user equipment settingsFrame Check: CCITT_1Enable Clk Btwn Frames: TrueEnable Active Idle: True (default)Idle Char: Flags (default)

Config Parameters - Protocol Active Settings

Frame Window Size: 7Min Rx Window: 2Active Polling: True Server Type: Primary for the host IRM, Secondary Remote IRM.T1 Timer: 3.000 secondsT2 Timer: 0.5 secondsN2 Timeouts: same as router�s valueMax Frame Length: 512 or 1024

Config Parameters - Protocol Inactive Settings

Should Auto Start: NoUse Explicit UA: False

If you have trouble getting a session to reconnect after it has disconnected,this is probably the first parameter to change. �Use Explicit UA� set toTrue is not precisely compliant with the LAP-B spec, so it is recommendedto leave it False unless you have session problems.

Active Disconnect: TrueNo Initial RR: TrueDisconnected Phase Timer: Disabled [65535]

Port LED Display

The port LED can be in one of four states:

LED State MeaningOff

This port has no radio link established.Protocol emulation is running, butno messages will be exchanged across the network.



Network Messages

There are several network messages sent between IRMs to maintain the LAP-B session. These appear onthe Network Manager�s Realtime Display as User Control Packet or as Data Packet. Only the informationcontained in the IFrame is sent as a Data Packet, the rest are User Control Packets.



Protocol Features

The ISO Poll/Select application provides protocolemulation for several manufacturer�s equipmentthat fallS under the general class of poll/selectcommunications. The software conforms with theInternational Standards Organization (ISO) specifi-cation 1745 and the American National StandardsInstitute (ANSI) X3.28 procedures.

Within this general class, there are several specificprotocol selections:

� IBM BiSync (3270): conforms with IBM specGA27-3004, Binary Synchronous Communica-tions

� Burroughs Poll/Select, Async: conforms with theDiebold spec 79-811-5. Diebold 9000 SeriesTerminal Poll/Select Protocol Manual

� Burroughs Poll/Select, Sync:� Lottery 3201:

Each one operates according to its own specificmanufacturer�s rules, but the general operation andconfigurations are similar.

In this release, only the Burroughs Poll/SelectAsync is supported.

Burroughs Poll/Select SupportedFeature

This protocol conforms with ANSI X3.28 Establish-ment and Termination Procedure Subcategory 2.5and Message Transfer Subcategories A4 and B1.The following features are implemented:

� Standard Poll/Select� Fast Select� Group Select� Broadcast Select� ASCII character set� Up to 32 terminals per multidropped line (Host

Server port); up to 32 multidrop Terminal Serversper Host Server port.

� Full RS-232 control handshaking.� Baud rates 300 to 19,200, each port.� Up to 4 active ports per CPU.

Compatible Terminal Equipment:

This protocol operates with the following equipment:

* Diebold serves 910 Automatic Teller Machines and Simulators. * Computer Peripheral Systems Including Poll/Select, Host and Terminal Emulators.

6 ISO Poll/Select Application

Sec 6 � Pg 211/98, III - 3CEMA Reference Manual � Protocol Applications

How to Configure:Use the Net manager, select the Port Tab.

6 - ISO Pol/Select Application

Select BPS AsyncPhysical Parameters, DepressPhysical Button. This screen appears:

Set the port physical parameters as desired. Theusual settings for Burroughs Poll/Select terminalsare 7 bits per character and Even Parity. Usuallythe remaining parameters can be left as default.Click on OK, and then select the BPS AsyncProtocol button. This screen appears:

terminals that will be polled. Click on MultidropTerminals and this screen will appear:

Again, these parameters can usually be left at theirdefault values, but can be changed if needed. Thetable on pages 4-5 gives a precise definition ofeach.The last step is Configuring the Multidrop Termi-nal. This MUST be done in the Host Server for all


Config Parameters Values

Parameter Required? Range Default

Multidrop Terminals Yes, on HS, ID: 2 character ASCIIoptional on TS or 4 character Hex none

Target: any remote port nonePriority: yes or no no

Polling Interval No 0.1 to 100 secs 1 secondPriority Polling Interval No 0.1 to 100 secs 1 secondNo Response Timeout No 0 .1 to 100 secs 3 secondsNumber of Polls to Inactive No 1 to 255 5Number of Retries toNak Messages No 1 to 255 5Periodic Update Time No 1 minute to 24 hours 10 minutesSuspended Session No 0.1 to 1000 seconds 10 secondsTimeoutMax Frame Size No 1 to 8192 bytes 2048 bytesDebug Enable No Yes or no yes

6 -ISO Poll/Select Application


Node Type

Multidrop Terminals

Active PollingInterval

Inactive PollingInterval

No ResponseTimeout

Number of Polls toInactive

Number of Retries toNak Messages

Periodic Update Time

Suspended SessionTimeout

Selects whether this port is a Host Server or Terminal Server selected in theUtilities Menu. A Host Server behaves as a secondary device responding to polland select commands. A Terminal Server behaves as a primary device initiatingpoll and select commands.

Selects which terminals will be emulated. Three fields:1. Terminal ID - the terminal address, entered in ASCII of Hex2. Terminal Server - select which terminal server will poll this device3. Priority Polling - yes or no

Must be configured at the Host Server side, optionally, can be configed at theTerminal Server side.

The minimum time interval between polls to a terminal that is active, but notpriority. The actual precise polling interval may become longer than this, if theprocessing load is high. Used in the Terminal Server side only.

Same as in polling interval, but is the interval at which terminals marked as prioritywill be polled. Usually this interval is less than the standard interval, but it does nothave to be.

Time a Terminal Server will wait for a response to a poll (in seconds).

The number of polls an active terminal (standard or high priority) does not respond to, ina row, before it is marked inactive. Used in the Terminal Server only.

The number of times the IRM will retry sending a message that has been Nak�d,before it will give up and discard the message. Used in both the Terminal Serverand Host Server.

Specifies the interval between the periodic update message that keeps the terminaltables in each unit in sync. Typical times are 5 to 15 minutes. Used in both HostServer and Terminal Server.

Used in both HS and TS. The amount of time a protocol session will remainsuspended waiting for the RF link to come back up. When this times out, allmessage queues are cleared and the polling mechanism is reset. Typical times are10 -30 seconds.

Config Parameter Definition

6 - ISO Poll/Select Application



The Terminal Server polls at the rate specified in theconfiguration, either the standard or priority interval,until a response is received. When a terminalresponds, the Terminal Server sends back a DeviceStatus network message to the Host Server, whichcauses the Host Server to begin responding to pollsor selects.

When selected, the Host Server will send themessage over the radio network to the TerminalServer connected to the specified device address.At the next opportunity, Terminal Server will thenselect the device and send it the message.

The Terminal Server constantly polls the terminals inits table at the operator-specified rate. When aterminal responds with a message, it is sent over theradio network to the Host Server where it is helduntil the next poll.

Both the Terminal and Host Servers contain suffi-cient memory to buffer many messages. Theavailable buffer space depends on many factors,such as number of multidrop terminals and what isother applications are running. The remaining bufferspace can be determine in the periodic diagnosticmessage (see section 4.3).

Config Parameter DefinitionThe maximum size, in bytes of a legal data link frame, starting from the Start ofHeader (SOH) character up to (and including) the Block Check Sequence(BCC) character. Messages longer than this will be rejected. This limit preventstransmissions with missed End Of Text (ETX) characters from waiting foreverfor the end of a message.

Used to enable the diagnostic text output to the designated diagnostic port.Useful when debugging a protocol interfacing problem.

Operation

Theory of Operation

The emulation process is based on an internalterminal (or device) table that is set with all theprotocol parameters at configuration time. The tablecontains an entry for each terminal to be emulated.

NOTEPolling emulation is performed only for terminalsthat are specified in the configuration. If commandsor messages are for terminal addresses not listedin the configuration, they will be ignored.

At startup, after each node has established a CEMAnetwork connection, the Host and Terminal Serversexchange Session Start messages. These make surethat the terminal tables in each node agree. TheHost Server will update the Terminal Server with itsportion of the master table if the two do not agree.

Polling emulation begins at the Host Server. TheHost Server remains in an Idle state until it receivesa poll or select command. If a poll/select commandis received for one of the pre-configured terminals,the Host Server sends out a Device Status networkmessage (or a complete Terminal Table networkmessage containing the status for all devices), tellingthe Terminal Server to start polling.

Max Frame Size

Debug Enable


Port LED Display

The port LED can be in one of four states:

OFF: This port has no radio link established. Protocol emulation will still run but messageswill not go back and forth across the radio network.

SLOW Blink: Radio link established for this port, but no port activity.�Host Server: not receiving polling for any configured terminals.�Terminal Server: not sending any polls, no terminals activated.

FAST Blink: Radio link OK, with one-way port activity.�Host Server: receiving polls but not responding since it has not received an activeterminal status message from the remote end .�Terminal Server: sending polls but not receiving any responses yet.

ON: Radio link OK and two-way port activity. IRM has polling and responses for at least oneterminal.

LED State Meaning



Network Messages

There are several network messages that thisprotocol sends to maintain the emulation and ex-change data and status. These will appear on theNetwork Manager�s Realtime Activity display. Usethis display when debugging terminal polling activityor message exchange problems.

One or more messages sent for every data frame transferred at the port. Only the numberof bytes sent over the radio network is displayed. This may be less than the actual number ofbytes at the port because of compression.

Only sent by Host Servers toTerminal Servers. First lists the number of devices (or termi-nals) specified for this Terminal Server and then for each device, lists the following informa-tion:� Device Address (in hex)� Device Existence: always Static� Device Status: Null (error), Active, Inactive, Wacked, Not Started, Tentative (not

used), Starting, Excluded� Target Number: internal number specifying the index into the multidropped array� Polling Interval: (in seconds)� Number of Missed Polls: number of missed responses to a poll.

Similar to device table, but only for one device.

Contains the CEMA node address and port number of the sending station along with terminaltable information: the number of terminals in the table and a checksum of pertinent data inthe table. The receiving station can use this to verify that its terminal table agrees with theremote end. The Terminal Server always sends a Session Start message in response to aSession Start. The Host Server will respond only if the checksum does not match, in whichcase, it responds with a Device Table message.

Data

Device Table

Device Update

Session Start


Message Name Description


Diagnostics

Note that many software segments (CEMA networkcontrol or other applications) use the diagnostic portto report their progress. As such, diagnostic reportsfrom different segments will be intermingled. Refer tothe Diagnostic section of each individual applicationyou have in your IRM if the diagnostic messagecannot be found here.

Startup Diagnostics


Identifies the port baud rate selected

Identifies this port was configed as a Poll/Select Host Server, with nn terminalsentered. Each configured terminal is listed with its address aaaa in hex and itstarget (the Terminal Server which will poll it) listed as CEMA link ll, port p.

Identifies that the application was configed as a Terminal Server.

A Start Session message has been sent to target # [0 thru n]

Poll/Select application attempted to send one of the session coordinationmessages, and it failed. The numeric code is a memory manager return valuethat corresponds to the Put_Message failure. This message usually occurswhen the radio link is down during a session establishment.

Received a Start Session message. If delaying... appears, it means that theradio link is not fully up in both directions, so the responding Start Sessionmessage will not be sent immediately.

A Change Connection Status event has just occurred for port p, indicating thatthe radio link has just gone up or down. State s is an internal state variable forthe session control layer.

Baud Rate

Port x is P/S Host Server:# Terms: nnAddr: aaaaTarget: llp

Port x is P/S TerminalServer

SS Msg to Tar#

Send_Session_Msg failednn Put_Message failure.

Rcvd SS Msg [delaying...]

Connect_Change, port p,state s




Runtime Diagnostics


Nt Cntrl to Tar # x:

Rcvd Nt Cntrl [bad]

Send_Net_Cntrl failed nn

RcvdPoll: aaaa

RcvdSel: aaaa

RcvdSpecSel: aaaa

Sending Msg

Sending EOT

ACKing Sel

NAKing Sel

RcvdEOT

Indicates the Poll/Select software has sent a terminal table or devicestatus type message (polling network control message). These messagesoccur at startup or whenever the polling state (active or inactive)changes. x indicates to which multidrop target node number (starting from0) the message was sent. If the node is a Terminal Server, x is alwayszero.

Indicates the Poll/Select software has just received a terminal table ordevice status type message (polling network control message). Thesemessages are expected at startup or whenever the polling state (active orinactive) changes. The word bad should never appear. It means thereceiving unit could not decode the control message. Probable cause isincompatible versions between host and terminal server software.

Poll/Select application attempted to send one of the polling networkcontrol coordination messages and it failed. The numeric code is amemory manager return value that corresponds to the Put_Messagefailure. This message usually occurs when the radio link is down during asession establishment

RcvdPoll: aaaa A poll for address aaaa (hex) was received in the port.

RcvdSel: aaaa A standard select for address aaaa (hex) was received inthe port.

A fast, broadcast or grouped select for address aaaa (hex) was receivedin the port.

A message is being sent out the port, either in response to a poll (HostServer) or select (Terminal Server).

Sending an EOT in response to a poll (no message ready).

Attempting to send an ACK out the port in response to a select

Attempting to send an NAK out the port in response to a select becausethe device is busy: the IRM�s buffers are too full to accept anymore data.

Received an EOT in response to a poll (Terminal Server only).


RcvdSOH

Poll Timed Out

Sending poll: aaaa

Sending sel: aaaa

Sel timed out

Rcvd Ack

Rcvd Nak

Rcvd Unk, NAKing

SentMsg time out

RcvdEOT after AckNak

Bad Cksm

No ETX

Rcvd Msg hhhhhh

Sent Ack

Sent Nak

Rcvd Nonsense


Received a message in response to a poll (Terminal Server only).

No response to a poll was received within the timeout period.

Sending poll to device aaaa (in hex).

Sending select to device aaaa (in hex).

No ACK was received for the select operation within the poll timeout period.

ACK was received in response to a sent message.

NAK was received in response to a sent message.

Unable to decipher the response to our sent message, sending a NAK in return.

No response was received to our sent message.

Received the normal EOT response to our ACK or NAK transmission.

Block Check Character (BCC) of the received message did not match thecalculated result, rejecting the message.

Received message did not contain an ETX character at the end, rejecting themessage.

Received a message with header hhhhhh (in ASCII).

Sent an ACK is response to a received message.

Sent a NAK is response to a received message.

Could not decipher response, or unexpected response for a given state.


Documents

COLLISION ELIMINATION MUL TIPLE A CCESS CEMA REFERENCE MANUAL · CEMA Reference Manual Œ Getting Started Sec 1 Ł Pg 1 11/98, III - 3 1.1 -A bout this Manual The CEMA SYSTEM IIIﬁ