Improvements to Home Location Register

Field of the Invention

The present invention relates to a method of and system for processing signalling messages received by a Home Location Register (HLR) in a telecommunications network, and is particularly, but not exclusively, suited to extending the functionality of location-related processing performed by the HLR when processing Mobile Application Part (MAP) messages.

Background of the Invention

The Home Location Register (HLR) is a central database that contains details of each mobile phone subscriber that is authorized to use network services provided by a given GSM network operator. The HLR stores details of every SIM card issued by the network operator in the form of subscriber records that are keyed by a unique identifier associated with the SIM card called an International Mobile Subscriber Identity (IMSI). Typically network operators have millions of active subscribers and a commensurate number of subscriber records in the HLR. The HLR additionally stores data relating to SIM cards that have been issued but have not yet been utilised by subscribers (commonly referred to as unactivated SIMs) so that a subscriber can utilise the network resources as soon as a SIM card is activated. Typically the number of SIM cards that are issued in this manner is far greater than the number that are ever activated, which essentially means that the HLR contains wasted storage. This problem is particularly acute when network operators provision unactivated SIM cards with a range of services such as teleservices, bearer services, supplementary services etc., since each service is identified by means of a record against the SIM. International patent application having publication number WO2007/039277 describes a system in which records corresponding to unactivated SIM cards are stored in a SIM waiting room, from which data are pulled by the HLR in the event that a previously unactivated SIM is activated. A problem with this method is that the HLR needs to pull data from the SIM

waiting room and/or the network requires a node dedicated to detecting the triggers and provisioning the HLR accordingly.

In addition to storing subscriber data that are accessed by network elements when serving requests for network services from mobile devices, the HLR is a system which receives and processes Mobile Application Part (MAP) transactions and messages so as to provide location information in relation to subscribers of its network. Since, by definition, mobile phone subscribers move, having the ability to identify the location of a subscriber is fundamental to the provision of mobile network services. In this respect the HLR is essentially a centralised administrator, managing the mobility of subscribers by updating their recorded position within the network; if the HLR fails, then the mobile network is effectively disabled. The processing by the HLR of any given network operators when performing these location updates is set out in GSM standard MAP 29.002 Phase 2+ Specification for 3G networks; given the importance of the functionality provided by the HLR, all "value-add" location- related functionality is typically implemented within Intelligent Network (IN) components and outside of the HLR.

Summary of the Invention In accordance with an aspect the present invention, there is provided a method and Home Location Register according to the appended claims.

In one arrangement the method involves processing signalling messages received by a Home Location Register (HLR) in a telecommunications network, the signalling messages being received from a device in the telecommunications network via a serving node and being a type of signalling message which is processed by the HLR according to a standardised processing model. The HLR has access to data identifying a plurality of message processing points associated with a given signalling message, and each said message processing point corresponds to a state of processing of the given signalling message by the HLR and is associated with an event to be triggered. The method comprises:

in response to receipt of a predetermined type of signalling message by the HLR, identifying a message processing point from the plurality of message processing points on the basis of said type of signalling message; in response to detection of a state of processing of the signalling message corresponding to the identified message processing point, triggering said event so as to provide a response other than those generated by the HLR according to the standardised processing model.

Thus with embodiments of the invention, standardised processing of a given signalling message, such as is performed by the HLR in accordance with MAP 29.002 Phase 2+ Specification for 3G networks, is supplemented by means of monitoring for processing points relating to the standardised processing, and performing certain actions when the processing points are detected. The processing points can include, for example, a start and an end point of a MAP state machine. In one arrangement the actions involve sending a control message to a service node in the network which can be used in retrieving data, this being subsequently used by the HLR in formulating a response message corresponding to the signalling message. Alternatively the control message could be used to trigger transmission of a data message to the device. Either way, in preferred arrangements the control message is sent by a module local to the HLR in response to said detected state of processing of the signalling message; the module can be selected based on the type of signalling message and/or network subscription, e.g. IMSI, associated with the signalling message. Advantageously, and because the control message is created by a module local to the HLR, the control message can be created using a structured mark-up language such as HTML and XML. This then opens up the possibility of the HLR being able to interact with a wider range of applications than is currently possible with Intelligent Network platforms.

