GB2532992A - Transferring data between subscriber databases - Google Patents

Abstract

Transferring data relating to subscribers of a communication network from a source Home Location Register (HLR) or Home Subscriber Sever (HSS) 218a, 218b, 218c, etc, to a target HLR/HSS 218 is improved by transferring the records for each subscriber and updating the source and target HLR/HSS on a record by record basis and avoiding the need for any network signalling to reregister data after the migration. The Subscriber Data Migration SDM enactor 224 is a software agent responsible for moving one subscriber at a time. The SMD coordinator 222 is a software agent responsible for managing the migration of a number of subscribers by allocating a free SDM Enactor for each subscriber to be moved. During data transfer a record of an identified subscriber on the source subscriber database is locked, whilst at the same time access to other subscriber data on the source subscriber database is maintained. Transferring data may comprise converting (transcoding) extracted data to a format compatible with the destination subscriber database. Also disclosed is a mediation function 226 that routes a network operation message to a subscriber database in a telecommunication network having a plurality of subscriber databases.

Description

TRANSFERRING DATA BETWEEN SUBSCRIBER DATABASES

Introduction

The present disclosure relates to a method and system for transferring data between databases. In particular, the present disclosure relates to transfer of data relating to subscribers of a communication network contained in a Home Location Register (HLR) or a Home Subscription Server (HSS).

Background

The core network of a typical cellular telecommunications network includes at least one network entity for storing a database of subscribers and the services to which the subscribers are entitled. This entity, known variously as a Home Location Register (HLR) or a Home Subscription Server (HSS), is implemented as a database on a dedicated, physical computing device.

The HLR records for individual subscribers are continually being updated: by the network itself (in provisioning and customer management changes); by virtue of the mobility of the subscriber's device; and as a result of customer-input changes.

Current approaches to the migration of subscriber data require the preparation of a batch of subscriber records for migration and the transfer of the records listed in the batch as a group. To ensure that records in the batch are consistent, recordal of changes in the records of the source HLR (i.e. provisioning operations) are suspended until the batch transfer is completed.

This is a lengthy procedure depending upon the number of records in the batch. The suspension of provisioning actions is not only a reduction in customer service, but it can also expose the operator to the risk of revenue loss through fraud, as account blocks cannot be applied until the suspension is lifted.

A further problem is caused by inconsistencies, where changes initiated in the network during the process are failed, or even worse, lost, as a result of the data being extracted and then subsequently altered on the original (source) HLR/HSS.

Summary

According to a first aspect of the present disclosure there is provided a method of transferring subscriber data relating to a subscriber of a communication network from a source subscriber database to a destination subscriber database, wherein the source subscriber database is accessible in real time, the method comprising identifying a specific subscriber in the source subscriber database; selecting a software agent configured to transfer data associated with a single subscriber, and transferring subscriber data associated with the identified subscriber to the destination subscriber database using the selected software agent.

By the mechanism described it is possible to create a move procedure that is totally invisible to the customer and operationally simpler and cheaper for the operator.

The step of identifying may comprise identifying at least two subscribers and wherein for each subscriber identified selecting a specific corresponding software agent and transferring subscriber data associated with each subscriber using the corresponding selected software agents. Therefore Subscriber Data Migration is performed one subscriber at a time, rather than in a batch format of many thousands, or hundreds of thousands. This greatly reduces the time taken, and hence the window for data inconsistencies to occur, typically from 3 hours to 3 seconds.

The transferring subscriber data associated with each subscriber may be performed substantially simultaneously. This allows moving many subscribers concurrently. With a typical migration time of 1 to 3 seconds per subscribers, each software agent can sequentially move between 1200 and 3600 subscribers per hour. Using a pool of 50 software agents, 60 000 to 180 000 subscribers can be moved per hour.

The method may further comprise locking during data transfer a record of the identified subscriber on the source subscriber database, while at the same time maintaining other subscriber access to the source subscriber database. This prevents subscribers which data are not transferred from one database to another from experiencing a loss of service.

Transferring may comprise extracting the subscriber data from the source subscriber database and converting the extracted data to a format compatible with the destination subscriber database. Converting may comprise transcoding the extracted data.

The method may further comprise, for each subscriber data being transferred, updating a location of the subscriber data on at least one of a provisioning system and a mediation function, such that a network operation message can be directed to the appropriate destination subscriber database. This allows new operations to be redirected seamlessly without service loss.

The data relating to a subscriber may comprise a dynamically-learned data. For example the dynamically-learned data may include a subscriber's location. This prevents the need for re-registration of the user as a result of the transfer of data. As a consequence it also removes the surge of signalling caused by re-registration and the loss of customer and operator service during the hours following the migration.

The data relating to a subscriber may further comprise at least one of statically provisioned data and customer-configured setting. For example the statically provisioned data may include permitted services supplied from the provisioning system.

The source subscriber database may be associated with a first network operator and the destination subscriber database may be associated with a second network operator.

According to a second aspect of the present disclosure, there is provided a network entity comprising at least one processor configured to execute: a plurality of subscriber database interface modules, in communication with respective databases among a plurality of subscriber databases; at least one subscriber transfer agent configured to transfer subscriber data associated a single subscriber between a source subscriber database and a destination subscriber database among the plurality of subscriber databases, and a coordinator module adapted to search for a subscriber data associated with an identified subscriber in the source subscriber database and to instruct the at least one software agent to transfer the subscriber data to the destination subscriber database.

