TITLE: PROCESSOR FOR USE IN REPLICATION OF DATABASES AND SYSTEM AND METHOD INCLUDING THE PROCESSOR

FIELD OF THE INVENTION

The present invention relates to a processor for use in replication of databases and a system and method including the processor. In particular, the invention relates to replication and synchronisation of databases in a communication system such as a mobile communication system.

BACKGROUND OF THE INVENTION

Many systems employ databases for storage of data used in operation of the systems. An example of such a system is a mobile telecommunications system which typically employs a number of databases particularly relating to mobile communication terminals operating in the system. In a number of systems it is desirable to replicate a primary database with a replica secondary database so that the replica secondary database can serve as a backup of the primary database in the event of its failure or can share the load of the primary database.

Replication is normally carried out by a procedure known as ^transaction replication' . A replicated transaction is a set of data-changing operations that are grouped in a collection, where each collection

represents the results of a committed transaction in a primary database, and is replicated in a secondary database. However this known procedure is not efficient because it is not always able to achieve complete consistency between the primary and secondary- databases .

SUMMARY OF THE INVENTION

According to the present invention in a first aspect there is provided a processor according to claim 1 of the accompanying claims .

According to the present invention in a second aspect there is provided a communication system according to claim 9 of the accompanying claims

According to the present invention in a third aspect there is provided a method according to claim 15 of the accompanying claims

Further features of the invention are as disclosed in the embodiments of the invention to be described.

Embodiments of the present invention will now be described by way of example with reference to the accompanying drawings, in which:

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a block schematic diagram of a system in which databases in a first database system are to be replicated and synchronised in a second database system in accordance with an embodiment of the invention.

FIG. 2 is a flow chart of a method of operation in the system of FIG.l.

FIG. 3 is a block schematic diagram showing an arrangement of infrastructure management components in a wide area mobile communication system illustrating use of the system of FIG. 1.

FIG. 4 is a block schematic diagram showing more detail of a zone controller of the mobile communication system of FIG. 3.

DESCRIPTION OF EMBODIMENTS OF THE INVENTION

FIG. 1 is a block schematic diagram of a system 100 in which databases in a first database system are to be replicated and synchronised in a second database system in accordance with an embodiment of the invention. The first database system 101, Database System 1, includes a plurality of databases, two of which are shown, namely a first database, Database 1.1, and a second database, Database 1.2'. A link 104 is provided between the Database 1.1 and the Database 1.2 since there is a dependency, which may be a complex two way dependency, between the data in the Database 1.1 and the data in the Database 1.2. The second database system 102, Database System 2, includes a plurality of databases, two of which are shown, namely a first database, Database 2.1, and a second database, Database 2.2. A link 105 is provided between the Database 2.1 and the Database 2.2 since there is a dependency, which may be a complex two

way dependency, between the data in the Database 2.1 and the data in the Database 2.2.

A database replication and synchronisation manager 103 is linked between the Database System 1, 101, and the Database System 2, 102. The database replication and synchronisation manager 103 is able to extract information and data from the Database System 1, 101, to hold information and data temporarily if appropriate, to process the information and data if appropriate, and to deliver the information and data to the Database System 2, 102. The database replication and synchronisation manager 103 is a processor, for example a programmed digital processor such as a server.

There are various known methods available by which the replication and synchronisation manager 103 may extract the information from the Database System 1, 101. However the present invention is not dependent on or restricted to any particular extraction method. Extraction methods known to those familiar with the art include use of one or more of: transactions, resulting table contents, audit trail logs and operations, and reports on differences between table contents.

The database replication and synchronisation manager 103 has a link 106 to the Database 1.1, and has a link 107 to the Database 1.2. The database replication and synchronisation manager 103 also has a link 108 to the Database 2.1, and has a link 109 to the Database 2.2.

The links 106, 107, 108 and 109 may be manually or automatically mediated over and may be wired or wireless

links. The links 104 and 105 are shown as separate links operating in parallel and the links 106 and 107 are shown as separate links operating in parallel. However, the links 104 and 105 could be provided by use of different communication channels on a common link.

