WO1999016260A1

WO1999016260A1 - A call routing system for routing calls to or from subscriber terminals

Info

Publication number: WO1999016260A1
Application number: PCT/GB1998/002888
Authority: WO
Inventors: Jonathan Andrew Thompson; Gavin John Meakes; Richard Mortimer Lamkin
Original assignee: Airspan Communications Corporation
Priority date: 1997-09-25
Filing date: 1998-09-24
Publication date: 1999-04-01
Also published as: AU9177098A; GB9720463D0; GB2329791A

Abstract

The present invention provides a call routing system for routing calls to or from subscriber terminal (ST) lines in a telecommunications system. The call routing system comprises a first storage (520) having type records (522), each type record identifying attributes of a type of subscriber terminal, a second storage (510) having line records (524), each line record identifying information about a line supported by a subscriber terminal of the telecommunications system, and a third storage (500) having ST records (505), each ST record relating to a subscriber terminal within the telecommunications system. Each ST record contains a first pointer (514) to a type record in the first storage identifying the type of that subscriber terminal, and a second pointer (516) to a line record in the second storage identifying a line supported by that subscriber terminal. Further, the call routing system comprises one or more call routing elements arranged to access the third storage to retrieve information about a subscriber terminal line required to route a call to or from that subscriber terminal line. Hence, the present invention provides a call routing system which contains all the necessary information about subscriber terminals, and the equipment lines connected to those subscriber terminals, to enable calls to be effectively routed to and from items of telecommunications equipment connected to those subscriber terminals, and which requires a significantly reduced memory capacity in order to perform the call routing functions.

Description

A CALL ROUTING SYSTEM FOR ROUTING CALLS TO OR FROM SUBSCRIBER TERMINALS

FIELD OF THE INVENTION The present invention relates generally to telecommunications systems, and more particularly to techniques for routing calls to or from subscriber terminals in the telecommunications system. BACKGROUND OF THE INVENTION

In a typical telecommunications system, a subscriber terminal may be located at a subscriber's premises for handling calls to and from that subscriber. One or more lines may be provided from the subscriber terminal for supporting one or more items of telecommunications equipment located at the subscriber's premises. Further, a central terminal may be provided for controlling a number of subscriber terminals, and in particular for managing calls between a subscriber terminal and other components of a telecommunications network.

As the number of users of telecommunications networks increases, so there is an ever increasing demand for such networks to be able to support more users. As techniques are developed to enable such systems to support more and more subscriber terminals, and hence more users, then it is clear that the quantity of information which must be stored about subscriber terminals in order to enable the components of the telecommunications network to effectively route calls to and from telecommunications equipment supported by those subscriber terminals also increases. It is hence desirable to reduce the amount of data that must be stored for each subscriber terminal provided within the telecommunications network. Further, the information about the subscriber terminals is typically required by a number of different components on physically separate pieces of equipment within the telecommunications network. Hence, it is often necessary for the information about the subscriber terminals to be replicated a number of times throughout the telecommunications network. This requirement to replicate the subscriber terminal information again makes it desirable to reduce the amount of information that must be stored about each subscriber terminal, thereby reducing the amount of information that must be replicated.

It is hence an object of the present invention to provide a call routing system for a telecommunications system in which the amount of subscriber terminal information which must be stored is reduced. SUMMARY OF THE INVENTION

Viewed from a first aspect, the present invention provides a call routing system for routing calls to or from subscriber terminal (ST) lines in a telecommunications system, comprising: a first storage having type records, each type record identifying attributes of a type of subscriber terminal; a second storage having line records, each line record identifying information about a line supported by a subscriber terminal of the telecommunications system; a third storage having ST records, each ST record relating to a subscriber terminal within the telecommunications system, and containing a first pointer to a type record in the first storage identifying the type of that subscriber terminal, and a second pointer to a line record in the second storage identifying a line supported by that subscriber terminal; and one or more call routing elements arranged to access the third storage to retrieve information about a subscriber terminal line required to route a call to or from that subscriber terminal line.

In accordance with the present invention, a call routing element involved in the routing of a call to or from a subscriber terminal line in a telecommunications system is arranged to access a storage containing ST records in order to retrieve information about that subscriber terminal line. A separate ST record may be provided for each subscriber terminal. However, rather than reproducing all of the relevant information directly within each ST record, the ST record includes a pointer to a type record identifying the type of the subscriber terminal, and another pointer to a line record identifying information about a line supported by that subscriber terminal. Since the type records and line records preferably contain information which may be common to more than one subscriber terminal, then the provision of pointers within each ST record to those type records and line records removes the need to reproduce that information separately for each subscriber terminal, and hence reduces the amount of subscriber terminal information that must be stored by the call routing system.

Hence, the present invention provides a call routing system which contains all the necessary information about subscriber terminals, and the equipment lines connected to those subscriber terminals, to enable calls to be effectively routed to and from items of telecommunications equipment connected to those subscriber terminals, and which requires a significantly reduced memory capacity in order to perform the call routing functions. As techniques are developed to enable telecommunications systems to support more and more subscriber terminals, then the memory requirements of the call routing system become evermore important, and so the advantages yielded by the call routing system of the present invention can be very significant.

In preferred embodiments, each line record in the second storage contains a pointer to a signalling record in a signalling storage, the signalling record identifying a signalling configuration for a class of lines. Preferably, each signalling record in the signalling storage provides a core group of signalling information that is common to a number of subscriber terminal lines. In such cases, a number of the line records will have pointers to the same signalling record, thereby saving a significant amount of storage space that would otherwise be taken up with replicating the signalling information. Further, in preferred embodiments, each line record in the second storage contains a pointer to an impedance record in an impedance storage, the impedance record identifying line impedance parameters. Again, the line impedance parameters within each impedance record are preferably common to a number of lines, and hence a number of the line records will have pointers to the same impedance record, thereby yielding further savings in storage space.

In addition, each line record in the second storage preferably contains a pointer to a number record in a priority number storage, each number record containing priority numbers for a class of lines. In systems that aim to support a large number of subscriber terminals, it is sometimes the case that a user may not always be guaranteed immediate access to the telecommunications network. In such situations, it is clearly advisable to provide a mechanism whereby certain emergency calls will be given priority over other calls. Hence, in preferred embodiments, each line can have a number of priority numbers associated with it, such that upon dialling one of those numbers, the call will be given priority over other calls. Since a number of the lines are likely to have the same core set of priority numbers, storage savings can be yielded by providing number records containing priority numbers for a class of lines, each line record then having a pointer to the number record containing the priority numbers relevant to that line.

In preferred embodiments, the second pointer in each ST record relates to a line record identifying the first line supported by that particular subscriber terminal, and the second storage is arranged such that the immediately following line records in the second storage relate to any other lines supported by that subscriber terminal. Hence, by this arrangement, the second pointer in each ST record can be used to identify the line record corresponding to the first line, and the subsequent line records can then be used to identify information about any other lines supported by the subscriber terminal. This arrangement provides further storage savings by removing the requirement to provide separate pointers to other line records.

