AU747498B2 - Trunk management system for telecommunications - Google Patents

Description

WO 99/62235 PCT/AU99/00414

I

TITLE: TRUNK MANAGEMENT SYSTEM FOR TELECOMMUNICATIONS FIELD OF INVENTION This invention relates to systems for managing telecommunications links and, more particularly, to apparatus, systems and methods for remotely controlling or monitoring the stations of a communications link using digital service channel(s) provided by the link itself. While the invention is particularly suited for use in terrestrial digital microwave systems, it is also applicable to digital trunk cable and even to some satellite communications systems.

The digital communications links with which this invention is concerned are typically high capacity and heavily multiplexed but are able to 'break-out' limited capacity service channel(s) without having to demultiplex the 'payload' traffic. For convenience, such sophisticated telecommunications links are herein called'trunks', irrespective of the character, source and destination of the traffic. The service channel or channels are used for link management, monitoring and servicing and normally comprise at least one full-duplex 64kb/s synchronous communications channel in each direction that is accessible by each station in the trunk. The service channel is usually accessed at each station by demodulating a carrier signal to the base or frame level where the inter-frame bits that comprise the service channels can be read. The frames carry the payload traffic in heavily multiplexed form and need not be demultiplexed to access the service channels. Normally, each trunk will comprise at least three stations; namely, two end stations and at least one intermediate relay or repeater station, the end station which is connected to a network control centre or a trunk controller being called the 'head' while the other end station is called the 'tail'. An intermediate station is said to be 'down' or'down-link' from the head and 'up' or'up-link' from the tail.

BACKGROUND TO THE INVENTION The manufacturers or vendors of equipment for telecommunications trunks employ their own proprietary point-to-point protocols on the trunk service channels so that vendor's equipment at a trunk controller can monitor and/or control the individual stations in a trunk using proprietary synchronous transport protocols. Generally, each WO 99/62235 PCT/AU99/00414 2 manufacturer or vendor offers its own proprietary system with its own specialised hardware that is incompatible with the monitoring and control systems of other vendors. There is even inconsistency as to where and how the clock signals are generated and transported in the service channel.

Some of the resulting problems are: Current trunk management systems often employ point-to-point communications protocols that allow the control centre to poll individual stations for data, but do not allow ready communication of management and/or control information between any two or more stations in a trunk using the service channel, thus making servicing by field engineers difficult.

Current trunk management systems cannot be readily re-configured to change the head station to the tail station or to a repeater station; certainly not in a dynamic fashion to by-pass a serious fault in the link 0 Since service channel capacity is easily overloaded in the event of fault avalanches caused by lost frames or the like, the causes and nature of such avalanches is most difficult to assess.

a It is difficult to integrate the inputs and outputs of the trunks of different vendors at a single control centre.

9 Monitoring and control functions that are additional or alternative to those provided by the vendor's system are difficult to implement for any one trunk (especially where the number of service channels is limited) and, if such an alternative or additional monitoring/control system is devised, it usually cannot be applied to the trunks of other vendors.

e The system manager is seldom licensed by the vendor of a trunk management system to modify the hat i.ware or software of that system.

9 Staff must be trained to understand the details of each trunk management system, both hardware and software, employed by the operator and separate spares must be kept and maintained for each system.

e Due to the high development cost and small market for each proprietary trunk management system, its cost is substantially higher than any mass-produced computer system of comparable complexity and function.

WO 99/62235 PCT/AU99/00414 3 SThe above difficulties inhibit system operators from contracting new vendors to install new trunks in a system, thereby facing a price and/or performance penalty.

OBJECTIVES OF THE INVENTION Accordingly, it is the general objective of the invention to provide means for assisting the monitoring or control of trunk communications systems, links and/or stations by using the digital service channels provided on such trunks. Alternatively or additionally, it is an object of the present invention to mitigate one or more of the above-mentioned difficulties with the systems, trunks or links of the art.