The network entity may comprise at least two subscriber transfer agents and wherein the coordinator is adapted to instruct the at least two subscriber transfer agents individually.

The processor of the network entity may further execute: a mediation function that routes a network operation message to a given subscriber database; wherein the routing of said message includes: obtaining, from a payload section of the message, a subscriber identity; obtaining, a database identity number including a reference to a subscriber database associated with the subscriber identity, the number being shared with each subscriber database in the plurality of subscriber databases; and routing the message to the subscriber database corresponding to the subscriber identity by matching the subscriber identity to corresponding subscriber database.

The at least one subscriber transfer agent may be adapted to confirm successful completion of data transfer to the coordinator.

The at least one subscriber transfer agent may be adapted to update a new location of subscriber data to at least one of a provisioning system and a mediation function.

According to a third aspect of the present disclosure, there is provided a telecommunication network entity comprising at least one processor to configured execute a mediation function that routes a network operation message to a subscriber database; wherein the routing of said message includes: obtaining, from a payload section of the message, a subscriber identity; obtaining a database identity number including a reference to a subscriber database associated with the subscriber identity, the number being shared with each subscriber database in the a plurality of subscriber databases; and routing the message to the subscriber database corresponding to the subscriber identity by matching the subscriber identity to the subscriber database.

The subscriber identity may be contained in a payload section of the message. In particular, the subscriber identity may be contained in a specific portion of the payload section. Examples of subscriber identity may include an IMSI or MSISDN for the subscriber. The telecommunication network entity of the second aspect and of the third aspect may be the same entity having processors as set out in both aspects.

Each of the plurality of subscriber databases in the preceding aspects may be a Home Location Register, HLR, or a Home Subscription Server, HSS.

According to a fourth aspect of the present disclosure, there is provided a method of routing a network operation message in a telecommunication network having a plurality of subscriber databases comprising: extracting a subscriber identity from a payload section of the message; obtaining a database identity number including a reference to a subscriber database associated with the subscriber identity, the number being shared with each subscriber database in the plurality of subscriber databases; and routing the message to the subscriber database corresponding to the subscriber identity by matching the subscriber identity to the subscriber database. This obviates the need to update the 11-ILR Number' identity in each migrated subscriber's MSC and SGSN records.

The step of extracting the subscriber identity may comprise identifying a payload section of the message and extracting the subscriber identity from the payload section.

Another aspect of the present disclosure provides a computer program comprising instructions arranged, when executed, to implement a method in accordance with any one of the above-described aspects. A further aspect provides machine-readable storage storing such a program.

Various respective aspects and features of the present disclosure are defined in the appended claims.

It is an aim of certain embodiments of the present disclosure to solve, mitigate or obviate, at least partly, at least one of the problems and/or disadvantages associated with the prior art. Certain embodiments aim to provide at least one of the advantages described below.

Brief Description of the Drawings

Various aspects of the present disclosure will now be described by way of example only and with reference to the accompanying drawings, of which: Figure 1 is a diagram showing certain elements of a typical cellular telecommunications network; Figure 2 is a diagram of a mobile network according to an embodiment of the present

disclosure;

Figure 3 is a flowchart of a method of transferring subscriber data according to an

embodiment of the present disclosure; and

Figure 4 is a flowchart of a method of routeing a message in a telecommunication network according to an embodiment of the present disclosure.

Detailed Description

Figure 1 shows certain elements of a typical cellular telecommunications network 100. A Mobile Subscriber (MS) 112 consisting of a User Equipment (UE) and a Subscriber Identity Module (SIM) accesses a mobile radio network 120, which does not have to be operated by the supplier of their services. The radio network 120 must establish the validity and extent of the services which it may offer to that subscriber. It does this by communicating with a Home Location Register/Home Subscription Server (HLR/HSS) (118a, 118b, 118c etc.), which is a fast computer database operated by the subscriber's supplier. The permitted services are enabled in this HLR/HSS database 118 by the supplier's customer management and provisioning system 116. Any communications directed towards the subscriber will arrive in the supplier's own mobile core 114, and then also communicate with the HLR/HSS 118 to be further routed to the mobile subscriber 112.

Similarly, any subsequent change to the subscriber's permissions will be modified in the HLR/HSS 118 by the Provisioning System 116 and subsequently updated in the relevant mobile radio and core 120 to enforce the change. Such changes may add or remove services, and most importantly, may immediately terminate all services if there is evidence that the device is stolen or is being used in a fraudulent or illegal manner.

Mobile networks frequently need to move subscribers from one HLR/HSS instance (118a, 118b, 118c etc.) to another. This is an operationally difficult process which significantly impacts on customer service.

The HLR/HSS system 118, like any computer system, is limited in capacity and processing ability, so a mobile operator may require many such HLR/HSS instances (118a, 118b, 118c etc.) to support all of their customers. It is thus necessary to direct the communications to the correct HLR/HSS instance (118a, 118b, 118c etc.), the one holding the data for the specific subscriber. This is necessary for both network communications and for provisioning changes. The routeing is achieved by two mediation functions, Fl and F2 (126a, 126b) for the network and provisioning paths respectively. When the subscriber is initially connected to the HLR/HSS 118, the specific instance of HLR/HSS (118a, 118b, 118c etc.) will be chosen, perhaps by a load balancing calculation, and the mediation functions Fl and F2 (126a, 126b) instructed as to the choice for their own databases to store.

