WO2006125829A1

WO2006125829A1 - Apparatus for service delivery to communications devices

Info

Publication number: WO2006125829A1
Application number: PCT/EP2006/062647
Authority: WO
Inventors: Steve Bailey; Michael David Stanmore Crook; Michael Eales; Steffen Paessler
Original assignee: Orange Personal Communications Services Limited
Priority date: 2005-05-27
Filing date: 2006-05-27
Publication date: 2006-11-30
Also published as: GB0510955D0; RU2007149246A; GB2427098B; GB2427098A; EP1889508A1; RU2385547C2

Abstract

Embodiments of the invention are concerned with improving methods of organizing subscription data for subscribers in a network, in particular when a subscriber has more than one device or line associated with their subscription. Embodiments of the invention are most conveniently embodied in a home location register ('HLR') for a mobile communications network: data are stored in separate data structures for the devices ('IMSI' ) and line numbers ( 'MSISDN') and currently paired devices and lines are indicated in the HLR by direct references, or pointers, linking one data structure to the other for the devices and lines. The currently paired device and service data are assembled for transmission to a visitor location register ('VLR') , thereby avoiding problems with the prior art of sending subscriber data for all potential pairings. Conveniently, this can be embodied in object-oriented software in which data aliases are used to create the references at appropriate levels in an object hierarchy as each data structure.

Description

Apparatus for Service Delivery to Communications Devices

Field of the Invention

The present invention relates to apparatus for service delivery to communications devices. It finds particular application in delivering services to mobile devices, for example to a group of mobile devices and/or via more than one telephone number associated with one or more devices.

Background of the Invention Worldwide, network technology has varied, the US for example generally using CDMA (Code Division Multiple Access) while Europe developed TDMA (Time Division Multiple Access). GSM (Global System for Mobile communications) has arguably been the most successful, supporting more than half of the world's cellular subscribers. GSM was initially supported by a family of standards drawn up by the European Telecommunications Standards Institute (ETSI). The international community is now working on third generation ("3G") standardisation, based on requirements set by the International Telecommunications Union ("ITU") known collectively as IMT- 2000. IMT stands for International Mobile Telecommunications. Networks under development today include the 3G UMTS ("Universal Mobile Telecommunication System") which is backwards compatible with GSM.

Embodiments of the present invention are generally designed to be at least compatible with GSM-based network technology, including UMTS networks. An established feature of mobile devices is the use of a removable module. These modules were originally designed to comprise simple eight-bit processors with a little memory. Removable modules for GSM systems are conventionally referred to as Subscriber Identity Modules ("SIM cards"), and in the early days of GSM the main task of a SIM was to give authorised users access to specified networks; to this end they stored data about the user and the networks. Nowadays, they are effectively computers, compatible with Java- based languages and operating systems, and capable of supporting many services, for example user personalisation and international roaming. These more sophisticated cards, often referred to generically as "smart" cards because they carry software and can run a set of processes, are referred to by alternative names such as Universal SIM cards or Universal Integrated Circuit Cards ("UICCs"). However, the term "SIM" as used herein is intended generally to mean a card carrying at least some subscriber data which is insertable to mobile devices, whether called a SIM or a UICC or by another name.

Referring to Figure 1, a mobile communications network needs to be able to deliver services to and from a mobile device 105, 110, wherever the device is currently located in relation to the home network 100. Figure 1 shows two networks, 100, 1100: the first network 100 is the home network for the devices 105, 110 as shown; and the second network 1100 is a visited network. Each network 100, 1100 has a set of at least one Mobile Switching Centre 125, 1125 ("MSCs") which route traffic in the respective network, and which are served by a set of base stations 115 (via base station controllers, not shown) which provide the air interface to the mobile devices 105, 110.

To find a device, a GSM network provides two types of data repository, a Home Location Register (HLR) 135 and a Visitor Location Register (VLR) 130. The HLR 135 is a master database which supports a set of subscribers by holding data indicative of available services and current location data, associated with the SIM card of a mobile device 105, 110. A VLR 130 is a database associated with a MSC 125 in the network. Each VLR will hold, on a temporary basis, service data for devices 105, 110 currently registered with it. The HLR 135 holds location data identifying the VLR 130 with which each mobile device 105, 110 has most recently registered.

A device 105, 110 receives location data from the base station 115 for the cell of the network in which it is located. If the device moves and starts to receive data from a switch in a different (VLR) area, the device 105, 110 triggers a location update in the network. The consequence of this is that the HLR 135 updates its own location data and sends service data for the device 105, 110 to the new VLR 130 for the device 105, 110. That is, it cancels the service data at the VLR 130 where the device was previously registered and sends the service data to the new VLR 130, so that the device 105, 110 is now registered with the new VLR 130. This process is known as a location update.

Incoming calls or messages to a mobile device 105 trigger a setup process in which the network queries the HLR 135 in order to obtain the current location data. The call or message is now routed and managed with reference to the VLR 130 with which the device is currently registered. This avoids unnecessary long distance traffic in the network by "delegating" management of the call or message to a local VLR for the called device. The first step in setting up a connection to the called device is taken by the GMSC 140 in the network 100. When a call or message is initiated to a mobile device, it is initiated to an international telephone number (the "MSISDN") for the subscriber. The "Gateway Mobile Switching Centre" GMSC 140 contains data mapping MSISDNs to HLRs. To connect an incoming call, the GMSC 140 requests location data from the appropriate HLR 135 for the called device 105. It is possible that the called device is currently registered with a vMSC/VLR 1125 belonging to a second PLMN 1100, different from that of its HLR 135. This is commonly referred to as "roaming". In this case, the GMSC 140 will still query the HLR 135 to find the current vMSC/VLR 1125 of the called device but the location data will indicate the vMSC/VLR 1125 on the second network 1100.