OUTLINE OF THE INVENTION This invention is based on the realisation that it is possible to efficiently implement Intemrnet Protocol (IP) in a multi-drop manner on a typical digital service channel of a telecommunications trunk, despite its limited capacity and normal synchronous partyline character. Hitherto, this has been impractical or impossible because IP requires each packet to be fully buffered at each intermediate station before it can be forwarded on the service channel. If long IP packets are passed from station to station on what is effectively a party-line in this way, delays can be expected quickly compound to such a degree that effective communications on a trunk service channel is impractical. As far as the applicant is aware, no prior art system has enabled an IP host to communicate using IP with the stations of a trunk via the digital service channel.

From one aspect, therefore, the present invention comprises a telecommunications trunk or service channel capable of transporting IP packets so that communication between stations, and between stations and the controller, can take place in a transparent manner using IP with such higher level IP-compatible protocols (for example, UDP, TCP, HTTP or SNMP) as desired. From this aspect, the invention also comprises means for effecting the transport of IP packets on the service channel of a telecommunications trunk in such a manner as to permit both the trunk controller and individual stations of the trunk to operate using IP.

WO 99/62235 PCT/AU99/00414 4 This desirable result may be achieved by treating the stations of a trunk collectively as a single IP subnet by employing the head station as a transparent router to encapsulate and re-address incoming IP packets in the form of 'service packets' that have short non-IP addresses corresponding to the trunk stations, so that each station can read the address of a service packet using low-level processes without needing to to buffer the whole packet. Each station preferably has a computer-based remote site controller (RSC) that runs IP and extracts the IP packets from incoming service packets addressed to it, and processes the received IP packets appropriately. Moreover, it is desirable that each RSC is able to generate it own IP packets containing data for other stations or for the wider network, and to encapsulate each in a service packet that is addressed appropriately for transport on the service channel.

If each service packet has a short station address located at a fixed position at or near the start of the service packet, the station address can be read after only a small portion of the packet has been received at an RSC, so the packet can be immediately forwarded (unless addressed to the RSC in question). However, it is desirable for each RSC to be able to buffer an entire incoming packet in the event that it is transmitting a self-generated service packet when another service packet is being delivered from the service channel. This is also an advantage in the handling of broadcast service packets where they must be copied into a buffer for local processing and passed back onto the service channel without delay by every station's RSC on the service channel.

However, only the head station RSC needs to routinely receive the whole of each incoming packet, whether it is an IP packet from the control centre or a service packet from the service channel. The head station needs to buffer each incoming IP packet while its address is read and the service packet vehicle is constructed. It also needs to buffer the whole of each service packet to allow the IP packet therein to be recovered and forwarded to the controller, or dealt with within the head RSC if addressed to it.

Since the controller and the head RSC normally will be on a common LAN, the speed of exchange of IP packets between the controller and the head RSC need not be of concern.

WO 99/62235 PCT/AU99/00414 Thus it will be evident that the head station RSC acts as a transparent IP router for the controller or a host at the control centre acting like an IP server with no knowledge of or concern with the structure of service packets or the protocol by which they are transported on the service channel. From the standpoint of the wider Internet, therefore, the trunk stations appear as normal IP addresses, which are accessible from anywhere on the Intemrnet, subject to appropriate firewall and other security measures imposed by the control centre LAN. Known proprietary network management systems (eg, Cabletron's SPECTRUM, Hewlett Packard's OPEN VIEW, Sun's SUNET MANAGER, or IBM's NET VIEW) can thus be installed on one or more terminals on the control centre LAN for the management of one or more trunks using IP in a completely transparent manner.

A simple and effective system of assigning Internet addresses to the stations of a trunk is to ensure that the IP addresses for the stations on a trunk differ only in only their least significant address digit(s) or byte(s) and to ensure that the stations are numbered in ascending order down the chain, with the head station assigned the lowest station address. [The lowest and highest possible station addresses say, 00 and FF are generally reserved as network and broadcast addresses.] When the head station receives an IP packet from the controller having the IP address of another station on the service channel, the head station RSC simply copies the last byte of the IP address into the appropriate place in a service packet header formed to carry the IP packet. If the incoming IP packet is addressed to the head station itself, its RSC immediately processes the packet within its own IP regime.