In another arrangement the actions involve modifying an identifier such as a MSISDN associated with the device; this modified MSISDN can then be used to formulate a response message to the signalling message received by the HLR. This arrangement is particularly useful for handling unsolicited SMS

messages, since a module can be introduced specifically for the purposes of marking certain Called Party Numbers as unknown to the network, and ensuring that such messages are thereafter dropped by the network.

According to a further aspect of the present invention there is provided a method of configuring a Home Location Register (HLR) with a trigger, the HLR having access to data identifying plurality of message processing points, each said message processing point corresponding to a state of processing of a signalling message by the HLR and being associated with an event to be triggered. In this further aspect the method comprises: receiving a signalling message from a serving node in the telecommunications network; identifying a message processing point from a plurality of message processing points on the basis of said type of signalling message; configuring the HLR to respond to a detected state of processing of the signalling message corresponding to the identified message processing point so as to trigger said event corresponding thereto, wherein said triggered event comprises sending a control message to a service node in the network, said control message being for use in retrieving data for use in formulating a response message corresponding to the signalling message received by the HLR.

Embodiments according to this aspect of the invention provide a mechanism for dynamically arming the HLR to respond to certain trigger events in dependence on the type of signalling message; for certain HLR portions, the arming of the HLR can also be dependent on the subscriber in respect of which the signalling message issues. The HLR can be armed in relation to MAP, INAP and CAMEL signalling messages, and can link the processing of such messages to the functionality provided by the afore mentioned modules that local to the HLR.

Further features and advantages of the invention will become apparent from the following description of preferred embodiments of the invention, given

by way of example only, which is made with reference to the accompanying drawings.

Brief Description of the Drawings Figure 1 is a schematic diagram of a network environment within which embodiments of the invention operate;

Figure 2 is a schematic diagram showing a portion of the environment shown in Figure 1 ;

Figure 3 is a block diagram showing components of a Home Location Register portion of Figure 2;

Figure 4 is a timing diagram showing steps performed by the components shown in Figure 1 when updating subscriber records;

Figure 5 is a block diagram showing components of further Home Location Register portion of Figure 2 when configured according to an embodiment of the invention;

Figures 6 and 7 are timing diagrams showing steps performed by the components shown in Figure 5 when operating in accordance with an embodiment of the invention;

Figure 8 is a block diagram showing an alternative configuration of components of the Home Location Register portion shown in Figure 3; and

Figure 9 is a timing diagram showing steps performed by the components shown in Figure 1 when the Home Location Register portion is configured as shown in Figure 8.

Detailed Description of the Invention

Embodiments of the invention are concerned with extending the functionality of the Home Location Register (HLR). More specifically, embodiments are concerned with dynamically arming trigger points within the HLR based on signalling messages such as MAP, CAMEL and INAP messages; in the case of MAP messages these trigger points are configured with respect to the MAP operation state machine points of triggering. The processing involved

in arming the HLR with these triggers will be described in detail below, but first an overview of an environment within which embodiments can operate will be described with reference to Figure 1, which shows a cellular communications network 10, such as a GSM network, comprising mobile switching centre (MSC) 2 connected via communications links to a number of base station controllers (BSCs) 4. The BSCs 4 are dispersed geographically across areas served by the MSC 2 and, as is known in the art, each BSC 4 controls one or more base transceiver stations (BTSs) 6 located remote from, and connected by, further communications links to, the BSC 4. Each BTS 6 transmits radio signals to, and receives radio signals from, mobile stations 8 which are in an area (known as a "cell") served by that BTS 6.

The MCS 2 is also connected via communications links to other MSCs (not shown), in the remainder of the communications system 10, and to a public switched telephone network (PSTN), public data network (such as the Internet), etc. which are not illustrated. The network is provided with a home location register (HLR) 12, which is arranged to provide the MSC 2 with data relating to a user upon request (typically populating a visitor location register (VLR), which is part of, or accessible by, the MSC 2). The MSC 2 is capable of handling service provision for both post-pay or contract users and prepaid users of the network in the area it serves. Thus, users may originate or receive a range of data, including multimedia, video, voice, data or fax calls or sessions, short messages using the Short Message Service (SMS), email messages, enhanced or multimedia messages, and may access data resources over private or public data networks such as the Internet. Signalling and data in respect of services provided to mobile stations 8 are routed via MSC 2, and delivery of SMS messages is handled by store-and-forward nodes such as SMSC 20.