When the HLR 135 sends service data to a VLR 130, in respect of a newly registering device 105, 110, a portion of the data includes an "International Mobile Subscriber Identity" (IMSI) registered for the SIM card of the device 105, 110. The IMSI is a unique identifier allocated to each SIM in a GSM or UMTS network and stored on the SIM card. It consists of a MCC (Mobile Country Code), a MNC (Mobile Network Code) and a MSIN (Mobile Station Identification Number). The IMSI is paired with the relevant MSISDN to reach that SEVI card in a device. It is the IMSI and/or variants thereof, not the MSISDN, which is transmitted over the air interface in call setup. This provides a level of security since the IMSI is never publicly available and thus cannot be reproduced easily for fraudulent purposes. Turning now to aspects of the subscriber identities - the IMSI and the MSISDN - there is usually a simple one-to-one relationship between the IMSI and the MSISDN. Subscriber data are stored at the HLR in a series of "subscriptions", each subscription being based on an IMSI paired with an MSISDN. However, it has been recognised that a subscriber may have several mobile devices and wish to use any one of them. Further the subscriber may wish to use more than one such device at the same time, for instance to send a facsimile while already involved in a voice call. Arrangements have been developed for enabling these variations, which essentially involve the subscriber being associated with one or more IMSI and/or MSISDN identifiers.

European Patent 1355503 in the name of TDC Switzerland AG describes an arrangement in which one user has access to a group of MSISDNs so that the user can receive a voice call and, for instance, send facsimiles or data at the same time. Data grouping the different IMSIs and MSISDNs relevant to one subscriber are stored on a database external to the HLR. A process associated with this database ensures that the EVISI/MSISDN combinations stored at the HLR reflect the current usage of devices in relation to MSISDN. One IMSI is designated as active, this corresponding to the device the user chooses for voice calls, and an EVISI/MSISDN combination using this IMSI is stored in a location in the HLR designated for the "active" pairing. Other EVISI/MSISDN combinations are also stored in the HLR to support the facsimile/data connections the user might wish to make. If the user wants to change the active device, the external database is configured to change the IMSI/MSISDN combination stored as "active" in the HLR. In practice, this involves swapping the IMSI data to make the new combinations because the set of IMSI data are smaller than the set of MSISDN data. As a result of the process, all previously applicable location information at the VLR is now deleted and the VLR receives data indicative of the newly active EVISI/MSISDN combination.

In a second arrangement, described in US Patent 6,366,777 assigned to Nokia Telecommunications Oy, a subscriber can use more than one SIM (so more than one EVISI) but the same MSISDN. In this case, the HLR has more than one IMSI field in its records for each MSISDN. When the subscriber changes SIM and triggers a Location Update (LU), the HLR checks whether the IMSI involved in the LU is the only one for that subscriber. If the HLR finds there is more than one IMSI stored in a field against the same MSISDN, it runs a check on whether the IMSI involved in the location update is currently active. It can do this by looking at which field the IMSI is stored in. If it is not stored in the currently active field, the HLR needs to deactivate the IMSI marked as currently active and to activate the IMSI involved in the location update. It does this by swapping the IMSIs around in the fields associated with the relevant MSISDN.

Summary of the Invention

According to a first aspect of the present invention, there is provided apparatus for identifying devices in a communications network, the apparatus comprising: a storage system comprising a set of one or more first data storage locations and a set of one or more second data storage locations; and a referencing mechanism for creating a direct link between one of the first data storage locations and one of the second data storage locations, wherein the set of first data storage locations is arranged to store data associated with one or more external identifiers, said external identifiers being for use outside of the network to route communications to one or more said devices within the network, and said set of second data storage locations is arranged to store data associated with one or more internal identifiers, said internal network identifiers being of a different type to said external identifiers and for use in identifying one or more said devices within the network, and wherein said referencing mechanism is responsive to an event associated with either of said external or internal network identifiers so as to change a direct link between said first data storage locations and said second data storage locations on the basis of said event. In the following passages, a set of first data includes an identifier that is externally recognisable outside of the network, for example in the form of an external identifier such as the MSISDN, and/or data indicative of services associated with the MSISDN (such as call forwarding settings, roaming conditions etc,); these latter data are referred to as service data in the description below. A set of the second data includes an identifier that is only recognisable within the network, for example in the form of an internal identifier such as the IMSI, and/or data associated with the device (such as encryption settings and current VLR); these latter data are referred to as device data in the description below. Although the IMSI identifies the SIM card, not the device itself, in practice the SIM card is always present in a specific device and to reach the SIM card, a connection is necessarily made to whichever device the card is present in.

The referencing mechanism can be arranged to create links according to any of the following configurations: two links, a first from an internal identifier to an external identifier, and a second from an external identifier to an internal identifier; two links: a first from an external identifier to a set of device data, and a second from an internal identifier to a set of service data; and two links, a first from a set of service data to a set of device data, and a second from a set of device data to a set of service data. In addition, in a particularly advantageous arrangement each link can be embodied as an entity that maintains a connection from a set of service data corresponding to an external identifier and which has a configurable connection to either an internal identifier or the set of device data corresponding to the internal identifier; such an entity is commonly referred to as an alias in the art. As a further alternative, in any of these possible arrangements the link could be specified in a table, rather than being embodied as a connection between the respective data storage locations. An embodiment of the present invention departs from the conventional