Every station on the service channel runs IP to process IP packets that it receives and to generate IP packets for transmission to other stations or to the controller for action or further routing. The RSC at each station encases each IP packet it generates within a service packet that it creates, addresses and puts on the service channel. Those service packets intended for other stations on the service channel preferably use the last byte of the destination station's IP address to address the service packet in the manner already indicated. Service packets containing IP packets that are not intended for another station are, by default, given the service channel address of the head station. Any station receiving a service packet with its own address, takes the whole WO 99/62235 PCT/AU99/00414 6 service packet off the service channel, extracts the IP packet and handles it using the appropriate higher level protocols (eg, SNMP/UDP) in the IP environment of its RSC.

However, in the case of the head station, most of the incoming service packets with its address will contain IP packets having addresses outside the service channel network and these IP packets will therefore be passed on to the controller for appropriate routing or processing.

If the addresses of stations along a trunk are allocated sequentially from the head (as indicated above), low-level routing means can be employed by the RSC at each station to determine whether a self-generated service packet should be placed on the up-link or on the down-link by comparing the service address of the packet with that of the station at which it is generated. Incoming packets from other stations on the service channel can thus be assumed to be intended for down-line stations with higher addresses and are forwarded accordingly. It is preferred that each RSC employs software daisy-chaining techniques to couple to the service channel to avoid delays due to differences in receiver and transmitter data rates or clock phase between RSCs.

While the above-indicated method of addressing service packets is preferred for its simplicity, the more normal methods used in IP networks based on the use of router tables to correlate IP and service channel addresses is also envisaged.

Each station RSC can communicate with on-site station elements such as RS232 devices, SCADA data recording systems, switches, intruder alarms, battery monitors, performance monitoring systems, digital and analogue I/Os (input/outputs) and, particularly, transceiver and data transport alarm events. A computer terminal, for example, might be connected to an RSC by a technician using a standard serial or parallel interface for communication with another technician at another RSC (or anywhere on the larger network). In addition, communication with legacy vendorspecific devices at the station and control centre can be handled in the same manner, if necessary by encapsulating vendor-format packets in IP packets. All data delivered, collected or generated in this way at the RSC being mediated by IP packets in an IP environment, but are carried on the service channel in service packets composed and addressed as indicated above. IP packets containing vendor-specific data received by WO 99/62235 PCT/AU99/00414 7 the controller can be directed to the vendor's management or control devices. In this way, legacy and new monitoring/management equipment can operate side by side using the one service channel while having the benefits of IP at the control centre and each RSC.

As taught in our copending Australian patent application No. 42911/97, the accurate time stamping of recorded alarm events in remote stations of a large telecommunications network according to a universal time reference is of great importance in the analysis of alarm 'storms' or'avalanches'. It is desirable for this purpose to time-stamp alarm events to microsecond accuracy and consistency across the whole trunk system. Accordingly, not only can all alarm (and other significant) data logged at a remote station be time-stamped in this manner but, according to the present invention, means can be employed to identify bunches or storms of alarms as they occur on a trunk A simple way of doing this is to regard all alarms occurring within a few seconds of another alarm as being members of a bunch or storm of alarms that are likely to have the same primary cause. This permits the use of a default mode for reporting alarms from a station in which only the first alarm of a bunch or storm is reported to the centre (with, perhaps, an indication of the number of alarms in the associated bunch or storm). This default procedure can reduce the load on the service channel manyfold in alarm situations where faults are intermittent or propagated along the stations of a trunk. However, upon a request from the centre, all alarms in a storm recorded by any station can be transmitted to the centre for analysis.

As an alternative to vendor-specific data logging and control systems, it may be convenient to employ MIBs (management information bases) to represent a station's status and control parameters in a structured manner and SNMP (simple network management protocol) be used at the transport layer within the IP region of the RSC.

MIBs and SNMP have been defined in standards such as RFC1213, RFC1155 or RFC1 157. Thus, communication between the network or trunk centre and a station's RSC will normally be by way of standard SNMP Get requests, SNMP Set responses and SNMP Traps. Each RSC may also monitor the value of MIB parameters and other measurable values, including the RSC's own state and originate SNMP Trap packets WO 99/62235 PCT/AU99/00414 8 under various sensed conditions. For example, the first alarm event of an alarm bunch may be communicated automatically in this manner.

DESCRIPTION OF AN EXAMPLE Having broadly portrayed the nature of the present invention, an example will now be described with reference to the accompanying drawings by way of illustration only.