In preferred embodiments, the call routing system further comprises an ST interface for providing a subscriber terminal with a copy of the data stored by the call routing system relating to that subscriber terminal. In preferred embodiments, the call routing system further comprises a plurality of management modules, said management modules including said one or more call routing elements, and at least two of said management modules maintaining a database comprising said first, second and third storages, the call routing system further comprising an interface mechanism for synchronising the databases maintained by said at least two management modules, the interface mechanism comprising: a first database manager for receiving information about modifications made to the database maintained by a first management module; a first communications element, responsive to the first database manager, to employ a communications protocol to send a change message to a second communications element associated with a second management module maintaining the database, the change message incorporating the modifications made to the database; a second communications element for employing the communications protocol to receive the change message and generate update information; and a second database manager for receiving the update information from the second communications element and updating the database using that update information. In preferred embodiments, the databases maintained by the management modules contain the necessary information about subscriber terminals, and the equipment lines connected to those subscriber terminals, to enable calls to be routed to and from items of telecommunications equipment connected to those subscriber terminals. Hence, the information within the databases are used to control the routing of calls by the call routing system. If a record in a database is updated, then it is desirable for a database associated with a different management module and also containing that record to be updated as well. In accordance with preferred embodiments of the present invention, this is achieved by an interface mechanism within the call routing system that employs a communications protocol to send change messages between the database managers associated with the databases.

By employing the call routing system in accordance with preferred embodiments of the present invention, a copy of the relevant subscriber terminal and subscriber terminal line information can be made from the database at the point of call instantiation, and this copy can then be used for the duration of the call. By this approach, databases can be updated whilst the call is in progress without affecting the call. Further, this approach avoids the requirement to provide specific pointers to line records within the call routing elements of the call routing system. By avoiding this requirement, the problems of having to update pointers as line records are updated is alleviated. In preferred embodiments of the present invention, the second communications element is responsive to a signal from the second database manager indicating that the database has been updated to employ the commumcations protocol to send an acknowledgement message to the first communications element. By this approach, an acknowledgement that the database has been updated is returned to the first communications element responsible for issuing the update, hence indicating to the call routing system that the necessary database synchronisation has taken place. In preferred embodiments, the first communications element includes a state machine allocated by the first commumcations element to send the change message to the second communications element. In accordance with this approach, the first communications element can allocate a separate state machine to be responsible for the transmission of a change message for each modified record. This removes the requirement for the first communications element to actually manage each database update procedure itself and hence provides improved performance. By assigning separate state machines to be responsible for each database update, a number of such updates can be managed in parallel, thereby improving the speed of the updating process, and so reducing the time taken to resynchronise the databases.

Preferably, the state machine is arranged to enter an awaiting state upon sending the change message, during which time it is not available for use by the first communications element, the state machine being arranged to exit the awaiting state upon receipt of the acknowledgement message from the second communications element, whereafter it is available for use by the first communications element. By this approach, a state machine is dedicated to a particular database update whilst that update procedure is taking place, and is then freed for subsequent use by the first communications element once that update procedure has been completed.

In preferred embodiments, one of said management modules maintaining the database is a shelf controller arranged to manage a shelf of equipment, and another management module maintaining the database is one of said call routing elements located on the shelf. In preferred embodiments, the shelf controller and the database maintained by the shelf controller can be accessed by an element manager used to manage the call routing system. Hence, the element manager may make some updates to the database maintained by the shelf controller, and then notify the shelf controller of the records that have been modified. This information is then propagated to the other management modules maintaining the database using the interface mechanism of the preferred embodiments.

In preferred embodiments, the call routing system comprises a plurality of said call routing elements, each arranged to maintain the database, the interface mechanism being arranged to synchronise the database maintained by the shelf controller with the databases maintained by the plurality of call routing elements.

Preferably, said one or more call routing elements are tributary units. However, it will be appreciated by those skilled in the art that the call routing elements need not be tributary units, and that the call routing elements can be provided by any other suitable processing units within the call routing system.

Viewed from a second aspect the present invention provides a central terminal for routing calls to or from subscriber terminal lines in a telecommunications network, comprising a call routing system in accordance with the first aspect of the present invention. Viewed from a third aspect, the present invention provides a concentrator unit for a telecommunications system, the concentrator unit comprising a call routing system in accordance with the first aspect of the present invention.

Viewed from a fourth aspect, the present invention provides a method of routing calls to or from subscriber terminal (ST) lines in a telecommunications system, comprising the steps of: (a) providing a first storage having type records, each type record identifying attributes of a type of subscriber terminal; (b) providing a second storage having line records, each line record identifying information about a line supported by a subscriber terminal of the telecommunications system; (c) providing a third storage having ST records, each ST record relating to a subscriber terminal within the telecommunications system, and containing a first pointer to a type record in the first storage identifying the type of that subscriber terminal, and a second pointer to a line record in the second storage identifying a line supported by that subscriber terminal; (d) employing one or more call routing elements to access the third storage to retrieve information about a subscriber terminal line; and (e) routing a call to or from that subscriber terminal line using the information retrieved at said step (d). BRIEF DESCRIPTION OF THE DRAWINGS

The present invention will be described further, by way of example only, with reference to a preferred embodiment thereof as illustrated in the accompanying drawings, in which:

Figure 1 is a schematic overview of an example of a wireless telecommunications system in which the present invention may be employed;

Figure 2 is a schematic illustration of an example of a subscriber terminal of the telecommunications system of Figure 1 ;

Figure 3 is a schematic illustration of an example of a central terminal of the telecommunications system of Figure 1 ;

Figure 3A is a schematic illustration of a modem shelf of a central terminal of the telecommunications system of Figure 1 ;

Figure 4 is an illustration of an example of a frequency plan for the telecommumcations system of Figure 1 ; Figure 5 is a block diagram showing elements of an access concentrator and central terminal used to manage calls to and from subscriber terminals in accordance with preferred embodiments of the present invention;

Figure 6 is an interaction diagram illustrating the communications between a modem shelf's shelf controller database manager and a modem shelf's tributary unit database manager in order to synchronise their subscriber terminal databases in accordance with preferred embodiments of the present invention;

Figure 7 is an interaction diagram illustrating the communications between a modem shelf's tributary unit database manager and a modem shelf's shelf controller database manager in order to synchronise their subscriber terminal databases in accordance with preferred embodiments of the present invention;

Figure 8 is an interaction diagram illustrating the communications between a shelf controller database manager and a tributary unit database manager within an access concentrator in order to synchronise their subscriber terminal databases in accordance with preferred embodiments of the present invention; and Figure 9 is a block diagram illustrating the structure of the subscriber terminal database in accordance with preferred embodiments of the present invention. DESCRIPTION OF PREFERRED EMBODIMENT