HLR data structures in which data are stored by "subscription", each subscription comprising a one-to-one MSISDN/IMSI combination. Instead, combinations between MSISDN and IMSI identifiers and corresponding sets of device and service data are established using links, and it is the links, rather than the data corresponding to the MSISDN or EVISI that are changed. Such an arrangement provides flexibility in terms of enabling users to use more than one device and be contactable via more than one number, but achieves this in a way that avoids the solutions of the prior art in which data are moved and indeed duplicated within the HLR to establish a pairing. Accordingly, particular advantages of embodiments of the invention include a reduction in storage space required (since data do not need to be copied) and, associated with this, a reduction in the number of possible sources of errors.

Preferably, the apparatus is adapted to provide a plurality of sets of first data storage locations and a plurality of sets of second data storage locations, each set of first data storage locations being related, by means of the referencing mechanism, to at least one set of second data storage locations. In one arrangement the referencing mechanism is arranged to constrain references between related sets of first data storage locations and second data storage locations.

Such an arrangement enables network operators to allocate and efficiently maintain more than one MSISDN (and the sets of service data associated therewith), and more than one IMSI (and the sets of device data associated therewith) to users. If one set of service data and one set of device data are related to one another by the referencing mechanism, these two sets can be allocated to one user or account and the referencing mechanism can be configured to constrain references between these sets of data. Preferably, the referencing mechanism is capable of installing more than one reference to a given set of device data (either directly or via the IMSI, as described above). This supports the type of service sometimes known as "Line 2", in which calls made to more than one number, or line, can be received at the same device in a particularly efficient manner. An embodiment of the invention might be used for example in respect of a group of devices belonging to a team of people such as doctors who operate an on-call rota. A publicly accessible number can be published as the "on call" number and the referencing mechanism can be used to establish a reference between the set of storage locations corresponding to the "on call" number and the set of storage locations corresponding to the EVISI of the device associated with whichever doctor is currently on call. It will be appreciated that the actual device to which this number corresponds can conveniently be changed - to mirror changes to the rota - in the HLR as described above. In addition, the devices of all the doctors can each be paired to service data associated with their own calling number by further references in the HLR, enabling any one of the doctors to make use their own device to make or receive voice or other calls. The apparatus may further comprise selecting means for use in selecting one or more links created or modified by use of the referencing mechanism. The selecting means might for example operate in accordance with rules based on date or time of day. It would not then be necessary for an operator or user to implement changes in call routing. In the example of the doctor on call described above, such linking means could be used to set up an automated rota of doctors on call.

In a known arrangement that enables users to receive and transmit data via a plurality of numbers, the HLR sends service and device data corresponding to each potential MSISDN/IMSI pairing to the VLR as part of the location update. For subsequent call handling events the MSC associated with the VLR has to run a process to determine which MSISDN/IMSI pairing should be used. By contrast, in embodiments of the present invention, the home location register only sends service and device data for the MSISDN/IMSI pairing or pairings that are currently active, which, by definition, are automatically identifiable from the referencing mechanism. This means that the MSC simply handles calls on the basis of the set of service data and device data that it receives from the HLR. As a result, embodiments of the invention co-operate with standard MSCs rather than requiring switches to be provisioned with bespoke software.

Thus, according to a second aspect of the present invention, there is provided a method of registering a device with a communications network, the communications network comprising a plurality of network nodes arranged to route said data, and a storage system comprising a set of one or more first storage locations and a set of one or more second data storage locations, said set of first data storage locations being arranged to store data associated with communications services available to a user of the communications network, and said set of second data storage locations being arranged to store data identifying attributes of a device associated with the user, the method comprising: i) identifying a direct reference between a first data storage location and a second data storage location; ii) selecting first data from the first data storage location and second data from the second data storage location on the basis of the identified direct reference; and iii) sending said selected data, via the network, to a said network node, for use in setting up a network connection The data sent in step iii) above preferably comprise service and device data of the type sent to the visitor location register in known arrangements. A process according to the second aspect of the invention can also be activated in response to any one of the following exemplary scenarios: a user-triggered change to the number that can be called to reach the user, a location update, or an update to the data relevant to the IMSI.

An "account" as used herein is a bundle of one or more sets of services and one or more SIM cards allocated to one account number in an associated billing system.

Brief Description of the Drawings

Routing apparatus according to an embodiment of the present invention, by way of example only, with reference to the accompanying figures in which:

Figure 1 shows a schematic block diagram of a mobile network context for embodiments of the present invention; Figure 2 is a schematic diagram showing a relationship between a mobile device and a number to which calls can be made to reach that device;

Figure 3 is a schematic diagram showing a relationship between a mobile device and two numbers to which calls can be made to reach that device;

Figure 4 is a schematic diagram showing a relationship between two mobile devices and one number to which calls can be made to reach either of the two devices; Figure 5 is a schematic diagram showing a first set of relationships between two mobile devices and two numbers to which calls can be made;

Figure 6 is a schematic diagram showing a second set of relationships between two mobile devices and two numbers to which calls can be made; Figure 7 is a schematic diagram showing a third set of relationships between two mobile devices and two numbers to which calls can be made;

Figures 8a - 8d show, schematically, various arrangements of a data structure for provisioning a home location register;

Figure 9 shows schematically a data hierarchy corresponding to a user having two numbers to which calls can be made, with the second of the numbers selected;

Figure 10 shows schematically a number or device change mechanism for changing the currently active number/device combination designated by the data structure of Figure 8a; Figure 11 shows steps in a process for turning on a handset in an embodiment of the present invention;

Figure 12 shows steps in a process for changing number in an embodiment of the present invention;

Figure 13 shows steps in a process for originating a call in an embodiment of the present invention;

Figure 14 shows steps in a process for terminating a call in an embodiment of the present invention; and