Brief Description of the Drawings Figure 1 is a diagram showing three stations of a generic digital microwave communications trunk of known form.

Figure 2 is a schematic illustration of a system of the present invention the allowing a remote site controller at any trunk station to communicate with a communications control centre as if it is part of an IP network.

Figure 3 is a diagram illustrating the manner in which vendor packets, IP packets and service channel packets are handled in the chosen example Figure 4 is a more detailed block diagram of a trunk station employed in the network of Figure 2.

The digital microwave communications system 10 of Figure 1 is employed as a trunk connection between one telephone region 12 and another 4 and represents systems in common use. System 10 comprises a chain of repeater stations 16R arranged between a head station 16H in region 12 and a tail station 16T in region 14, only one repeater station being depicted for the sake of clarity. Head station 16H includes a calltraffic input down-line multiplexer 18 that multiplexes incoming call/data lines 20 into a stream 22 of T1 frames (for example); an output down-line multiplexer 24 that adds a 64kb/s down-line service channel 26D to stream 22 by utilising inter-frame gaps; a down-line microwave modulator and transmitter 28 that generates microwave beam 29; an up-line microwave receiver and demodulator 30 that takes incoming radio traffic from region 14 on microwave beam 32, demodulates it and passes the demodulated signal to an up-line input demultiplexer 34 which generates a stream of frames 36 and breaks out the up-line (return) service channel 26U; an up-line output demultiplexer 38 that generates an outgoing group of call/data lines 40 to region 12; a service channel WO 99/62235 PCT/AU99/00414 9 interface unit 42H that is connected to receive alarm signals from and send control signals to I/O (input/output) devices (eg data-loggers and controllers) 44. Since this is the head station, the service channel input 26D is derived from a trunk controller 46 (rather than from an up-line station) and the service channel output 26U is fed through interface 42H to controller 46 (rather than to an up-line station).

Repeater station 16 has a down-line receiver 50 that converts beam 29 into a demodulated signal that is fed to an input down-line demultiplexer 52, which generates frame stream 22, breaks out down-line service channel 26D and feds it to service interface 42R. Outgoing down-line service channel 26D is then added to frame stream 22 by down-line mulitplexer 24H, which feeds the combined multiplexed signal to down-line transmitter 28H that regenerates beam 29. Up-going beam 32 from region 14 is received at repeater station 16R by up-line receiver/demodulator 30R and the demodulated signal is passed to a demultiplexer 34R that breaks out up-line service channel 26U and passes up-line frame stream 36 to a multiplexer 38R that recombines frame-stream 36 with service channel 26U and feeds it to an output up-line modulator/transmitter 54, which regenerates up-beam 32. Like head station 16H, repeater station 16R includes a service channel interface unit 42R through which down-line service channel 26D and up-line service channel 26U are fed, interface also having I/O circuits 44R connected to monitor and control elements of the repeater station 16R.

It will be seen that tail station 16T is essentially a mirror image of head station 16H. An input receiver demodulator 50T receives incoming beam 29 and its demodulated output is fed to demultiplexer 52T that generates frame-stream 22 and breaks out down-line service channel 26D. Frame stream 22 is demultiplexed to line level and output as a group of lines 60 into region 14, while a group of incoming lines 62 from region 14 is combined into up-going frame stream 36 by multiplexer 34T. Up-line output multiplexer 38R then combines service channel 26U with frame-stream 36 and feed the combined signal to up-line output modulator/transmitter 54T to generate upgoing microwave beam 32. Again, tail station 16T is fitted with a service channel interface unit 42T that takes down-going service channel 26D as an input and generates up-going service channel 26U as an output. Interface 42T is again WO 99/62235 PCT/AU99/00414 connected to I/O circuits 44R that are connected to monitor and/or control the operation of the station.

Station interface units 42, controller 46 and often I/O units 44 are usually vendorspecific so that they are expensive and usually cannot be modified to take new inputs or effect new controls. The packet protocols and coding employed are proprietary and designed to allow the data from stations to be collected in a polling (point-to-point) sequence. They are therefore poorly adapted for (and in many cases not capable of) use in communicating from one station to the next, or even from one station to the controller. Generally such communication depends upon the availability of additional party-line type service channels capable of transmitting voice or modem signals.