The telecommunications network 10 comprises a provisioning system 16, which is capable of independently accessing various network control nodes (such as the HLR 12), triggering updates and modifications to the data stored therein. The provisioning system 16 can be implemented as an intelligent network node in the form of a Service Control Point (SCP) or as an Open

Services Architecture (OSA) node; accordingly it can be configured to receive signalling messages using the INAP, CAMEL, XML or LDAP protocols. It will be understood by one skilled in the art that the configuration, and thus messaging protocols, is a design choice. As is known in the art, the Home Location Register is a central database that contains details of each subscriber that is authorized to use the GSM network 10 in the form of subscriber records. Referring also to Figure 2, whilst Figure 1 depicts HLR 12 as a single database it can be, and typically is, maintained as separate databases 12a ... 12f. Conventionally the Home Location Register stores details of every SIM card issued by the network operator; each SIM has a unique identifier called an International Mobile Subscriber Identity (IMSI) which is one of the primary keys to each subscriber record. The IMSI is an identifier that is internal to the network 10 and used to identify one or more devices within the network 10. In addition each HLR record includes the telephone numbers used to make and receive calls to the mobile phone, known as Mobile Subscriber ISDN (MSISDNs). MSISDNs are external identifiers for use outside of the network to route communications to one or more said devices within the network. In addition the HLR stores data identifying network services accessible by a given subscriber. As will be described in more detail below with reference to Figures 5 onwards, embodiments of the invention are particularly well suited to network configurations in which the telecommunications network comprises a secondary HLR 14, that is to say, secondary to HLR 12 in the sense that it stores data relating to SIM cards other than those relating to fully enabled and activated subscribers of the network 10. Accordingly the first part of the description describes a specific configuration of such a secondary HLR 14, specifically an HLR 14 that holds data relating to SIM cards that have not yet been activated by a subscriber (i.e. those that have not been inserted into a device 8 and used to register with the network 10). The configuration of this HLR 14 is unconventional and indeed forms the subject of Applicant's co-pending International patent application claiming priority from GB0718925.1; however it

is to be understood that the secondary HLR 14 is described herein for the purposes of providing a fully supported embodiment of the present invention.

The secondary HLR 14 is distinguished from a conventional HLR 12 in several ways: it holds a subset of subscriber data held by the HLR 12 (specifically a configurable set of data that allows the device 8 to interact with the network so as to receive a basic set of network services); and it is capable of responding to a subset of MAP messages configured on a fully-activated HLR, and thus is provisioned with a fraction of the processing capabilities required to be implemented in a fully functioning HLR. Thirdly it communicates with the provisioning system 16 via a non-standardised response mechanism and under certain predetermined conditions so as to change the state of the previously unactivated SIM to activated, and thereby enable the device 8 to receive a more advanced set of services. In a preferred arrangement this change of state is accompanied by moving the records held in the secondary HLR 14 to the HLR 12, as will be described in more detail below.

As shown in Figure 2, in some arrangements the telecommunications network 10 also comprises a Service Location Register (SLR) 15, which intercepts all Mobile Application Part (MAP) messages destined for HLR 12, 14 and determines to which physical database (or portion 12a ... 12f) of the Home Location Register the MAP message should be directed. As described in Applicant's European patent EP0784910, the SLR 15 performs a look-up function based on the IMSI contained within the MAP signalling message so as to identify which physical HLR 12a ... 12f holds subscriber records corresponding to the requesting device 8. Since the IMSIs corresponding to unactivated SIMs are stored in the secondary HLR 14 and are thus unknown to the SLR 15, the SLR 15 needs to be provisioned with the network identity of the HLR 14 together with a rule that causes the SLR 15 to send signalling messages corresponding to all unknown IMSIs to the secondary HLR 14. Whilst the secondary HLR 14 is shown as a separate database in the Figures it will be appreciated that it is a specific portion of the network's overall Home Location Register. It will be appreciated by one skilled in the art that routing to HLR