The present invention may be employed in any type of telecommunications system, for example a wired telecommunications system, or a wireless telecommunications system. Further, the present invention may be used in connection with any appropriate type of telecommunications signal, for example a telephone signal, a video signal, or data signals such as those used for transmitting data over the Internet, and in order to support new technologies such as broadband and video- on-demand technologies. However, for the purpose of describing a preferred embodiment of the present invention, a wireless telecommunications system will be considered that is used for handling telephony signals, such as POTS (Plain Old Telephony System) signals.

Before describing a preferred embodiment of the present invention, an example of such a wireless telecommunications system in which the present invention may be employed will first be discussed with reference to figures 1 to 4. Figure 1 is a schematic overview of an example of a wireless telecommumcations system. The telecommunications system includes one or more service areas 12, 14 and 16, each of which is served by a respective central terminal (CT) 10 which establishes a radio link with subscriber terminals (ST) 20 within the area concerned. The area which is covered by a central terminal 10 can vary. For example, in a rural area with a low density of subscribers, a service area 12 could cover an area with a radius of 15-20Km. A service area 14 in an urban environment where there is a high density of subscriber terminals 20 might only cover an area with a radius of the order of 100m. In a suburban area with an intermediate density of subscriber terminals, a service area 16 might cover an area with a radius of the order of IKm. It will be appreciated that the area covered by a particular central terminal 10 can be chosen to suit the local requirements of expected or actual subscriber density, local geographic considerations, etc, and is not limited to the examples illustrated in Figure 1. Moreover, the coverage need not be, and typically will not be circular in extent due to antenna design considerations, geographical factors, buildings and so on, which will affect the distribution of transmitted signals.

The central terminals 10 for respective service areas 12, 14, 16 can be connected to each other by means of links 13, 15 and 17 which interface, for example, with a public switched telephone network (PSTN) 18. The links can include conventional telecommunications technology using copper wires, optical fibres, satellites, microwaves, etc.

The wireless telecommunications system of Figure 1 is based on providing radio links between subscriber terminals 20 at fixed locations within a service area (e.g. , 12, 14, 16) and the central terminal 10 for that service area. These wireless radio links are established over predetermined frequency channels, a frequency channel typically consisting of one frequency for uplink signals from a subscriber terminal to the central terminal, and another frequency for downlink signals from the central terminal to the subscriber terminal.

Due to bandwidth constraints, it is not practical for each individual subscriber terminal to have its own dedicated frequency channel for communicating with a central terminal. Hence, techniques have been developed to enable data items relating to different wireless links (i.e. different ST-CT communications) to be transmitted simultaneously on the same frequency channel without interfering with each other. One such technique involves the use of a "Code Division Multiple Access" (CDMA) technique whereby a set of orthogonal codes may be applied to the data to be transmitted on a particular frequency channel, data items relating to different wireless links being combined with different orthogonal codes from the set. Signals to which an orthogonal code has been applied can be considered as being transmitted over a corresponding orthogonal channel within a particular frequency channel.

One way of operating such a wireless telecommunications system is in a fixed assignment mode, where a particular ST is directly associated with a particular orthogonal channel of a particular frequency channel. Calls to and from items of telecommunications equipment connected to that ST will always be handled by that orthogonal channel on that particular frequency channel, the orthogonal channel always being available and dedicated to that particular ST.

However, as the number of users of telecommumcations networks increases, so there is an ever increasing demand for such networks to be able to support more users. To increase the number of users that may be supported by a single central terminal, an alternative way of operating such a wireless telecommunications system is in a Demand Assignment mode, in which a larger number of STs are associated with the central terminal than the number of traffic-bearing orthogonal channels available. These orthogonal channels are then assigned to particular STs on demand as needed. This approach means that far more STs can be supported by a single central terminal than is possible in a fixed assignment mode, the exact number supported depending on the level of dial tone service that the service provider desires. In preferred embodiments of the present invention, each subscriber terminal 20 is provided with a demand-based access to its central terminal 10, so that the number of subscribers which can be serviced exceeds the number of available wireless links. Figure 2 illustrates an example of a configuration for a subscriber terminal 20 for the telecommunications system of Figure 1. Figure 2 includes a schematic representation of customer premises 22. A customer radio unit (CRU) 24 is mounted on the customer's premises. The customer radio unit 24 includes a flat panel antenna or the like 23. The customer radio unit is mounted at a location on the customer's premises, or on a mast, etc. , and in an orientation such that the flat panel antenna 23 within the customer radio unit 24 faces in the direction 26 of the central terminal 10 for the service area in which the customer radio unit 24 is located.

The customer radio unit 24 is connected via a drop line 28 to a power supply unit (PSU) 30 within the customer's premises. The power supply unit 30 is connected to the local power supply for providing power to the customer radio unit 24 and a network terminal unit (NTU) 32. The customer radio unit 24 is also connected via the power supply unit 30 to the network terminal unit 32, which in turn is connected to telecommunications equipment in the customer's premises, for example to one or more telephones 34, facsimile machines 36 and computers 38. The telecommunications equipment is represented as being within a single customer's premises. However, this need not be the case, as the subscriber terminal 20 can support multiple lines, so that several subscriber lines could be supported by a single subscriber terminal 20. The subscriber terminal 20 can also be arranged to support analogue and digital telecommunications, for example analogue communications at 16, 32 or 64kbits/sec or digital commumcations in accordance with the ISDN BRA standard.

Figure 3 is a schematic illustration of an example of a central terminal of the telecommumcations system of Figure 1. The common equipment rack 40 comprises a number of equipment shelves 42, 44, 46, including a RF Combiner and power amp shelf (RFC) 42, a Power Supply shelf (PS) 44 and a number of (in this example four) Modem Shelves (MS) 46. The RF combiner shelf 42 allows the modem shelves 46 to operate in parallel. If 'n' modem shelves are provided, then the RF combiner shelf 42 combines and amplifies the power of 'n' transmit signals, each transmit signal being from a respective one of the 'n' modem shelves, and amplifies and splits received signals 'n' way so that separate signals may be passed to the respective modem shelves. The power supply shelf 44 provides a connection to the local power supply and fusing for the various components in the common equipment rack 40. A bidirectional connection extends between the RF combiner shelf 42 and the main central terminal antenna 52, such as an omnidirectional antenna, mounted on a central terminal mast 50.

This example of a central terminal 10 is connected via a point-to-point microwave link to a location where an interface to the public switched telephone network 18, shown schematically in Figure 1 , is made. As mentioned above, other types of connections (e.g. , copper wires or optical fibres) can be used to link the central terminal 10 to the public switched telephone network 18. In this example the modem shelves are connected via lines 47 to a microwave terminal (MT) 48. A microwave link 49 extends from the microwave terminal 48 to a point-to-point microwave antenna 54 mounted on the mast 50 for a host connection to the public switched telephone network 18. A personal computer, workstation or the like can be provided as a site controller (SC) 56 for supporting the central terminal 10. The site controller 56 can be connected to each modem shelf of the central terminal 10 via, for example, RS232 connections 55. The site controller 56 can then provide support functions such as the localisation of faults, alarms and status and the configuring of the central terminal 10. A site controller 56 will typically support a single central terminal 10, although a plurality of site controllers 56 could be networked for supporting a plurality of central terminals 10.