Figure 2 is a functional schematic representation of an IP compatible trunk management system 50 formed in accordance with this invention wherein the control centre 52 comprises a local Ethernet LAN 54, with operator terminals 56, that communicates via an Intemrnet host system server 58 with remote site controllers (RSCs) at each trunk station using the trunk service channel. In Figure 2, host 58 is connected via the Intemrnet 60 to RSC 62 at the head station (not indicated) of the trunk (not indicated). Head RSC 62 is connected by the trunk service channel 64 to all stations, including in particular remote station 66 having remote RSC 68 which is connected to monitor various parameters at station 66. RSC 68 is supplied with vendor-format data from a legacy vendor interface 70. Altematively, device 70 may be a generic SCADA or data-logger device. In addition, RSC 68 is connected to receive other direct inputs, including analogue signals for battery voltages 71 and temperatures 72, and digital signals from security devices 73 and transceiver alarm lines 74. A field terminal 75 may also be connected to RSC 68 (via a RS232 connection, for example) so that it can be used by a service technician to communicate with any other trunk station, with control centre 52, or even with any other suitable device on the Intemrnet.

It is preferable that all data inputs are time-stamped especially the transceiver alarms 74 where timing is critical to diagnosis. Such alarms may be triggered by faulty fibres and cables or their connections, by lost frames due to multi-path fading in microwave WO 99/62235 PCT/AU99/00414 11 trunks or by system control faults, and their time stamping can be effected with the minimum of delay using RSC 68 and a GPS-dlerived clock 76 that is also connected directly to the RSC 68. In particular, it is desirable that transceiver alarm storms are identified and appropriately recorded so that the first alarm of each storm can be accessed by the RSC 68 for transmission to the control centre upon the receipt by the RSC of the appropriate interrogation IP packet from the control centre. This can save a great deal of unnecessary traffic on the service channel, as well as facilitate alarm analysis.

Figure 3 is a diagram illustrating the manner in which the transmission of information from the control centre 52 to the remote trunk station 66 in Figure 2 is handled in various digital packets. The transmission of data from station 66 to centre 52 typically involves the reverse procedure, except for a variation in the addressing of service packets, which will be explained below. In Figure 3 it is assumed that legacy vendor's equipment is installed at the control centre 52 and in station 66. If such legacy equipment is not present the additional steps of handling the vendor's packets or data at each end of the process are not required.

Non-IP format data from vendor control equipment (46 in Figure 1) at centre 52 (Figure 2) intended for vendor equipment (79 in Figure 2 or 42 in Figure 1) is packetised at centre 52 to generate a vendor packet 80 that is encapsulated in an IP packet 82 by host server 58. IP packet 82 is addressed to RSC 68 using normal IP procedures and routed to the head RSC 62. Preferably, all stations on the trunk are given consecutive addresses ascending from that of the head station to that of the tail station, the station number being indicated by the last significant byte of the IP address. In Figure 3, this byte is indicated at 84 in packet 82. Head RSC 62 receives packet 82 and examines its IP address. Since the packet 82 is not addressed to its own IP address, RSC 62 adds a head and tail to packet 82 to create a service packet 85 in HDLC format that 'encapsulates' IP packet 82. RSC 62 copies address byte 84 of IP packet 82 into the beginning of the head of service packet 85 where it is located either at the start of the packet or at a fixed number of bytes from the start of the packet This copied byte now forms the address 86 of the service packet 85 and is the address of remote RSC 68.

WO 99/62235 PCT/AU99/00414 12 Head RSC then places service packet 85 on the down-line of the service channel 64 (see Figure 2) on which it is fed past each station RSC inturn. At each station, address 86 is examined and the packet 85 is immediately passed down-line without any significant delay in each successive station, until station 66 with RSC 68 is reached.