portions 12a ... 12f can be performed by other network nodes such as a Signalling Transfer Point (STP).

Turning to Figure 3, an arrangement of the secondary HLR 14 will now be described in more detail. The secondary HLR 14 comprises a combination of processing components (standard operating system components, memory, processor, Input/Output interfaces, permanent storage, MAP processing software component 301 and bespoke records processing software component 303) and subscriber records relating to unactivated SIMs (DBl). The MAP processing software component 301 is entirely conventional, comprising software routines arranged to execute the processes defined within GSM standard MAP 29.002 Phase 2+ Specification for 3G networks. The database DBl stores data identifying services accessible by devices associated with newly activated SIM cards (keyed by IMSI associated with the SIM cards), and these data are queried by the MAP processing software component 301 in accordance with standard MAP processing methods when the secondary HLR 14 receives a message originating from a device associated with a previously unactivated SIM card. These services data relate to a predetermined and limited set of voice and messaging services; the set can either be standardised for all unactivated SIM cards, or standardised based on type of subscription (e.g. post- pay, pre-pay).

The records processing software component 303 is responsive to certain MAP messages so as to notify the provisioning system 16 that a previously unactivated SIM card relating to an IMSI stored in DBl has been activated. A particularly advantageous configuration of the records processing software 303 will be described later with reference to Figures 5 and 6, in conjunction with the description relating to the second aspect of the invention.

The provisioning system 16 can be embodied as a Service Control Point

(SCP), in which case the records processing software 303 sends an Initial

Detection Point (IDP) to the provisioning system 16 to activate management of updates to the subscriber records; the IDP message includes, as parameters, the

IMSI and/or the IMSI and MSISDN of the SIM in question. Alternatively the

provisioning system 16 can be embodied as an Open Services Architecture (OSA) node, with which the records processing software component 303 can communicate via XML or LDAP so as to notify the provisioning system 16 of the SIM in question. In response to notification of the SIM that has been activated, the provisioning system 16 identifies a portion of the HLR 12 (e.g. portion 12c) to which the subscription corresponding thereto is to be added, and updates the SLR 15 with the identity of this HLR portion 12c so that future requests for network services can be correctly routed to HLR portion 12c. In addition the provisioning system 16 can trigger delivery of certain message types to the device 8, e.g. welcoming the subscriber to the network 10. Furthermore the provisioning system identifies and configures certain network service nodes, e.g. SMS platforms, Prepaid billing platforms, Voicemail platforms, CRM platforms, etc., in accordance with the subscription associated with the IMSI received thereby so as to enable the device 8 to receive network services associated therewith. The steps involved in configuring such nodes in this manner are well known to those skilled in the art.

Figure 4 is a timing diagram illustrating the steps performed when a previously unactivated SIM card is activated by device 8. At step S4.1.1 the device transmits an Attach message, which is transposed to a MAP Send Authentication Information, Send Parameters in MAPvI (SAI) message by the MSC 2, and transmitted to the secondary HLR 14 at step S4.1.3 via the SLR 15. (As described above, the SLR 15 is configured with a look-up table linking all activated IMSIs associated with the network 10 and HLR portions 12a ... 12f, together with a default condition directing the SLR 15 to the secondary HLR 14 in response to receipt of an SAI message identifying an unlisted IMSI). The MAP processing component 301 receives the SAI message and performs conventional authentication routines, returning an SAI acknowledgement message to the MSC (S4.1.5, S4.1.7). Once authenticated, the device 8 transmits a Location Update (LU) message (S4.2.1), which is again forwarded to the secondary HLR 14 via the SLR 15. The process from this point differs from conventional HLR processing methods: as described above, the records

processing software component 303 is configured to monitor for receipt of certain MAP messages, one such message being a Location Update (LU) message, and perform certain steps in response to receipt thereof. In response to receipt of a LU message, the records processing software component sends a notification message to the provisioning system 16 (step S4.3.1).

The format of the notification message will be described in more detail with reference to Figures 6 and 7 and according to a preferred embodiment of the invention; suffice to say at this point that the notification message comprises data identifying the IMSI and optionally the MSISDN corresponding to the SIM associated with the device 8. The notification message can also include data indicative of instructions identifying the type of action required on the part of the provisioning system 16 (e.g. in the event that the provisioning system 16 receives messages from network nodes in addition to the secondary HLR 14).