As an alternative to the RS232 connections 55, which extend to a site controller 56, data connections such as an X.25 links 57 (shown with dashed lines in Figure 3) could instead be provided from a pad 228 to a switching node 60 of an element manager (EM) 58. An element manager 58 can support a number of distributed central terminals 10 connected by respective connections to the switching node 60. The element manager 58 enables a potentially large number (e.g., up to, or more than 1000) of central terminals 10 to be integrated into a management network. The element manager 58 is based around a powerful workstation 62 and can include a number of computer terminals 64 for network engineers and control personnel.

Figure 3 A illustrates various parts of a modem shelf 46. A transmit/ receive RF unit (RFU - for example implemented on a card in the modem shelf) 66 generates the modulated transmit RF signals at medium power levels and recovers and amplifies the baseband RF signals for the subscriber terminals. The RF unit 66 is connected to an analogue card (AN) 68 which performs A-D/D-A conversions, baseband filtering and the vector summation of 15 transmitted signals from the modem cards (MCs) 70. The analogue unit 68 is connected to a number of (typically 1-8) modem cards 70. The modem cards perform the baseband signal processing of the transmit and receive signals to/from the subscriber terminals 20. This may include 1/2 rate convolution coding and x 16 spreading with "Code Division Multiplexed Access" (CDMA) codes on the transmit signals, and synchronisation recovery, de-spreading and error correction on the receive signals. Each modem card 70 in the present example has two modems, and in preferred embodiments there are eight modem cards per shelf, and so sixteen modems per shelf. However, in order to incorporate redundancy so that a modem may be substituted in a subscriber link when a fault occurs, only 15 modems on a single modem shelf 46 are generally used. The 16th modem is then used as a spare which can be switched in if a failure of one of the other 15 modems occurs. The modem cards 70 are connected to the tributary unit (TU) 74 which terminates the connection to the host public switched telephone network 18 (e.g., via one of the lines 47) and handles the signalling of telephony information to the subscriber terminals via one of 15 of the 16 modems. Further, each modem shelf 46 includes a shelf controller 72 that is used to manage the operation of the whole of the modem shelf and its daughter network sub-elements (NSEs). The shelf controller (SC) is provided with a RS232 serial port for connection to the site controller 56 or to the pad 228. The shelf controller communicates control and data information via a backplane asynchronous bus directly with the other elements of the modem shelf. Other network sub-elements are connected via the modem cards.

The wireless telecommunications between a central terminal 10 and the subscriber terminals 20 could operate on various frequencies. Figure 4 illustrates one possible example of the frequencies which could be used. In the present example, the wireless telecommunication system is intended to operate in the 1.5-2.5GHz Band. In particular the present example is intended to operate in the Band defined by ITU-R (CCIR) Recommendation F.701 (2025-2110MHz, 2200-2290MHz) . Figure 4 illustrates the frequencies used for the uplink from the subscriber terminals 20 to the central terminal 10 and for the downlink from the central terminal 10 to the subscriber terminals 20. It will be noted that 12 uplink and 12 downlink radio channels of 3.5MHz each are provided centred about 2155MHz. The spacing between the receive and transmit channels exceeds the required minimum spacing of 70MHz.

In the present example, each modem shelf is arranged to support 1 frequency channel (i.e. one uplink frequency plus the corresponding downlink frequency), with techniques such as 'Code Division Multiplexed Access' (CDMA) being used to enable a plurality of wireless links to subscriber terminals to be simultaneously supported on a plurality of orthogonal channels within each frequency channel.

Typically, the radio traffic from a particular central terminal 10 will extend into the area covered by a neighbouring central terminal 10. To avoid, or at least to reduce interference problems caused by adjoining areas, only a limited number of the available frequencies will be used by any given central terminal 10. This is discussed in more detail in GB-A-2, 301 ,751, which also provides further details on CDMA encoding/decoding, and on the signal processing stages employed in the subscriber terminals and central terminal to manage CDMA communications between them.

The above description has provided an overview of a suitable wireless telecommunications system in which the present invention may be employed. The techniques used in preferred embodiments of the present invention to manage calls to or from subscriber terminals of the wireless telecommunications system will now be discussed.

As discussed earlier, in a Demand Assignment mode of operation, far more STs can be supported than there are traffic bearing channels to handle wireless links with those STs, the exact number supported depending on the level of dial tone service that the service provider desires.

However, the use of a Demand Assignment mode complicates the interface between the central terminal and the switch of a public switched telephone network (PSTN). On the switch side interface, the CT must provide services to the switch as though all of the subscribers are connected with direct service even though they may not be actually acquired to a radio frequency channel. Regardless of whether the ST is acquired or not to the switch, all of the subscribers must have a presence at the interface to the switch. Without some form of concentration, it is clear that a large number of interfaces to the switch would need to be provided. However, most PSTN switches still use unconcentrated interfaces, for example V5.1 or CAS, and only relatively few use concentrated interfaces, such as TR303 or V5.2.

To avoid each central terminal having to provide such a large number of interfaces to the switch, it is proposed to use an access concentrator, which transmits signals to, and receives signals from, the central terminal using concentrated interfaces, but maintains an unconcentrated interface to the switch, protocol conversion and mapping functions being employed within the access concentrator to convert signals from a concentrated format to an unconcentrated format, and vice versa. Such an access concentrator is illustrated in Figure 5, which illustrates elements of the access concentrator and central terminal used to manage calls.

It will be appreciated by those skilled in the art that, although the access concentrator 100 is illustrated in Figure 5 as a separate unit to the central terminal 10, and indeed this is the preferred implementation, it is also possible that the functions of the access concentrator could be provided within the central terminal 10 in situations where that was deemed appropriate.

As illustrated in Figure 5, the Access Concentrator 100 has a number of tributary units 110, hereafter referred to as XTUs (Exchange (facing) Tributary Units), which provide an unconcentrated interface to the switch of a telecommunications network. When an incoming call is received over path 200 from the switch of a telecommumcations network, then the XTU 110 receiving that call is arranged to determine from information associated with that incoming call which subscriber terminal line the incoming call is destined for, and to then use that information to access a database 150 associated with that XTU 110 in order to retrieve all of the necessary information about that subscriber terminal line to enable the call to be routed through the access concentrator to the central terminal and then over a wireless link to the subscriber terminal.

In preferred embodiments, the XTUs 110 are connected to the switch of the telecommumcations network via El lines. The number of El lines required will depend on the number of subscriber terminal lines supported by the wireless telecommunications system, each subscriber terminal line having a dedicated time slot on a predetermined one of the El connections.