Figure 15 shows, schematically, an application of an embodiment of the present invention.

Detailed Description of the Drawings

As described above, embodiments of the present invention are concerned with providing an efficient mechanism for facilitating changes to, and relationships between, subscriber network identities. The mechanism for effecting these changes is embodied as a referencing system, details of which are presented in detail later in the description. Firstly however, examples of the various services and configurations supported by embodiments of the invention will be introduced with reference to Figures 2 - 7:

Figure 2 shows a service in which a mobile device 105 having one SIM card and therefore one available IMSI is allocated one MSISDN (or line); such a relationship and service can be provided by prior art systems;

Figure 3 shows a "Line 2" service in which a mobile device 105 having one SIM card and therefore one available IMSI can select between lines. As shown, Line 1 205a (MSISDN 1) has been selected as the outgoing line for calls originating from the mobile device 105, while incoming calls made to either line will be directed to the device 105;

Figure 4 shows a "Multi-SIM" service in which more than one mobile device 105a, 105b, each having a SIM card and therefore an EVISI, are allocated to one line. In Figure 4, a device 105a (EVISI 1) has been selected to receive calls on the line but either device 105a, 105b can make outgoing calls on the line;

Figure 5 shows a "Line 2 plus Multi-SIM" service in which more than one mobile device 105a, 105b, each having a SIM card and therefore an IMSI, can each be allocated either of two different lines. In Figure 5, a device 105a (EVISI 1) has been selected to receive calls made to either line, while Line 1 (MSISDN 1) has been selected as the outgoing line for calls originating from either device 105a, 105b;

Figure 6 shows the "Line 2 plus Multi-SIM" service of Figure 5 in which a device 105a (IMSI 1) has been selected to receive calls made to either line, while Line 2 (MSISDN 2) has been selected as the outgoing line for calls originating from either device 105 a, 105b;

Figure 7 shows the "Line 2 plus Multi-SIM" service of Figure 5 in which a device 105b (IMSI 2) has been selected to receive calls made to either line, while Line 1 (MSISDN 1) has been selected as the outgoing line for calls originating from either device 105 a, 105b. It is assumed that data identifying the EVISIs, MSISDNs and services are input to the HLR 135 to support these various service scenarios by existing provisioning systems when a subscriber signs up to the service. Each line 205a, 205b has a set of service data associated therewith and each device 105a, 105b has a set of device data associated therewith; these sets of data are required by the MSC/VLR 125 to support connections requesting access to the line (MSISDN) or device (IMSI). In known systems, either all of the data associated with the services and devices would need to be sent by the HLR 135 to a relevant MSC 125, leaving the MSC 125 to process the data in a specialised way in order to ensure calls are handled correctly, or the services data or device data within the HLR would need to be swapped for each change in configuration (e.g. swapped from one data set to another). Each of the more complex scenarios described above is enabled in a particularly efficient manner by a data structure in the HLR according to an embodiment of the present invention. In particular, the data structure in the HLR 135 stores device and service data separately, the device data being related to the IMSI and the service data being related to the MSISDN, and establishes currently active device/line pairings by installing configurable references (or "pointers", including aliases) between device and service data for the active pairing. Only data for the active pairing are then sent to the MSC 125, which means that the MSC 125 does not have to perform any additional processing in order to identify an active pairing. Details of the data structure and mechanism for processing and accessing data in the data structure will now be described with reference to Figures 8a - 10.

Referring firstly to Figure 8a, in embodiments of the present invention, the data necessary to implement a voice or data connection are separated into two sets of data: one set 825, referred to as service data, associated with the line or MSISDN; and another set 830, referred to as device data, associated with the device or IMSI. Device data in this context comprises current VLR, encryption keys and the like, while service data in this context comprise call barring, call forwarding, network settings and the like, and the service and device data are preferably implemented as objects, having links to a plurality of other objects that are required to support a connection. More specifically the set of data 825 concerning the services accessible to the subscriber - associated with an MSISDN object - is arranged in a first object hierarchy, while the set of device data 830 - associated with an IMSI object - is arranged in a second object hierarchy. In order to assemble data required to support a particular MSISDN/IMSI combination, the HLR 135 needs to access both service and physical device data sets 825, 830, to process the data and to send the processed data to the MSC/VLR 125.

In the arrangement shown in Figure 8a, the two data sets 825, 830 are linked by the use of the object aliases 835a, 835b. In some computer operating systems and programming languages, a data object can be defined once and subsequently a number of aliases can be defined, which do not themselves hold data, but which refer to another data object. (In some languages, this is known as an "equate" instruction.) In this embodiment, an IMSI alias 835a is associated with the service data 841 object in the MSISDN data structure 825 and a MSISDN alias 835b is associated with the device data object 843 in the IMSI data structure 830. The IMSI alias 835a can also be connected to one of the device data objects (in the figure only one is shown) via connector 811a, thereby explicitly linking the set of service data 825 with a set of device data 830, and the MSISDN alias 835b can be connected to one of the service data objects via connector 811b, thereby explicitly linking the set of device data 830 with a set of service data 825. Whilst the figure shows a one:one relationship between the data 825, 830, it will be appreciated that, in order to provide the services shown in Figures 3 - 7, at least one of aliases 835a, 835b will additionally be connected, by other such connectors 811a, 811b, to data objects corresponding to other lines and devices. In this embodiment the links are provided by a combination of a respective alias 835a and a connector 811a.