Recently the industry has seen the emergence of "layered architecture" HLR/HSS.

These use multiple computer servers internally to achieve an unlimited capacity, and hence appear as a single logical HLR/HSS, apparently avoiding the need for mediation functions Fl and F2. However an operator may still require to replace one such layered HLR/HSS with another, perhaps from a different vendor, so the same multiple HLR/HSS position occurs.

As part of routine operation, the network operator must ensure that none of the HLR/HSS instances (118a, 118b, 118c etc.) becomes overloaded. This may require that subscribers currently connected to one instance are moved to another. Reasons to do this include as example: * Capacity expansion where new empty HLR/HSS instances are introduced and the operator wants to balance usage more evenly.

* An increase in subscriber usage which means that one or more HLR/HSS experiences an increase in demand, over that previously seen, hence requiring some of the demand to be moved to a less loaded instance.

* An upgrade or replacement, requiring all subscribers to be removed from the HLR/HSS instance leaving it empty, and suitable for removal.

* A change of HLR/HSS vendor.

Hence the operator must move some or all of the subscribers from one HLR/HSS instance (118a, 118b, 118c etc.) to another. This is known as a Subscriber Data Migration (S DM).

Before we discuss a typical Subscriber Data Migration procedure, we need to describe all the changes are necessary, as the procedure must update many systems and data items: 1. In the HLR/HSS, statically provisioned data supplied originally from the Provisioning System, such as permitted services and operator defined bars.

2. In the HLR/HSS, dynamically learned data, such as the subscriber's location (required for terminating services) or SMS Message Waiting data (required for SMS delivery).

3. In the HLR/HSS, service configuration data, such as customer selected call diverts and barring profiles, defined directly by the customer.

4. In the Mediation Functions Fl and F2, routeing data specifying the instance of the HLR/HSS for each subscriber 5. In the Mobile Core network, the identity of the HLR/HSS instance holding the subscriber. This is supplied when the subscriber registers on that part of the Mobile Core and may be used for communications to the HLR/HSS: for example, customer-defined changes to divert or bar services.

All of this data needs to be moved and modified correctly, in a consistent manner such that neither the subscriber service nor the networks operator functions are impaired. This is a difficult process.

A typical Subscriber Data Migration procedure might operate as follows: 1 A set of subscribers to be moved is identified, from one or more source HLR/HSS.

2 One or more destination HLR/HSS is chosen.

3 The Provisioning System is configured to suspend all changes to the set of subscribers to be moved. Depending on the capability of this system, this suspension may be limited to only the affected subscribers, or to a superset containing them, or most commonly, to the entire subscriber base.

4 A data extraction procedure is run on each source HLR/HSS to extract the service data Note that although the statically provisioned data could be supplied directly from the Provisioning System, and thereby avoid HLR/HSS extraction, the dynamically-learned and customer-defined data must be extracted, as it is held nowhere else.

The extracted data is now converted to a format suitable for loading into the destination HLR/HSS. If the source and destination HLR/HSS are from different vendors, this conversion can be a significantly large task.

6 The converted data is now loaded into the destination HLR/HSS.

7 The mediation functions Fl and F2 are updated to point the moved subscriber identities to their new HLR//HSS.

8 Network signals are generated to encompass all moved subscribers, to inform the Mobile Core that their currently stored HLR identity is incorrect 9 The Provisioning system suspension is ended and the backlog of actions completed.

It is clear that this is a lengthy procedure. The suspension of provisioning actions is not only a reduction in customer service, but it can also expose the operator to the risk of revenue loss through fraud, as account blocks cannot be applied until the suspension is lifted.

A further problem is caused by inconsistencies, where changes initiated in the network during the process are failed, or even worse, lost, as a result of the data being extracted and then subsequently altered on the original (source) HLR/HSS.

Since normal HLR/HSS operation does not require any need to set the dynamically-learned data, it is frequently the case that this cannot be loaded into the destination HLR/HSS. In this case, it is necessary to perform a further action: to request all migrated subscribers to re-register with the home network and thus to redefine the dynamically-learned data in the destination HLR/HSS. The action to do this can be combined with Step 8 (in which network signals are generated to encompass all moved subscribers), but the result is a large volume of signalling that can expose the network to adverse load. Worse, until this dynamically learned data is reset in this way, no mobile terminated actions, such as calls or texts, can be delivered to the migrated subscribers. Similarly, although provisioning updates may be made to the destination HLR/HSS as soon as the suspension is lifted, those changes cannot be sent out to the mobile radio core, and take effect, until after re-registration, exposing the operator to fraud.

The mechanisms available for Step 8 are rather limited. The 3GPP Data Restoration procedure (TS 23.007) defines a MAP message called Reset which can be sent to all known Mobile Switching Center (MSC) and Serving GPRS (General Packet Radio Service) Support Node (SGSN) to flag the relevant subscribers as needing confirmation. Each subscriber will then reregister upon the first radio contact between the Radio core and the user device. This can occur immediately if the subscriber tries to make a call, or upon a periodic update, typically every 2 hours. Thus the step will trigger a mass re-registration over the next few hours, during which the subscribers will be unable to receive calls or texts.

Just sending the Reset is no easy step: one first needs to compile a list of all the MSC and SGSN which may potentially be holding the affected subscribers. This may be a bigger list than just those MSC and SGSN holding the subscribers at the start of the data extraction because of subscriber mobility during the process. A mobile network with extensive roaming agreements may find this list holds in excess of 10,000 entries; a Reset message must be sent to every entry in the list.