Similarly, the links 106 and 107 could be provided by use of different communication channels on a common link. The invention is not dependent upon or restricted to any particular link ^• implementation. The Database 1.1 is to be replicated in the

Database 2.1. In other words, the Databases 1.1 and 2.1 have a structure in which data relating to a particular subject is held in a number of fields and the structure, the fields and the data in the fields is to be the same • in both the Database 1.1 and the Database 2.1.

Similarly, the Database 1.2 holding data in a number of fields, relating to the same subject as for Database 1.1 or another subject, ^' is to be replicated in the Database 2.2. The replications may be required, for example, because the Database 2.1 has to serve as a backup to the Database 1.1, and the Database 2.2 has to serve as a backup to the Database 1.2 in the event that there is a failure of the Database System 1. Alternatively, or in addition, the replication of the Database 1.1 by the Database 2.1 may be required so that in operation the Database 2.1 can share with the Database 1.1 processing of received database queries. Similarly, the replication of the Database 1.2 by the Database 2.2 may be required so that in operation the Database 2.2 can share with the Database 1.2 processing of received database queries.

The replication and synchronisation manager 103 manages the extraction, temporary storage, processing and transfer of information relating to the structure of the Databases 1.1 and 1.2 (although it could alternatively receive this information from another source) and the data stored in the respective fields of those databases to the Databases 2.1 and 2.2 to provide the replication. The replication and synchronisation manager 103 also ensures that the replicated pair of Databases 1.1 and 2.1 and the replicated pair of

Databases 2.1 and 2.2 are respectively synchronised. Synchronisation involves ensuring that after replication each of the respective databases of a replication pair have identical structure and contents. Synchronisation can also involve checks made during the replication process including for example: the individual operation of a transaction, its outcome, its dependencies on other operations in the transaction, and the sequencing of operations . The Databases 1.1 and 1.2 and the Databases 2.1 and 2.2 are related. An example of these databases is described later with reference to FIGS. 3 and 4. In view of this relationship, synchronisation of (at least part of) data of the Database 2.2 replicating that of (at least part of) data of the Database 1.2 may depend upon prior synchronisation of data of the Database 2.1 replicating that of the Database 1.1. The replication and synchronisation manager 103 therefore operates to manage the transfer of data from the Database System 1 to the Database System 2 so that the replication of the

databases of the Database System 1 by the databases of the Database System 2 is carried out in an efficient and complete manner. The replication and synchronisation manager 103 has been programmed with an order by which multiple data packages should be inserted in the

Database 2.1 and the Database 2.2, particularly where the data packages are inter-related. A method or procedure which may be used by the replication and synchronisation manager 103 will now be described with reference to FIG. 2.

FIG. 2 is a flow chart of a method 200 of operation in the system 100, the method embodying the present invention. In a step 201 the replication and synchronisation manager 103 extracts a data package X from the Database 1.1. The data package X may be all of the data held in the Database 1.1 or it may be a selected part of the data. For example, if the data is a selected part, the subject of interest in the selection may be expressed by a predefined field or set of fields in a set of, or all, database tables.

In a step 202 the replication aηd synchronisation manager 103 extracts a data package Y from the Database 1.2. The data package Y may be all of the data held in the Database 1.2 or it may be a selected part of the data.

It is to be noted that (insofar as the present embodiment of the invention is concerned) for a given state of the Database System 1 the order of the extraction of the data from the Database 1.1 and the Database 1.2 is not important. In other words, steps 201

and 202 may be performed in any order or may performed at the same time.

In a step 203 the replication and synchronisation manager 103 detects, e.g. using a program and information previously recorded by the replication and synchronisation manager 103, that there is a relationship between the data package X and the data package Y such that replication and synchronisation of the data package X in the Database 2.1 has to be completed before replication of the data package Y in the Database 2.2 can begin. In a step 204 the replication and synchronisation manager 103 begins inserting the data package X into the Database 2.1, but holds the data package Y. When data of the data package X into the Database 2.1 begins the Database 2.1 detects that there is a relationship between the data package X and the data package Y destined for Database 2.2. In a step 205, the databases 2.1 and 2.2 perform an interaction , or a processor associated with the Database System 2 performs the interaction on their behalf.