Figures 8b - 8d show alternative ways of linking a set of service data with a set of device data: as shown in Figure 8b, the links can be embodied as connectors 811a and 811b, which, respectively, are arranged to link service data network identifier (MSISDN) to the device data object 843 and to link device data network identifier (IMSI) to the service data object 841. Alternatively, as shown in Figure 8c, the links can be embodied as connectors 811a and 811b, which, respectively, are arranged to link service and device network identifiers to one another; as a further alternative, shown in Figure 8d, the links can be embodied as connectors 811a, 811b, arranged to link the service data object 841 with the device data object 843. As a further variant, the HLR 135 could have access to a table that stores data indicative of the links between respective sets of service data and device data.

Referring to Figure 9, the basic principle of creating references between the data structures 825, 830 can be extended to cover the scenarios shown in Figures 5 - 7 by provisioning additional sets of device data and/or service data, each set of data being equipped with an appropriate link. Figure 9 shows data structures supporting a Line 2 service, for which there are two sets of service data 825, 827 and one set of device data 830. The device corresponding to device data 830 will need to be able to receive calls via MSISDN 1 and MSISDN 2, corresponding to the sets of data 825 and 827 respectively, and this is facilitated by linking the IMSI alias data objects 835_al and 835_a2 in the service data 825 and 827 to the device data 830 by means of the connectors 81 l_ai and 811_a2.

Selection of the line to be used for outgoing calls is implemented by linking the MSISDN Alias data object 835b in the device data structure 830 to the service data object in the required services data structure (in this example, object 827) by means of connector 811b. This link can be changed - for example when the user wants to use a different line for outgoing calls - by means of a line or device change function 900 ("LDCF"), shown in Figure 10.

The LDCF 900 stores, or has access to, information identifying sets of service data and sets of device data, members of groups of devices and lines, and the current status of the links (if any) between the sets of data. This information can be stored by the LDCF 900 for example in a directory structure 901 such as one compatible with the known service data function ("SDF") used in intelligent network technology to separate service data from service control logic. In addition, as listed in Figure 10 in the directory structure 901, the LDCF 900 stores a set of rules for use in applying changes to line or device data and/or to links between the sets of data. In order to ensure that the data utilised by the LDCF 900 are current, either the HLR 135 copies the service and device data to the directory structure 900 whenever it is provisioned or updated, or the LDCF 900 accesses the services and device data directly rather than storing a separate copy. In addition, the LDCF 900 comprises processes 907 for implementing rules and changing or creating links between service data and the device data. The rules enable automated behaviour of the HLR 135, for example to change a current device or line according to context dependent data such as time of day, day of the week, location, credit available to the user etc.. The "set current line or device" process identified in Figure 10 is a process for changing the links 835a, 835b, 811a, 811b in the HLR 135 and is triggered by conditions satisfying the afore-mentioned rules. An example of operation of both the rules and the "set current line or device" process is provided at the end of the description, in respect of a scenario entitled "Doctors on Call". It will be appreciated from the foregoing that service data are selected by the HLR 135 on the basis of the IMSI in response to events such as the user turning on a handset, and a handset changing location area, while device data are selected by the HLR 135 on the basis of the MSISDN in response to events such as the occurrence of a mobile terminating call. In addition, changes to the link(s) between sets of service data and device data (for example either by user command or according to a rule) can trigger the HRL 135 to select a set of either services or device data (dependent on the nature of the command or output of the rule).

Operation of the HLR data structure will now be described for various call scenarios for the case where a subscriber has two lines (MSISDN 1, MSISDN 2) and one device (IMSI 1) (so corresponding, for example, to the arrangement shown in Figure 3). It will be appreciated that if an account covers a second, or indeed further, device, (e.g. in a Multi-SEVI/Line 2 arrangement, as shown in Figures 5 - 7), then the process steps described below could be applied in relation to each such device. Turn on Handset

In this scenario, it is assumed that the user has previously selected the line MSISDN 1 and therefore a link 835b, 811b in the HLR 135 has been set between a set of services data 825 and the set of device data 830 to identify the line MSISDN 1. Referring to Figure 11, the following steps take place in response to a user turning on their handset 105.

STEP 800: the handset 105 transmits its IMSI to the MSC/VLR 125.

STEP 805: the MSC 125 forwards the IMSI to the relevant HLR 135.

STEP 810: the HLR 135 checks that access is allowed and identifies the relevant MSISDN via the link 835b, 811b between the IMSI set of devices data 830 and the set of services data 825.

STEP 815: the identified data are transmitted to the MSC/VLR 125.

STEP 820: the MSC 125 returns a confirmation to the handset 105.

Thus the service and device data for the handset have been updated at the MSC/VLR 125.

Regarding known arrangements, the STEPS 800 to 820 described above differ in that the HLR 135 only sends the service and device data supporting the current MSISDN 1/IMSI pairing to the MSC/VLR 125, whether as a response to a location update or in response to the handset being switched on. In known arrangements, service and device data supporting both the MSISDN 1/IMSI and the MSISDN 2/EVISI pairings would have been sent to the MSC 125.

Change Current Line

As described above, within (as shown in figure 12) or external to the HLR 135, there is provided Line or Device Change Function (LDCF) 900, which can create or modify links 835a, 835b, 811a, 811b in the HLR 135, thereby creating selected MSISDN/EVISI pairings. In this example, shown in Figure 12, the functionality of the line change function 900 is described in relation to a user input at the handset 105. STEP 905: the user inputs a change of line command at the handset 105. STEP 910: the handset 105 sends a change line request to the MSC 125 STEP 915: the MSC 125 forwards the line change request over the network to the LDCF 900. The route this takes depends on the technology used: for example, for SMS this would be via an SMSC and for USSD this would be via the HLR and USSD server. STEP 920: the LDCF 900 instructs the HLR 135 to change the link 835b, 811b in place in the HLR 135 in accordance with the change line request (it will be appreciated that the LDCF 900 could alternatively change the link itself).