The second problem is how to identify only the affected subscribers. Reset can do this by one of two ways: you can define all subscribers on a specific HLR identity, or all subscribers within a specific International Mobile Subscriber Identity (IMS!) range.

Using Reset with a specified HLR identity causes all subscribers on the source HLR/HSS to be impacted, not just those migrated. Since a single HLR/HSS may hold five million entries, yet a typical Subscriber Data Migration may be one hundred thousand entries, it is easy to see that the impact is 50 times greater than it needs to be, creating a deluge of signalling, risking overload.

One can try and time the procedure for the 'maintenance window' traditionally used in telecommunications. However, the impact of worldwide roaming, machine-to-machine communications, and an increasing 24x7 lifestyle, especially for businesses like transport infrastructure, mean that the days of minimal night-time traffic have gone: performing the procedure at 2 AM may reduce the impact, but not significantly.

Worse, the re-registration is only triggered when the device contacts the radio network. If the subscriber has turned their device off (known as an 'IMSI detach' operation in mobile telephony), then there will be no radio contact until the subscriber wakes up and turns it on again -an WS! attach'). So one not only sees a deluge of signalling for 50 times the number of affected subscribers, one sees it at the start of the morning peak traffic period.

This is an open invitation to network overload and considerable service disruption. Alternatively, one could use Reset to specify a range of IMSI to define the affected customers. The IMSI is a unique identity associated with the SIM at manufacture. However, the degree of match between one or more IMSI ranges and the subscribers being moved will not be exact, and attempting to avoid excessive mismatch may create many allocation difficulty for the network operator, reducing their ability to load balance the various HLR/HSS. So the number of subscribers affected must be a superset of those migrated, creating a similar signalling deluge to the use of HLR Identity, but further compounded by the need to send the Reset message to each of the 10,000 MSC/SGSN entries for each of the IMSI ranges holding subscribers moved.

At the extreme, one can send a Reset message for a specific IMSI, hence achieving a perfect match between affected and migrated subscribers. However, it is impractical to send one Reset message for each of the 100,000 subscribers migrated to each of the 10,000 MSC/SGSN entries as this would lead to a billion messages. So one would have to try and send the Reset message to the specific MSC and SGN for that subscriber. But the effects of mobility mean that any data extracted from the source HLR/HSS starts to become stale immediately, and not all subscribers will be on the same MSC and SGSN at the time the Reset for their IMSI is sent. The Reset sent on their behalf will thus be ineffective as it will go to the wrong MSC and SGSN. These subscribers will continue to have no terminating services indefinitely.

An operator may attempt to repair such errors by observing the timestamps of subsequent re-registrations, and extracting lists of subscribers who were involved in the migration who have not yet reregistered. The whole Reset procedure can then be repeated. This is an iterative process, but after several days many of the subscribers will recover service.

Because of the way a single Reset message can trigger multiple signalling events, the message is now regarded as a security risk and a vector for a malicious party to cause a Denial of Service attack by injecting a relatively small number of Reset messages and triggering a flood of re-registrations and hence signalling overload. Thus increasingly mobile networks are applying security functions on network signalling interconnections; a Reset message from outside of the network will be filtered and discarded, regardless of whether its motivation is genuine or not. That will cause the migrated subscribers to suffer permanently impaired service, regardless of how many times the Reset approach is repeated. An alternative message exists which can be used in these cases: CancelLocation. However, a CancelLocation must be sent individually for each migrated subscriber to each of the correct MSC and SGSN entries, with the same 'stale data' problem and the same iterative approach. However, CancelLocation is far more disruptive to the customer, and will immediately terminate any call or data session the customer is making. The repeated issuing of these CancelLocation messages is thus likely to be intolerably disruptive.

Certain embodiments of the present disclosure enable a Subscriber Data Migration (SDM) to be performed at any time of day with no significant network impact and with no substantial customer service loss.

Certain embodiments introduce two new software functions in the source HLR/HSS: the SDM coordinator and the SDN enactors. There will be one coordinator and a pool of many enactors for each SDM operation.

Figure 2 shows elements of a cellular telecommunications network 200 including: a mobile phone (often referred to as a user equipment, or UE) 212, representing a plurality of such devices; a mobile radio core 220; a provisioning system 216; a plurality of (e.g. three) subscriber databases 218a, 218b, 218c; a mobile core 214; two mediation functions, 226a and 226b; a SDM coordinator 222; and a pool of SDM enactors 224a, 224b, 224c.

The provisioning system 216 is part of the network's customer management and billing system. This will allocate new subscribers' numbers (i.e. IMSI and MSISDN), and act as the master reference database of all services permitted for that subscriber, tariff, etc. To do this, it is responsible for creating suitable data entries for the subscriber in network elements such as the HLR/HSS 218 and maintaining these if the service is later modified, or terminated.

Each subscriber database 218 (HLR/HSS A, B or C) is a network element as defined in the 3rd Generation Partnership Project (3GPP) Standards performing the Home Location Register/Home Subscriber Server function. It acts as a fast real time database for network events and controls the services that may be used by the subscriber. It also provides the authentication keys to validate access. It stores subscriber location for routing of terminating events, so the subscriber can receive calls and texts. It also stores customer define preferences, such as divert-to numbers.