Since address 86 matches that of RSC 68, the service packet 85 is taken off the service line and the head and tail of packet 85 are removed by RSC 68 to 'unpack' IP packet 82. RSC 68 then processes packet 82 in an IP environment. It is likely that packet 82 will have a flag that is set to indicate that the pay-load data contained by the packet is intended for the vendor-specific device 70 at station 66. Accordingly, vendor data packet 80 is delivered to device 70 for processing in accordance with the vendor's programs. Though the service channel 64 is not an IP environment, IP packets can be conveyed transparently to and from the IP environment of host 58 and the IP environment of the RSC in any trunk station, with minimal delay and complication.

Figure 4 illustrates in diagrammatic form the microwave station 66 of Figure 2 and its RSC 68 which includes a VMEBus board 90 with a CPU 92 and various I/O ports, including an IP Ethernet port 94 that can optionally be connected to controller 58 if RSC 68 is reconfigured as the head RSC. Station 66 includes up-side and down-side microwave transceiver units 100 and 102. Up-side transceiver unit 100 includes microwave transmitter 104 and receiver 106, while down-side transceiver unit 102 includes receiver 108 and transmitter 110. Down service channel 112 connects receiver 106 to transmitter 110 via RSC 68, while up service channel 114 connects receiver 108 to transmitter 104 via the RSC. Normal serial RS232 connections could be used. A monitoring and control unit 116 in up-side transceiver unit 100 is connected to an I/O port 118 on RSC 68, while a similar monitoring and control unit 120 in downside transceiver unit 102 is connected to another I/O port 122 on RSC 68. For the sake of clarity, the main payload traffic connections between transceiver units 100 and 102 are not illustrated.

The number, type and use of the I/O ports 118 and 122 depends on the manner in which the station's trunk management systems monitoring and control units 116 and 120 and radio status and control electronics are implemented. For the purpose of this example, it may be assumed that the various inputs alarms and controls illustrated or Substitute Sheet (Rule 26) RO/AU WO 99/62235 PCT/AU99/00414 13 mentioned in respect of station 66 in Figure 2 can be incorporated in monitor units 116 and 120, including GPS clock inputs. Alternatively, an MIB may be implemented on a second computer (not shown) in station 66 and connected to the RSC 68 through the I/O port 118 and/or 122 to allow communication of SNMP packets between the second computer and the RSC 68, all analogue and digital inputs, alarms and clocks being handled by the second computer. Alternatively, an MIB can be implemented within the RSC 68.

Within RSC 68, HDLC service packets arriving on down-link service channel 112 from up-side receiver 106 are fed via a short FIFO down-buffer 124 and a down by-pass switch 128 to down-side transmitter 110. FIFO 124 is connected to CPU 92 via port 126 and line 123 so that the address of a service packet therein can be read. Packets emerging from FIFO 124 on line 112 can be received by port 125 via line 127.

Similarly, HDLC packets arriving on up-channel 114 are fed via a FIFO 130 (which is connected to CPU port 131 via line 129) and via up bypass switch 132 to up-side transmitter 104; and, packets emerging from FIFO 130 on line 114 can be received by input port 134 via line 136. Down bypass switch 128 is controlled by output port 138 and line 139 so that either line 112 is connected to transmitter 110 or an output line 140 from an output port 142 on card 90 is connected to transmitter 110. Similarly, up bypass switch 132 is controlled via line 133 by output port 144 of card 90 so the either line 114 or an output line 146 from an output port 148 is connected to up-side transmitter 104.

The operation of down FIFO 124 and associated by-pass switch 128 will now be explained, it being understood that the operation of up FIFO 130 and associated switch 132 is essentially the same. A service packet arriving at FIFO 124 is automatically stepped through the buffer. At the appropriate time and position in buffer 124 the service address byte of the packet header in the buffer is read by control port 126. If the service packet has the address of this particular station 66, by-pass switch 128 connects down transmitter 110 to output line 140 and the packet is taken off line 112 (as it emerges from FIFO 124) by port 125 for processing by CPU 92 in the manner described above with respect to Figure 3. If the packet is not addressed to this station but bypass switch 128 is open, the packet is also taken off line 112 by line 127 and Substitute Sheet (Rule 26) RO/AU WO 99/62235 PCT/AU99/00414 14 port 125 but it is not processed by RSC 68 but is merely temporarily buffered thereby.