STEP 925: the HLR 135 implements the change of line by moving the connector

811b associated with the IMSI for the relevant handset 105 from the set of service data representing an existing line 825 to data representing the new one

827.

STEP 930: changes to the service data for the new MSISDN/IMSI pairing are sent to the MSC/VLR 125.

STEP 935: the MSC/VLR 125 acknowledges the data. STEP 940: the LDCF 900 receives confirmation.

STEP 945: the LDCF 900 sends confirmation to the MSC 125.

STEP 950: the MSC 125 sends confirmation back to the handset 105.

STEP 955: the handset 105 displays confirmation for the user that the required change has been made. This process is different to known arrangements, in which the handset

105 itself records the change of line, the change having no impact elsewhere.

Originating Call

Referring to Figure 13, when a user originates a call from a device 105, the following steps take place:

STEP 1000: the device 105 signals call setup to the MSC 125.

STEP 1005: the VLR 130 associated with the MSC 125 only has data for the current MSISDN/EVISI combination and thus the MSC 125 performs standard call handling. This process is different to known arrangements in which the handset

105, to originate a call, sends the line recorded as current at the handset 105 to the MSC 125. The MSC/VLR 125 then has to process the service data already present in order to pick up the correct calling line indicator ("CLI") for an outgoing call. In embodiments of the present invention, such processing at the MSC/VLR 125 is unnecessary because by definition only one set of data is stored, allowing subsequent call handling to be performed in accordance with standard techniques.

Terminating Call

When a user receives a call on either of the two lines available to the device 105, the steps are equivalent to conventional call processing steps for a single line to single device with the exception of the steps involved in identifying a current MSISDN/EVISI pairing, which, in embodiments of the invention, require the HLR 135 to identify the current MSISDN/IMSI combination by means of links 835a, 835b, 811a, 811b between the set of services data 825 corresponding to the line receiving the call (for instance MSISDN 1) and the set(s) of device data 830. This method is performed in respect of all calls, whether single line or using any other pairings. The HLR has no knowledge of the service and continues in accordance with conventional methods.

Referring to Figure 14, in the case of a Line 2-to-single device service, where the device 105 is roaming and thus registered with a vMSC/VLR 1125 in a network 1100 other than the home network 100, the process steps for receiving a terminating call are as follows in accordance with conventional methods: STEP 1100: a call, for instance on MSISDN 1, is received at the relevant GMSC 140. STEP 1105: the GMSC 140 refers to the HLR 135 to obtain appropriate routing information.

STEP 1110: the HLR 135 checks that the call is allowed and identifies the relevant IMSI via the link 835_al, 811_ai between the MSISDN 1 set of services data 825 and the set of device data 830. STEP 1115: the HLR identifies the vMSC/VLR 1125 with which the device 105 is currently registered and requests a roaming number from the vMSC/VLR 1125 in respect of the relevant IMSI. STEP 1120: the vMSC/VLR 1125 allocates a roaming number and records the IMSI against it.

STEP 1125: the vMSC/VLR 1125 notifies the roaming number to the HLR 135. STEP 1130: the HLR 135 notifies the roaming number to the GMSC 140. STEP 1135: the GMSC 140 routes the incoming call to the vMSC/VLR 1125 using the roaming number.

STEP 1140: the vMSC/VLR 1125 retrieves the IMSI from the roaming number. STEP 1145: the call is connected to the device 105 identified by the retrieved IMSI and the device 105 displays the relevant CLI. As stated above, these call processing scenarios are based on a Line 2 service to a single device 105 (i.e. a single IMSI), as per the arrangement shown in Figure 3. If the subscriber had a Multi-SEVI service, the subscriber records would comprise two or more sets of device data 830, in which case there would be a plurality of links 835b, 811b (not shown), one originating from each set of device data, and the handling of a terminating call would be based on the link associated with the device data of the current IMSI.

In relation to users having subscribed to a Line 2 service, the steps set out above apply irrespective of the line on which a call is received. However, the MSC/VLR 125 only holds data relating to the current MSISDN/IMSI and, for the example set out above, only includes service data for MSISDN 1. If an incoming call is received on this line, then the service data at the MSC/VLR 125 will be appropriate. However, if an incoming call is received on the inactive line, via MSISDN 2, then the service data at the MSC/VLR 125 may not be appropriate. In relation to call forwarding services in particular, the forwarding service processes could potentially result in calls being directed to the wrong destination if dealt with at the MSC/VLR 125 in accordance with only active line service data. Thus, some kind of call handling mechanism is required in order to ensure provision of service in respect of the inactive line. It will be appreciated that this problem is not encountered with conventional arrangements in respect of which all sets of data - active or inactive - are sent to the MSC/VLR. In order to avoid service processes being provided inappropriately at the MSC/VLR, it is an option to disable relevant services as the service data are sent to the MSC/VLR 125 by the HLR 135, although leaving them apparently "active and operable" within the environment of the HLR 135. Because the MSC/VLR 125 cannot then action them, incoming calls could be monitored at the GMSC 140. If a call is detected that does not go ahead because it requires redirection, this can be determined at the GMSC 140 and a query sent to the HLR 135 to obtain correct forwarding data. This might be done for example by a service control point (SCP) of known type.

Application of Embodiments: Doctors on Call