The required interaction is detected for example by use of previously stored information and/or programs. The purpose of the interaction is to synchronise the internal state of the Database System 2. In a step 206, which may be applied once or repeatedly, the replication and synchronisation manager 103 monitors insertion of the data package X into the Database 2.1. The replication and synchronisation manager 103 may do this by sending one or more query messages to the Database 2.1 (or to a processor of the

Database System 2 associated with the Database 2.1) to enquire as to the state of synchronisation of the transfer of the data package X. The Database 2.1 (or an associated processor) may send one or more response messages indicating the state of synchronisation of the transfer of the data package X.

The Database 2.1 (or an associated processor) knows the state of the synchronisation for example by issuing a status query and receiving a response for an insert transaction; or by querying to check for an expected result of an insert transaction.

In a step 207 the replication and synchronisation manager 103 detects, e.g. from one of the response messages sent by the Database 2.1 or from the Database 2.2 or by some other means, that insertion of the data package X into the Database 2.1 has been successfully completed. In response to this detection, the replication and synchronisation manager 103 begins, in a step 208, insertion of the data package Y held by the replication and synchronisation manager 103 into the Database 2.2. In a step 209, the replication and synchronisation manager 103 monitors insertion of the data package Y into the Database 2.2 until the insertion is successfully completed. A procedure similar to that of the method 200 is applied in the transfer of other data packages from the Database System 1 to the Database System 2. In some cases, the transfer of a particular data package to the Database 2.1 may have to be completed before transfer of a related data package to the Database 2.2 can begin. In

other cases, the transfer of a particular data package to the Database 2.2 may have to be completed before transfer of a related data package to the Database 2.2 can begin. The relationships between the data packages and the order of completion of the data package transfers are pre-determined and known by the replication and synchronisation manager 103 and may also be known by the Databases 2.1 and 2.2.

If there are no further inter-dependencies between the data in the Database 1.1 to be replicated and the data in the Database 1.2 to be replicated then further replication of the Databases 1.1 and 1.2 could if appropriate proceed as separate procedures in parallel. The system 100 and the method 200 may be used in many applications employing replicated databases. Of particular interest are applications in communication systems, especially mobile communication systems. As an illustration, use of an example of the system 100 will now be described with reference to FIG. 3 which shows an arrangement of infrastructure management components in a wide area mobile communication system 300. The system 300 includes a system controller 301 and zone controllers 302, 303 and 304.

The zone controller 302 controls mobile communication operations in a geographical zone 305. The zone controller 302 is operably connected to a number of base transceiver stations and other infrastructure components (not shown) to provide communications in the zone 305. The base transceiver stations provide wireless connectivity for mobile stations (not shown) in cells

defined by the positions of the base transceiver stations in the zone 305. The zone controller 303 controls mobile communication operations in a geographical zone 306 and is connected to other infrastructure components in a manner similar to the zone controller 302. Base transceiver stations (not shown) connected to the zone controller 303 provide wireless connectivity for mobile stations (not shown) in cells defined by the positions of the base transceiver stations in the zone 306. The zone controller 304 controls mobile communications operations in a geographical zone 307 and is connected to other infrastructure components in a manner similar to the zone controller 302. Base transceiver stations (not shown) connected to the zone controller 304 provide wireless connectivity for mobile stations (not shown) in cells defined by the positions of the base transceiver stations in the zone 307. The zone controllers 302, 303 and 304 are connected together by links 311, 312, and 313 which may for example be wireless links or broadband internet links.

The system controller 301 is operably connected to the zone controllers 302, 303 and 304 by links 308, 309 and 310 respectively. The links 308, 309 and 310 may for example be wireless links or broadband internet links. The system controller 301 provides overall system control in the communication system 300 including control of the zone controllers 302, 303 and 304. An authentication centre 318 provides via a link 319 to the system controller 301, which may be a wired or wireless