Once the necessary information has been retrieved by the XTU 110 from the database 150, then the XTU 110 is arranged to contact the tributary unit 120 within the access concentrator 100, hereafter referred to as the CTU 120 (Concentrator Tributary Unit), to request a call manager within the CTU 120 to determine a suitable path for directing the call over the backplane between the XTU 110 and the CTU 120, over the backhaul between the access concentrator 100 and the central terminal 10, and over the wireless link between the central terminal and the subscriber terminal to which the call is destined.

The exact mechanism used by the call manager to determine the path for routing the call between the access concentrator, the central terminal and the subscriber terminal is not relevant for the purposes of the present invention. However, a detailed discussion of a preferred technique for performing this process is described in detail in UK Patent Application No. 9712168.5 filed on 11 June 1997.

However, in brief, the call manager preferably establishes a call object to represent the call, and then stores the information retrieved from the database 150 by the XTU as attributes of that call object. Further, the call manager preferably employs certain elements within the access concentrator and the central terminal to determine whether there is a radio slot available for carrying the call between the central terminal and the subscriber terminal. Herein, the term "radio slot" refers to the bandwidth elements into which each frequency channel is sub-divided, these radio slots being assigned to particular calls as required.

Once a radio slot has been allocated for the call, the call manager within the CTU 120 causes the addressed subscriber terminal to be invited to acquire the wireless link on that radio slot. Once the subscriber terminal has acquired the wireless link on the correct radio slot, then the call manager employs elements to allocate bearer time slots on the links of the concentrated backhaul interface between the access concentrator 100 and the central terminal 10, and on the concentrated backplane between the XTU 110 and the CTU 120 in the access concentrator 100.

The backplane and the backhaul are referred to as "concentrated" , because the number of time slots provided are less than the actual number of subscriber terminals supported by the system. Hence, a bearer time slot is allocated dynamically as and when required. Hence, unlike the El connections between the XTUs 110 and the exchange switch, where data relating to a particular subscriber terminal line will always appear on a particular time slot of a particular El line, the data for a particular subscriber terminal line may appear on any free bearer time slots on the backplane and the backhaul, since these time slots are allocated dynamically at the time the call is initiated. Once the above process has taken place, then the call can be routed from the

XTU 110 over the backplane to the CTU 120, and from there over the backhaul to a tributary unit 130 within one of the modem shelves of the central terminal with which the subscriber terminal has established the wireless link, this tributary unit 130 being referred to as a DTU 130 (Demand Assignment Tributary Unit). As discussed earlier with reference to Figure 3a, the data is then routed via the modem card 70, an analogue card 68, a transmit/ receive RF Unit 66, and then via d e RF combiner shelf 42 before being transmitted from the central terminal antenna to the subscriber terminal over the wireless link.

The above description has discussed the general technique used to route an incoming call from a switch of a telecommunications network to a particular subscriber terminal. A similar process is employed in the reverse direction for outgoing calls from a subscriber terminal to the switch. In this instance, when the subscriber terminal contacts the central terminal to establish an outgoing call, then once the radio link is established the DTU 130 within the appropriate central terminal modem shelf accesses the database 180 to retrieve the necessary information (eg El time slot ID) to enable the call to be routed via the backhaul and the backplane to the correct El line to the switch. The information retrieved is then transmitted with the set up message to the CTU 120 to enable a call object to be created.

Hence, as illustrated in Figure 5, a number of copies of a database containing information about the subscriber terminals, and the telecommunications equipment lines supported by those subscriber terminals, needs to be maintained on various cards of the wireless telecommumcations system. Thus, as illustrated in Figure 5, each XTU 110 maintains its own separate copy of the database 150, and the DTU 130 on each central terminal modem shelf will also maintain a copy of the database 180, the databases 150 and 180 preferably having the same structure, but with different fields being completed to reflect the different information required by the XTU's 110 and the DTU 130. For example, the DTU's database 180 preferably contains ST configuration information which can be supplied to a subscriber terminal for configuration purposes, this information not being required within the XTU databases 150. As mentioned earlier with reference to Figure 3, element managers are used to manage the wireless telecommunications system, and these element managers interface with the various equipment shelves via shelf controllers. Hence, the shelf controller 140 within the access concentrator 100 is arranged to maintain a database 160 which is updatable by the element manager, and which is then used to update the databases 150 associated with each XTU 110. Similarly, a shelf controller 170 on each modem shelf of the central terminal 10 is arranged to maintain a database 190 which is updatable by the element manager, and which is used to update the database 180 maintained by the DTU 130.

It is possible to only provide one database updatable by the element manager, such as the database 160 associated with the shelf controller 140 on the access concentrator. However, to update the database 180 on the modem shelf of the central terminal, the shelf controller 140 would have to communicate with the DTU 130 via the backhaul. This is not desirable since the links between separate shelves are not generally as reliable or quick as communications within a shelf. Hence, in preferred embodiments, each shelf maintains a database which is updatable by the element manager and then steps are taken within each shelf to keep the various copies of the database on that shelf synchronised.

Each shelf controller 140, 170 is provided with a database manager for managing the corresponding database 160, 190, and further each XTU 110 and each DTU 130 are provided with database managers to manage their corresponding databases 150, 180. Hence, it is clear that the system described with reference to Figure 5 requires a significant number of databases to be maintained, and that there is a great deal of overlap between the contents of each of these databases. With this in mind, it is clearly important that the various copies of the database are kept in synchronisation of one another, such that any changes in one of the databases is propagated to all of the other databases that also have an entry corresponding to the changed entry.

The manner in which this synchronisation is achieved between the database 180 maintained by the DTU 130 and the database 190 maintained by the shelf controller 170 on each modem shelf of the central terminal 10 will now be described in detail with reference to Figure 6, which is an interaction diagram illustrating the communications between the shelf controller 170 database manager and the DTU 130 database manager used to keep the database 180 in synchronisation with the database 190.

Whenever the element manager changes a record within the database 190, a "RecordModifiedO" function call is sent from the element manager to the shelf controller database manager 300 on the modem shelf containing the database 190. This RecordModified function call identifies which record(s) has/have been changed by the element manager. In preferred embodiments, upon receipt of the RecordModified function call, the shelf controller database manager 300 is arranged to issue a "MakeChangeMsgObj" function call to itself in order to create the internal representation of a "change" message to be sent from the shelf controller 170 to the DTU 130 to enable the database 180 to be updated. In preferred embodiments, this internal representation takes the form of an object called "message" (or "MsgObj" as it is referred to in Figure 6).

A "SendChange" function call is then used to pass the message object from the shelf controller database manager 300 to the shelf controller layer three protocol object 310 used for the communication between the shelf controller 170 and the DTU 130.

