Classifications

• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04W—WIRELESS COMMUNICATION NETWORKS
  • H04W8/00—Network data management
  • H04W8/02—Processing of mobility data, e.g. registration information at HLR [Home Location Register] or VLR [Visitor Location Register]; Transfer of mobility data, e.g. between HLR, VLR or external networks
  • H04W8/04—Registration at HLR or HSS [Home Subscriber Server]
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04W—WIRELESS COMMUNICATION NETWORKS
  • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04W—WIRELESS COMMUNICATION NETWORKS
  • H04W60/00—Affiliation to network, e.g. registration; Terminating affiliation with the network, e.g. de-registration
  • H04W60/04—Affiliation to network, e.g. registration; Terminating affiliation with the network, e.g. de-registration using triggered events
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04W—WIRELESS COMMUNICATION NETWORKS
  • H04W60/00—Affiliation to network, e.g. registration; Terminating affiliation with the network, e.g. de-registration
  • H04W60/06—De-registration or detaching

Definitions

• 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.
• GSM Global System for Mobile communications
• ETSI European Telecommunications Standards Institute
• IMT International Telecommunications Union
• IMT- 2000 International Mobile Telecommunications
• Embodiments of the present invention are generally designed to be at least compatible with GSM-based network technology, including UMTS networks.
• 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.
• SIM cards Subscriber Identity Modules
• SIM cards Subscriber Identity Modules
• 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.
• SIM Subscriber Identity cards
• UICC Universal Integrated Circuit Cards
• 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.
• MSCs Mobile Switching Centre 125, 1125
• 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.
• MSISDN international telephone number
• the "Gateway Mobile Switching Centre" GMSC 140 contains data mapping MSISDNs to HLRs.
• 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.
• a portion of the data includes an "International Mobile Subscriber Identity" (IMSI) registered for the SIM card of the device 105, 110.
• IMSI International Mobile Subscriber Identity
• 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).
• MCC Mobile Country Code
• MNC Mobile Network Code
• 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.
• 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.
• EVISI/MSISDN combinations are also stored in the HLR to support the facsimile/data connections the user might wish to make.
• 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.
• a subscriber can use more than one SIM (so more than one EVISI) but the same MSISDN.
• the HLR has more than one IMSI field in its records for each MSISDN.
• 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.
• apparatus for identifying devices in a communications network 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.
• 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.
• 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.
• 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.
• the link could be specified in a table, rather than being embodied as a connection between the respective data storage locations.
• 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.
• 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.
• 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.
• 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.
• 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.
• 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.
• the HLR sends service and device data corresponding to each potential MSISDN/IMSI pairing to the VLR as part of the location update.
• the MSC associated with the VLR has to run a process to determine which MSISDN/IMSI pairing should be used.
• 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.
• embodiments of the invention co-operate with standard MSCs rather than requiring switches to be provisioned with bespoke software.
• a method of registering a device with a 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
• 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.
• 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.
• FIG. 15 shows, schematically, an application of an embodiment of the present invention.
• 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;
• FIG 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.
• Line 1 205a MSISDN 1
• MSISDN 1 MSISDN 1
• FIG. 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.
• 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;
• FIG. 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.
• a device 105a EVISI 1
• MSISDN Line 1
• FIG. 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;
• IMSI 1 a device 105a
• MSISDN 2 Line 2
• FIG 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.
• IMSI 2 a device 105b
• MSISDN 1 Line 1
• 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).
• MSISDN line
• IMSI device
• 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).
• 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.
• 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
• service data in this context comprise call barring, call forwarding, network settings and the like
• 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.
• 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.
• 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.
• the two data sets 825, 830 are linked by the use of the object aliases 835a, 835b.
• 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.)
• 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.
• 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.
• 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.
• MSISDN link service data network identifier
• IMSI link device data network identifier
• 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.
• 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.
• 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 a i 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.
• LDCF line or device change function 900
• 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.
• SDF service data function
• 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.
• 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.
• 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.
• changes to the link(s) between sets of service data and device data 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).
• HLR data structure 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
• 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.
• 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.
• service and device data supporting both the MSISDN 1/IMSI and the MSISDN 2/EVISI pairings would have been sent to the MSC 125.
• 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.
• 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 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
• 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
• 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
• the MSC/VLR 125 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.
• CLI calling line indicator
• 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.
• 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.
• 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 a i 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.
• 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.
• 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.
• the steps set out above apply irrespective of the line on which a call is received.
• 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.
• 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.
• 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.
• SCP service control point
• the devices are assigned as follows: Nominated: EvISI 1 , IMSI 2, IMSI 3 Default: IMSI 4
• EvISI 1 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.
• each SIM card IMSI 1...4 has a telephone number and thus a separate MSISDN associated therewith (MSISDNl ...MSISDN4).
• 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.
• 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.
• 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).
• 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 - m sgn;
• STEP 1520 The HLR 135 changes the connector 811 a -ms g n 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.
• 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.
• 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.
• 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).
• 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.

Landscapes

• Engineering & Computer Science (AREA)
• Computer Networks & Wireless Communication (AREA)
• Signal Processing (AREA)
• Databases & Information Systems (AREA)
• Mobile Radio Communication Systems (AREA)
• Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Applications Claiming Priority (2)

Publications (1)

Family

ID=34834811

Family Applications (1)

Country Status (4)

Families Citing this family (5)

Family Cites Families (6)

• 2005
  • 2005-05-27 GB GB0510955A patent/GB2427098B/en not_active Expired - Fee Related
• 2006
  • 2006-05-27 EP EP06763306A patent/EP1889508A1/de not_active Withdrawn
  • 2006-05-27 RU RU2007149246/09A patent/RU2385547C2/ru not_active IP Right Cessation
  • 2006-05-27 WO PCT/EP2006/062647 patent/WO2006125829A1/en not_active Application Discontinuation

Non-Patent Citations (1)

Also Published As

Similar Documents

Legal Events