link, keys and related information required for authentication of users to operate mobile stations within the system 300 and to enable the encryption and decryption of information to be sent in secure communications in the communication system 300.

The zone controller 302 includes (or is associated with) an HLR (Home Location Register) database system 315. The zone controller 303 includes (or is associated with) an HLR database system 316. The zone controller 304 includes (or is associated with) an HLR database system 317. The HLR database systems 315, 316 and 317 provide examples of the Database Systems 1 and 2 described earlier with reference to FIG. 1. Each one of the HLR database systems 315, 316 and 317 may be replicated in each other one of those database systems. A system replication and synchronisation manager 314 is included in (or associated with) the system controller 301. The system replication and synchronisation manager 314 operates in the same manner as the system replication and synchronisation manager 103 described earlier with reference to FIGS. 1 and 2. Data from an HLR database system to be replicated in another database system, e.g. the database system 315 to be replicated in the database system 316, is delivered for replication via the appropriate links to and from the replication and synchronisation manager 314, e.g. the links 308 and 309.

FIG. 4 shows the zone controller 302 in more detail. The zone controller 302 includes the HLR ' database system 315 as shown in FIG. 3. The zone

controller 302 also includes a processor 401 which carries out functional operations of the zone controller 302 such as routing communications to and from mobile stations within the zone 305. The zone controller 305 also includes a VLR database 417. The VLR database 417 and the HLR database system 315 are both operably connected to the processor 401. The processor 401 stores relevant data which it receives in operation in the HLR database system 315 and in the VLR database 417 as appropriate and retrieves relevant data that needs to be delivered to other operational components of the system 300 from the HLR database system 315 and the VLR database 417 as appropriate. The processor 401 is able to receive messages from the replication and synchronisation manager 314 and to send messages to the replication and synchronisation manager 314 in the manner described earlier with reference to step 206 of the method 200 illustrated in FIG. 2.

An example of the HLR database system 315 is as follows. The HLR database system 315 stores data relating to mobile stations, ^λ MSs' of the system 300 for which the zone 305 is a home zone and pre-defined groups of MSs which are known as ^λ talk groups', TGs, for which the zone 305 is a home zone, i.e. the MS or TG is normally or mainly attached to one or more cells of the zone 305.

In a first database 405 of the HLR database system 315, data relating to MS profiles is stored. This data includes basic information about the identity of MSs known to the system 300 and authorised to use the system

100. The data may also include any parameters applied in the system 300 in the case of particular MSs, e.g. defining services of the system 300 to which each MS is given access or not given access. The data may also include details of TGs of which each MS is currently a member .

In a second database 407 of the HLR database system 315, data relating to MS locations is stored. This data concerns the current location of each MS for which the zone 305 is the home zone. The data is obtained for a given MS by a message sent from an appropriate component of the system 300 which knows where the MS is located in the system. For example, the component of the system 300 which sends such a message may be a base transceiver station to which the MS is currently attached for service. The data in the second database 407 may be recorded in the form of the identity of the zone controller or other zone component currently serving each MS . In a third database 409 of the HLR database system 315 data relating to MS keys is stored. This is data relating to (i) an individual key used for authenticated use of the system 300 by each MS; and (ii) an individual encryption key currently used by each MS. The data is recorded for each MS having the zone 305 as its home zone. The encryption key for each MS is the key provided to the MS to send and receive encrypted communications via the system 100 to another MS. This data may itself be encrypted. The encryption keys for use by individual MSs stored in the database 409 may have been provided by

the authentication centre 318 (FIG. 3) and delivered to the HLR database system 315 via the link 319, the system controller 301, the link 308 and the processor 401. Each key may also have been provided to each MS in question via the processor 401 of the zone controller 302 and the serving base transceiver station of the MS.

In a fourth database 411 of the HLR database system 315 data is stored relating to profiles of TGs for which the zone 305 is a home zone. This data includes basic information about the relevant TGs known to the system 300 and authorised to use the system 300. The data may also include any parameters applied in the system in the case of particular TGs, e.g. relating to services to which each TG is given access or not given access. The data may also include details of MSs that are currently members of each TG.