In preferred embodiments, the message object sent with the SendChange function call contains the complete record as modified, and hence implicitly includes all of the changes made by the element manager. However, it will be apparent to those skilled in the art that the message object included within the SendChange function call may instead just identify the changes to the previous version of the record.

As an alternative to making the message object, and then sending that message object via the SendChange function call each time a RecordModified function call is received by the shelf controller database manager 300, the shelf controller database manager 300 can be arranged to queue the changes until either the queue is full or until a timer expires. At that point, the MakeChangeMsgObj function call and the SendChange function call can be used to initiate the sending of the changes to the DTU 130 database manager via the shelf controller layer three protocol object 310.

In preferred embodiments, the communication between the shelf controller database manager 300 and the DTU database manager 340 is via a three layer protocol, a shelf controller layer three object 310 and a layer 3 state machine 320, and a DTU layer three object 330, terminating the layer three protocol used for such communications. In preferred embodiments, the layer two is based on the Q.921 standard, and layer one is a "High Level Data Link Control" (HDLC) layer.

Each time the shelf controller layer three object 310 receives a SendChange function call, it issues an "AllocSM" function call to itself in order to allocate a layer three state machine to handle the database update process for the record identified in the message object transmitted with the SendChange function call. Then, a "Send" function call is used to transfer the message object to the allocated layer three state machine 320.

Prior to receipt of the Send function call, the layer three state machine 320 will be in the "IDLE" state. Upon receipt of the Send function call, the layer three state machine 320 is arranged to start a timer, and then to issue a "CHANGE" message to the DTU layer three object 330. The CHANGE message is a hardware signal (a sequence of bytes) generated from the message object. Upon sending the CHANGE message, the layer three state machine 320 enters the "AW ACK" state, where it waits to receive an acknowledgement message from the DTU layer three object 330 to confirm that the update to the database 180 has taken place. Upon receipt of the CHANGE message, the DTU layer three object 330 converts the CHANGE message back to a message object, and issues a "UseChangeMsg" function call to the DTU database manager 340, this UseChangeMsg function call including the message object (containing the database record as updated). Upon receipt of the UseChangeMsg function call, the DTU database manager

340 is arranged to issue an UpdateDBrec function call to itself to cause the DTU database manager 340 to update the appropriate record in the database 180.

Once this update has taken place, the DTU database manager 340 issues a "SendAck" function call to the DTU layer three object 330, which then constructs an "ACK" message for transmission via the three layer protocol to the layer three state machine 320 of the shelf controller 170.

Upon receipt of the ACK message, the layer three state machine 320 stops the timer that it had started prior to issuing the CHANGE message, and then issues a "Free" function call to itself in order to free itself for subsequent use by the shelf controller layer three object 310. The layer three state machine 320 then enters the IDLE state.

If, for any reason, the layer three state machine 320 timer expires before the ACK message is received by the layer three state machine 320, then the layer three state machine 320 is arranged to resend the CHANGE message to the DTU layer three object 330. If, for any reason, the timer again expires before the ACK message is received by the layer three state machine 320, then in preferred embodiments an audit is performed. It will be apparent that there are a number of different ways in which this audit may be managed. However, in one embodiment, the shelf controller data base manager 300 is arranged to treat every record as modified, and hence to resend every record to the DTU database manager 340 via the three layer protocol. In addition to the element manager updating the database 190, and hence causing the process illustrated in Figure 6 to be employed to update the database 180, it is also possible that certain actions may cause the database 180 to be updated by the DTU 130 directly. For example, the DTU 130 may keep call statistics and update the database 180 accordingly. In such cases, it is necessary for the DTU 130 to contact the shelf controller 170 in order that the database 190 can be updated to reflect the changes made to the database 180. The process used to perform this update is illustrated in Figure 7, and, as will be apparent, is almost identical to the process illustrated in Figure 6, but with the steps taking place in the opposite direction. The only difference is that, in this latter case, the DTU layer 3 object 330 allocates a layer three state machine 325, rather than the shelf controller layer three object 310.

Figure 6 has illustrated the process used in preferred embodiments in order to synchronise the database 180 maintained by the DTU 130 with the database 190 maintained by the shelf controller 170 on each modem shelf of the central terminal 10. The process used to synchronise the databases 150 maintained by each XTU 110 and the database 160 maintained by the shelf controller 140 of the access concentrator 100 is almost identical, and is illustrated in Figure 8. As illustrated in Figure 8, the shelf controller database manager 400 on the shelf controller 140 again uses a MakeChangeMsgObj function call to create a change message object each time a RecordModified function call is received by the shelf controller database manager 400. Then, a SendChange function call is repetitively sent to the shelf controller layer three objects 410 (one shelf controller layer 3 object being provided for each XTU layer 3 object in preferred embodiments) such that one SendChange function call is issued for each database 150 maintaining a copy of the record that has been modified. The shelf controller layer three objects 410 will each allocate a state machine 420 when the SendChange function call is received. From this point on, it will be appreciated that the updating process for each database 150 is managed independently by the different layer three state machines 420 that have been assigned for each instance of the SendChange function call. For any update to a particular one of the databases 150, the layer three state machine 420 assigned to manage that update will stop its timer when the ACK message is received from the corresponding XTU layer three object 430. If for any reason the timer expires before the ACK message is received, then that layer three state machine 420 will resend the CHANGE message to the corresponding XTU layer three object 430. As discussed earlier with reference to Figure 6, if the timer expires again without the ACK message being received, then an audit will be performed.

As an alternative to the process illustrated in Figure 8, it will be appreciated that the SendChange function call could be sent just once, with a single state machine being allocated to manage the updates to all of the databases 150. In this instance, the layer three state machine 420 would send the CHANGE message to the XTU layer three object 430 corresponding to the first database 150, and upon receipt of the ACK message returned from that XTU layer three object 430 would then reissue the CHANGE message to the XTU layer three object 430 corresponding to the next database 150. Each time the CHANGE message is sent, the timer will be started, and each time the ACK message is received, the timer will be stopped. Only when a CHANGE message has been sent corresponding to each database 150, and corresponding ACK messages have been received, will the layer three state machine 420 issue a "Free" function call to itself and thereafter enter the IDLE state. It will be apparent that with this latter technique it would take longer to complete the updates to all of the databases 150 than with the technique illustrated in Figure 8, but may still prove to have adequate performance in certain situations.

Having described the techniques used in preferred embodiments of the present invention to manage calls to or from subscriber terminals of the telecommunications system, the techniques used to reduce the quantity of information that must be stored about the subscriber terminals will now be discussed in detail with reference to Figure 9, which is a diagram illustrating the structure of the subscriber terminal database in preferred embodiments of the present invention. Due to the large number of subscriber terminals that can be connected to a Demand Assignment telecommunications system, there is potentially a very large amount of data that must be stored within the telecommunications system relating to those subscriber terminals. For example, it is envisaged that a wireless telecommunications system such as that discussed earlier may allow for up to 32,000 lines to be supported through a single access concentrator. Hence, potentially, the database 160 illustrated in Figure 5 may need to provide records for up to 32,000 lines. The number of lines supported by a single subscriber terminal may vary, but in an example embodiment, each subscriber terminal may support one line, and hence the database 160 may have to store records for up to 32,000 subscriber terminals. In such situations, it will be apparent that it is very desirable for the data to be stored for every subscriber terminal to be minimised.