The reason why bypass switch 128 might be open (ie; why transmitter 110 might be connected to output line 140 from output port 142) is that RSC 68 was in the process of transmitting a service packet itself to transmitter 110. As soon as such transmission is completed, switch 128 can be returned to its normal by-pass position (as shown).

It will be noted that, when RSC 68 has a service packet to transmit, it will have the choice of passing it to uplink transmitter 104 or downlink transmitter 110. The choice is made by comparing the destination address of the service packet with that of its own station. If the packet address is higher, it should be placed on the downlink transmitter 110; if lower, it should be placed on the uplink transmitter 104. Use of the switches 128 and 132, together with the ability to buffer packets waiting for transmission allows two or more RSCs to simultaneously transmit without interference.

It is preferred that all RSCs installed on the service channel 64 are substantially similar in hardware and software. It is also preferred, that each RSC is symmetric with respect to the downstream and upstream; that is each RSC can receive service packets addressed to it on either the downstream and upstream and that each RSC can transmit service packets addressed to any other station on either the downstream and the upstream. This symmetry is useful, for example, where the usual tail station is used as the head station, or where a repeater station is to be used as a head station or a back-to-back head station. Thus, it is desirable that each RSC includes means for communicating via an IP LAN to a controller using IP packets.

It will be appreciated by those skilled in the art that the functions of the buffers, switches, ports and other elements of the Figures described can be implemented in software and need not be implemented as identifiable hardware elements. An outline of one possible software implementation is provided below.

Substitute Sheet (Rule 26) RO/AU WO 99/62235 PCT/AU99/00414 Indicative Software Summary 1 Initialise two synchronous serial ports in HDLC mode. One for upstream, one for downstream. Where clocks come and go from for the 4 possible serial streams (RX1,TX1,RX2,TX2) is configured.

2 The HDLC particulars are 16bit CCITT-CRC. HDLC SYNC Flag 7E. One Byte addressing (source destination). Two byte length field.

3 Setup buffers for DMA transfer of packets (uses the Motorola communications RISC controller to do most of the work).

4 Set up as a TCP/IP network interface. It handles its own hardware addressing (ie. Does not use broadcast RARP like Ethernet). Allow for Van Jacobson TCP header compression on TCP packets.

When the Local interface (the RSC) wants to send an IP packet out on the service channel network interface (as determined by IP routing tables): a) it reserves descriptors pointing to the packet and its encapsulating service packet header.

b) if the least significant byte of the destination IP address is less than the RSC's station address the service packet needs to be sent on the upstream port c) if more then downstream d) if same then return back to IP layer (local echo) e) if 255 then network broadcast so send both upstream downstream.

f) Perform any header compression if required g) automatic packet transmission via DMA and RISC h) handle transmit errors WO 99/62235 PCT/AU99/00414 16 6 When an Upstream receive interrupt occurs; a) If a header has been received determine if the packet is destined for furthur downstream or local (see above) b) If due for downstream start packet transmission downstream immediately, and also queue further packet components for downstream.

Pass through managed using DMA and RISC controller.

c) If due for local RSC wait till all packet components received and queue to IP layer d) If broadcast address 255 queue downstream and make a copy for the local RSC.

e) The Length in the HDLC header allows the rest of the packet to be received (and sent) mostly via DMA.

7 When a Downstream receive interrupt occurs behave exactly as per upstream, but in the opposite direction.

8 Packets due for upstream arriving from upstream are dumped. Similar for downstream.

9 If any packets due for local do not contain a recognisable IP packet then dump them.

Update all MIB-II statistics for this network interface layer as required. (Octet counts, Error counts, etc.) 11 Implement control on network interface by MIB-II calls. (Change of IP address etc.)

Claims (9)

1. A digital telecommunications trunk system comprising a series of stations including a head station a tail station and at least one intermediate repeater station for conveying multiplexed payload traffic from station to station therealong and for also conveying with the payload traffic a digital service channel from station to station therealong in such a manner that the service channel is accessible at each station for management and service purposes, the service channel being connected to a management or control centre for remotely monitoring and/or controlling station faults and/or conditions, the trunk being characterised in that: the centre and each station run Intemrnet packet transport protocol and communication between stations and between the centre and stations is effected on the service channel by the exchange of IP packets in a multi-drop network wherein each station is assigned a unique IP address.

