AU639665B2 - Distributed intelligence network - Google Patents

Description

OPI DATE 29/11/90 INT N AOJP DATE 10/01/91

INTERN

(51) International Patent Classification 4 HO4J 3/26, 4/00, 3/06 APPLN. ID 40625 89 PCT NUMBER PCT/US89/01806 q TREATY (PCT) (11) International Publication Number: WO 90/13956 Al (43) International Publication Date: 15 November 1990 (15.11.90) (21) International Application Number: (22) International Filing Date: PCT/US89/01806 28 April 1989 (28.04.89) (71)Applicant: FIRST PACIFIC NETWORKS, INC. [US/ US]; 1170 Kifer Road, Sunnyvale, CA 94086 (US).

(72) Inventors: CHU, Chi-Chi 3119 Mauricia Avenue, Santa Clara, CA 95051 SANGAMESWARA, Shanobhog 10200 Miller Avenue, Apartment #306, Cupertino, CA 95014 VITA, Peter, Paul, Lugtu 4928 Northlawn Court, San Jose, CA 95130 OUYE, Michael 840 Boyce Avenue, Palo Alto, CA 94301 STEVENS, David, F. 1090 North Clark, Mountain View, CA 94040 BARANSKI, Celeste 840 Boyce Avenue, Palo Alto, CA 94301 MONSSON, Cai, U. 4384 Belvedere Drive, San Jose, CA 95129 MURPHY, Timothy, Patrick 1074 Morton Court, Mountain View, CA 94040 MURPHY, Kevin, Thomas 335 North Clark Avenue, Los Altos, CA 94022 SALDING- ER, Alan 10340 Vicksburg Drive, Cupertino, CA 95014 CRINGLE, Robert, J. 2474 Alvin Street, Mountain View, CA 94043 McNAMARA, Robert, P. 836 Tatra Court, San Jose, CA 95136 ELLIS, Gary, M. 3165 Morris Drive, Palo Alto, CA 94303 (US).

GHATE, Ranjit 1170 Kifer Road, Sunnyvale, CA 94086 (US).

(74) Agent: SLONE, David, Townsend and Townsend, One Market Plaza, 2000 Steuart Tower, San Francisco, CA 94105 (US).

(81) Designated States: AT (European patent), AU, BE (European patent), CH (European patent), DE (European patent), FR (European patent), GB (European patent), IT S(European patent), JP, KR, LU (European patent), NL (European patent), SE (European patent).

Published z 6 With ai hre (54)Title: DISTRIBUTED INTELLIGENCE NETWORK USING TIME AND FREQUENCY MULTIPLEXING (57) Abstract A distributed intelligence network (10) using time and frequency domain multiplexing. On power-up, each node (20) determines its skew and requests downloading of program code and configuration data. A node claims timeslots by transmitting a packet into an apparently empty timeslot and verifying receipt of its own packet.

See back of page WO 90/13956 PC/US89/01806 1 DISTRIBUTED INTELLIGENCE NETWORK USING TIME AND FREQUENCY MULTIPLEXING BACKGROUND OF THE INVENTION The invention relates to communication networks and, more particularly, to a distributed intelligence network using time and frequency multiplexing.

Many office telephone systems are based on a private branch exchange (PBX) wherein all telephones are connected to a central switching device ("switch"). The switch provides connections amongst the various on-site telephones (extensions) and connections between on-site telephones and the public switched networks. So that it may support the various features (call waiting, call forwarding, conferencing, etc.) that many users have come to expect and require, the switch has had to become a rather powerful computer with a large amount of complex software. The telephones have also become more complex, and software for certain of the features are programmed locally at each phone.

The PBX system works well for the most part.

However, since every communication must go through the switch, a malfunction at that point may well have the effect of shutting down the entire system. Moreover, unless the system is configured with dual processors, modification of the switch software and configuration data may require that the whole system must be shut down.

For data communications, several different architectures are used. In a star network, all the terminals are coupled to a central point of the star, which provides centralized control of the flow of data.

The central control on such a system can time-division WO 90113956 PC/US89/01806 -2 multiplex data from different terminals by alternately holding data from one or the other transmitting terminal in a buffer until its timeslot is available. The central control unit provides the synchronization necessary to insert the data into the respective time slots.

Unfortunately, the star network suffers from several disadvantages. The bandwidth available through the switch matrix is limited, as well the integrity of the data passing through the switch. Furthermore, it is difficult to lay out the wires, because a new wire from the central control to the telephone must be laid each time a new telephone is added. In addition, a failure of the centralized control system disables the entire system.

Another data system architecture, and one which is easier to lay out, is a ring network. In a ring network, a single cable passes through each and every data terminal, aiV thus, network bandwidth is shared.

Rather than rely on assigned' timeslots or the acquisition of timeslots, bandwidth multiplexing employs the token method. In this method, a token is passed from one terminal to another, with the terminal desiring to transmit holding onto the token. A terminal cannot transmit unless it has the token, and therefore only one terminal will be transmitting at a time. This type of time-division multiplexing thus transmits data in irregular bursts, rather than regular assigned timeslot lengths. This type of transmission is appropriate for data communications, which typically occur in infrequent, long bursts. Voice communications, on the other hand, require a continuous connection over an extended period of time.

An alternative architecture for preventing errors due to two users attempting to acquire the network bandwidth simultaneously is used in the Ethernet system.

In this system, before a terminal may transmit it listens WO 90/13956 PCT/US89/01806 -3to see if the network bandwidth is being used.' Then while transmitting, the data terminal listens to determine if the data transmitted ip received in the same form. If the received data differs, then another terminal transmitted at th same time, resulting in a collision and thus scramkiled data. The transmitting station then stops transmitting and retransmits a random amount of time later. Thus, central control of the network bandwidth acquisition of timeslots is not needed.

Because data transmizsions occur infrequently, the chances of a collision on the second transmission are low. The chance of a collision increase as the number of terminals coupled to the system increases. Such a system is ill suited for voice traffic since the number of collisions will increas6 for voice communications which require continuous transmissions over an extended period of time. Additionally, the delay through the network is not fixed.

One approach which combines voice and data not using the private branch exchange is disclosed in Pa'ent No. 4,470,140 to Coffey, entitled "Distributed Switching Network The DSN system is built around a multiple bus network. In the DSN system, the communication media consists of twisted pair. For the network to operate properly, at least three paits of cabling must be laid out. This cabling acts as the backbone for the DSN system. One pair is used for transmitting information toward the Line Group Central Shelf and the other two pairs are used in a loop back arrangement for receiving transmissions from either other units or remote units through the Line Group Central Shelf, Each transmit and receive line is subdivided into frames and further subdivided into timeslots.

Communication between any two units in this network requires that each unit seize a timeslot for its own transmission needs and that it receive and read the WO 90/13956 PCFIUS89/01806 4 timeslot of the other to provide two way communication.

One of the major assumptions of the DSN syntem is that the buses are synchronous, that is, no allowances are made on the bus for signalling overhead or time of flight. Each timeslot has been partitioned to accept one byte of information, and thus, there is no room for timing errors.

The DSN system itself consists of two major units, Parallel Access Communications Interface Blocks (PIBs) and the Line Group Central Shelf. The PIBs are used to interface communication equipment to the network.

The PIBs are connected in parallel across the transmit lines and across the upstream portion of the looped back receive lines. The implication of the parallel access is significant in that when a PIB transmits onto the common transmit bus, the transmission is sent both upstream and downstream. The Line Group Interface Shelf (LGIS) is the terminus point for all of the cabling in the DSN System.

The LGIS provides network timing, switching between transmit and receive lines, switching between in-house calls and the Public Switched Telephone Network, as well as all of the network control functions.

When a PIB wishes to transmit information, two events.occur. The PIB Transmit Line first derives timing information so as to identify when to transmit on the transmit bus. This timing informatioh is generated by the Line Group Central Shelf and sent out on the receive line. By examining the status of the receive and the transmit lines, the PIB is able to ascertain that a particular timeslot is available. This determination of whether a timeslot is available is completely dependent on the parallel connection of the PIB to both the transmit and receive lines.

SUMMARY OF THE INVENTION 4A According to one aspect of the present invention there is provided a communication system for exchanging information between a plurality of nodes, comprising: a unidirectional transmitting medium coupling each of said nodes to a head-end of said transmitting medium; a unidirectional receiving medium extending from an originating end to each of said nodes; head-end translating means for transferring signals received at said head-end of said transmitting medium to said originating end of said receiving medium; means for generating a periodic timing mark on said receiving medium, each interval between a pair of timing marks being a frame, each frame defining a plurality of timeslots; means for transmitting a test signal from a first node on said transmitting medium; means for receiving said test signal at said first node on said receiving medium; means for calculating an elapsed skew time between the transmitting and receiving of said, test signal; 2 means for transmitting information for a specified timeslot an amount of time equal to said skew 25 time prior to the arrival of said specified timeslot at .said receiving means; and wherein said transmitting medium and said receiving medium are separate frequency channels on a single physical medium and said translating means is a 30 frequency translator.

I S te 9 I 122003.A General A preferred embodiment of the present invention is directed to a distributed communications network which provides numerous advantages over known communication systems.

The apparatus and methol'.; according to the present invention operate an a single communications medium yet provide a broad band network facility which can support all of the voice, data and video communications needs of a particular user. To do thLs, each node in the network may assign traffic type (voice, data and video) to a different portion of the network medium's flF spectrum.

Each separate frequency band thus comprises a subnetwork.

Subnetworks may be designed and engineered for specific services and a particular grade of service. For example, data networks can be designed and engineered for high speed transport, network availability, and/or data integrity. Partitioning the communication services in this way allows the subnetworks to be administered and run by separate entities the telecommunications department and the data processing department) each independent of the other (provided, of course, that each :i does not overlap the other's frequency domain).

The apparatus according to one embodiment of the present 25 invention is modular and incrementally expandable. *The interconnect is designed for easy installation# and user equipment can be added or moved without trained service personnel, network reconfiguration, or software changes.

Because of the distritbuted nature of the interconnect, any failure of a sinqle element will not effect the 4, operation of the ret.ning network. Thus, network additions, deletions, or .nodifications are transparent from an overall network performance and operational Iperspective. The independence of services between 3S subnetworks also allows the interconnect to be expanded and modified independent of the other subnetwork services. For example, if a business' data raquiraments WO 90/139 56 WO 9013956PCr/US89/01806 -6were to expand, additional network attachments may be made completely independent of the voice and video circuits already attached to the system. older local area data networks the network interface units, not the network medium) can be retired and replaced with newer, higher speed, more cost effective equipment, without effecting either the voice or video portions of the interconnect system.

In a preferred embodiment, invention is implemented in a voice system that uses time domain multiplexing. A timing mark generator broadcasts periodic timing marks that define a series of frames; a leading portion of each frame defines a signalling packet interval and a later portion of the frame defines a number of timeslots. The frame rate and timeslot width are such that one direction of a voice communication can be supported on a single timeslot on alternating frames.

The other direction is supported on the same timeslot on the interleaved alternating frames.

The intelligence is distributed and each node has its own operating software and configuration data, which are stored in RAM. This software and data maybo updated from time to time, and may be lost in the event of power loss. Each node also has a boot ROM1 it Which is stored a small amount of software to enable the node, at power up, to participate in the acquisition of the full operating software and data.

fot 2 o re d e~oc~wq'V f A 4Aplresent invention provides a technique for providing boot images (operating software and configuration data) to network nodes in a distributed commuting/communications environment. The protocols for providing boot images to nodes can be carried but with minimum disruption to ongoing network operation in tho event that only some of the nodes require service. The

V

WO 90/13956 PCT/US89/01806 7 boot process is both general and specific, it can boot either a specific node or the entire network concurrently.

The system includes one or more network boot units whose function is to maintain the operating software and configuration data in non-volatile memory (such as hard disk), and transfer copies (referred to as boot images) to the nodes at power up or for updates. For boot operations, the timeslots, normally reserved for voice, are used for data transmission.

In order to transmit boot images to a selected group of network nodes, referred to as boot consumers, the NBU must receive a boot request from a boot consumer.

The NBU then broadcasts a boot control signalling packvt ("IBCSP"I) having an image descriptor portion that describes the boot image to be transmiitted and a control portion that identifies the packet as a BCSP, specifies the class of boot consumers, and designates the timeslot(s) in which the boot image is to be transmitted.

During the transmission of a boot image, the NBU periodically sends out BCSP's so that boot consumers that were not in a position to receive the boot imago at the beginning of the transmission can pick up in midstream.

A boot consumer requiring a boot image has executable code in boot ROM, whereupon it listens for BCSP's from the NBU, determines whether any detected BCSP's specify tho desired type of boot image, and if so, causes data appearing in the appropriate timeslots to be read into local memory. Once the boot image has ben read in, the node can begin executing it. If a BCSP specifying the dewtead type of boot image is not detected within a certain time, the boot consumer sends a boot request signalling packet (tBRSP"), and continues to listen for BCSP specifying the desired type.

Each boot consumer is programmed to have a random wait period before seanding out a BRSP. Thus, if WO 90/13956 PCr/US89/01806 8 there are many nodes requiring the same type of boot image, the earliest boot request will be responded to by the NBU, thereby obviating the need for further boot requests by other units programmed to make their requests later.

If the system contains more than one NBU, the first NBU to receive the request, assuming it has the requested boot image and is not currently downloading a boot image, services the request in the manner described above. NBU's arbitrate amongst themselves to determine which of them is to respond to a given incoming request.

Each NBU sends a BCSP that identifies the sending NBU but specifies no time frames to be allocated. Each NBU then listens for BCSP's, and in the event that it first receives its own BCSP, it assumes responsibility. If it first receives a BCSP that originated from another NBU, it does not attempt to service the request.

kew c uati 14, pr,_rcrreA &mbod^4^i orP 4Ae _W-h*present invention provides a network having a wide bandwidth communications channel. This channel is organized architecturally as a time-ordered bus. All the nodes of the system are coupled to both the transmitting medium and the receiving mediumo The network bandwidth is (subdivided into timeslots. Timeslots are defined by a timing mark generator, with each node detecting the timing marks on only the receiving medium. The tie between each timing mark defines a frame, with each frame consisting of a plurality of timeslots. In this network, each node may be a different physical distance from a central turnaround point or head-end, resulting in each node transmitting in a different time relative to the received timing mark due to the differences in transmission time to the head-end and back. Accordingly, each node transmits a test signal and measures the time after the transmission until it receives the test signal Z, WO 90/13956 WO 9013956PCJ7/US~j9/01806 9back again. This time, designated a skew time, is used for transmissions of information. In all subsequent transmissions, each node transmits at a time equal to the skew time in advance of the timeslot it is attempting to transmit into.

The network employed in this invention is medium independent. In one embodiment, the transmission medium is a broadband CATV cable with a transmitting and receiving channel defined by different frequency bands.

The head-end of the system includes a frequency translator for translating the transmitted signal from the transmitting channel onto the receiving frequency band of the receiving channel. The system permits multiple channels* increasing the number of users that can be attached to the system. information is transmitted asynchronously within a timeslot, thus eliminating the need for precise synchronization to place a transmission packet within a specified timeslot. Each channel may contain a plurality of signalling t~rheslots and voice transmission timeslots. Each frame preferably has a first portion assigned for signalling packets and then a plurality of timeslots for voice communications.

When one node desires to call another, an identifying signal is transmitted in the signalling portion of the time-divided channel and is designated the signalling channel. When the called node receives the signal, it transmits an acknowledgment signal in the signalling portion. The calling node then signals a specified timeslot in which digitized voice or data is to follow.

Either node may direct the other node to switch to another timealot or channel for communication. This may be done, for instance, where one channel is extremely busy. Preferably, for two-Way voice communication, the first node would transmit in the specified timeslot in every othar frame, with the second node transmitting in the frames it between.

WO 90/13956 PCT/US89/01806 10 Data and digitized voice are both sent in the same manner, thus simplifying the circuitry required.

The signalling channel employs a slotted ALOHA type collision detection system, with each node monitoring on the receiving line to determine if the signal transmitted received in the same form. If :ollision is detected, the node waits for a random amount of time and attempts to transmit again. Collisions within voice timeslots employ an ALOHA collision technique whereby a test signal is inserted into a supposedly vacant timeslot and the received signal is compared with the original.

If the test signal is returned undamaged, the timeslot is considered seized. If an error is detected, the node waits, seizes another timeslot and the process continues again. Before transmitting, the node must determine that the timeslot is available for a series of frames. Once a node has acquired a t!,meslot by transmitting in it, it will retain that timeslot for the duration of the communication. Other nodes will detect data being transmitted in that timeslot, and will not attempt to acquire that timeslot.

Establishing Voice Telephone Link Another aspect of the present invention is the unique method of claiming a voice timeslot by individual telephone stations in distributed intelligence network.

One station generates a periodic timing mark, and the remaining stations monitor the timing mark and also monitor which timeslots following the timing mark are busy with transmissions. An individual station placing a call dynamicly chooses a free ti~eslot and begins transmission, In the event of a collision, another timeslot acquisition is attempted. Thus, there is no need for a central assignment of timeslots.

In particular, certain timeslots are set aside for control data, and others for voice data. A voice WO 90/1 3956 PCITUS89/01806 11 timeslot is first claimed, and then a signalling packet is sent in a control data timeslot. The signalling packet has destination address, and also contains data on the originator's address and the position of the claimed timeslot. The signalling packet is sent over a plurality of channels, and also specifies the correct channel frequency channel) of the originator. The originator's channel is then monitored for a response.

The receiving station will attempt to claim another timeslot having a predetermined relationship to the already claimed timeslot, for a response. Upon such a successful claiming an appropriate signalling packet is sent to the originat:ing station, and voice communication can then commence by the placement of voice data in the appropriate timeslots.

Session Laver The present inventio 4 eyidee a series of techniques for establishing, maintaining, and terminating voice communications between nodes in a network, and provides techniques for controlling communications when a user invokes features on a telephone.

In a preferred embodiment, the invention is implemented in a system that uses time domain multiplexing. A timing mark generator broadcasts periodic timing marks that define a series of cycles.

Each cycle includes at least one interval that defines a signalling packet interval while remaining portions of the cycle define a number of voice timeslots The cycle rate and VTS width are such that one direction of a voice communication can be supporttd on a single VTS. Designated pairs of VTS's in a cycle define a voice circuit capable of providing full duplex 3S communication. Each node is interfaced to a common broadband medium, and may provide trunk interfaces or telephone interfaces. A typical telephon call entails

C"

4 t -4 WO 90113956 PCI/US89/01806 12 an exchange of SP's between the nodes and a claiming process wherein vacant VTS's are claimed for the duration of the communication.

When a user takes a telephone off-hook and dials an extension, the node associated with that phone (first node) claims a first VTS of an apparently unused VC. The claiming entails having the node transmit a Claiming Voice Packet onto the VTS, and verifying that the node's own CVP comes back intact. Upon successfully claiming the first VTS, the first node transmits a Call Request SP addressed to the second node.

The second node, upon receiving the Call Request SP, sends an ACCEPT SP, which the first node acknowledges with an ACK SP. When the designated phone at the second node goes off-hook, the second node claims the second VTS of the VC, thereby completing the voice circuit. Upon successfully claiming the second VTS, the second node sends an ANSWER SP to the first node, which the first node acknowledges with an ACK SP. Thereafter, each node transmits voice data in its claimed VTS 4nd receives voice data from the VTS claimed by the other node. When either party goes on-hook, a disconnect SP is sent by the terminating station and the connection is terminated.

jcig (so The inventlonA ontemplates an exchange of SP's to invoke various features. For example, a hold feature wherein an ongoing conversation may be suspended by the first node is invoked by having the first node send a HOLD SP to the second node while ceasing to receive, and when the second node acknowledges with an ACK SP, it stops transmitting into its claimed VTS. The first node may periodically transmit CONTINUE HOLDING SP's and the second node will respond with CONTINUE-TO-HOLD SP's.

When the first node wishes to reestablish communication, it claims a new VTS, and sends an UNHOLD SP. The second node claims the remaining VTS of the VC and returns an ACK SP. The first node then transmits and receives and j 2 WO 90/13956 PCT/US89/01806 -13- VP's are exchanged.

Time-Freguency Multiplexing Another aspect of the present invention is the unique method and apparatus for implementing tiiundivision multiplexing. A plurality of different frequency channels are used, preferably four. Each channel has an upstream and a downstream frequency band.

Transmissions from any node occur on a particular channel in a timeslot in that channel and are routed on the upstream frequency band to a head-end return unit, which translates the signals into the downstream frequency band of the channel, and transmits them on the downstream frequency band. A timing mark generator is coupled to the system so that it can simultaneously generate timing marks on all four channels, thus synchronizing the various frequency bands. Each channel circuit in the head-end unit has its own clock, which is phase locked to a master clock to synchronize all 4 channels. In addition, the head-end unit contains a fast digital phase lock loop to allow a quick phase look on the first few bits of a data packet sent by a transmitting node. Each channel of the head-end return unit is phase looked to the same clock as the other channels# providing an.

additional element of synchronization. This combination of different synchronizing elements allows a practical time and frequency multiplexed system to operate.

synchronization is maintained between timing marks through the use of a pseudo-silence pattern (alternating i's and 04s) which is inserted at the headend unit. This will allow a phase lock to be maintained at the individual nodes in-between timing marks by, providing alternating data. The system thus allows each transmitting node to include only a single modem which can shift its frequency from one channel to another and still maintain synchronization. The only elements which 14 need access to all channels simultaneously are the headend return unit and the timing mark generator.

Maximum- LikSelihood Detector *MLDn The digital phase lock loop is also referred to as a maximum likelihood detector (MWD). This device is necessary to quickly phase lock upon a data packet. A '$pad" time where no transmissions occur is added by convention at the beginning of each packet to allow the MLD to reset. The MWD accepts the data after it has been demodulated and converted back into digital form. The data is provide~d into a shift register at a clock rate much higher than the data rate. A bit synchronizer then compares the various shifted outputs to determine which has an edge closest to the HIRU clock. once that determination is made, that shift register output is used for the remainder of the data packet, without further readjustment.

Preferred embodiments of the present invention will now be described by way of example only with reference to the accompanying drawings.

BRIEF DESCRIPTION OF THE DR~AWINGS Fig. A-1 is a block diagram illustrating a 30 typical physical organization of a communication network according to the present invention; Fig. A-2 is a schematic diagram of portions of tht network; Fig. A-3 is-a diagram showing the time astructure of signals on the network; fit W a3S Fig. A-4 is a schematic block diagram of a voice interface unit;* Fig. A-5 is a schematic block diagram of a WO 90/13956 PCT/US89/01806 15 network boot unit; Fig. A-6 is a flowchart of the boot ROM code; and Figs. A-7A and A-7B are flowcharts of the NBU code; Fig. B-l is a schematic block diagram of the RxTX circuit shown in Fig. A-4; Pig. B-2 is a schematic block diagram of the PCTL circuit shown in Fig. A-4; Fig. B-3 is a diagram showing the general time structure for P-RAM access; Fig. B-4 is a diagram showing signal input and output lines for the RxTx circuit, the PCTL circuit, and the P-RAM shown in Fig. A-4; Fig. B-5 is a diagram showing time slot marker pulses; Fig. B-6 is a diagram showing a delimiter search window; Fig. B-7 is a diagram showing the relationship between transmit and receive frame timing; Fig. B-8 is a diagram showing time slot pad times; Fig. C-I is a schematic diagram illustrating the transmission time differences to the head-end retransmission unit; Fig. C-2 is a block diagram of the circuitry for a connection at a node of the system of Fig. Al; Fig. C-3 is a diagram of the different frequency channels utilized in a communication system according to the present invention; Fig. D-l is a flow chart showing the claiming of a voice timeslot by an originating node; Fig. D-2 is a flow chart showing the claiming of a reverse timeslot by a called node; Fig. E-I to E-13 illustrate protocols for establishing and maintaining extension and trunk calls$ WO 90/13956 WO 9913956PCF/US89/01806 Figs. E-14 to E-35 illustrate protocols for implementing features invoked by the user; Figs. E-36 to E-38 illustrate protocols for terminating calls; Fig. F-1 is a block diagram of the HRU and its connection to the trunk interface units; Fig. F-2 is a block diagram of the phase lock synchronization of the four HRU channels; Fig. F-3 is a block diagram of a maximum likelihood detector (MLD); Figs. F-4 and F-5 are block diagrams of one channel of the HRU; and Fig. F-6 is a block diagram of the interface between the HRU and the trunk cards.

BRIEF DESCRIPTION OF THE TABLES Table A-1 is a list of abbreviations used in the application; Table A-2 sets forth the packet formats, Table A-3 is a map of the packet RAM ("1PRAM"1); Table A-4 sets forth the boot image format; Table A-5 sets forth the boot request signalling packet (11BRSP"1) format; and Table A-6 sets forth the boot control signalling packet ("1BCSP"1) format.

BRIEF DESCRIPTION OF THE APPENDICES Appendix I. is a specification for the transport layer software, setting forth the different transaction types supported.

.Appendix 2 is a specification of the software in the DRAM for controlling the communications.

Appendix 3 is a specification of the firmware for "Spike." Appendix 4 is a detailed specification of WO 90/13956 PCI/US89/01806 17 procedures for registration and de-registration of Voice and Trunk Interface Units.

DESCRIPTION OF THE PREFERRED EMBODIMENT Network Overview Table A-i provides a list of abbreviations used in the application.

Fig. A-1 is a block diagram illustrating a communication network 10 based on a bus medium 12. Bus medium 12 typically has the physical topology of a tree structure with a number of branches 12' to which various network nodes are coupled. The primary function of the network as described herein is to support voice communication among users on the network and between such users and the public switched network. However, network may also be used for data and video as well. The network contains no central intelligence for allocating bus resource. Rather, each node has its own intelligence providing it the capability of vying for :nd claiming bus resource as needed.

The network nodes include a plurality of voice interface units 20, each shown with one associated telephone 22, a trunk interface unit ("TIU") 25 having a plurality of trunk lines 27 for coupling to the public switched network, an attendant interface unit/console 35, one or more network boot units 40, each with its associated non-volatile storage such as a hard disk 42, and one or more timing mark generators 45. Bus medium 12 is coupled to a head end retransmission unit 50. An /O processor 51 couples TXU 25 to HRU 50. A network manager workstation ("NMWS") 52 with an associated hard disk 53 is coupled to the NBU and its disk. A VIU may be single-port LAavice with one phone as shown, or may be a multiple-port device (up to 24 ports) with each port capable of supporting a phone.

WO 90/13956 PC'/US89/01806 18 In a present implementation, NBU's 40 and HRU are physically located within the same cabinet as TIU, and timing mark generator 45 is incorporated into NBU Thus there are no separate enclosures for TMG 45, NBU or HRU Each node has associated address information.

This includes a 6-byte physical unit address ("PUA") which is a hardware embedded serial number unique to that node with respect to any other node in any network made by the same manufacturer. Uniqueness with respect to nodes made by different manufacturers can be guaranteed by agreement between the manufacturers or the establishment of a central PUA issuing authority.

Nodes can also be assigned a 2-byte local unique address by the network manager. The LUA is unique with respect to other nodes at a given customer site. It is possible to address all nodes at the same time with a broadcast LUA having u hexadecimal value

FFFF.

Nodes can also be assigned a 2-byte system link extension The same SLE may be assigned to multiple nodes, thereby permitting group addressing.

Conversely, a node supporting multiple phones may have more then one SLE.

Address comparison is performed as follows.

Each node contains a 64-bit hash table for each of PUA, LUA, and SLE address comparison. Since there are more than 64 possible addresses, the hash table mechanism does not provide a unique selection, but rather a first-level filtering only. Additional address selection is carried out by higher level softw&re. For the PUA and LUA hash tables, and for the SLE hash table where the node has a single SLE, one bit is set, that bit being in the position corresponding to the numerical value of the last 6 bits of the cyclic redundancy check of the node's PUA, LUA, or SLE, as the case may be. For a node with more WO 90/13956 PC/US89/01806 19 than one SLE, the SLE hash table has bits set for the multiple SLE's, the positions being determined as described above. Due to the lack of uniqueness, the number of bits set may be lfss than the number of SLE's.

Associated with each phone is a 2-byte configuration identifier which is stored in RAM and identifies the configuration (feature set, extension) for that phone. CID's are created by the system administrator at the NMWS. A unit's phone extension number can be used as the CID but this does not necessarily need to be true. Since each phone needs a configuration, multiple-phone VIU's will have multiple CID's. A special CID (value 0) is used to identify a configuration that if loaded into a unit, limits the unit's opeation to acquiring manually entered CID's.

Bus medium 12 .s preferably a broadband coaxial cable capable of supporting a number of frequency channels, each defined by a carrier frequency on which signals can be superimposed. Each user device can broadcast its transmissions on the cable toward HRU HRU 50 operates to receive signals on a first set of channels and retransmit them on a second set. Thus, twoway communications may be implemented on a single cable by frequency division multiplexing the available RF cable ,spectrum. The channels are preferably 6 MHz wide, with the transmitting channels in the range from 5-108 MHz and the receiving channels in the range of 175-400 MHz. In the preferred embodiment, there are four channels, each 3 with an associated transmit frequenty and receive frequency band, and each node is capable of operating on any of the channels. Each node is assigned a home channel on which it normally listens when not participating in a communication. Boot transmissions typically occur on a designated boot channel.

HRU 50 transmits a pseudo-silence pattern (PSP) alternating i's and 01s) when there is no incoming WO 90/13956 PCI/US89/01806 20 data. This allows the VIU'u in the network to always have an incoming data stream, which adds to the stability of the PLL's in all of the VIU modems and provides a less expensive and more efficient receiver and bit sync circuit. Additionally, the PSP acts as a "not" carrier detect, and the VIU's may consider the given channel as free when the PSP is received.

HRU 50 implements a data reclocking scheme to provide a constant phase data signal to the nodes. Since the upstream transmission is supplied by an unknown source with regard to phase (since the relative phase of the incoming packets varies with the physical position of the originating node), HRU 50 uses a Maximum Likelihood Detector (MLD) to reclock the downstream transmission.

The MLD detects the rising edges in the first four bits of packet preamble, and then delays the data path by a time of 0 to I bits (in increments of 0.062 bits) to properly align the center of the data bits and the edge of the sampling clock, With this method, no frequency lock is required since the downstream transmissions of HRU 50 are the system's source of master clock.

The described functions can be implemented with a high speed digital phase-locked loop that responds to the received packet's needs within a four-bit time span during the packet preamble. The selected delay will remain locked until a loss of carrier is detected at the headend which will be interpreted as an "End of Packet".

HRU 50 will then begin transmitting pseudosilence and reset the MLD for the next packet, Thus, while network 10 is physically and topologically organized as a tree, it is logically organized as a bus. The bus is logically a dual linear bus having transmit and receive channels 5S and 57 an shown schematically in Fig. A-2. While only two VXU's and two NBU's are shown, an actual system might have a hundred or more VU's 4 The representation of Fig. A-2 in WO 90/13956 PCT/US89/01806 21 schematic only, since there are not actually two physical buses, but rather a single broadband communications medium capable of supporting a number of communication channels.

Network Timing Fig. A-3 is a diagram showing the time structure of signals on the network. TMG 45 provides a series of timing mark packets transmitted simultaneously on all four channels, at 1-ms intervals, thereby defining a series ot 1-ms frames. The TM's also indicate whether they are on a boot channel, and provide the channel number.

The frames are logically grouped into pairs, each containing first and second frames, designated the forward frame and the reverse frame, with each pair defining a 2-ms cycle. Each frame consists of a timing mark, a 71-byte (60 data bytes) signalling packet and 28 19.5-byte (16 data bytes) voice timeslots each capable of containing a voice packet Each packet interval consists of a preamble of alternating lIs and O's, a delimiter, a data field, and a pad. The delimiter is a binary code specifying whether the packet is a TM, a VP, an SP, a claiming voice packet or a boot packet and is distinguishable from the preamble in that any 3-bit string has at least two bits in a row the same. Table A-2 provides a list of the various packet formats.

VP's are Used to provide voice communication and contain binary encoded (pulse code modulation "PCM") speech from a specific phone conversation. They are transmitted every cycle during the course of the conversation. An ongoing telephone conversation entails having VP's for one direction of the communication carried on a VTS of the forward frame and for the other direction of the communication on the coresponding VTS for the reverse frame. VP's contain no computer WO090/13956 PCI'/US89/01806 22 recognizable information. They are merely reconstructed into voice at the receiving node. A special voice packet, the CVP, is used to reserve a VP timeslot for data transmission/reception.

SP's are used for communications between nodes and contain computer recognizable information pe.tinent to the control of the network. While specific types of SP's will be discussed below, it is noted that an SP contains a data portion which includes a link header and a transport header as well as information specific to the type of SP. The link header contains source and destination address information, specifically: 2 bytes of destination address information (enough for an LUA or an SLE); an address control byte containing two 2-bit codes specifying the destination and source addrecs types (PUA, LUA, or SLE); a length byte; 4 bytes for the rest of the PUA if the destination address is a PUAI and 2 or 6 bytes of source address information.

BP

t s are used in boot operations to communicate configuration data and operating code from an NBU to other nodes. BP's are broadcast in the VTS's normally occupied by VP's.

Each node is characterized by a skew time related to its physical position on the bus. Skew time regars to the differential propagation delays resulting from the fact that the different nodes are at different distances from IIRU 50, The nodes most remote from the IMU will receive the timing marks latest in time, and would, if they merely synchronized their transmissions to the timing mark# transmit relatively late compared to nodes nearer the HRU. Accordingly# the further a node is from HRU 50, the earlier it must transmit relative to the timing marks to be in synchronization. A procedure whereupon each node dQtermines its own skew time is described later in this application. Xt essence, each node, on power-up, transmits an SP immediately upon WO 90/13956 PCT/US89/01806 23 receiving a timing mark, and counts the number of bit times (1/(5.018 MHz)) until it receives the same SP (as retransmitted by the HRU). This defines twice that node's skew time, and subsequent transmissions will be advanced by the skew time.

In the event that there are more than one TMG in the network, the TMG's arbitrate amongst themselves at power up to determine which is to become the master TMG.

Each TMG waits a random length of time (up to about ms), and then broadcasts TM's on all channels. If a TMG receives TMvs that it sent, it assumes the status of master TMG. The other TMG's assume the status of backup TMG's and monitor the four channels to ensure that the master TMG is sending valid TM's. In the event that TM's on any channel stop for some number of consecutive frames, the backup TMG's arbitrate to become the new master TMG. The arbitration process is similar to that described above.

sc Node Organization The hardware for a given node in the network includes certain portions that are essentially common to all nodes and certain portions that are different for the different types of nodes. The description in this section will be in terms of one of VIU's 20 and one of NBU's Fig. A-4 is a block diagram illustrating one of VIU's 20, the function of which is to interface one or more phones to the network. VIU 20, like other nodes, must be able to communicate on any channel. Access to multiple channels (only one at a time) is provided by a frequency agile modem 70. VIU 20 further includes a CPU 72 and associated memories, a codec 75 and telephone interface 77, and a control/interface circuit Other types of nodes in the network shar& the same basic hardwarm organization in the sense of having WO 90/13956 PCT/US89/01806 24 the same control/interface circuit elements, CPU and associated memories, and modem. However, other types of nodes would not include codec 75 or telephone interface logic 77, and would have different operating software and configuration data stored in their associated memories.

Some types of nodes (such as an NBU or a multi-port VIU) must be able to communicate on all channels at the same time, and are provided with a separate control/interface circuit and modem for each channel. Because each node uses the sams basic set of network elements for all configurations, the network is modular and incrementally expandable for both small and large telephone systems.

The memories associated with CPU 72 (preferably an a0186 microprocessor) include a packet RAM ("PRAM") 821 a DRAM 85, and a boot ROM 87. Control/interface circuit 80 contains a receiver/transmitter ("RxTx") 90, a packet controller ("PCTL") 92, a 3-port memory controller 93, and a PCM highway 95. PCM highway 95 is a 1.544-MHz, serial, full duplex highway which provides 24 6-KHz 8-bit timeslots (much like a T1 carrier). Also included in control interface circuit is a timing mark state machine 97 (shown in phantom since it isn't used in the VIU). In a preferred embodiment, control/interface circuit 80 is implemented in a 2-chip set, one chip containing RXTX and timing mark s!Ate machine 97, and the other containing PCTL 92, 3-port memory controller 93 and PCM highway Table A-3 provides a memory map of PRAM 82.

The PRAM contains, among other things, transmit and receive ring buffers for the PCM highway timeslots, tables specifying which network VTS's are free and which are busy, and boot buffers 100oa and 100b. Three-port controller 93 allows PRAM 82 to be accessed by RxTx PCTL 92 and CPU 72. The 3-port controller is responsible foz arbitration and control of all PRAM accesses, including accesses to buffers in PRAM 82 that WO 90/13956 PCr/US89/01806 25 hold incoming and outgoing packets.

RxTx 90 provides a 5.018-MHz serial interface to modem 70. It is at this interface that VP's and SP's are communicated. A phase-locked loop in modem recovers the system clock information (5.018 MHz in two phases) and provides it to RxTx 90. The RxTx generates transmit and receive frame boundaries and the timeslot boundaries within each of the frames. In most cases it uses its received frame as the time base and starts its transmit frame a skew time before. RxTx 90 is also responsible for skew calculation, preamble insertion and removal, and delimiter insertion, removal, and recognition. RxTx 90 also interfaces to CPU 72.

PCTL 92 operates under control of RxTx 90 and is kesponsible for voice and tone buffering and routing between network 10 and PCM highway 95. PCTL 92 also supports tone generation (dial tone, ring back, DTMF).

To send tones towards the handset, digitized samples of the tones are read from PRAM 82 and sent out on the codec bus. It also supports the transmission of tones to the network where DTMF tones nay have to be sent.

A key function of control/interface circuit is to route VP's, and to that end must keep track of the active VTS's on the network and map each of these active VTS's to one of the 24 voice ring buffers in PRAM 82.

The ring buffers are then mapped one-to-one to the 24 PCM bus timQslots in order to establish a connection between the network VTS and the codec. For receiving data RxTx 90 removes the preamble and delimiter, performs a serial to parallel conversion, and passes the data to PCTL 92.

The PCTL stores the data in the ring buffer and sends bytes to the codec as required. The ring buffers contain only the actual voice samples for VP's or boot data for BP's. For transmission# the PCTL receives PCM data samples from the codec, and stores them in the r-AM ring buffer. The PCTL thereafter provides the appropriate WO "0/13956 PCT/US89/01806 26 address information to RXTX 90, which appends a preamble and delimiter, performs a parallel to serial conversion, and transmits the data onto the network.

Fig. A-5 is a block diagram illustrating one of NBU's 40, the function of which is to download boot images (configuration data and operating software) to other nodes, referred to as boot consumers. As mentioned above, NBU 40 shares many common circuit elements with VIU 20 (and other nodes in the network). In particular, the NBU contains those elements described in connection with Fig. A-4 except codec 75 and telephone interface logic 77. While the NBU does not support telephones, it includes and uses the PCM highway to support conference calls. Those elements that do correspond are shown with the same reference numerals. Since, in the current implementation, timing mark generation is actually carried out by the NBU hardware, the NBU has four control/interface circuits and modems so as to be able to transmit TM's on all four channels simultaneously.

The NBU's CPU 72 interfaces with the NBU's associated hard disk 42 through a small computer system interface (SCSI bus interface) 105. The boot images are developed in an off-line development system and written onto floppy disks, which are loaded into NMWS 52 and stored on the NMWS hard disk. The boot images are then transferred to the NBU hard disk(s) independently of the network. Each NBU will typically have boot images for all of the nodes in the network.

General Software Organization The software in a given node is organized in a layered structure based on the International Standards Organization open System Interconnection Reference Model The OSI model contemplates an organization having some or all of the following layers: Physical; WO 90/13956 PCT/US89/01806 -27- Link; Network; Transport; Session; Presentation; and Application.

As will be described below, some of the layers are implemented using both hardware and software. Moreover, certain of the protocols have attributes that do not allow them to be classified in any single layer. Each of the layers will be discussed briefly, while more expanded description will be reserved for those layers pertinent to the present invention.

The physical layer is concerned with the interaction between the nodes and the network communications medium. Thus, the physical layer encompasses the modem and cable.

The link layer supports communications between nodes on the network, and is implemented using both hardware (most notably control/interface circuit 80) ad software. Some of the basic functions have been described above, some others will be described below in connection with the discussion of the operation of the network.

The link layer functions are as follows: monitoring TM reception for all nodes and supporting TM generation on certain devices; best effort delivery of SP's; selective filtering and verification of incoming SP's (using the hash tables); supporting boot buffer transfers; establishing, monitoring, and disconnecting voice circuits; transferring voice (with padding) from network to the codec; and transferring voice from the codec to the network; generating tone to the codec (with padding) and/or to the network; generating silence to the codec; performing diagnostics and reporting severe errors; and presenting statistics and minor errors WO 90/13956 PCT/US89/01806 28 gathered by the hardware.

The network layer provide a (channel) bridge for establishing communication between channels on the same cable, and between different cables, and will not be discussed further.

The transport layer is responsible for the reliable end-to-end delivery of data between host entities. This includes providing both best-effort and reliable datagram transfer services, built upon the service exported by the link layer. In a "pure" datagram delivery, transport makes a best effort to deliver an information (or a response) packet to the destination(s), but will not notify the requesting session entity if the delivery is not successful. A "reliable" datagram delivery entails delivery of a user information packet to the destination(s), with notification to the requesting session entity if transport is unable to deliver the packet. Transport also supports large data deliveries wherein a large data transfer request from a user entity is delivered to the destination(s) using a combination of both pure and reliable datagrams. If transport is unable to deliver the entire data without error, it will notify the requesting session entity. Appendix 1 is a specification for the transport layer software, setting forth the different transaction types supported.

The OSI model describes the session layer as the level that provides services required to establish and maintain connections between users across the network. It provides the following services: call establishment and disconnection functions between stations connected to a local area network; initiation and monitoring the voice communication path between the station set users; call establishment and disconnection functions for establishing voice communication between station users and the public switched network users; and implementing various end user features.

WO 90113956 PCT/US89/01806 29 Depending on the type of node on which it is executed, the sessionp layer has to provide different types of services to the higher layers. While it is possible to provide a common base code to some extent, the differences between such units as VIU's and NBU's make it difficult or impossible to Use the same session software on these different types of nodes. However, all the nodes utilize the same set of services and interfaces provided by the lower layers.

The presentation layer is in general concerned with the user interface. With respect to the network software running in the VIU's, the presentation layer is concerned with the duration and format of all the tones a user may hear from the handset, as well as controlling keyboard interaction and the format of messages displayed on liquid crystal displays for those phone models so equipped. A substantial part of these functions is actually implemented in hardware.

In the TIU, the presentation layer is limited to tone generation and detection. on the NBU, the presentation layer functions are really incorporated in the NMWS.

The application layer is in general concerned with the user application. In the current embodiment, the only application livel software implemented is the Network Manager. The Network Manager performs the following functions: node configuc-tion, downloading of configuration and code images to the network; monitoring, display and storage of network 4vents; network diagnostics; automatic route selection table generation; and remote network diagnostics.

The software for certain nodes an AIU interface to a microcomputerized console or a VIU interfaced to a microcomputerized feature phone named "Spike") contains additional coie to control the communications across the interface. Appendix 2 is a WO 90/13956 PCT/US89/01806 30 specification of the software in the DRAM for controlling the communications. Appendix 3 is a specification of the firmware for "Spike." C U Setup. Maintenance,. and Breakdown Consider now a typical phons call from one VIU to another. A station set is taken offhook and a local extension number is dialed. Since there is no central intelligence assigning VTS's to the various nodes, the originating device must first capture one. The control/interface circuit keeps track of the status of all the VTS's (busy or free) and attempts to claim the forward half of a free VS by transmitting a unique Claiming VP on that VTS and checking that it comes back intact. This assures that a VTS thought to be free is indeed free. All other nodes in the network see the Claiming VP on the VTS being claimed and change their PRAN-resident busy/free tables to specify that VTS as occupied.

Once the VTS is claimed, silence VP's are transmitted to maintain the circuit, and a Call Request SP is broadcast across the natwork. This SP is sent on all channels, and specifies the originator's home channel and the VTS that was claimed. This SP also contains information specifying the source LUA of the call originator and the desired group address (SLE) of the destination (since an extension number can appear at marty stations# it is considered to be a group address type).

All other Ptttious on the network receive the Call Request SP and compare the contents of the destination field within the packet to the extension numbers which are supported by the receiving station.

The Call Request is ignored if no match exists. Xf the 3S destination extension matches one of the extensions supported by the receiving station, and the destination is not busy# the destination sets itself to operate on WO 90/13956 PCIr/US89/01806 31 the originator's home channel, after which an Accept SP is sent back to the originator with the receiving station's LUA.

1 Since the LUA of the accepting station is included in the Accept SP, the originating station will know the specific station which has accepted the call.

Therefore, an Accept Acknowledgement SP is sent directly to the accepting station using LUA addressing to begin ringing at the destination station, and a ringback tone is sent to the originator's handset. When the destination station goes offhook, the reverse timeslot is claimed, indicating an answer. If the claiming is successful, an Answer SP is returned to the originating station. Silence VP's are now replaced with actual VP's.

After the conversation is over and either party goes onhook, a Disconnect SP is sent by the terminating station and the connection is terminated. If the destination is busy, a Busy SP is returned to the originator and the exchange ends with the originator receiving a busy tone.

Network Boot Unit and Protocols Nodes require the downloading of boot images when they are powered up, which occurs after a power failure, when they are first brought on line, or when they are disconnected and moved. Boot images are also downloaded when a new software release is to be installed on some or all of the nodes. Downloading typically occurs in two stages, first program code, and then configuration data. The program code is generally much longer than the data, and can be downloaded to a number of nodes at the same time. The configuration data is different for each nodae and must be downloaded on an individual basis. As will be described below, a node, having received its code image requires its CXD before it can request its configuration.

WO 90/13956 PCr/US89/01806 32 Table A-4 provides the format of a boot image file. Boot images are divided into blocks, with the size of each block depending on the size of boot buffars 100a and 100b in PRAM 82 (256 bytes each in the present implementation). As can be seen, the file contains an initial block having global information as to the boot image file, and a number of data blocks, each having the actual data Ond associated header information about the specific bloc=k (load address, block size, block number).

BPs, which occupy VTS's, are used to transmit boot images over the network. Each BP contains 16 bytes of data, which translates to a data rate of 64 kilobits/sec if only one VTS per cycle is used. In view of the possible large size of boot images, BP transmission and reception may occur on multiple VTS's, thereby providing higher data rates.

Boot transmissions occur in response to requests from boot consumers. Such requests are typically made when a node is powered up, either at the name time as the rest of the network, or after being connected to the network while the rest of the network has been tunning. A node requiring a boot image transmits a boot request SP ("BRSP") to request the image it needs. The NBU responds by sending boot control SP's ("BRSP") and BP's, as will be discussed in detail below.

Table A-5 sets forth the format for a BRSP.

BRSP's are sent to an address permanently assigned to NBU's and contain image descriptor information specifying the memory image being requested.

Table A-6 sets forth the format of a BCSP.

BCSP~s are sent on all channels and contain boot control and image descriptor information. Boot control specifies which channel, frame, and VTS('s) are used to transmit the image. The image descriptor provides information about the memory image itself. This information is statically bound to each boot image and resides with the WO 90/13956 PCT/US89/01806 33 boot image on hard disk 42. It is generated in the development environment and included as the header of the boot image file. It is extracted by the NBU to create the BCSP.

On power up, the boot consumer executes the code stored in its boot ROM. Fig. A-6 is a flowchart of the boot ROM code. Th-s node scans the various receiver frequencies to find a channel with timing marks. After identifying its unit type and boot channel, the node begins to receive and interpret SP's, waits for BCSP's identifying the necessary image, and transmits a BRSP if it does not receive the required BCSP within a certain random time interval (up to 50 ms). It performs its part of the boot operation according to the parameters specified in the BCSP.

Figs. A-7A and A-7B are flowcharts of the NBU code. Before transmitting the boot image, the NBU claims one or more VTS' (in the same manner as the VIU claims a VTS in a voice call), and transmits (on all channels) boot control SP's ("BCSP's") containing boot control information and image descriptor information about the boot image being broadceqt.

Multiple NBU's having the requested boot image arbitrate amongst themselves to decide which one is to respond to a BRSP. Upon receiving a BRSP, each NBU attempts to claim the service by adding the boot group address of the requested image and sending a BCSP with no VTS's allocated. If it receives its own BCSP (as determined by the source address) first, it will start the boot process by claiming one or more VTS's and sending a BCSP to the boot consumers. The downloaded image will satisfy multiple requests for the samea image.

BCSP's are sent a predetermined amount of time before the actual transmission of the specified block so as to allow the boot oonsumers time to receive the image.

They are also sent throughout the image transmission to WO 90113956 PCT/US89/01806 34 allow other boot consumers to start r' ceiving the image in the middle ot the transmission, with a second transmission being used to fill in the missing parts.

BCSP's are sent to group addresses, there being a group address assigned to each type of network unit. Boot ROM 87 in each unit, based on its unit type, can receive and filter for the corresponding BCSP.

There is also a procedure for downloading boot images to nodes that are not specifically requesting.

This is initiated at NMWS 52, which causes the NBU to send an SP instructinqgnode to take themselves out of service and then to come back up. On coming up, the nodes request the boot images as discussed above.

Boot packets are sent from and received into boot buffers 100a and 100b in PRAM 82. The control/interface circuit alternates between the boot buffers when retrieving or storing boot information, varying the delimiter to specify which buffer is to be used. There are two registers which control each direction of boot activity, the TX and Rx boot buffer and boot pointer registers (referred to collectively as the boot registers). Xn actual practice, units will never both transmit and receive boot information, but this facility is provided for diagnostic purposes. The boot registers are typically zeroed by software before starting boot transmission or reception. PCTL 92 controls (writes to) these registers during the boot process, so software should not write to the boot registers while the boot operation is in progress.

The Tx boot buffer register specifies the boot buffer (0 or 1) from which the next BP is to be fetched.

The TX boot pointer register points to the location in that boot buffer of the next UP. The Tx boot buffer register is toggled immediately after the last byte in a given buffer is read by PCTL 92. The Rx boot buffer register points to ths boot buffer (0 or 1) to which the WO 90/13956 PCT/US89/01806 35 next received BP is expected to be delivered. The buffer into which it is actually placed depends on the BP delimiter. The Rx boot buffer byte toggles after a BP is received which fills the current buffer, or immediately Vpon reception of a BP destined for the other boot buffer. The Rx boot pointer register always points to the next byte in the current boot buffer into which a BP is to be written.

As mentioned above, a node normally receives its code image first, followed by its configuration data.

Before a node can request its configuration data it must have its CID. If the node has just been powered up, it doesn't have its CXD. If the node is a TIU, it calculates the CID for each port based on its cabinet, slot, and port numbers. If the node is a VIU, it requests its CID from the NBU by sending a CID Request SP (with CID w A single-port VIU (needing only one CXD) identifies itself by its PUA. A multiple-port VIU makes separate CID requests for each of its ports, identifying itself on each request by its cabinet and slot numbers as wall as the port number. When all VIU'a come up at once, they could flood the network with CID and configuration image requests. To alleviate network congaestion, each device waits an amount of time based on its PUA before sending its CID request# If the requesting VIU has previously been installed on the system, the NBU has its CID in a table, and responds with a CID Rasponse SP. The CID Response SP specifies the CID and a backoff time for the VIU to wait before sending its BRSP requesting configuration data. If the requasting VIU has come up for the first timea, the NBU does not have its CID, and sends a CID Response SP (with CID w 0).

The VIU than uses this azero value CID to get a special configuration that only allows CID entry from the phoneo, no phone calls are possible with this configuration. A user picking up the handset hears an WO 90/13956 PCT/US89/01806 36 "Enter CID" tone instead of a dial tone. The user must then invoke the feature code to enter a CID, and hears no tone until the CID is verified. The VIU software receives the CID, and send a CID Request SP (with the non-zero CID) to register the CID with the NBU.

If the CID is unique on the network, the NBU responds with a CID Response SP that contains the CID.

The VIU gives a "CID Confirmed" tone to the user. The VIU then requests the configuration image from the NBU.

Once the configurition image has been received, the user gets a dial tone. If the CID is already registered by another device or is a reserved CID, the NBU sends a CID Response SP (with CID This causes an error tone if the phone is still ofthook. After the user hangs up, the "Enter CIZ" tone is produced when the phone is later taken offhook.

Onte a single-port node has been registered on the network, that node, togethur with its phone, may be relocated to a different area and reconnected to the network. The attached phone will then automatically assume the *ame extension number and pre-configured features as at the previous location. The same is true if a multi-port VIU and all the attached phones are relocated, and also for any other kind of network node, regardless of whether they support phones, trunks or NBU's.

The network also supports de-registration and re-registration of nodes according to pro-configured 36 criteria. Appendix 4 is a detailed specification of procedures for registration and de-registration of Voice and Trunk Interface Units. Varying modes of registration and re-registration are permitted. Thus, global registration and re-registration permits new phones to be added and existing phones to ba rt-ragistered at will, while the most secure mode permits nothing to be registered or re-registered.

WO 90/13956 PC/US89/01806 37 RXTX/PCTL/PRAM Organization and Operation Fig. B-I is a more detailed diagram of RXTX As shown therein, RXTX 90 comprises a modem interface 120, a modem receive state machine 124, a modem transmit state machine 128, a CPU interface 132, and a PCTL interface 136. RXTX 90 is synchronized to the network and therefore requests network-related data transfers.

Modem interface 120 packetizes and depacketizes all information going through control/interface circuit This includes inserting/detecting delimeters and generating/checking CRC's. The low level tasks of determining skew and maintaining the receive and transmit frame timing are also done here.

CPU interface 132 consists of interupt circuitry, command and status registers, and the microprocessor interface circuitry required to access them. In this embodiment, CPU interface 132 is designed to interface with the intel 80186 bus structure. To minimize the real-time load on CPU 72, CPU 72 is interrupted only when an event in which it is interested occursB.

PCTL interface 136 takes care of any bufferin; or timing considerations that might be'necessary for receiving and transmitting data. PCTL interface 13b also communicates the necessary information with PCTL circuit 92 for accessing P-RAM 82. Xn this embodiment, PCTL interface 136 is directly coupled to the P-RAM 82 data bus.

Modem RX state machine 124 and modem transmit state machine 128 control the operations between modem interface 120, CPU interface 132 and PCTL interface 136.

The operation of modem receive state machine 124 and modem transmit state machine 128 is governed by the timing inputs from modem interface 120 and the commands received from CPU interface 132. Modem receive state NO 90/13956 PC/US89/01806 38 machine 124 and modem transmit state machine 128 interact with each other when a node is monitoring its own transmission CVP's).

Fig. B-2 is a more detailed diagram of PCTL circuit 92. PCTL circuit 92 includes a RXTX interface 142, a network receive state machine 146, a network transmit state machine 150, a P-RAM interface 154, a PCM highway interface 158, a PCM highway state machine 162, and a CPU interface 166.

RXTX interface 142 is responsible for accepting commands from RXTX 90 and passing them to the appropriate network state machine 146 or 150. RXTX interface 142 also keeps track of the current network transmit and receive times',ots via network transmit and receive framing signals from RXTX Network receive state machine 146 translates the commands received from RXTX 90 involving network receive operations into the appropriate P-RAM 82 accesses. For example, one of these commands instructs network receive state machine 146 to deliver voice data to the P-RAM resident receive ring buffers from RXTX interface 142., Network receive state machine 146 is responsible for generating the required P-RAM addresses and for controlling the data flow between P-RAM 82, PCTL interface circuit 154, and RXTX interface 142. In addition, it maintains all state information necessary to perform these tasks, such as pointers into the TM, SP, CVP, and BP receive ring buffers. Network receive state machine 146 uses its own time slot interchange table to read the mapping between the network receive time slots and the receive ring buffersi, Network transmit state xachine 150 translates commands from RXTX interface 142 involving network transmit operations into appropriate P-RAM 82 accessQes.

For example, one of these commands instrcts network transmit state machine 150 to deliver voice data from the WO 90/13956 PCr/US89/01806 1- 39 P-RAM resident transmit ring buffers to RXTX interface 142. Network transmit state machine 105 is responsible for generating the required P-RAM addresses and controlling the data flow between P-RAM 82, PCTL interface 154, and RXTX interface 142. In addition, it maintains all the state information necessary to perform these tasks, such as pointers into the TM, SP, CVP, and ZP transmit ring buffers. The network transmit state machine 150 interprets the P-RAM resident time slot interchange which maps the network transmit time slots to the appropriate transmit ring buffer (and thus PCM highway timeslot). It then controls the actual data transfers from the P-RAM resident ring buffers to RXTX interface 142.

PCM highway interface 158 is responsible for keeping the PCM highway state machine 162 in sync with the PCM highway. It also controls transmissions onto the PCM highway. Data transmitted on the PCM highway should be encoded using mu-255 as per CCITT recommendation G.711.

PCM highway state machine 162 is responsible for transferring data between the P-RAM 82 ring buffers and PCM highway interface 158. As discussed below, there is one transmit and one receive ring buffer in P-RAM 82 for each of the 24 PCM highway time slots to buffer voice data between the network and the codecs. PCM highway state machine 162 interprets the mode command register in P-RAM 82 that selects idle, voice, or tone mode, and then transfers information as required. PCM highway state machine 162 also checks both transmit and receive ring buffers in P-RAM 82 on every access for overflow conditions, and takes appropriate action.

P-RAM interface 154 controls all accesses to P- RAM 82. It uses a slotted access scheme, reserving every other P-RAM access for PCM highway state machine 162. It reserves the remaining access slots for network transmit WO 90/13956 PCT/US89/O1806 40 state machine 150 and network receive state machine 146 as shown in Fig. B-3. Each state machine must request each use of its access slots from P-RAM interface 154.

Any slots not used by their owner are available for use by CPU 721.

CPU interface 166 services CPU requests to read from or write to command and status registers disposed within CPU interface 132. In addition, it routes requests to read from or write to P-RAM memory space to P-RAM interface 154. P-RAM interface 154 in turn provides a "ready" signal to CPU 72 when appropriate and transfers data as required. As the CPU operates using an unknown clock phase (and possibly frequency) compared to RXTX 90 and PCTL 92, all CPU requests are synchronized to the clocks within RXTX 90 and PCTL 92 before being executed.

Fig. B-4 is a more detailed diagram of the inputs and outputs for RXTX 90, PCTL 92, and P-RAM 82.

The I/O terminals of modem interface 120 (Fig. B-1) in RXTX 90 (shown at the bottom of RxTx 90 in Fig. B-4), includes an M-5 input terminal 200 for receiving 5.018 megahertz clock pulses (used e.g. for data timing); an RXD input terminal 204 for receiving serial data (5.018 MBPS) from modem 70; a TXD output terminal 208 for transmitting serial data (5.018 MBPS) to modem 70; an ME output terminal 212 for providing a modem enable signal to modem 70; a RCH bus 216 for providing a 4-bit receive channel number to modem 70; a TCH bus 220 for providing a 4-bit transmit channel number to modem 70; an MP input terminal 224 for receiving a modem fault signal from modem 70; a MFR output terminal 228 for providing a modem fault reset signal to modem 70; an OSCE output terminal 232 for providing an oscillator enable signal; and a bidirectional M/SF terminal 236 for synchronizing the transmit frame with other RXTX circuits 90 at the node, M/SF terminal 236 is an output terminal when RXTX circuit WO 90/13956 PCT/US89/01806 41 is a master timing mark generator, and it is an input terminal when RXTX circuit 92 is a slave timing mark generator. Circuit timing will be discussed in more detail below.

The I/O terminals of CPU interface 132 (Fig. B- 1) in RxTx 90 (shown at the top of RxTx 90 in Fig. B-4) include a bidirectional RTCPUD 242 bus for communicating 8-bit parallel status and command data with CPU 72; a RTCPUA bus 246 for receiving 5-bit addresses from CPU 72; an RTCS input terminal 250 for receiving a chip select signal from CPU 72; an INT output terminal 254 for providing interupt signals to CPU 72; an RDY output terminal 258 for providing "ready" signals to CPU 72; a BER output terminal 262 for providing bus error signals to CPU 72; an RTCPUR input terminal 266 for receiving CPU read pulses; and an RTCPUW input terminal 270 for receiving CPU write pulses.

The I/O terminals for PCTL interface 136 (Fig.

B-l) in RXTX 90, and RXTX interface circuit 142 (Fig. B- 2) in PCTL 92 include a TXS terminal 274 for communicating transmit frame synch pulses to PCTL 92 for marking transmit time slot boundaries; a TXFR terminal 278 for indicating to PCTL 92 whether the transmit frame is forward or reverse; an RXS terminal 282 for communicating receive frame synch pulses to PCTL 92 for marking receive frame time slot boundaries; an RXFR terminal 286 for indicating to PCTL 92 whether the current receive frame is forward or reverse; an RFL terminal 290 for indicating to PCTL 92 whether the receive frame is locked; a PW terminal 294 for providing signals to enable RXTX 90 to communicate directly with P- RM 82; a synch terminal 298 for providing signals to synchronize the state machines within PCTL 92 with the state machines within RXTX 90; a S-bit CMD bus 302 for communicating RXTX 90 commands to PCTL 92; and a bidirectional PD bus 306 which is an 8-bit data bus for WO 90/13956 PC/US89/01806 42 accessing P-RAM 82. PD bus 136 is coupled to one port of S 3-port controller 93. When more than one channel is to be accommodated in a device, multiple RXTX and PCTL circuits communicate with each other using the foregoing terminals. In that case, the terminals bay be broadly described as an interchannel bus (ICB).

The I/O terminals of CPU interface 166 (Fig. B- 2) in PCTL 92 (shown at the top of PCTL 92 in Fig. B-4) include a bidirectional PCPUD bus 320 which communicates with the lower 8 bits of the 80186 data bus; a PCPUA bus 324 for receiving the address bits required to access PCTL internal registers and P-RAM 82; a CRS input terminal 328 for receiving signals indicating that CPU 72 is accessing P-RAM 82; a CPS input terminal 332 for rqceiving signals indicating that CPU 72 is accessing the PCTJ 92 internal registers; a CRD input terminal 336 for reciving the CPU read signal; a CWR input terminal 340 for receiving the CPU write signal; a CRDY output terminal 344 for indicating to CPU 72 that the PCTL 92 internal register or P-RAM 82 access requested by CPU 72 has completed and valid data is available or has been accepted; and a PBER output terminal 348 for indicating that the PCTL 92 access requested by CPU 72 han not completed in a timely manner, thus ending the CPU cycle.

The signals on PBER terminal 348 can be used either to generate a "bus error" or non-maskable interupt to CPU 72.

The I/O terminals of PCM highway interface 158 (Fig. B-2) of PCTL 92 (shown on the right hand side of PCTL 92 in Fig. B-4) include an RPCM terminal 360 for transmitting data to codec 75; a TPCM terminal 364 for receiving data from codec 75; a PCLK input terminal 368 for receiving a 6,176 megahertz clock used to control the PCM highway interface; and a PCLK terminal 372 for establishing the 1.544 megahertz clock used to transmit and receive data on PCM highway 95. The signals on PCLK WO 90/13956 PCT/US89/01806 terminal 372 are output by PCTL 92 when a "PCM highway master" bit is set in a PCTL mode register discussed below. PCM highway interface 158 further includes a TSO terminal 376 for indicating that the PCTL 92 internal PCM highway time slot counter should be reset to time slot 0 on the next 6.176 megahertz rising clock edge. The signals on this line are output by PCTL 92 when a "PCM highway master" bit is set in the PCTL mode register. A TXEH terminal 380 provides signals to codec 75 indicating it should begin transmitting data on a current time slot; and a TOE terminal 384 provides signals to codec 75 to cause codec 75 to enable its output drivers to PCM highway 95. The signals on TOE terminal 384 typically are required when using codecs which cannot generate the required transmit PCM highway time slot timing using only the signals on TXEN terminal 380. A RXEN terminal 388 provides a signal which informs codec 75 to receive data from the PCM highway in a current time slot. A PTS bus 292 provides the current 5-bit time slot number on the PCM highway. A 4-bit PST bus 396 provide the current state of tble PCM highway state machine. It is primarily used during chip test.

The I/O terminals for P-RAM interface 154 (Fig.

B-2) in PCTL 92 include a 16-bit PA bus 402 for addressing P-RAM 82; a PCS terminal 406 for providing a chip select signal to P-RAM 82; a PWE terminal 410 for providing a write enable signal to P-RAM 82; and a POE terminal 414 for providing an output enable signal to P- RAM 82. These terminals are coupled to one port of 3port controller 93.

Control/interface Circuit Coan To Understand how control/interface circuit functions, and to understand the organization of P-RAM 82 and the command/status registera in RXTX 90 and PCTL 92, it is helpful to list the commands which occur within WO 90/13956 PC/US89/01806 44 control/interface unit 80. These commands may be separated into three categories: network commands processed by RXTX 90, PCM highway commands processed by PCTL 92, and RXTX/PCTL commands for communication between RXTX circuit 90 and PCTL circuit 92.

Network Commands The following is a list ol network commands: LO Transmit timing mark (TX TM); Transmit signalling packet (TX SP); Transmit claiming voice packet (TX CVP); Transmit voice packet (TX VP); Transmit boot packet (TX BP); Transmit silence (TX Silence); Receive timing mark (RX TM); Receive signalling packet (RX SP); Receive voice packet (RX VP); and Receive boot packet (RX BP).

PCM Highwav Commands The following is a list of PCM highway commands: Transmit idle; Transmit voice; Transmit tone; Transmit receive PCM highway data; Receive idle; Receive voice with gain switching; Receive tone with gain switching; Receive long tone without gain switching; Receive short tone terminate this cycle; Receive long tone terminal this cycle.

commands vill be discussed later.

The RXTX/PCTL P-RA- ORGANIZATHON To suppoft the foregoing commands, P-RAM 82 is, WO 90/13956 PCT/US89/01806 45 organized as follows. As noted in Table A-3, the addresses are listed in hexadecimal. The numbers in parenthesis following the block definition is the number of bytes in the block.

Page Number PA<13:1B> Function 0 7 These pages contain the actual Tx and Rx ring buffers. There is one Tx and one Rx buffer for each timeslot on the PCM Highway. Each buffer is 32 bytes long. This prevents the bit shifting performed by the HRU reclocking mechanism from causing the PCM highway to receive certain data samples twice and missing others entirely. The individual buffers are located as follows: PA<10:6> PCM Highway timeslot number 0 Transmit (to network) direction 1 Receive (to codec) direction PA Location (0 to 31) in each ring buffer 8 This page contains the 8 byte command blocks for each PCM Highway timeslot used by the PCM Highway state machine. These command blocks include the actual command as well as the ring buffer pointers and the vectors to tone and gain pad buffers.

It is organized as follows: PA PCH Highway timaslot number 0 PCM Highway timeslot command 1 Gain switching pad page number 2 Tone page number 3 Current pointer into tone buffer WO 90/13956 PCT/US89/01806 46 4 PCM Hwy Rx Rd pointer and state Network Rx Wr pointer 6 PCM Hwy Tx Wr pointer and state 7 Network Tx Rd pointer 9 This page contains four tables, located as follows: PA 0 Network Transmit active Table S0 Forward Frame timeslot 1 Reverse Frame timeslot 15 PA<4:0> Voice Timeslot Number (2 through 29) 1 Network Receive Active Table 0 Forward Frame timeslot 3 Reverse Frame timeslot Voice Timeslot Number (2 through 29) 2 Transmit Timing Mark Buffer. This buffer contains the data to be sent during a timing mark if this control/interface circuit is configured as a TM Master (discussed :0 below). The bytes are 0 written into this buffer by the CPU, starting at location 0, in the order they are to be sent.

3 Receive Timing Mark Buffer This buffer contains the data received during the last timing mark. The data is stored, starting at location 0, in the order it is received ifrom the WO 90/13956 PCr/US89/01806 47 network.

OA This page contains the SP transmit and receive data buffers. They are located as follows: PA<7>- 0 SP Transmit Data Buffer. This buffer contains the data to be sent out during the next TX SP command. The data should be sorted, starting at location 0, in the order it is to be transmitted. The first three bytes are assumed to be two least significant bytes of the destination address and the control byte. Except for the first SP after a reset, all Tx'd SPs will transmit bytes 0 59 from this buffer and then append a CRC.

1 SP Receive Data Buffer. This buffer contains the last SP received from the network. If the "SP Rx'd" bit is setr the SP has passed the Rx'd SP hash and its Rx'd CRC checked, and will not be overwritten by now Rx'd SPs until this bit is cleared.

The Ax SP hash circuitry assumes the first three bytes of the SP are as mentioned above.

0B This page contains the following four tables: PA<7:6> 0 Busy/Free Table. This table indicates whether there is activity on each Network timeslot. The value in each entry is the consecutive number of cycles in which no activity has been sensed on the timaslot.

This value pegs at 255. This table will not be valid until 255 cycles after a receive modem channel change (however it can be used after waiting the "Prea threshold" number of cycles WO 90/13956 PCT/US89/01806 48 after the channel change).

0 Forward Frame timeslot 1 Reverse Frame timeslot Nat Rx timeslot number 1 Receive SP Hash Table. These 32 bytes (256 bits) contain the hash tables for each of the four SP address spaces (one per channel). The hash table is computed and written by the CPU reflecting the network addresses for which it is listening.

PA<5> 0 PA<4:3> Address Space number.

Hash value.

2 Claiming Voice Packet Data buffers. The transmit buffer contains the data to be transmitted during the next Tx CVP command. The first 16 bytes of this buffer are transmitted onto the network during the CVP.

The receive buffer contains the 16 bytes received from the network during the CVP.

0 Transmit CVP buffer.

1 Receive CVP buffer.

3 TX'd CRC table. This table contains the CRC# of all packets transmitted the past frama, It is used exclusively by control/interface 80 to monitor collisions (TMs, SPs, and CVPs) and bit errors (normal VPs).

OC This page contains the 26 byte Transrit Boot Buffer 0.

This page contains the 256 byte WO 90/13956 WO 903956PUS89/01806 49 Transmit Boot Buffer I.

This page contains the 256 byte Receive Boot Butfer 0.

This page contains the 256 byte Receive Boot Buffer 1.

This page contains the timQslot interchangers (TSXrS) used by the Network Tx and Rx state machines to find the PCM Highway ring buffer it should use for a given network timeslot. It is organized as follows: PA<7:6> o Network Receive Machine TST I Network Transmit Machine TS1 2,3 Unused

PA<S>N

o Forward Frame timoslot I Reverse Frame timeslot ve Network timoslot number wRing buffeor to be usad These pages are used to hold individual ones or gain tablex. The CPU selects one of these pages# writes the tot* or gain table in the Page# and then places this Page number in byte 1 or 2 of the desired PCH Highway titeslot command block in page 8. When the command itself is written to byte 0 of the same block, the, PCM Highway state machine will use the referenced tone and/or gain table. In the, case of rocaiveo.only ton& modes, maultiple pages are usad to hold a single 'tone.

11 1F+ As noted above, P-1RAM 82 contains hot only the ring buffer# used for transmitting -the actual data betwean codec 73 and todem 70, but a tuimber of command and statuo byte lochtlio- The following tables and WO 90/13954 PCT/US89/01806 50 descriptions provide the bit assignments for the latter.

PAGE 8 PCM Highwav Timeslot Command (PA<2: 0>0) Codec I Codec PCTL I TX Cmd TX Cmd Rx Cmd Rx Cmd RXCmd Rx En TX En Enable bit<l> bit<0> bit<2> b7 b6 b5 b4 b3 b2 bi bO Table D-1 The bits are defined as follows: Lit, Snm unWian PCM Hwy Rx These bits command the PCM Timealot Highway state machine to perform a sequence of operations for this Peceive PCM timeslot ("receive" from the codec's point-of-view). The options are: 0 Xdl;t no transfer*. Any voice data received from the network is discarded.

1 Transfer voice from this time-slot's receive (from Network) ring buffer through the gain pad Highway.

26 2 Transfer Tona (from P- W tone buffer after passing through gain pad to PCM Highway).

3 Tranafer Long Tone (>256 bytea) to PCM Highway.

4 Same actions as 0", S Same actions as 6 Transfer Tone (from PAM toe buffer) after passing through gain pad 3 to PCH Highway stop after this tone cycle.

7 Tranter Long tone (>256 byteo) to P01 Highway WO "/13956 WO 9013956PCF/US89/01806 51. stop after this tone cycle.

PCZI Hwy Tx These bits command the PCM Highway state machine to perfor.m a sequence of operations for this Transmit PCM tiMeslot ("transmit" from the codec's point-of-view). The options are: 0 Idle; no transfers. Any voice data received from a codec or SPU is discarded.

I. Transfer Voice from PCI4 Highway to this timeslot's transmit (to Network) ring buffer.

2 Transfer Tone retrieved for this timeslot's RX Command (as read from tone buffer before level switching) to transmit ring buffer (If the Rx command is not one of the "1tone"' commands this Tx comrmarnd will place garbage in the transmit ring buffer).

3 -Transfer Receive PCM timaslot information to this timzs3.ot's transmit ring buffer.

(If this PCTL in transmitting onto the P014 Highway durinq the receiva time-alot, this commAnd loops the data back.) This bit, when sat, enables PCTL to actually transmit onto the Receive P14 higjhway during this P014 tim4eslot.

Hence, the receive information retrieved by the P014 Hwy #tate machine is shifted onto thie receive highway destined for the codeca. If this bit in taro, any data retrieved by the state machineo is not actual.ly transmitted as the output Mv. P014 Highway output Enable WO 90113956 PCT/US89/01806 52 buffer stays tri-stated. This bit must only be set if this PCTL chip is to transmit onto this timeslot. At all other times it must be zero. If multiple PCTL chips are driving a single Receive PCM Highway, this bit must only be set in at most one PCTL's P-RAM for each PCM Highway timeslot.

6 Generate Codec Transmit Enbl This bit, when set in the command byte of timaslot N, causes th- PCTL chip to generate a transmit enable to the attached codec in timeslot N. These enables are actually given only if the appropriate bit in the PCTL Mode register is set (see below), This bit, when set in the command byte of timeslot N, causes the PCTL chip to generate a receive enable to the attached codec in timeslot N. These enables are actually given only if the appropriate bit in the PCTL Mode register is set.

7 Generate Codec Receive Enable Ga"it Wijtchin Pad Page Number (PA<2:0>-1) Pad Pad P ad Pad Pad Pad Pad Pad Pg<7> Pg<6> Pg Pg<4> Pg<3> Pg<2> Pg<l> Pg<0> b7 b6 b5 b4 b3 b2 bl bO PAD Pamge PAD Page Table B-2 These bits form the page number of the Number gain switching PAD to be used for this PCM Highway timnslot. In the case of a receive-only tone command, which does not involve a PAD operation, this byte contains the first page of the tone.

WO 90/13956 PCT/US89/01806 53 Tone Page Number (PA<2:0>=2) Tone Tone S Pg<7> Pg<6> -b7 b6 b7 b6 Tone Tone Tone Tone Tone Tone Pg<5> Pg<4> Pg<3> Pg<2> Pg<l> Pg< b5 b4 b3 b2 bl b0 Table B-3 Tone Page Number Function These bits form the page number of the Tone to be used for this PCM Highway timeslot command. In the case of a receive-only tone, which generates a tone requiring multiple pages of P-RAM, this byte is the tone page currently being read.

Current Pointer Into Tone Buffer (PA<2:0>-3) Tone Tone Tone Tone Ton Tone I Tone

T

one Ptr<7> Ptr<6> Ptr<5> Ptr<4> Ptr<3> Ptr<2>Ptr< Ptr<o> b7 b6 b5 b4 b3 b2 bl bO Table B-4 Tone Pointer Tone Pointer Function This byte is the pointer into the tone buffer being used for this PCM Highway timeslot command. It points at the next tone sample to be read by the state machine and sent to the codecs and/or the transmit ring buffer. tC is reset to zero when it roads a tone sample of 0 (negative full-sale). Hence, this value is used to start another cycle of the tone buffer. Any real samples equal to 0 in the tone should be changed to Olh before being used. The sample read as 0 will be transmitted as OFFh (zero), so the tone should be written into the buffer such that its Iast sample is zero (OFFh).

If a "stop after this cycle" tone mode is selected via the PCM Hwy Rx Timeslot Command, the tone will be sent out WO 90/13956 PCr/US89/01806 54 normally until the end of the current tone cycle; the pointer will then remain pointing at the 0 tone sample rather than being reset to zero, thus sending silence (OFFh) to the Rx PCM Hwy (and the Network if so selected) until the PCM Hwy Rx Timeslot Command is changed.

PCM Hwy Rx Read 'PCM Rx 1 PCM Rx ISLP ISt<1> b7 b6 Pointer and State (PA<2:0>=4) PCM Rx! PCM RX IPCM Rx ST<0> I RD<4> ID<3> b5 b4 b3 PCM RX RD<2> b2 PCM R I PCM Rx RD<1> {RD<0> bl bO Table The bits in the PCM Hwy Rx Read Pointer should be initialized to all zeros before setting up a connection for a given PCM Highway Receive timeslot. CPU 72 should not write to this location during the connection, as doing this could corrupt PCTL State Machine operation.

Bit Nam PCM Receive Read Pointer PCM Receive State E=1an This is the next location to be read by the PCM Highway state machine from the receive ring buffer for this PCM Highway timeslot.

These bits indicate the state of the PCM Receive Read process for this timeslot. They are interpreted as follows: 0 Idle state. Network Rx Write Pointer is equal to PCM Rx Read Pointer.

Silence is given to codec, and the PCM Rx Read pointer is left unchanged.

1 Filling ring buffer. This state is entered from state 0 when the pointers are detected not equal the Network Rx Write Pointer has changed.) Silence is given to codec, and the PCM Rx Read pointer is left unchanged. State 2 is WO 90/13956 PCr/US89/01806 55 entered always the next time the PCM Highway state machine processes this timeslot.

2 Normal mode. The Network Rx Write pointer is checked against the PCM Rx Read pointer if they are equal, silence is given to the codecs and state 0 is entered. Otherwise, the PCM Rx Read pointer is used to read a byte of information from the receive ring buffer, the byte is sent to the codec, and the pointer is incremented (mod 32) and written, back to P-RAII.

This bit, if set, indicates that state 0 has been entered from state 2 (see above) at least once since this connection was established.

PCM Rx Read Slip Netrk x Write Pointer (PA<2:0>-5) 'Net R X X r NetRet Rx Net R x Net Rx Net Rx! Slip IIWr<4> Wr<3> Wr<2> Wr<l> Wr<O> b7 b6 b5 b4 b3 b2 bl bO Table B-6 The bits in the Network Rx Write Pointer should be initialized to all zeros before setting up a connection for a given PCM Highway Receive timeslot. CPU 72 should not write to this location during the connection, as doing this could corrupt PCTL State Machine operation.

i me =Function Network Rcv Write Pointer This is the next location in the receive ring buffer to be written by the Network Rx State Machine. This machine always writes 16 bytes at a time, and updates the pointer after each burst write. Hence, its value should always be 0 or 16.

This bit, when set, indicates that there Network RX WO 90/13956 PCI/US89/01806 56 Slip has been at least one instance where the Network Rx State Machine was active and could not write an incoming VP into the appropriate receive ring buffer because the PCM Rx Read Pointer would be passed. The Network Rx State Machine, when logging this error, inhibits writes to the ring buffer and does not change the pointer.

Hwv Tx Write Pointer and State (PA<2:0>-6) jPCM TX TX PCM TX IPCM TX IPCM TX PCM Tx1 PCM TX' slip State Wr<4> t Wr<3> IWr<2> Wr<l> Wr<o> I I I b7 b6 b5 b4 b3 b2 bl bo Table B-7 The bits in the PCM Hwy Tx Write Pointer should be initialized to all zeros before setting up a connection for a given PCM Highway Transmit timeslot. Software should not write to this location during the connection, as doing this could corrupt PCTL State Machine operation.

Bits Ha=e Function PCM Transmit This is the next location to be written Write Pointer by the PCM Highway state machine to the transmit ring buffer for this PCM Highway timeslot.

PCM Transmit This bit indicates the state of the State PCM Transmit Write process for this timeslot. It is interpreted as follows: 0 Idle state. Network Tx Read Pointer is equal to PCM TX Write Pointer. Received codec data Idiscarded, and the PCM Tx Write pointer is left unchanged.

1 Normal Mode. This state is entered from state 0 when the pointers are detected not equal the Network Tx Read Pointer has changed.) When this state is entered, the current PCM TX Write pointer is summed with 19 modulo 32 (to place write pointer just ahead of read WO 90/13956 PCT/US89/01806 57 pointer), and the codec data is written to location. The PCM Tx Write pointer is then incremented from that value (mod 32) and written back to

P-RAM.

Every subsequent time this timeslot is accessed, the PCM Tx Write pointer iscompared to the Net Tx Read pointer -if they are equal, the received codecdata is discarded and idle state (0)is entered. Otherwise, the PCM TxWrite pointer is used to write the codec information to the transmit ringbuffer. The pointer is then incremented (mod 32) and written back to P-RAM.

This bit, if set, indicates that state 0 has been entered from state 1 (see above) at least once since this connection was established.

PCM TX Write Slip Network Tx Read Pointer (PA<2:0>-7) Net Tx X N NeTxNet TX Net Tx Net TX Net TX Slip Rd<4> Rd<3> Rd<2> R<041> Rd<0> b7 b6 b5 b4 b3 b2 bI bO Table B-8 The bits in the Network Tx Read Pointer should be initialized to all zeros before setting up a connection for a given PCM Highway Transmit timeslot. CPU 72 should not write to this location during the connection, as doing this could corrupt PCTL State Machine operation.

Network TX Read Pointer EUnction This is the next location in the transmit ring buffer to be read by the Network Tx State Machine. This always reads 16 bytes at a time, and updates this pointer after this burst read. Hence, its value should always be 0 or 16. If data is requested for transmission when the corresponding PCM Hwy TX Write Pointer's state is idle, data is delivered from the Tx silenc* buffer (rather than from the transmit WO 90/13956 PCT/US89/01806 Network Tx Slip 58 ring buffer), and the Net Tx Rd Pointer is updated as if data had been read.

This bit, when set, indicates that there has been at least one instance where the Network TX State Machine was active and could not read an outgoing VP from the appropriate transmit ring buffer because the PCM Tx Write Pointer would be passed. The Network Tx State Machine, when logging this error, inhibits reads from the ring buffer and gives data from the Tx Silence Buffer in response to the RxTx requests. It also leaves the pointer unchanged.

Network Transmit Active Table Entry (PA<7:6>-0) Tx TX X Chani Chani Chani TxCmd X dTx Cmd Sinc PS <0> b7 b6 b5 b4 b3 b2 bl bO Table B-9 Rih Na=e TX Active Command These bits indicate the action required by the Not Tx State Machine for this network timeslot. They are encoded as followst 0 Xdle no transmission or channel change required this timeslot.

1 Transmit Voice Packet 2 Transmit Boot Packet 3 Upt this timeslot to change Tx Modem ch nnal (no transmit allowed).

Channel These bits form the new Tx channel number to be loaded into the Tx RP modem channel register if command 3 is selected above. tf any other Tx Active Command is givent these bits are not used.

WO "/13956 WO 9013956PCt/US89/01806 59 Transmit Pseudo-Silence Transmit PC!' Silence This bit, if set in conjunction with a transmit command durina, Master-mode loophack, causes the RxPc chip to send network pseudo-silence to the loopback circuitry.

If Tx Active command I is selected via bits <1:0>1 this bit, if set, causs PCTZJ to send data to the network 2*om the Tx silence buffer. if this bit 14a zero, data will be sent from the usual transmit ring buffer.

He R&_eceive __Active Table Entry (PA<7:6>ml) is x x _X X EnCTx I 'Allow 'lo CRC ck Aic'X VP I RX BP W7 Ii b b3 'b2 bl bO Table sm Allow Rx Boot Packet This bit, if set, allows boot packets to be received from the network during this timeslot and placed in thQ current Rx Boot Buffer. in addition, a disconnect interrupt is generated and the Disconnect bit not if this timeslot goes free. If this bit is zero, any incoming boot packets during this timas3.ot are discarded and disconnects are ignored (provided bit<l> is also zero). This bit is cleared by the hardware if a disconnect is detected on this tixueslot.

This bit, if set# allows voice packets to be received from the network during this timeslot. This data may be passod to a receive ring buffer depabding on the Value of this timeiulot'sa Rx Time Slot :ntarchmige entry as wal.l as the recaive, ring buffer's, Nat Rxc W~rite Pointer. in addition, a disconnect interrupt is generated and the Disconnect bit not it this timeslot Allow 'Ax voice Packet WO 90/13956 PCT/US89/01806 60 becomes free. If this bit is zero, any incoming voice packets during this timeslot are discarded (not written to any buffer) and disconnects are ignored (provided bit<0> is also zero). This bit is cleared by the hardware if a disconnect is detected on this timeslot.

Disconnect Enable Tx CRC Check This bit, if set, indicates that.the timeslot became free while the Allow Rx BP or Allow Rx VP bits were set. This bit can only be cleared by CPU 72 PCTL 92 can only set it. If the bit is clear, no disconnect has occurred on this timeslot. Hardware automatically clears the Allow Rx BP and VP bits when setting th4 Disconnect bit.

This bit is used to enable comparison of transmitted and received CRC values to detect errors. If one is transmitting on network tinmslot N, and wishes to have this comparison done and the CRC compare counter incremented based upon the results, this bit must be set in the Rx Active Entry for timeslot N+l. (If checking is required on VTS 29, the last VTS, this bit should be set in the "pseudo RX Active Entry" for TS If this bit is cleared, no CRC compare will be done for the previous timeslot. obviously this bit should be clear for every 7x Active Entry following a timeslot on which this control/ interface circuit is not tralasmitting.

Network bmusvtree Table Entry bl bO/0> Sbi bo Table B-11 WO90/13956 PCT/US89/01806 61 Function Busy/Free Value This quantity gives the number of cycles since activity (anything but network silence for the period from the beginning of the expected delimiter time until 4 bits into data byte 1 of the ixpected packet) has been detected on this network timeslot. Each time that activity is observed on this timeslot, this value is reset to zero. This value will not count past its maximum value of 255. This table is not valid for 255 cycles (about 0.5 seconds) following an Rx RF Modem channel change.

Hash Table Entry I HASH7 HASH6 HASH5 HASH4 HASH3 RASH2 HASH1 HASHO b7 b6 b5 b4 b3 b2 bl bO Table B-12 HamS HASH <7 Set if device is a member of a particular address class. Each bit represents an address class.

NetworkRc., eive PCM Timeslot i_ Aai Entry Table B-13 Those locations are written by CPU 72 to map Network timalots on which data is being received to receive ring buffers and thus PCM Highway Receive Timeslots. The mapping should be set up by CPU 72 as part of establishing the connection. The Active/Xdla* bit can be set or cleared at any time during a connection.L This bit should be zero for all Network timeslots on which nothing should be received.

WO 90/13954 Pr/US89/01806 62 Dita Em04 PCM Receive Timeslot 7 Active/Idle* Function The PCAm H*ghway Receive timeslot and ring buffer used to store voice data received from the network during this (as indicated by address) network timeslot., This bit, when zero, inhibits the Network Rx State Machine from writing incoming voice packets into the selected receive ring buffer or updating the Network Rx Write Pointer, When this bit is set, received voice packets are written into the selected receive ring buffer and the Network Rr Write Pointer is updated normally.

Network Transmit -1CM l Timslot Ma plEntry AtIVe PCM TX PCM TX PCM TX PCM TX IPCM TX /XdlQ* TS<4> TS<3> TS<2> TS<> TS<O> b7 b6 b5 b4 b3 b2 bl b0 Table B-14 Those locations are written by CPU 72 to map Network Timeslots on which voice data is being transmitted to PCM Highway Transmit timeslots and ring buffers. The mapping should be set up by CPU 72 as part of establishing the connecation, The Active/Xdle bit can be set or cleared at any time during a connection. This bit ashould bQ zero for all Network timeslots on which nothirg is being transmitted (this bit does not actually control the Network Transmit, however the PCTL Network TX State Machine makes fewer accesses to P-fAM ift it is zero).

t AA M Zcttio PC'Transmit imeslot 47> Active/XdlQ* Ihe PCM Highway Transmit timesst and ring buffer used to retrieve voice data to be sent to the network during ttis (as indicatrA by address) network timesluo This bit, when zeoo, inhibits the Network Tx State Machine from reading voice packets out of the saelcted transmit ring buffer or updating the WO 90/3156 PCT/US89/01806 63 Network Tx Read Pointer. If the Net Tx Active Table indicates a voice transmission on this timeslot, data is fetched from the Tx Silence tuffer.

When this bit is set and the Tx Active Table indicates a voice transmission on this timeslot, data is fetched from the selected transmit ring buffer and the Network Tx Read Pointer is updated normally.

COMMAND AND STATUS REGISTERS In addition to the command and status registers described for P-RAM 82, RXTX 90 and PCTL 92 contain command and status registers in their respective CPU interfaces 132 and 166. A description of these registers follows.

PCTL.RQaisters PCTL 92 contains several registers in CPU interface 166 which are accessible to CPU 2. They are used to select the dperating modes of the circuit as well as gain useful status information. All command registers may be reAd as well as written by CPU 72. Status registers, of course, are read-only.

PCTL.Transmit Status Reaister Table LrU&Lin PXFO Error Cur Buffer This bit is set if the TX Ring Buffer pointers (Net TX Read Pointer and PCH Hwy Tx Write Pointer) are misaligned in such a way that data is overwritten or duplicated.

This bit tells the RXTX chip which Boot Buf£fer (0 or 1) has new data to be sent to the network. The RXTX will then know which boot delimitor to send.

This bit tells the RXTX chip which Boot Buffer (0 or 1) has just been Empty Buffer WO 90/13936 PCT/US89/01806 64 emptied and therefore needs new data from the CPU. This bit is copied into a BP status register that the CPU can read. This bit is valid when the Boot Switch bit is set.

Boot Switch This bit is set when the Boot Buffer pointer has just changed states. It tells the RxTx chip to generate an interrupt the next possible time.

PCTL Receive Status Realter FIFO TMs HASH Abnorm Full Boot Disc Error X Missed Passed Switch Bufter Switch b7 b6 b5 b4 b3 b2 bl bO Table B-16 Disc PIFO Error THs Missed Euntion This bit is set if the connection to the far-end device is dropped. Disconnect is detected when a time slot has B/aFfree AND the active table indicates a connection should exist. This bit tells the RXTX chip to set an interrupt.

This bit is set when the Rx Ring Buffer pointers (the Net Rx Write Pointer and the PCM Hwy Rx Read Pointer) are misaligned and allows data to be overwritten or duplicated.

This bit is set to indicate that the TM Missed threshold was reached a critical failure. This bit is copied into a register that the CPU can read and an interrupt will be generated. The threshold is determined by the CPU and specified in a threshold register in Chapter 6.

This bit indicates that the SP HASH was passed and tells the RXTX chip that the CRC match results are meaningtul.

This bit is valid only if the "Boot Switch)* bit is set. It indicates if the boot buffer switch was expected.

This bit gives the number of the Boot Buffer that has been recently filled, It is 43> Hash Passed wi> Abnotch Switch WO90/13956 PCT/US89/01806 65 copied into a register that read. It is valid only when Switch" bit is set.

the CPU can the "Boot Boot Switch This bit is set when the boot buffer pointer changes states. It is copied into a register that the CPU can read and, with the "Abnorm Switch" and "Full Buffer" bits, the CPU has enough information to determine whether the latest boot reception was successful.

Mode Register This register is used to place control/interface circuit 80 in its various operating modes. The bits are organized as follows: Table B-17 This register is cleared all bits are reset to 0) when the PCTL reset signal is activated. All bits in this register may be read as well as written by CPU 72. The bits are defined as follows: LitA Wma Egnction Reset PCM Highway Enable This bit, when cleared, places PCTL 92 in Reset mode. In this mode, all state machines are hold in a reset state and can not perform accesses to P-RAM 82.

CPU 72, however, can still access P- PAM 82. When this bit is set to PCTL 92 operates normally.

This bit, when cleared, inhibits PCTL 92 from actually driving the PCH Highway output bus, regardless of what it is told by the PCM Hwy state machine 162.

This bit is used to select the type of codec enables to be generated by PCTL.

A "tO selects PCH Highway transmit and receive enable signals compatible with National TP3054 and Intel 2913/4 codec/ filter chips and TI 32020/3200C2 Signal Processors. A selects enable signals compatible with Motorola MC14400 Codec/SPU Mode WO 90/13936 PCT/US89/01806 66 series codec/filter chips.

5 MHz Clock Output Enable PCM Highway Master This bit, when set, enables the driver which sends PCTL's Master Clock to the 5.018 MHz clock out pin. When the bit is cleared, the driver is tri-stated.

This bit, when set, enables the drivers which transmit the PCM Highway State Machine's "Reset to PCM Timeslot 0" and "1.544 MHz Clock" signals to the corresponding PCTL input/output pins.

pin. When the bit is cleared, the output drivers are tri-stated.

Codec Control This bit, when set, enables PCTL's PCM Output Enables Highway transmit and receive codec/ filter control signals. If this bit is zero, these pins are tri-stated.

Counter Test This bit, when set, places PCTL in its Mode counter test mode. In this mode, PCTL allows all of its error counters to increment as if errors are being receivaed When this bit is cleared, all error counters operate in their normal ode.

PCM Timeslot This bit, when set, commands PCTL to Counter output drive its PCM Highway Timeslot Counter Enable output pins. If this bit is zero, these pins are tri-stated.

Threshold Register This register is used to select two thresholds. The first is the number of consecutive cycles a Network tiweslot must be unoccupied before the timealot is declared to be free and a disconnect generatad (if required). The second is the number of consecutiva receive Timing Marks which must be missed before an interruL. is given to the CPU. The bits are organised as follows t S X X X Misse e re Free <0> b7 b6 b5 b4 b3 b2 bl bO Table 8-18 WO 90/13956 PCT/US89/01806 67 This register is cleared all bibs are reset to the PCTL reset signal is activated. All bits in this may be read as well as written by CPU 72. The bits defined as follows: 0) when register are Function Free Threshold These bits set the Busy/Free "Free" threshold as followu for all network timeslots:

W

0 8 consecutive silent cycles 1 16 consecutive silent cycles 2 32 consecutive silent cycles 3 64 consecutive silent cycles These bits set the consacutive Rx TM missed interrupt threshold: Rx TM Missed Threshold w 0 Interrupt on 16 consecutive missed receive Timing Marks.

0 1 Interrupt on 32 consecutive missed receive Timing Marks.

2 Interrupt on 64 consecutive missed receive Timing Marks.

3 Interrupt on 128 consecutive missed receive Timing Marks.

RX SP Buffer Status Register uRXSP Missed Missed Missed Missed Missed Missed Missed BfFull SP<6> SP<5> SP<4> SP<3> SP<2> SP<1> SP<0> b7 b6 b5 b4 b3 b2 bl bO Table B-19 Bit 7 of this register may be read and written by CPU 72; the romaining bits are read-only. Bits<6:0> of this register are cleared after a CPU read they are unknown after a hardware reset. The bits are defined as follows: WO 90/!3956 PWC'/US89/O1806 68 Bits 1Nm Missed Rx SP Count These bits contain the number of SPs received by this control/interface circuit.

which passed the Rx address hash but were not accepted because the Rx SP data buffer was full. It will not count past its maximum value of 127, and is reset to zero after each CPU read access. This quantity.may only be read; writes to this register will not affect these bits.

This bit, when set, indicates that a valid SP has been received by this control/interface circuit 80 and placed in the Rx SP Data Buffer. An SP is valid if its CRC was good and the destination address hash was passed. RXTX will not place another Rx SP in to the Rx SP data buffer until this bit has been cleared by software. This bit can be read and written by CPU 72.

Rx SP Data Buffer Full Transmit Boot Buffer Register I X I X I X X IX TX Bt I bBuffer b7 b6 b5 b4 b3 b2 bl bO Tabld This register is cleared reset to 0) when the PCTL reset signal is activated. The bit is defined as follows: current Tx Boot Buf fer' This bit gives the current transmit boot buffer being used (or to be used) by PCTL 92. A indicates boot buffer 0 is currently selectod, while a means buffer I is being used. This bit can be written as well a& read by CPU 72. It should not be written, however, while TX BPs are being transmitted.

WO090/13956 PICr/US89/01806 69 Receive BWot Buffer Register X I X I _I I X I X IRx Bt I II I b7 b6 b5 b4 b3 b2 bi bO Table B-21 This register is cleared reset to 0) when the PCTL reset signal is activated. The bit is defined as follows: Bm Name xunlti2 Current Rx This bit gives the current receive boot Boot Buffer buffer being used (or to be used) by PCTL 92. A indicates boot buffer 0 is currently selected, while a means buffer 1 is being used. This bit can be written as well as read by software. It should not be written, however, whilo Rx BPs are being received.

Transmit Boot Pointer Register This register contains the pointer into the currently selected transmit boot buffer. It is used to read the next 16 bytes of boot information from the selected boot buffer during a Tx BP timeslot. It can be written and read by CPU 72, although it should not be written while Tx BPs are being sent by this PCTL circuit. The entire 8 bits of this register form the pointer, as each boot buffer is 256 bytes long.

Receive iloot Pointer Register This register contains the pointer into the currently selected receive boot buffer. It is used to write the next 16 bytes of boot information to the selected receive boot buffer during a Rx BP timeslot. It can be written and read by the software, although it should not be written while Rx BPs are being received by this PCTL circuit. The entire 8 bits of this register form the pointer, as each boot buffer is 256 bytes long.

Rx Timing Mark CRC Error Register This register contains the number of Timing Marks received with CRC errors since this register was last read by CPU 72.

It is reset to zero after each CPU read. The contents of this WO 90113956 WO 90/3956PUSI9/01 806 register are valid for control/interface circuits in either Master or Slave Timing Mark mode, issing Rx Timing Mark Register This register contains the number of Timing marks missed since last read. A Timing Hark is defined as "missed" when the receiver cannot detect a valid Timing Hark delimiter within 4 bit times of where it is expected OR when a valid TM delimiter is received but the CRC does not check. This register is valid in either Master or Slave Timing Mark mode. It is reset to zero after every CPU read access.

Consecutive Hissing Rx TM Register This register contains the number of Timing marks which have beeni missed consecutively. it is reset to zero when a Timing Mark with a valid CRC is received. It is also cleared by aCPU read, allowing another "Consecutive Missed Rx TM"1 Interrupt to be generated at this counter goes past the Missing TM threshold set in the Threshold Register.

Rx TM. Out-of-Sequence Register This register contains the number of Timing marks received outof-sequenoo since last read. A received Timing mark is deemed "out-of-sequence"l when it is received with a valid CRC and a frame number which is not the value expected based on the previous received Timing Mark. This register is valid in either Master or Slave Timing Mark mode. It is reset to zero after every CPU read access. Non-zero values in this regit~ter generally indicate that more than one network unit is generating Timing Marks.

Consecutive Rx Valid TM Register This register contains the number of consecutive valid Timing Marks received. It is reset to zero by any missing Timing mark or Timing Mark with an unexpected frame number. A valid Timing Mark is defined as a TA* with a good CRC and the expected frame numiber. Note that this register is not cleared during reset; hence its contents are unknown for the first 25S cycles the control/interface circuit is in 'Receive rrame lock (with the Interconnect), Tx Packet 'Bit Error Register This register containt the number of transmitted joackats, including regular vi'sl which were received back ftom the WO 90113956 1 '0 /USog/o l "I06 71 network in error, This check is done by computing a CRC on each packet transmitted, and computing a CRC on the same packet coming back from the network. If the two CRCs do not match, AND the corres '-'ding "Enable Tx CRC Check" bit is set in the Rx Active Table 4ftry, the Tx Packet Bit Error counter will be incremented. It is reset to zero after every CPU read.

Voice Slip Register This register contains the number of slips which have occurred in this PCTL chip since last read. A slip is a missed read or write of PCM data which occurs because ring buffer read anO.

write pointers have attempted to cross each other. If thp PCM Highway 6.176 MHz clock is frequency-locked to the network 5.018 MHz clock, there should be no slips recorded. This register is reset to zero after every software read. A bit in the read and write pointer register of each ring buffer can be used to detect whether a slip has occurred on a particular PCM Highway timeslot in a given direction.

Master Clock Monitor Register This register is used to obtain information on PCTL's Master Clock, which is received from the Rx Modem. This monitor operates using the 6.176 MHz clock provided externally, hence it may only be believed in situations where the external clock source derives 6.176 MHz from a "guaranteed good" source of 20.072 MHz clock, such as a PLL which is known to be present and operating.

The register consists of two 4-bit counters. The least significant 4 bits of this register contain the number of 6.176 MHz rising clock edges seen since the 5.018 MHz PCTL clock was last high; the most significant 4 bits contain the number of 6.176 MHz rising clock edges seen since this clock was last low. Both counters will not count past their maximum count of 15. If the PCTL Master clock is operational, each nibble of this register should contain 0, 1# or 2 at any time it is read by software. Higher values in either or both nibbles indicate this clock is not good. If the clock is not thert at all, one nibble should be pegged at 15. Each half of this register is only cleared by the appropriate level on PCTL Master clock.

flXTX Reg tr The RXTX circuit 90 contains several registers which are accessible to CPU 72. These registers are as follows, WO 90/13956 WCr/US89/01106 72 Tn Master/Slave Rerister x x x x x x b7 b6 b5 b4 3 b2 bi b0 Table 8-22 Bit& ma

M/S

Function I Master 0 Slave (condition after reset) The M/S bit determines if the device will transmit TMs. This bit is set only if the device is a master TMG or contending to become one. This bit is 0 after reset.

Tm Command/Lock status Register X X X X Looki LockO TM C.H/S b7 b6 b5 b4 b3 b2 bl b0 Table 8-23 Lock<l..0> 11 128 64 01 32 00 16 co'tsecutive good TMs consecutive good TMs consecutive good TMs consecutive good TMs TM Window These bits determine the number of consecutive good TMs that must be recetived before the RxTX "locks" the Rx frame.

Locking is explained blow.

1 16-bit window during predicted time 0 "Wide open" window (condition after reset) This bit determines how the lxTx searches for a TM delimiter during a frame. After reset this bit is cleared, This allows lxTX 90 to continuously search for THMs and realign the frame whnvor a good TM packet is found. This means that frame "lck"' does not exist yet and time slot boundaries are not WO 90/13956 Cr/iUS89/(Ht06 73 determined.

After the lock threshold is passed (determined by bits 3 and 2, above), circuitry in the RxTx chip will automatically set the bit to 1. TMs will only be detected during the predicted times and the rest of the frame can be used as intended (time slot boundaries are now in place).

The CPU can clear the bit whenever it wishes; the RxTx chip has no means of clearing this bit except during reset.

The CPU can set the bit if it is necessary to recognize the lock condition sooner than the specified threshold. The CPU can read this bit at any time to determine if the Rx frame is locked.

CJM/S 1 Master control/interface circuit 0 Slave control/interface circuit (condition after reset) This bit selects a "master" control/interface circuit 80 among the ones in a particular device. This bit is valid only if the TM Master/Slave bit (above) is a I since it is used to determine which control/interface circuit's "TXYM Sync" signal is used to synchronize all of the control/interface circuits when transmitting a TM. The master control/interface circuit should be chosen before arbitrating to become a master TMG (said another way, C M/S should be valid before M/S).

Naturally, if there is only one control/ interface circuit in a device and it is tranmitting TMs, this bit is gset. In the predominant TMG case, where there are four control/interface circuits one is chosen by the software and changed only if the chosen Chocolate's clock fails.

WO 90/13956 PC/US89/01806 74 TH Status Register ij4~b b7 __ill-iiI X X X 16 b5 -I b6 i b5 b4 X Multi) TMb3 b2 W3 b2 Ims TMs SMissgd bl bO Table B-24 =natigD TM Int Multi TMs lims This bit is set when there is an interrupt pertaining to Tms, making the information in this register valid.

This bit is set when there were multiple good TMs no CRC errors) received within 1 ms. This error will occur only when the Rx frame is not "locked." An interrupt will be generated if interrupts are enabled.

If the Rx frame is locked and the 1 ms interrupt is enabled, this bit will be set and an interrupt will be genfiated every millisecond. It does not depend on the reception of good TMst an interrupt will be generated even if a TM is missed.

If the Rx frame is NOT locked and the 1 mu interrupt is anabled this bit will be set and an interrupt will be generated every 1 me if there are no "Multi TM" errors (sea above).

This bit is set when the threshold for consecutive TMs missed has been reached a critical failure. This threshold is set by software in the PCTL chip. An interrupt will be generated if TM missed interrupt is enabled.

TMe Missed SP Comand Register MS byte Cmdl cdo F R SP3 SP2 SP3 SPO i4 b2 b bO b7 b6 b5 b4 b3 b2 bi bO Table 8-25 WO 90/13956 PCT/jJSj19/01806 75 Bits aM Enaln Cmd<l..0> F and R~ 11. Transmit SP illegal CPU command used by the hardware 01 illegal CPU command used by the hardware 00 No Command (condition after reset) Cmd <1.0O> is cleared by the XRxTx state machine after the expected SP deli~aiter time has passed (whether or not it was received). This insures that the command is processed only once.

After reset and after the~ off-line loopback is engaged or disengaged, Cmd<l..0> is set to I'll"g so that a skew SP can be sent automatically to calculate the skew.

11 Transmit on either forward or reverse frame Transmit on next forward frame 01 Transmit on next reverse frame 00 Transmit an SSP on next frame (fwd or rev) Each bit ,.4oiooses one of the f our SP partitions for transmission. Any combination of SIP partitions can be chosen aiid the SP will be sent on the next eligible one.

Programming Notat Do not write into the, SP' Cmd R~eg (HS byte) if there io a command penceing (i.Qe when Cmd <1.0O> does NOT equal "1001) The best time. to issue a new SP command is after the previous command is acknowledged by ain interrupt or after reading the SP' CmcI Rag to insure that bits Cmd is "100."1 Failure to comply will result in either overwriting the first command (if the writing of the second command falls in a non-SI' time slot) or the second command will be ignored (if the writing of the second command falls in at SP' time slot)* 0> SE' WO 90/13956 PCT/US89/0180 76 SP Command Register LS Byte TX 3 bx2 W7 b6 a- 1 TX1 TXO Rx2 I bWb,5 b4 Wb b2 MC- RX bI bO Table B-26 Tx Rx This selects the transmit frequency for the SP time slot.

This selects the receive frequency for the SP time slot. These bits are valid only when there is a command to transmit an SP.

The Tx and RX frequencies should correspond to the same network channel.

The default frequencies are reinstated after the SP time slot.

SP Status Register SX TX Not CRC I .nt 'SSP Seen MMatch b7 b5 b4 b3 W0 TX RX oX Good Error Good b2 bI bo Bits

SP.

from come Table B-27 are meaningful when a device is receiving its own Bits are used primarily when the received SP is a different device, but are also valid when the SP has from the same device.

Dits H= SP Int.: Tx SPt This bit is set if there is an interrupt pertaining to SPs, making the information in this register valid.

This bit is set if the transmitted SP was for determining skew (an SSP). This bit is read only to the CPU# but is affected by reseat and the loopback bit. This bit is set when there is a reset and when the loopback bit is engaged OR disengaged.

During these times, the skew must, be calculated. After the skew is known, this bit is cleared.

This bit in set when the SP sent was not Not Seen: WO 90/13956 PCI'C/US89/01 06 77 detected.

CRC MMatch: TX Good: This bit is set when the transmitted CRC does NOT match ("MisMatch") the received CRC. This is used to help determine if the received SP is in fact the one transmitted.

Note that it is possible to have a good CRC (bit 0 w 1) and a CRC mismatch at the same time.

This bit is set when the transmission was successful. This means that CRC MMatchuo AND there were no bit errors in the received packet (the CRC checker indicates no errors).

This bit is set if the received SP (typically from another device) has passed the HASH, but has a CRC error. An interrupt may be generated as a result it the CPU has enabled interrupts for reception of bad SPs (see Interrupt Command Register Section 5.3.1.7) This bit is set if the received SP (typically from another device) has passed the HASH and has a good CRC. An intarrupt is always generated in this situation, Rx Error: RX Good: CVP Command Register ICmdI 0 FI/R TS4 T83 T82 TS TSO0 b7 b3 b2 bO Table Bita 89=i2 47:6> Cmd Emtign 11 Transmit CVP Illegal CPU command used by hardware 01 Illegal CPU command used by hardware 00 No Command (condition after reset) Cmd<i, >0 is cleared by the Rxtx state machine after the expected CVP delimiter tize has passed (whether or not it was received). This insures that the command is processed only once.

WO 90/13954 PC/US89/) 806

F/R-

TS

S78 If CVP transmission is "blocked" (so CVP Status Register), Cmd is cleared.

This bit determines whether to claim a time slot in the forward or reaverse frame.

These bits specify the time slot to be claimed.

Note that unlike the SP Command Register, TX and Rx frequenoies need not be specified since CVPs always claim time slots in the default channel.

CVP Status Register is CVP X Int b b7 7 Not Block CRC aA Seen IMatch Good 53 b2 b! SO Table B-29 CVP Int 14> Not Seen Block This bit is sat if there is an interrupt pertaiing to cVPw, making the information in this register valid.

This bit is set if there was no CVP detected during the specifiad time slot.

This bit is set if the D/ur free table entry indicates that th time slot was busy beafor the clai was initiated. CVP transmission was blocked because the time slot was already busy.

This condition will clear CmAd of the CVP Command Register.

this bit is set if the reoevaed CVP CRC does not match the transmitted CC, thus indiating collision or some other form of transmission error.

This bit indicates a succsftul seizure of the time slot.

41> CAC MMatch Tx cood WO 90/13956 VCT/US8/01806 79 VP Status Register The command register for processing VPs exit in the P-RAM Active Table. There is, however, a VP Status Register.

VP X XX X XTx Disc IFIF FIFO b7 b6 b5 b4 b3 b2 bl bO Table Bit,. HM Function VP Int This bit is set if there is an interrupt pertaining to VPs. The only bit that generates an interrupt is the Disc bit, the others are for status only.

S Rx FIFO This bit is set if the Rx Ring Buffer pointers are misaligned.

Tx FIFO This bit is set it the TX Ring Buffer pointers are misaligned.

i Disc This bit is set if the connection is dropped. An interrupt is generated after a disconnect. During the interrupt routine, the CPU must read all Rx Active table entries to determine which time slot(s) have disconnected.

BP Status Register As with the VPs, the command register for processing BPs is in the PRAM Active Tables. similarly, there is a BP Status Register.

"BP X SI witch RX Bf RX X Tx Buf TXu Xnt Error um Switch Nu Switchl t b7 b6 b5 b4 b3 b2 bl bo Table B-31 WO 90/13956 PCr/US89/01806 80 Bits Name EunUction <7> BP Int Switch Error This bit is set if there is an interrupt pertaining to BPs, making the information in this register valid.

Bits 5 to 3 pertain to the reception of BPs, while bits 1 and 0 are for the transmission of BPs. They work independently of each other and reflect the latest status of the transmitted and received BPs.

This bit is set if the Boot Buffer switch in the Rx direction was unexpected. This means that the delimiter received did not correspond to the boot buffer pointed to by the buffer pointer.

"Rx Switch" must be set for this bit to be valid.

This bit gives the number of the Boot Buffer that was just filled by the network and needs tr be emptied by the CPU. "Rx Switch" must be set for this bit to be valid.

This bit is set when there was an Rx Boot Buffer switch. This will generate an interrupt.

This bit gives the number of the Boot Buffer that was just emptied by the network and needs to be filled by the CPU.

"Tx Switch" must be set for this bit to be valid.

This bit is set when there was a Tx Boot Buffer switch. This will generate an interrupt.

Rx Buf Num <3> Rx Switch TX Buf Num TX Switch Test Command Register X I Test I LB OFFlin CRC Delay LB En S I I I I I b4 b3 b2 bl bO Table B-32 WO 90/13956 PCr/US89/01806 81 Function Test CRC LB Delay OFFlin Lb En When set, the CRC generator will induce CRC errors. This is used to test the system's behavior in the event of a CRC error.

When set, the loopback path will not have any delay. When reset, the loopback path will insert a 4-bit delay.

This bit is set to enable the OFF-line tests that will tie the transmitted data to the received data. There are two variations of loopback, determined by the TM Master/Slave bit. Master LB will loopback the entire frame. Slave LB will loopback only during the time slots that the device is transmitting. This is described in more detail in Chapter 4, "Maintenance and Diagnostic Commands" section.

RXTX Transmit Status Register No Tx Tx Tx Tx Tx 'Tx' Tx TX TM SSP SP BP1 BPO CVP VP b7 b6 b5 b4 b3 b2 bl bO Table B-33 A bit is set if the corresponding packet will be sent to the network. "No Tx" is set if there is no transmission or if network pseudo-silence is transmitted (possible only during Master-loopback mode).

RXTX Receive Status Register iJunk CVP ISilen.I SP TM BP1I BPO VP I Rxx'd Rx'd Rx'd Rx'd Rx'd Rx'd b7 b6 b5 b4 b3 b2 bl bO Table B-34 A bit is et when the corresponding delimiter is detected. Only one of the least significant 5 bits will be set et any time. "CVP Tx'd" is set only when a CVP was transmitted by the same device. The "Junk" and Silen Rx'd" WO 90/13956 PCT/US89/01806 82 bits may be set when the "CVP Tx's" bit is set. "JUnk Rx'd" is set when anything but the expected delimiter is received.

This bit tells the PCTL chip to ignore the incoming data.

Packet Status Register 'Frame CRC CRC RC X X X X Error X IMMatchlError I I I I I I I b7 b6 b5 b4 b3 b2 bl bO Table Bits Name Frame Error CRC MMatch Function Set when the Mod 8 frame number in the received TM packet changes the Frame counter in the RxTx chip by any number but one. This error can only be detected during slave mode.

This bit indicates whether the 16-bit CRC received during the previous time slot is equivalent to the CRC sent (l-Not equivalent or MisMatch). With the exception of Timing Marks, this is used whenever a device is listening to its own transmission. It is, for example, for VPs during bit error rate testing (a device loops back a time slot for on-line diagnostics) and for SPs since a device always receives its own SP.

When set, this bit indicates that the CRC is correct based on the packet received rather than on a saved CRC value as in "CRC MMatch," above. This is used for TMs (slave mode) and SPs.

CRC Error Current Channel Register 1 Tx3 Tx2 TXO RX3 R2 Rxl 1 RxO I I_ I b7 b6 b5 b4 b3 b2 bl b0O Table B-36 WO 90/13956 PCT/US89/01806 83 Bits Name Tx Functiqn Specifies the current Tx frequency for the VP and TM time slots; the frequency may be different for the SP time slot. This value can be changed by a "Change Channel" command in the Active Table.

Rx Specifies VP and TM different the current Rx frequency for the time slots; the frequency may be for the SP time slot.

The two frequencies MUST be for the same network channel. The RxTx chip does not check if this is true; it is up to the software to insure this.

This register is not used in TIMs since the Modem cards are shared between several TIMs. The Modem cards have a register for selecting the Tx and Rx frequencies.

Hash Address Register I I I I I I Ii CTLI CTLO CRC5 CRC4 CRC3 ICRC2 ICRC1 I CRCO 1 CC i I I .I I l I- I- I b7 b6 b5 b4 b3 b2 bl bO Table B-37 Bits Na=e

CTL

CRC

CRC

Function Chooses 1 of 4 HASH Table pages Chooses 1 of 8 rows in the HASH Table page Chooses 1 Of 8 bits in the HASH Table entry Interrupt Command Register 'Int I X X X X TM Mis ISP Err ims 'Enable Int En lInt En Int En' IW I- b5. I b3 I b7 b6 b5 b4 b3 b2 bl b0 Table B-38 WO 90/13956 PCI/US89/01806 84 Bits Name Int Enable TM Mis Int En Enables all control/interface circuit interrupts except for the following which requires additional bits to be set.

When set, this bit allows interrupts to be generated \Yvary time the threshold is passed for the number of consecutive TMs missed. The "Int Enable" bit must be set also.

When set, this bit enables interrupts for reception of SPs which pass the HASH, but have CRC errors. The "Int Enable" bit must be set also.

When set, this bit enables 1 ms interrupts as described in the "lms" bit of the TM Status Register. The "Int Enable" bit must be set also.

<1> SP Err Int En 1 ms Int En <0> Reset Command Register i x x x I x i X Reset' i i I b7 b6 b5 b4 b3 b2 bl bO Table B-39 Bits ae Function Reset This bit is cleared after reset and stays cleared until the CPU sets it. When cleared, the RXTx chip will stay in a reset state.

In the absence of a clock input to the RxTx chip, the chip can be reset by first writing a 1 then a 0. This sequence will hold the chip in reset.

WO "/1395C. WO 90/395t -r/US89/01806 Skew Register HSB I I _T I I _I _f I X_ I I -x b0 b6 b5 b4 b3 b2 bl bO Table Skew Register LSB 1 Sk-ew 71 Sk-ew5 6 k-ew 5'Sk-ewj F k-ew 3l Skew 21 Sk-ewl 1 Skew 0l b7 b6 b 5 b4 b3 b2 b1 bO Table B-41 O> Skew ~Fncion The combined bits in both Skew Register MSB and Skew Register LSB show the value of the skew calculated by the RxTx chip.

Rx Frame Register IRCy-c7 1R~yc6 IRCyc5 ICyc41 RC-yc.3 C-yc:2 I RCycl IRCyf:O0 b7 b6 b5 b4 b3 b2 bl bO Table B-42 Bits NM RCyc These bits show the value of the Rx Cycle (FRAME) number. This register will show the value of the RX Cycle number in the received TM packet if the TM had no CRC errors. If the received TM packet was bad, the last Rx Cycle number will be incremented.

Fault Register X II b7 b6 b5' b4 W3 b2 bi bO Table B-43 WO 90/13956 PCT/US89/01806 86 Bits Faul Fault This bit can be read to see if the modem has generated a fault. A fault will exist if the modem has been transmitting for an exceedingly long period in the order, of an entire frame.) Writing anything to this address will generate a fault reset pulse which will restart the modem circuitry.

Oscillator Enable Register X Ix X 7 X X Osc b7 b6 b5 b4 b3 b2 b I.I b b5.. b I b naIbe b7 b6 b5 b4 b3 b2 bl bO Table B-44 EmIation Osc Enable: When set, this bit enables the modem oscillator. It can be read to confirm the status.

WO90/13956 PCT/US89/01806 87 RXTX/PCTL Comman.ds Now that the organization of PRAM 82 and the RXTX 92 internal registers have been described, the various commands between RXTX 90 and PCTL 92 may be described.

The command number and a short description is stated.

The data field describes what should appear on the PRAM data bus as a result of the command. The source and destination tells where the data comes from and which devices use it.

COMMAND 0 (00000): Description: No operation Data Field: Don't Care Sourc=: PD is tri-stated.

Destination: PD is tri-stated.

The Commands will be NOPs (Command 0) until the Rx frame is locked the TM threshold is reached).

The following commands are specifically for the transmit or receive direction.

Commands Issued when Transmittina Data to Modem COMMAND 1 (00001): Description: Read Tx Active Table for present time slot.

Data Field: See Table B-9 iource: P-RAM Destination: RxTx chip and PCTL chip COMMAND 2 (00010): Description: Read Net Tx PCM Timeslot Map Entry. This register maps a network voice time slot to a PCM highway time slot.

Data Field: See Table B-13 Source: P-RAM WO 90/13956 PC'T/US89/01806 88 Destination: PCTL chip COMMAND 3 (00011): Description: Read Net Tx Read Pointer. This register holds the Xmt Ring Buffer address which points to the first byte to be transmitted in this time slot.

Da Field: See Table B-8 Source: P-RAM Destination: PCTL chip COMMAND 4 (00100): Desription: Read PCM Hwy Tx Write Pointer. This register holds the first Xmt Ring Buffer address which will be written into by the PCM' Hwy during this time slot.

Data Field: See Table B-7 Source: P-RAM Destination: PCTL chip COMMAND 5 (00101): :Description Read PCTL Transmit Status.

Data Field: See Table Source: PCTL chip Destination: RxTx chip COMMAND 6 (00110): Description: Send RXTX transmit Status to PCTL. The RXTX sends status to the PCTL, stating the type of packet that will be transmitted.

DatajField: See Table B-33 Source: RxTX chip Destination: PCTL chip COMMAND 7 (00111): Description: Transfer appropriate data. This command is used WO 90/13956 PCI'/US89/01806 89 whenever packet data is needed from the P-RAM.

Data Field: The data byte to be transmitted in the current packet.

Source: P-RAM Destination: RxTx chip COMMAND 8 (01000): Desc intion: Write the first byte of the last time slot's CRC.

Data Field: Least significant CRC byte.

Source: RxTx chip Destination: P-RAM (OBCO-OBFF) COMMAND 9 (01001): Dscgriotion: Write the second byte of the last time slot's CRC.

Data Field: Most significant CRC byte.

Source: RxTX chip Dst.inatiQn: P-RAM (OBCO-OBFF) COMMAND 10 (01010): Descriptin: Transfer CVP time slot number from RxTx to PCTL.

Data Field: Least significant 6 bits of the octet is the frame bit (forward or reverse) and the 5-bit slot number.

(Table B-28, bits Source: RXTX chip Destination: PCTL chip COMMAND 11 (01011): Descrintion: Read Busy/Free table of CVP time slot. The CVP Command Byte (see Table B-25) specifies forward or reverse frame. The RXTx chip will issue this command every frame, but the data field will be used only during the designated frame (forward or reverse).

Data Field: See Table B-11 WO 90/13956 PCl/US89/01806 Sourge: P-RAM Destination: RxTx chip COMAND 14 (01110): Description: Update Network Tx Read Pointer Data Field: See Table B-B Source: PCTI chip estination: P-RAM ICB Commands forthe F Jx Diretion COMMAND 16 (10000): Description: Update Rtk Active entry to report Disconnect.

Data Field: See Table Source: PCTL Detination: P-RAM COMMAND 17 (10001): Descripti.il: Read Rx Active entry for current time slot.

Data.Fi! Jd: See Table Source P-RAM Deatination: RxTx and PCTL chip COMMAND IS (10010): Dmrzipian: Read Net Rx-PCH Timeslot Map Entry. This register t aps a network voice time slot to a PCM highway timQ slot., Dat-F l See Table 8-13 SofUrl P- PH h Desti~tnation:: PCTL chip WO 90/13956 PCT/US89/01806 91 COMMAND 19 (10011): Descri$tion: Read Net Rx Write Pointer. This register holds the Rcv Ring Buffer address where the first data byte is stored. When issued during a TM or SP time slot, the TM or SP pointer is just cleared since these packets always start at the same buffer address.

Data Field: See Table B-6 Source: P-RAM Detination: PCTL chip COMMAND 20 (10100): Descrition: Read PCM Hwy Rx Read Pointer. This register holds the first Rov Ring Buffer address which will be read by the PCM Hwy during this time slot.

Data.,ield: See Table aS2rcg: P-RAM Deitination: PCTL chip COMMAND 21 (10101): Descrition: Read PCTL Receive Status Data liel: See Table B-16 Sourcet PCTL chip Dpleknation: RxTx chip COMMAND 22 (10110): Dsoriion; S Send Delimiter Status. The RXTX sends status to the PCTL, stating the type of packet that was received, Data ield. See Table B-34 S~a RXTx chip nastinatiJ.n: PCTL chip COMMAND 23 (10111): WO 90/13956 PCT/US89/01806 92 Description: Transfer appropriate data. This command is used whenever actual information is sent to the P-RAM.

Data Field: The data byte received in the current time slot.

Source: RxTx chip Destination: P-RAM COMMAND 24 (11000): Description: Read the first byte of the last time slot's CRC.

Daa.ield: Least significant CRC octet.

Source: P-RAM (OBCO-OBFF) Destinationl: RxTx chip COMMAND 25 (11001): Description: Road the second byte of the last time slot's CRC.

Dat Field: Most significant CRC octet.

Source: P-RAM (OBCO-OBFF) Destination: RxTx chip COMMAND 26 (11010): Detscrition: Read Busy/Free Table Entry of current time slot.

Data Field: See Table B-11 2a2U=~: P-RAM Destination: PCTL chip COMMAND 27 (11011): Description: Update Busy/Free Table Entry of current time slot.

Datalield: See Table B-11 Sorce? PCTL chip Destination: P-RAM 'WO 90/1356 PCr/US8901806 -93- COMMAND 28 (11100): pgsriptiola Send HASH address to PCTL.

=LEjfj4: See Table B-37 gourc6,!. 'RxTx chip Dg,Mt.ination: PCTL chip COMMAND 29 (l111): escriptign Read HASH table entry.

ata Fiel: See Table B-12 Notsa this byte is used by the PCTI chip only.

SQurce: P-RAII Destination: PCTL chip COMMAND 30 (11110): De.gription: Update Network Rx W~rite Pointer =illald': See Table 8-6 PCTL chip go tin n: P-HAM COMMAND 31 (11111): Wsicripiof: Send Packet Status. The RxTx sends status to the PCTL, stating any errors detected after the ontire packet has been received.

paarjotl.d: See Table 8-35 sogr: lRxTx chip pifipjatio: PCTL chip RXTXZPCT.IJOPE1ATtO In this section it is assumed that multiple channels WO 90/13956 PCr/US89/01806 94 are supported, and the terminals coupling RXTX 90 with PCTL 92 are broadly referred to as the interchannel bus (ICB).

Timina Mark Generation Upon initialization, it is necessary to establish system timing. To do this, CPU 72 sets the M/S bit in the TM Master/Slave Register (Table B-22) for each control/interface circuit which CPU 72 desires to be a potential TMG. Each potential TMG waits a random length of time (up to about milliseconds) and then its timing mark state machine transmits TM packets on all channels.

In the tables tha\ follow, the time period refers to the current octet on the node input (not the octet on the ICB).

Also note that the commands in some delimiter time periods are labeled "early," "late," or "r-ormal." An means either a 0 command or no command at all is sent (the delimiter or pad time period was curtailed).

Tx time slots start during the pad of the previous time slot. At this point, the time slot counters in the RxTX chip and PCTL chip are incremented (using the signal on ync Terminal 298). The Tx state machine is allowed two commands for every octet. Since all pads except TM pads are 12-bits wide, there can be up to 3 commands during these times.

Time Period Cm Comments Pad time before Enable Tx Modem 4 bits timeslot (12 bits) before start of Tx frame.

Cmds 1-4 automatically issued, but they are ignored for TMs.

Send Preamble TM master/slave bit (Table (8 bits) 22) determines if the Tx modem is enabled. If not, nothing is sent, but the command sequence continues.

Send TM delimiter (POh) Fetch frame number (8 bits) from an RXTX register.

CMDs 8 9 are for CRC WO 90/13956 PCT/US89/01806 95 Send Frame number (8 bits, data byte 1) Send TMG ID 1 (8 bits, data byte 2) Send TMG ID 2 (8 bits, data byte 3) Send Boot Control 1 (8 bits, data byte 4) Send Boot Control #2 (8 bits, data byte 5) Send CRC LSB (8 bits) Send CRC MSB (8 bits) (7,9) (7,0) (7,0) (7,5) (14,0) (0,0) (0,0) (frame number) checking of last time slot. Not applicable to first TM.

Start CRC accumulation on Tx'd packet with this byte. Fetch first byte of TMG ID information from P-RAM TxTM buffer.

Fetch second byte of TMG ID information from P-RAM Tx TM buffer.

Fetch first byte of boot control information from P-RAM Tx TM buffer.

Fetch second byte of boot control information.

CMD 14 is issued but is meaningless for TM transmission.

No command activity while CRC is sent.

Save CRC in PRAM CRC buffer. Turn off TX modem at end of CRC.

If a control/interface circuit 80 receives the TM packet that it sent intact, it assumes the status of master TMG. The other control/interface circuits clear the M/S bit, assume the status of slave TMGs, and monitor their respective channels to ensure that the master TMG is sending valid TM packets.

The following is performed when receiving TMs: Command (17,18) Rx TM Preamble Rx TM Delimiter Comments CMD#17,18,19,20 are automatically issued but are ignored by the PCTL for TMs.

early normal late (19,X) (19,0) (19,0,X) WO 90/13956 PCT/US89/01806 96 Rx Frame Number (Data Byte 1) Rx TMG ID Byte 1 (Data Byte 2) Rx TMG ID Byte 2 Rx toot Control 1 (Data Byte 4) Rx Boot Control 2 (Data Byte 5) CRC LSB CRC MSB (20,22) (23,21) (23,24) (23,25) (23,30) (23,0) Start CRC accumulation.

Here, the delimiter status is known. The RxTx will continue issuing commands regardless of whether a delimiter is detected or not. If not, the PCTL will ignore data xfer commands (#23) Write Frame Number into P-RAM Rx TM Buffer. Also save (at least) 3 Isbs of frame in temp register.

The Frame Number appears on the ICB. TM history reported missed good).

Write TMG ID Byte 1 into P-RAM Rx TM Buffer. CMDs 24 25 are issued to support CRC checking on the last time slot.

Write TMG ID Byte 2 into P-RAM Rx TM Buffer.

Write Boot Control 1 byte into P-RAM Rx TM Buffer. CMD#30 is issued while the last data byte is arriving, but is ignored here.

Last TM data byte transferred. Write boot control #2 byte into P- RAM Rx TM Buffer. The Tx'd CRC of previous time slot is compared to Rx'd CRC (stored in RxTx).

Results in CMD#31, TM status reported.

The TM has an 8-bit pad instead of 12.

Check Rx'd CRC register for zero immediately after incoming CRC is shifted through. If CRC checks, (0,0) PAD before SP slot early normal late (31,0,X) (31,0) (31,X) WO 90/13956 PCT/US89/01806 97 load receive frame (Mod 8) into RxTx's Rx Frame Register. Set "TM Rx'd" bit in RXTX Receive Status Register if slave mode is selected, and increment consecuive Rx Valid TM register. If CRC is bad, increment Rx Frame register and increment RX TM CRC error register.

If this TM is received 1 ms after the previous TM, set Multi-TMs and TM Int bit in TM status register. If no TM was detected at all, increment missing RXTM register and consecutive missing RXTM register, and set pending interrupt in TM Status register if missing TM threshold has been reached. If a good TM was received but the frame count is out-of-sequence, increment TM out-ofsequence register.

In the event that TM packets on any channels stop for sore number of consecutive frames (as determined by the Threshold register (Table B-18) and the Consecutive Missing TM register), the backup TMGs arbitrate to become the new master

TMG.

Since the TM is much smaller than the other packets, CMDs #26, 27, 16, 28, 29 are not issued.

Receive Frame Timing Once the master TMG is established, each control/interface circuit 80 must establish proper receive and transmit fra4e timing. This is done by first capturing and locking into the incoming TM packets. Both master and slave TMGs perform this function. After coming out of reset or after the TM window bit in TM Command/Lock Status register (Table B- 23) is set to zero by CPU 72, RXTX 90 will begin searching WO 90/13956 PCT/US89/01806 98 continuously the search window is "wide open") for good TM packets. During this time, no other packets are recognized.

It is possible to detect several good TM packets within a millisecond, since there may be different devices arbitrating to become the master TMG. Errors will be recorded to prevent a false lock. Once a steady stream of TM packets is detected with TM packets spaced about a millisecond apart, with good CRCs and good frame numbers, RXTX 90 will lock the incoming frame by setting the TM Window bit to one. This means that RXTX 90 will search for TM packet delimiters during a small window at a predicted time (every millisecond). This leaves the rest of the frame for servicing other packets, and RXTX can function normally. Furthermore, looking for TMs only when they are expected prevents occasional voice data which mimic TMs with valid CRCs from causing receiver synchronization malfunction.

CPU 72 sets the "TM lock threshhold" in the TM command register (see Table B-23) to determine how many consecutive good TM packets must be detected before the frame is locked. RXTX 90 will lock the frame automatically when this threshhold is reached. If the chosen threshhold is too long, CPU 72 can lock the frame manually by setting the TM Window bit to one. In this embodiment, RXTX 90 cannot automatically declare loss of frame and open the search window by itself to reestablish it. Even if several frames have passed without good TM packets, RXTX 90 must continue to predict frame boundaries until the device is reset or CPU 72 gives an explicit command to open the window.

After the TM lock threshhold is reached, the receive frame is established upon reception of the next good TM packet.

After checking the CRC of the incoming TM packet and determining that the packet is free of errors, RXTX 90 counts the number of bits of the TM pad time and creates a bit-wide pulse during the last bit of the TM pad. See Fig. B-5. A number of bits in an SP is then counted, and the first voice time slot is marked by a pulse. This continues until the.next WO 90/13956 PCT/US89/01806 99 TM time slot where the pulse is lengthened to 8 bits to mark the beginning of a new frame. Once the receive frame is locked, the receive frame time pulses are meaningful. These timing pulses are shared with PCTL 92 (via RXS terminal 282) and allows control/interface circuit 80 to receive information within distinct time slot boundaries.

In this embodiment, if the TM packet received has a CRC error, the beginning of the SP time slot is determined from the last good TM packet. That is, RXTX 90 continues predicting time slot boundaries even if the TM packet is bad. A separate signal indicates whether the present frame is forward or reverse. This is determined by the LSB of the received frame number of a good TM packet (in this embodiment, if the TM packet is bad, the signal is toggled). This signal will be valid after the TM CRC is checked for the SP time slot.

The pulses of the receive frame signals mark the predicted time of arrival of a preamble. In actuality, a packet may arrive four bits earlier or later (because of reclocking by HRU 50). Because of this, a 16-bit window is established in which the delimiter may be found. See Fig. B-6.

A delimiter that lies partly or wholly outside this window must be ignored so that neighboring time slots are not affected.

After the receive frame is locked, the TM and VP slots use 16bit windows. The SP slots use 16-bit windows also unless the SSP is expected. The pulse for the next time slot does not change if a delimiter of the current time slot is early or late. This is because the source of transmission of the next time slot is independent. The shift in timing caused by an early or late delimiter is absorbed by the preamble or the pad (one or the other is shortened).

Skew Calculation As explained in the discussion of Network Timing, the Tx frame must start a skew time before the Rx frame.

Therefore, before Tx frame timing may be established, skew must be calculated. This is done by transmitting and receiving a WO 90/13956 WO 9013956PCI/US89/01806 -100skew signalling packet (SSP). The skew is represented by the number of bit times (of the 5.018 M4hz clock) it takes for the round trip delay. To account for skew variations during operation, skew for a particular device is recalculated every time it sends an SP.

A Signalling Packet is sent out during the SP timeslot, according to the SP Space and Tx Channel bits of the command. In addition, this transmitted packet is received and the CRCs of each are calculated and compared to detect c~ollisions. An interrupt is given after this receive check is performed giving the results. The hardware clears the command after the packet is transmitted to ensure the same packet is not transmitted again.

All SPs transmitted are either 14 bytes long or bytes long from the end of the delimiter to the start of thet CRC control/interface circuit 80 always transmits one of these lengths). The short packets are used to set the skew so that they do not interfere with the first voice timeslot if the actual skew of the control/interface circuit is great. The maximum length packets are used at all times thereafter.

A new skew calculation is performed whenever a Tx SP command is given by CPU 72. The new value is only accepted by control/interface circuit 80 if the SP was received correctly.

The command sequence is generally the same for SPs and SSPs so both will be described now. Rx~x 90, however, will generate and send a CRC after the 14th byte of an SSP.

The Tx modem will be disabled after the CRCs are sent, but the command sequence will continue as if a regular SP is being processed. All commands issued after the SSPs CRC are ignored.

Since different types of SPs may have different priorities, SPs are placed in eight different partitions in this embodiment. The partitions are determined by a modulo eight frame counter ,(modulo four cycle counter) transmitted by the master TMG, CPU 72 specifies, via the SP command register, WO 90/13956 PC'/US89/01806 101 in which one or more of the eight partitions it can be sent.

RXTX 90 then transmits the SP on the next allowable frame.

This partitioning scheme is simple enough to be implemented in hardware, thus freeing CPU 70 for more important tasks.

Time Period Commana Comments Channel Change Pad (3 bytes) (0,0) Pad (12 time before SP bits) (0,0,0,1,2,3) Re-tune Tx frequency time synthesizer to transmit channel specified in Tx SP command register LSB.

Inspect both SP command Registers (MSB and LSB) If command pending, check Spbits to see if it can beXmt'd this frame. If so, set flags to tell Rxstate machine that an SPis being sent this frame,and its length (short orlong). Then enable TxModem 4 bits before transmission is tobegin. If no SP is to betransmitted this frame,no furthur Tx SPprocessing is required. mds 1-4 are ignored forSPs.

Clear CMD bits of SP command register, making it inactive so it is not executed again. The SP Command Regs determine 1 the Tx modem is enabled.

If not, nothing is sent, but the command sequence continues.

Read first byte of SP from Tx SP buffer (assumed to be LSB of destination address). CMDs 8&9 are for CRC checking of previous time slot.

Read next byte to be transmitted during the transmission of the previous byte.

Send Preamble (8 bits) Send SP Delimiter (CCh) (8 bits) Send SP Data bytes (14 total if SSP, 60 total if normal SP) (4,6) (7,8) WO 90/13956 WO 9013956PCI'/US89/01806 102 Data Byte I (Destination address LSB) Data Bytes 2-58 or 2-13 Data Byte 14 or 59 Data Byte 60 or 14 (7,9) Start accumulating CRC on destination address LSB.

Also start Skew Counter' as first data bit is shifted out to the network.

(7,S) (14 0) Send CRC (2 bytes) (10,11f 0, 0) CMD 14 is issued but is meaningless for SP transmission.

Save value of CRC register in PRAM for use by Receive State machine in doing collision detection.

Turn off Tx Modem at end of CRC. CVP processing (CMD 10, 11) takes place but is meaningful only if there is a CVP command and if the frame is correct (fwd o~r rev). See the command sequence for CVPs.

Idle Time (SSPs only up to 46 bytes) (0#0) Channel Change Pad (3 bytes) (00,00,0,00) Re-tune Tx frequency synthesizer to normal transmit frequency as specified in RxTx register.

Control/interface circuit 80 will receive any SP sent on the channel to which it is listening, except when that control/interface circuit is transmitting an SP on another channel during that frame.* The receive sequence f or SPs awid sSPs are the same except for the length of the data byte field. The flxTx will know if it had just sent an SSP because it will have set the TX SSP bit in the SP Status Register. Since the SSP is much smaller iii length than an SP, it may be received in a much larger window during the. SP time slot. Because of this, there WO 90/13956 WO 9013956PCr/IIS89I01806 103may be a long sequence of NOPs (Command 0) when waiting for the arrival of an SSP packet;, Comme~nts Channel Change (3 bytes) (0,0,0,0,0,0) No ICB activity. RXTX is changing channels.

Active and timeslot map regs are read but ignored for SPs.

Rx SP Preamble time (17,18i) RX SP time Delimiter very late early normal late (19,0, (19 tX) (19,0) (19 go toX) RX SP Dest. Address (Data Byte 1) lbc SP Dest. Address (Data Byte 2) RX SP Control Field (Data Byte, 3) (20,22) (23t26) (23,t27) For SSPs ONLY.

Send CMD 0's until delim is found or until window is closed.

CMD Wt20 is ignored for SPs. Here the delimiter status is k~nown. The RxTxwill continue issuing commands regardless of whether a delimiter is detected or not. If not, the PCTL will ignore CKD#23. Start accumulating Rx CRC with this byte, which is the least significant byte of the destination address.

Read "SP BF Buffer Status Register Full"I bit. if full, do not transfer any bytes of incoming SP to the PRx SP Buf fer and stop processing. Increment missed 1RXSP count bits if address hash passes.

Write LSD of destination address to Rx SP Buffer increment pointer into P- R~AM The first Data byte appears on the XCD. CMDo 26 and 27 are ignored for SPs.

'Write 2nd LSD of Address to RX SP Buffer WO 90/13956 PCT/US89/01806 104 SP Data byte 4 (23,16) [Remainder of physical address treated as Data by hardware.] Data Byte 5 Data Byte 6 (23,28) (23,2,) increment pointer.

Latch bits of Rx CRC calculation after first 4 bits of Control byte shifted into CRC checker.

Write SP Control Field to Rx SP Buffer increment pointer. CMD 16 is ignored.

After 3 data bytes (2 address, 1 control) is known, the address HASH is calculated Using first bits of control field concatenated with bits of latched CRC as the address into the P-RAM resident hash table road appropriate byte.

Use bits to select a single bit in the Hash Table entry If this bit i' set, the packet has passed the address hash. Terminate RX SP processing if address hash does not pass.

Here, the HASH results are reported. The RXTX continues to issue commands regardless of whether the HASH is passed or not.

The TX'd SP CRC is compared with the Rx'd CRC (stored in RXTx).

Data Byte 7 Data Byte 8 Data Byte 9 Data Bytes 10-59 or DBs 10-13 for SSPs Data Byte 60 or DB 14 for SSPs (23,21) (23,24) (23,25) (23,0) (23,30) CMD#30 is issued while the last data byte it arriving, but is WO 90/13956 PCr/US89/01806 105 ignored for SPs.

CRC LSB CRC MSB (23,0) (0,0) (0,0) Place data byte 60 into Rx SP buffer.

Depending on when an SSP is rx'd, there may be idle time.

Idle time (SSP ONLY) (up to 46 bytes) Channel Change (3 bytes) (31,0,0,0,0,0) Packet status is reported. RxTx is changing channels.

PAD time before VTS early (0,0,X) normal (0,0) late (0,X) If CRC checks Rx CRC calc. equals zero after received CRC shifted through), set the "SP BF Full" bit, the Rx Good bit in the SP status register, and set the SP interrupt bit. If CRC does not check, set the CRC MMatch bit and increment the RxSP CRC Error register and generate an interrupt if enabled. Update the skew registers (MSB and LSB) with the skew value.

Changes in skew values will not generate interrupts to the CPU. The skew registers however, can be read by the CPU, in case variations need to be monitored.

Transmit Frame Timina In this embodiment, the Tx frame is generated two different ways depending on whether control/interface circuit is a master TMG or a slave. For a slave, the start of the TX frame depends on when the TM was received and the length of the skew, For a master, the Tx and the Rx frames are independent.

Slave-Mode. Slaves are all control/interface circuits except for the device that is a master TMG. As noted above, the TX frame must start a skew time before the Rx frame, WO 90/139.% WO 90/13956PCr/US89/O1 806 -106- However, the control/interface circuit needs to know the beginning of the flx frame to establish the beginning of the Tx frame. one way to circumvent this dilemma is to establish the beginning of the next Tx frame.

Each Rx frame is given a frame number by the master TMG.

The Rx frame with frame number N will establish the beginning of the Tx frame with frame number N+1 (See Fig. The beginning of the TX frame is determined by counting down from a fixed point in the lbc frame until this counter equals the skew count register. This fixed point must be far enough from the end of the Rx frame so that the maximum possible skew that the system will tolerate can be supported. This point is thus called the maximum skew point or MSP.

The time slot boundaries of the Tx frame are slightly different from that of the Rx frame. Instead of starting during the last bit of the previous packet's pad time, the pulse. occurs at the beginning of the pad time. This allows PRxTx 90 t6 prepare for data transmission well before the upcoming preamble (See Fig, B-B).

Mate Moegf a control/ int ei !ace circuit is the Master TMG or if it is contending to become the TMG (during power up or the loss of the Master TMG), the start of the TX frame is independent of the Rx frame. The start of the TX frame is dependent, however, to the start of the TX frame of other TMGs in the system. The control/interface circuits can work by themselves, but in this embodiment, all TMGs are synchronized (via the C-H/S bit in the TH Command/Lock Status register (Table B3-23) and SYNC terminal 298) so that transmissions of T~e occur simultaneously.

The pulses for the Tx frame edring Master Mode is the same as for Slave Mode. That is, the beginning of a time slot in marked by a pulse at the beginning ofa previous time slot's pad time.

Notice that the 1Rx timing differs from Tx timing in WO 90/13956 PCT/US89/01806 107 that Rx time slot boundaries are predicted values. Frame boundaries are aligned after receiving a good TM, but since each time slot contain information from varied sources, the first byte of the packet, the preamble, may actually appear 4 bits earlier or later than the predicted time slot boundary.

(The theoretical limit for error is plus or minus 2 bits, but the RxTx chip will accept up to plus or minus 4 bits of error).

Because of this discrepancy, it cannot be guaranteed that there will be a total of four commands during the preamble/delimiter time. Worst case, a time slot can receive a packet 4 bits earlier than predicted. Since the time slot counter changes at the predicted preamble time, half of the preamble time will have alneady passed if a packet comes early. This, effectively, allows for only one command during the preamble time. If the preamble is late by (worst case) 4 bits, there may be up to three commands during the preamble.

Since it is not known whether a packet is early or late until the delimiter is detected, this discrepancy is taken care of during the dalimiter window. Two XCB commands will be sent during the predicted preamble time, but during the delimiter time one, two or three commands are sent depending on whether the packet is early, on time or late, respectively.

The PAD is affected also. If the packet is late the pad time is shortened; hence, there may be only two commands instead of three during the 12 bit pad of voice time slots and only one command instead of two for the 8-bit pads of TM and SP time slots. If the packet is early, the pad time iD lengthened; hence, there may be up to four commands during voice time slot PADs and up to three for TM and SP PADs.

Othert Network. C nd After the appropriate timing parameters have been established, normal command processing may take place. A more detailed description of the other network commands and how they are processed using the RXTX/PCTL commands shall now be described.

WO 90/13956 PCT/US89/01806 108 Transmit Claiming Voice Packet (Tx CVP) The CVP command register is used to determine if there will be CVP transmission in the present time slot. The command instructs control/interface circuit 80 to send a single VP out on the selected VP timeslot and check the transmission coming back to detect collisions. If this one shot packet is transmitted and received with no errors, this unit has successfully claimed the selected VP timeslot, and can set up a normal Tx VP command. If not, the unit can try to claim another timeslot.

The control/interface circuit checks the selected VP timeslot's busy/free table entry before sending the CVP (during SP processing) to eliminate race conditions on a claim. If it is found to be already busy, the control/interface circuit inhibits the CVP transmission, sets a status bit, and reports this condition via an interrupt. If the claim was actually sent, the busy/free entry is left free. This allows units involved in CVP collisions to arbitrate between themselves for. the timeslot. Other units will not be able to claim the slot as their Ibusy/free tables will indicate that the timeslot is busy. This feature is especially useful for multiple responders.

Time Period ommand Comments Pad time before each VTS Check CVP command register to see if a claim is to be made this timeslot; if so, CMDL is ignored.

(Claim over-rides normal voice transmission). Read Busy/Free table entry for this timeslot during SP command processing. 'If the timeslot is already busy (Busy/Free entry is not above threshold), set the Block and CVP Int bit in the CVP status register to inhibit transmission of claiming VP If the timeslot is free, enable TX Modem 4 bit times before start of preamble.

WO 90/13956 PCT/US89/01806 109 Claim VP Preamble Claim VP Delimiter (33h) Send Data Byte 1 16 of claim VP Data Byte 1 Data Bytes 2-14 Data Byte 15 Data Byte 16 Pointer back to P-RAM.

CRC computed on data (4,6) (7,8) Also clear the CMD bits to prevent the CVP from being sent again next cycle.

Send Preamble.

Send VP Delimiter.

Read byte number 1 of TX CVP buffer.

CMDs 8 9 are for CRC checking of previous time slot.

Start CRC accumulation on first data byte. During each data byte from 1 read next byte to be Tx'd from Tx CVP buffer.

(7,9) (7,0) (7,5) (14,X) Transfer remaining data bytes.

Check PCTL transmit status.

Write new Net Tx Rd Save bytes 1 16 until next PAD, at which time it will be written to P-

RAM.

The results of CRC checking are not known until the following time slot since the CRC matching is done then. RxTx needs to remember the transmit time slot to send the CVP (n) and the receive time slot to check it If the CVP is transmitted, it is received and its status reported with an interrupt. The possible conditions are successful claim (Rx'd packet matched Tx'd packet), collision detected, or nothing detected.

Transmit Voice Packet (Tx VP) This command, given WO 90/13956 PCI'/US89/01806 110 via the Tx Active Table entry for the selected voice timeslot, instructs control/interface circuit 80 to transmit 16 bytes of voice data onto the network during this timeslot each cycle.

It gets this voice data from the P-RAM via PCTL 92, which has been previously set up by CPU 72 to deliver data from the correct PCM Highway timeslot or tone buffer.

This command is not used until the selected voice timeslot has been successfully claimed, hence there is no need to check for collisions. For maintenance reasons, however, a CRC will be computed on both the transmitted and received 16 byte data field. These values will be compared for each transmission, and any error will be logged in the Tx Packet Bit error register.

Tin~e Priod Comments Pad time before each

VTS

(1,2,3) Store calculated Tx CRC of packet sent in previous timeslot (in P- RAM) in case required by Rx State Machine for Tx and Rx comparison (e.g.

SP, CVP). Read Active table and prepare pointers. The Tx modem is enabled 4 bits before the start of the preambleif active. If not, nothing is sent, but the command sequence continues.

If channel change bit set,load new TX modem channel into current chaniiel register and do notailow a transmit this slot.

Send Preamble. Also, get Net Rd pointer for PCM Highway timeslot transmit ring buffer in P-RAM, if the active/idle bit in mapping register indicates VP Preamble (4,6) WO 90/13956 PCT/US89/01806 111 from Tx Silence VP Delimiter (33h) (7,8) (only inside PCTL).

VP Data Byte 1 15 silence be sent, send da buffer instead of from transmit ring buffer.

Send VP Delimiter. Get the first data byte from tie P-RAM using Net Transmit Read Pointer.

Increment this pointer Send VP Data. During transmit of byte N, fetch byte N+l from P-RAM, and increment pointer inside PCTL. Compute CRC on data bytes.

CMDs 8&9 are for CRC checking of previous time slot.

Transfer remaining data bytes.

Check PCTL status.

Send VP Data. Write new Net Tx Rd Pointer back to P-RAM. Save CRC computed on data bytes 1 16 until next PAD, at which time it will be written to

P-RAM.

This command, given Data Byte 1 Data Zytes 2-14 Data Byte 15 Data Byte 16 (7,9) (7,0) (7,5) (14,X) Receive Voice Packet (Rx VP) in the Receive Active Table entry for the selected timeslot, instructs RXTx 90 to receive incoming packets during this timeslot and transfer them to P-RAM 82 under control of PCTL 92. PCTL 92 has been previously set up by CPU 72 (through P-RAM) to deliver data to the correct PCM Highway timeslot receive ring buffer.

Time Period Command Comments Rx VP Preamble (or TM preamble, if last VTS3 (17,18) Read Receive Active Table entry for this VTS. If timeslot is not active, continue processing only WO 90/13956 PcM/US89/018Q6 112 until busy/free table update is performed. If a CVP was sent during this Tx timeslot, perform' sequence and busy/free update specified under TX CVP command.

Rx VP Delimiter Rx VP Data Byte 1 early (19,X) normal (19,0) late (19,0,X) (20,22) If anything but silence is recognized, clear busy/free to zero and write this byte back to P-RAM. If only silence is recognized by the time data byte 1 should be shifted into RxTx, add one to busy/free byte (unless already 255), and write back to P-RAM. If Rx active table entry indicates voice or boot is active, and the busy/free entry has just passed its "free" threshold as set in the threshold register, set the disconnect bit in the PCTL Receive status register and clear the active bits in the Rx active byte. Also write this byte back to the Rx Active table and set the Disc and VP Int bits in the VP status register.

Start CRC calculation on this byte.

Here, the delimiter status is known. The RxTx will continue issuing commands regardless of whether a delimiter is detected or not. If not, the PCTL will ignore CMD#23 below.

During reception of byte N, write byte N-1 to RX VP Data Byte 2 16 WO 90/13956 PCT/US89/01806 113 Rx Data Byte 2 Data Byte 3 Data Byte 4 Data Byte 5 (23,26) (23,27) Receive ring buffer in P-RAM and then increment Net Rx Write Pointer as stored in PCTL.

The first data byte appears on the ICB.

B/F and active table commands issued to PCTL chip. If a delimiter is found, the B/F-busy except for CVPs. For CVPs, B/F-free until the VPs are rx'd in the time slot.

(23,16) (23,28) (23,29) (23,21) (23,24) The HASH commands are issued but results are ignored.

Data Byte 6 Data Byte 7 Data Byte 8 Data Byte 9 Data Bytes 10-15 Data Byte 16 If Tx VP CRC checking is enabled for last timeslot, read CRC calculated on Tx'd VPfor that time slot. Compare to Rx CRC calculated on last Rx'dVP (stored in RXTX temp. register). If these do not match, increment the TX Packet Bit Error Register.

(23,25) (23,0) (23,30) PAD before next TX early (23,31,0,I) normal (23,31,0) late (23,31,X) Write pointer updated while last DB is still arriving.

Write byte 16 to Receive ring buffer and increment pointer stored in PCTL.

Write new Net Rx Write Pointer back to P-RAM.

Save Rx'd CRC calculated WO090/13956 PCM/US89/01806 114 on data bytes of this VP in temporary register for use during next timeslot to recognize VP CRC errors. Store 0 if no packet was RxId i.e. no, VP delimiter was detected.

This ensures the TX Packet Bit error register records a bit error in the delimiter.

This command, given Transmit Boot Packet (TX BP) via the Transmit Active Table entry for the selected voice timeslot (and enabled via a boot mode bit), instructs control/interface circuit 80 to send the next 16 bytes of the currently selected boot buffer (0 or 1) out during this timeslot, using the corresponding boot delimiter. If this 16 bytes completes the buffer, control/interface circuit will automatically switch to the other buffer, set status bits, and interrupt the CPU.

Timd Command Comments Pad time before each

VTS

BP Preamble BP Delimiter (rCh or 03h depending on the boot buffer used) (1,2,3) (5,6) (7#8) If boot bit in table is aet and boot mode is enabled, enable Tx modem 4 bits before the beginning of the preamble.

If not, it is disabled, but the command sequence continues, CMD#2 3 are ignored.

CMD#5 is issued instead of 4 to get current boot buffer from the PCTL transmit status register.

This decides the delimiter, Send delimiter of current boot buffer in use (0 or 1) as indicated by the CUR buffer bit. Read next boot data byte to be sent from current boot bufferusing the transmit WO 90/13956 PCT/US89/01806 115 BP Data byte 1 15 Data Byte 1 Data Bytes 2-14 Data Byte 15 BP Data byte 16 (7,9) (7,0) (7,5) (14,X) boot pointer register.

Increment boot pointer.

Send boot data byte. Read next boot data to be sent and increment boot pointer in PCTL.

CMDs 8&9 are for CRC checking of previous time slot.

Transfer remaining data bytes.

Check PCTL status.

Send boot data byte. If boot pointer has rolled around to 0 (from 255), toggle current boot buffer bit, set boot switch and empty buffer bits. Set the TX switch, Tx Buf Num and BP Int bits in the BP status register to generate an interrupt.

Receive Boot Packet (Rx BP) The following is performed for a Rx BP command by the Receive State Machines.

Command Comments Rx BP Preamble Rx BP Delimiter Rx BP Data Byte 1 (17,18) early (19,X) normal (19,0) late (19,0,X) (20,22) Here, the delimiter status is known. The RxTx will continue issuing commands regardless of whether a delimiter is detected or not. If not, the PCTI will ignore CMD 123.

If boot delimiter type matches current Rx boot buffer in use,leave WQ,90/13956 PCT/US89/01806 116 current boot pointer intact. If the new delimiter is different, toggle the current boot buffer bit, and reset thd receive boot pointer to 0.

While BP data byte N is being Rx'd, write BP byte N-I to the current boot buffer in P-RAM. Increment boot pointer in PCTL.

The first data byte appears on the ICB.

Rx BP Data Byte 2 16 Data Byte 2 Data Byte 3 Data Byte 4 Data Byte 5 Data Byte 6 Data Byte 7 (23-30) (23,27) (23,16) (23,28) (23,29) (23,21) (23,24) The HASH commands are issued but results are ignored.

Data By:e 8 Data Byte 9 Data Bytes 10-15 Data Byte 16 PAD before next

VTS

The Tx'd CRC of previous time slot is compared to Rx'd CRC (stored in RxTx). Results in CMD#31 (23,25) (23,0) (23,30) early normal late (23,31,0,X) (23,31,0) (23,31,X) Write pointer updated while last DB is still arriving.

Write BP byte 16 to current boot buffer.

Increment boot pointer, modulo 256. If carry out occurs, toggle current boot buffer bit and set an interrupt pending, with status indicating buffer was filled when switch occurred. Also latch boot buffer number before the switch so that WO 90/13956 PCr/US89/01806 117 software knows which buffer to process.

Transmit Silence (Tx Silence) Th;s command is implemented via a normal Tx VP command, combined with the active/idle bit in P-RAMs Network Transmit -PCM Timeslot Map Entry for the timeslot.

Packet Controller PM Highway Commanda This section briefly describes the operation of the Codec State Machine process. The Codec State Machine is responsible for the following: Buffering Voice and/or Tone data frook/to the codec bus to/from the network fo, each of the 24 codec bus timeslots.

Sending tones to codec bus timeslots and network timeslots from P-RAM 82. These tone patterns are written by CPU 72 before initiating the tone, and are read out continuously by the codec state machine to the desired timeaslots.

Gain level switching of voice and tones toward the codec bus. Voice data from the network and tones destined for the codec bus can be attenuated or amplified as desired via a digital pad controlled by the codac state machine. CPU 72 writes the 256 byte-long PCM translation table into P-RAM 82, and when commanded, the codec state machine will use each voice or tone sample as an address into this table, and send the contents of that location to the codec bus.

Codec Bus Control. The codec state machine provides the transmit and receive enables to control a codec (or SPU) on the codec bus, The timeslot(s) at which it is enabled is programmable by CPU 72 via P-RAM 82 Additionally, the codec state machine provides the enables which allow its PCTt chip to transmit on the codec bus These are also set by WO 90/13956 PCT/US89/01806 118 CPU 72 via P-RAM 82.

The codec state machine (hereafter called CSM for short) is a time division multiplexed state machine. It performs operations for each of 24 codec bus timeslots. All of the CSM's commands, data ring buffers, ring buffer read and write pointers, tones, tone pointers, and gain tables are stored in P-RAM 82. All software commands and associated data (such as tones and gain tables) are written into P-RAM 82 directly, as P-RAM 82 is dual-ported between PCTL 92 chip and CPU 72. All required arbitration logic is in PCTL 92. In addition, various status information can be accessed by CPU 72 via P-RAM 82.

The CSM executes a set of actions for each codec bus timeslot. The machine reads a control byte from P-RAM 82 at the beginning of each codoe bus timeslot. This byte tells the CSM which actions should be performed for this timeslot in both the receive (to codec) and transmit (toward network) directions, as well as which codec enables, if any, should be given.

The following describes each of the data transfer modes the CSM will support, and gives explanations of each mode. As noted above, PCTL 92 operates on PCM data coded in the mu-255 standard. Hence, the value commonly referred to as "zero" in sign-magnitude is coded as FFh for PCTL 92.

Likewise, negative full-scale is coded as 00h, while positive full-scale is coaed as R.eceive PCM HiahwaYCommands t ocodecs If Idle mode is selected for a given timeslot, the CSM performs no data transfer operations. This mode should be salected for every unused receive codec bus timeslot.

R his teod is seelected for norm ic traar ro an This mode is salected for normal voice transfer from an WO90/13956 PCT/US89/01806 119 incoming network timeslot to a PCM Hwy Rx timeslot. The CSM performs the following operations: 1. Read Receive (from Network) ring buffer read and write pointers from P-RAM 82.

2. Read a byte from the Receive ring buffer, performing required checks for under or overflow.

3. Update Receive ring buffer read pointer information to P-RAM 82.

4. Read location of gain table for this codec timeslot from P-RAM 82.

Send byte read from Receive ring buffer through gain table (use it as address into the 256 byte gain table).

6. Send result of this read operation to codec bus (if enabled).

Receive Tone with Gain Switching This mode is selected for sending a short tone (less than 256 samples per cycle) to a PCM Hwy Rx timeslot.

This mode can be used in conjuction with a Transmit PCM Hwy command to generate a tone to the network only by filling the gain table withi zeros (OFFh), thus sending silence to the codec bus.

The CSM performs the following operations: 1. Read page number (256 byte block in P-RAM) of tone buffer.

2. Read current offset into tone buffer.

3. Read next tone sample to be sent out, using the previous two bytes as address into P-RAM 82.

4. If tone sample is negative full-scale value (de *ied illegal), make tone sample w OFFh and write tone offset back into P-RAM as 0. Otherwise, keep tone sample as read, add 1 to offset and write this value back to P-RAM 82.

Read location of gain table for this codec timeslot from P-RAM.

WO 90/13956 PCT/US89/01806 120 6. Send tone sa~mple through gain table (use it as address into the 256 byte gain table).

7. Send result of this read operation to the codec bus (if enabled).

Receive Lgna Tone without Gain Switching This mode supports tones with cycles longer than 256 bytes, but it does not perform gain switching, The CSM performs the following actions: 1. Read current tone page number from P-RAM 82.

2. Read current tone offset in page from P-RAM 82.

3. Read tone sample from P-RAM 82 using above bytes as address 4. Read beginning tone page number from P-RAM 82.

If tone sample is negative full-scale value deemed illegal), make tone sample OFFh, write current tone offset back into P-RAM as 0, and write beginning tone page number back to P-RAM as current tone page number. Otherwise, keep tone sample as read, add one to 14 bit quantity current tone page and offset, and write the resulting least significant 8 bits back as current tone offset, most significant 6 bits as current tone page number.

6. Send tone sample to codec bus (if enabled).

Receive Short.Tone Terminate thQisCycle This command is identical to the Receive Tone with Gain Switching command except that it will not start another cycle through the tone buffer. It remains at the end of the current tone buffer, constantly reading out the last (illegal) value and sending silence to the Codecs. CPU 72 uses this command to transition between normal tone generation and idle state.

After software switchez ftom a rzaciv Tonu wiith Gain Switching to this command, it should allow PCTL 92 to finish the current tone cycle before starting another tone or switching to idle. CPU 72 can deduce that the cycle is completed by reading the tone offset pointer in P-RAM 82 a few WO 90/13956 PC/US89/01806 121 times and noticing it is at the terminal value (multiple reads are performed to guard against the case where the Terminate this Cycle command is given just after the command word is.read for the last tone sample in the cycle. For a short time the terminal value is in the tone offset pointer, but since PCTL 92 is executing a previous command, it will wrap around to zero).

An alternate method is to simply wait 32 milliseconds after issuing the Terminate this Cycle command this is the longest it could take to finish a 256 byte tone pattern.

The C3M performs the following operations: 1. Read the page number (256 byte block in P-RAM 82) of the tone buffer.

2. Read current offset into tone buffer.

3. Read next tone sample to be sent out, using the previous two bytes as address into P-RAM 82.

4. Xf the tone sample ii negative full-scale value (deemed illegal), make tone sample a 0FFh and DO MOT write the totie offset back into P-RAM 82. Otherwise, keep tone sample as read, add 1 to the offset and write this value back to P-RAM 82.

Read location of gain table for this codac timeslot from P-RAM 82.

6. Send tone sample through gain table (use it as an address into the 256 byte gain table).

7. Send the result of this read operation to the codec bus (if enabled).

Bgceive LonciTone -Terminate this Cvcle This command is identical to the Receive Long Tone without Gain Switching command except that it will not start another cycle through the tone buffer. Xt remains at the end of the current tone buffer constantly reading out the last (illegal) value and sending silence to the Codecs. The CSH performs the following actions: 1. Read current tone page number from P-RAM 82.

WO 90/13956 PCT/tJS89/01806 122 2. Read current tone offset in page from P-RAM 82.

3. Read tone sample from P-RAM 82 using the above bytes as the address.

4. Read the beginning tone page number from P-RAM 82.

If the tone sample is negative full-scale value (deemed illegal), make tone sample OFFh, but DO NOT write current tone offset back into P-RAM as 0, and DO NOT write the beginning tone page number back to P-RAM 82 as the current tone page number. Otherwise, keep the tone sample as read, add one to 14 bit quantity current tone page and offset, and write the resulting least significant 8 bits back as the current tone offset, and the most significant 6 bits as the current tone page number.

6. Send tone sample to codec bus (if enabled).

Transmit PCM Hiahwav Commands (from Codecs)

XIQ

If Idle mode is selected for a given timeslot, the CSM performs no data transfer operations. This mode should be selected for every unused transmit codec bus timeslot.

Transmit Voice This mode is selected for normal voice transfer from a PCM Hwy Tx timeslot to an outgoing network timeslot via a transmit ring buffer. The CSM performs the following operations: 1. Read Transmit (to Network) ring buffer read and write pointers from P-RAM 82.

2. Write the byte received during this codec bus timaeslot from the Tx PCM Highway (the codee transmit bus) to the transmit ring buffer, performing required checks for under or overflow.

3. Update Transmit ring buffer write pointer information to P-RAM 82.

WU 0/139565 PCr/US89/01806 123 Transmit Tone This mode is selected to transmit the Tone (without gain switching, regardless of which receive tone mode was used) retrieved for the Receive direction to the transmit ring buffer and thus the outgoing network timeslot. If the Receive command was not one of the two Tone Commands, this command will place meaningless information in the transmit ring buffer. The CSM performs the following operations: 1. Read Transmit (to Network) ring buffer read and write pointers from P-RAM 82.

2. Write the tone sample (using non-gain switched value) to the transmit ring buffer, performing required checks for under or overflow.

3. Update Transmit ring buffer write pointer information to P-RAM 82.

Transmit Rx PCM Hichwav Data This mode places the data from the corresponding Rx PCM Highway timeslot into the transmit ring buffer. If this PCTL chip is transmitting Rx data onto the Rx PCM Highway, this mode loops that data back towards the network. If another PCTL is driving the Rx PCM Highway during this timeslot, the data placed in the transmit ring buffer is from another control/interface circuit (and hence a different network channel). Thus this mode can be used to bridge VPs between network channels. The CSM performs the following operations: 1. Read Transmit (to Network) ring buffer read and write pointers from P-RAM 82.

2. Write the byte received during this codec bus timeslot from the Rx PCM Highway (the codec receive bus) to the transmit ring buffer, performing required checks for under or overflow.

3. Update Transmit ring buffer write pointer information to P-RAM 82.

WO 90/13956 PCT/US89/01806 124 Skew Calculation In the most general case, the HRU receives signals on upstream leg of the network and rebroadcasts them on the downstream leg of the network. The HRU provides a constant phase data signal to the downstream frequency band by adding fractional bit delay to upstream packets, as their relative phase upon reaching the HRU varies with the VIU's physical position on the network, and by inserting a pseudo-silence pattern for times in which there is no upstream data. The HRU uses a digital phase-locked loop (DPLL), well known in the art, to insert this variable fractional bit delay.

A phase-locked loop (PLL) located in the VIU modem recovers the system clock from this downstream signal, and the Receiver/Transmitter circuit uses that clock for receiving downstream data as well as transmitting upstream data.

Fig. C-l shows a pair of voice interface units (VIUs) 1002 and 1004. The upstream frequency band on the broadband cable is shown schematically as a transmission line 1006, with the downstream frequency band being shown as a receiving line 1008. Each of VIUs 1002 and 1004 transmits in the upstream band (line 1006) as shown by arrows 1010, 1012. Similarly, each of VIUs 1002 and 1004 receives signals in a downstream frequency band (line 1008) as shown by arrows 1014, 1016. A series of timing marks 1018 which appear in the downstream frequency band are shown beneath line 1008 in Fig. C-l.

As can be seen, VIU 1002 is a distance L1 from HRU 1020, while VIU 1004 is a distance L2 from HRU 1020. If VIU 1002 attempted to transmit in a timeslot defined to begin N microseconds after a timing mark 1018 by actually starting the transmission N microseconds after the timing mark is detected, the transmission would actually be received by VIU 1002 at a time t(skew) later. Time t(skew) is 0 where t 1 is the distance to HRU 1020, C is the speed of the signal on the transmission medium and t o is any delay incurred through the HRU. A transmission from VIU 1004, on the other hand, will be delayed by (2*L2/c)+t 0 Accordingly, data transmitted by VIU WO 90/13956 PCT/US89/01806 125 1002 will actually fall farther behind timing mark 1 1018 than data transmitted by VIU 1004.

This problem has been solved in the past by using a clock on the transmit line as in the ring network, or using the parallel transmit clock as in the Coffey patent discussed earlier. According to the present invention, each VIU upon booting up will determine its particular skew time by transmitting a test data packet and calculating the amount of time before it receives the test data packet. This time then is designated as a skew time, and each information packet transmitted thereafter will be transmitted an amount of time equal to the skew time earlier than the time that the specified timeslot will be detected on receiving line 1008 at that particular VIU. Test packets are transmitted immediately after the reception of the frame timing mark. For example, if a VIU determines a skew time of 38 microseconds, this represents a network o( approximately 3 miles in radius (assuming a delay of 6.25 microseconds per mile for an electromagnetic wave in the coaxial medium).

Timing marks 1018 are preferably generated by a timing mark generator located with the HRU or in a separate timing mark generator which is coupled to some point along the transmission line. The timing mark generator can be at any location on the cable, but must broadcast within all of the frequency bands. The timing marks then will be translated into the downstream frequency band by HRU 1020.

Fig. C-2 is a block diagram of the circuitry of any node connected to the system. A media interface unit couples the node to the media and to the control logic. An application interface unit couples the particular application to the control logic and the media. This core technolegy makes modularity possible and drastically reduces the complexity and time required for new application product development, enabling delivery of high quality, reliable products far more quickly.

A timing mark transmitted by a Timing Mark Generator Unit, is broadcast once per millisecond, establishing the link WO 90/13956 PCr/US89/01806 126 frame structure. Each VIU's RxTx circuit, after checking the timing marks for integrity, locks its internal counters to the framing established by the timing marks.

The VIU's CPU commands the RxTx and PCTL circuits to send signalling packets in the timeslot immediately following the timing mark. RxTx measures the skew time of the first such SP and adjusts its transmit frame to start (SKEW) bits before the next timing mark is received before its receive frame starts). Thus, any signalling or voice packets transmitted by a VIU will appear at the HRU at the correct instant referenced to the timing mark.

Establishing Voice TeleDhone-Link To establish a telephone call, a user picks up a phone 22 of Fig. A-4, and dials an extension number or an outside line. If an outside line is dialed, trunk interface unit 25 of Fig. A-i is the destination, and will act like the other voice stations as described below in establishing a connection to the originating station. The trunk interfacing then performs the necessary translation to send a call out on the outside telephone line.

Fig. Cr-i shows a flow chart of the sequence of events of the originating telephone station and Fig. D-2 shows a flow chart of the sequence of events of the receiving telephone station. When microprocessor 72 detects the off-hook condition of phone 22 and the dialled number, it initiates a program stored in DRAM 85 to establish a telephone link.

When off-hook the telephone sits on its "home" channel, which is one of the four frequency channels on the network, as assigned during a boot operation. The microprocessor under control of its program, causes the circuitry of Fig. A-4 to monitor timing marks and identify the position of timeslots, and then mcnitor the timeslots for the presence of pseudo silence. Pseudo silence is a series of alternatihg Ils and o0s which is inserted by the HRU to maintain synchronizationo Zf other than pseudo silence is WVO 90/13956 PCT/US89/01806 127detected, this means that a transmission is occurring in a particular timeslot by another station. A table is kept in PRAM 82 of the busy and free timeslots.

The program routine initiated by a telephone call first calls a function designated "claim-new" in order to claim a new timeslot. A random one of the free timeslots in the busy/free table in PRAM is chosen. The timeslot will be free in PRAM if no transmissions have been detected for 8 cycles or more. A dummy transmission packet (CVP claiming voice packet), containing a unique identifier will then be transmitted in the selected free timesVLt. The channel is then monitored to detect the return of the dummy packet on the receiving end of the selected channel as a result of the retransmission by the HRU. The received packet is compared to the originally sent packet, and if it is the same, no collision has occurred with another station trying to transmit.

If the CVP (claiming voice packet) is successful, subsequent occurrences of the timeslot are then filled with dummy data packets to maintain ownership by the originating station. If a collision has occurred, the process is repeated with a random selection of another free timeslot. At the same time that dummy packets are being inserted into the claim timeslot, a signalling packet is sent out on the same channel in the signalling packet position of a frame. This signalling packet specifies the originator's home channel and the position of the voice timeslot that was claimed, in addition to the originator's LUA address and the destination address. Again, the signalling pAcket is monitored on the return channel to ensure that no collision has occurred. if a collision has occurred, a retransmission is done after a random amount of time. After a successful transmission of the signalling packet on the home channel, modem 70 of Fig. A-4 is switched to the next channel and another signalling packet is sent in the same manner. This process is repeated until a signalling packet has been sent on all channels, The modem is then returned to the home channel to monitor the channel for a response.

WO 90/13956 PCr/US89/01806 128 At the receiving end, the address node is constantly monitoring for signalling packets addressed to it, even if it is involved in a conversation. These signalling packets (SPs) are filtered by hash tables as discussed earlier. Each node contains a 64 bit hash table for each of its PUA, LUA and SLE adreoses. As SPs are detected, the last six bits of the cyclic redundancy check of the address is used to produce a number corresponding to a position in the hash table. If a bit is set in this position, the signalling packet is then examined by software to determine if the address is for this node. If the bit is not set, the SP is ignored. Thus, the hash table provides a quick, initial filtering.

If the node has been addressed, and it is busy, a signalling packet will be sent to a trunk interface unit (TIU) with instructions for it to be retransmitted on the originator's home channel to inform the originator that the called node is busy. Since the modem of the receiving phone is busy, it cannot itself switch to another channel to send the response directly.

If the called node is not busy, it will switch its modem to the caller's home channel and monitor the transmissions to fill its busy/free table. The called node will then attempt to claim the timeslot in the reverse frame of the one occupied by the calling party. The reverse frame is simply an alternate frame, with originating party only occupying every other frame. The definition of which is the forward and which is the reverse frame is accomplished simply by the timeslot being claimed by the originating party being designated the forward frame, and thus could vary.

A timer is set to provide sufficient time for the busy/free table to become valid. When the timer expires, the timeslot of the originating node is examined to see if it is still occupied. If it is not, it is assumed that the call has been terminated. if it is still occupied, the called station attempts to claim the reverse timeslot in the same manner as the originating station claims the initial timeslot. If such a WO 90/13956 PCr/US89/o1806 129 claim is unsuccessful after several tries, a new timeslot is claimed and the originating station is informed in the same manner as if the called station were the originating station.

The originating station will attempt to move to the reverse frame of the newly specified timeslot.

Once there is a successful claiming of the reverse timeslot, the called station transmits an indication to this effect to the originating station in a signalling packet.

Thereafter, voice transmissions are sent in the voice packets.

Session Laver As described above, the session layer provides services required to establish and maintain connections between nodes on the network.

Depending'on the application and presentation supported on the diffrent types of nodes, session has to support different interface functions. In the case of the VIU and AIU, presentation functions are performed by the codec in the AfU and hardware and software controlling the VIU. The application layer function is to support the common telephone interfaces to the end user. The codec chip provides analog to digital conversion (and vice versa). Hence the services provided by the VIU and AIU sessions also include the following: Accept and interpret the keyed-in information.

Keyed-in information will be suitably decoded by the presentation layer before providing it to the session layer.

Provide the appropriate digital information to the codec to generate suitable tones to the user to indicate call progression.

Monitor the hook-switch changes and take appropriate actions.

Control the flow of digitized voice between the codec and the network.

Provide digital information for the VXU software to display the appropriate status of the calls and feature WO "/13956 WO 9013956PCr/US89/01806 130activations.

In addition to providing services as outlined above, the session layer must rely on certain services from other layers. This includes exchanging signalling information (transport layer), reserving voice circuits (link layer), and tone generation (link layer).- The nodes connected to the network exchange the signalling information using In order to communicate with other session layers using these SP's, a session layer must be able to set certain requirements on the way in which an SP is transferred over the network. In general session must be able to specify the RF channel(s) on which a signaling packet has to be transmitted, whether it should be notified of t~he delivery of the SP or not, cancelling of the SP transmission request *etc. in addition it must also receive the notification of any SP~ received for its consumption. The transport layer provides Ihese services to the session layer.

The transport level supports the 1kollowing transaction types required by the session layer.

TI(R) is a transaction information frame. It is transm±4-%ted as a "reliable" datagram, and will carry massion data. An acknowledgement is expected from the receiving session. If no acknowledgement is received within the set time-out, sending session will get notification from the transport.

TI(P) is a transaction information frame, It is transmitted as a "pure" datagram and will carry seQssion data.

It requires no acknowledgement from the receiving session* Best effort will be made (by the link layer) to transmit the packet.

TX(ijACK) is a transaction information frame similar to TI(R). It is transmitted as a "reliable" datagram and carries session data. In addition it will acknowledge the receipt of a transaction being received by the session.

Tl(PAC() is a transaction information frame similar to TI Transmitted as a "Ipure"I datagram and carries WO 90/13956 PCI/US89/01806 131 session data. In addition it will acknowledge the receipt of a transaction being received by the session.

TR(S ACK) is a transaction response frame generated by the session. It is transmitted as "pure" datagram. It will carry no session data and acknowledges the receipt of a TI(R) or TI(R ACK). In addition, receipt of this frame indicates that the receiving session has accepted the service request.

Receiving transport will notify the receipt of this frame to the session.

TR(SNACK) is a transaction response frame generated by the session. It is transmitted as a "pure" datagram. It will carry no session data and acknowledges the receipt of a TI(R) or TI(R ACK). In addition, receipt of this frame indicates that the receiving session has rejected the service request. Receiving transport will notify the receipt of this frame to the session.

TR(T ACK) is a transaction response frame generated by the transport. It is transmitted as a "pure" datagram and acknowledges the receipt of a transaction in proper sequence by the transport. This acknowledgement is for the transport layer and will not be passed to the session.

TR(TWNACK) is similar to TR(TJACK). However it informl the transport that an out of sequence message was rectiv6d by the transport.

The digitized voice between two communicating nodes is transmitted on dedicated VTS's. In order to establish a voice communication, a node must be able to reserve a pair of VTS's for its exclusive use. When a node initiates a call request through a SP, it will inform the other nodo(s) that a particular VTS has been reserved. It will also indicate to that node, which time slot of the reserved VTS pair is going to be used by the requesting node for transmission of digitized voice, If more than one node is willing to communicate, then they must able to contend for the response time slot (the eamaining time slot in the reserved VTS pair). The node which is successful in contending for this time slot will get the WO 90/13956 Pcr/US89/01806 132 right to complete the communication with the requesting node.

In order to provide the above function, session layer requires the following services from the link layer: The ability to reserve a VTS pair. This VTS pair is referred to as a voice circuit and is used for full duplex voice communication between the two nodes.

The al,%lity to contend for the response time slot (one of the time slots within the reserved VTS pair).

The ability to specify a delay factor while contending for a VTS. This will give the capability to prioritize the claimin between the contending nodes.

td) The ability to specify the transmission of either silence or voice on a VTS.

The ability to specify transmission (either voice or silence) without contending for the respnding VTS.

This will be used when the node is aware of the fact that other nodes are not competing for completing the communication path.

The capability to detect the absence of data on a VC (either silence or voice) for disconnect purpose.

In order to support the standard telephone interfaces to the user# session must be able to provide the codec with the digital data required to produce the appropriate call progression tones. In order to provide this, session requires the following services from the link layer: The ability to specify the type of tone and direct it to either codec or network or both.

The ability to stop the tone.

The ability to interrupt an active voice path and provide a tone for a specified amount of time and then continue with the voice communication.

The ability to initialize and change tha tone buffers used by PCTL 92 for tone generation at run time.

There are 1000 available SP time slots per second, on which a node can transmit a SP, However this SP space is partitioned into eight spaces and a session oendJig a SP can specify the partition(s) on which this particular SP has to be WO 90/13956 PCT/US89/01806 133 transmitted. Since the SP space is available to all the nodes, it is possible that more than one node may transmit simultaneously, which will result in collision. These collisidns will be detected and suitable actions will be taken by the lower layers. The session layer will be able to specify the transaction type for transmitting the SP. It is the responsibility of the transport layer to guarantee the reliable delivery of a SP (if desired by the session). The SP's will be transmitted by the transport as one of the transaction frames described earlier.

SP's are used by the session layer for the purpose of establishing a call between nodes. SP's are also used for the purpose of activating or cancelling some end user features and for negotiating some special services for the users. It should be noted that a VIU session will generate SP's for AIU, TIU, or NBU sessions (or vice versa). Therefore protocols are described according to the session which initiates the SP flow.

Hence the responding node could be of the same or different type. The destination address field in the SP header will determine the node(s) to which a SP is intended for.

Call Processia Protocols A user action on a VIU (either an attempt to establish a call or activate/cancel a particular feature) may result in a set of protocols exchange of different SP's).

The discupsion below will describe these protocols.

When a VIU user initiates a call request (by dialing digits), depending on the digits dialed it will result in one of the following set of protocols. In general when a user intends to make a call request (either to another station on the network or to a off-nat number) a CALLREQUEST SP will be generated. As a general rule the following conventions are observed before transmitting a CALLQREQUEST SP, Reserve a VC (a pair of VrTS').

Determine the channel (or channels) on which the CALi.EQUEST has to be sent. In general if the CALLtREQUEST is WO 90/1396 PCT/US89/01806 134 intended for the other similar type of node which has only one modem (an AIU or another VIU), then the CALL REQUEST SP is sent on all the available RF channels. If the destination node has one modem per RF channel TIU's and NBU's), then CALL_REQUEST SP is sent only on one specified channel.

Specify the RF channel on which it expects responses (usually the channel on which the VC has been reserved).

Only CALLREQUEST SP's will be broadcast on all available RF channels, Other SP's will be transmitted on only one of the RF channels as determined by the CALLREQUEST SP.

There are some exceptions to these rules in some specific protocols.

Figs. E-1 to E-3 show the SP's exchanged when the destination station is an individual extension Fig. E- 1 shows the situation where the IE can accept the call (Note: Apply Ringing is shown as a generic indication, it could as well be a call waiting indication). When the station is initiating a call request for another station on the network it will do so by sending the CALL REQ EXT SP. If the responding station is an IE it is the only extension with that address on the network) and is willing to accept the call, it will send an ACCEPT(IE) SP on the specified RF channel. When the calling session receives this response, it determines that there is only one station with this extension and acknowledges this station by sending an ACK SP. (It must also be noted that whenever a transport layer receives an ACK packet of any type (TR(SACK), TR(SNACK), TI(PACK), or TI(RACK)) it will clear its retransmit table of the transaction which caused this particular ACK).

When the receiving station user answers the call, an ANSWER SP will be sent. When this is acknowledged by the calling station, the call will be completed. If no ACK SP is received by the called station within the set time, then the called station will receive dial tone.

Pig. E-2 shows the situation when the called WO 90/13956 PCI/US89/01806 -135 extension is an IE and cannot accept the call because either the station is busy or it has DND in effect. In such a case, it will send a BUSY(IE).

Fig. E-3 shows the situation where, for some reason, no Xesponse was received within the set time-out. In such a case, the transport layer will notify the same to the session layer, at which point a REORDER tone will be given tu the user.

Figs. E-4 to E-7 show the situation where the called extension is a MAE, which means that more than one station may respond to the call request. Fig. r-4 shows the case where at least one station can accept the call. In the example there are three stations which have a line appearance for the same extension. Notice that ACCEPT(MAE) and BUSY(MAE) are transmitted as TI(R) and not as TI(RACK). This is done with a purpose. It h9 transport does not receive an ACK, it will not clear its z ,i mit table for this transaction. If a station in a MAE ias missed the CALL EQUEST SP in the first transmision, it is possible that it might receive it in subsequent retransmission. Thus, using these multiple broadcasts increases the probability of successful delivery of the CALL.REQUEST SP to all the stations in a MAE.

It is possible that many stations belonging to the MAE groups will try to respond simultaneously. This will increase the probability of SP collisions. This can be reduced by using some arbitration scheme for sending the response SP's.

In the present arbitration scheme, each MAE member will have an assigned position number for each of the stations within a MAE.

When a CALLt REQUEST EXT is received for a MAE extension, each station in the MAE will delay its response by an amount proportional to its position number te.j., u 10 msec.

where is its position in the group] This wIll reduce the probability of SP collisions, In order to minimize the maximum response timea the total number of appearances for a MAE extension will ba limited (say to When the destination extension is a MAE# if the calling station decides to disconnect the call before the call WO 90/13956 PCT/US89/01806 136 is answered, then a DISCONNECT SP has to be sent to all the ringing stations in the MAE. To facilitate this it is necessary for the calling station to maintain a list of ringing.

stations. It is awkward to maintain a list of responding extensions. In addition, the calling station would have to send a number of DISCONNECT SP's as "reliable" datagrams. To avoid this, a CONTINUE RING SP is broadcast on all the RF channels periodically (say every 1.5 sec.) as a TI(P). When a station answers the call by going off-hook, after acknowledging t 4 at station with an ACK SP, a STOPRING SP is broadcast on all tile RF channels. If a station receives this SP and if it is still ringing, then it will stop the ringing. If a station does not receive the STOPRING SP, it will monitor for CONTINUE RING SP. If a ringing station does not receive at least one CONTINUE RIUG SP within a set period (say every sec.) it will stop ringing the station. CONTINUE-RING and STOP RING SP's together provide a robust scheme in the MAE environment.

It is possible that more than one ringing MAE extension go off-hook simultaneously. In this event, only one of these stations will get the ownership of the voice circuit and will answer the call by sending an ANSWER SP. The other stations will receive a dial tone.

Fig. E-5 shows a MAE configured for the "single call" mode. In this mode, only one call is allowed on a MAE. XZ a station with one MAE extension is busy, it will be reflrtad un all the appearances of that MAE. If a MAE is configued for this modae, when a ringing MAE station receivas a STOPRING SP it will make itself busy. It will also monitor for a CONTINUEBUSY SP (say with a periodicity of 2 min.). If a busy MAE (which is not involved in conversation) does iot receive this SP in the set period, it will make itself idle.

Fig. E-6 ahows the disconnection of a oall after establishing a voice path. In such a cas&e, it is necessary to make other stations in that MAE idle. A MAKEIDLE SP will be broadcast as soon as a disconnect is detectad.

WO 90/13956 PCT/US89/O1806 137 Fig. E-7 shows the situation where the called extension is a MAE and at least one BUSY(MAE) is received by the calling extension. If no ACCEPT(MAE) is received before the expiration of time-out, a busy tone will be given to the user.

Figs. E-8 to E-11 deal with hunt groups. Hunt group extensions provide a mechanism to locate the first idle extension within a set of extensions. This means when a call request is made to the hunt extension each member can answer the call only if a member with the higher position has not answered the call already4 In order to provide this prioritized mechanism a call request will have an integer call attempt number in the CALL REQUEST SP (This integer number is transmitted as part of CALLREQEXT SP. CALLREQEXT(n) indicates the nth call request attempt for a hunt group). Each member in a hunt group will have a position number assigned to it. When the number in the CALL REQUEST SP matches the position number then that station will answer the call by sending either an ANSWER or a BUSY SP. The above scheme is sufficient if it can be guaranteed that all the members in the group will always be able to respond. In the event that some members may not be able to respond, it must be possible to make a new request to the next member. The following procedure supports this capability.

If the CALL REQ EX(1) is received by the hunt group members only the station with position I will send either an ACCEPT(HUNT) or BUSY(HUNT) SP. However, each other member will send the pertinent group information and its current status by sending HUNTGRP INFO (number of members in the group, terminating conditions if the last member does not answer the call, Busy/free). This SP is sent as a TI(P) and will not acknowledge the call request. similar to MAE, hunt members will delay their response depending on their position to reduce the probability of SP collisions.

When the CALL REQ EXT(n 1) is received by a hunt group member, it will compare its position number with On' in WO09O/13956 PCT/US89/01806 138 the call request SP. If they both match, it will send ACCEPT(HUNT) or BUSY(HUNT). These SP's will have other pertinent group information (number of members in the group, terminating conditions if the last member does not answer the call).

If it is necessary to make a call request (with n then the Busy/Free information received in HUNTGRPINFO SP's in response to the first call request attempt will be used to reduce the number of requests made. The requests will not be made to the members which sent the BUSY information explicitly.

If a busy response (or no response) is received for a call request made to the last member in the group then the call is terminated according to the terminating condition received in the hunt group information.

Fig. E-8 shows a situation where the first member of the hunt group has answered the call.

Fig. E-9 shows a situation where the first two members in the group are busy. A new call request will be made to the next member soon after receiving the BUSY(HUNT).

BWSY(HUNT) is transmitted as a TI(PACK).

Fig. E-10 shows a situation in which the first member of the hunt group failed to respond to the CALL REQEXT(l).

Note that the HUNT GRP INFO SP's are transmitted as a TI(P).

Hence the calling station has to wait till the time-out is elapsed. This gives a chance for the first member to receive retransmitted call request SP's.

Pig. E-11 shows a situation in which some hunt members are not responding. It must be noted that successive new call requests are made till all the members have been given an equal chance. Note that the calling station has to wait till the elapse of time-out to make a new call request when a hunt group member does not respond.

Figs. t-12 and E-13 relate to trunk calls. When the user dials digits requesting another user outside the network, then the session will initiate a trunk call request by sending WO 90/13956 WO 9013956PCT/US89/01806 -139- CALjREQJIXNK SP to the trunk group address. Since mor-e than one trunk group may be willing to answer the trunk call request, an integer number in the request SP specifies the group to which the request is made (similar to hunt group members). it is also possible to have a different extension for each trunk group. in this case there is no need for the integer data in the call request SP. In this case address filtering will be handled by the link layer. The decision to address a particular group has to be made by the session. This means some trunk addressing algorithms have to be implemented in the VITJ session layer.

Within each trunk group there can be a number of trunk interface modules (TIM's). Since each TIM will know the availability of its own trunks, an arbitration scheme is required for selecting only one trunk from different TIM's within the group. More particularly, each TIM within a grvup will have a position number associated with it. When a CALL REQ TNK is received by a TIM (which has the trunk group specified by the request number) it will perform the following functions.

If all the trunks within the TIM are busy, then that TIM will send a TRUNK -ACKINFO SP after delaying it for a time proportional to its position number (say n x 10 msec. where n is the position number of the TIM).* This SP will have information such as whether another trunk group exists or whether it is the last member v~ithin a group. This SP is transmitted As a TI(P) and will not cause the transport to clear its retransmit table. Tha delay factor used for transmitting the SP will reduce the probability of SP collioions when more than one TXM in a group is busy.

If a trunk is available, then the TIM will try to claim the response voice time slot after a delay period.

Delay 'mRacv.Cyclej n1 n2 x where RecvCyclej# t Cycle number on which the SP request was received# n1 i a preo-daterminad number of cycles WO 90/13956 PCT/US89/01806 140 (to allow session/transport response time), n2 a predetermined number of cycles (say n position number of the TIM).

If after the elapse of the delay period, the TIM is successful in claiming the response voice time slot then it will aeize a trunk and send an ANSWERINT SP to the caller.

Note that the delay used favors the TIMs with lower position numbei.r, and provides a method of locating an available trunk starting from the first trunk within a group. The delay used will be a cycle number and claiming is delayed till at least that cycle number before transmitting the ANSWERIHT SP. This delay !will be implemented in the link layer. Also the link layer will copy Recv Cycle_# of a received SP from a register in the control/interface circuit to the SP buffer in the PRAM.

The ANSWERINT SP indicates to the caller that a trunk has been seized and that the TIM is expecting the final call request SP

CALLREQTIKFJNL.

Since the same trunks are shared by the network and other outside networks which are making (alls to stations on the network, it is possible that a TIM mey find itself with no trunk available after claiming the response VTS successfully.

In this case it will release the response VTS and send a TRUNKGRPINFO SP to the caller.

When the caller receives the ANSWERINT SP from a TIM, a trunk is available for the user and the caller will send a CALLIREQTNK(FNL SP to this TIM only, so that the TIM can establish communication with the outside party.

Fig. E-12 shows the case where a trunk is available in the group. Note that TIM1 is busy and sends TRUNKGRP.INFO immediately as a TI(P).

Fig. E-13 shows the case where no trunk is available in the first group. Based on the information received ii the TRUNKGRP INFO SP, the caller makes a second request to another trunk group,* Note that some TIM'a are not responding and the last TIM is busy and sending TRUNK(GRP.XNFO as a TI(PACK) and will cause the transport retransmit table to be cleared. In WO 90/13956 PCT/US89/01806 141 the second group also no trunk is available and the TRUNK GRPINFO SP indicates that no further group is available and the caller receives a REORDER tone.

Feature-Related Protocols Figs. E-14 to E-39 illustrate the protocols that are carried out when a user invokes a feature, either before or during a call.

Figs. E-14 to E-16 deal with call holding. When a user invokes the "hold" feature (either implicitly or explicitly), at the station initiating "hold" the receive side of the "VC" is disabled (DropRx). When the other station receives the HOLD SP it will disable both receive and transmit (DropRx and DropTx) and enters a HELD-BY state. When the station invoking "hold" receives the ACK it will drop transmit, make the circuit available to the network and enter a HOLDING state.

If the station in HELD-BY state is a MAE configured for a "single call" mode, then the station which invoked the hold will broadcast a CONTINUEHOLDING SP periodically (2 min.). If the members in that MAE fail to receive this SP, then they will become idle. (Note This SP is similar to CONTINUEBUSY SP in the active state).

If the station in the HOLDING state is a MAE configured for a "single call" mode, then the station in the HELD-BY state will broadcast a CONTINUETOJIOLD SP periodically (2 min).

When the station in the HOLDING state invokes "unhold", a ,tiw VC is reserved and the other station is notified, When the other station receives the UNHOLD SP it will enable its transmit and receive using this new circuit.

It is not necessary for the HELD-BY station to coaipete for the response voice time slot as it is the only one which is in HELD-BY state. A simple one-way ,old is shown in Fig. E-14.

When a station in HELD-BY state invokes the "hold" feature, then both the stations will enter a TWO-WAY hold states If WO 90/13956 PCT/US89/01806 142 either of the stations is an MAE configured for "single call" mode, other station will send CONTINUETWOWAY SP periodically (2 min.). Two way hold is as shown in Fig. It is possible that both stations might invoke "hold" simultaneously. In this case when the stations receive a HOLD SP, each station will enter a HELD-BY state and send in ACK.

When the ACK is received, each station will enter TWO-WAY-HOLD state. When a station in the TWO-WAY-HOLD state invokes "unhold", after receiving r ACK, it will enter a HELD-BY state. The other station after receiving an UNHOLD SP will enter the HOLDING state. Then this will be the same as oneway-hold case. If a station in HOLDING state receives a HOLD SP, then it 'will enter the TWO-WAY-HOLDING state. If a station in the HELD-BY state invokes "hold" then it will send a HOLD SP and after receiving the ACK will enter a TWO-WAY-HOLDING state.

If the stations in TWO-WAY-HOLD state invoke "unhold" simultaneously, then the station with the higher LUA will claim a new VC and acknowledge the "unhold" first by sending a TI(RACK). The second station then enables this circuit (TxVoice, Rxvoice) and acknowledges the earlier ZthOLD SP.

The simultaneous hold and unhold situations are shown in Fig.

E-16.

Figs. E-17 to E-19 deal with call forwarding. When a station invokes the "'forward t feature to redirect incoming calls to another station in the Interconnect a FORWARDJREQ SP is transmitted on all the RF channels. If the destination station is vJ.lling to accept the calls, it will send an ACK and the user will receive a confirmation tone. This situation is shown in Fig. E-17. If a station is not accepting the forward request, then it will send a FORWARDDENIED SP as a TX(P).

This will allow other stations, if any destination is MAE or hunt group) to respond. if no ACK is received before the time-out and if at least one FORWARD DEMIED SP was received, then the user will be given a Denial Tone. This situation is depicted in Fig. E-18. When a CALL REQEXT SP arrives at the forwarded extension, it will send back a FORWARDEDb.ND SP. At WO 90/13956 PCT/US89/01806 143 this time, the calling station will make a new call request to the destination station as shown in Fig. E-19.

In order to avoid the circular forwarding effect when chain forwarding is in effect at the destinations, the number of times a station can receive a FORWARDEDIND will be limited to 2. If the calling station receives more than this number of FORWARDED IND in a row (i.e after making new call requests to the destination station), it will not make any further call requests and the user will hear ring back at this stage.

Fig. E-20 shows the case when a first user has put one user on hold and is active with another user. The first user can invoke the "consult" feature and stitch to the other call. The SP exchange is similar to O ie-iay hold.

Figs. E-21 to E-26 deal with cAll transfer. A user wanting to transfer a currently active call to another extension puts the first call on hold and will try to establish the call with the other station. If thk station trying to transfer (called the arbitrator) waits until the other station answers the call and goes on-hook, the call will be transferred automatically. The SP exchange in this situation is shown in Fig. E-21.

However it is possible that the arbitrator may go on-hook before the call gets answered. Therefore, thC arbitrator station has special responsibility to sea that SP exchanges are handled properly. Depending on the destilation extension type and the state of the call, the following, things can happen. If the destination extension is an IE and ahe arbitrator goes on-hook after hearing the ringing, then the SP exchange is aa shown in Fig. E-22.

However, if the user chooses to go on-hook immediately and if the ACCEPT(IE) is received afterwards, then the ACCEPT(XE) is ignored by the arbitrator and the call between the arbitrator and destination station is terminated, The caller on hold stays on hold to the arbitrator*. If the destination extension is a MAE, then the arbitrator station will ACK the ACCEPT(MAE) SP's until the WO 90/13956 PCI/US89/01806 144 time-out. Then it will send TRANSFER REQ on all the RF channels. If at the end of another time-out at least one ACCEPT XFER is received, it will complete the transfer by sending a TRANSFERRED IND SP. At this time the station which requested the transfer will monitor the call (Apply ringback, send CONTINUE RING SP etc.). The SP exchange in this case is as shown in Fig. E-23.

If the called extension is a hunt group, and the station has sent an ACCEPT SP, then the situation will be similar to that of an IE. However, if a BUSY(hunt) is received for a call request, then the new call request to the next member is done by the station requesting the transfer. The SP exchange in this situation is as shown in Fig. E-24. If there was no response from the first member of the hunt group and at least one HUNT GRP INFO is received before the elapse of time-out, then the SP exchaile will be as shown in Fig. If a transfer request has failed for any reason (e.g.

no response before the elapse of a time-out, or a BUSYACK(IE) is received, or at least one BUSY ACK(MAE) is and no ACCEPTACK(MAE) is received, or BUSY ACK(hunt) is received from the last member of the group), a TRANSFERFAIL SP is transmitted to the station requesting transfer. At this time if a station (or TIM) is configured for ringing the arbitrator again, then it will send a RINGAGAIN SP as shown in Fig. E-26.

Figs. E-27 and E-28 show the SP exchange for call waiting. If an extension is configured for a call waiting, it will receive a call waiting indication if a second call arrives when the extension is already busy with one call. If the user chooses to answer the new call by disconnecting the current call, then he (or she) will receive ringing after disconnection, This situation is shown in Pigure E-27. on the other hand, the user can put the first call on hold by invoking the *consult! feature as shown in Fig. E-28.

Fig. E-29 shows the SP exchange for call pickup. A ringing extension (directed pickup or group pickup or night answer) can be answered by another extension with this feature.

WVO 90/13956b W 9Cr/US89/O1806 145 Fig. E-30 shows the SP exchange for call park.

Invoking the I'call park" feature, a user can park an active call at *another extension.

Fig. E-31 shows the SP exchange for call retrieve.

As user may invoke the "call retrieve"' feature at an extension to retrieve a call parked at another extension.

Fig. E-32 shows the SP exchange for camp on. A user after receiving busy tone, can invoke the "camp-on" feature.

When the called sthtion becomes idle it will send a CALLBACK SP to the calling station to indicate that it is free. This will initiate ringing at the calling station. When the user goes off-hook a new call request is made to the called party (with LUA as calling address) automatically. If the called station is not an IE, a CAMPO NCANCEL SP is broadcast. If the station invoking the "camp-on" feature is busy when the CALLBACK SP is received, the user will receive a call waiting indication. At this time, if user goes on-hook, he will hear ringing.

rig. E-33 shows the protocol for establishing a conference call. A 3-way conference is established when a user with two calls (one active and other on hold) invokes the "conference" feature. A conference server (the NBU) is involved in the conference. All the parties involved will have a full duplex voice path to the server. The station establishing the conference is responsible for obtaining the server resource# Figs. E-34 and E-3S show the SP exchanges for an AXU operator can invoke the "override" feature to barge-in to a currently active call. The SP exchange when an attendant invokes this feature during an active call is shown in Fig. E- 34. When the station has DrD in effect invoking "overrida will cause ringing at the stution. This is shown in Fig. E-3S Pigs. E-36 and E-27 deal with disconnecting ringing or held calls. If the calling station disconnects a ringing call, and the ringing extension is an tE, a DISCORMT SP is sent as a TI(R). When an ACI SP is received by the calling WO 90/13956 WO 9013956Pcr/UJS89/01 806 -146extension, it will become idle as shown in Fig. E-36. If the ringing extension is a MAS, the calling station will broadcast a DISCONNECT SP and will become idle as shown in Fig. E-37. If for some reason, a ringing MAE extension does not receive the DISCONNECT SPI it will continue to monitor for CONTINtJE.RXNG SP. The station will become idle when It does not see CONTINUE tXNG SP within the expected time.

A station in the HELD-BY state can disconnect a call by goS~ng on-hook. If the station in the HOLDING state is not a MAE cvrifigurad for "1single call"# a DISCONNECT SP' is sent as a TI(R). The HELD-Bly state, station will become idle after receiving the ACK SP as shown in Fig. E-38. If IfOLDXNG station is a MAE configured for a "1single call"# a DXSCONREOT SP is broadcast and the HELD-BY station will become idle as shown in Fig. E-39, If for some reason, a HOLDING MAE extension does not receive the DISCONNECT SP# it will continue to monitor for CONTXNUE.TO HOLD SP. The i*tation will become idle when it does not st& a CONTINUJE TOJIOLD SP within the expected time* Tilne-"raquency Multiplexing Fig. P-1 is a block diagram of the HRU and its connection to the network and the outside trunks. In the embodiment shown, RU 1020 includes 4 Network HWand Cards (NHC) for channels 1-4, Each NH1C is identical and includes a receiver 1022 and a transmitter 1024 coupled to network medlom 1026. Packets raceived through raceiver 1022 from redium 1026 are processed through the fast phase lock loop# MLO 1020# before being returned to transmitter 1024. Each HIIC is coupled to the sate medium and receives upstream tranAsmissions from the voice interface, units 1030 and retransmits them downstream on zedium 1026 on a different frequency. This is done by first receiving 'the upstream, data, reconstructing it# aynchrohiziing it with MU) 1024, then remodulating it with the proper downstream carrier frequency for retransmission. A path is also provided fromn MLD 1028 to an InpUt/Output, Procassor (TOP) 1032* TOP 1032 esaentially multiplexes the, four channels onto WO 90/13956 PCT/US89/01806 147 a trunk bus 1034 for connection to one of trunk interface cards 1036. Each trunk interface card 1036 couples to an outside trunk 1038 for outside calls. These trunk interface cards could couple to a central office, or other types of trunks which are standard in a public telephone switching network.

Fig. F-2 shows the phase locking of the clocks of four NHC cards. An external clock may be provided to a clock receiver 1040, which is then phase locked to an internal clock of one of the NHCs in a primary phase lock loop 1042. This is used to produce two master clocks A and B. Enable logic 1044 will enable the A clock on one NHC and the B clock on another NHC to be applied to the A and B clock buses, and disable the connection to the A and B buses for the clocks on the other NHCs. The A and B clocks are then provided to all of the NHCa, and a select circuit 1046 examines the clocks to determine which is a better quality. Thus, if one of the NHCs has a bad oscillator, its clock will not be selected. The A clock is selected by default in the event they are similar. Xf no external clock is present, the oscillator of the primary phase look loop 1042 is used as the A or B clock.

A secondary phase lock loop 1048 on aach NHC phase locks to the system A or B clock and produces four different phase clocks for use in the NIC circuitry as needed. Thus, all NHlC are synchronized to the same A or B clock.

Maximum tikelihood l.tegctor(.MLDL The NHC implements a data reclocking scheme to time align all data being passed through the NHC. Since the upstream transmission is supplied by an unknown source with regard to phase, the reclocking circuit uses a maximum likelihood detector or ML to raOlock the data. The standard solution of phase locking a clock from the incoming data edges is not workable nince a PL, with such a short integration time would be far less stable than is needed for the system, and extremely difficult to build* The MLD detects the edges in 4 bits of packet preauble, and then delays the data path by a WO 901139S56 PCT/US89/01806 148 time of 0 to 1 bits, (in increments of .062 bitzs) to properly align the center of the data bits and the edge of the sampling clock.

With this method, no frequency lock is required since the NHC's downstream transmissions are the system's source of master clock. All of the system's PLLs and clocks are frequency coherent unless a given unit is in failure mode; in which case it will be supplying no broadband transmission and does not pose a problem. With this understanding, we can assume that the NHC's MLD circuit must only account for phase or time alignment differences. The described functions can be implementad with high speed digital circuitry that responds to the received packet's needs within a four-bit time span during the packet preamble. The selected delay will remain locked until a loss of carrier is detected at the head-end which will be interpreted as an "end of packet". The NHC will begin inserting a pseudo-silence pattern (PSP) and reset the MLD for the next packet. The PSP maintains synchronization between transmissions. There must be a minimum of two bit-times between packets when no carrier is present to allow the MLD circuit to reset.

Referring to Figure F3, there is shown a block diagram of one type of maximum likelihood detector (MLD) 1152 suitable for use in accordance with the invention. The MLD 1152 comprises a shift register 1130, a bit stream combiner 1132 and a two-level to three-level data converter 1134. The shift register 1130 has associated therewith a high-speed clock 1136 and a bit synchronizer 1130. The bit stream combiner 1132 uses as an input either a received transmission as provided by bit synchronizer 1138 or, if no carrier is detected, a continuous pseudo data source 1140. The function of pseudo data source 1140 is to provide a continuous string of pseudo data, for example, 1 0 1 0 1 0 format data as the pseudosilence pattern (PSP). The continuous data stream is then provided to the data converter 1134 where two level data is converted to three level data. This conversion is done by WO 9113,5 W /eCr/Us"9/018( 149 translating the data stream into 2 parallel data streams at one-half the frequency. The 2 streams are then converted into a single, three level data stream at the same on-half frequency. This results in data with more than one bit per hertz. The output of the data converter 1134 is coupled to the transmitter of the HRU.

The purpose of the MLD 1152 is to align data for optimum reception. The various signals received in burst mode through the HRU receiver. Each exhibit different phases as a result of differences in distance along the upstream channel from the HRU, as well as differences in filter delays and differences in the phase of any local clock. The MLD 1152 adjusts for differences in the phase ~f the input data so that the system clock used in connection with receiving the data in a synchronous format can strobe the received data at or near the midpoint of the bit in the bit stream. To this end, the shift register 1130 is clocked by a high speed clock 1136 at, for example, eight times he input data rate whereby each input bit is shifted to eight possible positions in turn for output at a selected tap 1142, 1144, 1146, 1148, 1150, 1152, 1154 or 1156. In the specific embodiment, each tap of the shift register thus preients an output data stream differing in time delay by one eight bit from the adjacent tap. The bit synchronize 1138 monitors each one of the taps and selscts by means of appropriate optimization a bit stream from one of the taps, providing as its output a bit stream to the bit stream combiner 1132. The bi~ synchronizer 1138 may, for example, include a mult)lexer and means for checking each of the input bit streams for errors due to sampling at a less than optimum phase. Should it be deemed unnecessary to adjust the phase automatically, the bit synchronizer may comprise a simple solector switch coupling one selected tap through to the bit stream combiner 1132.

MLD 1152 operates by having the bit synchronizer 1138 examiie the data bits as they pass along the shift register 1130, The timt ralationhip between the rising edges and the 'O 90/13956 I'CE/US89/O 1806 150 falling edges of the data bits are compared to those of the system clock. Based upon the calculations made by the bit synchronizer 1138, the appropriate shift register tap among the eight possible taps 1142-1156 is used to extract the data and send it to the bit stream combiner 1132. This calculation estimates the center of the data bit.

The center of the data bit must be known relative to the system clock. (The system clock is derived from the high speed clock 1136 which also runs the shift register 1130.) The bit synchronizer 1138 examines one of the lines 1142-1156 and notes when the edges of the data bits occur with respect to each other and with respect to the system clock. The time relationships are measured in terms of the periods of the high speed clock 1136. This examination occurs on the first portion of the incoming data stream which has a preamble especially designed to ease the task of the bit synchronizer (usually a 1 0 1 0 1 0 1 0 sequence) and also to iallow the synchronization process to occur before the message bits arrive.

The data clock, consisting of two phases CLK phase 1 and CLK phase 2, at the nodes is derived from the bit rate of the continuous downstream bit rate transmitted by the head-end.

Thus, the burst (packet) transmissions from the VIU nodes to the head-end are at a frequency known to the head-end but at an unknown phase. Once the MLD 1152 determines the phase, that phase is conrtant throughout the burst transmission.

Therefore, once the MLD 1152 ascertains the phase of the preamble it does not make any further adjustments for the remainder of the burst transmission.

The center of the bit times are calculated by taking the bit period, that is, the time oatween the start and .the end of a bit as measured in high speed clock 1136 periods, and dividing by two. This measurement can be made by a counter wi.hin bit synchronizer 1138 which is started when a bit transition occurs and is stopped when the next transition occurs. A similAr counting method can be used to determine the time relationship between the bit edges and the master clock W0901139% WO ')O/13936I'MJ/US89/0 It06 -151edges. The appropriate shift register 1130 output 1142-1156 to take the data from is found from the time relationships between the data edges and the master clock edge. The implementation can be done from a look-up table in a memory within the bit synchronizer 1138 or can be calculated in real time with either hard-wined logic or j fast dedicated microprocessor., lld-nSI ni& Figs. F-4 and F-5 are a block diagram of one of the network head-end cards of the head-end unit 1020 of Fig. F-1.

Signals from the network broadband cable 1026 are received by receiver 1160. A carrier detect uircuit 1162 provides signals to maximum likelihood detector 1164 indicating whether a carrier, and thus a transmission, is present. If no carrier is present, the pseudo-silence data source in the MLD is activated. The data itself is processed through detector 1166, low pass filter 1168, amplifier 1170 and level detector 1172.

The resultant data is then provided to HLD 1164.

MLD 1164 can retransmit the data through a summation circuit 1174, buffer 1176,,low pass filter 1178, phase equalizer 1180 and an attenuator circuit 1182. The data is then provided to a transmitter 1184 in which the data modulates the carrier frequency in a modulator 1186, with the output biing provided through buffer 1188 and diplex filter 1190 back to broadband network cable 1026.

The connectioni to the trunks is provided through a modem bus multiplexer 1192 which -provides the signals from I4LD 1164 to a bus 1194. The signals from bus 1194 are provided to a connector 1196 as shown in Fig. F-5, Connector 1196 couples to the XOP card as shown in Fig. P-6.

A clock generator circuit 1198 cnrntaina the clocking circuit Shown in Fig. V-2. A PAL decode controller 1200 has logic for selecting the best clock. Fig, F-S shows a frequency switch multiplexer 1202 for selecting the frequency channel of the particular NHC by providing an approprialte input to a frequency synthesizer 1204. Fig. P-5 also shows a reset decode WO 90/13956 I'CMrUS89/0 1806 152 fault generator 2106 and a power supply circuit 1208.

Fig. F-6 is a block diagram of the IOP card 1032 of Fig. F-l. Each df four NHC cards as shown in Figs. F-4 and is connected via a connector 1196 to a controller/interface circuit 1210. The construction of the controller/interface circuit is the same as that used on the voice interface units as described elsewhere in this application. A phase lock loop 1212 synchronizes the IOP timing to that of the NHCs. A PCM highway 1214, identical to the PCM highway used in the VIUs, is coupled to a trunk data buffer 1216. This couples the data to a trunk bus 1034 as shown in Fig. F-l. The specific trunk card address is provided through a trunk address buffer 1218 and an address decode circuit 1220.

The IOP is controlled by a microprocessor 1222 which has access to an EPROM and EEPROM 1224 and a DRAM 1226. An interface and clocking circuit 1228 couples DRAM 1226 to address and data buses 1230 and 1232. A clocking circuit 1234 is used to provide a clock to controller/interface circuits 1210.

The I/O Processor Card (IOP), is a general purpose CPU card used to control up to 24 full-duplex voice timeslots.

These voice connections can be from any of the four voice channels via the four chip sets 1210 and modem buses 1196. A 80186 microprocessor executes software from the 512Kbytes of dynamic RAM. The 16K-bytes of EPROM allows the IOP to self-test itself and request to be booted, and an 8K-byte EEPROM provides non-volatile storage of configuration information. An additional 8K of EEPROM is available. The EPROM will also contain card serial number, date of manufacture, revision, etc. Circuit 1228 is used to provide DRAM control, parity error interrupt control, memory write protection, memory refresh, and Watch-dog timer. The Trunk Group Bus Interface connects the IOP to other cards in the trunk group.

The four chip sets 1210 each consist of two custom LSI chips and an 8K x 8 static RAM. These chip sets WO 90/13956 Pcr/us89/o0i06 153 communicate with each other over an internal bus. Circuits 1210 each include a Receiver/Transmitter (Rx/Tx) which interfaces to the modem serial bus on the TIU backplane. A Packet Controller (PCTL) provides the PCM Highway consisting of 24 full-duplex timeslots for connection to trunk interfaces and server circuits. PCTL also provides XOP access to P-RAM, packets, tone generation, etc. A P-RAM, Packet RAM, 8K x 8 static RAM, is used for storing voice and signalling buffers.

These buffers hold the incoming and outgoing packets as well as some commands for handshaking between the 80186 and circuit 1210. The 80186 can read and write this RAM. In addition, this RAM can be optionally stuffed with a 32K x 8 RAM with the addition of a jumper on the lOP. It should be noted that P-RAM cannot b successfully accessed without the 5.018MHz modem clocks from the backplanie.

Circuit 1228 is a custor TSI chip which provides all of the timings for DRAM control, memory refresh, data buffering, and write protection. It also includes circuitry to handle watch-dog timer and NMI generation to the 80186. It contains an error register which captures 18-bits of the address during write protect errors, and parity errors.

The lOP Card provides up to 512K-bytes of parity checked dynamic RAM. RAM can be configured in 128K-byte blocks. Chip 1228 provides all the control timing, address multiplexing, memory refresh, and data buffering for the DRAM.

All timings originate from the modem (NMCs or NHCs); the modem provides two 5.018MHz clocks in qu&drature which are Used by the CIC chips 1210 to recover data from the network and for internal state timing.

The 20.072MHz phase-lock-loop circuit receives and locks to the selected 5.018MHz clock from one of the four chips programmed to be the master. 20.072MHz is provided to a chip 1228 which returns a 6.176MHz clock to the CIC chips 1210 for the PCM Highway. Chip 1228 uses a 10,036MHz clock (20.072MHz/2) from the 80186 to synchronize its DRAM control logic.

WO 90/13956 1'CI'US89/011W6 154 The Watch-Dog Timer (WDT) function, contained in chip 1228, provides a method of detecting incorrect program execution caused by software bugs or hardware malfunction. The WDT appears as an I/O port on the 80186's bus, and drives Non- Maskable Interrupt ai RESET to the 80186 microprocessor. Once enabled, software must tickle the WDT once every two seconds to avoid a Non-Maskable Interrupt. If not tickled within two seconds after an NMI, chip 1228 will reset the 80186 microprocessor.

conlusion It can thus be seen that the present invention provides a technique for rapidly and efficiently downloading code and data to nodes in a distributed intelligence network.

While the above is a complete description of the preferred embodiment of the invention, various modifications, alternative constructions, and equivalents may be employed. For example, while a coaxial cable is used in the preferred embodiment, fiber optic and other media could be used. Similarly, while the TMG function is carried out by the NBU hardware, physically separate units could be used.

Additionally, while the preferred time domain multiplexing scheme shows the SP interval at the beginning of each frame, with two frames making up a cycle, there are other possibilities. For example, there is no absolute reason to have two SP intervals in each cycle. Nor is it necessary to have the two Therefore, the above description and illustrations should not be taken as limiting the scope of the invention which is defined by the appended claims.

WO 00/ 1 39! j WO bC'IUSfI9/Of806 155 Table A-1 L~ist of AbbreviationIS AIU attendant interface unit/console BCFSP boot control siyjialling packet BP boot packet BRSP boot request signalling packet O~ID configuration identifier CVP claiming voice packet HRU head end retransmission unit IE individual extension lOP 1/O processor LUA local unique address HAD multiple appearance extension MLD maximum likelihood detector NBU netoork boot unit NMWS network manager workstation PCM pulse code modulation PCTL packet control circuit PRAM -packet RAM PUA physical unit address RxTx receive/transmit circuit SLE system link extension SP -signalling packet TIM trunk interface modul.,, TMG timing mark generator TM timing mark VC voice circuit VIU voice interface unit VP W voice -packet Ofts voice time $lot, WOW90/139 icr/US89OI/01806 156 Table A-2 Packet -tAJ (lengths in bytts- 1 Timina Mark Packet (TMI 10 bytes 1 Preamble 1 Unique Delimiter 1 Cycle Number 2 TMG Identification 1 Boot Control Information (4 bits for boot channel, 3 bits for Tx channel that corresponds to the Rx channel in which this TM was received, and one bit for an installation indicator) 1 Reserved for other boot information 2 CRC 1 Pad Sienallin Packot (sPI 71 bytes 3 Channel Change Pad (subject to change depending on modem delays) 1 Preamble 1 Unique Delimiter Data (60 bytes fixed in h/w, but the s/w does not have to use all of it). Includes a link header having 6, or 14 bytes, and a transport header having 7 bytes.

2 CRC 3 channel Change Pad Modem Enable/Disable Pad Skew.Sicnalint Packet (SSP1 (71 .btesl 3 Channel Change Pad (subject to change depending on modem delays) 1 Preamble 1 same delimiter as normal SP 14 Data 2 CRC (transmitter is turned off here) 46 Idle Tia 3 Channel change Pad 1 'Modem Enable/Disable Pad IWO 90/13956-15- Voice P1acket 195 btg I Preamble I Unique Delimiter 16 2 ms worth of PCH data Pad 11CI'/JSB9/01806~ I Preamble 1 same delimiter as ni 16 Data Pad Bnot Eac)ket (BPI 12.5 bytea I Preamble 1 Unique delimiter 16 16 bytes of boot data Pad )rmal VP Slop Timing Mark Signalling Slot 2e Voice Slots (SP or SSP) (VPt BPI Jr CVP) bytes 71 bytes 546 bytes 1TH Slot IlSP Slot 28 VP Slot$ 627 bytes total (5016 bits) Slop 2 bits) ,3018 bits/trame x I. frame/ma f 5.018 megabits/sac WO 90(/13956 I'CI/US89/0 l06 350 Tabe! gA-3 Map of PRAM (addresses in bytes (hex); lengths in bytes) Address Range Definition 0000 0020 0040 0060

OSCO

OSEO

001F 003F 005F 007F O5DF 05FF PCM Hwy Timeslot PCM Hwy Timeslot PCM Hwy Timeslot PCM Hwy Timeslot PCM Hwy Timeslot VCH Hwy Tiimes.ot 0 Xmt Ring Buffer (32) 0 *Rcv Ring Buffer (32) 1 Xmt Ring Buffer (32) 1 Rcv Ring Buffer (32) 23 Xmt Ring Buffer (32) 23 Rev Ring Buffer (32) 0600 061F 0620 07FF 0800 0807 0808 080F 001~a0 0817 08B 088F 08C -08BF 0900 093F 0940 097F 09800 09VO 09C0 09FF Transmit Silence Buffer (32) Unused, reserved for future use PCM Hwy Times3.ot PCK Hwy VTimeslot PCM Hwy Timeulot 0 Control Block (8) I Control Block (8) 2 Control Block (8) PCM Hwy Tiemelot 23 Control Block (0) Unused, reserved for future use Network Transmit Active Table (64) fltwork Receive Active Table (64) Traiiamit Timing Mark Data Buffer (64) lecieive Timing Mark Data Buffer (64) Network Transmit SP Data Buffer (128) Network Receive SP Data Buffer (128) OAOO OW 0A80- OAFF 0130 01340 01380

OBCO

013b

OBBF

01FF Network tuOy/Frrea Table (64) Network Receive SP ath Table (64) Network Claiming VP Data Buffers (64) Network Transmitted CRO Buffers (64) WO 90/1396 PCr/US89/01806 159 OC00 OCFF Netwotr Transmit Boot Buffer 0 (256) ODO0 ODFF Network Transmit Boot Buffer 1 (256) OEO OEFF Network Receive Boot Buffer 0 (256) OFOO OFFF Network Receive Boot Buffer 1 (256) 1000 103F Network Receive PCM Timealot Map (64) 1040 107F Network Transmit PCM Timeslot Map (64) 1080 10FF Unused, reserved for future use.

1100 11FF Gain Level switch or Tone Buffer (256) 1200 12FF Gain Level Switch or Tone Buffer (256) 1F00 1FFF Gain Level Switch or Tone Buffer (256) End of 8 KB P-RAM Additional memory may be provided for extra gain level 4witch or tone buffers. For example, Receive Long Tone Buffers (which can be over 60K in maximum length) are mde by using consecutive Gai Level Switch/Tone Buffers.

WO 90/13056 ItCrAJ889/01806 (lengths in bytes) 2 Image ID identifies the image type 2 Version specifies the version number of the program 4 Exec. Address specifies the program starting address 2 Exec. Control -used to control the execution after the image is booted, If Exec. control in seto the booted unit will start the program by jumping to the address specified by the BerOC.h7ddresz: field. If Exec. Control in cleared, the booted unit will restart the boot process cycle. This execution control mechanism allows a network unit to receive configuration data image$.

2 No. of Blocks specifies the number of memory blocks contained in this program image.

4 R~eserved The following are repeated for each block.

2 Pangth M 2 Block Number specifies the block sequence number of this block 4 Load Address specifies the load starting address of this block up to 245 M~emory Imago 2 Checksum -contains the Checksum of this block WO 90113956 WO 9/I3556 I/MUS69/O 1806 ALBoot B~equest- Sicgnallincf Packet Format (lengths in bytes) 6/10/14 addresses 7 2 2 Link Header Transport Header Boot select Packet Type Image XD version source and destination identifies the Packet as a Boot SP identifies the packet type as Boot Request SP identifies the type of program image being requested A~ WO1RD, specifies the version number of the program imaG. A value Of OxFFFF indicates an unspecified Version number.

WO 90/13956 PCr/US89/01806 162 Dtblg A-6. BOot Control Sic~allinct Packet- Y-%rmat (lengths in bytes) 6/10/14 Link Header 7 Transport Header 1 Boot Select I Packet Type 2 Channel/Frame 8J Timeslots- 2 X mage ID 2 Version 4 Exec. Address 2 Exec. control 2 Number of locks source and destination addresses identifies the packet as a Boot SP identifies the packet type as Boot control SP specifies the channel and frame, on which the NBtY will download the image blocks specifies the VTS's that will be used for the trz'nsmission. The VTS number 255 or the eighth value marks the end of the VTS list *same as boot image file *same as boot image file same as boot image file same as boot image file same as boot image file WO 90/13956 PMI'US854"01806 163 TABLE C-i HRU SIGNAL DESCRIPTIONS MRXD M Receive Data is the reconstructed serial data which is recovered by the NHC and delivered to the TIU interface at a rate of 5.018 Mbps. The data stream is synchronized with the Phase 1 clock, and data is shifted through on the falling edge. The rising edge is then used as the sampling clock edge.

MTXD MODE TransmitData is the serial data accepted at the TIU interface for broadband transmission. The data rate is again 5.018 Mbps. The data stream must be synchronized with the Phase 1 clock, and data is shifted ta the NHC on the falling edge. The rising edge is then used to sample the data by the NHC.

MTXE- HgOPM Tr nsmit Enable is an active low signal which enables broadband transmission by selecting MTXD as the source of inserted data rather than the PSP generator. MTXE must NOT be active when there is valid upstream transmission and is ORed with the NHC's internal Carrier Detect to insure that this condition is not violated. This "Enable Lock" circuit is necessary since this signal not only applies to the auxiliary interface, and MUST NOT disable the NHC transmit function. only an internal NHC fault signal or external NHC reset will disable or interrupt the downstream transmission.

MACLK ok is a 5.018 MHz clock which is reconstructed by the NHC and then delivered to the TIU interface. This clock can be described as "Phase and has a duty factor of 50/50±5%. The rising edge of this clock is used for MRXD sampling.

MBCLX MQDBH "Ilt Clck is a 5.018 MHz clock which is reconstructed by the NHC and then delivered to the TIU interface. This clock caii be described as "Phase 2" or "Phase 1 90 degrees", and has a duty factor of 50/50 MTLOCK- M T Looked is an Open Collector active low WO 90/13956 PCT/US89/01806 164 signal supplied to the TIU interface to indicate that the NHC is phase and frequency locked with either of the 40.144 MHz clocks NSYNCA and NSYNCB.

MFAULT QEM0 Fault is an active high signal which indicates an NHC failure, the signal will remain active until the NHC is reset by the lOP. While the fault signal is active, the outputs from the NHC are held inactive or tristate and broadband transmission is suspended.

MAO-2 MODE Address are address lines that, when used in conjunction with MRST-, will allow static reset of the NHC card if the MODEM Address matches the occupied slot.

MRST~ MO Reset is an active low signal supplied by the TIU which will hold the addressed NHC in a reset state.

NRFnl-3 Network Receive Frequency are used to select one of eight receive frequencies, (upstream channels) for the NHC to operate on.

Where represents NHC 0-4. The receive frequency is selected via a rotary hex switch located on the TIU Backplane.

NOTE: In the case of a Network MODEM Card, these switches would select the transmit or the upstream frequency.

NTFnl-4 Network Transmit Frequency are used to select one of sixteen transmit frequencies, (downstream channels) for the NHC to operate on. Where represents NHC 0-4. The transmit frequency is selected via a rotary hex switch located on the TIU Backplane.

NOTE: In the case of a Network MODEM Card, these switches would select the receive or the downstream frequency.

NSYNCA Network Ly Cloc is one of two 5.018 MHz clocks received from the TIU backplane as the "Master" clock.

NSYNCAOK- g= Sync Clock 2K indicates that NHC "A" generator is operating correctly.

NTLOCKA- NHCI Locked indicates that NHC is phase loked to the Tl source.

WO 90/13956 PCJ7/US89/01806 165 NSYNCB Network g~ynd C lock is one of two 5.018 MHz clocks :Leceived from the TIU backplane as the "Master" clock.

NCLK-

NTLOCKB-

H=1i j5y, Cloc1 QZ indicates that NHC "IB" clock generator is operating correctly.

H=1i I'D" Til Looke indicates that NHC tiBi is phase locked to the Tl source.

P.V Supplies a diode isolated voltage source for backplane pull up resistors and resistor packs. A maximum current of Soma is made available.

WA el/ lAQCA 11)I"11UOei' wn onr~oc D1fl 166 Appendix I VOICE TRANSPORT PROTOCOLS Version 2.0 Page 3-1 Voice Transport Protocol 3.1 Document History BVD Auto comments 25 April 85 Bob C prototype Version 18 April 86 Bob C 6 June 86 Bob C 25 June 86 Sangam 3.2 Introduction 3.2.1 Scope The reference model of Open Systems Interconnection (OSI), developed by the International Standards Organization (ISO), specifies that the transport layer is responsible for the reliable end-to-end delivery of data between host entities. The transport layer performs this service for session layer entities using the'services provided by the network layer.

This specification describes a transport layer Transaction protocol, p:oviding both best-effort and reliable datagram transfer services. These services are built upon the service exported by the link layer.

3,2.2 Overview 3.2.2.1 Transport Services The Interconnect Voice Transport provides the following services for the user entities.

Dataram A best effort is made to deliver an information (or a response) packet to the destination(s). If for some reason transport fails, then it will not notify the same to the requesting session entity.

i Darram delivery A user information packet is delivered to the destination(s). if transport is unable to deliver the packet for some reason, then it will notify the same to the requesting session entity.

WO 90/13956 PCT/U$89/01806 w 167 VOICE TRANSPORT PROTOCOLS Version 3.0 Page 3-2 Introduction Lare Data Delivery A large data txansfer request fts a user entity is delivered to the destination(a) using a combination of both "pure" and "reliable" d&tcams. If transport is unable to deliver the entire data withaut any error, then it will notify the same to the requesting session entity.

3.2.2.2 Transport Interfaces The Interconnect Voice Transport provides the above listed services by a set of commands and Indications.

A requesting session entity will request a desired transport service by issuing a coimand to the transport. Transport will make indication of an incoming event, result of an earlier request (if desired by the requesting entity) to the corresponding user entity.

3.2.3 Referenoes 1. Interconnect Voice Transport Protocol Revision 6/6/1986.

2. Interconnect Link Protocol Version 2.02, 6/11/1986.

WO 90/13956 168 VOICE TRANSPORT PROTOCOLS Version 3.0 Transport Interfaces PCT/US89/O1806 Page 3-3 3.3 Transport Inter-faces A user entity requesting a transport service will use the command block interface for issuing a command. The user entity will pass a command block with relevant data for the transport use. Once a command is given to the transport, the command block will be owned by the transport. The command block processing is done asvrchronouslv. When the transport receives commands by a user entity by invoking one of the following function calls, return from function call does not imply the completion of the request.

Transport will make indication to the session after completing the request (only when the session desires such notification).

The following are the procedure interfaces provided by the transport.

TXDATASPEREQ

CACELDATASPREQ

POSTBUYFER

Send user data to a remote transport user entity. A opcode parameter in the command block will specify the type of data transfer desired.

cancel a earlier TX DATASPREQ command.

Informs the transport that a buffer specified in the command block is available for the use of transport for receiving data addressed to this user entity.

Transport layer will make the following indications to the local user entities.

RXDATASP

RETDATA SPREQ Transport has received a data packet for the user entity.

Transport was not successful in completing the TX DATA SPREQ as desired by the user.

The transport will return the command block to the requesting user entity with the appropriate changes to the status field.

WO 90/13956 PCIMS89/01806 169 VOICE TRANSPORT PROTOCOLS Version 3.0 Page 3-4 Addressing User Entities 3.4 Addressing Transport User Entities The link layer will receive the packets gor all the addresses registered in it's address hash table and passes it to the transport layer. It is the responsibility cof the transport layer to deliver-them to the respective user entity. Different user entities are identified by a Tjlhr;, in the in the command block supplied by the user entity.

It is possible that a user entity will make number requests bef ore it receives a response f rom the transport.' In order to identify these request the user entity will also supply another identifier to the transport. This identifier will be referred to as TBj_;2 A user entity will also specify this identifier in the command block.

If a user entity is sending a response to a request from another entity then it will specify it by copying the TEU2, in the received request into another field referred as 1hin the command block. Xf the responding user entity is send ng a data transfer request (in addition to acknowledging a data receipt), then it will specify its own transaction identifier in the IM I field.

It must be noted that transport layer itself can be a user entity. in that case it will allocate its own identifiers for the purpose of communicating with other transport entities.

WO 90/13956 P~/US89/01806 170 VOICE TRANSPORT PROTOCOLS Version 3.0 Page Addressing User Entities Transaction Frames When ever a transport user entity requests for a data transfer to other user entity, the transport will prepare a transaction frame using the information supplied by the user through the command block. The format of the command block used for the data transfer purpose is shown in a Appendix. The transport layer will then use the services provided by the link layer to transmit the data on the network. If the user entity is requesting for a "reliable" data transfer, then tha transport will retain the command block till a response(s) is received from the destination(s). The format of the transaction frame is shown in the figure 1.

TSAP ID

I

MDB 0 0 PACKET TYPE TRANSAC ID TRANSAC ACK ID SEQUENCE NUMBER j ATTEMPT NUMBER USERDATA (OPTIONAL) Figure 1 A Transaction Frame The transport layer uses the fields specified above for the following purpose.

TSAP ID This field identifies the user entity. Currently identified transport user entities are 1) Session Layer, 2) Network Management, and 3) Transport Layer. The user entity requesting a data transfer will specify this field.

MDB This field is referred to as More Data Bit. If set, it will indicate the receiving transport layer that some more data packets will arrive for the user entity specified with the same transaction identifier.

WO 90/13956 PCT/US89/01806 VOICE TRANSPORT Addressing User 171 PROTOCOLS Version 3.0 Entities Page 3-6 PACKET TYPE This field specifies the packet delivery mechanism for the transport. Four bits will be used for this field. The transport layer will fill this field using the opcode specified by the user entity. The identified packet types are 1.

The Information Packet ("reliable" datagram).

Both the Transaction Reliable and the Transaction Reliable with "piggyback" Acknowledgement [TI(R ACK)] will have this packet type.

2. The Information Packet ("pure" datagram). Both the transaction pure datagram and tbh transaction pure datagram with "piggyback" acknowledgement [TI(PACK)] will have this packet type. 3. An Acknowledgement specified for the user entity An acknowledgement specified for the session layer [TR(S ACK)) will have this packet type). 4. A negative acknowledgement specified for the user entity. a negative acknowledgement for the session layer [TR(S NACK)] will have this packet type. 5. An acknowledgement for the transport layer tTR(T ACK)). 6. A negative acknowledgement for the transport layer [TR(T NACK)].

TRANSAC ID This field specifies the Transaction Identifier.

A user entity will specify this field. At a given time, more than one transaction from a user entity may be outstanding at the transport. Each of the outstanding transaction will have a unique transaction identifier specified by the user entity. A user entity can have up to 255 transaction identifiers. is not a valid transaction identifier.

TRANSAC ACK ID This field specifies the Transaction Acknowledgement Identifier. A user entity will specify this field. It will be the same as a TRNSAC ID of a transaction which this user entity is acknowledging. Note If the user entity is making a data transfer also ("piggyback"), then it will have its own transaction identifier in the TRANSAC ID field. Otherwise it will make TRANSAC ID as zero.

SEQUENCE NUMBER This field for the exclusive use of transport layer. When transport is making a large data transfer using multiple packets, then it will use this field to identify the packet sequence num- WO090/139S6 PCI'/US89/OI806 WO 90139S6PtT/US89/01806 172 VOZCE TRANSPORT PROTOCOLS Version 3.0 Page 3-7 Addressing User Entities ber. The use of this field is described in the command interface section (Large Data Transfer).

Up to 65535 sequence numbers are possible.

Transport layer will restrict this to a much :.wer number (320?) for implementation reasons.

ATTEMPT NUMBER It will indicate the transport transmit attempt number for the same transaction. Transport will increase this attempt number till it reaches the retransmit count specified by the user entity.

USER-DATA This field is specIfied by the user en-ity. in all single packet information transfers, this field will be filled by the user entity. In large data transfers, transport will fill this field using the buffer specified by the user.

3.5.1 Transaction Information (TI) Frames When ever a user entity initiates a data transfer by making a TX DATA SP REQ, the transport will create transaction frame(s) with appropriate entries and then make a transmit request to the link layer with a pointer to the entire command block. These frames will have a packet type of TI or TI (R ACK) or TI or TI(P ACK) as desired by the user entity. Transpoct may or may not request the link layer for a notification of successful transmittal of a pAcket.

When ever a user entity request for TZ(R) or T1(R ACK) type of packet transfer, transport will have the addltional responsibility of notifying the requesting user entity about the success or failure of the request. A success indication generally indicates that data is received by the user entity without any errors. In addition it may carry a "piggyback" data (e.g.

TI(R ACK) or TI(PjACK)), In addition whenever a user entity requests for a "reliable" transfer, it may also request for number times a packet as to be retransmitted before notifying a user entity and a time interval before each of these retransmit attempts, These parameters will be specified by the user entity in the command block.

When ever a user entity requests for a "reliable" data transfer the transport will maintain the command block in its internal retransmit table. This entry will be cleared either due to an acknowledgement from a remote entity or due to the final time-out after exhausting the retransmit count.

WO 90/13956 PCT/US89/01806 VOICE TRANSPORT PROTOCOLS Version 3.0 Page 3-8 Addressing User Entities If the acknowledgement packet has a "piggyback" data TI(RACK) or TI(P ACK) then transport will release the command block from the retransmit table and pass the information packet to the user entity by making RXDATASP indication.

In the case of time-out condition, transport will check for the retransmit counter. If it is not zero, it will initiate another transmit for the same transaction. If the counter is zero, it will return the command block to the user entity with the appropriate status indication.

3.5.1.1 Single Packet Transfer Majority of the call processing signaling information will be tranamitted in single packet called Signaling Packet Whenever a user entity request for a single SP transfer, it will copy its data in the USER DATA azea in the command block and will specify the desired control. The transport will transmit this as one of the Transaction Information frame ETI(R) or TI(P) or TI(RACK) or TI(1.ACK)J as desired by the user entity.

3.5.1.2 Large Data Transfer When a user indicates a large data transfer request by calling TX DATA SPREQ procedure with a command block pointer. When this request is made the user entity will not copy the data into USER DATA area in the command block. Instead, it will have a pointer in the command block which will point to the user data area, The user entity will also specify the length of the user data. In the first release of Interconnect product, the transport will restrict this length to l2k (approx). If a user entity has to transfer a data larger than 12k it will have to initiate multiple large data transfer requests.

Before making a large data transfer attempt, the receiving transport must have a buffer posted by the user entity consuming the data. The user entity which is consuming the data will have to issue a VOSTBUTFER ommand to its transport. It is possible that a large data transfer transfer initiation can either come from the user entity consuming the data or the user entity cerving the data. in either case it is the responsibility of the communicating user entities to make suitable negotiations using single SPa and ensure that receiving user entity has posted a buffer to its transport before the server entity issues TXDATASPREQ command for a large data transfer, When the transport layer receives the large data transfer request, it will put this command block into a list of large data transfohr requests which are already panding. Then it will prepare command blocks as desired by the user entity (note t only TI(P) packets hre allowed for data transfer) and give them to tha link WO 90/13956 PCTr/US89/01806 VOICE TRANSPORT PROTOCOLS Version 3.0 Page 3-9 Addressing User Entities layer. Transport will copy the data from the user specified buffer area into the USER DATA area of the command blocks in sequence. It also tags a sequence number of the packet into the the SEQUENCE NUMBER field in the transaction frame.

It is apparent that we will not have enough buffers to accommodate transfer of too many packets at a time. To solve this, transport layer will have a local flow control mechanism. The scheme followed by the transport will be simple. When ever transport issues five transmit commands in a row to the link layer, it will ask the link layer to notify the completion of the fifth command. When transport initiates the transfer first time it will issue ten transmit commands in a row. There afterwards, when ever a transport gets a notification of the completion of a transmit from the link, it will initiate five more transmit commands. This will be continued till transport is left with data sufficient to fit in a single SP. Note all those packets will have same transaction number and transport will tag a SEQUENCE.NUMBER and MDB bit is set. It should also be noted that all these packets are sent as TI(P) type packets.

When the transport has to send last packet, it will reset MDB bit and tags the appropriate SEQUENCENUMBER and transmits it as a TI(R) type of packet.

The receiving transport will copy the data into the allocated buffer (through the earlier POST BUFFER command) using the SEQUENCE NUMBER as index to the buffer storage area. It will also remember the sequence number of the packet it received correctly.

If the transport receives a out of sequence packet, it will mark the same in a bit r i When the transport receives a packet with MDB bit reset, it will send the entire bit map data in a TI(R) packet.

When the sending transport receives the b~t m=n packet, it will will copy the same into the user data area in the command block area given by the user entity in the TX DATA SP REQ command. If other receivers send bit m before the set time out, then transport Will make a LOGICAL OR of these bit &aDs. At the end of time-out, the transport will check for the retransmit count in the command block If it is zero, then it will make the appropriate status change and return the command block to the user ertity. If the retransmit count is not zero, then transport will uses the bit map to determine the data packets required to be retransmitted and will transmit them with appropriate SEQUENCE NUMBER as described earlier. Transport layer will use the ATTEMPT NUMBER field to indicate a new transmit attempt Each time it starts a new transmitting sequence it will increment this field (Initial value l, Maximum Value a Retransmit Count). The bki a is restricted to the user data area available in a single packet approx 40 bytes, 40 X 8 320 SPs which will give about WO 90/13956 PCT/US801806 175 VOICE TRANSPORT PROTOCOLS Version 3.0 Page 3-10 Addressing User Entities 12.5 K data transfer capability).

The receiving stations will check for the attempt number. When the transmit sequence with the attempt number reaches a maximum, it will return the received data to the user entity using the RX DATA SP indication. The data pointer will now point to the buffer posted by the user in the POST BUFFER command. The status in the command block will inform the user entity if the data was received correctly. If the data is not received correctly bit mAR in the user data area will indicate the SEQUENCE_ UMBER of packets which were not received.

It is possible that multiple user entities like to receive a large data transfer simultaneously. If the data transfer is initiated by the server periodic update of ARS table), then it is the servers responsibility make reliable negotiations with the consumer(s) before initiating large data transfer. However, it is possible that a server might receive large data transfer requests from several consumers (for the same data) at or about the same time (This will be a common case at power up time of TIMs). Hence it is essential for the units requiring data to listen for any such request(s) currently going on the network. To facilitate this, consumers will be listening for a CRSP (configuration requeat SP) from other consumers addressed to a server address or a CCSP (configuration control SP) addressed to group addresso If they see either of these packets, then it will post a buffer and will get ready to receive the data. If a consumer does not see any of these packets for a period of time after power up it will issue a new CRSP. The server after -eceiving a CRSP will delay its response for a period of time (30 sec.?) and then starts data transfer with TX DATA SP REQ command for a large data transfer. Once a data transfer-is complete, a consumcr station will remove these server and group address from its hash table.

This arbitration is used for reducing the probability of SP collisions which might occur during power up time. The scheme suggested here is for implementation of a user entity (Qg. net management) which may have to manage multiple large data transfer requests at the same time. This is included here for the purpose of illustrating a large data transfer example. By no means this dictates the user entity to follow this scheme. What transport layer assumes is a POST BUFFER command is initiated at the consumer before a TX DATA SP REQ is made at the server.

3.5.2 Transaction Response (TR) Frames The Interconnect Voice Transport allows responses for a "reliable" single packets to be generated by either transport or user entities. If a user entity request the transport to transmit a response frame session may request for TR(SACK) or TR(S NACK) packets types), then the receiving transport will pass this packet to the user entity. If the response packet is gener- WO 90/13956 PCr/US89/01806 176 VOXCJZ TIRXtBP0RT PROTOCOLS Version 3. 0 Page 3-11 Addressing User Entities ated by the transport TR(T ACK) or TR(TyACX) type of packets)$ then it will not be passed Up to the user entity. in either ca~e# no user data will be allowed in the umer data area.

Depending on the type of packet, the receiving tr '.sport will insert 00 for ACK type packets and 10OFH for 'uACK type of packets in the first byte of user data area and then p~sses it to the user entity. The response frames are sent as "1pure" datagrams.

WO 90/13956 177 VOICE TRANSPORT PROTOCOLS "Version 3.0 Command Interfaces PCr/US89/01806 Page 3-12 3.6 TRASPORT COMMAND INTERPAC7S 3.6.1 TX DATASPREQ COMMAND A user entity will prepare a command block and will pass a pointer to this block by calling a transport procedure TX DATA SP REQ. The format of the command block structure is shown in the Appendix. The parameters which a user entity will specify before giving this command are described below, OPCODE The opcode for this command. Specifies the transmit mode and packet type for the transport layer. Different opcodes for this command are described in this section later.

STATUS Before giving the command block to the transport, the user entity will set this field to '00. If tansport has to return the command block to the user entity using RET DATA SP REQ, then it will modify this field to indicate the execution result for the TX DATA SP REQ command. The various status -codes returned are described later in this section.

TSAP ID The user entity will identify itself by setting this field. If an invalid user entity is sat, transport will not accept the command.

TRANSACTION ID TRANSACTION ACKID The user entity will set this field. If the same user entity gives TX DATA SP REQ command with a TRANSACTION IB which is already existing in tEe transport retransmit table, transport will not accept the command.

It a user entity (or transport) is acknowledging a received transaction, then it will fill this field with the received TRANSACTION ID before giving a command to the transport.

The user entity will specify how many times RETRhASKITCOmUT WO 90/13956 178 VOICE TRANSPORT PROTOCOLS Version 3.0 Command Interfaces PCI/US89/01806 Page 3m-13 a packet has to be retransmitted before receiving a response or making a RET DATA SP REQ indication to notify the failure.- DATA-BUFFER PTR DATA BUFFERLTH

PARTITION

User entity indicates the pointer to a data buffer area. This is valid only when the large data transfer is specified in the opcode field.

User entity indicates the length of the data area pointed by the DATA BUFFER AREA.

It is valid only when the opcode specifies a large data transfer.

It indicates the link layer that only the SP PARTITION in this field must be used for transmitting this packet.

NUM4BER OFCHANNELS It indicates the many Rr channels transmitted.

link layer that on how this packet has to be LIST OFCHANNEL (MAX) DESTADDR MODE It is an array of length equal to the maximum number of Rr channels in the Interconnect Network. The user entity will indicate the channels on which this packet has to be transmitted. Each member in the array specifies one logical channel. Link layer will convert the logical channel number into the physical channel number before transmitting the packet.

It specifies the addressing mode for the destination. Link and hardware will use this field to deliver the packet to proper destination. It also specifies whether 16 bit or 48 bit addressing mode being used.

it is used for interpreting the source address field.

it specifies the addressing mode for the source. The receiving node will use this field to interpret the address field.

SOURCE.ADDRMODE

WO 90/13956 179 VOICE TRANSPORT PROTOCOLS Version 3.0 Command Interfaces PCT/US89/01806 Page 3-14 DESTINATION ADDR

SOURCEADDR

SP BUFFER PTR SP BUFFER OFFSET The destination address for which this SP is intended for.

The source address for the sending user entity.

Points to the user data area in the command block.

If the command specified is not for large data transfer, this indicates the offset to the user data area.

In general all the above fields have to be set by the user entity before giving the transport command. The user entity will call the following procedure ushort TX_DATASP REQ(cmd_blk) cadblkptr *cmdblk; where the cmdblk points to the user specified command block. If for some reason transport can not accept the user command it will be returned in the function return status. The execution status is returned to the user either by RX DATA SP or RET DATA SP REQ using indications later. In the subsequent sections various opcodes for this command are described. Only the parameters which are specific to each opcode are mentioned here.

WO 90/13956 180 PCT/US89/01806 VOICE TRANSPORT PROTOCOLS Version 3.0 Page 3-15 Command Interfaces 3.6.1.1 SEND_SP_R This opcode specifies that transport must send the user data in the command block as a "reliable" datagram. If this opcode is specified then the following fields are tested before returning the function status.

TSAPID This field must have a valid user entity.

TRANSACTIONID This field must have a identifier which is not already present in the transport retransmit table.

TRANSACTION ACK ID This field must be set to RETRANSMIT COUNT This field specifies how many times this packet has to be transmitted before notifying the user entity. This field must have a non-zero value for this opcode.

TX DATA SP REQ function call will return one of the following values.

COMMAND ACCEPTED Transport layer has accepted the command for processing.

ILLEGAL TSAP ID The user entity is not known to the transport.

DUPLICATETID The transaction identifier specified is already active in the transport.

NO RETRANSMIT Retransmit count is not specified.

TACKID NOTZERO The transaction ack identifier is not zero.

If the transport layer accepts the command for processing, it will notify the rasult of the command through RX DATASP or RET DATA SP REQ indibations.

WO 90/13956 181 VOICE TRANSPORT PROTOCOLS Version 3.0 Command Interfaces PCT/US89/01806 Page 3-16 3.6.1.2 SEND SP P This opcode specifies that transport must send the command block as a "pure" datagram.

specified then the following fields are tested the function status.

the user If this before data in opcode is returning

TSAPID

TRANSACTION ID TRANSACTION ACK ID This field must have a valid user entity.

This field must have a identifier which is not already present in the transport retransmit table.

This field must be set to TXDATA SP REQ function call will return one of the following values.

COMMAND ACCEPTED ILLEGALTSA3_ID DUPLICATE TID TACKID NOT ZERO Transport layer has accepted the for processing.

command The user entity is not known to the transport.

The transaction identifier specified is already aftive in the transport.

The transaction ack identifier is not zero.

After completing the command processing, transport layer will not make any indications to the user entity.

WO 90/13956 PCT/US89/01806 VOICE TRANSPORT PROTOCOLS Version 3.0 Command Interfaces Page 3-17 3.6.1.3 BEND_BPRACK This opcode specifies that transport must send the command block as a "reliable" datagram. If specified then the following fields are tested the function status.

the user data in this opcode is before returning TSAPID This field must have a valid user entity.

TRANSACTION ID This field must have a identifier not already present in the retransmit table.

which is transport

TRANSACTION.ACKID

RETRANSMITCOUNT

The user entity will copy the TRANSACTION ID from a received message to which it isi-sending this response.

This field specifies how many times this packet has to be transmitted before notifying the user entity. This field must have a non-zero value for this opcode.

TX DATA SPJ REQ function call will return one of the following values.

COMMAND ACCEPTED

ILLEGALTSAPID

DUPLICATE TID

NORETRANSMIT

Transport layer has accepted the command for processing.

The user entity is not known to the transport.

The transaction identifier specified is already active in the transport Retransmit count is not specified.

If the transport layer accepts the command for processing, it will notify the result of the command through RX DATA SP or RET DATA SPREQ indications.

WO 90/13956 PCI'/US89/01806 183 VOICE TRANSPORT PROTOCOLS Version 3.0 .Page 3-18 Command Interfaces 3.6.1.4 SENDBPP PACK This opcode specifies that transport must send the user data in the command block as a "pure" datagram. If this opcode is specified then the following fields are tested before returning the function status.

TSAP ID This field must have a valid user entity.

TRANSACTION ID This field must have a identifier which is not already present in the transport retransmit table.

TRANSACTION ACKJID The user entity will copy the TRANSACTION ID from a received message to which it is-sending this response.

TX DATA SP REQ function call will return one of the following values.- COMMAND ACCEPTED Transport layer has accepted the command for processing.

ILLEGAL TSAPJ D The user entity is not known to the transport.

DUPLICATE TID The transaction identifier specified is already active in the transport.

After completing the processing of the command, the transport layer will not make any indications to the user entity.

WO 90/1395(; 184 VOICE TRUWSPORT PROTOCOLS Version 3.0 command ILnterf aces PCT/1JS89/01 806 Page 3-19 3.6.1.5 BEIIDACKRBP This opcode will specify the transport that user is acknowledging a earlier transaction in a affirmative mannero The user entity will not till any data into the user data area. Transport layer only field user is going to specify for this command is the TP.ANSACPION-ACX ID.

TX DATA SP EEQ function call will return one of the following values.- COMMM~tD ACCEPTED ILLEGA14TSAP-ID Transport layer has for processing.

accepted the command The user entity is not known to the transport.

After completing the proqasaing of the command, the transport layer will not make any indications to the user entity.

WO 90/13956 WO 9013956Pcr/US89/01806 VOICE TRANSqPORT PROTOCOLS Version 3.D Command Interfaces Page 3-20 3.6.1.6 SENPNACK RBP This opoode will specify the transport that user is ackn&owledging a earlier transaction in a non-confirmnative manner. The user entity will not till any data into the itiser data area. Transport layer Only field user is going to specify for this command is the TRANSACTION ACK ID.

TX DATA SPEQ function call will return one of the following vafues.- COMAND ACCEPTED

ILEGAL-TSAP-ID

Transport layer has for processing.

accepted the command The user entity is not knxown to the transport.

After completing the processing of the command, the transport layer will not make any indications to the user entity.

WO 90/13956 PCT/US89/01806 VOICE TRANSPORT PROTOCOLS Versi*A 3.0 Command Interfaces Page 3-21 3.6.1.7 SEND LARGE DATA This opcode specifies that transport must send the data pointed by the DATA BUFFER PTR in the command block using more than one SPs. If this opcode Is specified then the following fields are tested before returning the function status.

TSAP ID TRANSACTION ID TRANSACTION ACKJID RETRANSMIT COUNT DATA BUFFER PTR DATA BUFFER LTH This field must have a valid user entity.

This field must have a identifier which is not already present in the transport retransmit table.

This field must be set to This field specifies how many times this packet has to be transmitted before notifying the user entity. This field must have a non-zero value for this opcode.

This filed will point to a data buffer area outside the command block.

This field specifies the length of the data buffer area.

TX DATA SP REQ function call will return one of the following values.

COMMAND ACCEPTED ILLEGAL TSAP D DUPLICATE TID

NORETRANSMIT

TACKIDpNOT ZERO Transport layer has for processing.

accepted the command not known to the The user transport, entity is The transaction identifier specified is already active in the transport.

Retransmit count is not specified.

The transaction ack identifier is not zero.

WO 90/13956 187 VOICE TRA.NSPORT PROTOCOLS version 3.0 Command Interfaces PC'/US$9/01806 Page 3-22 If the transport layer accepts the command for processing, it will notify the result of the command through RET-DATA-SP REQ indication.

WO 90/13956 188 VOICE TRANSPORT PROTOCOLS Version 3.0 Command Interfaces PCr/US89/01806 Page 3-23 3.6.2 CANCELDATAhSP REQ This command specifies transport layer to TX DATA SP REQ command. The user entity will by-calling the following procedure cancel an earlier specify this command u short CANCEL DATASPREQ (transaction id); where transaction id is the identifier for the TX DATA SP REQ command given by the user entity.

This function call will return one of the following values.

CANCEL DONE MARKED FOR CANCEL INVALID TRANSACTIOr Transaction is cancelled successfully.

Transport has marked the transaction canceling.

for The specified transaction does not exist in the transport layer.

If the transport reports the MARKED FOR CANCEL status, it Will not report to the user entity after- completing the command.

However the responses received for this transaction after registering this command will be discarded by the transport layer.

WO 90/13956 PCT/US89/01806 VOICE TRSGPORT PROTOCOLS Version 3.0 Page 3-24 Command Interfaces 3.6.3 TOST_BUTrER This command specifies the transport layer that a bufter is available for receiving a large data transfer. A user entity will call the following function with a pointer to the buffer area and 'the length of the buffer.

u_short POSTBUFFER(bufptr, buf lth, userid); DATA BUFFERPTR *buftptr; where bufptr points to a user brtter area, buflth indicates the length of the buffer and user id is the TSAP ID of the user entity.

The POSTBUFFER function call will return one of the following values.

POST BUFFEROK Transport accepts the buffer for receiving the data addressed to the user entity.

INVALID USER ID The TSAP ID supplied does not belong to a valid transport user entity.

WO 90/13956 190 VOICE TRANSPORT PROTOCOLS Version 3.0 Transport Indications PCT/US89/01806 Page 3-25 3.7 TRANSPORT INDICATIONS As discussed earlier transport will make the following indications to the higher layer.

3.7.1 RX.DAXTA.P When a data packet arrives for a valid user entity, transport layer will indicate the higher layer by calling this function with a pointer to the command block (which it received from the lower layer) This procedur could be part of transport layer so that it can make additional range checks on extensions and send the command block pointer to the appropriate user entity. In addition RX DATASP, function will duplicate the command block received and send it multiple user entities with same identifier (This required for supporting multi ported DOGHOUSE. It is possible that different Spikes connectod to a multi ported Doghouse might belong to a multi appearance extension or hunt group. Hence it may be required to send certain request packets to several session entities controlling individual spikes).

RX DATASP procedure will be part of transport task.

interface with th, user entity using a mailbox supplied user entity.

It will by the 3s7.2 RETJDATAJ3P2ZEQ If transport can not complete a TX DATA SP REQ command processing, it will make the appropriate status change in the command block and will return the command blook to the user entity using the mailbox provided by it in the command block.

The status field in the command block will have one the following values.

RESPONSET EOUT TRANSMXTJA-rAILURME

NOBUFFERJPOSTED

Expected responses did not arrive before the elapse of specified timeout.

Transport was not able to transmit before the elapse of the specified time out.

Receiving transport has no receive buffer to complete the large data transfer request.

LhRGEDATA_;CVO0K Transport did receive a large Buccessfully and data is now the data buffer posted by the data transfer available in user entity.

WO 90113956 PCJ'/US89/01 806 YOXCE T1~hNSPORT PROTOCOLS Version 3.0 Transport Indications Page 3-26 LARGE, DATA RCV NOT OK LARGE DATA TX OK LARGE DATA TX NOT OK Transport receivea an incomplete large data transfer, The user data area in the command block now contains the k~ ran of the packets which were not received.

T~ransport did complete a earlier large data transfer command (through TX DATA SPJREQ command) successfully.

Transport did not complete the large data transfer command successfully, The user data area in the command block now contains the ma= of the packets which were not successfully transmitte.

WO 90/113956 PCI'/US89/01806 192 VOICE TRAN~2SPORT PROTOCOLS Version 3.0 Page 3-27 Transport Indications 3.8 services imported From Link Layer Transport u~tilizes the following services provided by the link layer.

SEND-SP This service allows transport to transmit a signaling Packet on the specified channels once.

CANCEL-SP This service allows transport to cancel a earlier SEND-SP request.

The interfaces to these functions are described in the Interconnect Link Layer Protocol specifications.

WO 90/13956 PCT/US89/01806 VOICE TRANSPORT PROTOCOLS Version 3.0 Transport Indications Page 3-28 3.9 Voice Related Interfaces Link layer provides interfaces required for management of the voice circuits and tone buffers. These interfaces are transparent to the transport layer. A user entity will directly access these services from the link layer. These interfaces are described in the Interconnect Link Layer Protocol specifications.

WO 90/13956 WO 9013956PCr/US89/01806 VOICE TRANSPORT PROTOCOLS Transport indications revnuxn Command block Por TX DZATA SP REQ Command typedef struct. cmd bik struct cmd b17k *prlink: struct cmdblk *pB).ink; struct timer str *timer-str; byte Tr op code; byte Tr Status; byte tsap.id; byte rasp mbox; byte trnausaction id; byte transaction-ack id: byte retransmitcBount; byte attemptcounter; wolrd sequence Icounter; wolrd data buffer~ptr: Word ta buffer Ith; bitte li'j*kyap tyje; byte, 1±2 k rspjnbox; byte, lln)status; byte* pa.ttiont byte numoftchannels; b,'te txhnMAX CHAN~j byte tx"chan[MX)CHAHi3 byte dest addr mode; byte src aiddrmiode; stnid deet addr: stnid source addr; byte rcv chan: byte rcvj-rame num; PACHET *psp buffer: byte *Psp of fst; word lengthl byte SP buffert]: cMDBLX; Pointer for buffer manager Pointer for buffer manager Pointer to a timer structure Transport command Opcode Transport status Transport user identifier 1* Transport Response Mail Box Transaction identifier Transaction ack identifier Retransmit counter for transport*/ Attempt counter for transport Sequance Counter for transport Pointer to data buffer area Length of data buffer area link response type link will return here link will return status here*/ SP partition for transmit No of channels to transmit on channel identifier array Transmit status on each channel Destination Addressing mode Sorce addressing mode 1* Destination Address Source Address channel on which SP was received Frame on which SP was received /SP buffer pointer /*offset of the data buffer length of data from offset SP buffer area WO 90/13956 PCI'/US89/01806 195 V0XqE TRANSPORT PROTOCOLS TABDLE OF CONTENTS Voice Transport Protocol (Version 3.0) 3-1 3.*1 Document History .3-1 3.2 Introduction* 3-1 3o*24.1 Scope 3-1 3.2.2 Overview 3-1 3.2.2.1 Transport Services 3-1 3.2.2.2 Transport Interfaces oaoooot e o 3-2 3.2.3 References e 000000 0 3-2 3o*3 Transport Interfaces 3-3 3.4 Addressing Transport User Entities 3-4 Transaction Frames 3.5.1 Transaction Information (TI) Frames 3-7 3.5.1,1lSingle Packet Tranfer 3-8 3.5.1.2 Large Data Transfer 3-8 3.5.2 Transaction Response (TR) Frames 3-10 3.6 TRANSPORT COMMAND INTERFACES oes, 3-12 3.*69 1 TX DATA SP REQ COMMlAND 3-12 3 .6.1.1 SEND*SP R 3-15 3.6.1.3 SENDSP7RACK 9999999999.9o9.. 3-17 3 969194 SEND SP PACX 3-18 396,195 SEND ACKR SP 9999*99993-19 3.6.1.6 SEND NAK RSP 3.6.1.7 SEND LARG'E DATA 3-21 3.9692 CANCEL DATA SPREQ 99993-23 3.969.3 POST BUFFER .0*60G*66 3-24 3.7 TRANSPORTINDICATIONS a9 's 99 0 999999999996-600 660 a0 61 3-25 3.9792 R~ET DATASP REQ 3-25 3.8 Serviceslimpoited From Link La~yer 3"27 3.9 Voice Related Interfaces 3-28 APPENDIX At Command block Por TX DATA SP-REQ Command *9999*9 A 1 WO 90/13956 PCT/US89/01806 196 Appendix 2 DOGHOUSE/SPIKE DRIVER Page 0-1 Doghouse/spike Driver Transport Layer 1.1 Introduction This document describes the transport layer of the Spike Driver.

All of the processing described herein is executed on the Doghouse side of the Spikelink.

I.I.I overview At leash every 50 ms, the transport layer will poll Spike to see if he has any data for the Doghouse. In order to reduce the amount to real-time necessary to service the Doghouse-to-Spike link, the Doghouse will only request an acknowledgement from Spike once a second, or prior to the sending of data to the Spike.

All data messages received from Spike will be unpacked from the packet and individually buffered until requested by one of the session tasks. When a session task does request Spike information, transport will place the message in the mailbox associated with the requesting task.

The session layer will pass messages for Spike to the transport via a subroutine call. The transport layer will pack as many messages as possible into a packet. At the -nd of each polling cycle, transport will check to see if there is a packet to be sent to Spikel if so, transport will pass the packet to the link layer for delivery.

When describing data transfer directions, uplink refers to Spiketo-Doghouse messages while downlink is used for the Doghouse-to- Spike transfers.

1.1.2 References 1. Spike Leash Wokinq Document Extern'.l Design Specification Version 1.oo00, 16 August 1986 2. "Doghouse/Spike Driver Interface"' 23 September 1986 WO 90113956 PCr/US89/01806 197 DOGHOUSE/SPIKE DRIVER Page 1-2 1.2 Link to Trasport Protocol The transfer of information between Spike and the Doghouse is based on the exchange of serial packets using a zaster-slave relationship. The Doghouse is always the master and Spike is always the slave.

The master initiates information exchange every 50 ms by polling the slave. As previously mentioned, the Doghouse may poll Spike with one of two different messages. one poll requires Spike to return an acknowledgement, a data packet, or a busy message. This type of POLL will be referred to as an ACKed POLL. The second type of pollo an ACKless POLL, does not require any response from Spike but a data packet will be accepted if sent.

After an ACKed POLL, the master will expect three possible actions from the slave, 1. Spike will return an acknowledgement (ACK) indicating that he does not have any data to pass to the Doghouse.

2. Spike will return a data packet to the Doghouse. The master will acknowledge the data packet and Spike will acknowledge the acknowledgement.

3. The slave will indicate that he is busy and can not accept data from the Doghouse. In this case, the master should wait until the next polling cycle before attempting any further contact with Spike.

Aftear each of the first two events listed above, the zaster may send a data packet to Spike which will be followed by an acknowledgement from the slave. If the Doghouse does not have any data to send Spike, he simply waits for the next polling cycle. It is important' to note that the master must always send an ACKed POLL to thvo slave before sending a data packet to Spike.

After an ACKless POLL, the master will expect two possible actions from the slave.

1. Spike will return a data packet to the Doghouse. The master will acknowledge the data packet and spike will acknowledge the acknowledgement.

2. The master will timeout wait.,ng for a packet from Spike.

Since the Doghouse is not really expecting anything from Spike anyway# this condition will not be considered an error* WO090113956 3PCI/US89/01806 DOGHOUSE/SPIKE DRIVER Page 1-3 1.2.1 Psoket Pacaing Meohanim Packets are passed to Spike by making a request for input/output (RIO) through a custom device driver. Since Spike may have a packet to return to the Doghouse on an RIO call, a receive data buffer will be included in each call to the device driver. The addition of the receive buffer eliminates the need for two RIO calls (one to send a packet and one to receive a packet) for each communication transaction. In addition, a packet to send to Spike, a send packet length and a receive packet timeout will also be include in the RIO call.

When an RIO command completes, event flag and place a value in a will signal the completion of the will be used to show the status Possible values for the command completed successfuly, timeout in request parameters, or anothez vious request completed.

the device driver will set an state variable. The event flag command, while a state variable of the command upon completion.

status flag include, command error, checksum error, an error send request before the pre- WO 90/13956 PCIr/US89/01806 DOGHOUSE/SPIKE DRIVER Page 1-4 1.2.2 Typical Data Transfer Sequences Master slave POLL

DATA

ACK

ACK

DATA

ACK

(Master polls Slave for data) (Master sends data to Slave) Master Slave POLL

ACK

DATA

ACK

(Master polls (Slave has no (Master sends Slave for data) data to send) data to Slave) Master Slave POLNA

DATA

ACK

ACK

POLLA POLLNA Master Slave POLL

BUSY

POLL

DATA

ACK

ACK

DATA

ACK

(Master polls Slave for data) (Master has no data to send) (Master polls Slave at next interval) (Master polls Slave at next interval) (Master polls Slave for data) (Slave indicates that it's busy) (Master waits for next poll interval) (Master polls Slave for data) (Slave is no longer busy) (Master sends data to Slave) WO 90/13956 WO 9013956PCr/US89f 01806 DOGHOUSE/SPIKE

DRIVER

Page 1.2.3 Packet Yormat The packet type (POLL, ACK, etc.) is included in header. The general format of a packet is shown below: 7 6 5 4 3 2 1 0 I PID I Control I Message Length I k- -J -J I the packet Message Body

IA

Maxioum 48 bytes I

I

I checksum LSB I 1 Checksum MSB I Where: PID (4 bits) is the Protocol XD field. This field is used to identify the protocol used for the exchange of data. The validation of this field is a requirement for data exchange. In the future, when multiple protocols are specified, some protocol negotiation will be required based on the PID. For first release, thic field will be Olh.

Control (4 bits) is the control field. This field identifies the packet type. Control field values are: 00 01 02 03 04 06-Orh DATA(0) DATA(1) POLUIA (ACKless POLL) POLL (ACKed POLL)

ACK

BUSt Undefined and not used POLLNA, POLL, ACKv and BUSY "ackets are control packets and therefore have no message body and a message length of zero, The use of the two different forms of the DATA message is explained in the section on Data Packet Integrity.

WOn Q0/I1396 prrr~usss/oisoci DOGHOUSE/SPIKE DRIVER Page 1-6 Message Length (1 byte) is the length (in bytes) of the body of the message. This does not include protocol header or trailer fields such as PID, control, length, or Checksum. For first release, the maximum value of this field is 44.

Message Body (0 to 44 bytes) is the data portion of the packet and is only valid for DATA packets. The region is a variable length field which contains information used by higher level communications layers. Refer to the section on Message Unpacking Buffering for a more complete description of this field.

Checksum (2 bytes) is the mathematical summation of all bytes in the packet not including the checksum itself. The checksum is calculated and checked in the link layer (device driver).

1.2.4 Reliability Reliable transport is ensured through retransmission of suspected corrupt packets. Packets are considered corrupt if the device driver detects an error. Examples of driver detected errors include: a timeout before the return packet is received, or an inconsistency between the calculated checksum of a received packet and the checksum field of the packet.

Although timeouts could occur due to errors in either the Doghouse or Spike, the master has no way of distinguishing one from the other, In most timeout situations, the previous packet will be retransmitted to Spike two more times in the hope that the slave will respond. If a correct response is not obtained after three attempts, the Doghouse will reset the Spikelink driver, log a link error and return to its polling state. The exception to this immediate retry scheme applies to data packets.

If a data packet cannot be delivered, the Doghouse will immediately return to its polling cycle (ACKed POLLS) and wait for the next available opportunity to send the data packet to Spike.

If the Doghouse cannot deliver a data pac)oet after three attempts, the message will be dropped, the Spikelink driver will be reset, and a link error will be logged.

Invalid or unexpected response packets from Spike will cause the Doghouse to immediately return to the polling state in order to avoid any potentially confusing information exchanges. For example, the Doghouse POLLS Spike and correctly receives a DATA packet, which the Doghouse acknowledges. If Spike were then to erroneously send another DATA packet to the Doghouse, the master would immediately return to the polling state in the hope that Spike's condition would stabilize. The Doghouse will return to WO 90113956 PCT/US89/01806 202 DOGHOUSE/SPIKE DRIVER Page 1-7 the polling state instead of retransmitting the last packet to avoid having Spike think that an unexpected packet was accepted.

In the above example, a retransmission of an ACK following the invalid DATA packet might lead Spike to think that the unexpected DATA packet was accepted.

Any errors in the packet header fields, PID or control, will result in the loss of the packet. As with unexpected packet types, invalid header fields will cause the transport task to return to its polling state without any retransmission of the previous Doghouse packet.

1#2*4*1 Data Packet ZUtegrity Data packet integrity is accomplished by using two different data packet typest DATA(O) and DATA(1). Successive DATA packets sent to Spike alternate between the use of DATA(O) and DATA(l) control fields. This alternation effectively provides a modulo two sequence number attached to downlink data that allows detection of retransmitted DATA packets across polling sequences.

Spike should always transmit DATA(1) packets to the Doghouse, but both types will be acceptable.

WO 90/13956 PCr/US89/01806 DOGHOUSE/SPIKE DRIVER Page 1-8 1.2.4.2 Recovery Schemes for Lout Packets Master Slave Master POLL X

T/O

POLL A4K Master POLL ACM X

T/O

ACK DATA 1

DATA

ACK

ACK

Slave

DATA

x

T/O

ACM DATA Master AC x

T/O

ACK DATA Slave

DATA

DATA

ACK

ACK

Slave

DATA

ACK

ACK

ACK

ACK

ACM

Master Slave POLL

DATA

ACK

ACM

DATA(1) X

T/O

POLL

ACK

DATA(1)

AC

Muster POLL ACM DATA(O)

T/O

POLL DATAf0) Slave

DATA

ACX

ACX

ACK

ACX

WO 90/13956 PCIYUS89/O806 204 DOGHOUSE/SPIKE DRIVER Page 1-9 1.2.4.3 BUSY Conditions If three POLL-BUSY packet sequences are received in succession, an error counter will be incremented and an event flag will be set to notify the session tasks of a possible Spike malfunction.

1.2.4.4 Polling Timeouts If Spike is not responding to ACKed POLL packets from the Doghouse, three potential situations could exist.

1. There is not a Spike attached to the Doghouse.

2. For some reason Spike has gone insane and can not respond to a POLL.

3< There is a Spike attached to the Doghouse but the RS-485 is hooked up backwards and all the data is being inverted.

In order to handle the timeout cases liatad above, a variable will be maintained to indicated whether or not the Doghouse thinks a Spike is there. If we do bot think there is a Spike on the line, the Doghouse will continue to send ACKed POLLs in an attempt to establish contact with the electric canine. Each successive POLL will be preceded by a command to the link layer uo invert the data stream in an attempt to contact a newly attached device.

If the Doghouse does think there is a Spike attached and there is a timeout to an ACKad POLL, the Doghouse will continue to send POLLs requiring an acknowledgement. If the Doghouse receives three successive timeouts to POLLst we will assume that the Spike was disconnected. In so doing, we will change the state of the IS SPIKE THERE flag to NO, set an event flag, reset the Spikelink device ariver and begin inverting the data stream before each

POLL,

1*2.4.5 Packet Timeouts The Doghouse will only maintain packet timeouts for data exchanges (no character timeouts). The value of the packet tizmouts will b calculated by allowing 1.5 times the expected transport time for each byte, in addition to a turn around constant* Since the data exchange rate is roughly 521 us per byte, WO090/13956 PCI'/US89/OI806 205 DOGHOUSE/SPIKE DRIVER Page 1-10 transport will allow approximately 780 us per byte. In the case of unknown length receive packets DATA packets), 15 ms will be allocated. In addition to the time required for each byte, 6 ms will be included to allow Spike to turn the line around before sending data to the Doghouse.

The timeoait counter will start when interrupts have been enabled to start transmission from the Doghouse to Spike.

Examples of timeout values arelisted below.

Action Timeout Timeout Breakdown POLLNA 24 ms 3 ms to send POLLNA 6 ms to turn link around ms for Spike to send DATA packet POLL 24 ms 3 ms to send POLL 6 ms to turn link around ma for Spike to send DATA packet ACK 12 ms 3 ms to send ACK 6 ms to turn link around 3 ms for Spike to send ACK packet DATA variable 6 zs to turn link around 3 ms for Spike to send ACK packet (umber of bytes) 2 3 1 2 1.2.5 Message Paoking B Duffering Many of the messages session wishes to pass to Spike will not fill the message data area of a packet. In order to make full use of Spike's ability to separate multiple messages in each packet, transport will attempt to pack as many messagas as possible into each packet before transmission. This packing scheme will rely upon the fact that the message data area is capable of holding 43 bytes.

During the wait time for the next polling cycle, the session layer may attempt to send more messages than will fit in one packet or multiple messages that may not packed in the same buffer multiple display commands, multiple EEPROM read commands, and multiple EEPROM write commands). For this reason several packet buffers will be maintained in an attempt to avoid the loss of any massages. The current plan is to include five outgoing packet buffers. The buffir maintenance routines will keep track of the maximum number of buffers used at any one time WO 90/13956 PCT/US89/01806 206 DOGHOUSE/SPIKE DRIVER Page 1-11 and a flag to indicate any overflow conditions. If the allocation flags indicate that we run out of buffers or neared an overflow condition, more buffers will be added.

1,2.6 Error Counters 1.2.6.1 Errors in Spike Messages 1. Spike sent a packet with a control field we could not recognize 2. Transport thought it would have to read past the end of the data buffer in order to unpack multiple messages from Spike 3. Spike sent a data packet that either had a length of zero or a length larger than the size of the data buffer 4. Spike sent a packet with an invalid APID Spike sent a packet with an invalid PID 6. Spike sent a data message with a message count value of zero 1.2,6.2 Spike Response Errors 1. Transport tried unsuccessfully to sed a data packet three times and had to give up 2. Spike did not return an ACK packet following a data packet from the Doghouse 3. A packet timeout occurred when trying to send a DATA packet to Spike 4. Transport tried unsuccessfully to send an ACK to Spike three times in a row Transport expected Spike to send an ACK packet but Spike sent some other packet type 6. Transport received BUSY parxets to three successive ACKed POYZXs.

wnan/ I1 "G Pri7US89/01806 TT WA O~h12O~PCT/11S89/01806 207 DOGHOUSE/SPIKE DRIVER Page 1-12 7. Transport timed out three times in a row when sending ACKed

POLLS

1.2.6.3 Errors Detected by Spikelink Driver 1. The Spikelink device driver returned an invalid status type after an attempt to send a DATA packet to Spike 2. The Spikelink device driver status indicated that another request was pending when we issued a send DATA request.

3. The Spikelink device driver status indicated that another request was active when we issued a send DATA request.

4, The Spikelink device driver found an error in the RIO request parameters of a send DATA request The Spikelink device driver found an erroneous reserve request in response to a send DATA request 6. The previous send DATA request to the Spikelink device driver was cancelled by a reset commend 7. The Spikelink device driver detected a checksum error in a receive packet following a send DATA request 1.2.6.4 DATA Packet Errors from Spikelink Driver 1. The Spikelink device driver returned an invalid status type 2. The Spikelink device driver status indicated that another request was pending when we issued the POLL request.

3. The Spikelink device driver status indicated that another request was active when we issued the POLL request.

4. The Spikelink device driver found an error i1n the RIO request parameters The Spikelink device driver found an erroneous reserve request 6. The previous send request to the Spikelink device driver was cancelled by a reset command WO 90/ 13956 PrU8/10 PCr/US89/01806 DOGHOUSE/SPIKE DRIVER Page 1-13 7. The Spikelink device driver detected a checksum~ error in a receive packet 12-6.5 Resource Errors I. Transport could not butter any more data messages from Spike because all of the receive buffers contained data.

2. Transport tried to in order to buffer a able in the pool.

3. Transport could not the 50 ms scheduling POLL again.

get memory from the shared memory pool message but no more memory was availfinish all necessary processing before timer indicated that it was time to 1.2.7 Error rlaVs 1. Transport received BUSY packets to three Successive ACKed

POLLS.

2. Spike sent a packet with an invalid APID 3. Transport could not buffer any more data messages from Spike because all of the receive buffers contained data.

4. Transport could not finish all necessary processing before the 50 =s scheduling timer indicated that it was time to POLL again.

S. Transport tried to get memory from the shared memory pool in order to buffer a message but no more memory was available in the pool.

6. Transport tried unsuccessfully to send a data packet three times and had to give up 7. Transport timed out three times in a row when sendinig ACKed

POLLS

8. Transport detected an invalid message type 'when trying to unpack a DATA packet from Spike 9. A general flag that will be set if Transport detectst a bad P112, a bad control packet field, an unexpected packet type, WO 90/13956 DOGHOUSE/SPIKE DRIVER PCIr/US89/01806 Page 1-14 or an invalid message length.

WO 90/13956 PCr/US89/01806 210 DOGHOUSE/SPIKE DRIVER Page 1-15 1.3 Transport to Bession Protocol 1.3.1 Delivering Messages to Spike Session will make a subroutine call to provide transport with the message to send, the length of the message and the port to send the message to 0 for the Doghouse, 0 through 7 foV the Kennel).

1.3.2 Receiving Messages from Spike Each time the Doghouse receives message data from Spike, an event flag will be set indicating that there is data pending for session tasks. When a session task is ready to process Spike message data, it will set another event flag. At the point when both of these two flags are set, a message delivery task will come to life and take care of placing the next message from the transport receive buffer in the mailbox of the waiting session task.

A bit more intelligence will be placed in the task that puts messages in mailboxes than may otherwise be expected. Since roughly 90% of the messages that Spike will send are button events, the "postman" task will check to see if the message is a button event. If zo, the button and event will be placed in the mailbox of the session task. For all other messages, the "postman" will allocate a buffer from the shared memory pool, copy the message information to the buffer and then place a pointer to the data in the session task's mailbox. It ill be the responsibility of the session tack to free the allocated buffer memory when it is finished with the Spike data.

1*.33 Message Unpacking A Suffering Since Spike may send more than one message in each data packet, transport will have to unpack the messages and individually .buffer them until a sesion task is ready to reAeive information.

In order to unpack the messages, transport must recognize message types and tho number of bytes associated with each type. The table below contains the current uplink messages and the number of bytes associated with each. If the unpacking routine does not recognize a message type or detects an invalid APID, an error flag will be set and the rest of the message will be lost. if either of i.hesa events occur, session should respond as though it received a Key Event overflow message and poll the hookswitch of the Spike in question7 WO 90/13956 PCr/US89/01806 DOGHOUSE/SPIKE DRIVER Page 1-16 Message =ve fHEX 81 82 B 83 84 86 87 I II I O2eration Reset Event EEPROM Data EEPROM-Write-Complete KeyEvent KeyEventOverflow Key Event Status Rejict Number of Bytes 3 18 2 2 0 2 2 The receive portion of the transport layer will also buffer messages in an attempt to avoid e.ny message loss. Initially, fifteen message buffers will be allocated to store individual Spike messages. The receive portion of the transport task will use fifteen buffers since Spike could potentially put three messages in each packet (three times the five buffers guesstimated for the send portion equals fifteen). The buffer maintenance routines will keep track of the maximum number of buffers used at any one time and a flag to indicate any overflow conditions. If the allocation flags indicate that we run out of buffers or neared an overflow condition, more buffers will be added.

WO 90/13956 212 PCr/US89/01806 DOGHOUSE/SPIKE DRIVER Page 1-17 1.3.3o1 Message Data Area Forctat The format of the message area follows: 7 6 5 4 3 2 1 0 Message Header I APID I Message Count I I I Message Type I Mug #i I Message Data I (if any) I Max.

I 1 44 bytes :Message Type I I I I! I I Msg I #2 I Message Data (if >l msg) I (if any)

I

aw Where: APXD (4 bits) is the protocol ID for the application layer. For first release this value will be 0lh.

Message Count (4 bits) is the number of messages contained in this packet. This value should never be zero.

Message Type (I byte) contains the value of the message type.

Message.Data (0 to 42 bytes) contains parameters and data specific to the particular message.

1.3.4 ZError Counters I. Session send a packet with either a length of zero or a length larger than the size of the data area WO 90/13956 PCT/USB9/01806 D(OGHOUSE/SPIIM DRIVER 23Page 1-18 2. Session requested that the data be send to an invalid port number 3. Session tried to send a message with an invalid message type 4. Session tried to send a message but all the transmit buffers were full 1.3.5 Zrror Flaga 1. A general transmit error flag that is set when any of the first three cases in the 'Error counter' conditions occur.

2. An flag to indicate that all the transmit buffers filled and anotker was needed WO 90/13956 PCT/US89/01806 214 DOGHOUSE/SPIKE DRIVER Page 1-19 1*4 Transport to session Interface 1.4.1 Now to Pass Messages to Transport As previously mentioned, messages are passed to the Spikelink Transport routines through a subroutine call. The format of the call follows: ushort TX Spike MsAg data message, message length, messageyort, reset flag byte data message (DATAAREA SIZE): u ashort message_lengthl u short message ports boolean reset flag The constant DATA AZE SIZE is defined in ST CONST#H and currently has a value of 43. The information in the data message array should have the message type in tms first byte and any message data in subsequent bytes. Constants for each of the message types are also defined in STCONST.H The message length is the number of bytes that the transport routite shoutd copy into a transmit buffer the number of data bytes plts the message type byte).

The message port must be zero for the Doghouse and may be from zero to seven for the Xennel, The reset flag should only be set to TRUE it the message in the data essage array is a RESET message. For all other message FALSE should be passed as this parameter.

TOhe declaration for TXSpikeMsg in included in ST CONST.

4.1.1ss Returnz foan Calls to rXpikeuMaj Four different return Values may occur to calls to TX Spike Hag.

The constants for the return values are defined in STCONST. i 1 No ERROR The message was accepted and will be sent to SpIke.

WO 90/13956 PCT/US89/01806 215 DOGHOUSE/SPIKE DRIVER Page 1-20 2. NO SPIKE THERE Transport does not think there is a Spike on the leash; the message will be ignored.

3. FND ERROR Could nt buffer the message because all the transmit buffers were Cull the message will be ignored.

4. BAD INPUTS An invalid port number or message length was specified in the parameter list; the message will be %gnored.

1.4.2 Now to R34d Messages from Transport When a session task is ready to read a message from Spike, the requesting task must place the mailbox number which they would like to receive the message in, in the global variable active mailbox. once the mailbox value has been stored, th y event flag LINE TASK READY (defined in ST CONST.H) in the event group SPKLNK GROUP (defined in VCOMMON.H) must be set.

As soon as the spikelink transport task sees that a line task is ready to receive data AND there is data available, a message will be placed in the requesting task's mailbox.

Two types of messages may appear in the mailbox$ 1. Button Event Messages 2. Non-Button Event Messages All the structures and unions for the mailbox messages are defined in VSESSXTF.H while most of the constants are defined in ST CONST*H or VSESSITF.H Mailbox variables should be defined as T USERUION, This union contains the structures for both Button event messages USER SHORT) and Non-Button event messages (TUSER LONG).

The format of each message type follows* WO 90/13956 PCT/US89/01806 DOGHOUSE/SPIKE DRIVER Page 1-21 1.4.2.1 Button Event Messages The six byte byte byte word byte byte contents of button event messages is listed below.

scan code; up down; sparel; port numi type The scan code contains the button number on which the event occurred*- The up down field indicates whether or not the event was a button depression or button release.

The sparel field is not used.

The portnum field indicates which port the event came from.

The type field contains the value of the constant MSGUJJSER SHORT.

1.4.2.2 Non-Button Event Messages The six byte contents of non-button event messages is listed below, unsigned char far *P data; byte portnumi byte type; The P*data field contains a pointer to an area of the shared memory pool that contains the aessaga data.

WO 90/13956 PC/US89/01806 217 DOGHOUSE/SPIKE DRIVER Page 1-22 The format of the data in the memory pool is listed below.

7 6 5 4 3 2 1 0 I Number of bytes allocated I I Message Type

I

I I Message Data +(if any) I I IMPORTANT It111 It is the responsibility of the session task using the data to free the memory once the information from the message has been processed. Failure to release memory back to the memory pool will result in NO-MEMORY errors for future messages.

The port num field indicates which port the event came from.

The type field contains the value of the constant MSG USER3LONG.

WO 90/13956, pcr/ US89/0 1806 Table of Contents TA13LE 01 CON1TENITS Dogkhouse/Opike DriVer Transport Layer (V1.01) 1-1 References 1-1 1.2 Link to Transport Protocol 1-2 l.2.l Packet Passing Mechan 1-3 1.2.2 Typical Data Transfer Sequences 0*0*60004.0444 1-4 19.2.*3 Packet Format 999999999 1.2 4 Rel iab ilIity 0 99999*9999a99 1- 6 1..42 Data Packet Integrity 00*6 1-7 1.2.4.2 Recovery schemes for Lost Packets 1-8 2.92 *4 *3 1AUSY Conditions 999999999.999999991-9 1.2.4.4.Pol~1ing Timeouts 1-9 19 2.*4ol Vtz,00' Timieoutu 09 99999999999 9999*9999999 1-9 1.2.5 ies-w'. ;king Buffering 0 1-2.0 192.*6 Erroar Counters 1-11 1.2.6.A Errors it Spike Ma sage 1-211 1.6.2 Spike Response Errors 1.-1i 1.2,6.3 Errors Detected by Spikelink Driver 1-12 1.2o6.4 DATA Packet Errors from Spikelink Driver 1-12 12.*6.5 Resource Errors 999 *~1-1.3 192 *7 Error Flags *.1-13 1.3 Transport to Session Protocol 6000#60640000.0.0..10*.. 1-15 1..3,1 Delivering Messages to Spike 1-15 1.3.2 Receiving Massages from Spike 0 6 1-15 1.3.3 Message Unpacking 1-15 1o.4 Error Counters 999999999999999991-17 3 5 Error Flags ,9 6 0 00a* 0 4 6 0 0 1-1.8 1.4 Transport to Seusion Inttrface 9999999999991-19 1.4%1 HlOW to Pass Mtessages to Transport 1-19 1.4.1*1 Returns from Calls to TX Spike Mag 1-19 1.4.2 How to Read Messages from Trans-port7*4*t*** 1-20 1.4,2,1 uttonEvent Massages 1-21 1#4.2.2 Non-B~ttontventMessages 1-21 WO 90/13956 219 Appendix 3 PCT/US89/01806 'plN.. A tAKMADU gE Scope 1.1 Introduction This document describes the functions performed by, and the SpikeLink interface to the Spike Firmware. The Spike Firmware operates on an 8051 family processor which resides in a Low-end Spike, a High-end Spike, or a Marmaduke and communicates with the Doghouse software by sending messages through SpikeLink, an RS- 485 s~ .al link.

runctional Overview 2.1 Introduction The spike and Marmaduke firmware is responsible for managing the keyboard, LEDs, LC Display, EEPROM, and voice path, while reporting events to and taking commands from the Doghouse software through supervision of a communications protocol built on Spike's serial data interface. Besides managing these features, the firmware provides fault detection and reset facilities.

WO 90/13956 PeTrIUS89/01806 220 SPIKE MARMADUKE EDS Page 2-1 2.2 Features 2.2.1 Serial Data Interface The serial data interface is the physical medium through which communications between Spike and the Doghouse take place.

Firmware manages this resource by servicing a two layer data communications protocol which provides reliable transport of messages to and from Spike. This protocol is described in detail in Chapter 3. Messages are exchanged over this link at roughly ms. intervals although the rate is variable and is determined by the Doghouse. During any of these exchanges, multiple messages, which may be status or command information, can be transferred in both uplink and downlink directions.

2.2.2 Keyboard The firmware periodically scans the keys, which include digit keys, feature keys, and the hookswitch, and reports any changes in state to the Doghouse through the serial link by Key Event messages. Key depressions and releases are qualified (debounced) to the degree of one scanning interval, or 25 ms. Key events are buffered and sent to the Doghouse in the next SpikeLink polling interval. As many as 3 key events can be buffered between polls.

If more than 3 key events occur between polls, the key event buffer will be flushed and firmware will notify the Doghouse by sending a Key Event overflow message. Since one of the key events lost in such a situation could have been the hookswitch, Doghouse software should respond to an overflow by requesting the status of the hookswitch. To do this, the Doghouse would send a Key Status Request message and Spike firmware would respond with the status of the requested key in a Key Status message. Using the Key Status Request, the Doghouse can always inquire as to the status of any key.

Firmware is ignorant of the function of the keys with the exception of the digit keys, 1 through Firmware may be instructed to inject a local 500 Hz tone into the audio path for the duration that any of these digit keys is depressed. Firmware is instructed to enter this mode by assertion of the Keypad Tone Generation Enable bit (bit 6) in the Audio Flags parameter of the Set Audio Path message. Clearing this bit in a subsequent Set Audio Path message will disable this mode. The Keypad Tone Generation feature has been included as an optional method of generating user feedback during the dialing phase of a call. DTMF tones may otherwise be provided for this purpose by the Doghouse.

Wo 9011356 pcrr/US89/01806 221 SPIKE MARMADUKE EDS Page 2-2 2.2.3 LEDs Firmware performs two major functions for the display of the LEDs, cadencing the lamps as instructed by Doghouse software and multiplexing the lamps for power conservation. The Doghouse controls the cadencing of the lamps by sending Display Lamp messages through SpikeLink. These messages include a lamp number and a specific cadence to be used. There are 6 cadences fixed in ROM including solid on and solid off "cadences". All lamps that are set for the same cadence will blink or flash in phase.

Multiplexing of the LEDs is used to lower the operating current requirements for Spike. At most, one LED should be turned on at any given time. To meet this requirement, and to insure constant brightness and no visible flicker, outputs to all 9 LEDs are multiplexed on a 55.6 Hz cycle, or 2 ns. per lamp.

2.2.4 LC Display Firmware provides three LC Display services for use by Doghouse software. These services arc: display of up to 18 byte character strings starting at any cursor position, clearing of NN byte long fields at any cursor position, and a one-shot clear of the entire display. The SpikeLink messages that initiate these features are Display Text, Clear Display Field, and Clear Display. The Displa_ Text and Clear Display Field messages address the cursor by line and column. Mesaiges that address a field that extends past the end of a line will be truncated.

2,2.5 Audio Path The audio path to the user is controlled by firmware under the direction of Doghouse software. All hardware audio control features can be controlled through use of the St Audio Path message. Audio control features include control of the~ speaker, earpiece, microphone, and mouthpiece. Selection of the appropriate gain control for the audio path may also be madd. Gain control is used for selecting use of the ringer or speakbrphone potentiometers. Included in the audio control setting is the ability to generate a 500 Hz. local tone injected into the audio path. This tone may also be generated automatically upon depression of a digit key as described earlier in section 2..2.2 Note that in most cases, direct control of the audio path is given to the controlling Doghouse software. This has been done to allow the greatest possible flexibility for the operation of current and future features that use the audio path.

WO 90113956 PCr/US8/01806 222 SPIKE MARMADUKE EDS Page 2-3 2.2.6 EEPROM The firmware manages the onboard EEPROM as a raw storage resource for Doghouse software. Firmware knows nothing about the contents or position of data stored there. Firmware can write to or read from EEPROM in 16 byte blocks under the command of Write EEPROM and Read EEPROM messages. These messages address the EEPROM by block number. There are 512 blocks (8k bytes) of which all but the last 16 blocks (blocks 01FOh through OlFFh) can be written to. These last blocks are write-protected in hardware and are used to store read-only manufacturing data such as phone type and serial number. All 512 blocks may be read.

Note that the 16 write protected blocks are protected in hardware. If firmware is instructed to write to one of these blocks it will attempt to do so and a EEPROM Write Complete will be sent to the Doghouse following the attempt. Normally, this block was not written to EEPROM, however, special manufacturing drivers may write to protected EEPROM while write protect hardware is disabled by grounding a certain pin on the circuit board (see Sec. 3.2, Spike Marmaduke Hardware EDS).

After a write cycle is complete, firmware will send a EEPROM Write Complete message to the Doghouse. The Doghouse software should not send another Write EEPROM or Read EEPROM request until the EEPROM Write Complete message is received.

Although an EEPROM write cycle should complete in one polling interval, this handshake process insures that the command was received, acted on, and that the hardware is ready to read or write additional data.

In response to a Read EEPROM message, the firmware will read the requested 16 bytes from EEPROM and send the data to the Doghouse in a EEPROM Data message. The Doghouse software should wait for the EEPROM Data message before sending another Read EEPROM or Write EEPROM message.

WA oiI1MA096 p rll l gglO i R{IL y'f d 223 SPIKE MARMADUKE EDS Page 2-4 2.3 Resets Resets may occur in normal operation due to power failure or a command from the Doghouse. They may also occur due to abnormal conditions such as watchdog-timer expiration, drift in the firmware stack, spurious serial port interrupts, or wild Jumps to unused code space. For all types of resetst the firmware responds similarly.

2.3.1 Reset Operations The firmware functions performed during reset processing are: Determine the cause of the reset.

This information is passed to the Doghouse upon completion of reset in the Reset-Event message.

Quickly reset all user interfaces.

This includes turning off the audio path, and clearing the LEDs and LC Display.

Perform selftest- A selftest is perfor&ed to determine the health of various processor and spike hardware components. The following tests are performed: RAM A four pattern teit is made on all of internal RAM excluding the register and stack area.

ROM, All 4K of ROM is summed and compared with a stored ROM checksum.

Timer Both internal timers are tested for accuracy using instruction timing loops.

Serial Link Loopback teats are performed on the serial link.

LC Display The LC Display is tested by sending it a command and making sure it's BUSY bit is cleared in a reasonable amount of time.

If any of these tests fail# excluding the LC Display test, the test will be performed repeatedly until: the test is passed, or the Watchdog Timer expires. The reasoning for this is that if these tests of the processor continually fail, it is likely that the cause of the failure is not a transient event (ESD, e*tc.) but that of a hard failure which could result in indeterminate behavior, If the LC Display test fails the result will be logged in the ResetEvant message and operation will continue without the use of the LC Display.

Light all LEDs and display LCD logo for 500 ms.

This step is done ONLY if the cause of the reset is a power failure or WDT timeout. This step is performed to give the user feedback when installing a Spike in addition to providing a mechanism to visually detect a lamp failure. In addition an asterisk will be displayed in the left-most position of each line of the LC Display (if any).

Initialise internal data structures.

If the self-tests pass, operating firmware data be initialized. These data structures include manage SpikeLink. During this initialization, message will be queued for output to SpikeLink.

structures will those used to the Reset Event Begin normal operations Enable interrupts, start scanning the keyboard, looking for a SpikeLink POLL, etc.

2.3.2 Runtime Integrity The purpose of runtime integrity checks is to catch transient conditions which cause abnormal firmware behavior and to neutralize the effect of such conditions.

The primary runtime failsafe is the hardware Watchdog Timer (WDT). If firmware fails to reset the Watchdog Timer within 1 s o:nd, it will expire and pull the RESET line to the 80C51. This i, ,rimarily effective in detecting infinite loops in firmware, perhaps caused by a wild jump into data tables, etc. Note that since a WDT expiration causes a hard reset to the processor, it cannot be distinguished from a power fail reset.

Other than the WDT, firmware performs the following runtime checks: Stack Alignment Periodically, firmware checks that the stack size is correct.

Wild Jump All unused portions of ROM will be fillad with a jump instruction to a wild jump reet entry. If the processor starts running in the unused code space, a reset will occur.

Logic Error Boundary checks will be made on the contents of internal data structures so that firmware can detect internal inconsistencies that require a firmware reset.

Spurious Interrupt Serial port interrupts that occur while the serial line is not enabled for an operation that would generate such an interrupt will WO 90/13956 PCMUS89/01 806 225 SPIKE MAMADUKE EDS Page 2-6 cause the interrupt to be ignored and a Reject message to be generated. For ekxample, getting a serial receive interrupt while the serial lino is operating in the transai direction would cause the tirmware to ignore the intemrpt and queue a Rlej ect message for transmission to the Doghouse.

Since Stack Alignment, Wild Jump. nd Logic Error resets are generated by firmware, the cause of the reset can and will be reported in the Reset Event m~kssage following the reset. Watchdog Timer rests cannot be distiziguished from Power-Fail rosts.

WO 90/13n 6 Prr/ I)S9s/n1W 226 SPIKE MARMADUKE EDS Page 3-1 Spike to Doghouse Link All cotunications between Spike and the Doghouse use a two-wire, half-duplex, RS-485 data link operating at 19.2 K baud. Each byte is transferred as 1 start bit, 8 data bits (LSB first), and 1 stop bit. Parity is not used. Control and status information is passed through this link by means of a two-layer communications protocol. The lower layer combines the functions of the link and transport layers of the ISO model. It provides reliable transport of higher layer messages and keeps the half-duplex link synchronized. The higher layer consists of the application messages which pass status of user initiated events as well as control of Spike's user (display, etc.) and service (EEPROM, etc.) features.

Much of the design of the Spike to DoghouSe Link (SpikeLink) protocols is predicated on the limited resources of Spike's microcontroller and the physical, two-wire link. Spike is extremely limited on RAM, so SpikeLink is designed to allow the slave to operate with a minimum of buffer memory. Please be tolerant of SpikeLink's primitive qualities.

Packets may be sent downlink, or Doghouse to Spike, and uplink, or Spike to Doghouse.

3.1 The Link/Transport Layer The transfer of information between spike and the Doghouse is based on the exchange of serial packets using a master-slave relationship. The Doghouse is always the master and Spike is always the slave.

The master initiates information exchange every 50 ms by polling the slave. As previously mentioned, the Doghouse may poll Spie with one of two different messages. One poll requires Spike o return an acknowledgement, a data packet, or a busy message. This type of POLL will be referred to as an ACKed POLL. The second type of poll, an ACKless POLL, does not require any response from Spike but a data packet will be accepted if sent, After an ACKed POLL, the master will expect three possible actions from the slave, 1. Spike will return an acknowledgement (ACK) indicating that he does not have any data to pass to the Doghouse.

2. Spike will return a data packet to the Doghouse. The master will acknowledge the data packet and Spike will acknowledge the acknowledgement.

WO 90/13956 PCT/US89/01806 227 SPIKE MARMADUKE EDS Page 3-2 3. The slave will indicate that he is busy and can not accept data from the Doghouse. In this case, the master should wait until the next polling cycle before attempting any further contact with Spike.

After each of the first two events listed above, the master may send a data packet to Spike which will be followed by an acknowledgement from the slave. If the Doghouse does not have any data to send Spike, he simply waitv for the next polling cycle. It is important to note that the master must always sand an ACKed POLL to the slave before sending a data packet to Spike.

After an ACKless POLL, the master wil, expect two possible actions from the slave.

1. Spike will return a data packet to the Doghouse. The master will acknowledge the data packet and Spike will acknowledge the acknowledgement.

2. The master will timeout waiting for a packet from Spike.

Since the Doghouse is not really expecting anything from Spike anyway, this condition will not be considered an error.

Note that although successive polling sequences may occur, successive downlink data transfers are NOT allowed. The master must always poll the slave for data between sending downlink data packets, It is recommonded that downlink data packets be sent IMMEDIATELY after the polling sequence is complete. This will allow the most efficient use of a slave's single buffer.

As previously mentioned, if the slave is not able to accept further data from the master, it will rospond to POLL packets with BUSY packets until the busy condition is cleared.

There are two forms of DATA packets! DATA(O) and DATA(l). The extra information carried is a moddio 2 sequonce number, successive downlink DATA packets alturnate between use of DATA(O) and DATA(1) control fields. Retransmitted packets will break this sequence by using the same sequence number. This lets Spike know whather or not the DATA packet received is a retransmission.

WO90/13956 PCT/US89/01806 SPIKE MARMADUKE EDS Page 3-3 3.1.1 Typical Data Transfer Sequences I MWster Slave POLL

DATA

ACK ACr DATA

ACK

(Master polls Slave for data) (Master sends data to Slave) Master SlAve POLL

ACK

DATA

ACK

(Master polls Slave for data) (Slave has no data to send) (Master sends data to Slave) Master Slave POLLNA

DATA

ACK

ACK

POLMA POr4NA POLLUNA Master Ilave POLL

BUSY

a (Master polls Slave for data) (Master has no data to send) (Master polls Slave at next interval) (Master polls Slave at next interval) (Master polls Slave for data) (Slave indicates that it's busy) (Master waits for next poll interval) POLL ACK ACK DATA

DATA

(Hater polls Slave tor data) (Slave is no longer busy) !Master sends data to Slave)

ACK

WO90/13956 PCI'/US89/01806 SPIKE MMARMADUKE EDS Page 3-4 3.1.2 Frae Format The frame type (POLL, ACK, etc.) is included in The general format of a frame is shown below: 7 6 5 4 3 2 1 0 I PID I Control I Message Length I SMessage Body f (if Data type) I Checksu LSD -+cks I Checksum MSB nn-+ the frame header.

I

I Maximio S40 bytes P1t (4 bits) is the Protocol ID field. This field is used to identify the protocol used for the exchange of data. The validation of this tield is a requirement for data exchange. In the future, when multiple protocols are specified, sow protocol negotiation will be required based on the PID. or first reaeases this field will be 0Oho Control (4 bits) is the control field. This field identifies the packet type. Control field values are: 00 01 02 03 04 0-Orh DTA(0) DATA (1) POLLRA (ACKless POLL) POLL (ACKed POLL)

ACK

BUSY

Undefined and not used POLLA, POLL, ACK, and BUSY packets therefore have no message body and a use of the two different forms of the int Se. 3.1.3.

are control packets and meassage length of zero. The DATh message is explained WO, 90/113956 PCIr/US89/ 1806 SPIKE ?ARMADUKE J1DS Page Message Length (1 byte) is the length (in bytes) of the body of the message. This does not include protocol header or trailer fields such a6 PID, control, length, or Checksum, Control packets, such as POLL and ACK, have a message length of zero. For first erlUase, the maximum value of this field for a DATA packet is 44.

Message Body (0 to 44 bytes) is the data portion of the protocol. This is a variable length field which contains information used by higher level communications layers. The specific contents are detailed in a subsequent section of this document.

This field is non-existent for control packets (POLL, ACK, BUSY).

Checksum (2 bytes) is the mathematical summation of all bytes in the packet not including the checksum itself. In case of an overflow, the checksum is truncated to the two byte size of this field.

3.1.3 Reliable Transport Reliable transport is ensured through retransmission of suspected corrupt packets. Packta are considered corrupt itf the calculated checksum of a received packet is inconsistent with the checksum field of the packet, or, it a character timeout has occurred before all bytes of the packet (determined by the length field) have been received.

?or first releaser the value of the character timeout will be 1 at, The value of the packet timeout will be 1.5 times the transport time of the longest expected response packet, The packet timeout will be set following transmission of the last byte of the packet sent. Packet timeouts are used by the mastur only.

If the slave determines that a received packet is corrupt, it will flush its input buffer and wait for another transmission from the master. It the master receives a corrupt packet, it will flush its input buffer and wait for a packet timeout to occur, When the packet timeout occurs, the master will again flush its input buffer and retransmit its last outgoing message unless the master's last transmission was a DATA packet. In that case, the master waits until the next polling cycle to retransmit the downlink DATA packet. During normal downlink DATA transfers, the master alternates between sending DATA(0) and DATA(1) DATA packats, This alternation effactively provides a modulo two sequence number attached to downlink data that allows detection of retransmitted DATA packets across polling sequences. So, it the slave receives a DATA(0) in one polling frame and another DATA(0) in the next, it knows that the DATA(0) just received is a retransmission and throws it away after sending an ACK.

WO W013956 PC'r/US89/O1806 SPXKE MARMADUKE EDS I Page 3-6 A packet timeout at the mauter could also mean that a packet was never sent by the slave, possibly because the the last downlink packet was corrupt and was thrown away by the slave. Again, the master retransmits the previous downlink packlat. The slave can determine if the packet is a retransmission based on its state or sequence number and if so, the slave will respond to the link as though it has not seen the pactet before. For example, if the slave correctly received a POLL from the master, but the returned DATA was lost, the master would time out and resend the POLL packet. The slave at that time is looking for an ACK packet since it knows it cannot receive a POLL after sending a DATA packet.

So, the slave responds by resending the same DATA packet to the master.

If the master does not receive a proper response to a downlink packet after a third retransmission, the master will abort the current transmission attempt, log a link reset, and begin polling the slave. If the slave continues to respond improperly, the master may consider the link down, but should continue to poll the slave so as to provide service as soon as the condition is corrected.

For more information on transport reliability, see the Doghouse/Spike Driver Transport Specification.

wo 90/13056 SPIE MAPMADUKE EDS PCV~US89((1H$HW Page 3-7 3.13.1 Recovery Bahamas for Lost Packits Master Slave Master POLL X

T/O

POLL AaCK DATA Master POLL m ACK X

T/O

ACK DAT Master

DATA

ACK

ACK

Slave POLL

T/O

POLL ACK DATA Masten

,POLL-

ACK

X--

ACK DATA I' Slave

DATA

DATA

ACK

ICK

Slave

DATA

)hCK

ACK

ACK

slave

ACK

Slave Master POLL j DAUM X

T/O

POLL .s..Sth....jE DAUll) nS.u

DATA

POL ACK -"Wlon> DATAO) POLLuI.Sm bXTtn S.

DATA

ACK

ACK

WO 0/13956 SPIE MARMADUKE EDS PCT/US89/01806 Page 3-8 3.2 The Application Layer Messages sent between Spike and Doghouse constitute the highest layer of information transfer in the SpikeLink protocol.

SpikeLink messages request or report application events such as button events, ringing requests, and LCD display data.

Messages are divided into downlink, or Doghouse to spike, uplink, or Spike to Doghouse.

The format of the application message area is as follows: and Application Header 7 6 5 4 3 2 1 0 I APID I Message Count I Message Type I I I Msg #1 Mag #2 (if >1 msg) Message Data (if any) i I I Massage Type I Max.

44 bytes -e.44- -~rr Message Data (if an I I a;e.

S

Where: APXD (4 bits) is the protocol ID for the application first release this value will be 01h.

layer. Fo1 Message Count (4 bits) is the number of nessages contained in this packet. This value is never zero.

Message Type (i byte) contains the value of the message type, Message Data (0 to 42 bytes) contains parameters and data specific to the particular message. The format of these bytes is discussed in the description of the individual massage.

WO90/13956 PC'/UYS89/018( SPIKE MAMADUE EDS Page 3-9 3.2.1 Downlink Messages 3.2.1.1 Reset Value: Data: Olh None Description: This message initiates a Spike reset sequence which includes a full selftest. If no fatal errors are found during the selftest, Spike will return a Reset Event message. Note that Spike will not service the link while performing selftest. For more on resets see sec. 2.2.

3.2.1.2 Read EEPROM Value: Data: Description: 02h EEPROM Block Number (2 bytes: [lsbmsb]) Request for Spike to send contents of the 16 byte block of EEPROM referenced by EEPROM Block Number.

Spike should respcnd with an EEPROM Data message.

For first release, valid EEPROM Block Number addresses for this operation are 00 Eo 1FFh. If the EEPROM Block Number is out of bounds or if the EEPROM is- currently executing a read or write cycle, Spike will respond with a Reject message.

Doghouse software should wait for a EEPROMData response before sending another Read EEPROM or Write EEPROM request.

WO 90/13956 PCI/US89/0806 235 SPIKE MARMADUKE EDS Page 3-10 3.2.1.3 Write EEPROK Value: Data: 03h EEPROM Block Number (2 bytes: EEPROM Raw Data (16 bytes: 1,msb]) 1lsb,msb]) losb,lsb+l,.. ,mab- Description: Request for Spike to write EEPROM Raw Data to the 16 byte block of EEPROM referenced by EEPROM Block Number. If the write operation proceeds normally, a EEPROM Write Complete message will be returned following completion of the EEPROM write cycle (approx. 5 For first release, valid EEPRQM Block Number addresses for this operation are 00 to IFFh. Note that although firmware will accept EEPROM Block Numbers that fall in the write protected area (IFOh to lFFh), these writes will not normally occur due to write protect circuitry. Firmware accapts writes to these areas so that manufacturing equipment can access the protected areas while the write protect circuitry is physically disabled (see Sec. 3.2, Spike Marmaduke Hardware EDS). If the EEPROM Block Number is out of bounds or if the EEPROM-is cuirently executing a write cycle, Spike will respond with a Reject message.

3.2.1.4 Clear Display Value: Data: o4h None Descriptiont causa Spike to clear the entire LCD display.

WO 90/13954 1CE1US89/01806 SPZXE VAkP.ADUIE EDS Page 3-ll 3.2.1.5 Clear Diplay Field Value: Data: Description: DisplayLine (1 byte) Display Length (1 byte) DisplayColumn (1 byte) Spike will clear Display Length number of characters starting at Display Column on DisplayjLine.

Accepted Display Lino values are 0 to 3 inclusive.

Accepted Display Column values are 0 to 27h inclusive. Accepted DisplayLenqth values are 1 to 27h inclusive. The display addressing format is as follows: DisplayColumn Display Line 00 1 00 1 01 1 02 1 03 1 01 00 01 j 02 03 02 00 I 01 I 02 03 I 'Duke only 03100101 1 02 1 03 +m 9 9*4 4 9 9 4 S

S

S 9

S

if i.;4 24hi 25hi 26hl 27hl 1 24hl 25hi 26hl 27hi I 24hj 25h1 26hj 27h1 I 24hj 25hi 26hi 27h1 WO 00/13956 I'MTUS8/01806 SPI1IE ARMADUKE EDS Page 3-12 3.2.1.6 DisplayText Value: 06h Data. Display Line (1 byte) DisplayjLength (I byte) DisplayColun (I byte) DisplayData (1 to 19 bytes) Description: Spike will lozd Display Data to the LCD display starting at Display column on Display Line.

Display Length must contain the number of ciaracters in Display Data. The mapping of data bytes in Display Data to the actual characters displayed is published in literature describing the HD44780 Controller/Driver Chip. Accepted Display.Line values are 0 to 3 inclusive. Accepted DisplayColumn values are 0 to 27h inclusive.

Accepted Display Length values are 1 to 27h inclusive. Use of any combination of LCD addressing parameters that would cause a write to an LCD address outside of the visible display area will result in a Reject message. The display addressing format is as followst DisplayColIU DisplayLine 00 00 01 1 02 1 03 1 I 24h) 25h1 26h1 27h1 +acs. 4. q. a. 01 00 01 1 02 1 03 I 24h1 25h1 26hi 27hi 02 00 1 1 02 1 03 1 1 24hl 25hl 26h1 27hi 'Duke only 031 00 01 102 1 03 1 1 24hI 26hI 26h 2?hI h 4. 4.- W;O 90/13956 PCT/US$9/01806 238 SPIKE MARMADUKE EDS Page 3-13 3*24.17 Display.Lamp Value: 07h Data: Lamp Number (I byte) Cadence-Number byte) Description: initiates display described by Cadence Number to LED[amp Number]. Cadence Number values correspond to cadences as shown Below. Lamp Number values correspond to physical lamp positions as shown below. Lamp names pre those referenced in Figures 4-1, 4-2t and 4-3.

LampNumber:. LEDI LED2 LED3

LEDA

LED6 LED7 LED6 Message Waiting LED Cadence Number: 00 01 02 03 04 06 Solid Of f Solid On Flash (500 mF* On, 500 met Off) Wink (375 s. 125 ms. Oft) slow Wink (1875 ns. On, 125 mS. Off)

TBD

TD

WO 90113956 rCr/US9/wq80 239 SPIKE MAR14ADUKE EDS Page 3-1.4 3.2. XQy_8tAtUs Request Value: 08h Data: Key_ Number (I byte) Description: Request for spike to report status of key indicated by Key Number. hExpected resp~onse is a KeYStatus message. Doghouse software should wait for a Key Status response before sending another Key -Status Request. KeyuzTber values correspond to physical key positions as shown below. Key namies are those referenced in Figures 4-1# 4-2# and 4-3, WO 90/13956 rcr/USI9/01806 2140 SPIKE &MARM(ADU1CE EDS pacge 3-2.5 Kay~j~mber:Spika Mapping 00in31 10 -Cl 01 -2 11 C2 02 -3 12 C3 03 -4 13 -C4 04 -5 14 -6 15 "C6 06 -7 16 -C7 07 -8 17 w C8 08 9 18 unused 09 0 19 -DI O IA D2 OD -S2 ID w 0 OE -S3 IE wD6 OF- S4 IF 7 m HIookswitch Note; Low-end spike keys are a subset of H~igh-end Spike keys, Marmaduke 1Happing 00 1 10 0CS 01 -2 1 tC 02 -3 12 aLI 03 -4 13 -L2 04 5 14wL3 61 4 06 -7 16 LS 07 -8 17mLU 08m 9IS 3 09 -0 19-b4 OA IA 0B 13 0 OC-Cl 0w7 OD nC2 10 0Do OE C3 I aD Or C4 IV-D300 01 21. D2 WO 90/13956 PCr/US89/01806 .241 SPIKE MAMADUKE EDS Page 3-16 3.2.1.9 Set Audio Path Value: 09h Data: SAudio-Flags (1 byte) Format: Bit 0-4 Bit 5 Bit 6 Bit 7 Encoded control for speaker, he mic, and volume control, See he EDS for format.

0-Tone generation off 1-Tone generation on O-Keypad tone generation disab: I-Keypad tone generation enablt 0 (not used) Selects the audio path for Spike as described by Audio Flags Tone generation controls injection of a 500 Hz. tone into the audio path. When keypad ton* generation is enabled, a tone will be in- Jacted into the audio path while one or more of th4 12 DTMF keys is depreased.

The dtefault used for Audio FEgs at reset time is 01Fh.

WYO 00/13954i 9I'CS89/01 106 SPXKE MAMIADUKE EDS Page 3-17 3.2.2 Uplink Messages 3.24. Reset-Zvent Value: sh Datat Reset _Typ (I byte) Format: 00-Hard Rast (Power-tail WDT) 01%-oft Reset (Reset initiated by Rset message) 02"Stack Alignment Error Reset 03wWild Jump Error Reset 04-Logic Error Reset SelftestResults (I byte) Format: sit o Bit it bit 2-7 t 00LC Display lines 1 and 2 respondig 1-LC Display lines I and 2 not respont 0-IC Display lines 3 and 4 responding 1INC Display lines 3 and 4 not respont 0 (not used) Description: Firmwarecv .Level (I byte) Xndicates that a reset has just occurred and that firmware is now functional and servicing the link, ResetType indicatas the cause of the reset, Selftstesults indicates the status of hardware subsystems (currently only the LC display) tested during the reset. Note that if the processor does not pass selftest during reset proceasitg 1 this 1assage will not be generated and firmware will not service the link. For uore information on resets, see 4 040 2.2.

FirmwarojevjAvel will be equal to 01 until the first customer shipient.

WO 90113956 rPrUS89O 1806 243 SPIKE WM~DUKE EDS Page 3-10 3s24,.2 ZVPR0H-Dat& Value: 82h EEPfl0M B~lock Number (2 EEPR0Mjawpata (16 Iftmsb3) bytes: (lsbimsb) bytes: tlsb~lsb+l#*..,msb- Description: Returns the EEPROM.Data stored in MEROM at EEPROM Blockc number requested by the last Read EEPROM message received. For first release, vali3 EEPflOHBloo)kjNumbor addresses are 00 to irrh.

3 *2.2.3 ZR0)(.WrtQCouPletO Value:t Data: 83h EEPROM.Block Number (2 bytest Clsbjmsb3) Indicates that the EEPROM write cycle initiateA1 by 14st Writ#.e PROH at EEPRQHBlocknuinber was attempted, Description: WO 90/13956 WO 90/3956 cr/US$9/0 1806 SPIRE ?MUUi7DUXE EDS Pa 3-19 3*2.2.4 XeY eVent Va2.u,: 84hi 1XeyNumber byte) KeyEvont-Typ byte) FOrnmatt 00-Key closed 01-Key open Reports that a debounoed key event has occured at Xey Number. Xey Num~ber values correspond to physical' key poxiitlons as shown below. Key names are those referenced in rigures 4-1, 4-2# and 4-3.

Doscriptiont W91196245 PCI'/US89/01806 SPIKE MAP14ADUKE EDSPae32 Spike Mapping Key_Number: 00 -1 10 -Cl 01 -211-2 02 -3 12 -C3 03 -4 13 -C4 04-=5 14 -CS -6 15 C6 06-7 16 C7 07-8a 17 -C8 08 9 18 unused 09 -0 19 DI OA m IA -D2 OB IB -D3 0C Si IC -D4 OD -S2 ID -DS OE -S3 E 06 OF -S4IF-D Hookswitch Note: Low-end Spike keys are a subset of High-end Spike keys.

Marmaduke Mapping XeyNumber: 00 -1 10- 01 -2 11 -C6 02 -3 12 -LI 03 4 13 L2 04 5 14L-3 -6 15 U 06 7 16 LS 07 m8 17 -L6 08 -9 18 -D3 09 -0 19 D4 OA m* IA -DS on #I D6 OC C3 IC -D7 0D, C2 1Dm -D8 OE -C3 IE -D9 OF -C4 IF DIO

DI

21 132 WO 90/13956 WO 90/3956P!USO)/01 806 SPIKE MARMADUKE EDS Page 3-21 3.2.2.S KeyEvent Overflov Value: Data: 8 None Description; Indicates qual if ied curs, the KeyEvents that more than during the last buffer will be will be lost.

3 KeyEvents were key scan. If this ocflushed and the 3 3.2.2.6 KeyStatus Value: Data: Description: 8 6h KeyNumber (1 byte) XeyStatus-Type byte) Format: 00-Key closed 01-Key open Reports the debounced status of key KeyyNumber in response to a KeyStatus Request message.

Key Number values correspond to physical key poitions as shown below4. Key names are those referenced in Figures 4-1, 4-2, and 4-3.

WO 90/13956 PCT/US89/01806 247 SPIX MAIRMADUIE EDS Page 3-22 Spike Mapping KeyNuniber: 00 =1 10 C 01 -2 11 -C2 02 =3 12 =C3 03 -4 13 =C4 04 -5 14- CS -6 15 -C6 06 -7 16 =C7 07-B8 17-=C8 Os 9 18 unused 09 -0 19-=DI OA m IA -D2 OB IB -D3 OC IC =D4 OD -S2 1D OE -S3 IE -D6 OF -S4 IF -D7 Hookswitci Note: Low-end Spike keys are a subset of High-end Spike keys.

Marmnaduke Mapping Key Nuznber: 00 -1 10 -CS 01 -2 11 -C6 02 -3 12 -LI 03 -4 13 -L2 04 5 14 L3 6 15 -L4 06-=7 16- LS 07 -8 17 L6 0B -9 18 -D3 09 0 19 -D4 OA* 1A 0Bin- IB -D6 OC -Cl IC -D7 0D0- C2 1D D8 OE =C3 1E =D9 OF -C4 IF -DIO Dl 21. 02 WO 90/13956 PCT/US89/01806 SPIIM MARMADUhZE EDS Page 3-23 3.2.2.7 Reject Value: Data: 87h RejectCause (1 byte) Format: 00-Resource busy 01-Message type out of bounds 02-Message field(s) out of bounds 03-APID bad 04=Count field 0 interrupt received RejectedMessage_Type (1 byte) Message Type value; OFFh if not applicable This message indicates that the previously received message of type Rejected MessageType (Write ConfigurationData, Display_Text, etc.) was not acted on for the reason described by Reject_Cause.

Description: WO 90/13956 PCT/US89/01806 249 Table of Contents TABLE OF CONTENTS Sope 1-2 1. I Introduction 1-2 1 .2 Document History 1-2 1.3 Reference Documents 1-2 Functional overview 2-2 2.1 Introduction 2-2 2.2 Features 2-1 2.2.1 Serial Data Interface 2-1 2.2.2 Keyboard 2-1 2.2.3 LEDs 2-2 2.2.4 LC Display 2-2 2.2.5 Audio Path 2-2 2.2.6 EEPROM 2-3 2.3 Resets o 2-4 2.3.1 Reset Operations 2-4 2.3.2 Runtime Integrity spike to Doghouse Link 3-1 3.1 The Link/Transport Layer 3-1 3.1.1 Typical Data Transfer Sequences 3-3 3.1.2 Frame Format 3-4 3. 1 13 Reliable Transport 3.1.3.1 Recovery Schemes for Lost Packets 3-7 3.2 The Application Layer 3-8 3.2.1 Downlink Messages 3-9 3.2.1.1 Reset 3-9 3.2.1.2 Read EEPROM 3-9 3.2.1.3 Wrii EEPROM 3-10 3.2.1.4 Clear-Display 3-10 3.2.1.5 Cluar-Display Field 3-11 3.2.1.6 Display Text 3-12 3.2.1.7 DisplayLamp 3-13 3.2.1.8 Key Status Request 3-14 3.2.1.9 Se -Audio Path 3-16 3.2.2 Uplink Messags 3-17 3.2.2.1 Reset Event 3-17 3.2.2.2 EEPROM Data 3-18 3.2.2.3 EEPROM-Write Complete 3-18 3.2.2.4 Key Event 3-19 3.2.2.5 Key Event Overflow 3-21 3.2.2.6 Key Status a 0 3-21 3.2.2.7 Reject 3-23 WO 90/13956 250 Appendix 4 Rev 1.4 PCT/US89/01806 Reregistration Release Page 1-1 Introduction This document discusses the protocol for the registering, reregistration and deregistration of voice and trunk interface units. Tc aid the readers understanding, these three terms are defined as follows: Registration Registration is the process by which a unit obtains a configuration ID (CID) which has never been used on the network. Registration is done by entering the CID on the phone's keypad. An I/O unit needs a CID in order to obtain a Configuration Image, without which it can not operate. The NEMAC task controls the registration process and knows if a CID has been registered.

Reregistration Reregistration is the process by which a CID, that has already been registered, can be transferred from one unit to another without physically moving the unit. In other words, a phone number (and its associated configuration data) is'moved from one physical unit to another. Reregistration is done by entering the previously registered CID on the "new" phone's keypad. The "old" phone loses its CID and becomes inoperative. The NEMAC task controls the reregistration process and knows if a CID is being reregistered.

Reregistration is of particular importance to *MAPIs. The need to move a single phone to or from a MAPI will often arise. At the same time the MAPI can not be moved since a number of other phones must remain attached.

Deregistration Deregistration is the process by which a unit is caused to lose its CID (and configuration). The unit becomes inoperative. The deregistration procedure is carried out through the NetMan-PC by entering the appropriate command and the CID to be deregistered.

WO 90/13956 PCT/US89/01806 251 Reregistration Rev 1.4 Page 2-2 Release General Operating Modes The network may operate in any of three general modes regarding registration and reregistration: No-Registration Registration of units is disallowed.

Reregistration of units is disallowed.

No-Reregistration Registration of units is allowed.

Reregistration of units is disallowed.

Global Reregistration Registration of units is allowed.

Reregistration of units is allowed.

These three general modes of operation apply equally to all units on the network. The situation might arise where a single unit needs to be registered or reregistered while maintaining a No- Registration restriction on all other units. For this purpose Selective Reregistration has been provided.[l) It is available in all three general modes of operation. Selective Reregistration allows the system administrator to give a specific CID permission to register or reregister. The permission can be limited to a specified length of time and once used, is canceled. Selective Reregistration provides maximum configuration security but is highly restrictive. On the other hand, Global reregistration provides a high level of freedom to register and reregister units but a low level of configuration security.

The three 'eneral operating modes and Selective reregistration are discussed in detail below. The remainder of this document is highly technical. The casual reader may wish to skip the remainder of the document and instead turn to Appendix B, "Modes of Registration Illustrated".

The term Selective Reregistration was chosen over Selective Registration because it was thought the function will be used more often for purposes of raregistration than registration.

This was also true in the case of the term Global Reregistration.

WO 90/13956 PCT/US89/01806 Reregistration Rev 1.4 Page 3-3 Release No-Registration Mode The No-Registration mode prevents any unit from registering or reregistering (except those with Selective Reregisteration permission). This mode provides the highest level of configuration security. Only units with Selective Reregistration permission are allowed to register or reregister. The No-Registration mode is initiated by issuing the appropriate command at the NetMan-PC console. Using a SCSI level Control Packet, the NetMan- PC instructs the NEMAC task to reject all CID registration request packets arriving from the network, except those with Selective Reregistration permission. For more on this topic, see Selective Reregistration.

No-Rergistration Mode The No-ReregistrLtion mode prevents any unit from reregistering except those with Selective Reregisteration permission. This mode provides an intermediate level of configuration security. Units attempting to register with CIDs not currently registered are allowed to do so. Units with Selective Reregistration permission are also allowed to register or reregister. The No-Reregistration mode is initiated by issuing the appropriate command at the NetMan-PC console. Using a SCSI level Control Packet, the NetMan- PC instructs the NEMAC task to reject all CID reregistration request packets arriving from the network except those with Selective Reregistration permission. For more on this topic, see Selective Reregistration.

Global Reregistration Mode Global reregistration is intended to be used in situatfons where a large number of units must be reregistered An office floor plan is being reorganized) or where unit configuration security is of little concern. The global reregistration mode is initiated by issuing the appropriate command at the NetMan-PC console. Using a SCSI level Control Packet, the NetMan-PC instructs the NEMAC task to accept any and all CID registration request packets arriving from the network and to modify the PID/CID/PUA tables. It should be noted, the packet generated for unit reregistration will be of the same format as those used for CID registration requests.

WO 90/13956 253 PCT/US89/01806 Reregistration Rev 1.4 Page 5-4 Release At the PCP tables level, global reregistration means any physical unit, identified by its PID, may request a new identity by sending a CID registration request packet containing a new CID to NEMAC. In the No-Registration and No-Reregistration modes, if a CID registration request packet is received and the PCP tables already contain an entry for the specified CID or the recuester's EU, the request is rejected.

5.1 System Actions Under Global Reregistration.

With global reregistration enabled, CID registration requests are not rejected. The state diagram for global reregistration is presented in Figure 1 and is described textually below.

The NEXAC task first checks the NDD for the specified CID's configuration file. Further actions depend on the existence of the configuration file.

5.1.1 Configuration File Is Not Found If the configuration file is not found, a CID response packet containing the Bogus CID (see Appendix A) is returned to the requester. The receipt of a CID response packet containing the Bogus CID as the result of a manually entered CID, as in all cases, is treated as negative response. The Bogus configuration file is not requested. The unit maintains whatever configuration it had at the time of the request.

5.1.2' Configuration rile Is Found If the configuration file is found, the PCP tables are then examined for the specified CID. Depending on the results of this search the following actions will be taken.

CID Is Found If :he CID is found: 1. The NEMAC task sends a Kill Packet to the PUA of the unit currently associated with the CID, the "Old Unit".

2. When the Old Unit receives the Kill Packet, it clears its LUA and LE(s) thus disabling the unit.

3. NEAC then deletes the CID along with the associated PID WO 90/111 A DI"t7I I fiO/fil Qfl; W V 254 1 L* A I u Reregistration Rev 1.4 Page Release and PUA from the PCP tables, and adds the CID, PID and PUA contained in the original (New) CID registration packet.

4. A CID response packet containing the valid CID is returned to the original requester.

Steps one and two are needed to avoid two units using the same configuration and therefore the same LUA.

5.1.2.2 CID Is Not Found If the CID is not found, there is no possibility the CID is in use by any unit on the network.

1. NEMAC adds the specfied CID along with the PID and PUA contained in the CID registration packet to PCP tables.

2. A CID response packet containing the valid CID is returned to the requester.

5.2 Global Reregistration, summary In global reregistration mode everything goes. If a valid CID is entered at a given phone, that CID becomes associated with the phone's PID. The CID previously associated with the phone is gone, deleted from the PCP tables.

Selective Reregistration Selective reregistration is intended to be used in situations where a relatively small number of units must be registered or reregistered an individual is moving to a new office). It provides a high level of system security while allowing authorized individuals to register or reregister their phones.

Selective reregistration is initiated by issuing the appropriate command at the NetMan-PC console. Using a SCSI level Control Packet, the NetMan-PC instructs the NEMAC task on the NMIG to accept CID registration requast packets for only the specified

CID.

At the PCP tables level, selective reregistration means any physical unit, identified by its PXD, may only take on the iden- WO 90/13956 PCUS89/01806 255 Reregistration Rev 1.4 Page 6-6 Release tity of a CID whose PCP tables entry is marked for reragistration. The configuration file must be present on the NDD. Once reregistration of a CID has been accepted, permission to reregister that CID is withdrawn by NEMAC, 6.1 system Actions For Selective Reregistration The state diagram for selective reregistration is presented in Figure 2 and is described textually below. The NEMAC task first checks the system's general operating mode. The NEMAC stores the state of the general operating mode in the global var' byte Gen_OpMode. If the Global Reregistration operating mode is in force, Selective Reregistration has little effect. Further actions are identical to those described under Global Reregistration.

If the Global Reregistration operating mode is not in force, the NEMAC task checks if the CID appears in the PCP Tables. If the CID does not appear in the PCP Tables, it can not be previously registered and can not have reregistration permission. The rrereghash[] and cid hash(] tables are used to find the selected CID in the pcp[] table. Further actions depend on the existence of the CID in the pcp[] table.

6.1.1 CID Is Not Found In PCP Tables If the CID is not found in the PCP Tables, the CID can not have been previously registered. The system's general operating mode is checked. The NEMAC stores the state of the general operating mode in the global variable, byte Gen opMode. Further actions depend on whether the No-Registration or No-Reregistration mode is in effect.

6.1.1.1 No-Registration Node In Effect If the target CID is not found in the PCP tables, the No- Registration mode blocks any further processing of the registration request. A CID response packet containing the Bogus CID will be returned to the requester. The receipt of a CID response packet containing the Bogus CID as the result of a manually entered CID, as in all cases, is treated as negative response.

The Bogus configuration file is not requested. The unit maintains whatever configuration it had at the time of the request. No changes to the PCP tables are made. Statistics as to the number of attempts made to reregister a given CID could be kept but this WO 90/13956 PCT/US89/01806 256 Reregistration Rev 1.4 Page 6-7 Release is not currently done.

6.1.1.2 No-Reregistration Mode In Effect If the target CID is not found in the PCP tables and the No- Raregistration mode is in effect, it may still be possible to register the target CID. Further actions depend on the existence of the target CID's configuration file on the NDD. See "Checking For The Configuration File" below.

6.1.2 CZD Zs Found In PCP Tables If the CID is found in the PCP Tables, the NEMAC task checks if the CID has selective reregistration permission. The rereg hash[) table is used to find the selected CID in the pcp[) table. The pcp flag field of the pcp[ entry can then be checked for the validity and the reregistration permission of the entry. Further actions depend on the reregistration permission associated with the CID.

6.1.2.1 CID Does Not Have Reregistration Permission I. this situation the CID appears in the pcp[) table bhat has only the VALID PCP flag set, If the CID does not have reregistration pfirmission, a CID response packet containing the Bogus CID will be returned to the requester. The receipt of a CID response packet containing the Bogus CID as the result of a manually entered CID, as in all cases, is treated as negative response.

The Bogus configuration file is not requested. The unit maintains whatever configuration it had at the time of the request. No changes to the PCP tables are made. Statistics as to the number of attempts made to reregister a given CID could.be kept but this is not currently done.

6.1.2.2 CID Has Reregistration Permission If the CID has reregistration permission, one of two situations exist. Either the CID appears in the pcpC) table as part of a complete entry, or the CID appears in the pcpE3 table for reregistration purposes only (no valid PXD and PUA associated with CID and CID 4 REREG flag is set). Because the CID has reregistration permission there is no dependency on the general operating mode. Further actions depend on the existance of the configuration file on the NDD. See "Checking For The Configuration File" directly below.

WO W013956 PCr/US89/OI806 257 Reregistration Rev 1.4 Page 6-8 Release 6.2 Checking Por The Configuration Pile A check of the NDD is made for the target CID's configuration file if either of two sets of criteria is fulfilled. These are: 1. The CID is not found in the PCP Tables.

And The No-Reregistration mode is in effect.

2. The CID is found in the PCP Tables.

And The CID has reregistration permission.

Further actions depend on the existence of the configuration file on the NDD.

6.2.1 Configuration File Zs Not Pound If the configuration file is not found, a CID response packet containing the Bogus CID will be returned to the requester, The receipt of a CID response packet containing the Bogus CID as the result of a manually entered CID, as in all cases, is treated as negative response. The Bogus configuration file is not requested.

The unit maintains whatever configuration it had at the time of the request. No changes to the PCP tables are made.

6.2.2 Configuration Pile Is round If the configuration file is found, registration/reregistration of the CID can take place. Further actions depend on the existence of the CID in the pcp[] table.

6.2.2.1 CID Pound in PCP Tables At this point, if the configuration file is found and the CID appears in the PCP Tables, the CID must be able to reregister.

Reregistration of the CID can take place as follows: 1. The EMA task sends a Kill Packet to the PUA of the unit currently associated with the CID, the "Old Unit".

2. When the Old Unit receives the Kill Packet, it clears its LUA and LE(s) thus disabling the unit 3. NEMAC then deletes the CID along with the associated PID WO 90113956 Pff/US89/01806 258 Reregistration Rev 1.4 Page 6-9 Release and PUA from the PCP tables, and add the CID, PID and PUA contained in the original (New) CID registration packet.

4. A Clb response packet containing the valid CID is returned to the original requester.

Steps one and two are needed to avoid two units using the same configuration and therefore the same LUA.

6.2.2.2 CID Not Found In 2CP Tables At this point, if the configuration file is found but the CID does not appears in the PCP Tables, the CID must be able to register for the first time. Registration of the CID can take place as follows: 1. NEMAC adds the specified CID along with the PID and PUA contained in the CID registration packet to PCP tables.

2. A CID response packet containing the valid CID is returned to the requester.

6.3 Selective Reragiatration, summary Selective rreegistration strictly controls reregistration activities. Only CIDs which have been given reregistration permission are allowed to become associated with a new phone's PID. The CID previously associated with the phone is gone, deleted from the PCP tables.

Deregistration Unlike reregistration, deregistration is performed exclusively form the NetMan console. Since deregistration is largely an operation performed by the NEMAC task, no operation need take place on the phone unit. In addition, deregistration seams like an operation which should be limited to use by the system administrator.

Deragistration is initiated by issuing the appropriate command at the Netilan-PC console. Using a SCSI level Control Packet, the NetMan-PC instructs the NEMAC task on the NMIG to remove WO 90/13956 Prr/Iis8o/n1RO6 259 Reregistrationl Rev 1.4 Page 7-10 Release references to'the specified CID from the PCP tables.

The NEMAC task searches the PCP tables for the i'r ci.ied CID.

Depending on the results of this search the following actions are taken.

7.1 CID Xs Found If the CID is found: 1. The NEMAC task sends a Kill Packet to the PUA associated with the CID.

2. Wh.n the unit receives the Kill packet, it clears its LUA and LE(s) thus disabling the unit.

3. NEMAC then deletes the CID along with the associated PID and PUA from the PC? table.

Steps one and two are needed to disable the unit. The unit is left in a state where it can accept u new manually entered CID.

7.2 CID Is Not Found If the CID is not found, no deregistration can take place. The only action taken is the generation of an event, sent to the event log, indicatin4 deregistration did not take place because no CID was found.

WO 90/13956 WO 903956Pr/US891 01806 260 0) obdc Ovteral R er-g is troaticor.

Systemn ViewF from Doin t on Idle, Unit Able to Acceot CIO Input from Key Pod -C00 Entered at Unit -No Conflg File Found I Unit Sands Reregistratin -CDO Response Pkt Sent Packet to NetMon to Unit w/ Bogus CIO I NetMon Starts Checking an SCSI DISK.

Checingfor Config File an SCSI Disk -Config Fie Found -Start Checking PCP Tables tot the Specified CID ~Checking PCP Tables for CID -CDO Found In PCP Tables -CID Not Found In PCP Tables- I NetMon Sends 9111 Pocket to -Add CID w/ New PUA PlO "Old* Unit to PCP Tcbles -Old Unit Gives Up LUA -Send CIO Response Packet -NetMnn Deletes PIO/C1D/PUA to "Now" Unit From PCP Tables -Add CID w/ New PUA PlO to PCP Tables -Send 030 Response Packet to *New" Unit CDO Reregistrction Complete Figure 1.

0 ic

C)

NoTgrminNe t~an-PC Heyr I can't register Mode Set. myynwpoe No-registration ModeiSet.

Selectiv ca registrato NoorUe 0 Globa NeMan-PC I can registerW Raregistrationmynwpoeo.

(Rode SeL phone~~ can rehans reeere it Ncon Globabl eregistration mode St SelctveRrgitrtine Not tn Use.eitrwt Jfode sec.

C ID 4334.

Net Ma&- PC ~JThe Nob-registation node is set. Noody can re gister or Newgister. ecc. t those with Selective Remw gist vat ion permission.

Like CID 4334.

No-registration Mode Set.

Selective Reregistration In Use.

NAet Man- PC T' ho No-reregistmL ion 1?wde is' set. People can register unregistered CIDs. bid can't reregister S previously registered CIDs. No-reregistration Mode Set.

Selective Reregistration Not In Use.

WO 90/13956 Release 265 ReV 1..4 PCI/US89/01806 Page 9-12 0 PigUre 2.

WO 90/13956 PCT/US89/01806 Page 10-13 Reregistration Release Rev 1.4 10.0 Appendix A, Glossary of Acronyms Bogus CID The "Bogus" CID (value 0) is a special CID which is used to identify a configuration that if loaded into a unit, limits the unit's operation to dealing with manually entered CIDs. The receipt of a CID response packet containing the Bogus CID as the result of a manually entered CID is treated as negative response. The Bogus configuration file is not requested. The unit maintains whatever configuration it had at the time of the request.

CID Configuration Identifier. This sixteen bit value identifies unit configuration images on the NetMan-PC (and downstream from that point). CIDs are created by the system administrator at the NetMan-PC. A unit's phone extension number can be used as the CID but this does not necessarily need to be true. Since each phone needs a configuration, MAPIs will have up to eight CIDs while an API will have only one. See also, Bogus

CID.

Kill Packet The Kill Packet is used to deconfigure a unit. It contains the CID of the phone to be killed. This information is useful to MAPIs since only a single phone on a MAPI may need to be deconfigured while maintaining the configuration of other phones. The receipt of a Kill Packet by a unit will cause the unit to clear the LUA and LE associated with the specified CID.

LLS Logical Level SCSI Interface. The LLSI lies above the Low Level SCSI driver. The function of the LLSI is to dispatch processed SCSI Level Control Packets (SLCPs) to the appropriate applications level task (NBU, NEMAC, etc).

NBC

NBU

Network Boot card contains a SCSI controller, a 3.5 inch SCSI hard disk, unit for conference call processing.

interface and a DSP Network Boot Unit. Historically NBU refers to the WO 90/13956 PC/US89/01806 267 Reregistration Rev 1.4 Page 10-14 Release physical unit responsible for booting nodes on the network. After various design changes NBU has come to refer to the task running on the NMIG's IOP which performs this function.

NCIN New Configuration Image Notification packet. A NCIN Packet is a Signalling Packet which notifies a unit it has a new Configuration Image available to it on the NBU. The NCIN packet contains a valid CID which the receiving unit will use to request a new Configuration Image. The NCIN Packet should not contain the Bogus CID.

NDD Network Data Disk. The NDD is a synonym for the SCSI hard disk on the NBC card.

NEMAC Network Event Management And Control. The NEMAC is a task which runs on the NMIG's IOP. It is responsible for monitoring event messages generated by nodes on the network and to transmit control messages from the NetMan-PC to the network nodes.

NetMan The term NetMan has historically been used to encompass all the hardware and software associated with network management. For the purposes of this document the term "NetMan" includes the HetMan-PC, the NMIG and all software contained therein.

NetMan-PC Network Manager PC. The personal computer or work station which provides the network management user interface.

NMIG Network Management Interface Group. The NMIG is a board group consisting of an lOP card and an NBC card. It interfaces with the NetMan-PC through the NBC's SCSI bus. The NMIG's IOP executes the network booting and network monitoring software.

PCP PID-CID-PUA tables. At installation time a unit will register with the NMIG's NEMAC task. The NEMAC (Network Evant Monitoring And Control) task will keep tables which relate PIDs to CIDs to PUAs, the PCP tables. The NEMAC will not need to WO 90/13956 PCT/US89/01806 268 Reregistration Rev 1.4 Page 10-15 Release search on LUAs, therefore LUAs are not included in the PCP tables. The PCP tables represent the working configuration map of the system. To protect these tables from loss due to such events as power failures, the PC? tables will be saved on the NMIG local SCSI disk (NDD). Any modification to the tables will be recorded in the disk resident copy. on reboot, for any reason, the disk resident PCP tables will be read into memory.

PID Physical Identifier. This is a general term meaning the unit's serial number in the case of a API and the cabinet/slot/port number in the case of a MAPI and TIOP.

Port A port is a communications end point. A MAPI has eight ports to which phone units are attached. A TIM ha up to twenty-four ports to which trunk lines az attached.

PUA Physical Unit Address. .his address is a unit's serial number. A unit will have only one PUA no matter how many ports the unit has.

SLAP SCSI Level Access Point. SLAPs are service access points present in the Logical Level SCSI Interface (LLSI) which relate SLCP Command Types to the processing of the SLCP. An applications level task may register with the LLS1 to control the handling of all SLCPs with a given Command type.

Only one applications task may register for a given SLAP.

SLCP SCSI Level Control Packet. The NetMan sends commands to the NZMAC task through SCSI Level Control Packets. A SLCP is a special vendor specific SCSI command. In addition to SCSI control information, SLCP contain: a. A one byte Command Type field.

b. A two byte Sequence Number field.

c. A variable length Commandi Dependent Data field.

TIM Trunk interface Module. A group of cards made up WO 90/13956 WO 9013956PCI'/US89/0)1806 269 Reregistration Release RQV 1. 4 Page 10-16 TrkGrp of an lOP and up to three trunk cards.

'trunk Group. A Trunk group is a logical grouping of Trunk Ports organized on the Net~ian database.

They can be physically distributed. A TrkGrp could consist of all the ports on a TIM, or it could be composed of selected ports on various TIMs.

TSR Terminate-arAd-Stay-Resident. A come to be defined as a progran PC which remains in memory terminated. Some external event key stroke or activity at a cause the TSR to reactivate.

operating system such as MS-DOS of multitasking capability.

TSR program has running on an IBM even after it has (for example, a serial port) will TSRs give batch some small degree WO 90/13956 PCT/US89/01 806 270 Rev 1. 4 Reregiatration Release page 11-17 11.0 1ppendiX B, Modes ot Registration Illustrated The following illustrations attempt to show the behavior of the net~work under various circumstances. They are intended for the non-technichl reader.

WO "6/13956 PCr/US89/01806 271 Reregistration Rev 1.4 Release TABLE OF COUTENTS introduction 1)..ii 1-1 General Operating Modes 2-2 No-Registration Mode 3-3 No-ReregistrationMode 4-3 Global Reregistration Mode() 5-3 5,1 System Actions Under Global Reregistration. 5-4 5.1,1 configuration File Is Not Found 5-4 5#1.2 Configuration rile Is Found 5-4 5.1.2 ,1 CID Is Found 5-4 5.1.2.2 CID Is Not Found 5.2 Global fleregistration# Summary Se10ctiVe Reregistration 6.3. System Actions For Selective Reregistration 6-6 6,1,1 CID IsNot Found In PCP Tables 6-6 6.l.1.1 No-Registration Mode In Effect oo 6-6 6,1.1.2 No-Reregistration Mode In Effect 6-7 6.1.2 CID Is Found In PCP Tables 6-7 6.1.2.1 CID Does Not Have Reregistration Permission 6-7 6.1.2.2 CID Has Raregistration Permission 6-7 6.2 Checking For The configuration File 6-8 6.2.1 Configuration File Is Not Found 6-8 6.2.2 Contiguration Pile Is Found 6-8 6.2.2,l CID Found In PCP Tables 6-8 6.2.2.2 CID Not Found In PCP Tableuii 6-9 6.3 Selective Reregistration, Summary 6-9 Deregistration 0 4 o 6 4 0 6 0 4 0 4 4 7-9 7.1 CID Is Found i.lii7l 7#2 CID Is Wott Found to 60 6 0 60 66 0 4 6 6 4* 0 6 40 4 0 7-10 $o igu e I* 0 0 0 0, 6 s 0 a 0 44 6 6 6 0 o 0 o Stl OoO FigureL 2* 0 0 0 6 0 0 0 f, 6 6 6 6 6 0 0 6 0 0 4 0 9-12 100 XppendiX At Glossary Of ACrVoyms 0 0 001-13 11.0 Appendix B, Modes of Registration Illustrated *i.11-17

Claims (29)

1. A communication system for exchanging information between a plurality of nodes, comprising: a unidirectional transmitting medium coupling each of said nodes to a head-end of said transmitting medium; a unidirectional receiving medium extending from an originating end to each of said nodes; head-end translating means for transferring signals received at said head-end of said transmitting medium to said originating end of said receiving medium; means for generating a periodic timing mark on said receiving medium, each interval between a pair of timing marks being a frame, each frame defining a plurality of timeslots; means for transmitting a test signal from a first node on said transmitting medium; means for receiving said test signal at said first node on said receiving medium; means for calculating an elapsed skew time between the transmitting and receiving of said test signal; means for transmitting information for a specified timeslot an amount of time equal to said skew time prior to the i arrival of said specified timeslot at said receiving means; and wherein said transmitting medium and said receiving medium are separate frequency channels on a single physical S medium and said translating means is a frequency translator. 4tt

2. The communication system of claim 1 further comprising means, coupled to said first node, for digitizing a voice signal to produce said information. t"

3. The communication system of claim 2 further comprising a plurality of means for digitizing voice signals, each digitizing means being coupled to one of said nodes, each of *said nodes having a separate address, and a plurality of Smemories, each coupled to one of said nodes for storing the addresses of said nodes. 273

4. The communication system of claim 3 further comprising a plurality of transmitting and receiving channels on said physical medium, each of said nodes having means for transmitting and receiving on more than one channel. The communication system of claim 1 wherein at least one interval within each frame is designated a signalling packet interval, and fcrther comprising a network boot unit including: means for transmitting a boot control signalling packet ("BCSP") in a given SP interval, wherein the BCSP (i) contains boot control information signifying that a boot image is to be transmitted, (ii) specifies at least one timeslot in which the boot image is to be transmitted in later cycles, and (iii) contains image descriptor information identifying the boot image; and means for transmitting boot packets, each containing a portion of the identified boot image, within the specified timeslot or timaslots for each of a number of cycles subsequent to the frame in which the BCSP was transmitted. S. 6. The communication system of claim 5, wherein the NBU further includes means for transmitting the boot image over Ssuccessive cycles. 0 t Sf: 7. The communication system of claim 5, wherein the first node comprises: moans for testing for a predetermined time for the presence of a BCSP specifying a particular type of boot image; and a means for transmitting a boot request signalling packet ("BRSP") specifying thi particular type of boot image in the absence of a BSCP within the p'rdetermined time. a .rr' t,* I

8. The communication system of claim 5 wherein the NBU futher includes means for claiming at least one timeslot prior to transmitting boot packets.

9. The communication system of claim 8 wherein the claiming means comprises: means for determining a timeslot that is believed to be free; means for transmitting a claiming packet unique to the NBU on that timeslot; means for listening to that timeslot; and means for verifying the receipt of the claiming packet as sent. The communication system of claim 5 wherein the BCSP transmitting means includes means for transmitting a BCSP simultaneously on a plurality of channels, and wherein the boot packet transmitting means includes means for transmitting boot packets on a single channel.

11. The communication system of claim 5 wherein the BCSP transmitting means includes means for transmitting a BCSP after at least one boot packet has been sent.

12. The communication system of claim 1 wherein at least one interval within each frame is designated a signalling S packet interval, and further comprising: Ats a plurality of network boot units (NBU's), each NBU including: means for transmitting a boot control signalling packet Ps, ("BCSP") during the SP interval, the BCSP for that NBU to identifying that NBU as the source, means for testing for the reception of a BCSP, means for determining if the first BCSP received t, originated from itself, and means for assuming the status of master NBU if and only if the first received BCSP did originate from itself.

13. The communication system of claim 12, wherein each NBU further includes: means for transmitting a boot control signalling packet ("BCSP") in a given SP interval, wherein the BCSP contains boot control information signifying that a boot image is to be transmitted, (ii) specifies at least one timeslot in which the boot image is to be transmitted in later cycles, and (iii) contains image descriptor information identifying the particular boot image; and means for transmitting boot packets, each containing a portion of the particular boot image, within the specified timeslot or timeslots for each of a number of cycles subsequent to the frame in which the BCSP was transmitted.

14. The communication system of claim 1 wherein said information transmitting means includes means for asynchronously transmitting said information within said timeslot. c 15. The communication system of claim 1 wherein said information transmitting means further comprises means for transmitting information signals to a second Snode in said specified timeslot in first frames, said first frames occurring every other frame; and further comprising means for receiving information signals from said second node in said specified timeslot in second frames, said second frames occurring between said first frames. jeft.

16. The method of claim 15 wherein said periodic timing mark generating means includes means for receiving a timing signal from a public switched network and for using said S public switched network timing signal to produce said timing marksr 1 *IU

17. The communication system of claim 1 further comprising: means for monitoring, at each node, timeslots following said timing mark for the presence of messages; means for storing in a memory at each node a list of occupied timeslots; means for transmitting, at an originating node a dummy message in a claimed, random one of the unoccupied timeslots as determined from said memory list; means for monitoring said receiving medium for reception of said transmitted dummy message; means for comparing a received dummy message to the transmitted dummy message; means for transmitting a series of dummy messages in said claimed timeslot to keep the claimed timeslot occupied; means for updating said memory list in other nodes to indicate said claimed timeslot as being occupied; means for transmitting a signalling packet from said originating node having a destination address, an originating address, and the location of said claimed timeslot; .means for monitoring said receiving medium for a response to said signalling packet; means for receiving a responsive signalling packet designating a claimed response timeslot; and means for transmitting voice data in said claimed timeslot and converting voice data in said response timeslot into voice signals. 0. 0

18. The communication system of claim 17 herein each of said transmitting and receiving medium includes a plurality of frequency channels, wherein said signalling packet transmitting means further comprises means for sending said signalling packet S over each of said channels, and wherein said monitoring means includes means for monitoring for a response on a home channel containing said claimed timeslot.

19. The communication system of claim li/ further comprising: means for receiving, at a receiving node, said signalling packet addressed to said receiving node; means for transmitting a second dummy message in a' response timeslot having a predetermined relationship to said claimed timeslot; means for monitoring said receiving medium for reception of said transmitted second dummy message; means for receiving said second dummy message; means for comparing said received second dummy message to the transmitted second dummy message; meana for transmitting a signalling packet addressed to said originating node indicating that voice communication has been established; means for transmitting a series of second dummy messages in said response timeslot to keep said response timeslot occupied; and means for sending voice transmissions in said response timeslot.

20. The communication system of claim 19 further S comprising means for adding said reverse timeslot to said memory S list of occupied timeslots at said other node.

21. The communication system of claim 19 further S comprising: means for determining whether said receiving node is busy with another transmission; and means for sending a signalling packet to said originating node indicating that said receiving node is busy if said receiving node is busy. i "j C

22. The communication system of claim 21 wherein each of said transmitting and receiving medium has a plurality of chan ls and further comprising: means for determining whether said originating node is on the same channel as said receiving node; means for transmitting a signalling packet to an additional node when said receiving and originating nodes are on different channels and said receiving node is busy, said signalling package indicating that said receiving node is busy; and means for retransmitting, at said additional node, said signalling packet from said receiving node to said originating node on the frequency channel of sad originating node.

23. The communication system of claim 1 means for monitoring, at each node, timeslots following said timing mark for the presence of messages; means for storing in a memory at each node a list of occupied timeslots; means for transmitting, at an originating node a dummy message in a claimed, random ono of the unoccupied timeslots as determined from said memory list; means for monitoring said receiving medium for S reception of said transmitted dummy meisage; means for comparing a received dummy message to the transmitted dummy message; means for transmitting a series of dummy messages in ti said claimed timeslot to keep the claimed timeslot occupied; means for updating said memory list in other nodes to indicate said claimed timeslot as being occupied; means fov transmitting a signalling packet from said originating node having a destination address, an originating address, and the location of said claimed timeslot; means for monitoring said receiving medium for a response to said signalling packet; means for receiving a responsive signalling packet designating a claimed response timeslot; means for transmitting voice data in said claimed timeslot.and converting voice data in said response timeslot into voice signals; means for receiving, at a receiving node, said signalling packet addressed to said receiving node; means for transmitting a second dummy message in a response timeslot having a predetermined relationship to said claimed timeslot; means for monitoring said receiving medium for reception of said transmitted second dummy message; means for receiving said second dummy message; means for comparing said received second dummy message to the transmitted second dummy message; means for transmitting a signalling packet addressed to said originating node indicating that said response timeslot has been claimed; means for transmitting a series of second dummy messages in said response timeslot to keep said response timeslot occupied; means for sending voice transmissions in said response S timeslot; means for determining whether said receiving node is busy with another transmission; means for sending a signalling packet to said originating node indicating that said receiving node is busy if said receiving node is busy; means for determining whether s&id originating node is on the same channel as said receiving node; means for transmitting a signalling packet to an additional node when said receiving and originating nodes are on different channels and said receiving node is busy, said signalling package indicating that said receiving node is busy; and means for retransmitting, at said additional node, said signalling packet from said receiving node to said originating node on the frequency channel of said originating node.

24. The communication system of claim 1 further comprising: a second node, each node having at least one associated telephone characterized by address information, wherein at least one interval within each frame is designated a signalling packet interval, a plurality of time slots within each frame are designated voice time slots and pairs of VTS's in each cycle define a voice circuit and wherein each node further comprises: means for receiving signals from its associated telephone; means for claiming a first VTS of an unused VC when the node receives signals from its associated telephone; means for exchanging SP's; means for claiming the second VTS of the VC; and meahs for inserting voice data in their respective claimed VTS's;* means for generating the voice data on the basis of signals received from its associated telephone for transmission to the other node; and I means for applying voice data as received from the other node to its associated phone. 2S. The communication system of claim 24, wherein the first VTS claiming means Comprises: means for ascertaining the apparent availability of a aB particular VTS, means for transmitting a cl~iminq Voice Packet ("CVP") within the apparently available VTSI and means for verifying Itha receipt of the CVP intact to indicate the absence of collision. .281

26. The communication system of claim 25 wherein each node is capable of communication on any of a plurality of frequency channels, and wherein the SP exchanging means includes means for sending a Call Request SP on each of the channels, specifying a single channel for response.

27. The communication system of claim 25 wherein each cycle contains first and second frames, each frame including an SP interval and a plurality of VTS's, with any VC consisting of corresponding VTS's from the first and second frames.

28. The communication system of claim 1 further comprising a second node, each node having at least one associated telephone characterized by address information, wherein at least one interval within each frame is designated a signalling packet interval, a plurality of time slots within each frame are designated voice time slots and pairs of VTS's in each cycle define a voice circuit wherelh the first node includes: means for receiving signals from its associated telephone indicating an off-hook condition and a combination of keystrokes indicating a call to be placed to a second S node; and .S means for claiming a first VTS of an unused VC; means for transmitting a Call Request SP to the second node when the first VTS is successfully claimed; includes: means for receiving the call Request SP; means for sending an Accept SP or a Busy SP to the first node; f' wherein the first node further includes: means for receiving the Accept SP; means for transmitting an ACK SP to the second node; and means for applying a ringback signal or a busy signal to its own associated phone; wherein the second node further includes: means for receiving the ACK SP; means for causing its own associated phone to ring, means for receiving signals'from its associated phone indicating an off-hook condition, means for claiming the second VTS of the VC; and 'means for sending an Answer SP to the first node when th, second VTS is successfully claimed; wherein the first node further includes: means for receiving the Answer SP; means for sending an ACK SP to the second node; and wherein each node further includes means for inserting voice data in their respective claimed VTS's, each node generating the voice data on the basis of signals received from its associated telephone for transmission to the other node and applying voice d~ata as received from ithe other node to its K: associated phone.

29. The communication system C-1 claim 26, wherein the means for claiming the first VTS comprises means for ascertaining the apparent availability of a particular VTS; means for transmitting a Claiming Voice Packet ("CVP") within the apparently available VTS; and means for verifying the receipt of the CVP intact to indicate the absence of collision. The comumunication system of claim 29 wherein each Ot: ode is capable of communication on any of a plurality of Sfrequency channels, and wherein '.said means for transmitting a call R~equest SP' includes means for sending a Call Request SP' on each of the, channels, specifying a sint le channel for responae.

31. The communication system of claim 28 wherein first and second frames define a cycle, each frame including an SP interval and, a plurality of VTS's, with any VC consisting of corresponding VTS's from the first and second frames.

32. The communication system of claim 1 wherein said transmitting medium and said receiving medium comprise part bf a network medium, and wherein said head-end translating means coprises: a plurality of head-end means, c )pled to one Qnd of said network medium, for receiving said information in a first frequency band and retransmitting said information in a second frequency band, said first and second frequency bands being a channel, each of said head-end means operating on a different channel; a plurality of clock generators, each coupled to a different one of said head-end means, for producing the clock signals for said head-end means; a plurality of phase lock loops, each coupled to a different one of said head-end means, for phase lock synchronizing said clock signals to a maste clock; and a plurality of digital phase lock loop means, each coupled to a different one of said head-end means, for producing a fractional offset of the bits of said information in a timeslot following one of said timing marks to synchronize said information with said clock signals. 0. couple 33. The system of claim 32 further comprising means, Scoupled to said head-end means, for examining the contents of each timeslot and inserting a bit pattern for synchronization in i the absence of said information.

34. The system of claim 32 further comprising a plurality of second phase lock loops, each coupled to a different one of said head-end means, for phase synchronizing each said clock generator to an external clock; and logic means for selecting one of the outputs of said second phase lock loops as said master clock. The system of claim 32 wherein a first or last portion of each said timeslot contains no data to allow said digital phase lock loop means to reset.

36. The communication system of claim 1, wherein said ttansmitting medium and said receiving medium comprise part of a network 'medium, and wherein said head-end translating means comprises: a plurality of head-and means, coupled to one and of said network medium, for receiving said information in a first frequency band and retransmitting said information in a second frequency band, said first and second frequency bands being a channel, each of said head-end means operating on a different channel; diffrenta plurality of clock generators, each coupled to a sigfnal one of said head-end means, for producing the clock aplurality of ,*hasa lock loops, each coupled to a toI different one of said head-end moans# for phase lock synchronizing said clock signals to a matter clock; a plurality of digital phase. lock loop means# each coupled to a different on* df said head-end means, for producing 4 fractional of fset of the bits of said information in a timeslot :*oo following aoe of said timing marks to synchronize said information with said clock signals; 99 mtans, coupled to said head-*nd means, for examining the contents~ of each timaslot and inserting a bit pattern for aynchronitation in the absence of said message;, a plurality of second phase lock loops, each coupled to a different one of said head-end means, for phase synchronizing each said clock generator to an external clock; 'logic means for selecting one of the outputs of said second phase lock loops as said master clock; and wherein a first or last portion of each said timeslot contains no data to allow said digital phase lock loop means to reset.

37. The system of claim 36 wherein said digital phase lock loop means comprises: a shift register having a data input coupled to receive said received information and a clock input coupled to a head-end clock having a frequency at least four times the frequency of said received data; and means for selecting an output of said shift register corresponding to a minimum phase difference between said received data and said head-end clock.

38. The communication system of claim 1 wherein said 2: transmitting medium and said receiving medium comprise part of a network medium, and wherein said head-end translating means further comprises: a plurality of head-end units, each of said head-end unitj having a receiver for receiving transmissions from said medium at a first frequency and converting said transmissions to a second frequency in a transmitter for transmission back over said mediuml oef a plurality of interface circuits, each for coupling uson& o said head-end units to a multiple timeslot full-duplax i: bus; a data buffer for coupling said full-duplex bus to a trunk bus; a trunk address decoder and buffer for providing addresses to said trunk bus; 286 a processor for providing control signals to said interface circuits and address decoder and buff er; and a phase lock loop circuit for synchronizing a local clock to a clock signal received from at least one of said head-end units. Dated this 23rd clay March 1993 FIRST PACIFIC NET~ORXS, INC. By their Patent Attorney GRIFFITh HACK ~j Co. S #4 S S S I S S I, S *1 I, S 9 4- 9 S I S S I 9 4* 9 SO S. SW S S S 4 5** S St S S S S~ S S. a A 'S 4,