TELEPHONE CALL HANDLING SYSTEM

Abstract: There is described a system for providing number portability. In particular, there is described a cache structure for a number translation database, in which the pair of numbers to be translated are stored together with an identifier relating to the calling subscriber, and with two priority values, one of which forms part of a set of values specific to that subscriber, and one of which is a global priority value. Each exchange contains a local database, and is connected to a central node containing a master database. Changes in stored data must be entered through a service management system attached to the master database in the central node, and are then transmitted to the various local databases.

Description: TELEPHONE CALL HANDLING SYSTEM TECHNICAL FIELD OF THE INVENTION This invention relates to a system and a method for handling telephone calls, in a way which allows the introduction of number portability. DESCRIPTION OF RELATED ART With number portability, a telephone subscriber can retain a single telephone number in different circumstances which would otherwise require a change of number, for example when he changes from one service provider to another, or when he moves his office or residential location, or when he changes the level of service which he requires, for example changing from POTS to ISDN, or from NMT to GSM. One proposed method of providing number portability is described in US-A-5,434 , 914. This document discloses a system in which each node of the network has a name cache, and is also connected to a name server. The name cache contains details of number translations relevant to all subscribers connected to that node. When a call is attempted, details of the called number are passed to the name cache for translation. If unsuccessful, the name server is used to translate the logical number into a physical network address. When a number correspondence is to be changed, a signal is sent from the node which serves the relevant address to the name server, and can then be transferred to name caches in the other nodes. A disadvantage of such a system is that changes in number correspondences, which are to be stored in a node, may originate in another node, for example owned by a different service provider. This means that personnel must be authorised by all operators to alter data stored at their nodes, which increases complexity and expense. Moreover, searching the large name caches can be time-consuming. The present invention seeks to overcome these disadvantages. SUMMARY OF THE INVENTION The present invention seeks to overcome the disadvantages associated with the known methods of providing number portability. This is achieved by providing a name cache structure which allows more rapid searching, and only allows updating originating at a central location. The object of the invention therefore is to allow number portability, without the disadvantages of the prior art . According to a first aspect of the present invention, there is provided a method of operation of a telecommunications system, comprising: a central node, having a master number translation database, and having a service management system associated therewith; and a plurality of exchanges connected to the central node, each of the exchanges having a local number translation database; wherein the master number translation database and the local number translation databases can only be updated following a command through the service management system. According to a second aspect of the present invention, there is provided a communications system, comprising a plurality of interconnected exchanges, to which subscribers are connected, each exchange comprising a local name cache, for storing data relating to number translations, and each exchange being connected to a central name cache, wherein information relating to alterations in the stored data may be input only through the central name cache. This has the advantage that management of the system is centralised, which is advantageous particularly when the different exchanges are owned by different operators, as personnel then need to be authorised by only a single body. According to a third aspect of the present invention, there is provided a communications exchange, comprising a number translation database, the number translation database storing, for each number translation, a logical number of a called party, a physical number of the called party, and an identification of a calling party associated with that number translation. This has the advantage that the database is then, in effect, divided into a plurality of subscriber- specific databases, which amongst other things allows more rapid searching. BRIEF DESCRIPTION OF THE DRAWINGS Figure 1 is a schematic representation of a telephone system in accordance with the invention. Figure 2 is a flow chart showing the progress of a dialled call using the system in accordance with the invention. Figure 3 is a schematic representation of the structure of a local database. Figure 4 is a flow chart showing how a local database is updated. DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS Figure 1 shows a telephone system, in which a telephone 2 is connected to a first exchange 4, which contains a local database 6. The exchange 4 is connected to a master database 8, which has a service management system 10 attached to it . A second exchange 12 is also shown connected to the master database 8 for the purposes of illustration, and it will be appreciated that, in practice, many such exchanges may be so connected. The second exchange 12 has its own local database 14. Operation of the system shown in Figure 1 will now be described with reference to Figure 2. As shown in Figure 2, when a number is dialled, a check is first made in step SIO as to whether the dialled number is in a category for which the local database, associated with the exchange through which the call is made, may contain an entry. This check is made because some numbers, for example international numbers, may not be stored in the local database. If the dialled number is in a category which is never stored in the local database, then the procedure passes to step S12 , and the call is handled in a conventional way. If, on the other hand, the dialled number is in a category for which the local database may contain an entry, as would usually be the case, the process proceeds to step S14, in which the local database is interrogated to check whether it in fact contains an entry for the dialled number. If the local database does contain such an entry, then the process proceeds to step S16, where the indicated number translation is performed, and step S18, in which the call is routed to the indicated physical location. However, since the local database is not automatically updated with information relating to changes in location or service provider for the called subscribers, the entry contained in the local database may no longer be correct. In that case, the attempt to route the call to the physical location indicated in the local database will not succeed. Thus, in step S20 of the process, it is determined whether the call was successful, for example by testing for standard signalling indicating that the called number is vacant. If the call is successful, the process ends at step S22. On the other hand, if the call is not successful, the process proceeds to step S40. Similarly, if step S14 indicates that the local database contains no entry for the dialled number, the process also proceeds to step S40, in which a query is sent to the master database, to which the exchange is connected. As shown in Figure 1, the master database 8 is connected to a service management system 10, and so it will have been updated with any required changes, for example relating to altered location or service provider for a particular subscriber. The correct physical location can then be retrieved from the master database. The local database 6 is then updated with this new information, as illustrated in step S42 in Figure 2. Then, the process can proceed to step S44, in which the appropriate number translation is performed, and step S46, in which the call can be routed to the physical location indicated by the number translation. The process then proceeds to step S48, where it ends. Thus, it can be seen that the master database is only queried in cases where the local database does not contain information relating to the required number translation, or contains outdated information relating to the number translation. However, since the information changes relatively infrequently, this system will allow there to be a relatively small number of queries to the master database compared with the total number of calls handled. The updating of the local database, as illustrated in step S42 of Figure 2, can be carried out in several different ways. For example, the local database can be controlled so that it automatically stores number translation information relating to frequently dialled numbers, which may be defined in any desired way. In addition, the local database may contain number translation information relating to all of the numbers which terminate at the local exchange with which the local database is associated. Figure 3 shows, schematically, the structure of a local database. Specifically, for each number translation with which the database is concerned, the database or cache contains an indication of the physical number of a particular called party, the logical number of that party, a global priority value, a subscriber specific priority value, and also allows an identification of the particular calling subscriber, with which the number translation is associated. The structure of the database is such that it is possible to translate from a physical number into a logical number, and from a logical number into a physical number. This means that not only is it possible for a subscriber to dial a single number, which can then connect to a called party at one of several different locations, but the inverse is also possible. That is, a service is possible whereby if, for example, a subscriber wishes to call a restaurant, which forms part of a chain of restaurants, a number translation is carried out on the number of the calling party, in order to obtain his present location. This allows the call to be connected automatically to the nearest restaurant in the chain. As shown in Figure 3, it is also preferable that the local database, which necessarily stores the logical and physical numbers for each number translation which is to be performed, should also store at least one priority or a time stamp with each stored pair of numbers. Since the local database will have a maximum capacity set at some particular level, it is possible that the updating step, step S42 in Figure 2, may require that a pair of numbers be deleted from the stored pairs, if the database is full. For example, the pairs of numbers may be stored in the local database such that, whenever an already stored pair is queried, its time stamp is updated, to represent the time at which the pair was most recently queried. Then, if the database is full, and a new pair of numbers is to be added to the database, the pair of numbers with the oldest time stamp may be the one which is chosen to be discarded. Alternatively, there may be a priority stamp which overrides or interacts with the time stamp. Alternatively, or additionally, it may simply be arranged such that all pairs of numbers which are not queried within a certain time period are discarded. The arrangement shown in Figure 3 stores two priority values in connection with each number translation. Firstly, there is a global priority value, which forms part of a single set of priority values, one value of which is associated with every number translation. This priority value is then updated every time a number translation is queried or entered into the database. Secondly, there is a subscriber specific priority value, which forms part of a set of priority values associated with stored data for number translations in respect of numbers which are dialled by a specific individual subscriber. The structure of the database may then be such that, when it is desired to enter a new pair of numbers, the pair which are to be discarded may be the pair with the lowest global priority value, or the lowest priority value in the set of priority values specific to that particular calling subscriber. This feature, together with the presence of a subscriber identifier, corresponding to the calling subscriber who originated the entry of that number translation, means that each subscriber effectively has an individual local database of frequently dialled numbers. This may be used to facilitate the searching process, by only searching, in the first instance, for number translations having the subscriber identifier associated with the particular calling subscriber in any given case. Also, it may be arranged that, where a subscriber identifier is set, that entry may only be deleted by the identified subscriber, irrespective of the global priority value at any time. Figure 4 is a flow chart showing how a stored pair of numbers is updated, for example following a change in a subscriber's physical number. As indicated in step S82, the alteration must be initiated through the service management system, and a command is sent to the master database. Then, in step S84, the master database is updated, although, at this stage, the information is not transmitted to the local databases. The result of this is that, when the logical number of that subscriber is next called, the call is unsuccessful, and a query is then sent to the master database, as shown in step S86. Following that query, the local database is updated in step S88, as described previously. This completes the process, as shown in step S90. Updating the system in this way means that the system security, for example the authorisation of the various personnel, can be handled in a centralised way, which avoids the disadvantages associated with personnel being authorised by one operator to alter data stored at the exchanges of other operators, or needing to be authorised by all operators. Thus, there is provided an arrangement which allows number portability to be provided, while greatly reducing the number of queries which must be made to a master database, and increasing the system security. Moreover, it is not necessary to connect a management system to each local database. In addition, this arrangement can be used in any network, since the system is not dependent on the use of any specific signalling protocol. Existing protocols can be used for updating the local database.