The mobile radio core 220 comprises all the functions of a mobile network including Radio Access and the Circuit-Switch and Packet Switch cores, as defined by 3GPP. While not shown, the mobile radio core 220 includes two 3GPP entities, the Mobile Switching 35 Centre, MSC and Serving GPRS support node, SGSN.

The mobile core 214 comprises all the functions of the home mobile network, specifically the entity involved in delivering calls towards a subscriber: the GMSC (Gateway Mobile Switching Centre).

The SDM coordinator 222 is a software agent responsible for managing the migration of a number of subscribers by allocating a free SDM Enactor for each subscriber to be moved, requesting the migration, and keeping records of who has been successfully migrated and who encountered what failure, for subsequent analysis and repair.

The SDM enactor 224 is a software agent responsible for moving one subscriber at a time. After each subscriber is moved, the SDM Enactor reports the success or failure to the SDM coordinator and awaits the next instruction.

The mediation functions 226 are routers, capable of routing messages relating to a specific subscriber to the instance of the HLR/HSS which hold the data. Mediation functions Fl, 226a, is for network messages and F2, 226b, for provisioning commands.

Note that different HLR may belong to a specific operator or to different operators. In case of Mobile Virtual Network Operators (MVN0s), the virtual operator may rent a portion of the HLR from the "non-virtual" operator.

Figure 3 shows a flow diagram of a method for performing Subscriber Data Migration (SDM).

In a first step 300, the SDM coordinator 222 identifies a single subscriber or a list of subscribers in a source HLR/HSS (HLR A -218a, say) to be moved to a destination HLR/HSS (HLR C -218c, say). The SDM coordinator 222 is supplied with either a list of the subscribers to be moved, or a set of criteria to determine which subscribers should be selected to be moved. In the former case the list is a set of subscriber identifies, such as IMSI or MSISDN. In the latter case, the SDM Coordinator 222 searches the database in the source HLR/HSS 218a seeking subscribers matching the search criteria. When either the supplied list is complete, or no more matching subscribers can be found, the SDM Coordinator's 222 task is completed and it can report the SDM operation is finished.

Then at step 302, for each subscriber selected, the SDM Coordinator 222 allocates an idle SDM Enactor (224a, say) from a pool of SDM enactors 224, and instructs (step 304) the allocated SDM Enactor 224a to migrate that one specific subscriber to the required destination HLR/HSS, for example HLR/HSS C 218c.

For each subscriber to be moved, the allocated SDM Enactor 224a performs the following tasks. First (Step 306) the SDM enactor 224a locks access to subscriber data on the source HLR/HSS 218a.

Applying a lock around a database entry is a known technique to prevent conflicting update operations, and it is expected that the HLR/HSS 218a would already implement such a subscriber lock for its own data integrity purposes. An implemented lock can be re-used; if no lock functionality is in fact available, a new lock must be applied. For the duration of the lock, any HLR/HSS operation for this subscriber, whether requested by network signalling or by the provisioning system 216 will be temporarily stalled. Similarly, any in-progress transaction will hold the lock briefly, preventing the migration action from starting until the transaction has completed. Data integrity is thus achieved.

With the subscriber data now protected by the lock, the SDM Enactor 224a extracts (step 308) all of the subscriber data: this includes the statically provisioned data, the dynamically-learned data and the customer-configured setting.

Data conversion may be required (Step 310). In this case, the SDM Enactor 224a performs data conversion of the extracted data (Step 311). This involves the conversion to the provisioning interface to the destination HLR/HSS 218c. This does not need to be the same syntax as that used by the provisioning system 216 itself, and indeed, it needs to offer capabilities not used by the provisioning system 216.

While not shown, encryption of subscriber data may also be required. Some data such as the AKA secret key can be very sensitive, so this may be encrypted for the transfer with a temporary transport key.

The technique for doing this is known from the conventional secure transfer of other sensitive data from the provisioning system 216, or in data transfer between SIM manufacturer and provisioning system and/or HLR/HSS when new subscriber connections are added.

In these cases, the SIM manufacturer will generate a key "Ki", then pass the key in a protected (enciphered) format to the mobile network. The SIM data, including the protected secret key may be stored in intermediate systems, such as the provisioning system 216. The key is then passed to the HLR 218, still protected, during a creation of a new subscriber entry. It is only decrypted inside the HLR 218. It may be subsequently re-encrypted for storage using a different 'storage' key. Depending on how the process operates, the transport key encryption may be specific to each SIM, or may apply to a batch file containing all the SIM ordered in one batch. Likewise, the transport key will vary from supplier and supplier. The point is to prevent the secret key, Ki, ever being passed or held in clear. In reuse of this capability for HLR Migration, the secret AKA key, Ki, is extracted from the storage protection as for any other network usage of this key. It is then encrypted using a transport key allocated for the purpose, and received at the destination HLR in the same format as any new connection. So as with a new connection, the HLR to HLR migration has not passed the Ki in clear.

Once converted, the subscriber data are transferred (step 312) to the required destination HLR 218c. To do so, the SDM Enactor 224a makes a connection to the destination HLR/HSS provisioning interface and recreates the subscriber on the destination HLR/HSS 218c using the converted extracted data.

All three elements of the data must be transferred (i.e. statically provisioned data, dynamically-learned data and customer-configured setting data). It is crucial that the dynamically-learned data is transferred to the destination HLR/HSS 218c, as it is the transfer of this data that removes the need for any re-registration and hence any network signalling. This also means that terminating events, such as calls, texts and provisioning changes may be directed towards the relevant MSC and SGSN On the mobile core 214) immediately, without waiting the hours necessary for the re-registrations to occur, thus removing both the customer's service loss and the operator's fraud exposure.