Referring to Figure 15, an application of embodiments of the invention will now be described for a scenario requiring communication with various General Practice surgeries. In the example it is assumed that two doctors are members of a first practice that operates an "on call" rota when the surgery is closed; the "on call" doctors are associated with devices having, respectively, SIM cards IMSI 1 and IMSI 2. A second practice provides emergency cover via a further device having SIM card IMSI 3. In the first practice the reception is associated with a device having SEVI card EVISI 4. Time dependent rules TDRl to TDR3, listed below, allow a rota to be set up between the devices. These time dependent rules cause the LDCF 900 to change the links 835a, 811a in the HLR 135 at 18.00, 01.00 and 08.00. The device data identifies the IMSIs of relevant SIM cards: TDRl : If 18.00 - 01.00 then CurrentDevice=IMSI 1 TDR2: If 01.00 - 08.00 then CurrentDevice=IMSI 2

TDR3: If 08.00 - 18.00 then CurrentDevice=IMSI 4

The devices are assigned as follows: Nominated: EvISI 1 , IMSI 2, IMSI 3 Default: IMSI 4 These rules are stored against a MSISDN assigned to a publicly available telephone number, which has been assigned to the group specifically for callers to reach a doctor on call, out of surgery hours, and which is referred to herein as the MSGN 1500. In addition each SIM card IMSI 1...4 has a telephone number and thus a separate MSISDN associated therewith (MSISDNl ...MSISDN4). It is to be noted that the IMSI links 835_al, 811_al, 835_a2, 811_a2 for MSISDN 1 and MSISDN 2 remain pointing to IMSI 1 and IMSI 2 throughout, which means that doctors can continue to receive calls on their respective MSISDNl and MSISDN2 while incoming calls on MSGN 1500 will be directed to whichever device is associated with the currently active IMSI.

An additional option is to use existing service data such as "call forward on busy". This might be provided within the service set for the MSGN 1500 to forward calls to the default IMSI in the event that the handset of the doctor on call is already engaged on a call, either via the MSGN 1500 or via its own MSISDN.

In the following passages, a scenario is described in which the data stored in storage 901 and the HLR are updated in response to various time and device related events.

Considering firstly the time related events, at 01.00, rule TDR2 is triggered, requesting the relevant EVISI link 835_a__msgn, 811_a-_msgn for the MSGN 1500 to change from pointing to IMSI 1 to point to IMSI 2. In response, the LDCF 900 checks the status of the device associated with IMSI 2 and determines that the device is switched off, causing the IMSI link 835_a__msgn, 81 l_a_ msgn to point instead to IMSI 4 (the default device). At some time later the device corresponding to EVISI 2 is turned on, causing the following steps to ensue:

STEP 1500: The handset 105b signals to the MSC 125 with which it is registered; STEP 1505: The MSC 125 notifies the HLR 135; STEP 1510: The HLR 135 checks that access is allowed, causing service data corresponding to the active line to be retrieved, and triggers the LDCF process 900; STEP 1515: The LDCF process 900 triggers the rules and finds under rule TDR2 that IMSI 2 should be current. The LDCF process 900 therefore instructs the HLR 135 to move the relevant connector 811_a-_msgn;

STEP 1520: The HLR 135 changes the connector 811_a-ms_gn in the data structure for the set of MSGN service data to point to IMSI 2 instead of EVISI 4; STEP 1525: The HLR 135 also updates the device data at the VLR 130 to reflect the newly active MSISDN/IMSI pairing, using a Cancel Location signal (of known type) and sending device data corresponding to IMSI 2; STEP 1530: The HLR 135 confirms the change in link back to the LDCF 900; STEP 1535: The LDCF 900 reports back to the MSC 125 for the handset 105b corresponding to IMSI 2; and STEP 1540: The MSC 125 sends confirmation back to the handset 105b.

Additional Details Amending the links 835a, 811a, 835b, 811b between the MSISDN and

IMSI data hierarchies is done using known object oriented software programming techniques. Each alias 835a is embodied as a software object and therefore comprises data which can only be operated on using specified methods encapsulating the data. Failure processing is preferably provided, in known manner, to ensure that the links are kept consistent and that changes can be undone in the event that a critical step fails.

In the above description it is assumed that although the links can be modified dynamically, a link always exists between one or more sets of services data and one or more sets of device data. However, the link could itself be ascertained dynamically, on the basis of various rules and the like that are either stored by, or accessible to, the HLR 135, at the time of data retrieval (e.g. in response to a Location Update, processing of a Mobile Terminating call). Thus data required to identify a current line or device - rules and/or manual input from the user - would be stored in response to input and reviewed at the time of data retrieval, instead of being used to change a link. Processing means to effect the storage of such input could be embodied in the HLR or in a separate system; in either case, the data would be accessed when a query in respect of a user is received, and the appropriate services and/or device data corresponding to the query identified in real-time.

In the above embodiments it is assumed that there is one link between a set of service data and the IMSI identifier. However, a set of links could be used in place of a single link, which, when the set of service data comprise data corresponding to two or more different types of services, facilitates flexible selection of (a) particular service(s) within the set.

Claims

1. Apparatus for identifying devices in a communications network, the apparatus comprising: a storage system comprising a set of one or more first data storage locations and a set of one or more second data storage locations; and a referencing mechanism for creating a direct link between one of the first data storage locations and one of the second data storage locations, wherein the set of first data storage locations is arranged to store data associated with one or more external identifiers, said external identifiers being for use outside of the network to route communications to one or more said devices within the network, and said set of second data storage locations is arranged to store data associated with one or more internal identifiers, said internal network identifiers being of a different type to said external identifiers and for use in identifying one or more said devices within the network, and wherein said referencing mechanism is responsive to an event associated with either of said external or internal network identifiers so as to change a direct link between said first data storage locations and said second data storage locations on the basis of said event.