Turning back to Figure 4, in addition to triggering the records processing software component 303, the LU message causes the MAP processing software component 301 to retrieve, from the DBl, data indicative of services accessible by the newly activated device 8. These services are then notified to the MSC 2 and stored in a VLR thereon in accordance with conventional HLR MAP processing procedures via a series of MAP Insert Subscriber Data (ISD) messages (steps S4.2.5 ... S4.2.11).

The provisioning system 16 sends a response message back to the secondary HLR 14 via the provisioning interface (step S4.3.4) so as to cause the set of subscriber records corresponding to the IMSI identified at step S4.1.1 to be modified in accordance with data contained within the response message. This modification might, for example, involve the secondary HLR portion 14 removing barrings to certain services, provisioning additional teleservices and bearer services etc.; these changes to the subscriber records cause the conventional MAP processing software 301 to send a series of further ISD MAP messages to the MSC/VLR 2, as shown by steps S4.4.1 ... S4.4.n in Figure 4. At a predetermined time (typically overnight), the provisioning system 16 manages the migration of the newly activated subscriber so as to move the subscriber

records from the database portion DBl associated with the secondary HLR 14 to a storage portion associated with the HLR 12, updating the SLR 15 and other nodes involved in the routing of MAP messages accordingly.

Alternatively, step S4.3.3 could involve the provisioning system 16 allocating a portion of the HLR 12 to the IMSI of the newly activated subscriber and updating the SLR 15 in real time. In this arrangement the provisioning system 16 sends a provisioning request to the allocated HLR portion (e.g. 12a) at step S4.3.4 and deletes the subscriber records in DBl. The ISD MAP messages sent at Steps S4.4.1 ... S4.4.3 would then be sent by allocated HLR portion 12a to the MSC 2.

An embodiment of the invention will now be described with reference to Figure 5, which shows the functionality of a given HLR portions 12a. Embodiments of the invention are referred to herein as a MAP trigger engine, and this refers to the combined functionality provided by MAP trigger software component 501, a data structure 502 defining MAP trigger points, and plugin software components 503, 505, 507 shown in Figure 5. Embodiments of the invention make use of the fact that each MAP operation performed by the MAP processing software component 301 comprises a plurality of state machine points of triggering, in particular a "start point" and an "end point", and uses the various trigger points to perform MAP-specific functions. The trigger points are conveniently stored in a structure 502 for each MAP message type; whilst the trigger points are shown being keyed on IMSI, and thus subscriber-specific, it is to be understood that keying in this way is a preferred feature of an embodiment of the invention and that the trigger points could alternatively be configured identically for all subscribers; an example will be described later with reference to Table 2.

An example of a structure 502 is shown in Table 1 below:

Table 1

The plugins 503, 505, 507 are triggered to send data to an information source 18 at one or a plurality of MAP processing points, as specified in the structure 502, and under the control of the MAP trigger software component 501. More specifically, the numbers "0", "1", "2" identify the plugin that is to be invoked in response to a particular state point in respect of a MAP message received from a particular IMSI. For example, referring to Table 1, in relation to the Location Update (LU) MAP message the structure 502 specifies that plugin 1 (503) should be triggered at the "End" point of the state machine corresponding to processing of a LU message by the HLR portion 12a for IMSI 1. In relation to the SSREQ MAP message, the structure 502 specifies that plugin 2 (505) should be triggered at the "End" point of the state machine corresponding to processing of a SSREQ message by the HLR portion 12a for both IMSI 1 and IMSI 2. Whilst the trigger points data 502 are shown as being held separate from the subscriber data DB2, the skilled person will appreciate that these data can be stored as part of the subscriber records. It will also be appreciated that whilst Table 1 shows two trigger points, namely "start" and "end", there could other MAP trigger points listed in the data structure 502; moreover, whilst the table lists plugins against only one of the trigger points for any given MAP message type, it is to be understood that the MAP message could have one or more plugins associated with more than one trigger point.