It is also envisaged that in an embodiment where up to 32,000 lines are supported through a single access concentrator, each modem shelf of a central terminal may be able to support up to 3,000 lines, or 3,000 subscriber terminals assuming each subscriber terminal supports one line. Hence, the database 190 illustrated in Figure 5 will also have to store records for a large number of subscriber terminals, and so it is again important for the amount of data stored to be minimised.

In accordance with preferred embodiments of the present invention, each database 150, 160, 180, 190 should at least have a record for each subscriber terminal that the card associated with that database may need to access information about. The information that is stored in the records will vary from card to card, although in preferred embodiments the overall structure of the data will remain the same.

Figure 9 illustrates how each of the databases is structured in accordance with preferred embodiments of the present invention. Firstly, each ST database will provide an ST record structure 500 having a record 505 for each subscriber terminal relevant to the card with which that database is associated. Within each ST record, a number of entries are provided. A first entry 514, hereafter call the "StClass" entry contains a pointer to a record 522 in an StClass data structure 520, this StClass record 522 providing all the necessary details about the type of the subscriber terminal identified in the ST record 505. For example, the StClass record 522 may provide, amongst other things, the following information: the number of lines supported by the subscriber terminal the version of the software that the subscriber terminal is currently running the desired radio bandwidth for the subscriber terminal - the dialling mode of the subscriber terminal an indication as to whether, in the event of congestion, a congestion tone is to be generated, and after what period of time the period, in seconds, after a call has finished that the radio is held up to allow follow on calls without reacquisition of the wireless link. The above is an example of some of the items of information that may be stored in each StClass record 522. It will be appreciated by those skilled in the art that the exact information stored, and the format of that information, can be chosen at will. The main aim of each StClass record 522 is to provide a core amount of information that will be common to a number of the STs supported by the telecommunications system. In that instance, it is clear that a number of the first entries 514 in each ST record 505 will point to the same StClass record 522, thereby yielding a significant saving in the amount of information that needs to be stored within the ST database.

A second entry 516 in each ST record 505 includes in preferred embodiments a pointer to a line record 524 providing information about a first line supported by that subscriber terminal. In preferred embodiments, a line record data structure 510 is provided having a line record 524 for each subscriber terminal line. Since each database may have to store information about a large number of lines, then it is clear that the information stored in each line record 524 should be kept to a minimum. Hence, in preferred embodiments, each line record 524 includes pointers to other data structures containing information that may be common to a number of lines. As an example, a first entry 526 in each line record 524 preferably contains a pointer to a record 534 in a signalling class data structure 530, this signalling class record 534 preferably containing signalling configuration information common to a class of subscriber terminal lines. An example of the types of information that may be stored within each signalling class record 534 is as follows: the exchange release pulse width in milliseconds the seize time in milliseconds the clear time in milliseconds the minimum and maximum answer recognition times in milliseconds - the minimum and maximum hook digit time in milliseconds.

Again, it will be apparent to those skilled in the art that the exact information stored in each signalling class record 534 can be tailored as desired. The main aim is to provide in each signalling class record 534 a core group of signalling information that is common to a number of ST lines. In such cases, a number of the line records 524 will have pointers to the same signalling class record 534, thereby saving a significant amount of storage space that would otherwise be taken up with replicating data.

An example of a second entry 528 which may be provided within each line record 524 is a "LinelmpClass" pointer to a record 536 in an impedance class data structure 540. Each line impedance class record 536 preferably contains line impedance parameters required by a programmable circuit within the subscriber terminal, these parameters preferably being common to a number of lines.

A third entry 532 which may be provided within each line record 524 is a

"Priority NumClass" pointer to a record 538 in a priority number class data structure 550. In a Demand Assignment system, it is clear that a user cannot always be guaranteed immediate access to the telecommunications network, since there will be fewer wireless links than there are potential users. In such situations, it is clearly advisable to provide a mechanism whereby certain emergency calls will be given priority over other calls. In preferred embodiments, a particular radio channel can be kept free for priority calls. Each line can then have a number of priority numbers associated with it, such that upon dialling one of those numbers, that line will be connected to the telecommunications network via the priority radio channel. Since a number of the lines are likely to have the same core set of priority numbers, storage savings can be yielded by providing priority number class records 538 containing a list of priority numbers, and each line record 524 then having a priority number class pointer 532 pointing to the appropriate priority number class record 538. In addition to the various pointers 526, 528, 532 provided within each line record 524, a number of other parameters specific to the line will also be provided within the line record 524. Examples of these attributes are as follows: an ST identifier identifying the subscriber terminal to which the line is connected a line number identifying the particular line the Erlang loading of the line the call rate of the line the number of incoming and outgoing calls attempted to and from the line. The above is just an example of some of the attributes that may be stored in each line record 524. It will be appreciated by those skilled in the art that the exact information stored can be varied to suit the particular application.

Returning to the ST record data structure 500, in addition to the pointers 514 and 516 stored within each ST record 505, examples of certain other attributes which may be stored within each ST record 505 are as follows: the serial number of the subscriber terminal an authentication count, used with the serial number in an authentication encryption key an ST identifier assigned to the subscriber terminal on installation - the automatic gain level of the ST an indication of up to four central terminal modem shelves that the ST can be resident on an indication of the central terminal modem shelf the ST was last resident on the backhaul bearer slot currently allocated to the subscriber terminal - the radio slot currently allocated to the subscriber terminal.

Again, the above information is just an example of the information that may be stored within each ST record 505, and it will be apparent to those skilled in the art that the exact information stored can be varied dependent on the application.

In the preferred embodiment, each ST supports one line, and hence the first line pointer 516 will actually be a pointer to the sole line supported by that subscriber terminal. However, if a subscriber terminal supports more than one line, then in preferred embodiments the line record data structure 510 is arranged such that the second and subsequent line supported by that subscriber terminal have line records immediately following the line record corresponding to the first line. Hence, the first line pointer 516 can be used to identify the line record 524 corresponding to the first line, and the subsequent line records can then be used to identify information about the other lines supported by the subscriber terminal. This arrangement again saves storage space by removing the requirement to provide separate pointers to other line records.

As mentioned earlier, it is preferable that every record, irrespective of the database 150, 160, 180, 190 that that record resides in, will have the same overall data structure. However, dependent on the location of the database in which the record resides, it may be unnecessary for certain of the entries to be completed. For example, in the database 160 within the access concentrator 100, it is necessary for each line supported by the access concentrator to be identified, and hence a separate line record 524 will be provided for each such line. However, it is not necessary for all of the information about those lines to be present within the database 160. For example, it is not necessary for the database 160 to contain the signalling class information, the impedance class information or the priority number class information, since this is typically only used by the subscriber terminals as configuration information, and hence the pointer entries 526, 528 and 532 within each line record 524 need not be present.