The transfer may or may not be successful (step 314).

If the creation of the subscriber on the destination HLR/HSS fails, then the SDM Enactor should prepare an error report listing the subscriber's identity (IMS! or MSISDN) and the error reason in a failure log (Step 324). Reasons for failure might include for example: the destination HLR/HSS 218c is full, or the destination HLR/HSS 218c is not configured to offer one of the subscribers services. The SDM Enactor 224a then terminates the specific subscriber's migration by releasing the data lock on the source HLR/HSS 218a (Step 326).

All stalled operations which were awaiting the release of this data lock are then processed, restoring all service to this subscriber.

The SDM Enactor 224a can then report its completion (with failure) to the SDM Coordinator 222 and its readiness to be given the next subscriber to be migrated (Step 328). Migration of other subscribers will be unaffected by any migrations that fail, and any subscribers whose migration fails will continue to receive service on the source HLR/HSS 218a. The reasons for failure recorded in the log can be manually studied subsequently, for remedy and a repeat scheduling of the migration in a subsequent SDM Coordinator 222 request.

If the creation of the subscriber on the destination HLR/HSS 218c succeeds, then the SDM Enactor 224a performs a number of updates (Steps 316, 320). It updates the subscriber data on the source HLR/HSS 218a (Step 316) to report the subscriber has been moved to the destination HLR/HSS 218c. The SDM Enactor 224a then terminates the specific subscriber's migration by releasing the data lock on the source HLR/HSS 218a (Step 318). All stalled operations which were awaiting the release of this data lock are then processed, restoring all service to this subscriber. As in the failure case, the updates have suffered a momentary delay only, and are still suitable for execution. The first stage of each operation will be to read the subscriber data. Before any other processing is considered, the operation acts on the 'moved to' data. This 'moved to' data informs transaction handlers that the message should be forwarded to the new HLR/HSS and that all other elements of the subscriber data in the source HLR are now considered obsolete.

The SDM enactor 224a also needs to updates the routeing entries for the migrated subscriber in the mediation functions Fl 226a and F2 226b (Step 320). At this stage, the mediation functions Fl 226a and F2 226b have not changed, so any new network signalling will continue to be routed by Fl 226a to the source HLR/HSS 218a, where upon encountering the 'moved to' attribute, it will be forwarded accordingly. Likewise F2 226b will send any new provisioning system 216 operations to the source HLR/HSS 218a for forwarding or rejection as chosen. By updating the routeing entries all new network and provisioning operations will now be directed towards the destination HLR/HSS 218c and be performed without impact from the migration. This includes any rejected operations being retried. The functions Fl 226a and F2 226b may have many instances for capacity, and the changes may either be distributed internally from a 'master' Fl and master 'F2', or alternatively, the SDM Enactor 224a will need to make the change to each instance of Fl and each instance of F2. Should any of these updates fail, there is no need to reverse the subscriber migration, as the subscriber's service will continue unaffected by the obsolete mediation entry because of the forwarding approach described. However, the SDM Enactor 224a should write a record of the failure to a log file for post migration resolution.

One further task remains: The SDM enactor should add the successfully moved subscriber identity to a completion log and signal its readiness to be given the next subscriber to be migrated (step 322).

After the whole migration process is completed, and if the network operator is satisfied the destination HLR/HSS 218c is stable under its new demand, and all errors in updating the mediation functions Fl and F2 are resolved, then the successful migration log is used to delete the residual entries on the source HLR/HSS 218a with their 'moved to' attributes. Since all the mediation functions were long since updated, there are no operations for the moved subscribers arriving at the source HLR/HSS 218a and this 'clean up' can be done at leisure.

By using a pool of SDM Enactors 224a, 224b, 224c, the migration of each subscriber occurs in isolation from, and with no dependence upon, the migration of any other subscriber. It is thus possible to use many SDM Enactors to move many subscribers concurrently. With a typical migration time of 1 to 3 seconds per subscriber, each SDM Enactor 224 can sequentially move between 1200 and 3600 subscribers per hour. Using a pool of 50 such SDM Enactors 224, the aggregate rate is 60,000 to 180,000 subscribers per hour.

Note that the time it takes to migrate one subscriber is so short (1 to 3 seconds) that the delay is well within the fimeout for a typical network or provisioning request (i.e. 10 to 15 seconds). A network signalling operation would normally be expected to complete within a fraction of a second, thus a 2 or 3 second delay is acceptable for the few messages for a specific subscriber arriving precisely during that subscriber's migration. Thus apart from a momentary delay, the operation will be unaffected.

If a network signalling operation has been prevented during migration, a stalled network signalling operation is then created, the source HLR/HSS 218a forwards the signalling to the recorded destination HLR/HSS 218c where the operation will be processed normally. Having forwarded the operation, the source HLR/HSS 218a performs no other function in the operation's execution, this is now the responsibility of the destination HLR/HSS 218c.

Reference to "stalled commands" above relates to the use of a data lock on the subscriber's data. In the conventional software/database mechanism known as a "semaphore", a software operation must acquire the lock before it can access the data, if the lock is already taken it must wait in a queue. When the current holder of the lock completes their operation, the lock is released and queued requests are then processed in turn, each acquiring and eventually releasing, the lock. Hence only one activity is allowed access to the data at a time, preventing multiple access conflicts.