In a fifth database 413 of the HLR database system 315 data relating to TG locations is stored. This data concerns the current location of MSs of a given TG for which the zone 305 is the home zone. The data is obtained by messages sent from components of the system 300 knowing the current location of the relevant MSs.

In a sixth database 415 of the HLR database system 315 data relating to TG keys is stored for relevant TGs, i.e. TGs having the zone 305 as home zone. The data in the sixth database 415 includes, for each relevant TG, data relating to a group authentication key currently used by MSs that are members of the TG for group communications amongst those MSs. The data also includes for each relevant TG details relating to the encryption

key currently used by MSs that are members of the TG to send and receive group encrypted communications via the system 100 amongst the members of the TG. This data may itself be encrypted. The encryption keys for use by the MSs of the TG stored in the database 415, which may be additional to the keys stored for individual ( ^λ non- group' ) use by the MSs in the database 415, may have been provided by the authentication centre 318 (FIG. 3) and delivered to the HLR database system 315 via the link 319, the system controller 301, the link 308 and the processor 401. Each TG key may also have been provided to each MS which is a member of the TG in question via the processor 401 of the zone controller 302 and the serving BTS of the MS. The VLR (visitor location register) database 417 of the zone controller 302 holds data related to MSs and TGs currently attached to a BTS of the zone 305, for which the zone 305 is not a home zone. In other words, such MSs and TGs are Visitors' to the zone 305. If for example, a plurality of MSs and a particular TG have the zone 306 as a home zone, the data relating to these visiting MSs and the TG is delivered from the VLR database 417 via the processor 401 to the zone controller 303 via the link 311. The data is then stored in the databases of the HLR database system 316 of the zone controller 303 which correspond respectively to the databases 407 and 413.

The zone controller 302 includes a memory 419 which stores data, other than data stored in the HLR database system 315 and in the VLR database 417, and also

programs. The processor 401 works in conjunction with the memory 413 to obtain data and programs needed in operation by the processor 401.

Each of the zone controllers 303 and 304 has a structure and operation which are the same as has been described for the zone controller 302 with reference to FIG. 4. Each of the HLR database system 316 of the zone controller 303 and the HLR database system 317 of the zone controller 304 stores data in six different databases similar to the six databases of the HLR database system 315.

In addition, each of the database systems 315, 316 and 317 has six databases (not shown) which are replicas of corresponding databases of a first one of the other two database systems and six further databases (not shown) which are replicas of the second of the two other databases. These replica databases are all established through operation of the replication and synchronisation manager 314 in the manner described earlier with reference to FIG. 2.

Establishment of replica databases in the manner of the embodiments of the invention which have been described above can be performed more efficiently than prior art procedures taking into account that some data packages have to be replicated, and the replications have to be synchronised, in a particular order. An example of such ordering in the system 300 might for example be that details of MSs attached to a first cell of the zone 305, e.g. a new cell in the zone 305, have to be replicated and synchronised before MSs attached to

a second cell of the zone 305, e.g. a cell adjacent to a new cell; or that details of MSs attached to a given cell have to be replicated and synchronised before replication of TGs attached to the cell. The mobile communication system 300 may operate according to a set of known industry standard protocols. For example, it may operate in accordance with TETRA standards as defined by ETSI (European Telecommunications Standards Institute) . Alternatively, the system 100 could similarly be employed in a mobile telecommunications system operating according to another set of known industry standard protocols, such as the APCO 25 standards defined by the Association of Public Safety Communications Officials International (APCO) . The system 100 and the method 200 of replication embodying the invention which have been described earlier with reference to FIGS. 1 and are beneficial compared with the prior art in that it the system 100 and method 200 can always be used even in cases where two or more databases to be replicated are of different nature and/or of different implementation. Furthermore, unlike the prior art, the replication and synchronisation manager 103 employed in the method 200 may advantageously ensure that replicated data is consistent at all points in time during replication, thereby allowing the system 100 to be operational at all times.