When a subscriber terminal is initialised, it preferably receives a copy of entries from its ST record as stored in the central terminal database 180, these entries providing configuration information for the subscriber terminal. Hence, in preferred embodiments, the database 180 will contain all of the subscriber terminal and line configuration information required for configuration purposes by the subscriber terminal associated with the subscriber terminal and line records.

In accordance with preferred embodiments of the present invention, the above ST database structure is used such that all the necessary information to route a call from the telephone exchange to a subscriber terminal equipment line and vice versa can be extracted from one database. For example, in the case of an incoming call, the XTU 110 receiving the incoming call will access its corresponding database 150 in order to retrieve all of the necessary information about the destination subscriber terminal and subscriber terminal line required to route the call to that subscriber terminal line. Similarly, for an outgoing call, the DTU 130 can access its database 180 in order to extract all the necessary information to enable an outgoing call to be established via the central terminal and access concentrator to the telephone network. This approach avoids the requirement for absolute consistency between the databases at each end of the system (ie at the XTU 110 and the DTU 130). Further, this approach avoids the need to replicate the data more often than is necessary. For example, in accordance with this approach, there is no requirement for any copies of the database to be stored for access by the CTU 120. This is a significant advantage, since the CTU 120 is responsible for managing each ongoing call and, in this regard, as mentioned earlier, establishes a call object for each ongoing call. This function already requires a significant amount of storage capacity to be available within the CTU 120, and hence it is a significant advantage not to have to store any ST database information at the CTU 120.

Further, by providing all of the required line information within an ST database strucmre as described earlier, there is no need to provide specific pointers to line records in the XTUs and DTUs. By avoiding this requirement, any problems associated with updates are alleviated. Instead, at the point of call instantiation, a copy of the relevant ST and line information is made from the database, and this copy is then used for the duration of the call. By this approach, it is clear that the databases can be updated whilst the call is in progress without affecting the call.

Although a particular embodiment has been described herein, it will be appreciated that the invention is not. limited thereto and that many modifications and additions thereto may be made within the scope of the invention. For example, various combinations of the features of the following dependent claims could be made with the features of the independent claims without departing from the scope of the present invention.

Claims

1. A call routing system for routing calls to or from subscriber terminal (ST) lines in a telecommunications system, comprising:

a first storage having type records, each type record identifying attributes of a type of subscriber terminal;

a second storage having line records, each line record identifying information about a line supported by a subscriber terminal of the telecommumcations system;

a third storage having ST records, each ST record relating to a subscriber terminal within the telecommunications system, and containing a first pointer to a type record in the first storage identifying the type of that subscriber terminal, and a second pointer to a line record in the second storage identifying a line supported by that subscriber terminal; and

one or more call routing elements arranged to access the third storage to retrieve information about a subscriber terminal line required to route a call to or from that subscriber terminal line.

2. A system as claimed in Claim 1 , wherein each line record in the second storage contains a pointer to a signalling record in a signalling storage, the signalling record identifying a signalling configuration for a class of lines.

3. A system as claimed in Claim 1 or Claim 2, wherein each line record in the second storage contains a pointer to an impedance record in an impedance storage, the impedance record identifying line impedance parameters.

4. A system as claimed in any of claims 1 to 3, wherein each line record in the second storage contains a pointer to a number record in a priority number storage, each number record containing priority numbers for a class of lines.

5. A system as claimed in any preceding claim, wherein the second pointer in each ST record relates to a line record identifying the first line supported by that particular subscriber terminal, and the second storage is arranged such that the immediately following line records in the second storage relate to any other lines supported by that subscriber terminal.

6. A system as claimed in any preceding claim, further comprising an ST interface for providing a subscriber terminal with a copy of the data stored by the call routing system relating to that subscriber terminal.

7. A system as claimed in any preceding claim, comprising a plurality of management modules, said management modules including said one or more call routing elements, and at least two of said management modules maintaining a database comprising said first, second and third storages, the call routing system further comprising an interface mechanism for synchronising the databases maintained by said at least two management modules, the interface mechanism comprising:

a first database manager for receiving information about modifications made to the database maintained by a first management module;

a first communications element, responsive to the first database manager, to employ a communications protocol to send a change message to a second communications element associated witii a second management module maintaining the database, the change message incorporating the modifications made to the database;

a second communications element for employing the communications protocol to receive the change message and generate update information; and

a second database manager for receiving the update information from the second communications element and updating the database using that update information.

8. A system as claimed in Claim 7, wherein the second communications element is responsive to a signal from the second database manager indicating that the database has been updated to employ the communications protocol to send an acknowledgement message to the first communications element.

9. A system as claimed in Claim 7 or Claim 8, wherein the first communications element includes a state machine allocated by the first communications element to send the change message to the second communications element.

10. A system as claimed in Claim 8 and Claim 9, wherein the state machine is arranged to enter an awaiting state upon sending the change message, during which time it is not available for use by the first communications element, the state machine being arranged to exit the awaiting state upon receipt of the acknowledgement message from the second communications element, whereafter it is available for use by the first communications element.

11. A call routing system as claimed in any of claims 7 to 10, wherein one of said management modules maintaining the database is a shelf controller arranged to manage a shelf of equipment, and another management module maintaining the database is one of said call routing elements located on the shelf.

12. A call routing system as claimed in Claim 11, further comprising a plurality of said call routing elements, each arranged to maintain the database, the interface mechanism being arranged to synchronise the database maintained by the shelf controller with the databases maintained by the plurality of call routing elements.

13. A call routing system as claimed in any preceding claim, wherein said one or more call routing elements are tributary units.

14. A central terminal for routing calls to or from subscriber terminal lines in a telecommunications network, comprising a call routing system as claimed in any preceding claim.

15. A concentrator unit for a telecommumcations system, the concentrator unit comprising a call routing system as claimed in any of claims 1 to 13.

16. A method of routing calls to or from subscriber terminal (ST) lines in a telecommunications system, comprising the steps of:

(a) providing a first storage having type records, each type record identifying attributes of a type of subscriber terminal;

(b) providing a second storage having line records, each line record identifying information about a line supported by a subscriber terminal of the telecommunications system;

(c) providing a third storage having ST records, each ST record relating to a subscriber terminal within the telecommunications system, and containing a first pointer to a type record in the first storage identifying the type of that subscriber terminal, and a second pointer to a line record in the second storage identifying a line supported by that subscriber terminal;

(d) employing one or more call routing elements to access the third storage to retrieve information about a subscriber terminal line; and

(e) routing a call to or from that subscriber terminal line using the information retrieved at said step (d).