In the HLR Migration activity of the present disclosure such a subscriber data lock is used: indeed, subscriber data lock exists in typical HLR implementations. HLR Migration is an operation requiring lock protection, hence all network and provisioning requests arising during the migration period become queued (i.e. stalled). When the migration has completed, the data is modified in the source HLR to state that the subscriber has been moved, and to where. Thus as each queued transaction is processed in turn, they receive the information that the subscriber is no longer in this (source) HLR. The queuing and dispatching of the queue entries is inherent in the implementation of a data lock 'semaphore'.

For network transactions, the signalling is forwarded on to the new (destination) HLR where it can be processed unaffected (assuming the duration of the delay was only a few seconds).

For stalled provisioning system created operations, the source HLR/HSS 218a could forward the request to the recorded destination HLR/HSS 218c in the same manner as for network signalling. However, the complexity and non-standard nature of provisioning interfaces makes this a more difficult challenge, especially if the source and destination HLR/HSS are from different vendors. Forwarding provisioning commands raises new challenges on the technical mechanism used as transport, authenticating the access for the creation and deletion of services and subscribers, and so on. A simpler and effective alternative relies on the availability of a retry mechanism (not available on the network interface). The source HLR/HSS 218a rejects the provisioning system request with an error, indicative of a short term temporary problem, provoking a retry. The retry will be sent to the new HLR because the mediation function has been updated during the migration, and hence will be successful.

Network operation can be affected by data migration. This is because the MSC and SGSN (in the mobile radio core 220) are given an "HLR Number" identity during the original registration process, and this identity has not been changed by the subscriber data migration. The 3GPP specifications do not permit a way of modifying this identity, once downloaded. Any network operations which are generated by the MSC or SGSN on behalf of the subscriber which are addressed using this HLR Number identity, instead of an IMSI or MSISDN subscriber key, will thus go to the wrong place. TS 29.002 defines a number of operations which are permitted to be addressed in this manner.

The solution is to avoid using the individual HLR identifies (i.e. the HLR Global Titles) as the HLR Number identity in such network operations, and to allocate a new identity that is common to all HLR/HSS in the operator's network.

Figure 4 is a flowchart of a method of routeing a network operation message in a telecommunication network having a plurality of subscriber databases, where the network operation is generated by the MSC or SGSN on behalf of the subscriber and is addressed using an HLR identity common to all HLR/HSS.

Such network messages are defined by 3GPP specifications (e.g. TS 29.002 for MAP) and include a header portion and a payload portion.

At step 400, the mediation function extracts a subscriber identity, such as IMSI or MSISDN, from a network message for performing an operation. This is achieved by extracting the subscriber identity from the payload section of the message. The mediation function decodes the message in exactly the same way as would the target HLR. The only difference is that the majority of the message can be ignored by the mediation function. Only the subscriber identity (IMS! or MSISDN) need be extracted, and that is typically the first or second item in such a message The mediation function works on two levels. The first level is purely an address-based router, using the message address in the SCCP layer of the protocol. The second level is to use the MAP (or other HLR/HSS-related protocol) to derive the identity if the SCCP address is insufficient.

The mediation function also receives (at step 402) the shared HLR identity (i.e. a database identity number that is common to all subscriber databases). The operator configures the Global Title routeing in their signalling network to deliver these HLR Number' addressed messages to the mediation function Fl.

The Mediation Function recognises these addressed messages such that any message sent to the shared HLR Identity' is inspected to derive the subscriber identity, i.e. the IMSI or the MSISDN.

The mediation function then routes (step 404) the message to a subscriber database associated with the subscriber identity.

As a result of the use of a per-subscriber mediation function, migration of subscribers one by one is enabled, such that the duration of the process is short enough to avoid a service outage using the queuing/locking mechanism and forwarding. Furthermore, the second-level mediation function capability may be used to avoid the problem of changing the stored HLR identity.

The functionality in Fl can be extended to be configured with one or more such 'HLR Number' identities, and if messages are received addressed to them, the mediation function needs to extract the specific subscriber key from the message payload, where it is always a mandatory parameter. Note that at any time, only a single HLR Number identity would be used. However, if that identity ever had to be changed, such as by a change to a national number plan, then two HLR Numbers might be used concurrently. The key is that it wouldn't matter which was received, as they would both route identically. By configuring all HLR to use the new HLR Number, then over time, all subscribers would be using the new one, and the older HLR Number could be removed. Such changes to national number plans typically 'parallel run' such conversions for 6 or 12 months.

One advantage of the preceding disclosure is that subscribers can be migrated between HLR/HSS with no significant loss of customer service, no effective loss of customer data, no increase in network signalling and no loss of provisioning ability. Furthermore, the work is contained purely in the HLR/HSS and mediation domains, and is therefore easier to schedule as no liaison with the support department of the provisioning system is required to suspend service. Because the network and customer impact is so small, it is now possible to run these migrations at any time of day, thereby gaining a 24 hour maintenance window and avoiding the need for 'out of hours' overtime. The time taken to completely move an entire HLR/HSS worth of subscribers is now reduced to a day, making upgrade procedures faster and cheaper.

A skilled person will appreciate that variations of the disclosed arrangements are possible without departing from the scope of the appended claims. Accordingly, the above description of specific embodiments is made by way of example only and not for the purposes of limitation. It will be clear to the skilled person that minor modifications may be made without significant changes to the operation described.