Claims: CLAIMS 1. A method of operation of a telecommunications system, comprising: a central node, having a master number translation database, and having a service management system associated therewith; and a plurality of exchanges connected to the central node, each of the exchanges having a local number translation database; wherein the master number translation database and the local number translation databases can only be updated following a command through the service management system. 2. A method as claimed in claim 1, wherein a local number translation database is updated after an enquiry to the master number translation database following a failure to find correct data in the local database. 3. A communications system, comprising a plurality of interconnected exchanges, to which subscribers are connected, each exchange comprising a local name cache, for storing data relating to number translations, and each exchange being connected to a central name cache, wherein information relating to alterations in the stored data may be input only through the central name cache. 4. A communications exchange, comprising a number translation database, the number translation database storing, for each number translation, a logical number of a called party, a physical number of the called party, and an identification of a calling party associated with that number translation. 5. A communications exchange as claimed in claim 4, wherein the number translation also stores, for each number translation, a first priority value which forms part of a set of priority values specific to that calling party. 6. A communications exchange as claimed in claim 4 or 5, wherein for each number translation, the number translation database further stores a second priority value which forms part of a set of priority values common to all calling parties. 7. A communications exchange as claimed in claim 4, 5 or 6, comprising means for searching in response to a call request from a subscriber, such that, first, the stored number translation information associated with that calling party, is searched, and then the larger database is searched. 8. A communications exchange, comprising a number translation database, the number translation database storing, for each number translation, a logical number of a called party, a physical number of the called party, an identification of a calling party, and a first priority value which forms part of a set of priority values specific to that calling party, wherein the database can contain data relating to a predetermined maximum number of number translations with the identification of a particular calling party, and, when it is desired to add to the database data relating to a number translation which would cause the predetermined maximum number to be exceeded, a number translation with the identification of that particular calling party is removed from the database. 9. A communications exchange as claimed in claim 8, wherein, when a number translation is to be removed from the database, it is the number translation with the lowest first priority value which is removed. 10. A communications exchange as claimed in claim 9, wherein the first priority values are set so that the oldest entry has the lowest first priority value. 11. A communications exchange, comprising a number translation database, the number translation database storing, for each number translation, a logical number of a called party, and a physical number of the called party, and the database allowing a dialled logical number to be translated into a physical number and allowing a dialled physical number to be translated into a logical number.

Inventors: BERGSTRAND KARL MAGNUS, BERGSTRAND, KARL, MAGNUS
Applicants: BERGSTRAND KARL MAGNUS, ERICSSON TELEFON AB L M, BERGSTRAND, KARL, MAGNUS, TELEFONAKTIEBOLAGET LM ERICSSON
Application year: 1997
Main classification: H04Q3
IPC codes: H04M3, H04Q3