2. Apparatus according to claim 1, wherein the storage system comprises a plurality of sets of first data storage locations and a plurality of sets of second data storage locations, each set of first data storage locations being related to a respective set of second data storage locations for use by the referencing mechanism.

3. Apparatus according to claim 1 or claim 2, wherein the set of first data storage locations is arranged to store data associated with communications services available to the user, and said set of second data storage locations is arranged to store data identifying attributes of a device associated with the user.

4. Apparatus according to any one of the preceding claims, wherein the link identifies an external identifier with an internal identifier and said referencing mechanism is responsive to said event so as to identify a different link between said external identifiers and said internal identifiers.

5. Apparatus according to claim 3, wherein the link identifies an internal identifier with a set of services data and said referencing mechanism is responsive to said event so as to identify a different link between a set of services data and said internal identifiers.

6. Apparatus according to claim 3, wherein the link identifies an external identifier with a set of device data and the referencing mechanism is responsive to said event so as to identify a different link between a set of device data and said external identifiers.

7. Apparatus according to claim 3, wherein the link identifies a set of services data with a set of device data and the referencing mechanism is responsive to said event so as to identify a different link between said sets of services data and sets of device data.

8. Apparatus according to any one of claim 3 to claim 7, wherein the referencing mechanism includes a first entity associated with a set of said services data and a second entity associated with a set of said device data, and the referencing mechanism is responsive to said event so as to change a link between the first entity and said internal identifiers.

9. Apparatus according to any one of claim 3 to claim 8, wherein the referencing mechanism is responsive to said event so as to change a link between the second entity and said external identifiers.

10. Apparatus according to any one of the preceding claims, wherein the referencing mechanism is arranged to constrain references between sets of first data storage locations and second data storage locations.

11. Apparatus according to any one of the preceding claims, wherein the referencing mechanism is arranged to create more than one link with respect to a given set of first data storage locations.

12. Apparatus according to any one of the preceding claims, wherein the referencing mechanism is arranged to create more than one link with respect to a given set of second data storage locations.

13. Apparatus according to any one of the preceding claims, wherein the storage system is arranged to store a plurality of software objects, each first data storage location and each second data storage location comprising a plurality of respective first and second software objects, each of the first and second plurality of objects corresponding to an aspect of a network service and/or a device attribute, wherein each link comprises an object linked to one of the first or second plurality of software objects and being arranged to hold data identifying a software object in the other of the first or second plurality of software objects.

14. Apparatus according to any one of the preceding claims, wherein each first data storage location is adapted to store a selected portion of data necessary to set up a connection in the communications network, and each second data storage location is adapted to store a complementary selected portion of said data corresponding to said connection, the referencing mechanism being arranged to create a link between respective first and second data storage locations which together provide sufficient data to set up said connection.

15. Apparatus according to any one of the preceding claims, comprising connection means for use in assembling data for use in setting up a connection to a device in the network, the connection means being adapted to assemble data in part from a first data storage location and in part from a second data storage location, said first and second data storage locations being interrelated by means of a link therebetween.

16. Apparatus according to any one of the preceding claims, wherein the storage system is arranged to store a plurality of rules for use in changing said link.

17. Apparatus according to any one of the preceding claims, including a repository arranged to store rules for use by the referencing mechanism in creating or modifying said links.

18. Apparatus according to any one of the preceding claims, wherein each said internal network identifier comprises an identifier for an identity module adapted for insertion into a communications device.

19. Apparatus according to any one of claim 1 to claim 17, wherein each said internal network identifier comprises an identifier for a device.

20. Apparatus according to any one of the preceding claims, wherein the data associated with a given external identifier are stored in no more than one first data storage location.

21. Apparatus according to any one of the preceding claims, wherein the data associated with a given internal identifier are stored in no more than one second data storage location.

22. A method of registering a device with a communications network, the communications network comprising a plurality of network nodes arranged to route said data, and a storage system comprising a set of one or more first storage locations and a set of one or more second data storage locations, said set of first data storage locations being arranged to store data associated with communications services available to a user of the communications network, and said set of second data storage locations being arranged to store data identifying attributes of a device associated with the user, the method comprising: i) identifying a direct reference between a first data storage location and a second data storage location; ii) selecting first data from the first data storage location and second data from the second data storage location on the basis of the identified direct reference; and iii) sending said selected data, via the network, to a said network node, for use in setting up a network connection.

23. A method of processing a call within a communications network, the communications network comprising a plurality of network nodes arranged to route data within said communications network, and a storage system comprising a set of one or more first storage locations and a set of one or more second data storage locations, said set of first data storage locations being arranged to store data associated with communications services available to a user of the communications network, and said set of second data storage locations being arranged to store data identifying attributes of a device associated with the user, the method comprising: transmitting data indicative of a called number corresponding to said user to the storage system; identifying a status of said called number on the basis of a reference between said set of first data storage locations and said set of second data storage locations; in the event that the called number is identified as inactive, handing control of the call processing to a gateway node, and in the event that the called number is identified as active, transmitting data retrieved from the second data storage locations to a network node associated with the device.

24. Apparatus for identifying devices in a communications network, the apparatus comprising: a storage system comprising a set of one or more first data storage locations and a set of one or more second data storage locations, each set being associated with a user of the communications network; and a referencing mechanism for creating a direct link between one of the first data storage locations and one of the second data storage locations, wherein the set of first data storage locations is arranged to store data associated with communications services available to the user, and said set of second data storage locations is arranged to store data identifying attributes of a device associated with the user, and wherein said referencing mechanism is responsive to an event associated with either of said external or internal network identifiers so as to change an existing direct link between said first data storage locations and said second data storage locations on the basis of said event.