It will also be well understood by persons of ordinary skill in the art that whilst the described embodiments implement certain functionality by means of software, that functionality could equally be implemented solely in hardware (for example by means of one or more ASICs (application specific integrated circuit)) or indeed by a mix of hardware and software. As such, the scope of the present invention should not be interpreted as being limited only to being implemented in software.

Lastly, it should also be noted that whilst the accompanying claims set out particular combinations of features described herein, the scope of the present invention is not limited to the particular combinations hereafter claimed, but instead extends to encompass any combination of features or embodiments herein disclosed irrespective of whether or not that particular combination has been specifically enumerated in the accompanying claims at this time.

Claims (1)

1. CLAIMS 3. 6.

   A method of transferring subscriber data relating to a subscriber of a communication network from a source subscriber database to a destination subscriber database, wherein the source subscriber database is accessible in real time, the method comprising: identifying a specific subscriber in the source subscriber database; selecting a software agent configured to transfer data associated with a single subscriber, and transferring subscriber data associated with the identified subscriber to the destination subscriber database using the selected software agent.

   A method as claimed in claim 1, wherein identifying comprises identifying at least two subscribers and wherein for each subscriber identified selecting a specific corresponding software agent and transferring subscriber data associated with each subscriber using the corresponding selected software agents.

   A method as claimed in claim 2, wherein transferring subscriber data associated with each subscriber is performed substantially simultaneously.

   A method as claimed in any preceding claims, further comprising locking during data transfer a record of the identified subscriber on the source subscriber database, while at the same time maintaining access to other subscriber data on the source subscriber database A method as claimed in any preceding claims wherein transferring data comprises extracting the subscriber data from the source subscriber database and converting the extracted data to a format compatible with the destination subscriber database.

   A method as claimed in claim 5, wherein converting the extracted data comprises transcoding the extracted data.

   A method as claimed in any preceding claims further comprising, for each subscriber data being transferred, updating a location of the subscriber data on at least one of a provisioning system and a mediation function, such that a network operation message can be directed to the appropriate destination subscriber database.

   8 A method as claimed in Claim 1, wherein the data relating to a subscriber include dynamically-learned data, thereby alleviating the need for any subscriber re-registration.

   9. A method as claimed in claim 8, wherein the data relating to a subscriber further include at least one of statically provisioned data and customer-configured setting.

   10. A method as claimed in Claim 1, wherein the source subscriber database is associated with a first network operator and the destination subscriber database is associated with a second network operator.

   11 A network entity comprising: at least one processor configured to execute: a plurality of subscriber database interface modules, in communication with respective databases among a plurality of subscriber databases; at least one subscriber transfer agent configured to transfer subscriber data associated a single subscriber between a source subscriber database and a destination subscriber database among the plurality of subscriber databases, and a coordinator module adapted to search for a subscriber data associated with an identified subscriber in the source subscriber database and to instruct the at least one subscriber transfer agent to transfer the subscriber data to the destination subscriber database.

   12. A network entity as claimed in claim 11, comprising at least two subscriber transfer agents and wherein the coordinator module is adapted to instruct the at least two subscriber transfer agents individually.

   13 A network entity as claimed in claim 11 or 12 wherein the processor further executes a mediation function that routes a network operation message to a given subscriber database; wherein the routing of said message includes: obtaining, from a payload section of the message, a subscriber identity; obtaining, a database identity number including a reference to a subscriber database associated with the subscriber identity, the number being shared with each subscriber database in the plurality of subscriber databases; and routing the message to the subscriber database corresponding to the subscriber identity by matching the subscriber identity to corresponding subscriber database.

   14. A network entity as claimed in claim 11, wherein the at least one subscriber transfer agent is adapted to confirm successful completion of data transfer to the coordinator.

   15. A network entity as claimed in claim 11, wherein the at least one subscriber transfer agent is adapted to update a new location of subscriber data to at least one of a provisioning system and a mediation function.

   16. A telecommunication network entity comprising at least one processor to configured execute: a mediation function that routes a network operation message to a subscriber database; wherein the routing of said message includes: obtaining, from a payload section of the message, a subscriber identity; and obtaining a database identity number including a reference to a subscriber database associated with the subscriber identity, the number being shared with each subscriber database in a plurality of subscriber databases; and routing the message to the subscriber database corresponding to the subscriber identity by matching the subscriber identity to the subscriber database.

   17. A telecommunication network entity as claimed in claim 16 wherein the subscriber identity is contained in the payload section.

   18. A telecommunication network entity as claimed in any one of claims 16 to 17 wherein the subscriber identity includes at least one of an IMSI or an MSISDN 19. A telecommunication network entity as claimed in any one of claims 16 to 18 comprising a processor as claimed in any one of claims 11 to 15.20. A telecommunication network entity as claimed in any one of claims 11 to 19, wherein each of the plurality of subscriber databases is a Home Location Register, HLR, or a Home Subscription Server, HSS 21. A method of routing a network operation message in a telecommunication network having a plurality of subscriber databases comprising extracting a subscriber identity from a payload section of the message; obtaining a database identity number including a reference to a subscriber database associated with the subscriber identity, the number being shared with each subscriber database in the plurality of subscriber databases; and routing the message to the subscriber database corresponding to the subscriber identity by matching the subscriber identity to the subscriber database.