Each plugin 503, 505, 507 is preferably a self-contained software component that is optionally configured to communicate with an information source 18; the information source 18 stores data used to supplement conventional processing of MAP messages, and is configured to either return selected data to the plugin or to perform a certain function in response to receipt of a message, as will be described below with reference to various example MAP messages. A particularly advantageous feature of this aspect of the invention is that the plugins 503, 505, 507 - or control functionality - are local to the HLR portions 12a ... 12f, 14 rather than being embedded in an SCP such as is described in WO99/60800. As a result, the plugins 503, 505, 507 are not restricted to communicating via IN protocols and can instead use for example XML, which is a particularly flexible mechanism for embedding requests for data, processing instructions and the like, when communicating with the information source 18. As a result the HLR can request data in a more flexible manner than would be possible if the plugins were implemented as part of a

Service Control Point SCP, since data would then have to be requested and received within the constraints of Intelligent Network protocols and procedures.

The plugins 503, 505, 507 are configured in light of the functionality and messaging requirements of the information sources 18 with which they interact, and all processing units are equipped with the requisite XML parsers in accordance with conventional methods. In the event that the action taken by the information source 18 involves sending response messages to the plugins, these can take one of three responses: CONTINUE, indicating that the HLR portion 12a should continue processing according to the MAP state machine with no modifications; CONTINUE + arguments, indicating that processing of the MAP state machine should be restarted, with arguments provided within the CONNECT message; and RELEASE, which causes the HLR portion 12a to terminate processing according to the MAP state machine. The RELEASE response message can include data indicative of the reason for instructing termination of the processing; conveniently this can be specified by selection of an appropriate RELEASE protocol. An example of this response from the

information source 18 will be described with reference to Figure 6. Alternatively the information source 18 can transmit messages destined for nodes other than the HLR portion 12; an example of this will be described with reference to Figure 7. Turning to Figures 6 and 7, it is to be noted that the SLR 15 has been omitted from Figures 6 and 7 since the SLR 15 has merely an entirely conventional role in this aspect of the invention. Turning firstly to Figure 6, this relates to the handling of SMS messages: a short message is sent from the device 8, via the MSC 2 to the SMSC 20 (step S6.1), to a destination terminal. Once received by the SMSC 20, the SMSC 20 sends a MAP message to the HLR portion 12a (this being the HLR portion corresponding to the IMSI of the CdPN) at step S6.2. The MAP message is captured by the MAP trigger software component 501, which accesses the data structure 502 in order to identify the trigger points, if any, corresponding to this MAP message for this Called Party (i.e. MSISDN corresponding to the destination terminal, from which the IMSI can be identified: step S6.3). In addition to capturing the trigger point, the MAP trigger software component 501 identifies the plugin that is to be invoked when the trigger condition is met.

Referring to Table 1 , in this example the trigger point is determined to be "Start" and the Plugin is Plugin 2; the MAP trigger software component 501 is accordingly arranged to monitor for the start of SRI SM MAP processing by MAP processing software 301. In this example it is assumed that the HLR portion 12a cannot locate routing instructions for the Called Party Number; as a result the MAP processing software 301 returns "Subscriber Absent" at the end of its routines. With conventional HLR configurations this would be transmitted back to the SMSC 20 in a SRI-ACK message, causing the SMSC 20 to repeat the delivery attempt at predetermined intervals and the HLR to store the pending SMS message in a queue. With embodiments of the invention, however, once this start point has been detected the MAP trigger software component 501 invokes plugin 2 505. This causes the plugin 505 to change the called party MSISDN to a dummy, non-existent MSISDN and return a CONTINUE with

arguments response (the arguments comprising the dummy MSISDN) - steps S6.9, S6.l l. In response to receipt of the CONTINUE message, the MAP processing component 301 looks up the dummy MSISDN; upon finding that the dummy MSISDN is unknown to the HLR portion 12a (step S6.13) the MAP processing component 301 returns "Unknown Subscriber" in a MAP SRI-ACK message transmitted to the SMSC 20 (step S6.15). Upon receipt, the SMSC 20 discards the SMS message (step S6.17).

This application of the MAP trigger engine is particularly well suited to handling SPAM SMS messages, since it minimises network resources that would otherwise be taken up in the attempted delivery of unsolicited messages.