2. In a digital telecommunications trunk system comprising a series of stations including a head station a tail station and at least one intermediate repeater station for conveying multiplexed payload traffic from station to station therealong, a digital service channel conveyed from station to station with the payload traffic so as to be accessible at each station for communication with a control centre connected to the head station for management, control and/or service purposes, the control centre being adapted to run Intemrnet packet transport protocol and the use of (IP) at each station so that communication between stations and between the centre and stations is effected on the service channel by the exchange of IP packets in a multi-drop network wherein each station is assigned a unique IP address.

3. A digital service channel system for interconnecting of the stations of a digital telecommunications trunk for remote monitoring and/or control purposes, the stations of the trunk including a head station and at least one repeater station and the system being characterised by the use of an internet packet transport protocol (IP) for communication between stations of the trunk in a network in which each station has its own IP address. WO 99/62235 PCT/AU99/00414 18

4. A system according to any preceding claim wherein: before each IP packet is transmitted on the service channel, it is enclosed in a service packet having a header which precedes the IP packet onto the service channel, said header including a short non-IP format service address code signifying the destination station for which the service packet is intended, said code being located at the start -of said header, or near the start of the header at predetermined number of bits therefrom, each station includes a computer-based remote site controller (RSC) adapted to receive each incoming service packet and to read its service address code using low-level means while the packet is in transit through the RSC without either having to buffer the entire packet before retransmitting it or having to interpret any part of the IP packet enclosed within the service packet, and each station RSC is adapted to remove the header from each service packet received thereby that has the service address of that station and to process internally the enclosed IP packet. A system according to claim 4 wherein: said head station RSC is adapted to communicate with a control centre using IP and each repeater station RSC is adapted to insert the service address code of the head station in the header of each service packet originated by said repeater station in each case where said service packet encloses an IP packet having an IP address that does not correspond to the IP address of any station connected to the service channel, said head station RSC is adapted to remove the header from each service packet received thereby, to inspect the address of the enclosed IP packet and to forward IP packets received from the service channel to the control centre in the case that the IP packets have IP addresses that do not correspond to the IP address of any station connected to the service channel, and said head station RSC is adapted to process internally any received IP packet bearing the IP address of the head station.

WO 99/62235 PCT/AU99/00414 19

6. A system according to claim 4 or 5 wherein the service packet address of a service packet, which encloses an IP packet that has the IP address of a station on the service channel, comprises the least significant byte, or portion of the least significant byte of said IP address.

7. A system according to any one of claims 4-6 wherein: the service channel includes a up-channel for carrying data in one direction along the stations of the trunk and a down-channel for carrying data in the opposite direction along the stations of the trunk, service packet station addresses are allocated to stations in ascending order from one end of the trunk to the other along the up-channel, the RSC of each station except the head station includes means adapted to compare the destination address of a service packet generated by said RSC with said RSC's own station address, and includes means adapted to direct said generated service packet onto the up-channel if said destination address is higher than said own address and to direct said generated service packet onto the down-channel if said destination address is lower than said own address.

8. A system according to any preceding claim wherein at least one of the stations on the service channel includes means for monitoring and recording alarms occurring within the respective station, the system including: means for time-stamping each alarm event so that the time at which each alarm occurred is recorded together with the nature of the alarm, and means for identifying alarms bunches, each alarm bunch comprising a series of alarms that occur in close time proximity to one another, whereby data concerning the first alarm event of each alarm bunch can be included in an IP packet and forwarded to the control centre upon receipt of an interrogation packet requesting said data.

9. A computer-based remote site controller (RSC) for use in controlling and/or monitoring a station of a telecommunications trunk having a digital service channel interconnecting a plurality of trunk stations, the RSC comprising: WO 99/62235 PCT/AU99/00414 means for generating or accepting IP packets for transmission on the service channel, means for adding a header to each of said IP packets including a short service channel or station address, means for examining the service channel address of each service packet received by the RSC, for passing service packets onto the service channel that are not addressed to said RSC, and for removing the header of those service packets that are addressed to said RSC so as to extract or expose the IP packet, and means running IP for processing received IP packets and for generating new IP packets for transmission on said service channel network.