Figure 7 shows a further example of operation of the MAP trigger engine, in this case in relation to Location Update MAP messages. The steps largely progress as described with reference to Figure 6, but since the MAP message received from device 8 (having IMSI 1) is a LU message, the trigger point is identified from the data structure 502 to be "End" and to relate to plugin 1 503. Accordingly at step S7.15 the MAP trigger software component 501 is triggered to invoke plugin 1 503 on the basis of IMSI 1, which sends a message to the information source 18, identifying the MSC/VLR 2 to which the device 8 is attached and network identifier of the device 8 (IMSI 1). In this example the information source 18 is configured to respond with the transmission of an SMS message Ml instead of sending a response back to the HLR portion 12a (steps S7.19, S7.21). Since the network node 18 is in receipt of mobility information (i.e. identity of the MSC/VLR 2), it can send the message Ml directly to the MSC 2 (thereby bypassing the SMSC 20). This application of the MAP trigger engine is particularly well suited to registration requests from previously unactivated subscribers (and thus arrangements in which the HLR portion 12a is the secondary HLR 14), since the SMS message sent at step S7.19 can be a "Welcome" message, serving to introduce the subscriber to the network. Accordingly, in preferred arrangements of the secondary HLR 14, the Records processing software component 303 is configured as shown in Figure 8. For this secondary HLR 14, entries in the

trigger data structure 502 would not necessarily require keying by IMSI, since by definition all IMSIs stored therein require notifying to the provisioning system 16, and the network operator might decide to send Welcome messages as a matter of course to all newly activated subscribers. An example data structure 502 for the secondary HLR 14 is shown in Table 2, from which it can further be seen that only one set of trigger points is listed therein (for a Location Update MAP message). This is appropriate for arrangements in which subscriber records are moved to a HLR portion 12a ... 12f once the provisioning system 16 has completed its configuration procedure, since any subsequently received MAP messages will be directed to, and handled by, a HLR portion 12a ... 12f corresponding to a fully activated subscriber.

Table 2

Figure 9 shows an alternative form of the timing diagram shown in Figure 4 for the case in which the Records processing software component 301 is embodied as the MAP trigger engine. This arrangement includes the additional step of triggering transmission of a welcome message at the end of the conventional MAP processing. As described above, steps S4.2.5 - S4.2.9 involve the secondary HLR 14 transmitting data indicative of services, including the Short Messaging Service, to which the newly activated subscriber can take up access. Referring also to Figure 7, since these services data are transmitted to the MSC 2 (and thus VLR for the device 8) early in the conventional processing of the LU MAP message, when the Welcome message is delivered to the MSC 2 at step S7.19 by the information source 18 it can be successfully delivered to the device 8.

Whilst the above embodiments describe the invention as a mechanism for triggering of events based on points within the MAP processing state

machine, embodiments of the invention also provide a mechanism for dynamically arming the HLR to respond to certain trigger events. The arming of the HLR can be considered to occur at step S6.3 of Figures 6 and 7, and the HLR can be considered to respond to the trigger so as to invoke a plugin 503, 505, 507 when the relevant point is reached (e.g. Step S6.7 in Figure 6 and Step S7.15 in Figure 7). Turning back to Tables 1 and 2, it will be appreciated that this arming of the HLR is dependent on the type of signalling message; in addition, for certain HLR portions, the arming of the HLR can also be dependent on the subscriber in respect of which the signalling message issues. Whilst the above embodiments describe arming of the HLR in relation to MAP signalling messages, the HLR could be dynamically armed in this manner in relation to signalling messages other than MAP messages: for example, the trigger structure 502 could include INAP and/or CAMEL messages, or indeed any other protocol associated with signalling messages received by the HLR, and link the processing of such messages to the functionality provided by the plugins 503, 505, 507 etc.

The above embodiments are to be understood as illustrative examples of the invention. It is to be understood that any feature described in relation to any one embodiment may be used alone, or in combination with other features described, and may also be used in combination with one or more features of any other of the embodiments, or any combination of any other of the embodiments. Furthermore, equivalents and modifications not described above may also be employed without departing from the scope of the invention, which is defined in the accompanying claims.